The SDN Control Plane

상위 문서: Network Layer

개요

SDN control plane은 네트워크의 SDN 지원 장치들 사이의 패킷 전달을 제어하고, 해당 장치들과 서비스들을 구성하고 관리하는 네트워크 전역을 관리하는 로직이다. 해당 문서에서는 네트워크의 forwarding 장치를 "패킷 스위치(packet switch)" 혹은 스위치로 부른다. SDN 아키텍처의 네 가지 주요 특징은 다음과 같다:

• Flow-based forwarding: 패킷 스위치에 의한 패킷 forwarding은 transport/network/link layer 각각의 헤더에 있는 어떤 필드 값에 기반할 수 있다. 이는 IP 데이터그램의 목적지 IP 주소에 의존하는 전통적인 라우터 기반의 forwarding 방식과 매우 대조된다. SDN control plane은 figure 1과 같이, 네트워크 내의 모든 스위치 들에 대한 flow table을 계산하고, 관리하고, 설치한다.
• Separation of data plane and control plane: Figure 2에 나타나 있는 것과 같이, 스위치들로 구성된 data plane이 "match + action"에 따라 주어진 역할을 수행할 뿐이다. Control plane은 그러한 data plane을 제어하도록 스위치의 flow table을 결정하고 관리하는 서버와 소프트웨어로 구성된다.
• Network control functions: external to data-plane switches: SDN control plane은 소프트웨어로 구현되며, 이 소프트웨어는 스위치들과 물리적으로 분리 되어있는 서버에서 실행된다. Figure 2에서 볼 수 있듯이, control plane은 두 가지 구성 요소인 SDN 컨트롤러(SDN controller)와 네트워크 제어 애플리케이션(network control application)로 구성된다. SDN 컨트롤러는 네트워크의 상태 정보을 유지하고, 이를 control plane에서 실행되는 네트워크 제어 애플리케이션에 제공하여 해당 애플리케이션들이 data plane에 위치한 네트워크 장치들을 모니터링, 프로그래밍, 제어할 수 있도록 한다.
• A programmable network: 네트워크는 control plane에서 실행되는 네트워크 제어 애플리케이션들을 통해 프로그래밍된다. 해당 애플리케이션들은 SDN control plane의 두뇌와 같은 역할을 하여, SDN 컨트롤러가 제공하는 API를 통해 data plane을 명시하고 제어한다. 예를 들어, 라우팅 네트워크 제어 애플리케이션은 출발지와 목적지 간의 종단 간 경로를 결정할 수 있으며, 이는 SDN 컨트롤러가 유지하는 노드 상태 및 링크 상태 정보를 사용하여 Dijkstra 알고리즘을 실행함으로써 가능하다.

위에서 논의한 특징들로부터, SDN은 네트워크 기능을 분리시킬 수 있다는 것을 보여준다. 스위치, SDN 컨트롤러, 네트워크 제어 애플리케이션은 각각 다른 조직에 의해서 제공될 수 있는 별개의 구성 요소이다. 이는 기존의 전통적인 방식에서는 스위치/라우터가 control plane의 소프트웨어를 내장한 채 통합되어 구현되던 것과는 대조적인 방식이라고 할 수 있다.

Background

전통적으로 network layer는 분산형(distributed)으로, 각 라우터가 스스로 forwarding table을 구성하여 구성되었다. 따라서 라우터는 하드웨어와, 전용 OS로 구성된 monolithic 시스템이었으며, 각 라우터가 OSPF, RIP, BGP 등의 라우팅 프로토콜을 자체적으로 실행하였다. 하지만 이는 중대한 문제점이 있었는데, 다양한 기능 수행을 위해 각각 별도의 middlebox들이 필요하다는 것이었다. Middlebox란, 일반적인 포워딩/라우팅 외의 특수한 네트워크 기능을 수행하는 장비이다. 아래는 middlebox들의 예시이다:

