[컴퓨터 네트워크] 37. Network Layer (13) : SDN control plane

이전에 정리한 SDN은 data plane 관점에서의 SDN 이었다.

이번엔 control plane 관점에서 SDN을 정리해보자.

즉, 어떤 OpenFlow 기반의 라우팅 테이블이 어떻게 만들어지는지, 누가 만드는지를 살펴보자.

 

SDN

인터넷 네트워크 계층인 기본적으로 분산 라우터 기반의 control approach를 쓰고 있다.

라우터끼리 라우팅 도메인(AS, 정확히는 area) 내에서 정보를 교환해서 각 라우터가 스스로 라우팅 알고리즘도 결정해서 포워딩 테이블을 만들었다.

 

이 방식은 최초의 라우터를 만든 CISCO 사에서 시작했다.

그때는 라우터를 만들면서 당연히 장치에 필요한 소프트웨어를 다 넣어서 같이 팔았다.

온전한 일체형 제품을 판 것이다. (이를 가리켜 monolithic router 라고 한다.)

라우터에 필요한 하드웨어 장치, 소프트웨어 장치, 라우팅 프로토콜을 다 포함시켜서 파는 것이 지금까지의 주류였다.

(시스코 라우터에 들어가는 OS 이름이 iOS 라고 한다. 애플보다 먼저 사용된 이름이라고..)

 

여러 미들박스들이 등장한 이후에도, 각 미드박스들이 동일한 정책을 사용했다.

즉, 하드웨어도 만들고 그 안에 들어가는 소프트웨어까지 다 만들어서 파는 것이다.

(방화벽, 로드밸런서, NAT 등등..)

 

그런데 2000년대 중반부터 SDN이라는 새로운 아이디어가 등장했다.

 

기존에는 이렇게 라우터끼리 서로 정보를 주고받고, 각각 라우팅 알고리즘을 돌려서 포워딩 테이블을 만들었다.

 

하지만 SDN에서는 이렇게 패킷을 처리하고 포워딩하는 것까지는 이전 방식과 같지만, 포워딩 테이블을 만들 때 일종의 서버 역할을 하는 컨트롤러가 만들어서 라우터에 뿌리는 방법을 채택한다.

 

따라서 SDN은 기존의 분산 알고리즘이 아니라, 논리적으로는 중앙화된 컨트롤을 만들자는 아이디어와 같다.

컨트롤러가 권한을 갖고, 컨트롤러가 intelligence를 갖고, 뭔가 알고리즘을 돌려서 나온 결과를 라우터가 수동적으로 받아서 그에 맞게 행동하는 것이기 때문이다.

(그리고 분산 알고리즘은 그 알고리즘이 제대로 동작할 것이라는 것을 증명하는 것이 매우 어렵다. 하지만 중앙화되면 이를 파악하는 것이 더 쉽다.)

 

이 방식을 사용하면 제일 큰 장점이 바로 네트워크 관리의 용이성이다.

중앙에서 하나의 머리가 뭔가를 다 지시하고 결정하기 때문에, 뭔가 실수하거나 그럴 수도 있지만, 그게 아니라면, 굉장히 똑똑하고 착한 존재(컨트롤러)가 실권을 잡고있다면 문제가 없을 것이다.

라우터의 설정을 잘못하는 문제를 미리 방지하는 것이다.

 

만약 라우터마다 각각 설정해야한다면, 라우터 관리가 조금만 소홀이 되어도 (실무자가 지식이 조금 얕다든가..) 큰 문제가 발생할 수 있다. (DV에서 한쪽으로 트래픽이 몰리는 현상과 같은 경우)

 

또한 트래픽 플로우에 대해서도, 혼자 독단적으로 결정하기 때문에, 더 세밀하게 조정할 수 있다.

라우터끼리 합의를 할 필요가 없기 때문이다.

따라서 전에 정리한 것처럼, IP가 매칭된 결과에 따라 다양한 action을 취할 수 있다.

 

이 아이디어를 구현한 표준 프로토콜들 중 유명한 것이 OpenFlow 이다.

SDN은 굉장히 넓은 개념이기 때문에 Open Flow는 SDN의 일부라고 보면 된다.

SDN의 컨트롤러가 실제로 라우터나 스위치를 컨트롤할 때 사용하는 일종의 인터페이스인 셈이다.

 

---

SDN의 등장 배경

 

과거에는 하나의 컴퓨터에서 하드웨어, OS, 유용한 소프트웨어까지 모두 한번에 팔았었다.

 

