The SDN Control Plane

youngwiki
Pinkgo (토론 | 기여)님의 2025년 5월 9일 (금) 06:46 판 (→SDN Layers)

상위 문서: 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 컨트롤러는 네트워크의 상태 정보[1]을 유지하고, 이를 control plane에서 실행되는 네트워크 제어 애플리케이션에 제공하여 해당 애플리케이션들이 data plane에 위치한 네트워크 장치들을 모니터링, 프로그래밍, 제어할 수 있도록 한다.
  • A programmable network: 네트워크는 control plane에서 실행되는 네트워크 제어 애플리케이션들을 통해 프로그래밍된다. 해당 애플리케이션들은 SDN control plane의 두뇌와 같은 역할을 하여, SDN 컨트롤러가 제공하는 API[2]를 통해 data plane을 명시하고 제어한다. 예를 들어, 라우팅 네트워크 제어 애플리케이션은 출발지와 목적지 간의 종단 간 경로를 결정할 수 있으며, 이는 SDN 컨트롤러가 유지하는 노드 상태 및 링크 상태 정보를 사용하여 Dijkstra 알고리즘을 실행함으로써 가능하다.

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

또한 SDN control plane은 논리적으로 중앙 집중화된(logically centralized) control plane이다. control plane이 이렇게 구성되는 이유는 아래 3가지가 있다:

  1. easier network management: 별개의 라우터가 forwarding table을 잘못 구성하는 것을 방지하고, traffic flow를 유연하게 제어할 수 있다.
  2. table-based forwarding: OpenFlow등을 통해 별개의 라우터의 forwarding 작업을 중앙에서 프로그래밍할 수 있다.
    • 중앙화된 forwarding 방식: 하나의 SDN 컨트롤러에서 테이블을 계산한 후 분배하므로 간단하다.
    • 분산형의 forwarding 방식: 모든 라우터가 각자 자신의 테이블을 계산하므로, 복잡하고 오류가능성이 증가한다.
  3. SDN을 통해서 폐쇄형, 수직 통합 구조에서 개방형, 수평 분산 구조로 전환할 수 있다. 이를 통해서 산업의 규모를 키우고, 더 빠른 혁신을 가능케 할 수 있다.

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에 대한 논의가 증폭되기 시작하였다.

또한, 전통적인 라우팅 방식은 traffic 엔지니어링이 굉장히 힘들다. 예를 들어, figure에서 u→z 트래픽은 u→v→w→z의 경로를 따라, x→z 트래픽은 x→w→y→z의 경로를 따라 이동하기를 원한다고 하자. 전통적인 링크 상태 라우팅(OSPF 등)은 단지 링크의 비용을 조정해서 경로를 설정해야 하기 때문에, 유연성이 부족하다. 또한 u→z 트래픽을 u→v→w→z의 경로와 u→x→y→z의 경로를 따라 분산(load balancing)하고 싶다고 하자. 이는 전통적인 라우팅 방식에서는 불가능하거나, 하고자 하여도 새로운 라우팅 알고리즘을 필요로 한다. 또한, 어떤 라우터는 특정 subnet으로부터 출발한 트래픽과 다른 subnet으로부터 출발한 트래픽을 구분하여 처리하길 원할 수도 있다. 하지만 전통적인 목적지 기반의 라우팅에서는 트래픽의 종류를 구분하지 않으므로 불가능하다.[3]

SDN Layers

