Content Delivery over SDN: incremental vs. clean-slate ... · 데이터는 노드 B1, A2를 거쳐 A1에게까지 전달된다. 여기서 A1은 source의 주소를 다시 원래의

52

OSIA S&TR JOURNAL

OSIA Standards & Technology Review Journal * September 2012, Vol.25, No.3 53

요약 최근10년간의인터넷트래픽변화를살펴보면,호스트중심의응용과서비스에서콘텐트

중심으로이동해온경향이가장두드러진다.특히네트워크의트래픽양은비디오트래픽의증

가에기인하여폭발적으로늘어나고있다.따라서이러한콘텐트들을어떻게망에부하를줄이

면서사용자에게빨리효율적으로전달하는지여부가현재인터넷사업자들에게최대관심사

이다.콘텐트들을인터넷에서효율적으로전송하기위해서는근본적으로망장비들이어떤콘

텐트가전송되고있는지를파악해야하는데,현재망장비들은콘텐트의내용을전혀모르고IP

주소만보고패킷을전송하기때문에문제가생긴다.본고에서는라우터/스위치들이콘텐트

의내용을알도록하기위해서2가지방법을소개하는데,하나는콘텐트별로IP주소를할당하

는점진적인접근방법이고,또하나는혁신적인콘텐트중심네트워킹기술을구현하는방법이

다.두가지다OpenFlow/SDN기술을사용해서구현가능하다.

1. 서론 원격접속이나파일전송등호스트간의자원공유를주요응용으로하는인터넷은host-

to-host통신패러다임을기반으로설계되었으나최근에는웹,비디오전송,P2P기반의파일

공유등의콘텐트중심의응용들이인터넷트래픽의대부분을차지하고있다.하지만현재의

인터넷은수십년전에설계된아키텍처및프로토콜구조를그대로유지하고있기때문에이

러한콘텐트중심의통신응용들로변화되는환경에효과적으로대처하기어렵다는한계점을

지니고있다.따라서이러한현재인터넷의근본적인한계와약점을해결할수있는새로운형

태의미래인터넷에대한연구가전세계적으로활발하게진행중이다.

대표적인미래인터넷연구로는정보중심의네트워킹(Information-CentricNetworking,

ICN)연구를들수있다[1][2].호스트중심의인터넷디자인과실제인터넷사용패턴의괴리

는수백만의사용자가동일한콘텐트를동시에요청하는경우에서버성능저하문제를발생

시키고,또한동일한콘텐트가사용자수만큼반복되어전송되는중복다운로드로인해네트워

크자원낭비문제를심화시킨다.이러한문제점을해결하고,효율적인콘텐트전달을가능하

게하기위해콘텐트중심으로인터넷을새롭게설계하고자하는연구방향이바로정보중심

의네트워킹(Information-CentricNetworking,ICN)연구이다.대표적인연구로는미국UC

버클리의Data-OrientedNetworkArchitecture(DONA)[3],PARC의Content-Centric

Networking(CCN)[4][5][6],EUFP7프로젝트의Publish-SubscribeInternetRouting

Paradigm(PSIRP)[7],4WARD의NetworkingofInformation(NetInf)[8]등이있다.

한편software-definednetworking(SDN)[9][10]기술은크게두가지문제를해결하기

위해등장하였다.첫째는클라우드컴퓨팅,멀티미디어등대용량트래픽증가,트래픽동적

인변화증가등기존의네트워킹기술로는급변하는망변화에대처를효율적으로못하는것

이하나고,둘째는망장비들이proprietary기술로구현되어있는경우새로운기술이나프

로토콜들을개발,운영하는것이매우어려운데이를개방형인터페이스로표준화하면동적

인환경이나새로운요구사항에맞추어망의운영을쉽게중앙서버에서제어할수있다.가

장대표적인OpenFlow기술은중앙서버controller와OpenFlow장비들간의인터페이스

를OpenFlow프로토콜로표준화하고이를이용해각flow를어떻게처리할지controller

