[펌]SDN(Software-Defined Networking) : 과거, 현재, 미래의 프로그래머블 네트워크

퓨터 과학자들은 네트워크의 속도와 안정성, 에너지 효율, 보안 등을 획기적으로 개선시킬 수 있는 방법을 계속해서 찾아왔다. 그러나 새로운 방법을 설계하거나 제안하더라도 인터넷의 코어를 구성하고 있는 라우터나 스위치들이 완전히 닫혀져 있기 때문에 이 장치들 위에서 새로운 프로그램을 실험하는 것이 원천적으로 봉쇄되어 있었다. 

또한 네트워크 콴리도 일부 운영자나 엔지니어에게 종속되어 있고 그마저도 사용하기가 쉽지 않았다. 이런 네트워크 구조의 한계성을 극복하고 새로운 요구 사항들을 수용하기 위해서 기존 네트워크 구조에 혁신적인 개념을 도입하여 등장한 것이 SDN(Software-Defined Network)이다. 이 글에서는 SDN의 기본적인 개념과 기존의 프로그래머블 네트워크, 그리고 SDN의 구조를 살펴본다.

 

글 : 이상호 / 광주과학기술원 정보통신공학과
자료 협약 및 제공 : KOSEN(한민족과학기술자 네트워크) / www.kosen21.org

개요

컴퓨터 네트워크는 일반적으로 수많은 네트워크 장비들로 구성된다. 이 장비들에는 라우터, 스위치와 같이 패킷을 전송하는 것을 목적으로 하는 것이 있는가 하면 방화벽(firewall)과 같이 패킷 전송과는 다른 목적을 위한 장비들도 있다.

네트워크 운영자는 다양한 범위의 네트워크 이벤트나 응용 프로그램의 요청을 처리해야 하기 때문에 관련 정책을 수립하고 적용해야 하는 책임을 가지고 있다. 네트워크 환경이 변하는 경우, 상황에 따라 네트워크 운영자는 상위 레벨의 정책을 하위 레벨의 환경 설정 명령으로 변환시켜주는 작업도 수동으로 해주어야 한다. 

종종 네트워크 운영자는 상당히 제한된 도구를 사용해서 이런 종류의 복잡한 작업을 수행해야 하는 경우도 있다. 그래서 네트워크 관리(network man-agement) 와 성능 조율(performance tuning)은 상당히 힘든 일이고 에러가 많이 발생할 수 있는 여지가 있다. 그리고 네트워크 장비들이 일반적으로 수직 통합형의 블랙박스이기 때문에 이 점 역시도 네트워크 운영자나 관리자가 직면하는 문제들을 더욱 악화시킨다.

네트워크 운영자나 관리자가 극복하기 어려운 문제 중 하나는 “Internet Ossification”이다. 현재 인터넷이 전 세계적으로 사용되고 있고, 사회적으로 굉장히 중요한 사회 기반 시설이기 때문에 물리적인 하부구조, 프로토콜 등의 관점에서 인터넷을 개선시키는 것은 상당히 어려운 일이다. 그런데 현재의 인터넷 응용 프로그램들 그리고 개발되고 있는 응용 프로그램들이 상당히 복잡하고 어려운 기능들을 요구하기 때문에 이런 부분들을 해결하기 위해서는 인터넷이 개선되어야만 하는 상황이다.

네트워크를 개선시키는 것을 용이하게 하기 위해서 “프로그래머블 네트워크(program-mable network)”라는 개념이 제안되었다. 특히, software-defined network는 새로운 네트워크 패러다임으로서, 네트워크 장비를 중앙에서 제어할 수 있어 프로그램을 짜듯이 네트워크를 자유롭게 제어하고 관리할 수 있다. 이는 네트워크 관리를 용이하게 하고 네트워크의 개선과 진보를 가능하게 해줄 수 있다. 

주요 아이디어는 소프트웨어 개발자가 스토리지나 컴퓨팅 자원을 다루는 것과 같이 손쉬운 방법으로 네트워크 자원을 다룰 수 있도록 해주는 것이다. SDN에서는 소프트웨어 기반의 컨트롤 기능들이 중앙에 집중되어 있고, 네트워크 장비는 단순하게 패킷을 전송하는 장비로서 오픈 인터페이스(ex. ForCES[2], OpenFlow[3])를 통해서 프로그램의 변경이 가능하다.

