SDN

Intro

SDN(Software Defined Network)은 기존에 Hardware단에 결합되어 있던 각종 Routing, Forwarding 방식을 별도의 Controller를 통해서 제어하는 방식을 제시한 것이다. 현재 이러한 기술에 대한 연구가 꾸준히 이루어지고 있는데, 이유를 알기 위해서는 기존의 Network 구성 방식의 문제점을 먼저 짚어보자.

Internet의 문제

Traffic 과증가

Traffic의 매년 20% 이상으로 굉장히 가파르게 성장하고 있다. 이것 자체도 문제가 될 수 있지만, 이로 인한 문제가 더 큰 문제가 되고 있다.

통신사업자의 고민

계속해서 늘어나는 traffic 대비 수익의 정체가 발생하였다. 즉, 증가하는 traffic을 수용하기 위한 link, switch 등의 투자 비용은 계속해서 요구되는 한편 신규 가입자 수는 거의 존재하지 않기 때문에 통신사업자가 가져가는 수익은 현재 매우 정체되어있다. 반면에 늘어난 traffic에 대한 이득은 고스란히 대규모 service 업체에서 가져가고 있다. (ex. Google, Netflix, etc..)

이러한 관점에서 통신사업자와 서비스 사업자 간의 아래와 같은 대립이 계속되고 있다.

• 공정성(Fairity) : traffic 증가는 서비스 사업자도 같이 부담하자.
• 망중립성(Neutrality) : traffic 증가는 서비스 사업자가 상관할 영역이 아니다.

느린 표준화

표준화라는 절차는 호환성 검사 및 성능 확인 등을 거치면서 굉장히 많은 시간을 요구한다. 하지만, 신기술은 계속해서 쏟아지고 있기 때문에 표준화가 이 속도를 못따라가고 있는 것이 실황이다. 이를 실제 상용에서 적용하는 것 역시 더 많은 시간이 들게 될 수 있다.

Vender 의존성

통신 장비(Switch, Router, Ethernet, etc...)를 제작하는 Vender(Cisco, Juniper, etc...)가 만든 platform에 의존하는 설정 방법이 혼란을 야기했다. 즉, 각 vender마다 다른 시스템과 configuration 방법이 존재하기 때문에 human error를 야기할 가능성이 높았다.

또한, Switch/Router의 동작을 제어하는 것이 해당 vender가 제공하는 API에 제한되기 때문에 사용자가 Programming을 통해 Routing을 제어하는 것이 불가능했다. 그렇기에 신기술에 대한 테스트를 수행할 수 없을 뿐만 아니라 Vender에서 해당 신기술을 적용하기를 기다리는 수 밖에 없었다.

Router/Switch의 복잡도 증가

traffic의 증가만큼 Router, Switch의 성능적인 향상 및 양적 증가는 많은 문제를 야기하고 있다. 먼저, 성능을 만족하기 위하여 점점 가격이 급격하게 상승하고 있다. 양적으로의 증가는 결국 Routing Table의 크기를 크게 증가시키고 있다. 이는 Table Lookup, Convergence Time 증가를 야기한다.

초기 인터넷의 구조적 문제

초기 인터넷인 ARPANET은 설계 자체가 절대 연결이 끊기지 않는(autonomous, Best Effort) Network를 추구했다. 그렇기에 사람에 의한 개입이 쉽지 않고, 통제가 어려운 구조이다. 따라서, 각 장비에게 부여되는 책임이 커졌다.

TCP/IP 기반의 수 많은 Protocol

지연보다는 연결에 초점을 맞춘 안전한 TCP/IP 기반의 통신은 Network의 성능면에서 많은 어려움을 겪고 있다. 물론 새로운 TCP 방식도 제시되고 있지만, 이를 교체하는 것은 전체 Network를 변경해야하는 경우가 많기에 이에 대한 교체는 사실상 불가능하다고 간주되고 있다(호환성 문제). 또한, IoT 디바이스에서는 해당 TCP/IP가 다소 무거운 구현이기에 이를 포함할 수 없는 경우가 많다. 따라서, 별도의 Protocol을 지원하는 시스템이 필요하다.

