OpenFlow


## Intro

<https://ieeexplore.ieee.org/document/6838228>에 기재된 `OpenNetMon: Network Monitoring in OpenFlow Software-Defined Networks`의 내용에 대한 리뷰이다. 이름에서 알 수 있듯이 OpenNetMon은 POX OpenFlow Controller를 이용하여 수많은 network component로 이루어진 fine-grained Network에서 Traffic Engineering을 위한 QoS Metric을 flow 단위로 제공하는 것을 목표로 한다. 수집하는 데이터는 **Throughput**, **Packet Loss**, **Delay**를 측정한다.

## Monitoring

Monitoring의 종류 그리고 OpenNetMon 이전의 Monitoring 방법론에 대한 소개를 먼저한다.

> **Type of Monitoring**

세 가지 기준에서 Monitoring 방법들을 구분한다. 그 중에서 첫 번째로 제시된 것이 **Active**, **Passive**이다.

- **Active** : 추가적인 packet을 Network 상에 삽입하여, 해당 packet의 동작을 통해서 측정을 하는 방법으로 과도한 추가 packet은 Network에 영향을 주기 때문에 이에 유의해야 한다. 반대로 너무 적은 packet을 사용하는 경우에도 정확성과 실시간성이 떨어질 수 있다.
- **Passiv** : 추가적인 packet의 삽입없이 기존 traffic에 대한 관측만으로 측정하는 방법으로 모든 네트워크에 적용할 수 잇는 범용적인 방법은 사실상 불가능하다고 할 수 있으며 각 Network를 위한 전용 Hardware 장비가 필요할 수도 있다. 또한, Synchronization을 위한 별도의 방법 또한 필요하다.(각 Network 장비에서 관측한 Traffic이 서로 대응되는지 확인할 수 있어야 하기 때문)

두 번째는 어떤 Layer에서 Monitoring을 수행하는가이다. Application Layer에서 측정을 하게 된다면, 활용할 수 있는 데이터가 많아지고, 실제 user 입장에서의 최종 데이터를 얻는 것이 가능하다. 하지만, 실제 서비스 제공자 입장에서 모든 End Device에 대한 접근이 불가능한 경우가 많다. 반대로 Network Layer에서 측정을 수행하는 경우에는 사용할 수 있는 데이터가 각 Switch 와 같은 Network 장비에서 packet이 어느 port로 나갔는지와 같은 간단한 정보밖에 사용할 수 없다는 단점이 있었다.

세 번째로 제시되는 것이 `OpenFlow`를 이용하였는가 아니면 이를 사용하지 않았는가이다. `OpenFlow`가 등장하면서 결국 Network Layer에서의 측정이 더 큰 의미를 가지게 된다. 왜냐하면, **Switch에 설정을 미리 주입하거나 새로운 traffic에 대한 정보를 실시간으로 추가할 수 있으며 Flow 단위로 통계치를 얻거나 임의의 packet을 추가하는 등의 작업을 수행할 수 있었기 때문에 Network Layer에서의 더 많은 Monitoring이 가능해졌다.** 이것이 해당 논문이 OpenFlow를 통해서 구현하고자 하는 바이다. Network Layer에서 복잡한 네트워크에서도 보다 정확하고, 실시간의 통계 데이터를 추출할 수 있다는 것이다.

아래는 해당 논문에서 추가로 제시하는 OpenNetMon 이전에 존재했던 Monitoring 방법에 대한 정리이다.