하지만 지금은 각각의 계층이 분리되고, 각 계층마다 서로 정보를 주고받는 open interface가 존재한다.

따라서 많은 혁신 기술, 프로그램들이 등장하고, 많은 회사, 플레이어들이 등장해서 더 좋은 제품이 빠르게 나오게 되었다.

 

SDN의 지향점이 바로 이와 같은 것이다.

과거에는 시스코에서 모든 것을 다 만들었다면, 이제는 하드웨어 OS 소프트웨어를 분리해보자는 것이다.

---

전통적인 라우팅 방법의 문제점

 

위 그림과 같은 네트워크가 존재한다고 해보자.

그리고 컴퓨터에서 서버로 가는 트래픽은 위와 같은 최단 경로를 거친다.

 

 

그런데 만약 내가 z까지 가는 경로를 위와 같은 경로를 사용하고 싶다면 어떨까?

기존 방법에서는 link 코스트를 바꿔서 억지로 이 경로를 선택하게끔 해야했을 것이다.

또는 아예 새로운 라우팅 프로토콜을 고안해서 이 경로가 나오도록 하는 알고리즘을 짤 수 밖에 없다.

(사실상 불가능하다고 보는 것이다..)

 

---

 

다른 문제는 로드밸런싱 문제다.

왜 경로를 하나만 사용해야 하나? 라는 문제다.

두 경로를 따라서 트래픽을 분리하면 조금 더 빨리 도착할 수 있지 않을까?

(물론 목적지에서 이 두 트래픽을 합치는 문제가 있다.)

 

기존 라우팅 프로토콜 방식에서는 이게 불가능하다.

새로운 알고리즘을 만들지 않는 이상 할 수 없다.

---

 

세번째 문제는 서로 다른 곳에서 출발한 트래픽의 목적지가 같은 경우다.

이때 기존 라우팅 알고리즘에서는 w 라우터에서 같은 목적지로 가는 패킷을 받았을 때 같은 경로로 보낸다.

근데 경우에 따라서는 이를 구분하여 서로 다른 경로로 보내고 싶을 수도 있다.

이는 전통적인 라우팅 알고리즘으로는 할 수 없다.

 

하지만 SDN은 위 3가지 상황을 모두 구현할 수 있다.

---

SDN 구조

 

SDN은 위와 같은 구조를 가진다.

각각의 포워딩 테이블은 flow-based 방식으로 컨트롤러가 생성하여 보내준다.

routing, access control, load balance 와 같은 것들은 컨트롤러가 사용하는 기능을 말한다.

 

 

전체적인 계층도를 밑에서부터 보면,

제일 밑에는 data plane 영역으로, SDN 기능을 적용한 여러 범용 스위치 (commodity switch) 로 구성되어 있다.

이 스위치들이 SDN의 실질적인 기능을 수행한다.

각 스위치에는 컨트롤러가 계산해서 만든 flow table이 들어간다.

그리고 각 스위치와 컨트롤러는 OpenFlow 라는 프로토콜 (API) 를 사용한다.

 

 

SDN 컨트롤러는 네트워크의 OS 역할을 한다.

실제로 ONOS, ODL 과 같은 컨트롤러들이 널리 사용된다.

 

컨트롤러는 제어정보 (네트워크 상태 정보)를 관리하며, 이 정보를 각 스위치에 내려보내면, 각 스위치가 제어정보에 따라서 액션을 취하는 형태를 갖는다.

스위치는 컴퓨터의 하드웨어에 해당하는 것과 같고, 컨트롤러는 OS, 그 위쪽은 어플리케이션에 해당하는 것과 같다.

상위 계층과 northbound API를 통해 상호작용하고, 아랫 계층과는 southbound API를 통해 상호작용한다.

 

컨트롤러는 (단수형태긴 하지만) 매우 중요한 역할을 하기 때문에, 성능, 확장성, 견고성 등을 높이기 위해 분산 시스템으로 구현되어 있다.

(해커의 해킹이나 하드웨어 고장 등에 잘 대처해야 한다.)

 

 

마지막 상위 계층은 network-control app 이라고 부른다.

컨트롤러라는 OS를 통해 스위치를 적절하게 통제하는 brain 역할을 수행한다.

라우팅, 로드밸런스, 방화벽과 같은 기능을 수행한다.

 

이 어플리케이션들은 라우터 벤더 / 라우터 제조사들과 무관하므로, 3rd party 어플리케이션을 가져다가 사용할 수도 있다.

 