가제어하는기술이다[11][12][13].스탠포드대학의주도로시작된OpenFlow기술의상용

화를촉진시키기위해서2011년3월표준화단체인ONF가만들어졌다.ONF는Deutsche

Telekom,Facebook,Google,Microsoft,Verizon,Yahoo!에의하여설립되었으며,여기서

OpenFlow기술을표준화하고있다.

본고에서는OpenFlow기술을이용하면콘텐트중심응용의트래픽들을효율적으로전송

하기위한두가지접근방법을설명한다.첫째는incremental접근방법으로기존OpenFlow

기술에서구현가능한기술로각콘텐트이름을하나의IP주소로매핑시켜서같은콘텐트는같

은IP주소의flow로처리하는방법니다.둘째는혁신적인(cleanslate)접근방법으로PARC

의CCN기술을향후정의될OpenFlow기술을사용해서구현하는것이다.즉웹주소와같은

콘텐트이름이각패킷에있으면OpenFlow장비들이이를분석하고콘텐트캐쉬와pending

interesttable에관련데이터를처리하는것이다.2장과3장에서두가지방법을자세히소개

한다.

2. 점진적인 (Incremental) 접근 방법 본장에서는IP기반의네트워크에서OpenFlow를이용하여콘텐트전송을효율적으로하

기위한네트워크구조를제시한다.이를위해서각각의콘텐트에IP주소를동적으로할당하

고OpenFlow프로토콜을이용하여할당된IP를통해콘텐트요청(i.e.HTTPGET)및콘텐

트데이터가전송되도록한다.이러한방식을통해기존의IP를이용한전송방식을해치지않

Content Delivery over SDN: incremental vs. clean-slate approaches

권태경, 장덕현, 서준호서울대학교


54

OSIA S&TR JOURNAL


고route-by-name을에뮬레이션하는것이가능하다.

먼저하나의도메인내에서오리지널콘텐트서버로부터의콘텐트전송및캐쉬된콘텐트

전송이어떻게이루어지는가에대해설명하고,그후서로다른도메인사이의콘텐트전송이

어떻게이루어지는가에대해설명하도록한다.

2.1 도메인 내에서의 콘텐트 전송 그림1은제안된OpenFlow기반의구조에서콘텐트가어떻게전송되는지를보여준다.

Enduser1이콘텐트요청을위해HTTPGET메시지를자신의액세스노드R1에보내면(1)

R1은해당패킷에대한내용이자신의OpenFlowFlowTable에정의되어있지않으므로

OpenFlow프로토콜에의해이를자신의콘트롤러에전달한다(2).콘트롤러는해당패킷을

받은후HTTPGET메시지안의콘텐트이름을추출하고해당콘텐트가네트워크상에캐쉬

되어있는지를확인한다.이를위해콘트롤러는각각의콘텐트가네트워크상의캐쉬에저장

될경우콘텐트의이름과저장된노드의위치정보를가지는contentdistributionmetadata

table을유지한다.따라서해당콘텐트의캐쉬가존재한다면contentdistributionmetadata

table의검색을통해캐쉬된노드의위치를알수있다.본시나리오에서는해당콘텐트가네트

워크상에처음요청되었기때문에요청된콘텐트의캐쉬를발견하지못하고,DomainName

Server(DNS)를통해오리지널콘텐트서버(youtube.com)의위치를알아낸다.그후요

청된콘텐트의이름으로사용될IP주소(i.e.10.1.2.3)를콘텐트에할당하고이를content

metadatatable에저장한다.그리고OpenFlow노드인R1,R2,R3에할당된IP주소에대한

flowtableentry를생성함으로써enduser1과콘텐트서버사이의경로를생성한다(3).End

user1이보낸HTTPGET메시지는R1에서destination주소가10.1.2.3으로치환이되고,

R2를거쳐R3까지전달된다.여기서R3는콘텐트서버에메시지를전달하기전destination

주소를원래의destination주소인콘텐트서버의주소로치환한후콘텐트서버인youtube.