|                 | Active/Passive | Layer   | OpenFlow 여부 | 설명                                                                                                                                                                                                            |
| :-------------- | :------------- | :------ | :------------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| SNMP            | Active         | Network | X             | port 단위의 packet counter 기능 제공 <br/> switch의 통계정보 제공(CPU, RAM)                                                                                                                                     |
| NetFlow / cSamp | Passive        | Network | X             | switch를 통과하는 n개의 packet마다 임의의 1개의 packet을 선별하여 이를 대표값으로 하여 Network 상태를 측정하지만, 정확도가 많이 떨어질 수 있다.                                                                 |
| Skitter         | Active         | Network | X             | 전체적인 Network Delay를 측정하기 위해 대표지역에 측정기를 설치하여 실행한 project로, 이를 통해 대략적인 지연을 예측할 수는 있지만 정확하지는 않다.                                                             |
| IPMON           | Passive        | Network | X             | TCP/IP packet header를 추출하여, timestamp와 함께 중앙 server로 전송하여 이를 분석하는 방식이다. <br /> Passive임에도 Synchronization을 맞추기 위해서 통신은 불가피하며 Network 크기가 커질 수록 비용이 커진다. |
| OpenTM          | Passive        | Network | O             | 각 Flow의 통계 데이터를 일정 주기로 Query하여 수집한다. Flow의 시작과 끝 지점에서만 측정하는 Last-Switch 방식을 사용한다.                                                                                       |
| OpenSAFE        | Passive        | Network | O             | SDN의 모든 새로운 Flow가 Controller로 이동하는 것을 이용하여 Monitoring 시스템으로 Controller가 이를 전달하도록 하는 방식이다.                                                                                  |
| OpenSketch      | -              | -       | -             | Monitoring을 위해 OpenFlow 자체를 재정의하자는 것으로 새로운 Protocol을 정의해서 더 나은 Monitoring을 수행하자는 방법이다. <br /> 하지만, 이렇게 새로운 Protocol을 만드는 것은 Risk가 너무 크다.                |

## OpenNetMon

기존의 Monitoring 방식들은 OpenFlow의 Packet 삽입을 이용한 방식을 제대로 사용하지 않았을 뿐만 아니라 Flow 측정에 있어 최적화에 한계가 있었을 뿐만 아니라 **Throughput**, **Packet Loss**, **Delay**을 통합하고자 하지 않았다. 따라서, OpenNetMon은 이를 수행하는 것을 목표로 한다.

각 측정 요소를 어떻게 수집할 것인지를 각 각 정리한다.

> **1. Throughput**

OpenFlow의 `FlowStatsReq`(Controller에서 각 Switch로 전송하는 Request)를 주기적으로 호출하여 각 Switch에서 전송한 Byte의 양과 각 Flow의 지속 시간을 얻는다. 주기적 호출 싱레는 경로 상의 처음과 끝을 호출하는 Last Switch 방식을 사용하며, 이는 Round Robin이 대규모 네트워크 환경에서 비효율적일 뿐만 아니라 Packet Loss 측정 시에도 Last Switch는 필수적으로 필요한 요소이기에 최적 요소만을 사용하는 것이다.

또한, 이러한 호출 주기는 변동적으로 설정되었는데 이는 Link State Information에 기반한 Routing Discovery 시에 이를 교환 및 동기화하는 것은 Network Throughput에 많은 영향을 미치며 Throughput을 굉장히 큰 범위로 변동되게 한다. 이에 따라 아직 convergence(수렴)이 안된 시점에는 주기를 더 빈번하게 하고, 후에는 이를 되돌리도록 하는 설정이 필요하기에 이 또한 추가되었다.

> **2. Packet Loss**

시작지와 목적지의 Switch에서 해당 Flow에 대한 Packet Counting을 수행하여 계산한다.

> **3. Delay**

Packet을 하나 생성하여 출발 시간과 도착 시간을 통해 측정한다. 따라서, 다음과 같은 식으로 정리할 수 있다. 아래 RTT는 Controller와 각 Switch 간의 RTT를 의미한다.

$$ t_{delay} = (t_{arrival} - t_{sent} - {{1}\over{2}}({RTT}_{sentSwitch-controller} + {RTT}_{arrivalSwitch-controller})) $$

## Evaluation