요약

즉, Traffic은 계속해서 증가하고 있는데, 이를 해결하기 위한 신기술들은 계속해서 적용이 느려지고 있으며, Vender들 마다 다른 표준으로 인해 너무나 복잡한 네트워크 구성은 운영비용의 최적화가 어렵고, 유연한 네트워크 구조를 만드는데 굉장한 부담으로 다가왔다. 따라서, 이를 해결할 방법이 필요해졌다.

SDN

위에서 제시한 문제들은 결국 각 Switch/Router와 같은 Hardware 장치에 Software가 귀속되어서 발생한다. 따라서, Switch/Router는 단지 Hardware의 기능을 수행하도록하고, Software는 최소한의 기능만을 남긴 후 이들이 수행하는 Forwarding/Routing 등의 동작을 별도의 Generic Computer에 Controller라는 역할을 부여하고, 이 Controller에 의해서 Forwarding/Routing을 제어할 수 있도록 구성한 Network를 통해서 기존 문제를 해결하자는 것이다.

이를 통해서, 결국 각 장치들은 Routing이 어떻게 정해졌는지에 대한 내용은 알지 못한다. 하지만, Hardware적으로 packet의 입력을 받을 수 있을 뿐만 아니라 Controller로부터 어디로 packet을 forwarding 해야할지에 대한 정보는 알고 있고, 이에 따라 packet을 내보내는 것도 가능하다. 따라서, 전체 네트워크가 Controller를 분리함으로써 추상화가 되는 것이다. 이러한 추상화의 장점은 결국 유연한 네트워크를 만들 수 있다는 것이다.

이것이 SDN이 추구하는 사상이다. 이것을 가능하게 한 것이 OpenFlow의 등장이다. OpenFlow에 대한 설명은 별도의 Posting에서 다룬다.

Google의 SDN 활용 사례

문제 상황

Google에서는 매년 40~45%의 Traffic의 증가가 발생하였다. 이를 대비하기 위해서, Google에서 전용 해저 케이블을 설치하였다. 이를 통해서, Google의 각 DataCenter 간의 연결 품질을 올리고 싶었다. 하지만, 실제로 DataCenter간의 통신에는 30~40% 수준으로만 케이블을 사용했다. 기존의 Routing으로 DataCenter간 서비스의 Traffic을 적절하게 분배하고 싶었지만 이를 수행할 수 없었다.

해결책

자체 개발한 OpenFlow Protocol을 지원하는 Switch를 개발하여, 이를 이용하여, 다음과 같은 서비스에 weight를 부여하여 적절하게 traffic을 분배하였다.

• User data copy : 각 데이터 센터간의 e-mail, video 등의 파일 동기화
• 검색어 ranking을 위한 데이터 copy
• Datacenter간 상태 동기화

해당 service에서 발생하는 traffic을 적절하게 weight를 부과하여 SDN을 활용하여 분배하여 결국 Datacenter간의 통신에서 광케이블 활용률이 90%까지 상승했다.

주요 OpenSource

SDN 구축에 많이 활용되는 주요 OpenSource를 정리한다. 그전에, OpenSource의 구성 형태를 알아볼 필요가 있다. 아래와 같은 형태로 각 OpenSource를 구분하여 살펴볼 수 있다.

• North : 실제 SDN Controller와 communication을 통해 SDN configuration을 변경한다던가 GUI로 현재 상태를 체크하는 등의 동작을 수행할 수 있다.
• North Bound Interface : SDN Controller와 communication을 가능하게 하는 Protocol이다.
• SDN Controller : 실제 SDN에서 Routing을 제어할 Controller
• South Bound Interface : SDN Controller와 Network Node들(실제 또는 가상 Switch)과의 communication을 가능하게 하는 Protocol이다.
• South : Physical / Virtual Switch