현재 SDN은 학계와 산업계에서 큰 관심을 받고 있다. 네트워크 운영자, 서비스 제공자, 제조업체들은 최근 Open Network Founda-tion[4]을 설립하였는데, 이는 산업계가 주도하는 조직으로서 SDN을 개선하고 OpenFlow 프로토콜을 표준화하는 것을 목표로 한다. 학계에서는 OpenFlow Network Research Center[5]를 설립해서 SDN을 연구하고 있다. IETF, IRTF 등과 같은 표준 제정 기관들은 표준화에 힘쓰고 있다.

Software defined networking 분야는 상당히 최근에 제안되었고, 굉장히 빠른 속도록 성장하고 있다. 그러나 해결해야 할 중요한 문제들이 많이 있는 상황이다. 이 분석물에서는 프로그래머블 네트워크에 대한 그동안의 히스토리를 살펴보고, 현재 진행되고 있는 부분도 살펴볼 것이다.

이전의 프로그래머블 네트워크

SDN은 네트워크가 동작하는 방식을 변화시킬 수 있는 엄청난 잠재력을 가지고 있다. 특히 OpenFlow는 네트워킹에 있어서 근본적으로 새로운 아이디어로서 큰 관심을 받고 있다[6]. 얻을 수 있는 이득은 중앙 집중식 제어, 단순한 알고리즘, 상품화하기 쉬운 네트워크 하드웨어, 서드파티 앱(third-party app)의 설계 및 디자인 가능 등이 있다.

▲ 그림 1. Software-Defined Network의 구조

OpenFlow가 산업계에서 엄청난 관심을 받고 있지만, 프로그래머블 네트워크와 비연계 제어 로직(logic)이라는 아이디어는 수년간 지속적으로 제안되어왔다. 이 장에서는 현재 SDN 패러다임의 수많은 아이디어들의 근간이 된 초기 프로그래머블 네트워크에 대해서 살펴보고자 한다.

1. Open Signaling

Open Signaling(OPENSIG) working group은 “making ATM, Internet and mobile networks more open, extensible, and programmable”[7]이라는 목표를 가지고 일련의 워크숍과 함께 1995년에 시작되었다. 현실화하기가 상당히 어려운 일이기는 하지만, 통신 하드웨어와 제어 소프트웨어를 분리하는 것이 필수적이라고 믿었다. 이 제안의 핵심은 오픈된 프로그래머블 네트워크 인터페이스를 통해서 네트워크 하드웨어에 대한 접속을 허용하여 분산 프로그램 환경을 통한 새로운 서비스를 적용하는 것이 가능하도록 하는 것이다.


2. Active Networking

1990년대 중반에 Active Networking[9], [10]은 프로그래밍이 가능한 네트워크 하부구조를 제안하였다. 이 제안에서는 두 가지 방식이 고려되었다. 첫째는, 사용자가 프로그래밍을 할 수 있는 스위치이고, 둘째는 라우터에서 실행될 수 있는 프로그램이다. Active Networking이 산업계에서 폭넓게 사용되지는 못했는데, 그 이유는 보안과 성능의 문제 때문이다.

3. Devolved Control of ATM Networks (DCAN)

1990년대 중반에 생긴 또 다른 프로젝트는 Devolved Control of ATM Networks(DCAN) [11]이다. 이 프로젝트의 목적은 ATM 네트워크의 확장성을 위한 제어와 관리에 필요한 하부구조를 개발하는 것이다. 전제는 ATM 스위치 장비의 제어 및 관리 기능이 장비 자체에서 분리되어야 하고 외부 개체에 위임되어야 한다는 것이다. 이것이 SDN이 가지고 있는 기본적인 개념이라고 볼 수 있다.

4. 4D 프로젝트

2004년을 시작으로 하여, 4D 프로젝트는 네트워크 요소들 사이의 상호작용을 결정하는 라우팅 결정 로직과 프로토콜을 분리하는 것을 강조하였다. 4D 프로젝트에서는 4가지 차원(plane)을 지지하였다. 4가지 차원에는 패킷 처리를 위한 데이터 차원, 토폴로지와 트래픽 측정값들을 모으기 위한 발견(discovery) 차원, 패킷 처리 규칙 설치를 위한 배포(dissemina-tion) 차원, 네트워크 레벨의 목표를 패킷 처리 상태로 변환시키는 컨트롤러로 구성된 결정(decision) 차원이 있다.