실제 실험을 통해서 OpenNetMon에 대한 성능을 테스팅하였다. 이과정에서 총 4개의 OpenFlow를 지원하는 Switch를 일자로 연결하고 각 말단에 Server와 Client를 연결한 후에 각 Switch가 POX OpenFlow Controller에 직접적으로 연결되도록 구성하고, 각 말단과 Server/Client로의 연결은 1Gbps Ethernet로 연결하고, Switch간의 연결은 100Mbps에 1% loss, 1ms delay로 설정을 하였다. 실제 전송 데이터는 video stream traffic을 활용하여 복잡한 traffic 전송을 표현하고자 했다.

실제 그래프와 Topology는 직접적으로 가져오지는 않았다. 아무래도 저작권에 대해서 제대로 알 수 없어서 가져오지 않았다. 하지만, 논문과 같이 비교하면서 보면 도움을 받을 수 있을 것이다.

> **1. Throughput**

Application Level에서 구현한 `tcpstat`과 비교했을 때, 16KB/s(1.2%) 정도 밖에 차이가 나지 않았다. 하지만, 초기에 17.8%까지 차이가 발생하는데 이는 초기 준비 기간으로 만약 초기 준비 기간을 준다면 해결 가능하다. 또한, 한 번씩 spike가 발생하는데 이는 polling 과정에서 이전 요청보다 현재 요청이 먼저 도착할 때 발생한다. 이를 위해 synchronization을 맞춰주기 위한 로직을 추가한다면 해결이 가능하다. 여기서는 sleep과 mutual exclusion을 이용하기를 권장한다.

> **2. Packet Loss**

정확하지는 않지만 받아들일 수 있을 정도의 오차밖에 발생하지 않는다.

> **3. Delay**

Control Plane에 기반하여 전송하는 방법과 VLAN을 기반으로 Data plane으로 전송하는 법 그리고 실제로 user가 체감하는 delay를 비교했을 때, Control Plane을 그대로 이용하는 경우에는 생각보다 큰 오차가 발생한다. 이는 Controller에서 Software Scheduling 과정에서 발생하는 에러이기에, VLAN을 기반으로 Data Plane을 이용하는 경우에는 실제 데이터와 비교해도 오차가 거의 없는 것을 볼 수 있다.

## Review

해당 논문은 OpenFlow가 나오고 이를 이용해서 Monitoring을 수행하고자 했던 여러 ISP와 연구자들에게 도움을 주었다고 생각한다. 이를 통해서 OpenFlow를 이용한 여러 Monitoring 방식이 연구되었던 것 같다. 그래서 Network 논문임에도 261건 정도의 인용수를 획득한 것으로 보인다. 또한, OpenFlow를 이용한 Monitoring 방식을 사용한다는 것이 흥미로웠고, 기존의 Monitoring 방식을 OpenFlow를 통해서 적용해보는 것이 당시 연구에서 중요했던 포인트였던 것으로 보인다. 새로운 기술에 기존 기술의 아이디어를 접목하는 것도 고려해서 논문을 작성하는 것도 좋은 방법이라고 생각된다. 또한, 구현이 Github로 open되어있기 때문에 신뢰도도 높았던 것으로 보인다. 만약 해당 부분을 좀 더 확인하고 싶다면 인용 논문을 좀 더 탐색해보는 것도 좋은 방법이 될 것 같다.

작성자가 Posting을 작성하는 날짜를 기준으로 261 번의 인용수를 자랑하는 논문을 리뷰한 것이다. 앞으로도 NOMS 논문 중에서 인용수가 많았던 논문들을 위주로 한 번 Review를 진행할 예정이다.

## Reference