SDN Controller

네트워크 OS 역할을 하는 SDN 컨트롤러에 대해 더 자세히 정리해보자.

 

SDN 컨트롤러는 다시 세 영역으로 구분할 수 있다.

맨 아래에는 OpenFlow와 SNMP (Simple Network Management Protocol) 이 존재한다.

OpenFlow 프로토콜을 사용해서 아랫 계층과 통신한다.

(SNMP를 사용할 수 있지만 보통은 OpenFlow를 더 많이 사용한다.)

 

이때 아랫 계층에 보낼 정보는 그 중간에 저장되어 있다.

(network-wde state management, 즉 네트워크 전반의 상태를 관리하는 영역)

분산 데이터베이스 역할을 수행한다.

 

예를 들면 다익스트라 알고리즘을 돌리기 위한 각 라우터와 라우터 사이 link-state 정보와

SDN에서는 라우터와 라우터 사이 말고도 end-system 호스트에 대해서도 어떤 호스트와 어떤 호스트 사이의 통신은 못하게 막는 것과 같이 programmable 한 제어가 가능하기 때문에 host 정보도 저장한다.

또 switch 정보(물리적으로 몇 개의 포트가 있는지, switch fabric은 어느정도의 성능을 갖고 있는지에 대한 정보) 등을 갖고 있다.

 

이 외에도 라우터가 사용할 flow table, 여러가지 통계 정보들도 갖고 있다.

 

그 위에는 interface lyaer to network control apps 라고 해서, 네트워크 어플리케이션과 통신하는 추상 API를 갖고 있다.

즉, 가운데는 데이터가 저장된 자료구조가 들어있고, 알고리즘은 상위 계층 어플리케이션이 수행하기 때문에, 그 둘 사이를 연결해주는 역할을 한다고 볼 수 있다.

 

맨 위에는 network graph (전체 토폴로지), RESTful API, intent 등이 들어있다.

 

REST (REpresentational State Transfer)는 소프트웨어 아키텍처이다.

 

intent는 ONOS 라는 컨트롤러에서 제안한 것으로 host 사이의 통신을 제어하기 위해 등장했다.

high level 어플리케이션의 의도(intent)를 스위치에 전달하기 위해 사용한다.

 

---

OpenFlow protocol

컨트롤러와 스위치 사이에서 동작하는 프로토콜이다.

TCP를 사용하여 메세지를 교환하며, 보통 메세지는 보안을 위해 암호화까지 한다.

 

컨트롤러에서 스위치로 가는 메세지와, 스위치에서 컨트롤러로 가는 메세지로 구분된다.

(controller-to-swtich, switch-to-controller)

 

엄밀하게는 OpenFlow API 와 프로토콜은 구분된다.

API는 좀 더 일반적인 action을 명세하는데 사용된다.

(좀 더 상위의, 추상적인 내용)

 

Controller - to - switch

크게 4가지 종류의 메세지를 사용한다.

 

1. Feature

컨트롤러가 스위치에게 쿼리를 보내서 스위치의 feature (특성) 정보를 요청하면, 스위치가 이에 응답한다.

 

2. Configure

스위치 configuration을 설정하도록 세팅하는 목적으로 보낸다.

물론 스위치 configuration을 물어보는 쿼리를 보낼 수도 있다.

예를 들면 스위치가 트래픽을 분류해서 차등화된 서비스를 제공하도록 설정값을 변경할 수 있다.

 

3. modify-state

flow-table의 내용을 추가/삭제/수정하도록 지시하는 목적으로 사용한다.

 

4. packet-out

swtich-to-controller에서 packet-in 과 쌍으로 사용되는 유형의 메세지다.

스위치가 받은 패킷을 스위치가 어떻게 처리해야 할 지 모를 때, 컨트롤러에게 패킷에 대한 처리 방법을 물어볼 수 있는데, 이때 packet-in 요청을 보낸다. 컨트롤러는 이에 대해 packet-out 메세지를 보내서 응답한다.

(어떤 output - port 로 보내라든가, 보내지 말라든가)

 

Switch - to - Controller

크게 3가지 종류의 메세지를 사용한다.

 

1. packet - in

상술했듯, 특정 패킷이 들어왔을 때, 이 패킷에 대한 처리 방법을 문의하는 메세지다.

 

2. flow-removed

컨트롤러가 flow table의 엔트리를 지우라고 요청했을 때, 엔트리를 지우고 나서 보내는 응답이다.

 

3. port status