5. NETCONF

2006년에 IETF Network Configuration Working Group은 네트워크 장비의 설정을 수정할 수 있도록 하기 위한 관리 프로토콜로서 NETCONF를 제안하였다. 프로토콜은 네트워크 장비가 API를 노출하는 것을 허용하였고, 이 API를 통해서 설정 데이터를 검색하거나 전송할 수 있게 된다.

과거에 활발하게 사용이 되었고, 현재도 사용되고 있는 또 다른 관리 프로토콜은 SNMP[12]이다. SNMP는 1980년대 후반에 제안되었고, Management Information Base(MIB)에 저장되어 있는 데이터를 실행하기 위해서 Structured Management Interface(SMI)를 사용한다. 설정을 수정하기 위해서 MIB에 있는 변수를 변경하는 데에도 사용이 가능하다. 그런데 SNMP는 처음 의도했던 것과는 달리 네트워크 장비를 설정하는 데 사용하기보다는 장비 성능을 모니터링하는 용도로 사용되었다. 또한 보안이 취약하다는 약점도 가지고 있다.

NETCONF의 경우 제안된 시점에서는 SNMP의 단점을 보완할 수 있는 네트워크 관리의 새로운 접근법으로 여겨졌다. NETCONF가 장비 설정을 손쉽게 할 수 있다는 장점은 있지만, 데이터와 관리 차원을 분리하지 않았다는 단점도 있다. 물론 SNMP의 경우도 마찬가지이다. NETCONF는 새로운 기능을 네트워크 장비와 관리 장비 모두에 설치해야 하기 때문에 NETCONF를 적용한 네트워크를 완전히 프로그래머블하다고 말하기는 어렵다.

6. Ethane

OpenFlow OpenFlow OpenFlow OpenFlow에 바로 앞서 서 2006200620062006년에 SANE/SANE/SANE/ SANE/Ethane 프로젝트[13]가 수행되었다. 이 프로젝트에서는 기업 네트워크를 위한 새로운 구조를 제안하였다. 이 프로젝트의 목표는 중앙에 있는 컨트롤러(controller)가 네트워크의 정책과 보안을 관리하게 하는 것이다. SDN과 유사하게 Ethane은 두 가지 요소(controller, Ethane switch)를 사용한다. 컨트롤러는 패킷을 전송해야 할지 말지를 결정하고, Ethane 스위치는 컨트롤러를 향한 흐름표(flow table)와 보안 채널로 구성되어 있다. Ethane은 Software-Defined Networking의 기반을 마련하였다.

Software Defined Networking 의 구조

데이터 통신 네트워크는 일반적으로 네트워크 하부구조에 연결되어 있는 최종 사용자 장비 또는 호스트(host)로 구성되어 있다. 이 하부구조는 호스트에 의해서 공유가 되고 호스트 사이에서 데이터를 전송하기 위해서 통신 링크와 라우터, 스위치 같은 스위칭 장비를 사용한다. 

라우터나 스위치는 일반적으로 닫힌 시스템이고, 종종 제조 업체만의 특징적인 제어 인터페이스를 가진다. 그래서 이런 장비들은 한 번 설치가 되고 나면 현재의 네트워크 하부구조를 개선하는 것이 너무나도 어렵다. 다시 말하면, 완전히 새로운 프로토콜이나 서비스를 말할 것도 없고, 기존 프로토콜의 새 버전을 설치하려고 해도 현재의 네트워크에서는 넘기 힘든 큰 장애물이라고 볼 수 있다. 네트워크의 네트워크라고 할 수 있는 인터넷도 예외는 아니다.

앞에서 언급된 것처럼, 일명 “Internet Ossification”[3]은 데이터 차원과 제어 차원을 밀접하게 결합시키는 데 큰 역할을 한다. 이는 네트워크에서의 데이터 흐름을 결정하는 것이 각각의 네트워크 개체에서 이루어지는 것을 의미한다. 이런 환경에서는 새로운 네트워크 응용 프로그램 또는 기능을 추가하려고 하는 경우 하부구조에 직접적으로 적용이 되어야 한다. 

다양한 네트워크 장비에 대한 공통된 제어 인터페이스가 부족하기 때문에 설정이나 정책 적용과 같은 간단한 작업도 상당히 많은 노력이 들어가게 될 수 있다. 그 대신에 방화벽과 같은 미들 장비(middlebox)를 사용하는 것이 network ossification 효과를 피해갈 수 있는 방법이다. Content Delivery Networks(CDNs)[14]는 좋은 예가 될 수 있다.