com에전달한다(4).HTTPGET메시지를받은콘텐트서버는요청에대한데이터를자신의

액세스노드R3에전송한다.R3는해단패킷의source주소를콘텐트에할당된IP인10.1.2.3

으로치환한후콘트롤러에의해세팅된경로를통해해당패킷을전달한다.따라서해당데이

터는R3,R2을거쳐R1에게까지전달이된다.여기서R1은source주소를다시콘텐트서버의

주소인youtube.com의주소로치환한후enduser1에게전달한다(5).이러한과정을통해

enduser와콘텐트서버에별도의수정없이route-by-name을에뮬레이션하여콘텐트를전

달할수있다.

이러한방식으로콘텐트의캐쉬및캐쉬된콘텐트의전송도가능하다.만약R2에해당콘텐

트가캐쉬되었다고가정하면,enduser2에서동일한콘텐트에대한요청이이루어졌을때캐

쉬된콘텐트를전송할수있다.Enduser2가HTTPGET메시지를자신의액세스노드인R2

에보낼경우R2는위의경우와마찬가지로자신의OpenFlowflowtable에서해당패킷에

대한entry를찾을수없으므로OpenFlow프로토콜에의해콘트롤러에이를전달한다.콘트

롤러는이번에는자신의contentmetadatatable을통해이미해당콘텐트에특정IP가할당

되었음을알고contentmetadatadistributiontable의검색을통해R2로부터캐쉬된콘텐트

(10.1.2.3)가전송되도록한다.따라서enduser2는R2로부터캐쉬된콘텐트를전송받는다

(8).

2.2 인터도메인 콘텐트 전송 본장에서는2-1에서설명한도메인내에서의콘텐트전송을기반으로하여서로다

른도메인사이의콘텐트전송을위한프레임워크를제시한다.이를위해본연구에서는

inter-controlleragent(ICA)를도입한다.ICA는다른SDN의controller와의통신및

inter-domain콘텐츠전송을위한기능을담당한다.구체적으로다른도메인의ICA와의

connectionsetup,그리고inter-domaincontentdistributionmetadata및도메인간콘텐

트전송을위한policy등을유지한다.

그림2는서로다른도메인사이의콘텐트전송이이루어지는과정을보여준다.해당시나리

오에서는하나의도메인(ISPA)에있는enduser가다른도메인(ISPB)에있는콘텐트서버

로부터콘텐트를전송받는다.각각의ISP의ICA사이에는이미connectionsetup이이루어

져있다고가정한다(e.g,SSL).


그림 1. 하나의 도메인 내에서의 콘텐트 전송

56

OSIA S&TR JOURNAL


먼저enduser가콘텐트요청을위해HTTPGET메시지를자신의액세스노드인A1로보

내면(1),A1은해당ISP내에서의콘텐트전송시나리오와마찬가지로자신의OpenFlow

flowtable을먼저확인하고해당패킷에대한entry가없으므로이를자신의콘트롤러에게전

달한다(2).콘트롤러는먼저자신의contentmetadata및contentdistributionmetadata를

확인하여해당콘텐트에대한요청을처리한적이있는지그리고도메인내에해당콘텐트의캐

쉬가있는지에대해확인한다.도메인내에서해당콘텐트가확인되지않으면자신의도메인의

ICA가유지하고있는inter-domaincontentdistributionmetadata를통해다른ISP내의콘

텐트를요청한다.여기서설명의편의를위해ICA사이의통신을통해inter-domaincontent

distributionmetadata항상최신의상태로유지되고있다고가정한다.즉,콘트롤러가ICA에

게특정콘텐트에대한정보를요청할때ICA는해당콘텐트가존재하는다른도메인을이미

알고있다고가정한다.여기서는ISPB가콘텐트를가지고있다고가정하므로ISPA의콘트롤

러는ICA를통해ISPB에콘텐트전송에대한요청을보낸다.콘텐트전송요청에는해당콘

텐트에대해ISPA에서할당한IP주소가포함된다.또한필요에따라QoS에대한요구사항이

