Network

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

Routing


## Intro

Overlay Network란 기존의 Network 위에 만들어진 가상의 Network를 의미한다. 그렇기에 물리적인 광통신 네트워크에 구성된 모든 네트워크를 Overlay Network라고 볼 수도 있지만, 일반적으로는 Public Internet 위에 구성된 가상의 Network라는 의미로 사용된다.

대표적인 예시로 P2P, VPN을 들 수 있다. 그 외에도 VLAN, MPLS 등도 들 수 있지만 Application 계층에서 구현한 P2P와 VPN을 해당 Posting에서 중점적으로 다룰 것이다. Overlay Network는 상위에 계층에 의해서 만들어지기 때문에 하위 계층에서는 해당 data를 분석하는 것은 사실상 불가능할 뿐만 아니라 이렇게 데이터의 크기가 더 커지기 때문에 네트워크의 과부하를 초래하기도 한다. 하지만, 이러한 기술은 구현이 하드웨어단에서 진행하는 것보다 간략할 뿐만 아니라 유연한 구성이 가능하기 때문에 여러 분야에서 활용되고 있다. 이로인해서 이러한 서비스를 구현하는 업체를 `Free Rider`라고 부르기도 한다. 통신 사업자 입장에서는 traffic 증가로 운영 비용이 증가하는데 비해 이에 대한 이득은 서비스 제공업체에서만 가져가는 현상때문이다.

## P2P

Peer To Peer의 약자로 여러 client 간의 통신을 수행할 때, 가장 기본적인 모델로 모든 Client가 서로 동등하게 연결되는 Network이다. 이는 `Client-Server` 구조와는 반대되는 개념으로, 하나의 Server로 모든 Client가 연결되어 이를 통해서 서로 정보를 주고 받는 구조와는 형태가 매우 다르다. 특히 파일 공유, 통신, VoIP, Instance Message, CDN과 같은 분야에서 많이 사용된다. 이는 P2P의 다음과 같은 **장점** 덕분이다.

1. Scalability : `Client-Server` 구조에서는 Client의 증가는 곧 Server의 부하 증가를 의미한다. 하지만, P2P에서는 노드 수의 증가는 전체 Network의 크기 증가를 의미하지만, 각 Node에게 부과되는 부하의 증가를 야기하지는 않는다.
2. Low Cost : Service 제공자 입장에서는 값비싼 Server를 유지하지 않아도 되기 때문에 이로 인한 비용적 이득을 볼 수 있다. 하지만, 통신 사업자 입장에서는 이것이 더 신경쓰이는 부분이다.
3. Availability : 일부 노드에 장애가 발생해도 전체 네트워크 연결에 미치는 영향은 적다.

하지만, P2P는 여러 인터넷 문제를 야기할 수도 있다. 대표적으로 제기되는 것이 다음과 같은 문제이다.

1. 과도한 인터넷 대역폭 소모  
   P2P에 참여하는 Node는 Bandwidth의 대부분을 P2P에 사용한다. 이를 통해서 P2P 전송의 효율을 최대화하고자 한 것이다. 하지만, 이로 인해 여타 다른 Network 장비들의 성능에 영향을 줄 수 있다.
2. 통제가 어려움  
   P2P를 통해서 공유되는 자료가 부정적인 컨텐츠(음란물, 불법 저작물 유통)를 포함하더라도 이를 통제할 수단이 없을 뿐만 아니라 과도한 Traffic에 대한 차단을 수행하려고 해도 P2P port를 주기적으로 바꾸거나 VPN 등을 활용하며 이러한 차단마저도 우회하고있다.
3. 낮은 보안성  
   P2P software는 각 client에서 동작하며, 각 Client는 Host의 기능도 수행해야 하는데 이에 대한 책음은 원래 Service 제공자에서 Client로 전과되었으며, 이는 Client에서 직접적으로 방어해야 한다. 그렇기에 보안성이 낮고 악성코드에 무방비하다.

2000년대 중반까지만 해도 이러한 P2P Traffic이 전체 인터넷의 60~80%를 차지하여 큰 문제가 되었지만, 현재에는 2.4%로 감소하였다. 이는 Streaming Platform의 성장이 컸다고 보고 있다. 다음은 대표적인 P2P Service에 대한 예시이다.

> **Napster**

최초의 P2P service로 유명하며, 무료 음원 MP3 파일을 공유하는 서비스를 제공하였다. `Login Server`만을 유지하고, 이곳에서 각 node의 MP3 file 정보와 user 정보를 mapping하여 관리하고 이들을 통해서 조회를 수행하면 Download는 P2P에 의해서 수행되는 원리이다. 그런데 이 단계에서 문제가 발생할 수 있다. 바로 Client 간의 P2P를 수행할 때에 NAT로 인해서 실제 Client의 주소를 알아내는 것이 어려울 뿐만 아니라 방화벽에 의해서 막힐 수 있기 때문이다. 이를 해결하기 위해서 `STUN`이라는 개념을 활용한다. 여기서는 자세히 다루지 않지만 NAT에 의해서 만들어진 Public Address와 Private Address를 저장하여 이를 저장하고 있다가 NAT 내부에 Node를 식별할 수 있도록 돕는 기술로 별도의 Server를 구성하여 해당 장소에 저장해두는 것이 일반적이다. 또한, file을 갖고 있는 Node에서 방화벽이 존재한다면, 이를 우회하기 위해서  외부 Server가 file을 보유한 Node에서 오히려 요청을 보내고 파일을 전송하는 것처럼 우회를 수행하기도 한다.

> **Torrent**

BitTorrent와 uTorrent에 대해서만 알아볼 것이다. BitTorrent는 가장 초기 버전으로 OpenSource로 공개되었고, version 6인 uTorrent부터는 비공개로 개발되었다. 32, 64, 128, 256 KB 단위로 file을 나누고 조각 단위로 전송하는 방식이다. Torrent Network를 구성하는 요소는 다음과 같다.

- Web Server : Torrent는 별도의 File 공유 Web Service를 제공하지 않기 때문에 사용자들은 자신이 파일을 가지고 있음을 `X.torrent` 라는 file에 담아서 Web Service에 업로드해야 한다. 이를 다운로드하여 Torrent Application을 실행시키면 file download가 진행되는 것이다.
- Tracker : Torrent에서 제공하는 Server이다. P2P에서 각 peer들의 상태정보를 수집하고, 이를 통해서 통신을 중계한다.
- Seed : 완전한 파일을 가지고 있는 Peer
- Leech : 해당 파일을 일부 가지고 있는 Peer
- Downloader : Leech와 같은 의미로 사용되기도 하며, 다운로드가 완료되면 Leech 또는 Seed가 된다.

Downloader가 Download를 `X.torrent` file을 기반으로 수행하기를 Tracker에게 요청하면, Tracker는 해당 파일을 소유한 Peer List를 반환하고 이를 통해서 각 Peer로 부터 파일 조각을 다운 받아 결합하여 최종 file을 완성한다는 원리에 기반하고 있다. uTorrent는 기존 TCP에서 UDP로의 변경 뿐만 아니라 STUN 기능 등을 포함하여 성능을 향상시켜 출시되었다.

> **Skype**

VoIP를 기반으로 하여 파일 전송 등을 제공하는 P2P 서비스이다. 2003년에 처음 시작되어 현재는 MicroSoft에 인수되었고, 2012년 이후로는 `Client-Server` 구조로 전환하였다. 시스템을 구성하는 요소는 다음과 같다.

- Login Server : 회원가입 및 사용자 정보를 저장하는 Server로 Skype에 의해서 관리된다.
- SN(Super Node) : 실제 Skype Client가 연결되는 Node로 이들은 각자 연결되어 각 Client에게 통신을 제공한다. 초기에는 항상 켜져 있고, 공인 IP 주소를 가지고 있는 고성능 고대역 장비이면 어떤 Skype Client도 Super Node가 될 수 있었다. 하지만, 2012년 대규모 장애가 발생한 이후 MicroSoft에서 운용하는 Machine(Azure)으로 대체되었다.
- SC(Skype Client) : 일반 Skepe 이용자를 의미한다.

Skype의 Code가 공개되지 않았기 때문에 자세히 알 수 없지만 다음과 같이 추측은 가능하다. Login Server를 거쳐서 Login을 수행하며, 이 과정에서 적절한 Super Node를 통해서 먼저 연결 상태 체크 등을 수행한다. 이제 사용자가 통화를 시작한다면, 해당 Super Node를 기반으로 UDP 음성 packet이 오고 갈 것이다.

### STUN

Session Traversal Utilities for NAT 의 약어로 UDP hole punching이라고도 부른다. Network Address Translation으로 번역되는 내부망의 node의 Private Address를 Public Address와 Mapping하여 관리한다. 원래는 NAT 내부에 존재하는 Node를 식별할 수 없지만, 이를 통해서 NAT 내부에 존재하는 대상에게 Request를 보내는 것이 가능해지는 것이다. 이와 유사한 개념으로 TURN이 존재하는데 이는 직접적으로 Traffic을 전달받아서 중계를 수행하는 역할을 맡는다.