▲ 그림 2. OpenFlow 프로토콜에서의 컨트롤러와 전송장비 사이의 통신

Software-Defined Networking은 네트워크의 개선을 용이하게 하고 네트워크 데이터 경로를 간단한 프로그램으로 제어하기 위해서 개발되었다. 그림 1에서 보는 것처럼, 제어 로직에서 전송 장비를 분리함으로써 새로운 프로토콜이나 응용 프로그램을 보다 쉽게 설치할 수 있고 관리 역시 용이하게 할 수 있으며 다양한 미들 장비를 소프트웨어 제어에 통합시킬 수 있다. 그러면 네트워크는 결정을 내릴 수 있는 네트워크 컨트롤러와 단순한 전송 장비로 구성된다고 볼 수 있다.

1. 현재의 SDN 구조

SDN 구조로 잘 알려진 것으로는 ForCES [2]와 Openflow[3] 가 있다. ForCES와 Openflow는 제어 차원과 데이터 차원을 분리한다는 SDN의 기본적인 원칙을 따르고 있고, 두 차원 사이에서의 정보 교환을 표준화하고 있다. 그러나 두 SDN 구조는 설계, 전송 모델, 프로토콜 인터페이스 측면에서 기술적으로 상당히 다르다.

◆ForCES 
IETF ForCES(Forwarding and Control Element Separation) working group에서 제안한 접근법은 제어 개체와 전송 개체가 분리되도록 네트워크 장비의 내부 구조를 재정의하는 것이다. 그러나 네트워크 장비는 여전히 하나의 개체로서 다루어진다. Working group이 고려하고 있는 것은 하나의 네트워크 장비 내에서 제3의 제어 개체를 새로운 전송 하드웨어와 결합시키는 것이다. 그래서 제어 차원과 데이터 차원이 가깝게 유지가 될 수 있다. 그에 반해서 OpenFlow 같은 SDN 시스템에서는 제어 차원이 네트워크 장비에서 완전히 분리되어 있다.
ForCES 는 전송 개체(Forwarding Element, FE)와 제어 개체(Control Element, CE)라고 불리는 두 개의 로직 개체를 정의한다. 전송 개체는 패킷 단위의 작업을 처리하기 위해서 하드웨어를 사용하는 것에 대한 책임을 가지고 있고, 제어 개체는 제어 및 신호 처리 함수를 실행하고 ForCES 프로토콜이 전송 개체로 하여금 어떻게 패킷을 처리할지에 대해 지도를 한다. 프로토콜은 master-slave 모델을 기반으로 동작하는 데 전송 개체가 slave가 되고 제어 개체가 master가 된다.

◆OpenFlow 
OpenFlow는 제어 차원과 데이터 전송 차원을 분리하고자 하는 SDN의 원칙에 의해서 제안되었고, 두 차원 사이에서의 정보 교환에 관해서 표준화하였다. 그림 2에서 보이는 것처럼 OpenFlow 구조에서는 OpenFlow 스위치와 같은 전송 장비가 하나 이상의 flow table과 추상 계층을 가지고 있어서 OpenFlow 프로토콜을 통하여 컨트롤러와 안전하게 통신할 수 있다. Flow table은 flow entry로 구성되어 있고, 각각은 전송해야 할 패킷을 어떻게 가공하여 전송할지에 대해서 결정한다. Flow entry는 전형적으로 match field, counter, a set of instructions로 구성되어 있다. Match field는 매칭시키는 룰로서, 수신한 패킷의 매칭을 위해 사용된다. Match field는 패킷 헤더에서 보이는 정보를 가지고 있다. Counter는 수신한 패킷의 수와 같은 특정한 흐름에 대한 통계를 얻기 위해서 사용된다. A set of instructions는 매칭이 된 패킷을 어떻게 다룰 것인가를 알려준다.


2. 전송 장비

네트워크 하부구조는 라우터, 스위치, 가상 스위치, 무선 엑세스 포인트와 같은 서로 다른 물리적인 네트워크 장비들로 구성되어 있다. Software-defined network에서는 제어 로직과 알고리즘을 컨트롤러에 올리거나 제거할 수 있기 때문에 이러한 종류의 장비들이 추상 계층에서 오픈 인터페이스를 통해서 연결이 가능한 것으로 여겨진다. SDN에서는 이런 종류의 전송 장비를 단순히 스위치로 표현한다(그림 3).