이름	용도
NAT	사설 IP 주소 활용
Firewall, IDS	기업, ISP, 서비스 제공자 보안
Load balancers	데이터센터, 기업망, 모바일 네트워크
Application-specific boxes	CDN, 서비스 제공자 맞춤 장비
Caches	콘텐츠 전송 최적화

따라서, 2005년 이후로 control plane에 대한 논의가 증폭되기 시작하였다.

SDN Layers

SDN 내의 다양한 구성 요소들은 크게 data plane과 control plane으로 구분된다. 이때 control plane은 SDN 컨트롤러와 네트워크 제어 애플리케이션으로, 계층적으로 구분된다. 이 문단에서는 SDN의 계층적으로 어떻게 구분되어 있는지에 대해 더욱 자세히 살펴본다.

Data Plane

Data plane에서 가장 기본이 되는 장치는 스위치이다. 해당 문단에서는 스위치를 기준으로 data plane에 대해 설명한다. 스위치란, 패킷을 forwarding하는 역할을 하는 하드웨어이다. 이는 빠르고, 저렴하며, 단순하다는 특징이 있다. 또한, Generalized Forwarding을 지원한다. 스위치의 다양한 기능을 구현하기 위해 사용되는 flow table은 스위치에 의해 구성되지 않고, SDN 컨트롤러에 의해서 구성된다. 즉, 스위치는 스스로 판단하여 움직이지 않으며, SDN 컨트롤러가 만든 flow table에 따라 기계적으로 움직일 뿐이다.

스위치들은 분명히 SDN 컨트롤러에 의해 제어되며, 이를 위해 표준화되어 있는 인터페이스(API)가 존재한다. 이는 어떤 동작을 제어할 수 있고, 어떤 것이 불가능한지 사전에 제안한다. 이러한 인터페이스에는 대표적으로 OpenFlow가 있다. 또한 스위치와 SDN 컨트롤러가 서로 소통(communicate)하기 위한 프로토콜이 존재하며, OpenFlow가 역시 대표적인 예시이다. 즉, OpenFlow는 API이면서 동시에 프로토콜로도 사용된다. 이 프로토콜을 통해 컨트롤러가 스위치에 명령을 내리거나, 스위치가 flow table을 요청할 수 있다.

SDN Controller

SDN 컨트롤러의 기능은 figure 3와 같이 세 개의 계층으로 나뉜다:

먼저, A communication layer가 있으며, 이는 SDN 컨트롤러와 네트워크 장치 간의 통신을 담당한다. SDN 컨트롤러가 원격의 SDN-지원 스위치나 호스트 또는 기타 장치를 제어하려면, 컨트롤러와 해당 장치 간에 정보를 전송하는 프로토콜이 필요하다. 또한 각 네트워크 장치들은 자신 주변에서 일어나는 변화들이 SDN 컨트롤러에 전달하여 SDN 컨트롤러가 네트워크 상태에 대한 최신 정보를 유지할 수 있도록 해야한다. 이러한 역할을 하는 인터페이스를 흔히 southbound interface라고 한다.

그 다음으로는 a network-wide state-management layer가 있으며, 이는 말 그대로 네트워크 전반의 상태(state)를 관리하고, 최신으로 유지하는 역할을 한다. 예를 들어 SDN control plane이 어떤 data plane의 middlebox에 대해 올바른 결정을 내리기 위해서는 SDN 컨트롤러가 네트워크의 호스트, 링크, 스위치 등에 대한 최신 정보를 습득하고, 유지해야 한다.

마지막으로는 The interface to the network-control application layer가 있다. SDN 컨트롤러는 네트워크 제어 애플리케이션과 northbound interface를 통해 상호작용한다. 이 API는 네트워크 제어 애플리케이션이 하위 계층 내의 네트워크 상태와 flow table을 읽고 쓸 수 있게 한다. 예를 들어, 애플리케이션은 네트워크의 상태가 변경되었을 때 알림을 받을 수 있도록할 수 있으며, 이에 따라 data plane에서 발생한 네트워크 상태 변경에 반응하여 조치를 취할 수 있다.