## VPN

Virtual Private Network의 약어로 90년대 말에 기업의 사설망 구축 시에 사용되던 기술이 공용화된 것이다. 이는 OSI 7계층에서 2 계층 이상에서 적용이 가능하며, 어느 계층에서 수행하냐에 따라 목적이 조금씩 다르지만, packet을 Encapsulation하여 도청, 감청, 탈취 등의 작업을 수행할 수 없도록 막는 것이 주 목적이다. 이를 통해서 개인정보를 암호화하고, 인터넷을 사용하는 것이 가능하다. 통신 사업자에 의해서 구성된 VPN이 아닌 경우 대역폭이 보장되지는 않는다. IPSec에서 부터 시작하여, SSL과 같은 기술이 이에 포함되고, 우리가 일반적으로 생각하는 VPN은 응용 계층에서의 활용이다. 이 경우에는 Proxy Server를 먼저 거쳐서 Traffic 자체를 우회시키는 방식이다.

## Reference

- Thumbnail : Photo by [Mark McGregor](https://unsplash.com/@mmcgregor?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/peer?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)


Overlay Network


## Intro

광통신은 빛에 데이터를 저장하여 광섬유를 통해서 데이터를 보내는 방식이다. 그렇다면, 굳이 왜 빛으로 변환하는 과정을 거치면서 까지 광통신을 사용하고자 하는지를 알필요가 있다. **이는 간단하게 빠르고, 멀리 전달할 수 있기 때문이다.** 그리고, 전자파를 이용하는 무선통신과 다르게 빛은 4가지의 특징을 가지기 때문이다(반사, 굴절, 간섭, 편광). 광섬유 내부에서는 여러 원인에 의해서 상쇄(손실)가 발생하기 때문에 이를 증폭해줄 방법이 필요하며, 광섬유를 어떻게 구성할지에서부터 처음에 데이터를 어떻게 빛으로 변환할지에 대한 방법과 받은 빛을 다시 데이터로 변환하는 방법이 굉장히 중요하다.

---

![광통신](/images/optical-transfer.jpeg)

따라서, 이를 위한 기술과 장비들을 먼저 살펴보고 갈 것이다.

### 광섬유

실제로 빛이 이동하는 통로 역할을 수행한다. 주요 구성요소는 보호용 아크릴, cladding, core이다. 빛은 실제로는 core 내부에서만 이동한다. 내부에서 빛은 지그재그로 이동하며 계속해서 cladding과 접하지만 빛의 굴절률을 이용하여 전반사 시키도록 설계를 해두어 core로만 빛이 통하게 된다. 이때, 이러한 빛의 이동 경로를 하나의 mode라고 하고, 이는 처음 빛의 입사각에 따라 달라진다. 이러한 mode를 여러 개 허용한다면, 이는 multi mode fiber(MMF)라고 하고, 하나만 허용한다면 single mode fiber(SMF)라고 한다. 일반적으로는 SMF가 더 고효율 시스템을 활용하기 때문에 전송 효율은 높지만 비용적인 측면에서 MMF도 자주 사용된다.

![광섬유](/images/optical-fiber.jpeg)

#### 광섬유 손실

광섬유는 다음과 같은 이유에 의해서 빛을 손실한다.

1. 결합 손실(Coupling Loss) : 초기에 Lasor 장치와 광섬유의 core 사이에서 발생하는 손실
2. 흡수 손실 : 광섬유 제작 과정에서 core에 섞인 어쩔 수 없는 불순물에 의한 손실
3. 산란손실(Scattering Loss) : 광섬유의 core에서의 비균질성에 의해서 굴절률이 순간적으로 변하여 발생하는 손실
4. 구부러짐에 의한 복사 손실(Bending Loss) : 광섬유의 일부 구부러짐에 의하여 굴절률이 영향을 받아 발생하는 손실
5. 접속 손실(Joint Loss) : 광섬유간의 결합 과정에서 발생하는 손실

#### 손실 보상(Dispersion Compensation)

광섬유 내에서 손실을 보상하기 위해서 사용되는 대표적인 방법이 4가지가 있다.

1. DCF(Dispersion Compensation Fiber)를 이용한다. 이는 빛의 파장을 더 길게 변화시키는데 이를 이용하여 중간에 증폭을 가하는 것이다. 이를 이용할 때에는 SMF로 광섬유로 채택하고, 먼저 진행한 후에 해당 길이의 19%만큼을 DCF로 통과시켜서 손실된 양만큼을 보충해주고, 다시 SMF로 진행시키는 것이다. 마치 빛을 오목 렌즈(SMF)로 퍼트리면, 다시 볼록 렌즈(DCF)로 모아주는 것과 유사하다.
2. EDF(Erbium Doped Fiber), PDF(Pr Droped Fiber) 등을 활용한다. 이는 자체적으로 광을 증폭하는 효과를 갖고 있기 때문에 이를 중간에 통과 시켜서 증폭을 수행한다. 이 방식이 더 짧은 길이의 Fiber로 증폭이 가능하다.
3. 중계기를 활용한다. 중간에서 빛을 다시 전기로 바꾼 후에 이를 다시 광으로 증폭하여 전달하는 방식이다. 이 방식은 편리하지만, 전기가 필요하며, 처리 과정에서의 지연이 크다는 단점이 있다.
4. 증폭기를 활용한다. 광섬유 내 모든 신호를 증폭 시킨다. Noise도 같이 증폭될 수 있다는 단점이 있지만, 빠르기에 많이 사용된다. 대표적인 증폭의 방법은 다음과 같다.
   - EDFA : EDF를 이용한 증폭 방법이다. 원리는 전달되는 빛에 약한 광신호를 섞어서 증폭시키는 것이다. 단점은 C, L band만을 커버할 수 있기 때문에 더 넓은 범위에 대해서는 제한적이다.
   - Raman 증폭 : 빛의 산란효과를 활용하여 특정 주파수 영역의 빛을 증폭시키는 기능을 한다. 더 넓은 범위를 커버할 수 있고, EDFA보다 덜 빈번하게 설치하여도 무방하다.

### Tranceiver

광송수신기를 의미한다. 대게 광송신을 담당하는 TOSA와 광수신을 담당하는 ROSA를 모두 포함하여 만든 장치로 실제 Switch/Router에서 광케이블(광섬유)이 연결되는 interface 역할을 한다. 해당 기술은 소형화와 저전력화가 핵심이고 현재에는 하나의 Switch/Router에 32개 이상 포함할 수 있을 정도로 소형화/저전력화가 진행되었다.

#### Tranceiver 내부의 변조 기술

> **광변조기술**

기본적으로 데이터를 빛으로 바꾸고자 할 때에는 기존 데이터의 주파수를 그대로 이용(BaseBand)하기 보다는 고주파 대역과 결합하여 해당 고주파 대역(BroadBand)으로 변환하여 보낸다. 이를 수행하면 장거리 통신에 유리하며, 안테나의 길이를 단축할 수 있을 뿐만 아니라 Noise를 개선하기에 유리하다는 장점을 갖고 있다. 이를 기반으로 하여 총 2가지 형태의 변조 기술이 존재한다.

- 직접 변조(Direct Modulation) : 데이터의 0과 1에 따라 광원을 키고 끄고를 수행하도록 하는 방식
- 외부 변조(External Modulation) : 광원은 계속 켜둔 상태에서 데이터의 0과 1에 따라 빛을 막았다가 통과시켰다를 제어하는 방식

> **신호변조기술**

data를 신호로 변환하는 기술이다. 대표적인 방식은 4가지가 존재한다.

1. ASK(Amplitude Shift Keying) : 디지털 신호에 고주파 신호를 결합하여 변환 신호를 만드는 방법으로 두 개의 transiter로도 만들 수 잇을 정도로 매우 간단하나 잡음에는 취약하다.
2. FSK(Frequency Shift Keying) : 디지털 신호에 따라 고주파 신호의 주파수를 변환하여 신호를 보내는 기술로 간단하면서도 잡음에 강하지만, 많은 주파수 대역을 필요로 한다.
3. PSK(Phase Shift Keying) : 디지털 신호에 따라 고주파 신호의 위상을 역전시켜 변환하여 신호를 보내는 기술로 간단하고 잡음에 강하지만 수신측에 부가적인 위상 추적 장비가 필요하다.
4. QPSK(Quadrature PSK) : 위상을 더 세분화하여 4단계로 나누어 신호를 보내는 PSK 방식이다. 기존의 PSK보다 전송 효율이 높아진다.
5. QAM(Quadrature Amplitude Modulation) : ASK와 PSK를 조합한 방식으로 ASK와 PSK를 별도로 수행하고 이에 의해서 생성된 신호를 합쳐서 전송하는 방식이다. 나타나는 위상의 수에 따라서 4-QAM, 8-QAM, 16-QAM, 32-QAM 등으로 나뉜다. 참고로 4-QAM은 사실상 QPSK와 동일하다.

## 광통신망

광 케이블로 구성된 물리 네트워크이다. 크게 3가지 Network로 구성되어진다. 일반적으로는 각 Network가 Ring Topology로 구성된다. 이는 장애에 대비하기 위함이다. OTN이라고도 부르며 중간 Router에서의 변환을 최소화하고 광통신으로 직접적으로 연결하는 하위 네트워크를 구성하는 것이다.

초기에는 SONET/SDH라는 형태가 있었다. 이는 Synchronous Optical Network / Synchronous Digital Hierarchy의 약자로 거의 비슷한 두 기술을 붙여 부르는 말이다. 사실상 표준을 발행한 기관이 미국이냐 국제기관이냐의 차이이다(그래서 세부 용어들은 내부적으로 다르다). TDM으로 다중화 전송을 수행하였고, 이후에는 통계적 다중화라는 TDM의 고정 시간분할을 유동적으로 바꾼 방식이 등장하지만 여기서는 사용되어지지 않았다. 원래는 음성 통신에 초점을 맞추었기 때문에 장애 시 사람이 인식하지 못하는 ~50ms 이내에 자동 절체를 수행하는 작업도 최초 도입되었다. 이로인해 음성 통신에서는 우수한 성능을 보였지만 인터넷 트래픽에서는 위에서 말한 통계적 다중화를 지원하지 않아 대역폭 낭비가 심했다. 이에 따라 아래와 같은 형태의 Network로 구성된 형태로 변화하게 되었다.

1. ROADM : Reconfigurable Optical Add-Drop Multiplexer의 약자로 특정 파장을 Drop하거나 Add하는 장치인 OADM을 발전시킨 장치이다. 원래는 설정을 변경하는 것이 숙력된 기술자들에 의해 하드웨어적으로 가능했는데 이를 원격으로 제어하는 기술을 적용한 것이 ROADM이다. 이는 Backborn에서 광파장을 분리하고 분석해서 적절하게 Routing하는데 사용된다.
2. MSPP : Multi Service Provisioning Platform의 약자로 SONET/SDH와 ATM, Ethernet을 동시에 지원하는 Module로 여러 Platform의 Interface로 기능한다.
3. PON : Passive Optical Network 의 약자로 하나의 광통신 지원장치(OLT, Optical Line Terminator)를 통해서 모든 빛을 하나의 Fiber로 합하여 여러 장치들에게 광통신을 지원하는 형태의 Network로 대게 광통신의 End 지점에서 많이 사용되는 Network이다.
   - TDM-PON : Time Division Mulitplexing의 약저로 수신 시에 OLT를 이용하여 광케이블로 온 빛을 직렬화하고, Splitter를 통해서 네트워크에 Broadcasting하는 방식이다. 송신 시에는 시분할을 통해서 각 장비에서 오는 광 데이터를 전송한다.
   - CWDM-PON : Coarse Wavelength Division Multiplexing 의 약자로 수신 시에 채널을 최대 18개까지로 나누어 각 채널을 통해서 통신을 수행하도록 하는 방식이다. 이때, RN이라는 장치가 Prizm처럼 빛을 분산시키는 역할을 한다.
   - DWDM-PON : 각 광가입자마다 별도의 고유 파장을 부여하는 방식이다. 방식은 CWDM과 매우 유사하다.
   - NG-PON2 : TDM과 WDM을 결합하여 하는 방식이다.

## Reference

- Thumbnail : Photo by [Compare Fibre](https://unsplash.com/@comparefibre?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/optical-network?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)


광통신망


## Intro

Network는 여러가지 종류가 존재한다. 일반적인 LAN을 제외한 Network의 대표적인 종류(BackBorn, Internet, Datacenter, 등)를 알아본다.

## BackBorn Network

BackBorn은 등뼈, 중추를 의미한다. 즉, 네트워크의 중추라는 것이다. 해당 네트워크는 각 Node와 Node를 직접적으로 연결하기 보다는 이미 구성되어있는 LAN 간의 연결을 수행하는 네트워크이다. 작은 범위에서는 특정 건물 내에서의 LAN간을 연결하는 Network를 의미하기도 하지만 대게의 경우 LAN과 Internet을 연결하는 Internet BackBorn Network를 의미한다. 이러한 BackBorn Network는 앞 서 살펴본 LAN과의 연결 뿐만 아니라 대게 4가지의 역할을 할 수 있어야 한다.

1. 서비스 서버 및 국내 외 타 사업자 연결
2. 고가용도 스위치 및 라우터를 사용하며, 이중화를 구성
3. 타 통신사업자와의 연동을 위한 IX(Inter Exchange)를 구성
4. 데이터센터와 연결되는 Switch를 제공

우리가 Ethernet을 통해서 공유기에 packet을 전달하면, 공유기는 건물 내 Switch로 연결되고, 이것이 BackBorn Network로 packet을 보내면 BackBorn에서 이를 올바른 Network로 다시 옮기는 역할을 수행한다.

대게 이와 같은 일은 통신사업자(국내에는 KT, SKT, LG)가 수행하고 있다. 물론 접속하고자 하는 사이트가 해외에 위치하는 경우 해외 통신사업자의 BackBorn으로 넘어가서 해당 Network를 찾게 되는 것이다. 따라서, 이를 그림으로 나타내면 아래와 같다.

![backborn network](/images/backborn-network.jpeg)

### Topology in Backborn Network

이러한 BackBorn Network를 구성할 때에 주로 사용되는 것은 Star topology이다. 이는 Star topology는 하나 이상의 중심 node로 traffic이 몰리게 되는데 이러한 구조는 관리 및 요금 측정 등과 같은 과정을 쉽게 처리하는 것이 가능하기 때문이다. 하지만, 중심으로 traffic이 집중되는 만큼 재난 발생에 취약할 수 있고, 이로 인한 지연으로 인해 전송 효율이 감소할 수도 있다.

미국의 통신사업자 AT&T는 Mesh Topology를 활용하는데 이는 중앙에 모든 Traffic이 집중되지 않기 때문에 가용성이 높고, 국제적인 Traffic이 많고, 이로 인한 traffic이 많기에 토지가 큰 미국의 특성을 이용해 다른 지역에서 사용하지 않는 장비를 우회해서 traffic을 처리할 수 있다는 장점이 있다. 하지만, 유지 관리 과정이 다소 난해하고 이로 인한 비용이 Star Topology보다 크다고 할 수 있다.

## Internet

Internet은 서로 다른 Network를 연결하는 또 하나의 Network이다. 대게 필연적으로 Internet 통신이라고 하면, BackBorn을 거쳐서 통신하는 것을 Internet이라고 하는 경향이 있다.

### 이동통신

부가적으로 대게의 통신 사업자는 국내 지역에 기지국(Base Station, 대게 전봇대에 설치된 경우가 많다.)을 통해 이동 통신 종량제 네트워크 서비스를 제공한다. 이 역시 BackBorn Network와 연결되어 각종 서비스를 제공한다.

### 이중화

BackBorn Network의 가장 중요한 특징 중 하나가 고가용성을 제공해야 한다는 것이다. 즉, 끊기지 않는 Network를 지향한다는 것이다. 이를 위해서 망 자체를 이중화하고, BackBorn과 연결되는 Router에서의 Link 사용률을 40%로 제한함으로써 일부 장애시에도 문제가 발생하지 않도록 하는 것이다. 또한 Star Topology의 경우 Core Router로 향하는 Link를 삼중화하여 특정 Link에 에러가 발생하여도 최대한 통신이 가능하게 하고자 노력하고 있다.

## Datacenter Network

Datacenter는 Service를 제공하는 업체들에서 다양한 Application을 제공하기 위해서 여러 machine을 모아두고 저장해놓은 기관이다. 이러한 Datacenter Network의 규모가 Backborn Network의 규모를 넘어서고 있는 시점에서 중요성이 더 커지고 있다.

### Term

- Rack : 수 많은 machine을 효율적으로 저장하기 위해서 층별로 machine을 저장하여 보관하는 수납 공간 또는 수납된 모든 machine을 의미한다.
- ToR Switch : Top of Rack Switch의 약어로 Rack의 machine에게 Network를 제공하기 위해서 Rack의 최상단에 존재하는 Switch를 말한다.

### Topology in Datacenter Network

- Tree : 매우 직관적인 구조의 Topology이다. 각 ToR Switch가 더 상위 Switch인 Access(=Edge) Switch에 연결되고, 해당 Access Switch가 Aggregation Switch/Router로 연결되고, 최종에는 Core Router에 연결되어 해당 Core Router를 통해서 Internet에 연결되는 형태를 가지고 있다. 이와 같은 경우 3가지 큰 특징을 가진다.
  - 특징
    - Over Subscription : 상위 Switch/Router/Link의 bandwidth가 하위 Switch/Router의 bandwidth보다 크도록 설계하는 것
    - Same Distance with Core : Core와의 거리가 모든 rack에서 동일하기 때문에 효율적인 Networking이 가능하다. 이러한 Traffic을 North-South Traffic이라고 한다.
    - No Loop : Tree 구조 자체가 Loop가 없는 형태이기 때문에 Loop로 인한 Traffic 혼잡을 막을 수 있다. 만약, East-West Traffic을 위해서 link를 중간에 증설하였다면, 이를 해결하기 위하여 Spanning Tree Protocol을 활용하여, Loop를 없애기 위한 설정을 한다.
  - 단점
    - East-West Traffic의 낮은 효율 : 좌우 Traffic이 빈번하게 발생한다면, 이로 인한 비효율이 크게 발생할 수 있다. Virtual Machine이 굉장히 많이 사용되고 있는 상황에서 어느 Physical Machine에 Virtual Machine이 존재하더라도 동일한 IP를 유지한다거나 동일한 수준의 가상화를 제공하기 위해서 이러한 East-West Traffic이 많아지고 있다(80% 이상을 차지하고 있다). 따라서, 현재에 사용이 많이 줄었다.
    - 확장이 어려움 : 상위 계층이 하위 계층의 BandWidth에 의존하기 때문에 초과량을 넘은 경우 확장이 모든 구간에서 수행되어야 한다.
- Spine-Leaf(=Clos, Leaf-Spine) : 상위 Spine Switch/Router에 모든 하위 Leaf Switch/Router가 연결되어 있고, 이 Leaf Switch/Router에 ToR Switch가 연결되어 있는 구조이다. 이러한 구성을 갖추게 되면, East-West Traffic의 처리가 매우 용이하다.
- Fat-tree : Tree의 Edge/Aggregation Switch/Router의 수를 k개로 Group을 만들고, 해당 Group을 k개 만들어서 여러 개의 Core를 두어 구성하는 형태이다. 마찬가지로 East-West Traffic의 처리 역시 매우 용이하다.

## Edge Computing Network

통신 사업자 입장에서 가입자와 인접한 전화국에 서버 pool(소규모 datacenter)을 구축하고, 이를 통해서 보안 또는 요금 측정 등과 같은 Network 기능을 구현하고자 하는 네트워크를 구축하고 있다.

## Optical Transport Network(광통신망)

광케이블을 이용하여 구축한 Physical Network로 고속 통신을 지원하기 위해서 고안되었다. 이는 후에 Posting에서 자세히 다룰 예정이다.

[🔗 광통신망](/posts/optical-transport-network)

## Digital Subscriber Line(DSL)

ADSL부터 시작되어 여러가지 형태로 변화되어온 Network 형태이다. 종류는 다양하게 ADSL/HDSL/SDSL/RADSL/VDSL 등으로 존재한다.

ADSL은 Asymmetric Digital Subscriber Line의 약자로 전화선을 이용한 통신 방식이다. 1988년 미국에서 최초 개발되었고, 현재에도 저가형 인터넷 서비스에 사용 중이다. 또한, VDSL은 주파수 대역을 확장하여 속도 향상을 꾀하였다.

## Reference

- Thumbnail: Photo by [Markus Spiske](https://unsplash.com/@markusspiske?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/internet?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)

인터넷이 처음 세상에 등장한 이래로 다양한 종류의 네트워크 구조가 만들어졌다. 작게는 우리가 사용하는 Wifi를 구성하는 LAN 영역에서 부터 전체 세상을 연결하는 Internet와 같은 광범위한 네트워크가 존재한다.


Network의 종류


## Intro

SDN의 본격적인 시작이 OpenFlow라고 보아도 무방하다. OpenFlow는 2007년 Stanford 대학에서 개발이 시작되었고, 지금도 de facto standard(사실상의 표준)으로 받아들여지고 있는 Protocol이다. 해당 Protocol의 핵심은 기존 Switch/Router를 data plane(데이터 평면)과 control plane(제어 평면)으로 나누고, 제어 평면을 OpenFlow Protocol에 따르는 Controler로 대체하면서, OpenFlow Protocol을 따르는 Switch는 data plane만을 포함하여, 둘 간의 통신을 통해서 제어 평면을 구성하자는 것이다. 여기서 데이터 평면은 실제로 interface로 packet이 들어오고, 내보내는 역할을 하는 계층이라고 보면 되고, 제어 평면은 packet에 어떤 동작을 수행시킬지 그리고 어느 interface로 내보낼지를 결정하는 역할을 하는 계층이라고 보면 된다. 이러한 구성을 통해서, 결국 SDN을 구축할 수 있는 토대를 제공하게 된 것이다.

## OpenFlow Switch

OpenFlow Switch는 다음과 같은 형태로 구성되어진다.

![OpenFlow Switch](/images/openflow-switch.jpeg)

## OpenFlow Protocol

해당 사항은 reference에 기반한 version 1.3.1의 기능을 요약한 내용이다.

기본적으로 OpenFlow Protocol을 지원하는 Switch의 구조부터 알아보아야 한다. Switch는 기본적으로 외부와 연결이 가능한 Port, Routing을 위한 여러 개의 Table, 그리고 Controller와의 의사소통을 위한 Channel을 가진다. 각 요소의 역할을 간략히 하나하나 알아보도록 하자.

> **1. Port**

OpenFlow에서 packet이 Switch로 왔다갔다하는 통로라고 볼 수 있다. 대게 Switch를 가르키거나 packet의 진입 위치를 식별할 때 사용된다. 이는 실제로 존재하는 것이 아닌 추상화된 개념으로, 총 3가지의 Port를 통해서 Switch를 가르킬 수 있다. 각 Switch는 여러 개의 Port를 가지고 이를 통해서 다른 Switch들과도 연결되어진다.

- Physical Port : 실제 Switch의 interface와 일대일로 대응되는 가상 Port이다. 즉, 해당 interface로 packet이 들어왔다면, OpenFlow에서는 이와 대응되는 port로 packet이 들어왔다고 판단한다.
- Logical Port : OpenFlow를 쓰지 않고, Switch 자체적으로 정의한 Tunnel과 Loopback과 같은 가상 Port이다.
- Reserved Port : OpenFlow Protocol에 의해서 정의된 Port이다. 이를 통해서, Controller, All, Table의 맨 처음, IN_PORT 등을 쉽게 가르킬 수 있다.

> **2. Table**

Switch는 여러 개의 Table을 가지고 있다. Table을 통해서 Switch는 Routing을 수행하는 것은 기본적인 Switch의 동작과 동일하다. Switch의 특정 Port로 packet이 들어왔을 때, packet의 목적지와 진입한 Port, 그 외에 metadata에 기반하여 matching을 수행하여 일치하는 대상을 찾아서, 해당 Table에 기술된 동작을 수행하는 것이다. 대게 무슨 동작을 수행할 것인가에 따라서 종류가 나뉘어지며, v1.3.1에는 총 3가지의 종류가 존재한다.

1. Flow Table : 대게 어떻게 Packet을 어느 Port로 Routing할 것인가를 다룬다. 뿐만 아니라 Packet의 Header를 변경하거나 MPLS Label과 같은 추가 정보를 더하는 등의 동작을 수행할 수 있다. (각 Switch는 하나 이상의 Flow Table을 소유한다.)
2. Group Table : 패턴과 일치하는 packet에 대해서 여러 동작을 수행하게 하거나 상황에 따라 다르게 적용하도록 하기 위해서 사용할 수 있다. (각 Switch는 1개 이하의 Group Table을 소유한다.)
3. Meter Table : packet의 빈도(rate) 조절과 측정을 수행할 수 있다. (Meter Table은 Controller에 의해서 관리된다.)

> **3. OpenFlow Channel**

OpenFlow Switch 내부에서 Controller를 연결하는 Interface로 Switch의 상태를 Controller에게 알리거나 Controller로 부터 변경사항을 전달 받기 위한 통신 채널이다.

---

이렇게 이루어진 OpenFlow Switch들은 서로 연결되어 있으며, 하나 또는 여러 Controller와 각 각 연결되어 있다. Controller는 각 OpenFlow Switch로 부터 상태 정보와 인접 Switch 정보 등을 전달받아서 내부적으로 Flow Table을 구축한다. 그리고, Controller에서 중앙 통제를 통해서 전체 네트워크를 관리할 수 있는 것이다. 이를 수행할 때에는 Controller에서 각 Switch의 Table을 지정함으로써 구현이 가능하다. 그렇다면, Switch에 Table을 설치하였을 때, 어떻게 Packet을 처리하는지에 대해서 알아보자.

### Pipeline

Switch 내부에는 여러 개의 Table이 존재하는데, Packet이 Switch의 특정 Port로 들어오면, 먼저 Flow Table을 거치게 된다. Switch 내부의 여러 Flow Table 중에서 index($\ge 0$)가 작은 값부터 시작하여 Flow Table에서 일치하는 pattern의 Flow Entry를 찾게 된다(Flow Table의 하나의 열). 해당 Entry에 적힌 `Instruction`에 따라 `Action`을 바로 수행하거나 `Action Set`에 추가한 후에 다음 Table 또는 Port를 통해서 다음 Switch로 이동하게 된다. 이때 Port 밖으로 나가기 이전에 Action Set에 모아둔 Action을 한 번에 수행한다.  
만약, Flow Table의 어떤 pattern과도 일치하지 않는다면, 이를 `Table Miss`라고 하고, 미리 지정해둔 miss flow entry에 따라 Action을 수행한다. 아무 설정도 하지 않았다면 default로 해당 packet을 drop한다.

그렇다면, 각 Table을 구성하는 요소(entry)들이 어떻게 구성되는지를 확인해보자.

> **1. Flow Entry**

- Match Field : 일치하는 Packet을 찾기 위하여 Ingress Port / Egress Port / Packet Header / 다른 Table에서 생성된  Metadata 등을 사용한다.
- Priority : 일치하는 대상이 많을 경우, 높을 수록 조회 시에 우선시 되어진다.
- Counters : match가 수행된 횟수를 마킹한다.
- Instructions : packet에 대해서 특정 Action을 수행시키거나 Action Set을 변경한다.
- Timeout : 최대 처리 시간 또는 남은 시간 등을 표시한다.
- Cookie : Controller에 의해 설정된 데이터로 대게 해쉬 / 암호화 되어진다. 이는 Controller에서 Flow 관측 및 조절 시에 사용한다.

> **2. Group Entry**

- Group Identifier : Group 식별자
- Action Buckets : 여러 개의 action과 이에 해당하는 parameter를 담은 bucket들을 정렬 후 보관
- Group Type : Group의 동장 방식을 선택
  - all :  모든 bucket을 실행
  - select : bucket을 번갈아가면서 실행하여 Load Balancing을 실행
  - indirect : bucket 하나만 실행하며, bucket을 여러 개 두는 것을 허락하지 않는다.
  - fast failover : 가장 먼저 켜져있다고 판단되는 port를 가진 bucket 하나만 실행
- Counters : Group에 의해 처리된 packet의 수

> **3. Meter Entry**

- Meter Identifier : Meter 식별자
- Meter Bands : packet rate와 이에 따른 packet 처리 방법을 가진 여러 meter band를 순서없이 저장. band를 선택할 때에는 측정된 rate보다 작으면서 가장 큰 rate를 가진 band를 선택한다. 각 band는 아래와 같이 구성된다.
  - Band Type : rate를 넘긴 후의 packet 처리 방식을 선택
    - drop : packet을 버린다.
    - dscp remark : IP header에 drop 우선순위를 높인다.
  - Rate : packet rate의 하한선
  - Couter : 처리된 packet의 수
  - Type Specific Arguments : 부가 정보
- Counters : Meter에 의해 처리된 packet의 수

---

마지막으로, Instruction과 Action 그리고 Action Set의 구성을 살펴보자.

> **1. Instruction**

Instruction은 다음과 같은 종류가 있다. 이를 통해서 명령을 적용하거나 Table을 이동하고, ActionSet을 변경하는 것이 가능하다.

1. `meter meter_id` : packet에 특정 meter를 적용
2. `apply-actions action(s)` : packet에 해당 action(s)를 즉각적으로 수행
3. `clear-actions` : `Action set`을 바로 비우기
4. `write-actions action(s)` : Action Set에 해당 action(s)를 추가
5. `write-metadata metadata/mask` : metadata를 추가
6. `goto-table next-table-id` : 특정 table로 이동. 단, 반드시 현재 Table index보다 더 큰 index로 이동해야 한다.

> **2. Action Set**

pipeline이 종료 된 후에 실행되는 action이 저장되어 있다.

action은 기본적으로 아래 순서대로 실행되지만, 동일한 action은 들어온대로 실행되는 것이 아닌 임의로 실행된다.

1. `copy TTL inwards` : TTL을 체크하는 action을 실행
2. `pop` : 만약, packet에 tag가 존재한다면, 모두 제거한
3. `push MPLS` : MPLS tag(=label)을 추가
4. `push PBB` : PBB tag를 추가
5. `push VLAN` : VLAN tag를 추가
6. `copy TTL outwards` : TTL을 체크하는 action을 실행
7. `decrement TTL` : TTL을 감소시키는 action을 실행
8. `set` : `set-field`에 해당하는 action을 실행
9. `qos` : `qos` 관련 action을 실행
10. `group` : 연관된 group bucket의 action을 실행
11. `output` : `output` action으로 명시된 port로 packet을 forwarding

> **3. Action**

실제로 packet을 처리하는 방법에 대한 방법이다.

1. `output` : OpenFlow port 중 어디로 forwarding할지를 지정
2. `set-queue` : QoS 지원을 위해 packet을 내보낼 Switch의 queue Id를 지정
3. `drop` : 직접 호출할 수는 없지만, output이 없거나 `clean-actions` 수행 시에 내부적으로 수행한다.
4. `group` : group을 통해 packet을 처리하도록 group table로 packet 전달
5. `push-tag` : MPLS / VLAN 등의 tag를 추가
6. `pop-tag` : MPLS / VLAN 등의 tag를 삭제
7. `set-field` : header의 가장 끝에 특정 값을 추가
8. `change-ttl` : ttl값을 수정

## 표준화 현황

| version | 발표일  | 주요 기능 추가                                  | 기관                |
| :------ | :------ | :---------------------------------------------- | :------------------ |
| OF 1.0  | 2009.12 | MAC, IPv4, Single Table                         | OpenFlow Consortium |
| OF 1.1  | 2011.2  | MPLS/tunnel, Pipeline(Multi Table), Group Table | OpenFlow Consortium |
| OF 1.2  | 2011.12 | IPv6, Of-Config, 다중 Controller 지원           | ONF                 |
| OF 1.3  | 2012.9  | Meter Table(QoS), Controller 별Event Filtering  | ONF                 |
| OF 1.4  | 2013.10 | Optical port monitoring, Flow 삭제 원인         | ONF                 |
| OF 1.5  | 2014.12 | Egress Table 추가                               | ONF                 |

현재에는 OpenFlow 표준화는 중단된 상태이다. 모든 요구사항을 받아들이다보니 match field의 크기가 너무나 커졌기 때문이다. 따라서, 이용자의 요구에 따라서 programming 할 수 있는 환경을 제공하기 위한 P4(Programmable Protocol-Independent Packet Protocol)을 제작하였다.

즉, 기존에는 Protocol과 이를 지원하는 Switch를 주요 서비스로 삼았다면, 이제는 Programming이 가능한 언어와 이를 이용할 수 있는 Switch를 제공하는 방향으로 전환하였다.

## Reference

- [Openflow specification](https://opennetworking.org/wp-content/uploads/2013/04/openflow-spec-v1.3.1.pdf), ONF, 2012
- Thumbnail: Photo by [Maksym Tymchyk 🇺🇦](https://unsplash.com/@maksym_tymchyk?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/flow?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)


OpenFlow


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



## Intro

mininet은 현실적인 가상 네트워크 환경을 구축해주는 `Network Emulator`, 더 정확히는 `NETOWKR Emulation Orchestration System`이다.  
이를 통해서, 가상의 End Device(Host), 각종 Switch, Router, 그리고 이를 연결하는 Link를 단 하나의 Linux Kernel로 만들 수 있다. 여기서 그치지 않고, 각 Host에 `ssh` 접근을 수행하여 기본 Linux Kernel 동작을 수행하거나 ethernet을 이용해서 각 device로 packet을 전송하는 것과 같은 효과를 볼 수 있다. (실제 speed와 delay에 기반한 속도를 볼 수 있다.) 또한, SDN과 같은 환경에 필요한 Controller 역시 구성하는 것이 가능하다. 그렇기에 실제로 SDN Network를 Test하고 연구하는 목적으로 많이 사용되고 있다.

## 장점

1. Fast - 가상 네트워크의 구성이 굉장히 빠른 시간 내에 구성된다. 실제로 동작해보면, 이를 알 수 있다.
2. Customize Topology - 간단한 네트워크에서부터 시작해서, Backborn, Datacenter, Internet 등 모든 네트워크 구성이 가능하다.
3. Can run every programs in Linux - 간단한 Web Server에서부터 시작하여 Mornitoring Service인 Wireshark 등의 활용이 가능하다.
4. Progammable - 각 Switch의 동작도 programming이 가능하기에 OpenFlow Protocol을 기반으로 packet forwarding 역시 customizing이 가능하다.
5. LightWeight - Labtop에서 돌아갈 정도로 가볍다.
6. Can share results - 각 Topology와 같은 구성은 python code로 구성되고, test code 등도 쉽게 공유가 가능하다.
7. Easy - Mininet 실행과 구축 그리고 운영이 매우 간단한 CLI, Python code로 작성이 가능하기 때문에 매우 쉽다.
8. OpenSource - 쉽게 커뮤니케이션이 가능하고, 누구나 해당 프로젝트에 참여가 가능하다.

## 주의사항

1. 만약 10Gbps 이상의 traffic을 처리하기를 원하는 경우, 부하를 적절히 분배하기 위한 구조를 실행자 측에서 구성할 필요가 있다.
2. Mininet은 하나의 Linux Kernel을 통해 모든 Virtual Host를 제어한다. (다른 Platform, Window 등은 지원하지 않는다. VM 필요)
3. Mininet에서는 OpenFlow Controller를 사용할 수는 있지만, 이를 직접 제어할 방법은 제공하지 않는다.
4. 기본적으로는 Host LAN과는 분리되어 있다. (물론 `NAT`를 통해서 연결도 가능하다.)
5. 기본적으로 Mininet에 의해 생성된 Host는 PID와 file system을 공유한다. (물론 바꿀 수는 있지만, 유의하자.)
6. Simulator가 아니기 때문에, Virtual Time에 대한 매우 정확한 지표를 제시할 수는 없다.

> Mininet 활용

Mininet을 제대로 활용하기 위해서는 다음과 같은 사항을 숙지해야 한다.

0. 설치
1. Topology 생성
2. Performance 측정
3. OpenFlow를 이용해서 Custom Routing

이제부터 위의 내용을 하나하나 수행해 볼 것이다.

## 0. 설치

[Mininet Repo](https://github.com/mininet/mininet)

위의 링크에서 INSTALL이라는 파일에 따라서 설치를 진행해보자. 역시 제일 쉬운 것은 제작자가 직접 만들어놓은 Virtual Machine 이미지를 활용하여 실행하는 것이다.

## 1. Topology 생성

아래의 형태가 가장 기본적인 형태의 Topology이다. 이를 실행시키면, 기본적으로 두 개의 Host가 하나의 Switch에 각 각 연결된 형태로 구성되어진다.

![one-switch-topology](/images/one-switch-topo.jpeg)

```python
from mininet.topo import Topo

class SingleSwitchTopo(Topo):
  "Single switch connected to n Hosts."
  # build function 내부에서 topology를 구성하는 요소에 대해 정의
  # self.__init__의 parameter가 해당 함수로 그대로 전달된다.
  def build(self, n=2):
    # s1이라는 이름으로 Switch 생성
    switch = self.addSwitch('s1')
    for h in range(n):
      # h1, h2, ... 이라는 이름으로 Host 생성
      host = self.addHost('h%s' % (h+1))
      # h1, h2, ... 을 s1과 연결
      self.addLink(host, switch)

# 후에 topology를 생성할 때, 아래 이름을 통해서 지정이 가능
topos = { 'singleSwitch': (lambda: SingleSwitchTopo())}
```

이를 파일로 생성하고, 다음과 같이 실행시키면 된다.

```bash
$ sudo mn --custom [file명.py] --topo [topology 이름],[build function parameters]

# example
$ sudo mn --custom mytopo.py --topo singleSwitch,3
```

하지만, 위와 같이 mininet command를 통해서 실행시키는 것은 자동화에는 적절하지 않을 수 있다.  
만약, 부가적인 설정을 해주고 싶거나 실행 후에 test 및 실험하고자 하는 상황을 만들고자 한다면 추가적인 programming이 필요하다.  
아래 코드를 추가적으로 살펴보자.

```python
from mininet.topo import Topo
from mininet.net import Mininet
from mininet.util import dumpNodeConnections
from mininet.log import setLogLevel

class SingleSwitchTopo(Topo):
  "Single switch connected to n Hosts."
  def build(self, n=2):
    switch = self.addSwitch('s1')
    for h in range(n):
      host = self.addHost('h%s' % (h+1))
      self.addLink(host, switch)

def simpleTest():
    "Create and test a simple network"
    topo = SingleSwitchTopo(n=4)
    # Mininet 생성
    # 이때, Topology, Host, Switch, Controller, Link 등에 대한 Customizing이 가능하다.
    net = Mininet(topo)
    # mininet 실행
    net.start()
    print( "Host의 연결 상태를 출력" )
    dumpNodeConnections(net.hosts)
    print( "Netowork 연결 상태를 체크" )
    # ping to every node with each node.
    net.pingAll()
    # mininet 정지
    net.stop()

if __name__ == '__main__':
    # Tell mininet to print useful information
    setLogLevel('info')
    simpleTest()
```

```bash
python [file명.py]
```

이를 통해서, Mininet를 우리가 정의한 Topology에 따라서 실행하고 테스트를 수행하는 code이다.  
이러한 기능 뿐만 아니라 host의 성능을 제한하거나 Link 용량을 제어할 수도 있고, Switch를 제어할 수도 있고, 특정 Host에서 Command를 실행시키도록 할 수도 있다.  
더 자세한 사항은 아래 링크를 통해서 확인해보자.
[More Example](https://github.com/mininet/mininet/tree/master/examples)

위에서 살펴본 사항은 가장 기본적인 Mininet에서 제공하는 Template에 기반하여 programming을 수행하는 것이다. 만약, 직접적으로 제어를 원하는 경우 더 하위 단계의 API를 활용하여 구현하는 것도 가능하다. [API Doc](http://api.mininet.org)

### 추가 참고사항

code convention이 후에 버전에서는 좀 변경되었다.

- camelCase 표기가 snake_case형태로 변경되었다. example. `addHost -> add_host`.
- `build`가 `__init__`으로 바뀌어, 나의 기준에서는 이해하기 쉬워졌다.

변경되었지만, 여전히 기존 버전 표기도 지원하기 때문에 사용하는데는 문제가 없다.

## 2. Performance 측정

해당 사항은 Mininet에서 권장하는 방법이다.

1. Bandwidth - `bwm-ng`, `ethstats`
2. Latency - `ping`
3. Queues - `tc`
4. TCP Congestion Window statistics - `tcp_probe`
5. CPU usage - for all: `top`, per host: `cpuacct`

## 3. OpenFlow를 이용해서 Custom Routing

Mininet 자체만으로도 값지지만 SDN을 구축하기 위한 OpenFlow Protocol을 이용한 Routing을 Emulating할 때에 굉장한 효과를 얻을 수 있다.  
Mininet을 실행시킬 때에 아무 설정을 하지 않으면 기본 Ethernet switch를 사용하는 기본 Controller를 사용한다. 하지만, Open vSwitch(ovs)와 같은 OpenFlow Protocol을 지원하는 Controller를 활용할 수도 있다.  
기본적인 Switch(대략 4096개)는 이미 지원을 하고 있다. 이를 불러와서 사용하거나 원하는 경우에는 python을 통해서 직접 구현하여도 무방하다. 심지어는 원격에 있는 controller를 사용할 수도 있다.

이렇게 Controller를 정의하고, 외부에서 해당 Controller의 동작을 정의해주면, Mininet에 의해서 정의된 Network가 의도대로 동작하는지를 계속해서 확인할 수 있다.

## NutShell

Mininet에서 어떻게 이렇게 빠르게 가상 Network System을 가볍게 구현할 수 있는가에 대한 열쇠는 `container`이다. 이를 통해서, 서로 완전 분리된 Host를 기본적으로 구성하는 Container이기에 이를 쉽게 구현할 수 있을 뿐만 아니라 Virtual Machine을 직접적으로 구현하지 않기 때문에 가볍고 빠를 수 있는 것이다. 또한, Virtual Link 같은 경우에는 Linux Traffic Control(`tc`)를 활용하여, Virtual Ethernet이 각 Virtual Switch와 Interface들을 통해서 전달되는 것을 제어할 수 있다. 마지막으로, Switch는 기본적인 Linux Bridge를 활요하거나 Open vSwitch를 활용하여 구성하여 가상화가 가능하다.

## 결론

Mininet은 가상 Network를 Emulating 할 수 있는 Tool이기에 실제로 SDN을 테스트하기 이전에 각종 기능을 체크하기에 용이하다.  
또한, Network에서 핵심적인 Forwarding에 관한 기술은 다른 기술에게 맡겨서 더 안정적인 구조를 가지고 있다.  
이에 따라 Open vSwitch를 이용해서 자유롭게 시스템을 제어할 수 있을 뿐만 아니라 ONOS와 같은 도구를 통해서 Network를 구성하는 과정을 테스트하기에 굉장히 유용하다.

## Reference

- Thumbnail : Photo by [Jordan Harrison](https://unsplash.com/@jordanharrison?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/network-cable?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)
- mininet : <https://github.com/mininet/mininet/wiki/Introduction-to-Mininet>


Mininet


## Intro

Segment Routing은 MPLS의 차세대 버전으로, 초기에는 MPLS의 문제를 해결하기 위해서 제시되었다. 예를들면, TE(Traffic Engineering) 시에 Star Topology에서는 효율이 안나온다던지 ECMP(Traffic을 여러 output interface로 분배시키는 방식)을 활용할 수 없다와 같은 제한을 해결하고자 등장하였다. 그렇지만, 현재에 와서 와서 더 중요시 여겨지는 것은 **네트워크 구조의 단순화**이다. 즉, 기존의 복잡하던 Switch의 설정 방법(통신장비 vender 마다 다른 설정법, 여러 Protocold이 존재)과 운용 방법을 통일하고, 단순화 시킴으로써 사람에 의한 에러(Human Error)를 최소화하고자 하는 노력이라고 볼 수 있다.

## 용어

- **Segment** : 하나의 path가 여러 개의 작은 path들로 구성되는 것에서 유래하였다고 보며, 하나의 명령어(instruction)을 segment라고도 부른다. 명령어는 어디로 전달할 것인가와 packet을 어떻게 변형할 것인가에 대한 내용을 포함한다.  
  Segment는 SID라는 id값을 통해서 구분하며, 이는 [0, 1,048,575] 까지를 사용할 수 있다. 특별한 목적을 가지는 [0, 15,000) 예약된 SID이고, [15,000 ~ 16,000)는 인접한 egress Router를 가르키는데 사용하는 `Adjacency SID`이고, [16,000, 24,000)는 Segment Routing이 유효한 범위 내에서 각 Router에 임의 설정이 가능한 영역대로 `Prefix SID` 라고 부른다. 그 외에 영역은 동적으로 할당되는 SID로 자동 할당 시에 사용된다. 여기서 중요한 점은 **Adjacency SID와 Prefix SID만 있으면, 모든 경로를 표현하는 것이 가능하다는 것이다.** 추가적으로, SR Policy를 재사용하고 싶은 경우가 발생할 수 있는데 이를 위해서 SR Policy 자체에 SID를 부여하는 것이 BSID(Binding SID)이다.  
  ![SID-table](/images/sid-table.jpeg)
- **Headend Router** : Segment Routing 영역으로 들어오는 Ingress Router이다.

## 동작 원리

Segment Routing 영역으로 Packet이 진입하면, 해당 packet의 Destination과 부가 정보를 확인하여, SR Policy(=Segment List, 방문해야할 경로를 순서대로 나열해놓은 리스트)를 MPLS 또는 IPv6의 부가 공간에 삽입한다. 이때에는 Stack 형태로 List를 구성하고, 중간 Router들에서는 Segment에 따라서 동작을 수행하며, packet을 최종 Egress Router까지 전달한다. 여기서 각 경로는 모든 세세한 경로를 표시할 필요는 없다. 만약 A에서 B로 가는 SID를 설정했어도, 그 내부에서 어떤 경로를 선택할지는 System적으로 알아서 Routing하도록 설정하는 것도 가능하다.(`Loose Source Routing`) Ingress에서 SR Policy를 지정하면 이를 `Push`라고 하고, 내부 Router는 가장 아래 Segment를 확인하고 자신과 관련 있는 경우에는 `Pop`을 수행하여 하나의 Segment를 삭제 후 이에 따라 동작을 수행하고, 그렇지 않으면 연결된 Link로 기존 BGP에 따라 알아서 Routing을 수행한다. 이를 `Continue`라고 한다.

## Usecase

다음과 같은 형태로 Routing을 설정하는 것이다. 아래 예시에서는 모두 1 -> 2 -> 3 -> 4 순으로 Routing을 수행하기를 원한다고 생각하자.

`SID 16002`의 경우에는 `1 -> 2`로 이동하는 것이 `1 -> 4 -> 3 -> 2` 보다 IGP cost가 적으므로, `1 -> 2`로 원하는대로 이동할 것이라고 예상할 수 있다.
이후 `SID 16004`의 경우에도 `2 -> 3 -> 4`로 이동하는 것이 `2 -> 1 -> 4`로 이동하는 것보다 IGP cost가 적으므로, `2 -> 3 -> 4`로 원하는대로 이동하는 것을 예상할 수 있다.

![sr example 1](/images/sr-example-1.jpeg)

하지만, IGP cost가 우리의 바램과는 다른 경우에는 다음과 같은 현상이 발생할 수도 있다.
아래에서 `SID 16004`를 보면, `2 -> 1 -> 4`가 `2 -> 3 -> 4`보다 IGP cost가 적기 때문에 우리가 원하는 방향과는 반대로 동작할 것임을 예상할 수 있다. 따라서, 이를 해결하기 위해서 우리는 다음과 같은 경로를 채택해야 한다.

![sr example 2](/images/sr-example-2.jpeg)

여기서는 `1 -> 2 -> 3`이 `1 -> 4 -> 3`보다 크기 때문에 원하는대로 `1 -> 2 -> 3`으로 움직일 것이다. 하지만, 여기서 `3 -> 4`로 가는 경로가 어려울 수 있다. 이 경우에는 앞 서 보았던 Adjacency SID를 활용하여야 한다. 이는 마지막으로 가야할 egress Router를 지정하기 때문에 routing 시에 costing을 고려하지 않고, 바로 Static Routing이 가능하다. 따라서, 이를 활용하면 최종으로 `3 -> 4`로 가는 경로를 획득하는 것이 가능하다.

![sr example 3](/images/sr-example-3.jpeg)

## Configuration

- SR-MPLS : MPLS와 같은 방식을 추구하지만, 설정 방식에서 LDP와 RSVP를 사용하지 않고 IGP를 활용해서 이를 수행할 수 있도록 하여 Protocol을 단순화하였다.  
  Segment List(`SR Policy`)를 전달하는 과정이 MPLS의 Label을 전달하는 방식과 유사하며, 지나야하는 경로를 명시하여 stack 형태로 쌓아서 전달하면, 각 내부 Router는 이를 참고하여 제거 또는 유지하며, Egress Router를 찾는다.
- SRv6 : IGP와 IPv6 Protocol만을 활용하여 네트워크를 구성할 수 있도록 하는 것이 목표이다. 네트워크 자체를 프로그래밍 하고자 하는 요구 때문에 필요성이 강조되었다. 이는 IPv6의 주소값인 128bit를 topology를 식별할 주소값과 packet 처리를 위한 값(특정 packet에게는 다른 routing table을 적용 등)으로 나누어 사용함으로써 구현이 가능하다. 따라서, IPv4의 짧은 주소 체계로는 이를 수행할 수 없다. 따라서, IPv6 Protocol을 이용하여 수행하는 것이다.  
  Segment List(`SR Policy`)를 전달하는 과정은 위와 유사하지만, 이를 IPv6 Option 영역에 stack형태로 저장한다.

## Traffic Engineering

Traffic을 제어하고, 해당 제어를 위한 제한사항들을 실시간으로 update하고, 운용 관리하는 것이 가능하다. MPLS에서 수행하던 TE(Traffic Engineering)과 유사하지만, Bandwidth를 사용하지 않는 대신에 delay라는 조건을 갖고 있다. 이는 packet이 도착하는데 걸리는 시간을 측정한 값이다.  
해당 조건들을 활용하여 Traffic을 입맛에 맞게 변경하는 것이 가능하다.

또한, 장애 대책 시에도 Segment Routing은 강점을 가지고 있다. 일반적인 OSPF를 활용하는 경우에는 LFA(Loop Free Alternate)를 통해서 우회 경로를 계산한다. 하지만, 이는 생각보다 비효율적인 경로 계산을 수행하게 된다. 따라서, 이를 개선하는데 Segment Routing이 적절하다. 다음 예시를 보자.

[그림]

장애 이전에 `1 -> 2 -> 3 -> 5` 그리고 `6 -> 2 -> 3 -> 5` 라는 traffic이 존재할 때, 만약 `2 -> 3` link가 끊어지면, 기존의 LFA를 이용하면 찾게 되는 경로는 다음 경로와 같아진다.

![sr post convergence 1](/images/sr-post-convergence-1.jpeg)

이는 상당히 비효율적인 경로인데, 이렇게 계산을 수행하는 이유는 `1 -> 2 -> 6 -> 7 -> 3 -> 5` 라는 차선 경로로 가는 도중에 `2 -> 6`으로 이동 이후에 기존 Traffic에 영향으로 인해 `6 -> 2`로 다시 돌아오는 현상이 발생하기 때문이다. 따라서, 결론상 더 큰 비용이 발생하는 경로(`2 -> 4`)로 들어가서 오히려 더 많은 비용이 발생하게 된다.

![sr post convergence 2](/images/sr-post-convergence-2.jpeg)

이를 해결하기 위해서는 장애가 발생한 이후에 다시 IGP가 계산하는 최단 경로인 `Post-Convergence Path`를 사용하면 된다. 하지만, 해당 경로는 Loop를 야기할 가능성이 존재한다. 이로 인해, 해당 방식을 사용하지 않았었는데, Segment Routing을 이용하여 경로를 제한함으로써 Post Convergence Path를 사용할 수 있게 되었다. 즉, Segment Routing의 Adjacency SID를 이용해서 나가야할 지점을 명확하게 하며, Loop가 발생할 수 있는 지점에서 Static Routing을 지정하면서, Prefix SID를 통해서 경로를 적절히 지정하여 해결이 가능한 것이다.

![sr post convergence 3](/images/sr-post-convergence-3.jpeg)

## Programmable

Segment Routing의 또 하나의 강점은 SDN 지향적인 구조라는 것이다. 즉, 중앙에서 각 Switch의 동작을 제어하는 Controller를 Segment Routing을 통해서 직접 구현이 가능하다는 것이다. 즉, Segment Routing Network가 특정 Controller에게 자신의 상태 정보 등을 주기적으로 보내면, Controller에서는 이를 이용해서 Database를 구축하고, 이를 바탕으로 Routing Table을 완성하는 것이다. 이를 기반으로, 후에 요청이 Headend 장치로 들어오면, 해당 장치는 Controller에게 처리를 요청하고, 이에 대한 응답을 받은 Headend 장비는 적절하게 SR Policy를 해당 packet에 저장하여 Routing이 가능해지는 것이다.

## Summary

|                   | MPLS                                                               | SR-MPLS                  | SRv6                 | Segment Routing의 장점                                                            |
| :---------------- | :----------------------------------------------------------------- | :----------------------- | :------------------- | :-------------------------------------------------------------------------------- |
| 제어 프로토콜     | 기반 : IGP/BGP, 추가 : LDP/RSVP-TE                                 | IGP/BGP                  | IGP/BGP              | LDP/RSVP-TE 와 같은 추가 Protocol이 없음                                          |
| 데이터 평면       | MPLS 데이터 평면을 정의해서 사용                                   | MPLS 데이터 평면을 활용  | IPv6를 활용          | IPv6를 활용한 경우 추가적인 설정이 필요없음                                       |
| 경로 계산 및 조정 | 사실 Ingress에서 설정하지만 각 노드가 관여                         | Source(Ingress)에서 결정 | 동일                 | Source Routing으로 명확한 구조                                                    |
| LSP의 Label 관리  | LSP의 갯수가 많아질 수록 각 노드의 부담 증가                       | 인접 노드, 링크만 관리   | 동일                 | 내부 Router의 부담이 크게 감소                                                    |
| Operation         | Push, Swap, Pop                                                    | Push, Next, Continue     | 동일                 | Swap 연산이 필요없다.                                                             |
| 장애 대책         | Fast ReRoute                                                       | TI-LFA, Fast ReRoute     | 동일                 | Fast ReRoute는 convergence time이 길어 실용 사례가 적다.                          |
| Programmability   | 불가능                                                             | 불가능                   | Network Programmable | IPv6를 이용한다면, Traffic Engineering, VPN을 Programming을 통해 구현이 가능하다. |
| 네트워크 확장성   | 일반적으로는 높다. 하지만, RSVP-TE를 활용하는 경우 낮아질 수 있다. | 확장성이 높다.           | 동일                 | 확장성이 높다.                                                                    |
| 네트워크 구조     | 일반적인 분산 제어 구조                                            | SDN 적용이 가능          | 동일                 | SDN 기반의 중앙집중 제어와 기존 방식으로 분산 제어도 가능함                       |

## Reference

- Thumbnail: Photo by [Arno Senoner](https://unsplash.com/@arnosenoner?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/forwarding?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)


Segment Routing


## Intro

MPLS는 2계층과 3계층 사이에서 Routing을 가속화하기 위한 방법으로 제시된 방법이다. 뿐만 아니라 기존에 존재하던 Networking의 문제를 보완하기 위해서 고안되었기에 여러 우수한 기능을 가지고 있다.

## MPLS

기존의 Routing에서는 매 hop(router)당 Routing Table을 참조하여 packet을 전송했다. 하지만, 이 과정은 생각보다 많은 시간이 필요하다. 이를 이용해서 화상 통화 등을 한다면, 서비스 품질이 매우 떨어질 위험이 있다. 따라서, MPLS는 Routing를 더 빠르게 하고, 품질 항상을 위해서 만들어졌다. 이는 Multi-Protocol Label Switching(MPLS)이라는 말처럼, 기존의 IP를 이용한 Routing이 아닌 Label(또는 tag)이라는 별도의 data를 이용하여, 3계층을 거치지 않고, Routing을 고속화하는 역할을 할 수 있다.

또한, **MPLS**에서는 사전에 고효율 경로를 설정하고, 이를 통해서 통신하도록 하여 성능 문제를 해결한다. 예를 들어, Packet이 들어오면, 진입점에 있는 Router(Ingress Router)가 해당 Packet에 Label을 표기하고 내부 Network로 전송하게 된다. 이제 내부 Router에서는 Packet을 모두 확인하지 않고, 해당 Label만을 이용하여 Forwarding을 수행한다. 그렇기에 더 빠른 Routing이 가능해지는 것이다.

![MPLS packet](/images/mpls-label.jpeg)

하지만, 그 외에도 추가로 더 많은 장점을 보유하고 있다.

1. 여러 Protocol과 호환이 가능하도록 overlay로 개발되었다. (2.5 Layer라고도 불리는 이유이다.)
2. TE(Traffic Engineering)를 위한 여러 설정을 제공한다. 따라서, bandwidth, QoS(서비스 품질)에 따라서 Traffic을 제어하는 것이 가능하다.

## 용어

- MPLS Network : **MPLS**를 통해서 구축한 Network를 의미한다. 해당 Network로 진입하는 순간 Packet에는 Label과 부가적인 header가 추가된다.
- Label : Label은 각 Router에게 하나씩 주어지는 Router의 고유 식별값이다.
- LER(Label Edge Router) : Network 제공자 입장에서 Edge Router로 두 가지 종류로 나뉜다.  
  Ingress와 Egress는 항상 고정인 것이 아니라 packet에 입장에서 계속해서 변경된다.
  - Ingress Router: packet이 Network로 진입하는 Router로 실제 Network를 전체 조회하고, Label을 추가하는 역할을 한다.
  - Egress Router : packet이 Network를 탈출하는 Router로 Packet의 남아있는 Label을 삭제한다.
- LSR(Label Switched Router) : MPLS Network 내부에 존재하는 LER이 아닌 Router들로 이들은 Packet의 Label을 Switching하고, Forwarding하는 역할을 수행한다.

![mpls-example](/images/mpls-example.jpeg)

## 동작 원리

`LSP(Label Switched Path)라는 최단 경로를 찾고, 이를 통해서 Packet을 전달시킨다.`가 Protocol의 핵심적인 전략이다. 형성된 LSP에 따라서 labe들을 설정해두면, 이제 내부 Router에서는 자신에게 해당하는 Label을 교환하여 다시 Forwarding을 수행하면 되는 것이다. 따라서, 3계층을 거치지 않고 Routing이 가능하다. 위에서 나온 용어로 정리하자면, Ingress LER에서는 packet의 목적지와 요청지 정보 등을 활용하여 LSP을 구성하고, 이에 알맞는 Label을 packet에 추가한다. 이제 이 packet을 받은 LSR에서는 Label을 하나 빼고, 다음 LSR을 찾아가기를 반복하며, egress LER에 도달한다. egress에서는 Label이 남아있다면, 모두 제거하고, 원래 사용 중이던 Protocol에 맞게 다시 Routing을 수행한다.

![mpls-example](/images/mpls-example-2.jpeg)

### LSP 구성

총 3가지 방법을 통해서 생성이 가능하다. 이는 후에 나올 Configuration에 따라서 어느정도 바뀌게 된다.

1. Best Effort LSP : Label 할당이 알고리즘에 의해서 자동적으로 할당되며, 항상 연결이 지속될 수 있도록 하는 것을 최대 목표로 하기 때문에 여타 방식들에 비해 성능이 떨어질 수도 있지만, 장애 대응에 적절하다고 할 수 있다.
2. Static LSP : Label을 직접 수작업을 통해서 할당해주며, 경로를 customizing할 수 있지만, 이로 인해서 예상치 못한 문제가 발생할 수도 있다.
3. Signaled LSP : 일정 이상의 자원(Bandwidth, 등)을 제한하여 경로를 최적화할 수 있다.

### Configuration

MPLS network를 구성하기 위해서는 결국 각 Router에 Label을 나누어주는 것과 LSP를 구성하는 것이 중요하다. 아래에는 대표적인 MPLS의 Topology를 살펴본다.

- LDP : 위에서 설명한 Best Effort LSP를 구성하는 Protocol로 Label을 분배하고, 각 Router에서는 Label의 Push/POP/Swap을 수행한다.
- RSVP-TE : 특정 제약 조건을 먼저 제시를 하고, 이를 기반으로 이와 일치하는 경로를 찾아서 packet을 Routing하는 방식이다.

## Versus

| 구분                   | ATM       | IP        | MPLS      |
| :--------------------- | :-------- | :-------- | :-------- |
| IP Traffic Engineering | 우수      | 보통      | 매우 우수 |
| 고속 포워딩            | 매우 우수 | 보통      | 우수/보통 |
| QoS                    | 매우 우수 | 보통      | 우수      |
| VPN 비용               | 고가      | 저가      | 중가      |
| 확장성                 | 우수      | 매우 우수 | 매우 우수 |
| 구축 / 유지 비용       | 매우 고가 | 저가      | 고가      |

## References

- Thumbnail : Photo by [Tyler Farmer](https://unsplash.com/@tylerfarmer?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/forwarding?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)
- <https://www.itworld.co.kr/tags/6580/MPLS/108621>
- <https://blog.naver.com/thorong/70147777745>