포함될수있다(3).

CDNInterconnection(CDNI)metadata와같이inter-domaincontentdistribution에

는도메인사이의콘텐트전송에대한policy가미리설정되어있으므로요청을받은ISPB의

ICA는해당policy에따라콘텐트전송에대한가부를결정한다.본시나리오에서는ISPB가

콘텐트를제공하기로하였다고가정한다.따라서ISPB는ISP내에있는콘텐트의위치및네

트워크상황을체크하고ISPA에서콘텐트에할당한IP주소를기반으로자신도해당콘텐트

에IP주소를할당하고이를ISPA에게알린다(4).이경우할당된IP주소는2-1에서설명한

바와같이콘텐트의ID로사용된다.만약ISPA와동일한IP를사용할수없을경우다른IP주

소를사용하고이를ISPA에게알린다.ISPA는ISPB가보낸응답을체크한후이에대한확

인메시지를보낸다(5).

그후각각의ISP는자신내의OpenFlow노드의flowtableentry를추가함으로써end

user와콘텐트서버사이의경로를설정한다.만약ISPA와ISPB가동일한콘텐트에대해

서로다른IP를할당하였다면이를nodeA2와nodeB1에서이를치환할수있는action

을OpenFlow프로토콜을통해추가한다(6).경로가설정되고나면enduser가보낸HTTP

GET메시지의destination주소는노드A1에서해당콘텐트의ID로할당된IP주소로치환

된후노드A2,B1를거쳐노드B2까지전달된다.여기서노드B2는destination주소를다시

원래의주소인콘텐트서버의주소로치환한후콘텐트서버에전달한다(7).HTTPGET메시

지를받은콘텐트서버는콘텐트를노드B2에전송한다.노드B2는source주소를해당콘텐

트의ID로할당된IP주소로치환한후설정된경로를통해데이터를전송한다.데이터는노드

B1,A2를거쳐A1에게까지전달된다.여기서A1은source의주소를다시원래의주소인콘텐

트서버의주소로치환하여enduser에게전달한다(8).

만약요청되어전달되는콘텐트가노드A2에캐쉬될경우,2-1에서와마찬가지로캐쉬된

노드로의콘텐트요청전송및응답이가능하다.

3. 혁신적인 (Clean Slate) 접근방법

본장에서는기존의호스트중심의플로우콘트롤에서데이터중심의플로우콘트롤을하기

위한구조를제시한다.이를위해OpenFlow프로토콜확장및기존의commodity하드웨어

스위치에서지원해야할요구사항들에대해기술한다.

3.1 NDN 포워딩 이번섹션에서는오픈플로우프로토콜을지원하는네트워크상에서NDN네트워크를실현

하기위한방법을제시함에앞서,NDN네트워크의구성요소인NDN노드들이수행하는NDN

포워딩에대해알아볼필요가있다.이를통해NDN네트워크를실현하기위한각노드들의핵

심적인NDN포워딩기능들을도출할것이다.이렇게도출된기능들은다음과같다:(i)이름

기반의테이블룩업,(ii)인터레스트/데이터패킷프로세싱,(iii)네트워크내재캐슁지원.또한

이렇게도출된기능들과기존의오픈플로우스위치의포워딩기능들과차이점을살펴보고,오

픈플로우(오픈플로우프로토콜과오픈플로우스위치)확장시고려사항을도출할것이다.

3.1.1핵심적인NDN포워딩기능

그림3은NDN네트워크의구성하는NDN노드의구성요소에대해도식화한그림이다.

NDN노드는패킷을포워딩하기위해서세개의서로다른데이터구조를유지하고있다:(i)


그림 2. 인터도메인 콘텐트 전송

58

OSIA S&TR JOURNAL


ContentStore(CS),(ii)PendingInterestTable(PIT),(iii)ForwardingInformationBase

(FIB).이외에룩업을빠르게하기위한각데이터구조의인덱스테이블을유지한다.또한다