컨트롤러에게 자신의 포트 정보를 알리는 용도로 사용된다.

(물리적으로 포트가 떨어졌다든지)

 

사실 네트워크 operator는 이 메세지를 직접 사용하지 않는다.

OpenFlow API 라는 프로그래밍하기 편한 높은 레벨의 추상화를 사용한다.

 

---

Example

 

위와 같은 구조의 SDN이 있다고 해보자.

 

먼저 s1 라우터가 link failure 를 감지했다고 해보자.

그러면 OpenFlow port status 메세지를 사용하여 컨트롤러에게 포트 상태의 변경을 알린다.

 

그러면 SDN 컨트롤러는 이 메세지를 수신하고, link state 정보를 수정한다.

 

그러면 변경된 링크 정보를 기반으로 network graph를 수정한다.

그리고 수정한 그래프를 토대로 다시 다익스트라 알고리즘을 돌린다.

 

다익스트라 알고리즘 라우팅 어플리케이션은 링크 정보가 바뀔때마다 호출되도록 설정되어 있어서, 그래프 상태가 바뀔 때마다 호출된다.

 

 

다익스트라 알고리즘을 수행하기 위해서 link state 정보에 접근하여 변경된 링크 정보를 확인한다.

그리고 새로운 경로를 계산한다.

 

 

새로운 경로를 스위치에 반영하기 위해서, 먼저 flow table을 수정한다.

 

그리고 컨트롤러는 OpenFlow를 사용해서 각각의 라우터에게 변경된 flow table을 뿌려서 변경이 필요한 라우터들에게 업데이트 하도록 한다. 이때 s3은 이 정보를 받지 않았다. 왜냐하면 링크정보의 변경과 상관없이 s3의 플로우 테이블은 변하지 않았기 때문이다. (s3 입장에서는 기존 다익스트라 방식으로 계산한 s1, s2, s4 로 가는 최단경로가 모두 변하지 않았다.)

 

---

SDN 이 당면하고 있는 과제

 

1. control plane을 단단하게 만들기

지시를 내리는 컨트롤러 부분이 매우 중요하기 때문에 믿을 수 있고, 성능이 좋아야 하고, 보안도 좋고, 확장성도 좋아야 한다.

특히 failure 에 대해 견고해야 하기 때문에, 기존 reliable 분산 시스템에 대한 이론을 고려한다.

또 보안이 중요하므로 security도 잘 고려해야 한다.

어떤 상황에서도 스위치를 잘 제어해야 하기 때문에 dependability도 필요하다.

 

2. 네트워크, 프로토콜이 특정 상황에 적합한 요구사항을 원할 때

실시간성, 매우 높은 신뢰성, 매우 높은 보안성 등을 어떻게 수용할 수 있지 고민해야 한다.

 

예를 들면 실시간성을 제공하기 위해 어플리케이션 레벨에서 어떤 알고리즘을 사용해야 할지, 그 알고리즘을 사용하기 위해서 Contorller에서는 어떤 데이터베이스, 자료구조가 필요할 지 등을 고민해야 한다.

 

3. 하나의 AS 범위를 벗어나기

현재 SDN은 하나의 AS 내에서만 사용되는데, 이를 벗어나서 전체 인터넷 스케일로 사용될 수 있는지도 고민해야 한다.

AS를 벗어나려면 모든 AS가 SDN을 사용해야 하고, 어떤 컨트롤러를 사용할 지 AS 사이의 합의가 필요해서 쉽지 않다.

 

4. 5G, 6G

5G, 6G와 같은 셀룰러 네트워크에서 SDN은 중요한 역할을 수행한다.

---

SDN과 기존 라우터 프로토콜의 미래

- SDN으로 계산한 포워딩 테이블과, 라우터로 계산한 포워딩 테이블

기존 방식은 오로지 포워딩 테이블만을 만들기 위해 존재하는 것이지만, SDN은 포워딩 테이블을 만드는 것이 여러 기능 중 하나일 뿐이다.

 

- SDN을 사용해서 혼잡 제어를 할 수도 있다.

기존에는 end system이 혼잡 제어를 하다보니 즉각적인 대응도 힘들고, 혼잡의 발생 위치를 파악하는 것도 힘들었다. (Excplicit이 아니라면) 하지만 SDN을 사용하면 라우터로부터 정보를 받아서 직접 혼잡을 제어할 수도 있을 것이다.

 

그래서 앞으로 SDN이 어떻게 진화해 나갈지는 기대가 된다고 할 수 있다.