5-2. SDN controllers

5-1. Traditional routing algorithms(per-router control)

(1) Routing algorithm classification

- Link state routing algorithm: Dijkstra's algorithm(OSPF)

- Distance vector algorithm: Bellman-Ford algorithm

- Hierarchical routing(BGP)

(2) Routing protocols

- RIP, OSPF/BGP

 

5-2. SDN controllers(logically centralized control)

ㄴ OpenFlow, ODL, ONOS controllers

(1) Network management, configuration

- Internet Control Message Protocol(ICMP)

- SNMP, YANG/NETCONF

---

Traditional Internet: Per-router control plane

 

network layer은 여태까지 per-router 접근법으로 실행됐었다.

switching hardware를 가지고 있고 Cisco IOS와 같은 proprietary router를 운영하는, monolithic한 router들이었던 것이다.

그리고 필요한 기능들을 middlebox로 구현해야 했었다.

 

 

Traffic engineering

 

여러 가지 이유로 route를 유연하게 결정하는 것.

 

 

Q: 아래의 경로가 훨씬 비용이 적지만 그럼에도 밑의 경로를 선택하고 싶다면?

A: 위의 경로를 사용할 수 있도록 link route를 재정의해줄 수 있지만, 매우 제한적인 작업이다.

 

Q: uvwz와 uxyz 두 경로에 load balancing하고 싶다면?

A: 목적지가 같기 때문에 불가능.(destination-based forwarding) 하고 싶다면 새로운 algorithm 필요.

 

Q: w가 파란색 경로를 선택하고 싶다면?

A: 불가능.(destination-based forwarding)

 

 

이렇게 한계가 존재한다. 이를 해결하기 위해 SDN이 사용된다.

 

SDN

 

network control pane과 forwarding plane을 물리적으로 분리

-> control plane은 logically centralized되어 여러 router들 관리

 

- network management가 쉬워짐

: router가 개별적으로 configure해야 했음. But,, SDN을 통해 centralized server 두면 알아서 configure해줌

=> router misconfiguration 방지, traffic flow가 유연해짐

 

- programmable router

: centralized programming은 중앙에서 forwarding table 전체를 관리하기 때문에

distributed programming보다 programming이 쉬움

 

- open(non-proprietary) implementation of control plane

: 한 회사가 독재식으로 운영하면 발전이 더딤. non-proprietary하기 때문에 발전 빠르게 됨

 

SDN Analogy: mainframe of PC evolution

 

SDN은 다음과 같이 hardware, OS, application을 만들어 운영 => 특정 application을 실행할 수 있는 기계 설계 가능

 

 

하나의 hardware 위에 여러 종류의 OS가 존재 가능

그 위에 다양한 종류의 application 동작 가능

 

SDN control plane

 

- remote controller가 forwarding table 독자적으로 만들어 router들에게 내려보내줌

=> router들은 generalized flow-based forwarding 수행(같은 flow 가진 traffic에 대해서는 같은 방식으로 forwarding)

 

- control plane은 data plane과 분리됨

=> data plane와 switching과 control plane의 flow table 계산이 병렬적으로 진행

 

- remote controller 위에 application 여러 개 둘 수 있음(아래 그램에서 초록색 부분)

 

 

SDN의 관점에서

- Data plane switches(SDN-controlled switches)

: 하드웨어

: generalized data-plane forwarding 수행하는 fast, simple commodity switch

: switch flow table은 controller에 의해 computed, installed

 

- (southbound) API

: data plane switch와 SDN controller 사이 interface

: table를 기반으로 switch control하기 위한 것. 어느 것이 controllable한지 정의

: ex. OpenFlow

 

- SDN controller

: network state information 유지

: northbound API를 통해 applicaton과 소통

* SDN controller가 직접 switch programming을 하지 않고 northbound API에게 시킴

: southbound API를 통해 network switch들과 소통

: distributed system으로 동작 => performance, scalability, fault-tolerance, robustness 증진

 

- (northbound) API

: SDN controller와 network-control application 사이 interface

: higher-level abstraction을 통해 switch들을 programming함(SDN controller 대행)

 

- network-control applications

: network을 control하는 뇌같은 역할

: SDN controller가 제공하는 network status info 사용(northbound API를 통해 소통)

: SDN controller와 다른, 제삼자 회사들이 만들 수 있음

=> 각자 자신의 역할 수행(routing/access control/load balancing/ 등등 ..)

 

 

Distributed SDN controller의 구성요소

 

 

Interface layer to network control apps

: network control app들(위 계층)의 동작을 위해 사용될 자료들을 추상화시켜놓음

 

1. network graph

2. RESTful API

3. intent

 

 

Network-wide distributed, robust state management

: 물리적으로는 distrubuted database이고, network state, links, switches, services 정보를 가지고 있음

 

1. statistics: flow table의 세 번째 entry. switch들로부터 모아 와서 관리

2. flow table: 위에서 받아온 flow table 유지

 

 

Communication layer

: SDN controller & switch 간 소통을 위한 layer

 

1. OpenFlow: OpenFlow msg는 TCP에 encapsulate되어, OpenFlow Controller를 통해 서로 소통하게 된다.

- "controller->switch"

* features: controller가 switch에게 특징을 묻는 query함 => switch들은 이에 대한 응답 받음

* configure: controller가 현재 switch에 query하거나, configuration parameter를 새로 설정하라는 msg 보냄

* modify-state: controller가 상태 정보 add, delete, modify

* packet-out: 이런 packet은 너의 어느 포트로 내보내라

 

- "switch->controller"

* packet-in: packet을 controller에게 transfer할 때 packet-in msg에 포장해 보냄

* flow-removed: flow table entry가 delete되면 controller에게 알림

* port status: port status 변화를 controller에게 알림

*** switch를 programming하는 것은 SDN controller가 직접 OpenFlow msg를 만들어 보내지 않고,

northbound API interface의 abstraction을 사용.

 

- SNMP: traditional internet에서부터 존재하던 관리 프로그램

 

 

SDN: control/data plane interaction example

 

1. S1에서 experiencing link failure 발생하면 OpenFlow를 통해 controller에게 알림

2. SDN controller는 OpenFlow msg를 전달받고 link-state info를 업데이트

3. Dijkstra's routing algorithm app은 SDN controller에게 link state에 변화가 생기면 자신을 트리거해달라고 말해 놓음

=> 변화가 생겼으니 app이 트리거됨

* Link-state info 변화에 따라 abstraction인 network graph도 변화

4. Dijkstra's routing algorithm이 SDN의 network graph info와 link state info를 가지고 새로운 route 계산

5. link state routing app은 SDN의 flow-table-computation 

6. 새로운 flow table entry가 OpenFlow 사용해 다른 모든 switch들에게 새로운 table 제공

 

=> 모든 업데이트는 controller가 독단적으로 하지 않고 항상 network application abstraction을 통해 수행됨

 

 

SDN: selected challenges

 

- control plane의 기능 향상되어야.

SDN은 기능이 하나에 모아져 있지 않은 distributed system

=> 어떻게 robust하게, reliable하게 동작하게 해줄거냐에 대한 이론들이 추가적으로 연구될 필요가 있음(아직 부족..)

 

- network들, protocol들은 mission-specific한 요구사항 충족시킬 수 있도록 향상되어야.

* ex. real-time, ultra-reliable, ultra-secure 등등의 mission-specific 요구사항들

 

- Internet-scaling

인터넷은 수많은 AS로 이루어짐 => SDN controller가 어떻게 동작하면 효율적일지 고민해봐야.

 

- SDN은 5G cellular network에서 중요