른NDN노드와연결하기위한여러인터페이스로구성되어있다.

이름기반의테이블룩업:NDN에서콘텐츠의이름은계층구조를갖는alphanumeric의

인간이읽을수있는형태를갖는다.한예로현재쓰이고있는URI를들수있는데,그형태는

cnn.com/us/a.avi/_v4/_s8와같다.그의미는해당이름을갖는콘텐츠(a.avi)는cnn에서

처음게시하였으며미국서버에서생성되었으며버전4의세그먼트8번을의미한다.

이런계층적이름구조를가정하는이유는같은이름접두사(nameprefix)를갖는이름들

을하나의동일한이름접두사(nameprefix)로줄일수있어FIB테이블의사이즈를획기적

으로줄일수있다.이렇게줄여진이름접두사(nameprefix)는추후에이름전부(fullname)

가인터레스트/데이터패킷에담겨서오면가장길게매칭이되는이름접두사를택하는것을

약속한다.이를longestprefixmatching(LPM)이라칭한다.하지만LPM은exactmatching

에비해복잡도가크다.그이유는fullname의nameprefix를미리알지못하기때문에테

이블에있는비슷한nameprefix를갖는엔트리를전부비교해야한다.현재까지고정길이

의IPv4/IPv6주소체계에대해LPM을위한많은연구가이뤄졌다.하지만이또한고정길이

(32비트IPv4/128비트IPv6)의현주소체계와비교해보았을때alphanumeric이고가변의

URI스타일의이름구조는LPM을적용하기가어렵다.

인터레스트/데이터 패킷 프로세싱:FIB는인테레스트패킷이NDN노드로들어왔을때요

청하는콘텐츠가존재하는방향으로가는길을알려주는역할을한다.이를위해FIB에는해

당되는콘텐츠의aggregation된nameprefix와다음노드(또는face정보)정보를갖고있

다.반면에PIT는FIB와는다르게데이터패킷이NDN노드로들어왔을때해당콘텐츠를요

청한노드로데이터패킷을전달하기위한정보를갖고있다.이를위해PIT에서는해당콘텐

츠이름(fullname)과들어온페이스번호를유지한다.NDN에서는이를breadcrumb이라

칭한다.지금까지NDN에서두노드간에네트워킹을위한중요한데이터구조2가지에대해살

펴보았다.지금부터CS테이블에대해알아보자.데이터패킷은전달과정중에미래의추가

적인요청을수행하기위해중간의NDN노드들에저장/캐슁될수있다.캐슁이된데이터패

킷은NDN노드의스토리지에저장이되고해당리스트를CS테이블에기록한다.

이제부터인터레스트패킷이전달되는과정에대해알아보자.인터레스트패킷이NDN노

드에들어와서CS에매칭이될수있다.이는해당NDN노드에콘텐츠가이미존재(캐슁)한

다는의미이므로더이상인터레스트패킷을다음노드로전달하지않고자신이갖고있는데

이터를돌려준다.만약인터레스트패킷이PIT에매칭이되면이는이미이전에같은콘텐츠

요청이있었다는이야기이므로해당패킷을더이상다음노드로전달하지않고기존의PIT

엔트리에새로운정보(해당리퀘스트가들어온인터페이스)를추가한다.CS또는PIT에매칭

이안됐을경우새로운리퀘스트로간주하고매칭된FIB엔트리에담긴정보를이용하여다음

노드로전달한다.

이제부터데이터패킷이전달되는과정에대해알아보자.인터레스트패킷이전달되는과

정에비해데이터패킷전달은간단하다.데이터패킷이NDN노드로들어오면인터레스트패

킷과마찬가지로CS와PIT테이블을룩업한다.한가지다른점은데이터패킷은FIB테이블을

룩업하지않는다.CS에매칭이되면해당데이터는이미NDN노드의스토리지안에캐슁이

되어있으므로전달하지않는다.PIT에매칭이되면해당콘텐츠데이터에대해요청이있다는