OpenFlow 네트워크에서 스위치는 Pure 스위치와 하이브리드 스위치 두 가지 형태가 있다. Pure OpenFlow 스위치는 기존의 전통적인 방식을 따르지 않고 데이터 전송에 대한 결정을 온전히 컨트롤러에서 한다. 하이브리드 스위치는 전통적인 프로토콜과 OpenFlow를 지원한다. 현재 사용되고 있는 대부분의 상업 스위치는 하이브리드 형태이다.

▲ 그림 3. 네트워크 오퍼레이팅 시스템으로서 분리된 제어 로직

3. 컨트롤러

그림 3에서 보는 것처럼, SDN 모델에서는 제어가 중앙에서 이루어지고 응용 프로그램은 네트워크가 하나의 시스템인 것처럼 생각하고 동작한다. 이런 방식으로 인해서 SDN 모델은 다양한 범위의 응용 프로그램 및 네트워크 기술에 적용이 가능하다. 그림 4는 OpenFlow 프로토콜을 기반으로 한 SDN 컨트롤러의 구조를 보여준다.


4. Southbound 통신 (컨트롤러-스위치)

SDN 의 중요한 특징 중 하나는 데이터 차원과 제어 차원 사이의 연결이다. OpenFlow 프로토콜은 스위칭 하드웨어와 네트워크 컨트롤러 사이의 통신을 정의하고 있는데, 이는 컨트롤러와 스위치 사이의 상호작용에 대한 구현의 한 방식이 될 수 있다. 보안을 위해서 OpenFlow 1.3.0 은 스위치와 컨트롤러 사이에서 암호화된 전송 계층 보안 (Transport Layer Security, TLS) 통신과 인증을 기반으로 한 데이터 교환을 위한 추가적인 지원을 하고 있다.


5. Northbound 통신 (컨트롤러-서비스)

외부 관리 시스템 또는 네트워크 서비스는 네트워크에 관련된 정보를 추출하거나 네트워크 정책을 제어하고 싶을 수 있다. 또는 컨트롤러들이 서로 간에 통신을 해야 할 필요가 있을 수도 있다. 컨트롤러와 스위치의 통신과는 달리 현재 northbound interaction 에 대한 표준은 정해지지 않았다.


6. 표준화 노력

최근 SDN 과 관련하여 여러 표준화 조직들이 관심을 받고 있다. 예를 들어서 IETF’s Forwarding and Control Element Separation (ForCES) Working Group 은 표준화 매커니즘, 인터페이스, 프로토콜에 관해서 표준화를 진행하고 있다. Open Network Foundation (ONF) 은 OpenFlow 프로토콜을 표준화하려고 노력하고 있다.

SDN 개발 툴

SDN은 새로운 서비스와 프로토콜을 빠르게 개발할 수 있게 함으로써 네트워크의 개선 및 발전을 용이하게 하기 위해 제안되었다. SDN 기반의 서비스와 프로토콜을 개발하기 위한 다양한 툴과 환경이 있다. Mininet 은 모든 OpenFlow 네트워크가 하나의 머신 (machine) 에서 모방 (emulation) 할 수 있도록 해준다. ns-3 네트워크 시뮬레이터는 OpenFlow 스위치를 지원한다. 

소프트웨어 스위치 플랫폼으로는 Open vSwitch, Pantou/Open WRT, ofsoftswitch13, Indigo 등이 있고, SDN 스위치로는 Hewlett-Packard 의 8200zl, IBM 의 RackSwitch G8264, Juniper 의 Junos MX-series 등이 있다. 컨트롤러 플랫폼으로는 Nicira 의 POX, Kulcloud 의 MUL, Rice University 의 Maestro, NEC 의 Trema, Stanford 의 Beacon 등이 있다. 코드 검증 및 디버깅 툴로는 NICE, Anteater, VeriFlow, OFRewind, STS 등이 있다.

SDN 의 적용

