
## Intro

SDN Lullaby는 SDN/NFV 환경에서 효율적인 VNF 배치에 관하여 작성한 논문이다. 이 논문에서는 VNF 배치 문제를 DRL을 이용하여 해결하였다. 이를 위해서, 해당 논문에서는 상용 Cloud Data Center에서 주로 사용되던 VM Consolidation 방식을 활용하였고, 이 과정에서 추가적인 구현을 더해서 VNF 배치 문제를 해결하였다. 해당 Posting에서는 이를 구현 및 작성하는 과정에서 겪은 문제를 기반으로 한 회고록이다.

## Description

우선 해당 프로젝트를 통해서 해결하고자 했던 문제부터 정의하자면, 간단하게 SDN/NFV 환경에서 수 많은 VNF가 Virtual Machine(VM)의 형태로 존재하게 되는데 이를 Network Performance와 Energy Efficiency를 모두 고려하여 효율적으로 배치하는 것이 굉장히 어렵고, Rule based 방식으로는 한계가 있는 NP-Hard 문제라는 것이다. 이를 해결하기 위해서 해당 논문에서는 DRL 방식 중에서 PPO를 활용한 해결책을 제시하였고, 성능은 Rule based 방식보다 System Load가 낮은 경우에는 더 성능이 좋았지만, 높은 경우는 오히려 성능이 떨어졌다.