위와 같이 구성되어 있는 SDN 컨트롤러는 논리적으로 중앙 집중화되어 있다. 즉, data plane이나 네트워크 제어 애플리케이션의 관점에서, SDN 컨트롤러는 단일하고 일체화된 서비스이다. 하지만, 이러한 서비스들과 상태 정보를 저장하는 데이터베이스는 실제로는 여러 대의 서버에 의해 구현된다.

SDN example

해당 문단에서는 SDN 예시 상황을 바탕으로 SDN에 의해 제어되는 스위치들과 SDN 컨트롤러 사이의 상호작용에 대한 설명을 한다. 해당 상황은 Dijkstra 알고리즘을 사용하여 최단 경로 라우팅을 결정하며, figure 4와 같이 구성되어 있다. 이는 라우터 중심 제어 방식(per-router-control)과 비교하여 가지는 차이점은 다음과 같다:

• 해당 예시에서의 Dijkstra 알고리즘은 스위치 밖의 별도 애플리케이션으로서 실행되며, 각 라우터별로 실행되지 않는다.
• 패킷 스위치들은 링크 상태 업데이트를 서로에게 전파하는 대신, SDN 컨트롤러에게만 전송한다.

또한 아래와 같은 상황을 가정하자:

• 스위치 s1과 s2 사이의 링크가 다운되었다.
• 네트워크는 최단 경로 라우팅을 수행하며, 그 결과 s1, s3, s4의 포워딩 규칙이 영향을 받지만, s2는 변화 없다.
• OpenFlow가 communication layer의 프로토콜로 사용되며, control은 링크 상태 라우팅 외에 다른 기능은 수행하지 않는다.

이때 SDN 컨트롤러와 스위치 사이의 상호작용은 다음과 같이 진행된다.

1. 스위치 s1은 자신과 s2 사이의 링크 장애를 감지하고, OpenFlow의 포트 상태(port-status) 메시지를 사용해 SDN 컨트롤러에 링크 상태 변화를 알린다.
2. SDN 컨트롤러는 해당 OpenFlow 메시지를 수신하여 link-state manager에게 전달하고, 해당 manager가 link-state database를 갱신한다.
3. Dijkstra 알고리즘 기반의 LS 라우팅 애플리케이션은 이전에 링크 상태에 변화가 발생할 경우 알림을 받도록 등록해 놓았다.
   • 이 애플리케이션은 SDN 컨트롤러로부터 링크 변화 알림을 수신한다.
4. LS 라우팅 애플리케이션은 업데이트된 링크 상태 정보를 얻기 위해 link-state manager와 상호작용하며, 필요시 link-state management layer의 다른 구성 요소들과도 상호작용할 수 있다.
   • 이후 애플리케이션은 새로운 최단 경로를 계산한다.
5. 라우팅 애플리케이션은 flow table manager와 상호작용하여, 업데이트가 필요한 플로우 테이블 항목들을 결정한다.
6. 플로우 테이블 관리자는 OpenFlow 프로토콜을 사용하여 영향받는 스위치들(s1, s2, s4)의 플로우 테이블을 갱신한다.

위 예시는 SDN을 사용하는 ISP가 기존의 최단 경로 기반 라우팅 대신, 맞춤형 라우팅 방식으로 쉽게 전환할 수 있음을 보여준다. 그 이유는 컨트롤러는 원하는 방식대로 플로우 테이블을 구성할 수 있으므로, 애플리케이션 제어 소프트웨어만 바꾸면 원하는 어떤 형태의 전달 방식도 구현할 수 있기 때문이다. 이러한 변화의 용이성은 전통적인 라우터 기반 제어 평면과 큰 차이가 있다고 볼 수 있다.