의미이므로PIT엔트리의정보를이용하여요청한노드쪽으로데이터를전달한다.

네트워크 내재 캐슁:NDN에서캐쉬를함으로써많은이득을볼수있는데네트워크트래

픽절감효과와delay를줄일수있다.

NDN노드의캐쉬스토리지가꽉찾을경우새로운데이터를캐쉬하기위해서는기존에존

재하는데이터중하나또는여러개를골라교체해주어야하는데주로LRU또는LFU를많이

쓴다.

3.1.2오픈플로우와의차이점및확장시고려사항

위섹션에서알아본세가지의핵심적인NDN포워딩기능을지원하기위해오픈플로우를

확장하는건쉬운일이아니다.그이유는오픈플로우포워딩을위한데이터구조와NDN포워

딩을위한데이터구조가근본적으로다르기때문이다.따라서이번절에서는그차이를살피고

오픈플로우확장시고려할사항에대해알아본다.

가변적 name 성질을 고려한 오픈플로우 확장:현오픈플로우버전1.0은12개의튜플을


그림 3. NDN Forwarding Engine

60

OSIA S&TR JOURNAL


사용해서플로우를구별한다.또한각튜플은고정적인크기를갖는다.하지만앞서언급했듯

이NDN네트워크주소체계는가변적이고alphanumeric한name기반이다.13번째튜플로

NDN의name을추가하기위해서는2가지를반드시고려해야한다:(i)가변적인name을담

기위한고정적인튜플,(ii)오픈플로우에서제공하는와일드카드메커니즘과nameprefix를

LPM하기위한메커니즘과의호환성.따라서우리는다음장에서이두가지고려사항을해결하

기위한새로운방법을고안할것이다.

플로우 테이블과 NDN의 세 데이터구조의 차이:오픈플로우버전1.1의multipletables기

능을이용하면NDN포워딩엔진의세데이터구조를쉽게확장할수있다.하지만아직까지버

전1.1을구현할스위치가만들어지지않아우리는singletable인버전1.0을이용해확장할

수밖에없다.또한multipletables기능을이용해확장을한다고하더라도이를NDN전용데

이터구조로이용하게되면메모리를비효율적으로사용하게되고,오픈플로우의플로우의개

념에위배된다.따라서우리는앞서언급한인터레스트/데이터패킷프로세싱을오픈플로우

액션으로추상화하는방법에대해설명할것이다.

오픈플로우 스위치/라우터에서의 네트워크 내재 캐쉬 지원:네트워크내재캐쉬는NDN네

트워크만의독특한특징이다.따라서현재상용화된스위치/라우터에는네트워크내재캐슁

기능이존재하지않는다.또한상용스위치/라우터에는패킷버퍼링을위해보통용량은작지

만(몇킬로바이트)엑세스속도가빠른메모리(SRAM/0.45ns,DRAM/55ns)를탑재하고있

다.하지만NDN네트워크에서는데이터캐슁을위해이보다더많은메모리(몇기가바이트)

를요구한다.하지만보통용량이큰메모리는엑세스속도가느리기때문에highspeed스위

치/라우터상황에서는적합하지않을수있다.따라서다음절에서이를고려한방법을고아할

것이다.

3.2 ND-Flow

3.2.1FIELDANDMATCHINGEXTENSION

오픈플로우스위치로하여금컨텐츠이름을인식하게하기위해선기존의12개튜플의플

로우필드를확장할필요가있다.따라서우리는위그림과같이NDN을위한이름필드와패

킷타입필드를새롭게추가하였다.

또한위에서언급하였듯이기존의고정적인필드들에반해NDN에서의이름은가변적이어

서많은문제점을야기하였다.따라서가변적길이의이름을고정적길이의라벨로변환할필

요가있다.이를위해ND-Flow에서는해슁기법을이용한다.

PIT는exactmatching을요구하고,FIB및CS는wildcardmatching을요구한다.이를

위해PIT는패킷의전체이름에대한해슁을한뒤해당된해슁값을이용하여exactmatching

을한다.