SDN의 기본 구조는 figure가 자세히 보여주고 있다. 아래는 해당 figure에서 얻을 수 있는 몇가지 중요한 특징들이다:

  1. flow-based forwarding: OpenFlow 등으로 정의된 플로우 단위 기반 forwarding에 해당한다.
  2. control plane / data plane 분리: 스위치는 기계적으로 forwarding만을 할 뿐, 실제적인 제어는 중앙의 컨트롤러에서 수행된다.
  3. control logic이 switch 외부에 존재: control logic이 control plane에 존재하므로, 스위치는 어떠한 제어도 수행하지 않는다.
  4. control 애플리케이션의 프로그래밍 가능성: load balancing, 라우팅, 보안 등의 복잡합 작업들을 네트워크 제어 애플리케이션이 수행한다.

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 컨트롤러의 기능은 다음의 세가지가 있다:

  1. SDN 컨트롤러와 네트워크 장치 간의 통신을 담당한다.
    • SDN 컨트롤러는 아래 data plane의 스위치들과 소통하며, 이때 사용하는 것이 southbound API이다.
    • 대표적으로는 OpenFlow가 존재하며 이는 패킷 정보를 받아오거나(Packet-In), 플로우 테이블의 설치/삭제(Flow-Mod), 상태 통계 요청(Stats Request)등의 역할을 한다.
  2. SDN 컨트롤러는 상위의 네트워크 제어 애플리케이션(라우팅, firewall, load balancing 등을 담당)과 소통한다.
    • SDN 컨트롤러는 상위의 네트워크 제어 애플리케이션(라우팅, firewall, load balancing 등을 담당)과 소통하며, 이때 사용하는 것이 northbound API이다.
    • 이 API는 네트워크 제어 애플리케이션이 하위 계층 내의 네트워크 상태와 flow table을 읽고 쓸 수 있게 한다.
    • 예를 들어, 애플리케이션은 네트워크의 상태가 변경되었을 때 알림을 받을 수 있도록할 수 있으며, 이에 따라 data plane에서 발생한 네트워크 상태 변경에 반응하여 조치를 취할 수 있다.
  3. SDN 컨트롤러는 전체 네트워크의 상태를 지속적으로 저장하고, 갱신한다.
    • 저장되는 정보에는 각 링크의 사용량이나, 지연, 장애 여부 등이 있다.
    • 이렇게 저장되고 관리되는 정보를 바탕으로 최적의 경로를 계산하고, 부하를 계산하는 등의 다양한 라우팅 정책을 실행할 수 있다.

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

Network-control Apps

네트워크 제어 애플리케이션이란, SDN 구조의 실질적인 지능을 담당한다. 이들은 네트워크의 동작을 정의하고 결정하는 알고리즘이나 로직을 포함한다. 이 애플리케이션들은 직접 data plane의 스위치를 제어하지는 않으며, 대신 SDN 컨트롤러가 제공하는 northbound API를 이용하여 flow table 설치, forwarding rule 설정, 네트워크 상태 조회 등을 실행한다. 즉, 애플리케이션이 명령하고, SDN 컨트롤러가 이를 실행하는 구조이다.

기존의 네트워크에서는 Cisco와 같은 특정 기업이 라우터를 통해서 모든 소프트웨어와 하드웨어를 한번에 통합하여 제공했지만, 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가 기존의 최단 경로 기반 라우팅 대신, 맞춤형 라우팅 방식으로 쉽게 전환할 수 있음을 보여준다. 그 이유는 컨트롤러는 원하는 방식대로 플로우 테이블을 구성할 수 있으므로, 애플리케이션 제어 소프트웨어만 바꾸면 원하는 어떤 형태의 전달 방식도 구현할 수 있기 때문이다. 이러한 변화의 용이성은 전통적인 라우터 기반 제어 평면과 큰 차이가 있다고 볼 수 있다.

각주

  1. ↑ 예: 원격 링크, 스위치, 호스트의 상태 등...
  2. ↑ API는 Application Programming Interface의 약자이다. 이는 어떤 소프트웨어가 다른 소프트웨어와 통신하거나, 그 기능을 사용할 수 있도록 정의된 규칙/명령어들의 집합을 의미한다.
  3. ↑ 즉, LS (링크 상태)나 DV (거리 벡터) 기반 라우팅은 이런 세밀한 제어를 지원하지 않는다.
원본 주소 "https://junhoahn.kr/junyoung/index.php?title=The_SDN_Control_Plane&oldid=2401"