ONOS


## Intro

SDN을 실제 구현하는 것은 굉장히 어려운 일이다. 따라서, Mininet을 활용하여 가상의 Topology를 통해서 먼저 테스팅을 한 후에 실제로 적용하는 것이 일반적이라고 할 수 있다.

따라서, 해당 Posting에서는 `Mininet`, `OpenFlow`, `Open VSwitch`, `ONOS`를 이용하여 간단한 Tutorial을 수행해볼 것이다. 이 Posting을 통해서 남기고자 하는 것은 SDN을 테스팅하는 절차를 익히는 것이다.

## 0. Tools

먼저 작성자의 실행환경은 MAC OS X로 대부분의 설정은 모두 동일하지만 `XTerminal`은 Window/MAC이 다르기 때문에 Window 전용을 설치해야 한다.

- Host Machine
  - Virtual Box : [🔗 Download](https://www.virtualbox.org/wiki/Downloads) [🔗 공식사이트](https://www.virtualbox.org/)
    - VM을 실행시키기 위한 도구, OpenSource이며 무료이기 때문에 많이 사용된다.(v6.1)
  - Vagrant : [🔗 Download](https://www.vagrantup.com/downloads) [🔗 공식사이트](https://www.vagrantup.com/)
    - Virtual Environment 구축을 자동화하는 도구(v2.2.19)
  - XQuartz : [🔗 Download](https://www.xquartz.org/releases/index.html) [🔗 공식사이트](https://www.xquartz.org/)
    - XTerminal 시스템으로 원격으로 Graphic 시스템을 호스팅하는 도구이다. 즉, `ssh`로 접속한 시스템에서 추가적으로 terminal을 생성하거나 GUI를 요구하는 application을 실행시킬 때 이를 host machine에서 실행할 수 있도록 돕는다.(v2.8.1)
- Virtual Machine
  - Mininet : [🔗 Download](http://mininet.org/download/) [🔗 공식사이트](http://mininet.org/)
    - Network Topology를 가상으로 구성할 뿐만 아니라 추가적인 configuration / testing이 가능한 Virtual Environment Emulator(v2.3.0)
  - OpenVSwitch : [🔗 Download](https://www.openvswitch.org/download/) [🔗 공식사이트](https://www.openvswitch.org/)
    - Virtual Switch를 실행시킬 수 있는 tool이다. 이를 통해서, Virtual Machine 내부에서 Virtual Switch를 가동시킬 수 있다.OpenFlow Protocol에 기반한 다양한 API를 내재하고 있기 때문에 이를 통해서 Virtual Switch의 Configuration 등과 같은 작업을 수행할 수도 있다.(v2.9.8)
  - ONOS : [🔗 Download](https://wiki.onosproject.org/download/) [🔗 공식사이트](https://wiki.onosproject.org/)
    - Open Network Operation System으로 SDN의 Controller 역할을 수행할 수 있다. 뿐만 아니라 WEB Interface도 제공하며, 다양한 API를 추가적으로 제공하기 때문에 유용하다.(v2.5.7)

## 1. Setup

위에 제시한 Tool을 모두 `Virtual Machine` 내부에 설치해야하지만, 자동으로 해당 tool을 설치하는 `Vagrantfile`을 만들어놓았기 때문에 사용해도 좋을 것이다. 해당 VagrantFile로 build하면 시간이 굉장히 소요될 수 있다. (인터넷 상태에 따라 천차만별이지만, 대략 20분?)

```bash
$ git clone https://github.com/euidong/virtual-sdn-boilerplate
$ cd virtual-sdn-boilerplate
$ vagrant up
# 접속
$ vagrant ssh
```

> **Run ONOS**

```bash
# In Virtual Machine
$ cd $ONOS_ROOT
$ bazel run onos-local
```

## 2. Scenario를 작성

우선 어떤 상황을 **emulation**할 것인지에 대한 구체적인 계획이 필요하다. 따라서, 이를 먼저 구상해보자. 아래 예시는 단순히 내가 생각한 예시이므로 정확성이런 것은 생각하기 보다는 흐름만을 익혀보자.

```plaintext
💡 Base Scenario

1. 후지산 인근에서 계속해서 화산활동이 감지되고 있다. 또한, 후지산은 100년 단위로 폭발을 해왔는데 최근 170여 년 동안 폭발이 존재하지 않고 있다. 이로 미루어보았을 때 후지산의 화산폭발은 얼마 남지 않았을 것이라고 추측할 수 있다.
2. 후지산에서 폭발이 발생하는지를 파악하기 위해서 곳곳에 관측기가 필요하며, 이를 분석할 센터가 안전을 위해 후지산 아래에 존재하며 백업 서버를 별도로 다른 공간에 두고 있다.
3. 각 관측소에서 서로 간 데이터 공유도 계속해서 발생하는 경우가 빈번하다. => Horizontal traffic이 많다 -> datacenter와 유사한 형태의 Network -> Spine-Leaf 구조가 적절.
```

## 3. Topology 구성 with Mininet

먼저, topology를 작성해야한다. 이를 위해서 `Mininet`을 활용한다. 이에 대한 개념 정리는 [🔗 Mininet](/posts/mininet)애 해두었다. Base Scenario의 3번 사항에서 알 수 있듯이 우리의 Topology는 Spine-Leaf 구조를 갖는 것이 적절하다. 따라서, 이를 먼저 표현해보도록 하겠다.

> **Source Code**

- `/vagrant/example/mt-fuji/topo.py`

```python
from mininet.topo import Topo

class SpineLeaf(Topo):
  def build(self):
    s_num = 2
    l_num = 5
    h_num = 2
    spines = []
    leaves = []
    hosts = []

    for i in range(s_num):
      spines.append(self.addSwitch('s%s%s' % (1, i+1)))
    for i in range(l_num):
      leaves.append(self.addSwitch('l%s%s' % (2, i+1)))
      for j in range(s_num):
        self.addLink(spines[j], leaves[i])
      for j in range(h_num):
        hosts.append(self.addHost('h%s%s' % (i+1, j+1)))
        self.addLink(leaves[i], hosts[i * h_num + j])

topos = { 'spineleaf': (lambda: SpineLeaf()) }
```

- 실행

```bash
$ sudo mn --mac --controller remote --switch ovs --custom /vagrant/example/mt-fuji/topo.py --topo=spineleaf
```

- 실행 결과
  - 빨간색 : `Spine Switch`
  - 청록색 : `Leaf Switch`

![Spine-Leaf Topology](/images/spine-leaf-topo.png)

## 4. Test 환경구축

주로 사용되는 Test 환경용 도구는 다음과 같다.

1. `ping` : 특정 machine 간의 연결 상태를 확인하기 위해서 많이 사용되어진다.
2. `trace` : `ping`과 유사하지만 지나쳐간 `hop`을 모두 조회 가능하여 좀 더 세부적인 경로를 확인할 때 유용하다.
3. `iperf` : client와 server 구조로 이루어지며, `tcp`, `udp` packet을 전송할 수 있다. 특정 machine에서는 `server`로 실행시키고, 다른 machine에서 해당 `server`로 data를 보내도록 할 수 있다. `ping`보다 주기적으로, 대용량의 데이터를 보내고 관측할 수 있다.
4. `wireshark` : 실젤 traffic의 이동을 GUI로 볼 수 있도록 돕는 도구이다.
5. `ONOS WEB GUI` : ONOS에서는 Web을 통해서 Network 상태와 Traffic을 관측하는 것이 가능하다.

여기서는 `iperf`를 통해서 데이터를 전송하고, `ONOS WEB GUI`를 통해서 traffic을 관측할 것이다.

아래 command를 통해서 `h51`가 위에서 언급한 후지산 아래의 서버가 되고, `h52`가 백업 서버가 되는 상황을 가정하기 위해서 해당 두 위치를 `iperf server`로 지정한다. 그리고 모든 관측소(`h11`, `h12`, ..., `h41`, `h42`)에서 `iperf client`가 되어 traffic을 주기적으로 보내도록 설정한다.

```bash
mininet> h51 iperf -s -u &
mininet> h52 iperf -s -u &

# xterm 명령어는 host에 위에서 설명한 XQuartz가 정상적으로 설치되어있어야 작동한다.
mininet> xterm h11 h12 h21 h22 h31 h32 h41 h42

# 각 client에서 다음과 같은 요청을 전송한다.
$ iperf -u -c 10.0.0.9 -i1 -t100000000000
```

![ONOS에서 확인한 모습](/images/sdn-tuto-example-1.png)

## 5. Flow Control

기본적으로 Flow를 제어할 수 있는 방식은 해당 Setting을 수행핼 때, 3가지 방법이 있다.

1. Open vSwitch CLI : OpenFlow Protocol에 기반한 여러 CLI 명령어를 지원한다. 이를 통해서, Flow Table을 직접 작성하는 것이 가능하다.
2. ONOS REST API : ONOS REST API를 통해서 제어가 가능하다. 이때에는 ONOS가 high level로 추상화한 flow control 방식을 활용해야 한다.(ex. intent) 이는 ONOS를 실행하고 있다면, 다음 url에서 확인이 가능하다. [http://localhost:8181/onos/v1/docs/](http://localhost:8181/onos/v1/docs/)
3. ONOS CLI : ONOS CLI 명령어를 통해서 제어가 가능하다.

이제부터 해당 세가지 방식을 적절히 활용하여 설정하여 각 Simulation 별로 수행을 해보도록 하겠다.

### Scenario 1

> **중간에 link가 끊어진 경우 with ONOS CLI**

![sdn-tuto-scenario-1](/images/sdn-tuto-scenario-1.png)

먼저 모든 host에서 server로 traffic을 중계해줄 수 있도록 다음과 같이 intent를 설정해줄 수 있다. 특정 host간의 intent를 설정하면 자동으로 경로를 찾아서 routing을 수행해준다. 또한, 특정 연결이 중간에 사라져도 자동으로 경로를 재설정한다.

```bash
onos> add-host-intent 00:00:00:00:00:01/None 00:00:00:00:00:09/None
onos> add-host-intent 00:00:00:00:00:02/None 00:00:00:00:00:09/None
onos> add-host-intent 00:00:00:00:00:03/None 00:00:00:00:00:09/None
onos> add-host-intent 00:00:00:00:00:04/None 00:00:00:00:00:09/None
onos> add-host-intent 00:00:00:00:00:05/None 00:00:00:00:00:09/None
onos> add-host-intent 00:00:00:00:00:06/None 00:00:00:00:00:09/None
onos> add-host-intent 00:00:00:00:00:07/None 00:00:00:00:00:09/None
onos> add-host-intent 00:00:00:00:00:08/None 00:00:00:00:00:09/None
```

이 후에 mininet에서 특정 link를 비활성화시킨다.

```bash
mininet> link s11 l25 down
```

![sdn-tuto-scenario-1-result](/images/sdn-tuto-scenario-1-result.png)

### Scenario 2

> **Load Balancing을 통해서 측정 데이터 고르게 분배 with Open Vswitch CLI**

![sdn-tuto-scenario-2](/images/sdn-tuto-scenario-2.png)

이전 Scenario의 intent를 유지한 상태에서 OpenFlow의 Group Table의 `select` type을 활용하면, Load Balancing이 가능하다. 먼저, ONOS CLI에서 외부 flowRule도 받아들이도록 설정한 후

```bash
$ onos localhost
onos> cfg set org.onosproject.net.flow.impl.FlowRuleManager allowExtraneousRules True
```

다음과 같이 group entry 생성 및 flow추가로 구현이 가능하다.

```bash
$ sudo ovs-ofctl add-group l21 \
  "group_id=1,type=select,bucket=output:1,bucket=output:2" -O OpenFlow11
$ sudo ovs-ofctl add-flow l21 in_port=3,actions=group:1 -O OpenFlow11
$ sudo ovs-ofctl add-flow l21 in_port=4,actions=group:1 -O OpenFlow11

$ sudo ovs-ofctl add-group l22 \
  "group_id=1,type=select,bucket=output:1,bucket=output:2" -O OpenFlow11
$ sudo ovs-ofctl add-flow l22 in_port=3,actions=group:1 -O OpenFlow11
$ sudo ovs-ofctl add-flow l22 in_port=4,actions=group:1 -O OpenFlow11

$ sudo ovs-ofctl add-group l23 \
  "group_id=1,type=select,bucket=output:1,bucket=output:2" -O OpenFlow11
$ sudo ovs-ofctl add-flow l23 in_port=3,actions=group:1 -O OpenFlow11
$ sudo ovs-ofctl add-flow l23 in_port=4,actions=group:1 -O OpenFlow11

$ sudo ovs-ofctl add-group l24 \
  "group_id=1,type=select,bucket=output:1,bucket=output:2" -O OpenFlow11
$ sudo ovs-ofctl add-flow l24 in_port=3,actions=group:1 -O OpenFlow11
$ sudo ovs-ofctl add-flow l24 in_port=4,actions=group:1 -O OpenFlow11
```

![sdn-tuto-scenario-2-result](/images/sdn-tuto-scenario-2-result.png)

### Scenario 3

> **h51이 down되어 h52로 traffic redirection with Open Vswitch CLI**

![sdn-tuto-scenario-3](/images/sdn-tuto-scenario-3.png)

server로 가는 Leaf Switch에서 packet의 IP, MAC 주소를 변경하여 Redirection이 가능하다.

```bash
$ sudo ovs-ofctl add-flow l25 \
  "in_port=1, dl_dst=00:00:00:00:00:09,
   actions=mod_dl_dst:00:00:00:00:00:10,mod_nw_dst:10.0.0.10,output:4"
$ sudo ovs-ofctl ad-flow l25 \
  "in_port=4, dl_src=00:00:00:00:00:10,
   actions=mod_dl_src:00:00:00:00:00:09,mod_nw_dst:10.0.0.9,output:1"
```

![sdn-tuto-scenario-3-result](/images/sdn-tuto-scenario-3-result.png)

### Scenario 4

> **Meter를 이용해서 관측소로 가는 과도한 traffic 차단 with ONOS REST API**

![sdn-tuto-scenario-4](/images/sdn-tuto-scenario-4.png)

특정 Switch에서 특정 port로 나가는 traffic의 최대값을 `500KB/s`로 제한하는 예시이다.

- Meter를 생성하기 위한 REST API  
  **`/meters/of:000000000000000c`로 POST 요청**

```json
{
  "deviceId": "of:000000000000000c",
  "unit": "KB_PER_SEC",
  "burst": true,
  "bands": [
    {
      "type": "DROP",
      "rate": 500,
      "burstSize": 0,
      "prec": 0
    }
  ]
}
```

- Meter를 특정 Switch에 적용하기 위한 REST API  
  **`/flows/of:000000000000000c?appId=meter`로 POST 요청**

```json
{
  "priority": 40000,
  "isPermanent": true,
  "deviceId": "of:000000000000000c",
  "treatment": {
    "instructions": [
      {
        "type": "METER",
        "meterId": "1"
      },
      {
        "type": "OUTPUT",
        "port": "2"
      }
    ]
  },
  "selector": {
    "criteria": [
      {
        "type": "ETH_TYPE",
        "ethType": "0x0800"
      }
    ]
  }
}
```

![sdn-tuto-scenario-4-result](/images/sdn-tuto-scenario-4-result.png)

## Reference

- Thumbnail : Photo by [Alina Grubnyak](https://unsplash.com/@alinnnaaaa?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/virtual-network?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)


SDN Tutorial


## 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)
