Software Defined Networking PDF Library

Editor’s Note:  Opinions and views expressed about software defined networking contained in the SDN document library are those of the document publishers and do not represent the views of SDNCentral. Documents come from publicly accessible sources including:  authors, publishers and web crawlers or submissions to SDNCentral.  SDNCentral is not responsible for factual accuracy in any listed documents.

Network Functions Virtualization and Software Defined Networking PDF and PPTs

Analyst Reports

Publicly available Network virtualization, Software-defined networking, SDN, and OpenFlow analyst reports library

Corporate Presentations

Network virtualization, Software-defined networking, SDN, and OpenFlow corporate presentation library

HotSDN 2013 WhitePapers

ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking (HotSDN)

Network Functions Virtualization

Network Functions Virtualization offers a new way to design, deploy and manage networking services.

Success Stories

Network virtualization, Software-defined networking, SDN, and OpenFlow success stories library








출처 :










Starting with Fedora 16 the openvswitch user space tools and the required kernel modules were included in the Fedora distribution. I spent some time on these packages and here an introduction and some information on how to use these components.


1. Introduction

Openvswitch is an alternative to the bridge module which has been part of the kernel, since the 2.4 series. The openvswitch has quite a few enhancements compared to the standard bridge module. These are described in detail One of these enhancements is the support for the OpenFlow protocol.

Conceptually,a switch’s functions can be broken down into two pieces: Control plane, data plane. The control plane is the core intelligence of the switch which handles discovery, routing, path computation, communication with other switches etc.The control plane creates a forwarding/flow table which the data plane uses toprocess the incoming packets at line speed. OpenFlow is a protocol which lets you offload the control plane of all the switches to a central controller and lets a central software define the behavior of the network (also called Software Defined Networks).

This setup is in contrast to the current infrastructures with proprietary switchesusing proprietary tools/protocols for management. OpenFlow being an openstandard allows switches from different vendors to be managed in a standard waywithout tying the infrastructure down with any proprietary tools.


2. Installation in Fedora

In Fedora, the implementation of the openvswitch is broken down to two pieces, the openvswitch kernel module (Data Plane) and some user space tools (ControlPlane). Since the incoming data Packets have to be processed as fast as possible, the data plane of the openvswitch was pushed to kernel space.

In order to use the openvswitch for networking VMs, the openvswitch service should be started and the command line tools have to be used to properly configure the openvswitch (will refer as vswitch here on) based bridge. The vswitch in Fedora can work in two modes: standalone, OpenFlow modes.


This article will primarily concentrate on how to bring up a VM connected to
openvswitch’s bridge in both Standalone & OpenFlow modes. The Virtual
Machine will be attached to a TAP device, which will be connected to the openvswitch’s bridge and traffic will be forwarded to the physical network via the physical NIC attached to the bridge.


 Before you go any further, install the openvswitch and tunctl packages with:

# yum install openvswitch tunctl



3. Bridging

3.1 Standalone mode

As the name suggests, in this mode the vswitch’s bridge handles all theswitching/forwarding functionality by itself. To bring up the vswitch’s bridge
start the openvswitch service with


# service openvswitch start


Use the standard tunctl command for creating a tap device:

 # tunctl –t tap0 –u root


Use the following commands to stop the NetworkManager service, bring down the em1 interface and flush all the ip addresses (if any) on the em1 interface (em1 being the NIC which will be used by the VMs to access the physical network)



 # service NetworkManager stop   

 # ip add flush em1

 # ifconfig down em1


Run the following commands to create a vswitch-based bridge by the name ovs-switch :

# ovs-vsctl add-br ovs-switch  ##(create bridge with name ovs-switch)

# ovs-vsctl add-port ovs-switch tap0 ##(add the tap interface to bridge)

# ovs-vsctl add-port ovs-switch em1 ##(add the em1 interface to the bridge)

# ifconfig tap0 promisc up ##(bring up the interface in promiscuous mode) 

# ifconfig em1  promisc up



These commands create a new bridge and add a tap device and local network port (em1) to the bridge. Setting these ports in promiscuous mode will let the trafficfrom the VM to be forwarded to host’s physical network and vice versa. Set an IP address on the ovs-switch interface with DHCP as follows:

  # dhclient ovs-switch


Now you can start your Virtual Machine with a command similar to the following:

# /usr/bin/qemu-kvm  -smp 2,cores=2 -net tap,ifname=tap0,script=no -net nic,model=rtl8139,macaddr=52:54:00:45:67:30 -m 2048M  ~/multiqueue/fedora.img