각 OpenSource에 대해서는 자세히 다루지 않는다. 세부적으로는 시간이 주어지면 하나씩 해나갈 생각이다.

ONOS

위에서 설명한 영역에서 North, North Bound Interface, SDN Controller의 역할을 모두 수행할 수 있는 Open Source이다.

Open Network Operating System의 약자로, ONF에서 관리하며 SDN Controller를 구성하는 방법을 제시한다. 이를 통해서, 유연하고 안정적인 Network Service를 구축하는 것을 목표로 한다. 유연하다는 것은 간단한 program을 구현할 수 있는 interface를 제공하며, 네트워크 상태를 정의하고, 이를 실시간으로 업데이트할 수 있는 환경을 제공한다. 안정적이다의 기준을 ONOS에서는 99.999 % Availability를 제공하는 것을 목표로 한다.

본 목적은 Controller를 구성하는 것이지만, REST API(NIB)에서부터 Web을 통한 Dashboard GUI(North)와 CLI(North)를 제공하고 있다. 또한, 내부적으로 OpenFlow의 동작을 추상화하여

🔗 공식 사이트

Open DayLight

ONOS와 가장 많이 비교되어지는 OpenSource로 마찬가지로 North, North Bound Interface, Controller 기능을 제공한다.

Cisco와 Network Vender를 모아서, ONOS를 견제하기 위해서 초기에 시작된 Project로 ONOS는 SDN Controller에 좀 더 집중하는 한편, Open DayLight는 SDN 시스템을 구축하는 환경을 제공하는 것을 강조한다. 또한, Vender에 의해서 관리되기 때문에 ONOS와 비교하였을 때, SBI가 케이블tv 및 IoT Protocol까지 확장되었다. 자세히는 아래 표를 통해서 살펴보도록 하자.

🔗 공식 사이트

ONAP

ONAP은 Open Network Automation Platform의 약자로 SDN의 Life Cycle을 관리하는 도구로 이해하면 쉽다. 위의 제시한 Controller로 부터 각 각의 Switch에 이르는 장치들의 상태를 확인하고, 적절하게 orchestration하는 도구이다. 이는 AT&T의 ECOMP project와 중국 네트워크를 위한 Open-O가 결합하여 Opensource화를 진행한 프로젝트이다.

🔗 공식 사이트

P4

Programmable, Protocol-Independant Packet Processor의 약자로 기존의 제한된 기능만 수행하던 Fixed Function Switch를 필요에 따라 기능을 다르게 구현할 수 있는 Programmable Switch로 대체하고, P4를 이용하여 programming할 수 있는 환경을 제공하는 것을 목표로 한다. 현재에는 Switch 내부의 Packet Forwarding과 Access Control 기능 개발용으로 특화된 상태이다. 아직까지는 Queue의 Scheduling과 같은 기능은 제공하지 않는다.

🔗 공식 사이트

DPDK

고성능 packet 처리를 위한 Library와 Driver의 집합이다. Virtual Switch의 가장 큰 문제는 OS Kernel을 통과하면서 발생하는 Overhead이다. 이를 해결하기 위해서, DPDK에서는 Kernel을 통과하여 수행하는 Kernel bypass라는 기능을 제공한다. 이를 통해서 Packet 처리를 가속화하였다.

🔗 공식 사이트

FD.io

DPDK와 마찬가지로 packet 전송의 가속화를 목표로 한다. 기존 하나의 Packet을 보낼 때, 그래프 연산이 끝날 때까지 다음 packet이 무기한 기다리는 것을 방지하고자 병렬 또는 동일 목적지 packet을 빠르게 식별하여 packet 전송을 최적화하는 것을 목표로 한다.

🔗 공식 사이트

OpenStack

OpenStack은 범용 Cloud를 구축하는 Solution을 제공한다. 즉, 여러 Node를 가진 사용자라면, 여타 Vender(AWS, GCP)를 이용하지 않고, Cloud 환경을 구축하는 것이 가능하다. 이를 통해서 구축한 Cloud에 Controller를 구성하고 SDN를 제공하는 경우도 많다.