- Niels L. M. van Adrichem, Christian Doerr, Fernando A.Kuipers, [`"OpenNetMon: Network Monitoring in OpenFlow Software-Defined Networks"`](https://ieeexplore.ieee.org/document/6838228), June 2014
- Thumbnail : Photo by [Tobias Tullius](https://unsplash.com/@tobiastu?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/@tobiastu?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)


OpenNetMon

## Intro

P4는 Programmable Switch, 즉 Hardware에 묶여있는 Software를 통해 DataPlane을 사용하는 것이 아닌 필요에 따라 Switch의 DataPlane을 직접 Programming하여 사용하는 새로운 방법론을 제시한다.

## History

예전 Posting에서 [🔗 OpenFlow](/posts/openflow)와 [🔗 SDN](/posts/sdn)에 대해서 다룬 적이 있다. 이때, P4에 대해서 간략히 알아보고 지나갔었는데, 해당 Posting에서는 이를 자세히 다룰 것이다. 만약, 이에 대한 개념이 잡혀있지 않다면, 해당 Posting을 이해하기 어렵다. 따라서, SDN과 OpenFlow 관련 Posting을 먼저 읽고 다시 돌아오기를 바란다.

먼저, P4의 초기 시작은 OpenFlow의 성장과 연관이 있다. OpenFlow는 기존의 Switch를 Data Plane과 Control Plane으로 나누어 Control Plane을 외부 Server(Controller)로 옮기고 이들은 OpenFlow Protocol을 통해서 Switch의 Data Palen을 제어하고자 했다. OpenFlow의 사용이 가속화되면서 계속해서 새로운 version이 update되었고, 1.0에서 1.5까지 도달하게 되었다. 그런데, 여러 Usecase와 Protocol을 지원하기 위해서 점점 비대해지는 Header를 마주치게 된다. 이는 통신 속도의 저하를 야기할 뿐만 아니라 기존의 유연한 시스템을 만들고자한 OpenFlow의 탄생 배경과도 거리가 있게 된다. 따라서, Data Plane을 필요에 따라 Protocol, Header, Algorithm을 포함하여 Programming으로 구현하여 사용하면 좋지 않을까라는 발상에서 시작된 것이 P4이다. 그렇기에 P4의 full name이 **Programming Protocol-independent Packet processors**인 것이다.

이렇게 시작된 Project는 점점 비대해지며, 원래는 Programmable Switch를 위한 언어를 목적으로 했다면 현재에는 여러 목적의 장비(target)을 지원하는 언어로 확장되었다. 따라서, P4를 한 문장으로 정의하라고 하면, **Programmable Target의 Data Plane을 Programming하는 언어**라고 할 수 있다.

## 동작원리

P4를 통한 Programming을 통해서 우리가 최종적으로 만드는 것은 두 가지이다. 첫번째로, `DataPlane runtime`은 Table과 Action 그리고 적절한 Alogrithm을 통해 실제로 Packet을 처리 및 Forwarding할 Software를 제작하고, Control Plane에서 Data Plane을 제어 및 설정을 하기 위한 API를 제작한다.

![p4-overview](/images/p4-overview.jpeg)

이를 위해서 Target을 제작하는 Vender는 다음과 같은 3가지를 제작한다.

1. P4 Architecture : 해당 Target에서 작동이 가능한 Interface와 extern object를 정의해놓은 명세서이다. 후에 P4 programmer는 이를 참고하여 해당 Interface에 해당하는 Package를 작성하면 된다.
2. P4 Compiler : Programmer가 작성한 Code를 Compile하여 API와 DataPlane Runtime을 생성한다.
3. Target(Hardware) : 실제로 동작하는 Hardware이다.

이제 P4 개발자(Programmer)는 P4 Architecture를 기반으로 하여 원하는 동작을 구현한다. 이를 Compiler를 통해서 실행시켜 정상동작 여부를 확인하여 최종적으로 동작하는 P4 Target을 완성할 수 있다.

이렇게 보았듯이 P4 Programming 과정은 Target 디자이너(Vender)에 의해서 만들어진 객체 지향 Architecture에 기반하여 Implementation을 수행하는 것이 핵심이다. 아마 객체 지향에 익숙하다면 굉장히 친숙한 개념일 것이다.

## 구성요소

P4 programming을 통해서 실제로 작성하거나 사용하는 구성요소들은 아래와 같다.

- **Architecture** : P4를 지원하는 지원하는 Switch의 구성요소들의 interface(객체지향에서의 interface)를 작성한 명세서로 이는 Programmer가 아닌 해당 Target을 제작한 Vender가 작성한다. 이를 기반으로 P4 Programmer는 Implementation을 수행한다.
- **Header Type** : 해당 Data Plane에서 사용할 각각의 Packet의 Header의 형태를 의미한다. 즉, Packet의 Header 부분을 정의한 것이다.
- **Parser** : 연속으로 들어오는 Packet에서 Header를 식별하고 추출하는 역할을 한다.
- **Table** : Programmer에 의해서 정의된 key와 이에 대응하는 Action이 저장된다. 이를 통해서, Routing Table, Flow Lookup Table, ACL 등과 같은 일반 Switch의 Table도 구성이 가능하며, 더 복잡한 형태의 새로운 Table을 구성하는 것도 가능하다.
- **Action** : Header와 Metadata에 특정한 조작을 가할 수 있다.
- **Match-action unit** : 실제로 Table을 조회하여, Action을 수행하는 Unit으로 동작순서는 다음과 같다.
  1. Packet의 field와 metadata를 활용하여 key를 생성한다.
  2. 생성한 key로 Table에서 조회(Lookup)한다.
  3. 조회된 key에 대응하는 action이 존재한다면, 이를 수행한다.
- **User-defined metadata** : Programmer(user)에 의해서 정의된 data 구조로 각 packet에서 추출이 가능하다.
- **Intrinsic metadata** : 기본적으로 정의된 data 구조로 각 packet에서 추출이 가능하다.
- **Extern object** : 일반적인 Programming Language에서 Library와 같은 역할을 하며, P4가 실행될 Hardware에서 제공하는 기능들이 여기에 포함된다. P4에서 이를 이용하여 Programming이 가능하지만, 이는 P4를 지원하는 Hardware Switch 제작자가 지정하는 것이기에 P4를 통한 구현은 불가능하다.
- **Deparser** : Packet의 Header와 Payload를 다시 결합하여 output port로 내보낼 Packet을 생성한다.
- **Control flow** : target의 packet 처리를 기술하는 필수적인 program 요소이다. Deparsing과 Match-action 등을 이를 통해서 기술할 수 있다.

## Example

가장 기본적인 Siwtch(Very Simple Switch, **VSS**)를 구현하며 P4의 programming 절차를 익혀보자. 아래 그림은 VSS를 분석한 그림이다.

![Very Simple Switch](/images/vss.jpeg)

### Flow

총 3가지의 Flow가 존재한다. 하나는 일반적인 데이터 Packet을 의미하며 Target의 **Physical Ethernet**을 통해서 들어온 packet이 이에 해당한다. 또 다른 하나의 Control Flow로 대게 SDN의 Controller를 통해서 들어온 Packet이다. 대게 이는 CPU를 통해서 전달되기 때문에 **From CPU**라고 표기한다. 마지막은 **Recirculate**인데 이는 동일 Target 내부에서 재처리를 위해서 다시 Arbiter로 전달된 Packet을 의미한다. 이는 한 번의 순환으로는 제대로 된 처리가 어려운 경우에 사용한다.

### Component

주황색 박스의 요소는 Hardware로 정의된 요소(Arbiter, Parser Runtime, Demux/Queue)를 의미하고, 검은 박스의 요소(Parser, Match-action Pipeline, Deparser)는 Software로 구현되는 요소를 의미한다. 각 요소를 먼저 알아보도록 하자.

1. **Arbiter**  
    한국어로는 중재자라는 뜻을 가지며, Input을 일차적으로 가공하는 Block(장치)으로 아래와 같은 기능을 수행한다.
    - 총 16개의 Port를 가지며, 3가지 종류의 Input을 입력받는다. (1)Physical Ethernet Input, (2)Control Flow(from CPU), (3)Recirculate Input을 받는다.
    - **Ethernet Input인 경우**, checksum을 추출하고 검증한다. 만약, 올바르지 않은 checksum이라면 packet이 버려지고, 올바르다면 packet의 payload에서 checksum을 추출하여 다음 단계로 전달한다.
    - 여러 packet을 동시에 수신한 경우에는 이를 scheduling하는 Algorithm을 실행시킨다.
    - Arbiter가 Busy 상태이고, 대기 queue가 꽉 찬 경우에는 도착한 packet을 Drop한다.
    - packet을 받은 port를 `inCtrl.inputPort`에 저장하여, Match-action Pipeline으로 전달하여 packet이 어디서부터 왔는지를 marking한다. 여기서는 Physical Ethernet port는 0 ~ 7번까지를 의미하고, 13은 recirculation port, 14는 CPU port를 의미한다.
2. **Parser**
   Packet을 가공하여 Input Header를 추출하고, user defined metadata를 생성하여 이를 Match-action Pipeline으로 전달한다.
3. **Parser Runtime**
   Parser와 협력을 하며 실행되는 장치이다. Parser에 정의된 action에 기반하여 Match-action Pipeline으로 error code를 Match-action Pipelien, packet payload에 대한 정보(payload 길이 등)를 Demux로 전달한다.
4. **Match-action Pipeline**
   Parser로 부터 전달받은 Input Header와 Parser Runtime으로 부터 받은 error, Arbiter를 통해 받은 `inCtrl.inputPort`를 기반으로 하여 key를 구성하고, 이를 통해서 Table을 조회하여 적절한 Action을 조회하여 실행한다. 이를 통해서 결론적으로 Output Header와 `outCtrl.outputPort`를 생성한다.
5. **Deparser**
   Deparser의 역할은 output Header를 다시 재조립하는 장치이다. 온전한 header 형태를 완성해서 Demux에서 Packet을 최종으로 생성할 수 있도록 돕는다.
6. **Demux/Queue**
   밖으로 전달할 packet의 header는 Deparser로부터, payload는 Parser로 부터 전달받아서 이를 재결합하여 새로운 packet을 생성하여 올바른 output port로 내보내는 역할을 하는 장치이다. output port는 Matc-action Pipeline의 `outCtrl.outputPort`를 통해서 전달된다. 세부적인 동작은 아래와 같다.
   - packet 삭제를 원하는 경우 drop port로 packet을 내보낸다.
   - Physical Ethernet으로 나가는 packet인 경우 해당하는 output interface로 전달한다. 만약, 해당 interface가 Busy 상태라면 Queue에 저장된다. output interface에서는 packet의 checksum을 계산하여 packet의 끝에 붙여서 내보낸다.
   - CPU를 통해서 전달하는 Control plane packet의 경우에는 Deparser에서 생성된 Header를 사용하지 않고, original packet 그대로만 전송할 수 있다.
   - `outCtrl.outputPort`가 올바르지 않다면, 해당 packet은 drop된다.
   - 만약, Demux가 Busy 상태이고, queue에 빈 공간이 존재하지 않는다면, `outCtrl.outputPort`를 무시하고 packet을 drop한다.

### Architecture.p4

아래는 위의 내용을 기반으로 Vender가 작성한 Architecture의 내용이다.

```c++
// File: "very_simple_switch_model.p4"
// Core Library로 packet_in과 packet_out을 사용하기 위해 필요하다.
#include <core.p4> 

// Port는 4bit로 표현 가능하다.
typedef bit<4> PortId;

// 4 width(bit)로 표현하는 8, 생략해서 8만 써도 무방
const PortId REAL_PORT_COUNT = 4w8; 

// Input packet에 동반되는 metadata로 Match-action Pipeline에서 사용된다.
struct InControl {
  PortId inputPort;
}

// Special Input Port
const PortId RECIRCULATE_IN_PORT = 0xD;
const PortId CPU_IN_PORT = 0xE;

// Match-action Pipeline에서 생성되는 Output packet에 동반되는 metadata
struct OutControl {
  PortId outputPort;
}

// Special Output Port
const PortId DROP_PORT = 0xF;
const PortId CPU_OUT_PORT = 0xE;
const PortId RECIRCULATE_OUT_PORT = 0xD;

// 공통으로 사용되는 H는 header로 programmer에 의해서 정의된다.

/**
 * Parse
 * @param b             input_packet
 * @param parsedHeaders headers contructed by parser
 */
parser Parser<H>(packet_in b, out H parsedHeaders);


/**
 * Match-action Pipeline
 * @param headers     Parser로 부터 받고, Deparser에게 보낸다.
 * @param parseError  parsing 도중에 생성된 error
 * @param inCtrl      packet을 받은 input port를 포함한 정보
 * @param outCtrl     packet을 보낼 output port를 포함한 정보
 */
control Pipe<H>(inout H headers, 
                in error parseError, 
                in InControl inCtrl, 
                out OutControl outCtrl);

/**
 * Deparser
 * @param outputHeaders programmer에 의해서 정의된 output header
 * @param b             밖으로 내보낼 packet
 */
control Deparser<H>(inout H outputHeaders, packet_out b);

/**
 * Top level Packet
 */
packege VSS<H>(parse<H> p, Pipe<H> map, Deparser<H> d);

/**
 * Extern block
 * 이는 Target vender가 내부적으로 구현한 block이다.
 * programmer는 아래 선언된 block을 자유롭게 사용가능하다.
 */
extern Checksum16 {
  Checksum16();
  void clear();
  void update<T>(in T data);
  void remove<T>(in T data);
  bit<16> get();
}
```

이렇게 작성된 architecture를 기반으로 하여 programmer는 코드 작성이 가능하다.

### Programming.p4

먼저 어떤 동작을 수행하게 할지를 정의하자.


1. Ethernet/IPv4 header를 활용하여 Forwarding을 수행할 것이다.
2. CheckSum을 확인하여 정당성 여부를 확인한다.
3. TTL 값을 확인하여 정당성 여부를 확인한다.
4. Destination IPv4를 활용하여 Next Hop의 IPv4를 찾는다.
5. 추출했던 Packet의 Header를 다시 Ethernet/IPv4로 재구성한다.

이를 코드로써 구현하면 아래와 같다.

```c++
// File: "very_simple_switch_impl.p4"
# include <core.p4>
# include "very_simple_switch_model.p4"

// 해당 program은 packet에서 IPv4와 
// ethernet header를 가져와
// destination IP에 기반하여 packet을 
// forwarding하는 것을 목적으로 한다.

typedef bit<48> EthernetAddress;
typedef bit<32> IPv4Address;

// Standard Ethernet header
header Ethernet_h {
  EthernetAddress dstAddr;
  EthernetAddress srcAddr;
  bit<16>         etherType;
}

// IPv4 header (without option)
header IPv4_h {
  bit<4>      version;
  bit<4>      ihl;
  bit<8>      diffserv;
  bit<16>     totalLen;
  bit<16>     identification;
  bit<3>      flags;
  bit<13>     fragOffset;
  bit<8>      ttl;
  bit<8>      protocol;
  bit<16>     hdrChecksum;
  IPv4Address srcAddr;
  IPv4Address dstAddr;
}

// packet에서 추출한 header형태의 구조체
struct Parsed_packet {
  Ethernet_h ethernet;
  IPv4_h     ip;
}

/* Parser Section */

// Programmer에 의해서 정의된 error로 
// parsing 도중에 이를 발생시킬 수 있다.
error {
  IPv4OptionsNotSupported,
  IPv4IncorrectVersion,
  IPv4ChecksumError
}

/**
 * @param b 들어오는 packet
 * @param p parsing해서 나갈 packet Header
 */
parser TopParser(packet_in b, out Parsed_packet p) {
  Checksum16() ck; // checksum block을 instantiating

  state start {
    b.extract(p.ethernet); // p의 ethernet 부분을 b에서 추출
    transition select(p.ethernet.etherType) {
      0x800: parse_ipv4; // forward packet to parse_ipv4
      // default rule이 없기 때문에 0x800(ethernet)을 
      // 제외한 packet을 모두 rejected 된다.
    } 
  }

  state parse_ipv4 {
    b.extract(p.ip);
    verify(p.ip.version == 4w4, error.IPv4IncorrectVersion);
    verify(p.ip.ihl == 4w5, error.IPv4OptionsNotSupported);
    ck.clear();
    ck.update(p.ip);
    verify(ck.get() == 16w0, error.IPv4ChecksumError);
    transition accept; // 다음 block으로 out을 forwarding
  }
}

/* Match-action Pipeline Section */

control TopPipe(inout Parsed_packet headers, 
                in error parseError,
                in InControl inCtrl,
                out OutControl outCtrl) {
  IPv4Address nextHop;

  action Drop_action() { outCtrl.outputPort = DROP_PORT; }

  action Set_nhop(IPv4Address ipv4_dest, PortId port) {
    nextHop = ipv4_dest;
    headers.ip.ttl = headers.ip.ttl - 1;
    outCtrl.outputPort = port;
  }

  table ipv4_match {
    // lpm : longest-prefix match
    key = { headers.ip.dstAddr: lpm; }
    // 해당 테이블에서 key에 대응할 수 있는 action의 list이다. 
    // 해당 table은 후에 controller에 의해서 채워진다.
    // 즉, 테이블은 p4 prgramming을 통해서 채우는 것은 아니다.
    actions = {
      Drop_action;
      Set_nhop;
    }
    size = 1024;
    default_action = Drop_action;
  }

  action Send_to_cpu() {
    outCtrl.outputPort = CPU_OUT_PORT;
  }

  table check_ttl {
    // exact : 정확히 일치하는지 여부를 확인
    key = { headers.ip.ttl: exact; }
    actions = { 
      Send_to_cpu;
      NoAction;
    }
    const default_action = NoAction;
  }

  action Set_dmac(EthernetAddress dmac) {
    headers.ethernet.dstAddr = dmac;
  }
  
  table dmac {
    key = { NextHop: exact; }
    actions = {
      Drop_action;
      Set_dmac;
    }
    size = 1024;
    default_action = Drop_action;
  }

  action Set_smac(EthernetAddress smac) {
    headers.ethernet.srcAddr = smac;
  }
  
  table smac {
    key = { outCtrl.outputPort: exact; }
    actions = {
      Drop_action;
      Set_smac;
    }
    size = 16;
    default_action = Drop_action;
  }

  apply {
    if (parseError != error.NoError) {
      Drop_actrion();
      return;
    }

    ipv4_match.apply();
    if (outCtrl.outputPort == DROP_PORT) return;

    check_ttl.apply();
    if (outCtrl.outputPort == CPU_OUT_PORT) return;

    dmac.apply();
    if (outCtrl.outputPort == DROP_PORT) return;

    smac.apply();
  }
}

/* Deparser Section */

control TopDeparser(inout Parsed_packet p, packet_out b) {
  Checksum16() ck;
  apply {
    b.emit(p.ethernet);
    if (p.ip.isValid()) {
      ck.clear();
      p.ip.hdrChecksum = 16w0;
      ck.update(p.ip);
      p.ip.hdrChecksum = ck.get();
    }
    b.emit(p.ip);
  }
}

// VSS packet를 Instantiate
VSS(TopParser(), TopPipe(), TopDeparser()) main;
```

여기까지가 기본적인 P4에 대한 설명이다. 후에 전반적인 문법과 작성법에 대한 가이드를 작성하도록 하겠다.

## Reference

- Thumbnail: [🔗 P4 공식홈페이지](https://p4.org)
- [P4 specification](https://p4.org/p4-spec/docs/P4-16-v1.2.2.pdf)


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


Open Flow