3.2.2NewActionsforPacketProcessing

NDN의세가지데이터스트럭처를오픈플로우상에서구현하기위해새로운데이터스트

럭처를정의하지않고,각각의데이터스트럭처를오픈플로우의액션으로추상화하였다.이를

위해NDN을위한다섯가지새로운액션을추가하였다:CSActionforInterest,CSAction

forData,PITActionforInterest,PITActionforData,FIBActionforInterest.각각의액

션들의오퍼레이션은아래수도코드에도식화되어있다.


그림 4. OpenFlow에서 NDN 지원을 위한 ND-Flow 구조

62

OSIA S&TR JOURNAL


또한새로운액션들은기존오픈플로우에존재하는아토믹한액션(그림에서의파란글씨)들

로정의하였다.이렇게함으로써확장성및이식성을높일수있다.

3.2.3In-networkCachingSupportwithTwo-levelMemoryHierarchy

기존의스위치들은적은용량의빠른메모리를버퍼로제공한다.하지만NDN만의새로운

기능인캐슁으로인해더많은용량의메모리를요구한다.이를위해우리는스위치의시스템

메모리를활용한다.

하지만시스템메모리는용량이큰반면속도가현저히느리기때문에고속으로들어오는

컨텐츠요구량을처리하지못한다.따라서우리는스위치의각라인카드에있는고속의메모리

도이용한다.따라서현재CPU설계처럼Two-levelMemoryHierarchy로설계하였다.

3.2.4Routingpopulation

중앙콘트롤러는그가관장하고있는네트워크의스위치토폴로지뿐만아니라각엔드호스

트(publisher)가공개하고있는name-prefix정보를갖는다.이를이용하여shortest-path

알고리즘을이용하여각name-prefix로향하는모든루트를계산한뒤해당루트들을스위치

의플로우테이블에삽입한다.

4. 결론 및 토의 이상으로OpenFlow/SDN기술을사용하여어떻게콘텐트를효율적으로전송할수있을

지관련된두가지접근방법을살펴보았다.콘텐트전송이외에도이동성지원,멀티캐스팅,

DDoS관련수비기법등을OpenFlow/SDN기술을통해서쉽게구현가능할것으로전망된다.

향후관련분야에서원천기술을확보하기위해산학연이같이노력해야할것으로생각된다.

참고문헌[1] A. Ghodsi, S. Shenker, T. Koponen, A. Singla, B. Raghavan, and J. Wilcox. Information-

centric networking: seeing the forest for the trees. In ACM Workshop on HotNets ‘11.[2] L. Muscariello, G. Carofiglio, and M. Gallo. Bandwidth and storage sharing performance

in information centric networking. In ACM SIGCOMM Workshop on ICN ‘11.[3] Teemu Koponen, Mohit Chawla, Byung-Gon Chun, Andrey Ermolinskiy, Kye

Hyun Kim, Scott Shenker, and Ion Stoica, “A Data-Oriented (and Beyond) Network Architecture” , In Proceedings of SIGCOMM 2007

[4] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, and R. L. Braynard. “Networking named content,” In Proceedings of ACM CoNEXT, 2009.

[5] V. Jacobson, D. K. Smetters, N. H. Briggs, M. F. Plass, P. Stewart, J. D. Thornton, R. L. Braynard, VoCCN: Voice Over Content-Centric Networks, ReArch ’09, Rome, December, 2009.

[6] D. k. smetters and v. jacobson. “Securing network content”, october 2009. parc technical report. http://www.parc.com/content/attachments/securingnetwork-content-tr.pdf.

[7] Dimitrov, V. and Koptchev, V. PSIRP project – publish-subscribe internet routing paradigm: new ideas for future internet. Printed in a separate ACM DL issue in the “ACM International Conference Proceeding Series (ICPS)”, Vol. 471 (ISBN 978-1-4503-0243-2), Pages: 167-171.

