[ 네트워크 ] SDN - (2)

 

SDN - (2)

 

SDN-controlled switches

 

 data plane은 SDN control 되어있는 SDN-controlled switch들이다. 이것들은 스위치 기능을 해주는 하드웨어이다.

 이 내부에는 flow table이 있어 table 기반의 switch control이다. software에 의해 control 되는 API가 존재하는데 이 API는 OpenFlow를 통해서 단일화되어 있는데, 어떤 것이 control 가능한지, 어떤 것이 안되는지 이런 것들이 정의되어 있다. 그리고 이 controller하고 communication해야 하므로 이에 대한 protocol이 있는데, 이 protocol은 OpenFlow에 의해서 정의가 되어있다.

 

 

 

 

 

SDN controller

 하드웨어 switch 위에는 SDN controller가 있다. 이 controller는 network OS로 생각하면 된다. Network에 대한 상태정보를 갖고 있다. 그래서 실제 application들과 SDN-controlled switches들의 중간역할을 하게 된다. 그래서 SDN controller는 각각 분산적으로 구현이 된다. performance, scalability, fault-tolerance 등을 해결하기 위한 역할을 한다.

 

 

 

 

 

 

 

network-control applications

 

 맨 위에 network-control application들 있다. 이게 핵심적인 routing, load balance, access control과 같은 부분이 있다. 여기서 중요한 것은 unbundled이다. 밑에 있는 하드웨어와 독립되어 있다. routing vendor 또는 SDN controller와 분리시킬 수 있다. 이 부분만 다른 vendor를 통해 할 수 있다. 다만 API를 통해서만 하면 된다.

 

 

 

 

 

 

 

SDN controller에 들어가는 요소들

communication layer : switch하고 통신하는 부분. OpenFlow나 SNMP가 있다. 이런 네트워크를 관리하는 protocol들이 붙어있다.

Network-wide state management layer : 분산된 switch, router들에 대한 정보들이 DB에 저장이 된다. link-state에 대한 정보, host 정보, 물리적인 switch정보들이 중간에 쌓인다. 그러면 이것으로부터 통계를 뽑아내고 flow table도 만든다.

interface layer : 바깥 routing이랄지, 맨 위에 있는 프로그램을 실제 하기 위한 API들이 있다.

 

 

 

 

 

 

 

 

OpenFlow protocol

 각각의 switch로부터 공통된 정보를 주고받는 역할을 한다. 여기에는 TCP가 사용이 된다. 그리고 OpenFlow message를 만들기 위해 세가지 클래스를 만들어놨다. (controller-to-switch, asynchronous(switch to controller), symmetric(msic))

 

 

1. OpenFlow: controller-to-switch messages

Controller에서 switch로, 위에서 아래로 내려가는 것이다. 이 때는 어떤 message가 내려갈까?

- features : controller가 어떤 switch features에 대한 쿼리를 보내서 switch가 응답한다.

- configure : controller가 어떤 parameter를 설정하는 것이다.

- modify-state : OpenFlow tabale을 추가, 삭제 및 수정한다.

- packet-out : controller가 switch port에서 어떤 패킷을 보내라고 요청한다.

 

 

2. OpenFlow: switch-to-controller messages

switch에서 controller로, 아래서 위로 올라가는 messages이다.

- packet-in : 어떤 패킷을 controller에다가 전달한다.

- flow-removed : switch에 있는 어떤 flow table entry를 삭제되었다는 것을 알려준다.

- port status : controller에다가 내 port가 바뀌었다고 알려준다.

 

 

 network opertor들은 OpenFlow messages를 통해 바로 프로그램하는 것은 아니다. 이것은 공통되도록 정해지는 것이고, 실제 모든 것은 controller에서 작동한다. 즉 네트워크의 효율적 운용을 위해서 기능을 잘 분리시켜 놓았다는 것이다.

 

 

 

 

 

실제 interaction 하는 예시

1. s1이 controller에다가 link failure가 생겼다고 OpenFlow protocol을 통해서 알려준다.

2. 중간에 있는 SDN controller가 이를 받고, 자신의 link state information을 업데이트 한다.

3. 이 내용을 위쪽으로 올려서 다이제스트라 알고리즘이 이 변화를 적용해서 알고리즘을 돌리게 된다.

4. 이 알고리즘의 계산 결과(route 정보)를 밑으로 내려준다.

5. 맨 위에 있는 routing application이 계산된 Flow table을 밑으로 내려주낟.

6. controller가 OpenFlow 통해서 밑에 있는 모든 switch들에게 이렇게 적용하라고 뿌려준다.

 

 

 

 

 

 

 

Controller 예시

OpenDayLight (ODL)

1. ODL

 맨 아래는 이 때까지 했었던 동일한 내용이고, 중간이 핵심부분이다. 어떤 식으로 관리할 수 있게 만들었느냐가 각 Controller마다 다르게 할 수 있는 부분이다. ODL에서는 Network service application을 분리하고 Basic Network Service Functions이라고 해서 여러 manager들로 구성을 해서 구현을 하였다.

 

 

 

 

 

ONOS controller

2. ONOS

 맨 아래 부분이 좀 더 추가되긴 했지만 비슷한 구조이다. 중간 부분은 host, devices… 등등으로 구성된다. distributed core 이 부분에 대해서 많이 계산했다. service reliability라던지, performance scaling 등등… 이런 부분을 고려해서 만들었다.

 

 

 

 

 

 

 

 

SDN : selected challenges

 SDN은 2010년 이후에 나온 기술로, 나온지가 오래되지는 않았다. 몇 년 되지는 않았지만 급속도로 시스템에 파고들고 있다. 실제 모바일 쪽, 5G 기관망에서도 SDN의 철학이 다 들어가 있다.

 그래서 좀 전에 보듯이 controller들을 dependable하게 만들 수 있을까. 즉 얼마나 더 신뢰할 수 있을까. reliable의 상위개념이라고 보면 된다. performance-scalable, secure distributed system. 이런 부분들을 control plane을 얼마나 더 잘 설계할 것인가 하는 이슈가 계속 남아있음. real-time이라던지 ultra-secure 이런 mission-specific한 요구조건들을 맞추도록 어떻게 잘 설계할 것인가는 아직도 연구가 이루어지고 있다.

 

 

 

 

 

 

 

[참고]

Computer Networking A Top-Down Approach 7-th Edition / Kurose, Ross / Pearson