SDN 은 네트워크 환경에서 다양하게 적용이 될 수 있다. 제어 차원과 데이터 차원을 분리함으로써 프로그래머블 네트워크는 개별적인 요구에 맞게 제어를 할 수 있고, 미들박스를 제거할 수 있으며 손쉽게 새로운 네트워크 서비스 및 프로토콜을 설치할 수 있게 된다. SDN 의 이런 장점들을 기반으로 하여 SDN 은 다양한 분야에 적용이 가능한데 예를 들면 엔터프라이즈 (Enterprise) 네트워크, 데이터 센터, 하부구조 기반의 무선 접속 네트워크, 광통신 네트워크, 중소기업 등이 있다.

해결해야 할 문제점 및 장래 방향

SDN 이 광범위하게 적용되기 시작함에 따라 새롭게 해결해야 할 문제들이 생겨나고 이로 인해서 SDN 이 나아가야 할 방향들도 파악이 되고 있다. SDN 이 장차 연구해야 할 방향들은 다음과 같다. (1) 컨트롤러 및 스위치 설계, (2) SDN 의 확장성 및 성능, (3) 컨트롤러-서비스 인터페이스, (4) 가상화 및 클라우드 서비스, (5) 정보 중심 네트워킹, (6) SDN 활용 이종 네트워킹

결론

이 분석물에서는 Software-Defined Network의 기본적인 개념과 기존의 프로그래머블 네트워크, 그리고 현재 가장 잘 알려진 Software-Defined Network의 구조, 즉 ForCES와 OpenFlow에 대해서 살펴보았다. SDN은 기술 발표 이후 빠르게 성장하고 있고, 2012년 초부터 Google은 데이터센터에 OpenFlow를 도입하기 시작하였다. 최근 몇 년 사이에 SDN이 많이 활성화되고 있는 것을 볼 때 SDN에 관심을 가지고 지속적으로 연구할 필요가 있을 것으로 예상된다.

 

 

References

1. Bruno Astuto A. Nunes, Marc Mendonca, Xuan-Nam Nguyen, Katia Obraczka, and Thierry Turletti. A Survey of Software-Defined Networking: Past, Present, and Future of Programmable Networks. IEEE COMMUNICATIONS SURVEYS & TUTORIALS, 2014.
2. A. Doria, J. Hadi Salim, R. Haas, H. Khosravi, W. Wang, L. Dong, R. Gopal, and J. Halpern. Forwarding and Control Element Separation (ForCES) Protocol Specification. RFC 5810 (Proposed Standard), March 2010.
3. N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner. Openflow: enabling innovation in campus networks. ACM SIGCOMM Computer Commun. Review, 38(2):69–74, 2008.
4. Open networking foundation. https://www.opennetworking.org/about.
5. Open Networking Research Center (ONRC). http://onrc.net.
6. Thomas A. Limoncelli. Openflow: a radical new idea in networking. Commun. ACM, 55(8):42–47, August 2012.
7. A.T. Campbell, I. Katzela, K. Miki, and J. Vicente. Open signaling for atm, internet and mobile networks (opensig’98). ACM SIGCOMM Computer Commun. Review, 29(1):97–108, 1999.
8. A. Doria, F. Hellstrand, K. Sundell, and T. Worster. General Switch Management Protocol (GSMP) V3. RFC 3292 (Proposed Standard), June 2002.
9. D.L. Tennenhouse, J.M. Smith, W.D. Sincoskie, D.J. Wetherall, and G.J. Minden. A survey of active network research. IEEE Commun. Mag., 35(1):80–86, 1997.
10. D.L. Tennenhouse and D.J. Wetherall. Towards an active network architecture. In DARPA Active NEtworks Conf. and Exposition, 2002. Proc., pages 2–15. IEEE, 2002.
11. Devolved Control of ATM Networks. http://www.cl.cam.ac.uk/research/srg/netos/old-projects/dcan/#pub.
12. J. D. Case, M. Fedor, M. L. Schoffstall, and J. Davin. Simple network management protocol (snmp), rfc1157, 1990.
13. M. Casado, M.J. Freedman, J. Pettit, J. Luo, N. McKeown, and S. Shenker. Ethane: Taking control of the enterprise. ACM SIGCOMM Computer Commun. Review, 37(4):1–12, 2007.
14. Andrea Passarella. Review: A survey on content-centric technologies for the current internet: Cdn and p2p solutions. Comput. Commun., 35(1):1–32, January 2012.

 

최영재 기자  cyjtw@techworld.co.kr

<저작권자 © EP&C News, 무단 전재 및 재배포 금지>