자세한 설명은 `CNSM 2023` 에 오늘(2023/07/11) 제출하였기 때문에 결과가 나오면 추가로 업데이트하도록 하겠다. 일단은 구현에 대한 모든 내용은 Github [SDN Lullaby](https://github.com/euidong/sdn-lullaby)에서 볼 수 있다.

## Process

해당 프로젝트의 시작은 연구실에서 진행 중인 프로젝트 중 외국인 학생에게 할당되어있던 파트가 통채로 나에게 넘어오면서 시작된다. 프로젝트를 이어 받아서 유지, 보수하는 것으로 얘기가 되고 있었는데 사실상 구현이 거의 되어있지 않다는 것을 알게 되었다. 결국 그 학생은 이미 떠나갔고, 결국 나는 이를 처음부터 구현해야하는 상황에 놓여졌다. 이것이 4월 20일 나에게 주어진 미션이였다.

우선 큰 흐름에서는 기존 외국인 학생이 제시한 방향인 강화학습을 활용한 VM Consolidation으로 가닥을 잡았다. 하지만, 실제 요구사항에 대한 정의가 애매했기에 이 부분은 랩미팅과 기존 자료들을 통해서 얻을 수 있었다.

초기에는 여러 다른 논문을 찾아보면서, 어떤 구현이 가장 타당한지에 대한 조사를 진행하였다. 이 과정에서 VM Consolidation은 **Server Selection**, **VM Selection**, **VM Placement** 3단계로 나누어진다는 것을 알게 되었다. 즉, 어떤 서버에서 VM을 옮길지를 먼저 선택한 후에 해당 Server에서 어떤 VM을 선택할지를 결정한 후, 마지막으로 해당 VM을 어느 Server로 옮길지를 결정하는 것이다. 하지만, 해당 논문들을 읽으면서 든 생각은 왜 첫 번째 단계인 **Server Selection**이 왜 필요한가였다. 사실 결론적으로 원하는 것은 VM을 선택하고자 하는 것다. 즉, Server Selection은 선택하고자 하는 VM을 제한하는 역할을 수행한다. 이는 잘못된 추론을 하는 경우에 명백하게 편향적인 선택이 될 수 밖에 없다. 따라서, 해당 프로젝트에서는 과감하게 해당 단계를 생략하고 두 단계로 진행하는 것을 목표로 하였다. (**VM Selection**, **VM Placement**)
또한, 알고리즘을 선택하는 과정에서는 처음에는 강화학습 중에서도 기본적인 SARSA, Q-Learning을 적용하여 해당 문제를 푸는 것을 목표로 하였다. 하지만, Server의 상태(State)를 강화학습의 Input으로 주는 과정에서 문제가 발생했다. Input으로 전달해야할 정보는 Server의 상태, VM의 상태, 전체 Server를 포함하는 Edge의 상태 등이 있었는데 이를 모두 하나의 State로 정의하는데에는 한계가 있었기 때문이다. 이는 VM의 수와 Server의 수가 늘어남에 따라 제곱으로 State와 Action의 갯수가 늘어나기 때문에 이를 모두 하나의 Table로 표현하는 단순한 SARSA, Q-Learning으로는 한계가 있다는 것을 깨달았다. 따라서, 이를 해결하기 위해서 두 가지 선택지 중에서 하나를 골라야했다.

1. State를 압축할 수 있는 방법을 찾는다.
2. Deep Learning을 적용하여, Table을 Network로 추정하자.

랩미팅 과정에서 교수님은 1번을 강조하셨다. State를 압축할 수 있는 방법을 찾는다. 굉장히 간단한 알고리즘만으로도 해결이 가능할 것이라고 얘기하셨다. 하지만, 초기에는 이에 대한 감을 잡지 못했기 때문에 결론적으로는 2번을 선택했다. 사실 State가 많아진다면, 간단한 DQN(Deep Q Network)만 활요하더라도 어느정도 성능을 챙길 수 있을 것이라고 생각했고, State를 압축할 방법이 당시로서는 생각하기 어려웠다.

따라서, DQN을 활용하여 문제를 해결하는 것을 바로 시도하였다. 여기서도 결국 문제에 부딪히게 된다. 바로 State를 모두 활용하는 것까지는 좋은데 Output의 크기가 계속 변화하면 어떻게 할 것인지에 대한 문제를 해결할 수 없었다. 즉, 우리가 원하는 VM Consolidation은 결국 어떤 VM을 어떤 Server로 옮길지를 결정해야 한다. 그렇다면, 매 사건마다 Server와 VM의 갯수가 달라질 수가 있다는 것이다. 일반적으로는 Server의 갯수가 변화하는 일은 흔치 않지만, VM은 매번 바뀔 것이다. 따라서, 우리가 고를 VM의 갯수를 해당 System에서는 Input State가 주어지기 전까지는 알 수 없기 때문에 Deep Learning Model의 Output의 크기를 알 수가 없다는 것이다. 즉, Input과 Output의 크기를 정해놓고 시작하는 일반적인 Deep Learning Model로는 한계가 있다는 것이다. 이를 해결하기 위해서 결국 RNN을 활용하기로 결정한다. 즉, RNN에 Input으로 주어지는 데이터가 (Batch size, Sequence length, Input size)의 형태로 주어졌을 때, output의 형태는 (Batch size, Sequence length, Output size)와 같다. 여기서 Sequence length는 변화하지 않는데, 내가 하고자 하는 작업이 사실은 VM/Server의 정보가 주어졌을 때, 하나의 VM/Server를 선택하는 일이기 때문에 VM/Server의 수만큼 Sequence를 만들고, 여기서 나오는 Output size를 1로 고정한다면, 결국 어떤 크기의 VM/Server 수가 들어오더라도 그만큼의 Output을 보장받을 수 있었다. 따라서, 이를 활용해서 초기에는 LSTM에 기반한 DQN 모델을 구현하였다. 여기서 RNN(LSTM을 포함한)은 사실 Sequence를 거치면서 값을 누적하기 때문에, 우리의 원래 의도랑은 다르게 어느 위치에 Input 데이터를 넣느냐가 영향을 미칠 것이라는 것을 생각해서 이를 완화시키기 위해서 Bi-Direction으로 LSTM을 구성하였다. 이렇게 구성한 모델은 아래와 같다.

![sdn-lullaby-arch-1](/images/sdn-lullaby-arch-1.png)

이를 실험하기 위해서, Emulation 환경도 구현을 해서 실험을 한 결과 서버 4개 정도에서 정상적으로 Consolidation이 진행되는 것을 확인했다. 하지만, 실제로 서버 갯수가 8개를 넘기자 전체적으로 성능이 떨어지는 것을 관측했다. 또한, 학습 과정에서 VM의 갯수가 Episode마다 유동적으로 변화하기 때문에 Batch 단위의 학습을 하기 위해서, Memory에 저장하는 과정에서 Episode Length마다 별도의 공간에 따로 저장하였다. 그리고, 학습을 진행할 때에는 Random하게 Length를 하나 선택해서 Episode를 추출했는데, 어떤 Length를 선택하냐에 따라서도 값의 변화가 크기 때문에 이 구조가 variance를 더 크게 할 것이라는 결론에 도달했다. 따라서, 이 문제를 해결하기 위해서 다음과 같은 해결책을 생각했다.

1. Self Attention 구조 적용(LSTM -> Self Attention)
2. Zero Padding 추가

앞 서 제시했던 Bi Direction을 활요한 LSTM은 설계 자체가 Hidden Value를 순서대로 추출해나가면서 이득을 취하는 것인데 해당 구조에서는 각 요소의 특징을 입력으로 받아서 어떤 요소를 선택할지에 관한 문제이기 때문에 Self Attention 구조가 더 적절하다는 판단을 했다. 또한, zero padding을 추가하여 모든 데이터를 한 번에 저장하였다. 또한, 추가적으로 불가능한 Action의 선택을 방지하기 위해서 추가적인 preprocessing을 추가하였다. 즉, 옮길 수 있는 서버가 없는 VM인 경우, 선택한 VM을 옮길 수 없는 경우는 미리 filtering을 수행하여 해당 데이터를 zero 로 marking하였다. 이를 통해서, 불가능한 Action을 선택하는 것을 방지하였다. 따라서, 이를 반영하여 변경된 구조는 다음과 같다.

![sdn-lullaby-arch-2](/images/sdn-lullaby-arch-2.png)

하지만, 전체적인 성능 개선이 이루어지지 않았고, 따라서 이를 해결하기 위해서 `AlphaStar`라는 논문을 참고하였다. 해당 구조에서는 아래와 같은 구조를 보여준다.

![alphastar](/images/alphastar.jpeg)

여기서는 Encoding Layer를 두고, 이후에 LSTM을 통해서 Sequence 정보를 입력받고, 후에 이를 기반으로 Action을 선택하는 구조를 갖고 있다. 또한, 여기서 특정 Unit을 선택하기 위해서 Self Attention과 Attention을 혼합하여 사용하는 것을 보고 내가 위에서 VM/Server Selection에 Attention Mechanism을 사용하는 것이 일반적인 해결책이라는 것을 알게 되었다. 어쨌든, 이름 참고하여 다음과 같은 구조를 구현했다. 여기서는 DQN이 아닌 PPO를 적용하였다.

![sdn-lullaby-arch-3](/images/sdn-lullaby-arch-3.png)

해당 구조를 통한 실험 역시 실행하였지만, 전체적인 성능 역시 변화하지 않았다. 그래서 결론적으로 최종적으로 두 가지 구조를 변형하여 구현을 마무리하였다. 먼저, 기존 DQN 구조에서 input layer를 추가하여 PPO 구조로 변경하는 것, 그리고 불가능한 Action에 대한 filtering을 preprocessing이 아닌 postprocessing으로 수행하는 것이다. Preprocessing을 수행하는 경우에는 결론적으로 정보의 손실이 발생하게 되는데 이로 인한 손해를 보지말고 차라리 최종 선택 단계에서 불가능한 Action을 선택할 확률을 0이 되도록 postprocessing하는 방식으로 변경하였다. 따라서, 최종 구조는 다음과 같다.

![sdn-lullaby-arch-4](/images/sdn-lullaby-arch-4.png)

해당 최종 구조를 통해서 결론적으로 에너지 효율성과 네트워크 처리 능력까지 향상하는 결과를 얻을 수 있었다. (이는 논문과 Github에 업로드된 자료를 확인하도록 하자.)

## Opinion

결론적으로 나의 첫 번째 Full Paper 논문이 였기에 아쉬움도 많이 남지만, 애착도 그만큼이나 남을 것으로 생각하고 있다. 먼저 총평을 하자면, 나름 만족할만한 프로젝트였다고 생각한다. 우선 랩 미팅마다 매주 progress를 발표하고, 논의하는 과정 자체가 굉장히 유의미했다고 생각한다. 그 때 작성한 자료들이 지금 작성하고 있는 글 그리고 얼마 전에 제출한 논문을 작성하는데 많은 도움을 주었다. 따라서, progress를 주 단위나 작업 단위로 정리하는 것은 굉장히 중요하다는 것을 다시 한 번 느꼈다. 그리고, 실제로 Deep Learning과 Reinforcement Learning을 활용하여 Project를 직접 구현한 것은 이번이 처음이기 때문에 굉장히 많은 걱정을 하였는데 많은 사람들의 도움을 받고 여러 책곽 논문의 도움을 받아서 결국 성공적으로 마무리했다는 것이 중요한 경험으로 남을 거 같다. 또한, 문제를 정의하는 것이 가장 중요하고, 여러 논문을 찾는 사전 준비 단계가 반 이상이라는 것을 깨달았다. 이 과정이 탄탄해야 막힘없이 진행이 가능한데 이를 초기에는 간과한 거 같아서 앞으로는 초반 준비 단계에서 자료 찾고 읽는 것에 굉장히 집중해야겠다는 생각이 들었다. 그리고, 구현하는 과정에서도 관련 자료가 있으면 계속해서 읽어보는 것이 전체적인 구현의 질을 높일 수 있다는 것을 다시 한 번 상기할 수 있는 기회였다.

해당 프로젝트를 하면서, 만족했던 점은 다음과 같다.

1. 이때까지 프로젝트를 진행하면서, 내가 항상 가지는 마인드는 "어떠한 판단을 하였다면, 이에 대한 근거를 항상 제시할 수 있어야 한다." 였는데 이는 해당 프로젝트에서는 꽤나 잘 지켜진 거 같아서 만족한다.
2. 정리를 굉장히 잘 해두었다. 발표 자료 및 자료 조사 내용 정리를 굉장히 잘 해두었고, 이를 통해서 논문 작성에도 큰 도움을 받았다.

아쉬웠던 점은 다음과 같다.

1. DRL은 처음 적용하다보니 여러 알고리즘을 실험해보고 싶었는데 결과적으로는 DQN, PPO 밖에 적용하지 못했다.
2. 실험 결과를 내는 과정에서 시간이 굉장히 오래 걸렸다. 이는 실험을 진행하면서, 여러가지 문제가 발생했기 때문인데 이를 미리 예측하고 대비하지 못한 것이 아쉽다.
3. 최종 구현의 Performance에 미련이 남는다. 결론적으로는 Baseline 시스템과 비교했을 때, 조금 좋은 부분이 있고, 어떤 부분에서는 매우 뒤떨어지기도 하는데 이에 대해서 General한 성능 향상이 있었다면 더 좋았겠다는 생각이 든다.

## Reference

- For Thumbnail: <a href="https://www.flaticon.com/free-icons/lullaby" title="lullaby icons">Lullaby icons created by Freepik Flaticon</a>
- For Thumbnail: <a href="https://www.flaticon.com/free-icons/data-server" title="data server icons">Data server icons created by The Chohans Brand - Flaticon</a>
- Arulkumaran, Kai, Antoine Cully, and Julian Togelius. "Alphastar: An evolutionary computation perspective." Proceedings of the genetic and evolutionary computation conference companion. 2019.


SDN Lullaby


## 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](/posts/openflow)에서 다룬다.

### 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를 구분하여 살펴볼 수 있다.

![SDN Architecture](/images/sdn-arch.jpeg)

- 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의 동작을 추상화하여

[🔗 공식 사이트](https://wiki.onosproject.org/display/ONOS/ONOS)

> **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까지 확장되었다. 자세히는 아래 표를 통해서 살펴보도록 하자.

|                 | ONOS                    | Open DayLight            | 비고                    |
| :-------------- | :---------------------- | :----------------------- | :---------------------- |
| 라이선스        | Apache 2.0              | Eclipse Public License   |                         |
| 개발자          | 제한 없음               | Vender                   |                         |
| SBI 지원        | 여러 SBI 지원           | ONOS보다 다양한 SBI 지원 |                         |
| 주요 고객       | 통신 및 클라우드 사업자 | 데이터 센터              |                         |
| 보안성          | 약함                    | 중간                     | 아직 모두 보완성이 낮음 |
| OpenFlow 호환성 | 1.0 ~ 1.5               | 1.0 ~ 1.3                | ONF 표준                |
| P4              | 지원                    | 지원                     |                         |
| Network 가상화  | 지원                    | 지원                     |                         |

[🔗 공식 사이트](https://www.opendaylight.org)

> **ONAP**

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

[🔗 공식 사이트](https://www.onap.org)

> **P4**

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

[🔗 공식 사이트](https://p4.org)

> **DPDK**

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

[🔗 공식 사이트](https://www.dpdk.org)

> **FD.io**

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

[🔗 공식 사이트](https://fd.io)

> **OpenStack**

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

[🔗 공식 사이트](https://openstack.org)

### 주요 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](https://unsplash.com/@dulhiier?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/network?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)