🔗 공식 사이트

주요 SBI

South Bound Interface란 실제로 Switch와 Controller가 어떻게 communication을 수행할 것인지에 대한 Protocol을 의미한다. 현재 사실상 표준이라고 여겨지는 Protocol은 다음과 같다.

OpenFlow

앞 서 계속해서 설명해왔기에 생략한다.

NetConf

Network 장비(Switch, Router)의 Configuration을 위한 Protocol로 기존 Vender마다 다르던 Configuration 과정을 이를 통해서 간략화하고, 기초적인 Programming을 통해서 이 과정을 자동화하는 것도 가능하다.

I2RS

OpenFlow를 통해서 기존 Network 장비의 데이터 평면과 제어 평면의 완전 제거에 대한 반발로 인해 생겨나 Protocol이다. 이는 Cisco에서 만들어졌으며, 기존 Switch/Router의 제어 평면을 그대로 유지하면서 외부 Controller로부터의 제어를 일부 수용하는 형태의 Protocol이다.

BGP-LS / PCE-P

SDN Controller와 Network 상태 정보를 공유하기 위해 개발된 Protocol이다.

LISP

IP에 의한 네트워크 주소와 단말기 주소가 완벽하게 구분되지 않는 문제에 의해서 만들어졌다. 즉, 단말이 이동 시에 네트워크 주소를 재설정해주는 등의 번거로움이 발생할 수 있다.따라서, IP header에 LISP header를 추가하여 실제 기기 주소와 네트워크 주소를 식별하는 정보를 추가하는 것이 핵심 아이디어인 Protocol이다.

주요 연구 동향

1. CORD

현재까지는 DataCenter, Cloud에 한정되어 있는 SDN의 적용을 실제 전화국 및 가입자 통신 시설의 가상화까지 이어가고자 하는 것이 목표이다. 현재 프로젝트는 총 4개의 세부 프로젝트로 나뉘어져서 진행중이다.

1. E-CORD : 기업용 최적 인터넷 구성 시간 단축
2. R-CORD : 광가입자 서비스 장치의 가상화
3. A-CORD : 데이터 수집 기능을 프로그래밍 가능하게 구현하여 이를 통한 제어를 목표
4. M-CORD : 4G/5G 장치의 가상화

2. Pronto Project

네트워크의 모든 동작을 Monitoring하고, 제어하는 Deep Programmable Platform을 구현하여 네트워크 사업자가 제어권을 확보하도록 하는 것을 목표로 한다.

NFV

SDN과 같이 얘기되어지는 NFV(Network Function Virtualization)도 살펴보고자 한다. 위에서 SDN을 설명하였지만, 결국 아직까지는 DataCenter를 운영하는 서비스 사업자 지향적이다. 대게 닫힌 네트워크 내에서 사용이 용이하다는 것인데, 이는 보안과 관련된 부분도 부족하기 때문이다. 따라서, 통신 사업자들은 SDN을 효과적으로 구성하기 위해서 통신 장비의 하드웨어와 소프트웨어를 분리할 방법을 찾아야 했다. 여기서 나온 방법이 Cloud를 활용하여 소프트웨어 영역을 Cloud 내부에서 구현하고, 통신 장비는 최소한의 소프트웨어만으로 구성하는 것이다. 즉, Network의 특정 기능을 가상화해서 필요에 따라 각 하드웨어 장비가 불러와 사용한다는 개념이다. 결국 통신 사업자 입장에서는 SDN을 구축하기 위해서는 NFV의 구현이 우선시되는 것이다. 이를 수행하게 되면, 당연히 Software의 유연한 구현이 가능하고, 각 장치에서 Software까지 부담해야 하는 비용이 줄기 때문에 설치 및 운영비용(CAPEX / OPEX)에서 큰 이점을 볼 수 있는 것이다.

Reference

• Thumbnail : Photo by Nastya Dulhiier on Unsplash