[8] B. Ahlgren, M. D’Ambrosio, C. Dannewitz, A. Eriksson, J. Golic, B. Gronvall, D. Horne, A. Lindgren, O. Mammela, M. Marchisio, J. Makela, S. Nechifor, B. Ohlman, K. Pentikousis, S. Randriamasy, T. Rautio, E. Renault, P. Seittenranta, O. Strandberg, B. Tarnauca, V. Vercellone, and D. Zeghlache, \Second netinf architecture description,” 4WARD EU FP7 Project, Deliverable D-6.2 v2.0, Apr. 2010, fP7-ICT-2007-1-216041-4WARD / D-6.2, http://www.4ward-project.eu/.

[9] Kate Greene (March/April 2009). “TR10: Software-Defined Networking”. Technology Review (MIT). Retrieved November 20, 2011.

[10] B. Lantz, B. Heller, and N. McKeown. A network in a laptop: rapid prototyping for software-defined networks. In ACM Workshop on HotNets ‘10.

[11] Google and facebook support openflow standards. http://www.webestigate.com/2011/04/15/googleand-facebook-support-openflow-standards/.

[12] Openflow switch specification, version 1.1. http://www.openflow.org/documents/openflowspec-v1.1.0.pdf.

[13] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner. Openflow: enabling innovation in campus networks. SIGCOMM Comput. Commun. Rev., 38(2):69–74, Mar. 2008.

[14] M. Baugher, B. Davie, A. Narayanan, and D. Oran. Self-verifying names for read-only named data. In INFOCOM Workshops on NOMEN ‘12, 2012.

[15] K. Cho, H. Jung, M. Lee, D. Ko, T. T. Kwon, and Y. Choi. How can an isp merge with a cdn? IEEE Communications Magazine, 49(10):156–162, 2011.

[16] K. Cho, M. Lee, K. Park, T. T. Kwon, Y. Choi, and S. Pack. Wave: Popularity-based and collaborative in-network caching for content-oriented networks. In INFOCOM Workshops on NOMEN ‘12, 2012.

[17] A. R. Curtis, J. C. Mogul, J. Tourrilhes, P. Yalagandula, P. Sharma, and S. Banerjee.


64

OSIA S&TR JOURNAL


Devoflow: scaling flow management for high-performance networks. In ACM SIGCOMM ‘11.

[18] S. Podlipnig and L. Böszörmenyi. A survey of web cache replacement strategies. ACM Comput. Surv., 35(4):374–398, Dec. 2003.

[19] M. . Ruiz-sÃ , anchez, I. S. Antipolis, E. W. Biersack, S. Antipolis, W. Dabbous, and I. S. Antipolis. Survey and taxonomy of ip address lookup algorithms. IEEE Network, 15:8–23, 2001.

저자 소개

권 태 경-1993:서울대학교컴퓨터공학학사

-1995:서울대학교컴퓨터공학석사

-2000:서울대학교컴퓨터공학박사

-1998:IBM왓슨연구소방문연구원

-1999:Universityof NorthTexas방문연구원

-2000~2002:UCLA박사후연구원

-2002~2003:CityUniversityNewYorkPrincipalEngineer

-2003~2004:CityUniversityNewYork박사후연구원

-2004~2008:서울대학교전기컴퓨터공학부조교수

-2008~현재:서울대학교전기컴퓨터공학부부교수

-관심분야:미래인터넷,무선네트워크,Mobile/ubiquitouscomputing

장 덕 현-2004:서울대학교컴퓨터공학학사

-2004~현재:서울대학교컴퓨터공학석박통합과정

-관심분야:미래인터넷,센서네트워크,Softwaredefinednetworking

(SDN)

서 준 호 -2008:한국정보통신대학교(ICU,현KAIST)학사

-2008~현재:서울대학교컴퓨터공학석박통합과정

-관심분야:Contentcentricnetworking(CCN),Software


Documents

Content Delivery over SDN: incremental vs. clean-slate ... · 데이터는 노드 B1, A2를 거쳐 A1에게까지 전달된다. 여기서 A1은 source의 주소를 다시 원래의