The virt-manager doesn’t yet support openvswitch. So there are currently no options available to start a VM using vswitch from virt-manager.


3.2 OpenFlow Mode


For running openvswitch in OpenFlow mode most of the commands from the abovesection have to be used. So, the commands are copied below to be comprehensive:


# yum install openvswitch

# service openvswitch start

# service NetworkManager stop

# ovs-vsctl add-br of-switch

# ovs-vsctl add-port of-switch tap0

# ovs-vsctl add-port of-switch em1

# ifconfig tap0 promisc up

# ifconfig em1 promisc up


NOTE: the bridge setup in OpenFlow mode will be referred to as of-switch here on.


4. POX Controller

Before you go any further, an OpenFlow controller should be up and running. The moment the bridge comes up it needs to talk to an OpenFlow Controller to make any forwarding decisions. Quite a few controllers available in the form of both software and hardware. The POX controller (software) will be used in this article. Download the sources of POX from with the following command:


 # git clone


After downloading the sources the controller can be run as follows:

# ./ forwarding.l2_learning

The above command will start POX with OpenFlow enabled and uses a plugin
forwarding.l2_learning on top. This plugin checks the incoming packets and
automatically creates a learning table for the bridge. Based on your
infrastructure requirements you can customize the available plugins or create
new ones. You can start the POX controller without any plugins (as ./, butthe controller will not know what to do with an incoming traffic. The user will have to manually setup the flows in the bridge in this scenario.


The above command will make pox listen on all network interfaces. If pox has tolisten on a particular interface and a particular port, you can start pox with

#./  OpenFlow.of_01  --address= --port=6666  forwarding.l2_learning


The openvswitch doesn’t support the hybrid openflow mode, where some of the traffic is processed by the built-in switch logic of openvswitch and some of the traffic is processed with the help of an OpenFlow Controller. The openvswitch has a failure mode of operation though. If the switch loses its connection with theController, it can fall back to using its built-in logic. This fall back behavior can be configured with the following commands:

 # ovs-vsctl set-fail-mode ovs-switch standalone

The above command will make the bridge fallback to the standalone mode if theconnection to the controller fails at some point.

 #ovs-vsctl set-fail-mode ovs-switch secure

After setting the fallback mode to secure, if the connection to the OF controllerfails, the switch will not be able to forward any packets at all.



4.1 Remote Controller

Consider the scenario where the OF controller is running on a remote host and thevswitch’s bridge (of-switch) is brought up in secure mode. If dhclient in run on the of-switch the switch has no idea how to forward the DHCP traffic as it cannot talk to a remote Controller without an IP address. So you either need to set the of-switch interface’s fall back mode to standalone mode OR assign a
static ip and setup up a static route so that the bridge can access the remote
controller. Once the bridge establishes a connection to the remote controller,
the traffic will be forwarded by the bridge based on the plugins setup in the
OF controller.


 Now that the bridge and the OF controller are running, the controller information can be assigned to the bridge with the following command:

  # ovs-vsctl set-controller of-switch tcp:


NOTE: with the above command, the bridge is connecting to an OF controller on the localhost which is listening on port 6633


5. Related Commands

Since the bridge and the controller are setup, you can power on the VM now (as shown in the above qemu command) and get the traffic directed by the OF controller. Whenever a new packet comes in and the bridge has no information on how to forward it, the bridge will send the packets header (with L2, L3 and some L4 information) to the controller. The controller will respond with an OF command telling the bridge how to forward traffic similar to that packet. The flows thusly assigned to the bridge can be listed with the following command:

 # ovs-ofctl dump-flows of-switch


 An example of one such response from the controller is shown below. A flow entry primarily contains a set of field=value entries and action entry. The field=value entries are used to identify the incoming packet and the actions tells the bridge with what to do with the matching traffic.


cookie=0x0, duration=14.604s, table=0, n_packets=61, n_bytes=7418, idle_timeout=10, hard_timeout=30,tcp, vlan_tci=0x0000, dl_src=78:2b:cb:4b:db:c5, dl_dst=00:21:9b:8e:36:62, nw_src=, nw_dst=, nw_tos=0, tp_src=22, tp_dst=60221


The above flow should be self-explanatory. If the traffic comes in from src macaddress 78:2b:cb:4b:db:c5, destination mac address 00:21:9b:8e:36:62, traffic istcp traffic, src ip=, dest ip=, TCP source port 22, tcp destination port 60221 forward the packet to port 1 (actions:1).


The ports configured in the bridge can be seen with the following command

# ovs-ofctl show ovs

OFPT_FEATURES_REPLY (xid=0x1): ver:0x1,

n_tables:255, n_buffers:256

features: capabilities:0xc7, actions:0xfff

 1(em1): addr:78:2b:cb:4b:db:c5

     config:     0

     state:      0

     current:    1GB-FD COPPER AUTO_NEG


supported:  10MB-HD 10MB-FD

 2(tap0): addr:a6:30:4d:0f:40:49

     config:     0

     state:      LINK_DOWN

     current:    10MB-FD COPPER

 LOCAL(ovs): addr:78:2b:cb:4b:db:c5

     config:     0

     state:      0

OFPT_GET_CONFIG_REPLY (xid=0x3): frags=normal


According to the above mentioned flow, the traffic has to be forwarded port 1 which is the em1 interface of the host.



If necessary some custom flows can be assigned to the bridge manually, followingare some examples of the same:

# ovs-ofctl add-flow of-switch
"in_port=LOCAL,table=0,idle_timeout=60,ip,hard_timeout=60,vlan_tci=0x0000, dl_src=78:2b:cb:4b:db:c5,dl_dst=00:09:8a:02:80:c0, nw_proto=1,nw_dst=, n w_src=,actions=drop"

The above rule makes the bridge drop all ICMP traffic (nw_proto=1) from192.168.7.189 to


As shown in the above add-flow example, the values idle_timeout and hard_timeout are defined for all the flows. These values tell the bridge how long this rule has to be used by the bridge. The idle_timeout causes the related flow to be deleted after a defined number of seconds of inactivity. The hard_timeout willdelete the flow after the defined number of seconds regardless of the activity. If a static rule has to be setup on the bridge, the idle_timeout and hard_timeout have to be set to  0(zero).



This concludes my investigation for now.  Hopefully this article will help more users start playing with the OpenFlow technology.


Above article is for informational purposes only. The content is from my
interpretation of the technologies/terminologies mentioned. This information is provided as is and may contain some typographical errors and/or technical inaccuracies.






출처 :







최근 SDN의 현황

-       OpenFlow는 미국 NSF의 지원으로 스탠포드 대학에서 진행된 미래인터넷 연구의 결과물로서, 라우터나 스위치와 같은 네트워크 장치에 종속적인 형태로 제공되던 제어 기능을 논리적으로 중앙 집중적인 형태로 분리하여, 표준 API를 통해 통신하는 구조를 토대로 개발된 기술이다. 현재 OpenFlow SDN(Software-Defined Networking)이라는 보다 넓은 개념으로 확장되어, Google, Facebook, Verizon, Cisco 등과 같은 업체 중심으로 새롭게 결성된 표준화 기구인 ONF(Open Networking Foundation)를 통해 현실 적용에 필요한 표준 규격과 기술을 개발하고 있다

-       SDN OpenFlow는 기존 네트워킹 기술과 달리, 간결한 메커니즘을 토대로, 기존의 네트워크 장비의 보조적인 역할을 수행하던 소프트웨어의 역할을 보다 확대하고, 분산 시스템과 운영체제, 데이터베이스와 같은 소프트웨어에서 정립된 개념을 적극적으로 도입하여 혁신의 속도를 높일 수 있는 구조와 생태계를 구성하는 데 노력하고 있다. 이처럼 소프트웨어의 역할을 극대화하여 혁신의 속도를 높일 수 있다는 장점의 이면에는, 이러한 소프트웨어 모듈의 오류가 전체 네트워크에 악영향을 미칠 수 있다는 위험도 존재하는데, SDN/OpenFlow에서 소프트웨어 오류로 인한 문제를  최대한 줄이기 위해 SDN 프로그래밍 관련 기술 동향을 언어와 검증 기법, 가상화라는 세 가지 관점으로 분석한다.


2.     SDN언어




FML(Flow-based Management Language)

엔터프라이즈 네트워크에 정책을 선언적인 방식으로 정의

네트워크 정책 및 설정을 논리기반언어로 정의

ACL, VLAN, 라우터정책, QOS, NAT

Frenetic, NetCore

Frenetic : 모듈화와 단일 티어 추상화를 제공하며, 경쟁 조건(race condition) 처리를 언어 런타임 차원에서 지원

NetCore : 네트워크 모델과 정형 의미론(formal semantics)을 이용하여 정의한 언어를 제공

Frenetic : 임베디드 언어형태

NetCore : 고수준 표현을 OpenFlow 규칙 형태변환하는 컴파일러 제작, policy 정형 검증을 위한 이론적 기반

Nettle, Procera

Nettle : OpenFlow 컨트롤러와 스위치가 서로 주고 받는 이벤트와 메시지를 하나의 스트림으로 추상화

이산적인 이벤트발생과 연속적인 시간에 따른 값이나 신호의 변화로 SDN 동작을 모델링

Procera : 고수준의 표현으로 policy를 정의할 수 있으며, 네트워크 컨트롤러 기반으로 동작하고 시제 연산자 사용

Nettle : 로드 밸런싱 애플리케이션

Procera : 이벤트 히스토리 제어

-       SDN구현을 위한 프로그래밍 언어에 따라 대규모 네트워크의 정책적용언어에서 데이터베이스 쿼리기반(Frenetic)언어 및 이벤트 및 history까지 제어 가능한 언어가 활발히 연구 중이다.


3.     검증기술

-        SDN/OpenFlow가 향후 널리 적용될 경우에 발생할 수 있는 잠재적인 문제점을 보완하기 위한 주요 검증기술





OpenFlow 네트워크의 프로그래밍 오류를 검출하기 위해, 모델 체킹(model checking) 기반의 검증 및 테스트 도구

OpenFlow에 최적화 된 네 가지 휴리스틱(huristic) 기법을 개발하여, 이벤트 발생 순서에 따른 경우의 수를 크게 줄이고, 잠재적인 오류 검출 특화, Python으로 구현

모델 체킹 기법을 SDN/OpenFlow 문맥에 단순히 적용하는데 그치지 않고, SDN에 맞게 적용 및 보완했다는 점에서 SDN에 대한 모델 체킹 기법의 대표적인 사례

HAS(Header-Space Analysis)

헤더를 구성하는 비트 패턴을 다차원의 기하 공간으로 표현하고, 스위치나 라우터와 같은 네트워크 장치를 거쳐는 부분을 변환 함수로 처리하여, 네트워크의 동작과 속성을 정적으로 분석하는 기법

현재 정의된 네트워크 설정 및 프로토콜 설계에 대한 패킷의 흐름 모델을 정의하고, 모든 패킷에 대한 동작을 정적으로 분석가능


SDN의 이론적인 모델을 수학적으로 정의, 네트워크 설정 업데이트 과정을 패킷 단위와 플로우 단위로 추상화하여, 네트워크 업데이트 과정에 발생하는 여러 가지 동작과 관련하여 네트워크에서 보장해야 하는 주요 속성을 엄밀하게 분석할 수 있는 이론적인 토대제공

언어 및 검증과 관련하여 이론적인 토대를 마련하고, 업데이트와 관련된 SDN의 전반적인 동작 과정에 대한 다양한 메커니즘 제시

Frenetic이나 Nettle 플랫폼과 결합되는 형태로도 발전할 가능성

FortNOX, VeriFlow

보안 위협 상황과 부주의한 네트워크 설정으로 인한 OpenFlow 규칙 간의 충돌을 실시간으로 검사하기 위해 개발한 NOX 컨트롤러의 확장한 모듈

네트워크에 대한 주요 속성을 실시간으로 검증하는 기법, 컨트롤러와 네트워크 장비 사이의 계층에서 동작하며, 검증으로 인한 지연 시간 최소화 메커니즘을 제시


gdb의 기능을 SDN 기반의 네트워크 문맥으로 재구성하여, 포워딩 상태와 패킷 로그 조작을 통해 에러의 원인이 되는 부분을 추적

 backtrace를 구성할 수 있도록, 패킷이 네트워크 장치를 지나칠 때마다 postcard라는 메시지를 전달하여, 모든 플로우의 시작점에 해당하는 패킷마다 특정한 표시를 남기는 효과를 구현

기술 검증 수준의 프로토타입을 제시했지만, ndb 논문에서 지적한 개선

사항을 반영하고, JTAG과 같은 하드웨어 지원도 뒷받침된다면, SDN/OpenFlow 네트워크의 디버깅 작업에 핵심적인 도구로 발전할 가능성

-       SDN/Openflow의 안정성을 위해 소프트웨어 검증기술을 비롯하여 보안, 디버깅기술까지 다양한 연구가 진행되고 있으며 가까운 시일 안에 상용에 가까운 새로운 네트워크 패러다임이 형성될 것이다.


4.     가상화

-       앞서 살펴본 SDN 프로그래밍 언어 및 검증 도구는 결국 SDN/OpenFlow 환경과 밀접하게 연계하여 동작할 수밖에 없다 이러한 환경을 제공하기 위한 플랫폼에서는 네트워크 가상화를 주요 요소 기술로 다루고 있는데, SDN 가상화 관련 논문과 오픈 소스 기반 소프트웨어 스위치인 Open vSwitch, 그리고 클라우드를 위한 오픈 인터페이스 기반 플랫폼인 OpenStack을 중심으로 가상화 관련 기술 동향도 간략히 정리한다.

가상화 기술



슬라이스 추상화

가상 네트워크들이 서로 방해하지 않는 모델 기반

VLAN과 같은 저수준의 메커니즘에 의존하는  네트워크 가상화 기술을 대체할 수 있도록, 슬라이스라는 네트워크 추상화 단위를 프로그래밍 모델 차원에서 지원하는 새로운 메커니즘

Frenetic/NetCore 언어를 이용한 슬라이스 단위의 가상 네트워크 모델을 정의하고, 이렇게 표현된 네트워크 명세를 OpenFlow 스위치 코드로 변환하는 컴파일러와, 이 과정의 정확성을 검증하기 위한 기법

Open vSwitch

오픈 소스 프로젝트로 활발히 개발하고 있는, 네트워크 가상화를 위한 소프트웨어 스위치

OpenStack 기반의 클라우드나 데이터 센터를 위한 가상 네트워크를 구성하는데 필요한 기능탑재

NaaS(Network as a Service) 서비스를 위한 핵심 모듈

STT(Stateless Transport Tunneling) 터널링 프로토콜과 OpenFlow 제어 및 관리를 위한 데이터베이스 모듈


컴퓨팅과 스토리지, 네트워크 등을 담당하는 이종 모듈끼리 메시지 큐와 REST API 기반의 플랫폼 독립적인 인터페이스로 상호 작용하는 구조의 클라우드 플랫폼

Xen을 비롯한 다양한 요소 기술을 구현한 상용 및 오픈 소스 제품을 최대한 수용하면서 기술 개선의 속도를 높일 수 있는 구조

-       Open Stack : cloud computing platform을 개발하기 위한 오픈소스 프로젝트이다. (흔히들 Cloud O/S 라고 부른다.)

-       OpenStack의 모든 소스코드들은 Apache 2.0 license 하에 모두 공개되어 있다.

-       OpenStack의 소프트웨어 구성요소는 크게 Compute(Nova), Storage(Swift), Networking, Dashboard, Shared Services 로 나눌 수 있다.


5.     표준화 활동 및 향후 연구 전망

-       ITU-T에서는 미래 네트워크를 연구하는 SG13/Q.21 그룹에서 SDN을 위한 프레임워크와 정형 명세 및 검증 요구사항에 대한 기고서가 제안되어 표준 문서 작업을 시작하고 있으며, 이와 관련하여 ONF와도 문서의 방향과 활동 방식에 대해 두 차례의 liaison 교환을 통해 논의된 바 있다.

IETF에서도 올해 상반기에 결성된 SDN RG를 통해 학계와 업계의 SDN에 대한 주요 방향과 프레임워크에 대해 활발히 논의되었으며, ETRI에서는 SDN을 위한 정형 언어에 대한 기고도 발표한 바 있다

-       SDN 언어는 FRP 기반의 Nettle, Procera, Frenetic logic 기반의 FML의 두 갈래로 구분할 수 있는데, 모두 DATALOG와 같은 선언적인 형태의 DB 쿼리 언어에 기반을 두고 있으며, 현재 활발히 연구되는 Frenetic Nettle, Procera만을 보면 모두 FRP 기법을 적용하고 있다. 특히 Nettle은 언어뿐만 아니라 컨트롤러 프레임워크의 의미도 강한데, 향후 Frenetic이나 NetCore와 결합하여 서로 시너지를 이룰 수도 있을 것으로 전망된다.

-       한편 검증 기법과 관련한 연구는 크게 모델 체킹을 비롯한 전통적인 정형 기법을 최대한 SDN/OpenFlow 문맥에 맞게 최적화하고, 기존 모델 체킹에서 흔히 지적되던 상태 공간 문제를 해결하는 기법을 가미하거나, SDN 문맥에 최적화된 디버깅 기능을 제공하는 것처럼 외부 도구를 활용하는 방식과, FortNOX Kinetic처럼 SDN/OpenFlow컨트롤러와 같은 핵심 구성 요소에 보안 및 신뢰성 보장 모듈을 추가하여, 컨트롤러 동작 과정에서 자동으로 주요 속성을 검증하는 방식으로 구분할 수 있다. 전자의 방법 중 스탠포드 대학 연구팀에서 제시한 HSA 기법은 패킷이라는기본 단위의 특성을 이용하여 범용적인 정적 분석 도구를 개발했다는 점에서, 모델 체킹이나 정리 증명 도구에 의존하는 다른 기법과는 색다른 시도라 볼 수 있다. 또한 ndb FortNOX는 정형 기법과 같은 특별한 배경 지식이 없어도 사용할 수 있을 형태로 구성하거나, 기존 OpenFlow 개발자의 관점을 충실히 반영한 도구를 제공한다는 점에서, 정형 기법이나 함수형 언어에 기반한 기법보다 쉽게 현장에 적용할 수 있을 것으로 예상된다. 또한 현재로선 언어와 검증 기법에 대해 다소 학문적인 접근이 두드러지는 경향을 보이고 있지만, 과거에도 라우팅 관련 policy 설정 및 동작 오류 문제가 꾸준히 제기되었고, 특히 소프트웨어 중심의 혁신을 추구하는 SDN에서는 이를 실현하는 소프트웨어 및 주요 모듈에 대한 동작의 신뢰성이 더욱 강조될 수 밖에 없으므로, 앞으로도 연구 활동의 규모와 활성도가 지금보다 확대될 것으로 전망된다.



-       정형 기법(Formal Methods) : SW/HW  시스템의  명세와  검증을 위한 수학 및 논리학 기반 기술이다. 소프트웨어 공학의 한 분야로, 계산이론, 프로그래밍 의미론을 비롯한 여러 가지 전산학의 이론에 기반을 두고 있으며, 시스템의 요구사항을 엄격히 만족시키고 신뢰성을 보장해야 하는 실시간 임베디드 시스템을 비롯한 다양한 분야에서 주로 활용된다.

-       정형 의미론(Formal Semantics) : 프로그래밍 언어의 의미를 수학 및 논리학 기반으로 엄밀히 정의한 것으로, 언어 및 컴파일러 구현이나 프로그램 검증에서 주로 활용된다.

-       FRP(Functional Reactive Programming) :  함수형 언어 기반의 반응형(reactive) 프로그래밍을 위한 방법론으로서, 연속적인 시간의 흐름에 따라 동작과 신호가 변하며, 이산적인 이벤트에 반응하는 모델에 기반을 두고 있다.





출처 :

           전자통신동향분석 27 6(2012.12)





복잡해져 가는 네트워크 환경 속에서 소프트웨어정의네트워킹(SDN)이 성숙기에 이르기 전까지는 패브릭 이더넷이 당면한 문제를 해결할 수 있는 현실적인 대안이라는 주장이 나왔다. 

20일 어바이어코리아는 서울 삼성동 코엑스에서 진 터젼 어바이어 엔터프라이즈 솔루션 담당 부사장이 참석한 가운데 기자간담회를 갖고 이같이 주장했다. 

터젼 부사장은 "(네트워크 기술에서 하드웨어 종속성을 줄인다는 점에서) SDN이 가야하는 방향은 맞지만 현실에서는 SDN이 아직 성숙하지 않았고, 채택율도 낮은 편"이라며 "이보다는 이미 수 년 간 구현된 사례들을 확보하고 있는 이더넷 패브릭 기술이 현실적인 대안"이라고 주장했다. 

▲ 진 터젼 어바이어 부사장.

그는 현재 SDN 기술은 과거에 사용됐던 레거시 네트워크 모델과 크게 달라진 점이 없다고 지적했다. 때문에 지금과 같은 복잡한 네트워크 문제를 해결하고 빠른 속도를 유지하기에는 한계가 있다는 설명이다. 

터젼 부사장에 따르면 기존 네트워크를 구축하기 위해서는 OAM, BGP, PIM, OSPF, MSTP, TRILL, STP, 802.1 등 모든 이더넷 기술 표준 프로토콜을 지원하면서도 각각 프로토콜이 서로 연동되도록 해야했다. 여러 프로토콜들 중 하나에만 문제가 생겨도 전체에 영향을 미쳤다. 

반면 터젼 부사장은 어바이어는 자사 패브릭 이더넷을 적용한 가상화 네트워크 기술인 '패브릭 커넥트'를 통해 엔드투엔드 엔터프라이즈 가상화 솔루션을 구현할 수 있다"고 강조했다.  OAM, 802.1 외에 프로토콜을 하나로 통합해 단순화 했다는 것이다. 

실전에서 이러한 기술을 사용한 것이 바로 소치 동계 올림픽이다. 소치 올림픽 공식 네트워크 공급사로 선정된 어바이어는 경기장, 선수촌, 미디어 센터, 데이터 센터, 기술 운영센터를 패브릭 커넥트로 연결했다.  

이를 통해 소치 올림픽 선수단, 코치, 자원봉사자, IOC위원을 포함해 4만여 명이 사용하는 12만개 모바일 기기를 연결하고, 경기 현장 전역에서 데이터 및 음성, 영상, 무선 인터넷 서비스와 올림픽 최초로 36개 HD 비디오 채널을 지원하는 IPTV 기술을 제공한다. 

어바이어는 또 경기장 곳곳에 설치된 2천500여 개 무선 액세스포인트(AP)를 통해 올림픽 경기를 중계하는 취재진들은 와이파이 서비스를 사용하고, 일반 관중들은 모바일 기기를 통해 경기 이미지와 영상을 실시간으로 공유할 수 있도록 했다.  

소치 올림픽에 적용된 패브릭 커넥트는 국제표준인 SPB(Shortest Path Bridge)에 기반해 네트워크 상 L3 영역인 IP레벨까지 지원하는 차세대 가상화 기술이다.  

다양한 네트워킹 플랫폼에서 사용이 가능하며, 짧은 시간 내에 설계와 구축이 가능하고, 발생할 수 있는 문제에 빠른 해결책을 제공하여 역동적으로 변화하는 올림픽 경기 환경을 효과적으로 관리할 수 있는 것이 특징이라고 어바이어는 설명했다.







출처 :








구글이 자사 퍼블릭 클라우드 서비스 환경에 '안드로메다'란 이름의 소프트웨어정의네트워크(SDN) 기술을 확대 적용했다. 외부에 오픈소스로 직접 제공하는 것은 아니다. 현재로선 자사 퍼블릭 클라우드 서비스를 차별화할 수 있는 기반 기술로 사용하려는 모습이다. 

구글은 2일(현지시각) 클라우드플랫폼 공식블로그를 통해 구글 서비스 일부에 쓰이던 안드로메다가 이제  퍼블릭 클라우드 서비스인  '구글컴퓨트엔진(GCE)' 사용자들에게도 제공된다고 밝혔다.  

구글은 일단 GCE에서 제공되는 '구역(zone)' 가운데 'us-central1-b'와 'europe-west1-a', 2곳을 안드로메다 기반으로 돌린다. 몇 달 뒤 나머지 구역에 있는 인프라도 안드로메다 기반으로 바꾸기로 했다.  

GCE 사용자들은 안드로메다 기반의 로드밸런싱, 보안, 방화벽 서비스를 주문형으로 쓸 수 있다. 구글은 안드로메다를 통해 클라우드 인프라에서 처리되는 가상머신(VM)간 데이터 전송이나 연산 작업을 보다 빠르게 만들었다. 네트워크같은 자원도 좀더 효율적으로 활용해 결과적으로 비용도 낮췄다.  

안드로메다는 구글 내부 인프라에 구현된 네트워크 가상화를 구성하는 SDN 기반 요소 가운데 하나라고 한다. 안드로메다 자체는 구글 클라우드플랫폼 서비스에서 제공되는 제품은 아니다. 그 안에서 돌아가는 가상 네트워크와 망내 패킷처리에 대한 수요예측, 세부구성 설정, 관리를 조화시키는 역할이다.

구글 수석엔지니어(Distinguished Engineer) 아민 바다트는 이달초 '오픈네트워크서밋'에서 안드로메다를 클라우드 도입시 필수인 가상화에 뒤따르는 네트워크 영역의 문제에 대응하기 위한 기술로 소개했다.  

바다트에 따르면 가상화 도입시 인프라 운영자는 VM, 하이퍼바이저, 운영체제(OS), 랜카드, 랙형 스위치, 패브릭 스위치, 외곽 라우터, 네트워크 말단부에 걸쳐 성능, 가용성, 보안성 요구를 조화롭게 지원해야 하는 과제를 떠안게 된다. 안드로메다는 이런 부담을 덜어줄 수 있다. 

바다트는 이전부터 구글이 안정적인 클라우드플랫폼 서비스를 위해 SDN 기술로 저수준 하드웨어부터 고수준 소프트웨어 구성요소까지 모든 네트워크 스택에 걸쳐 '프로그래밍이 가능한' 접근을 하면서, 보안과 성능에 최적화된 설계를 수행해왔다고 설명했다.  

구글이 처음으로 SDN 기반 네트워크 가상화를 구현한 시점은 2012년으로 알려져 있다. 당시 구글은 오픈플로 기반 SDN으로 네트워크 운영 효율을 개선하는 작업을 시도했다. 이제는 안드로메다 기반으로 클라우드 인프라를 운영한 덕에 더 저렴하고 빠르고 증설에 유리해졌다는 설명이다.  

구글이 제시한 안드로메다의 목표는 기반 네트워크의 본래 성능과 네트워크기능가상화(NFV)를 함께 퍼뜨리겠다는 것으로 보인다. 속을 들여다보면 최근 달아오르고 있는 아마존웹서비스, 마이크로소프트(MS) 애저 등 경쟁사 클라우드와의 차별화 시도로 보이기도 한다. 

▲ 구글이 내부 인프라에 써오다 컴퓨트엔진에 확대 적용한 SDN 기술 안드로메다의 추상화된 개념도.

이는 구글 내부 서비스와 동일한 네트워크 처리 노하우를 나머지 인프라에 그리고 독립적인 외부 사용자들에게도 확대 지원하겠다는 의미다. 기능적으로는 분산서비스거부(DDoS) 보호, 투명한 서비스 로드밸런싱 기술, 제어목록 접근과 방화벽 등을 포함한다.  

온라인 IT미디어 기가옴은 구글 안드로메다를 소개하면서  SDN 기반의 새로운 서비스는 독립적이면서 멀티테넌시를 지원하는 모순적인 상황을 실현해 준다는 점에서 흥미롭다고 평했다.  

보도에 따르면 구글은 네트워크 흐름을 제어함으로써 한 사용자의 VM이 내는 트래픽을 미리 정해진 클라우드 안에서만 발생되게 만들 수 있다. 즉 사용자 데이터와 연산 업무를 물리적인 장치에 묶이게 하는 제약을 두지 않으면서 특정한 클라우드 영역만 쓰도록 정할 수 있다는 얘기다.  

아직 안드로메다 기반으로 돌아가는 네트워크는 IPv4만 지원한다. 차세대 인터넷주소 체계인 IPv6를 지원하지 않는 상태다.  

바다트에 따르면 구글은 안드로메다를 GCE 사용자들에게만이 아니라 VM 이전이나 자동화 기능에도 적용할 수 있도록 만드는 중이다. 회사측은 이미 안드로메다를 써서 하드웨어상의 특정 작업을 독립적으로 처리할 수 있게 했고 사용자들에게도 이를 지원할 방침이다.  

그는 사용자들이 안드로메다에 담긴 기능을 제대로 쓸 수 있는 최선책은 구글 클라우드를 사용하는 것이라고 언급했다. 안드로메다를 오픈소스 소프트웨어로 내놓을 계획이 있느냐는 물음에 대한 답변이었다. 구글의 대규모 인프라를 최적화하는 핵심 노하우에 해당하니 선뜻 개방하긴 어려울 듯하다.  

바다트는 또 "안드로메다는 오픈플로를 일정부분 사용하고 있지만, SDN을 위해 오픈플로가 필수는 아니다"고 잘라 말했다. 그는 "안드로메다 기능을 구축하기 위해 네트워크에 연결된 장비를 모두 바꾸진 않았고 소프트웨어로 (안드로메다를 구현하기 위한 작업을) 모두 해냈다"고 덧붙였다.  

오픈플로는 네트워크장비의 제어부와 중앙 컨트롤러가 정보를 주고받기 위한 통신 프로토콜이다. 초기 SDN 구현시 주요 수단으로 거론된 오픈소스 기술이다. 서버와 네트워크 제조사, 가상화 플랫폼 업체 모두 각자의 구상에 따라 이를 활용한다. 업계 공통의 표준 프레임워크로 진화되진 않았다.








출처 :







+ Recent posts