소프트웨어 정의 네트워크(SDN) 제어 평면

이 절에서는 4.4절에서 사용한 SDN 용어들을 다시 채택하여
네트워크의 포워딩 장비들은 ‘패킷 스위치’ 또는 그냥 ‘스위치’라고 부를 것이다.

이 스위치들에서의 포워딩 결정은 네트워크 계층에서의 출발지/목적지 주소, 링크 계층에서의 출발지/목적지 주소 외에도
트랜스포트 계층, 네트워크 계층, 링크 계층 패킷 헤더의 다른 많은 값에 기반하여 이루어진다.

SDN 구조의 특징

플로우 기반 포워딩

SDN으로 제어되는 스위치들에서의 패킷 전달은 트랜스포트 계층, 네트워크 계층, 또는 링크 계층 헤더의 어떤 값을 기반으로 하든 이루어질 수 있다.

이는 앞 절에서 살펴본,
IP 데이터그램의 포워딩이 온전히 데이터그램의 목적지 주소를 기반으로 이루어지는 전통적인 라우터 기반 포워딩과는 매우 대조적인 특성이다.

💡 SDN에서는 모든 네트워크 스위치의 플로우 테이블 항목들을 계산하고 관리, 설치하는 일이 모두 SDN 제어 평면의 임무다.

데이터 평면과 제어 평면의 분리

데이터 평면

• 네트워크의 스위치들로 구성된다. (이들은 상대적으로 단순하지만 빠른 장치들)
• 자신들의 플로우 테이블 내용을 기반으로 ‘매치 플러스 액션’을 수행한다.

제어 평면

• 서버와 스위치들의 플로우 테이블을 결정, 관리하는 소프트웨어로 이루어진다.

네트워크 제어 기능이 데이터 평면 스위치 외부에 존재

SDN 제어 평면은 소프트웨어로 구현되어 있으며, 네트워크 스위치로부터 멀리 떨어진 별도의 서버에서 수행된다.

아래의 그림에서 볼 수 있듯, 제어 평면은 2개의 구성요소로 이루어진다.

1. SDN 컨트롤러(또는 네트워크 운영체제)
2. SDN 네트워크 제어 애플리케이션들의 집합

SDN 컨트롤러는

1. 정확한 상태정보(e.g., 원격 링크와 스위치, 호스트들의 상태)를 유지하고,
2. 이 정보를 네트워크 제어 애플리케이션들에 제공하며,
3. 애플리케이션들이 하부 네트워크 장치들을 모니터하고 프로그램하고 제어까지 할 수 있도록 수단을 제공한다.

그림에서의 컨트롤러는 단일 중앙 서버의 형태이지만, 실제로 컨트롤러는 논리적으로만 중앙 집중 형태다.

(일반적으로는 협업 능력과 확장성, 높은 이용성을 갖도록 몇 개의 서버에 구현)

프로그램이 가능한 네트워크

제어 평면에서 수행 중인 네트워크 제어 애플리케이션을 통해 네트워크를 프로그램할 수 있다.

이 애플리케이션들은 SDN 컨트롤러가 제공하는 API를 이용하여 네트워크 장치들에 있는 데이터 평면을 명세하고 제어한다.

e.g.,
라우팅 네트워크 제어 애플리케이션은 SDN 컨트롤러가 갖고 있는 노드 상태 및 링크 상태 정보에 기반한 다익스트라 알고리즘을 수행하여
출발지와 목적지 사이의 종단 간 경로를 결정한다.

SDN 제어 평면

: SDN 컨트롤러와 SDN 네트워크 제어 애플리케이션

SDN 컨트롤러

컨트롤러의 기능은 크게 3개의 계층으로 구성된다.

1. 네트워크 제어 애플리케이션 계층과의 인터페이스
2. 네트워크 전역 상태 관리 계층
3. 통신 계층

통신 계층: SDN 컨트롤러와 제어받는 네트워크 장치들 사이의 통신

💡 제어받는 장치들과의 통신

• SDN 컨트롤러가 원격의 SDN 기능이 가능한 장치들의 동작을 제어하려면 컨트롤러와 그 장치들 사이에 정보를 전달하는 프로토콜이 필요하다.
• 장치는 주변에서 관찰한 이벤트를 컨트롤러에 알려, 네트워크 상태에 대한 최신의 정보를 제공해야 한다.

컨트롤러와 제어받는 장치들 간의 통신은 ‘사우스바운드(southbound)’라고 알려진 컨트롤러 인터페이스를 넘나든다.

이 통신 기능을 제공하는 구체적 프로토콜은 OpenFlow이며, 이는 모두는 아니지만 대부분의 SDN 컨트롤러에 구현되어 있다.

네트워크 전역 상태 관리 계층

💡 네트워크 전역에 분산되고 견고한 상태 관리

SDN 제어 평면의 궁극적인 제어 결정을 위해서는
컨트롤러가 네트워크 호스트와 링크, 스위치, 그리고 SDN으로 제어되는 다른 장치들에 대한 최신 정보를 알아야 한다.

제어 평면의 궁극적인 목적은 다양한 제어 장치들의 플로우 테이블을 결정하는 것이므로 컨트롤러도 이 테이블들의 복사본을 유지해야 할 것이다.

스위치의 플로우 테이블이 가지는 카운터들과 같은 이러한 정보 조각들은 모두 SDN 컨트롤러가 유지하는 네트워크 전역 ‘상태’의 예들이다.

네트워크 제어 애플리케이션 계층과의 인터페이스

💡 네트워크 제어 애플리케이션들을 위한 인터페이스와 추상화

컨트롤러는 ‘노스바운드(northbound)’ 인터페이스를 통해 네트워크 제어 애플리케이션과 상호작용한다.

이 API는 네트워크 제어 애플리케이션이 상태 관리 계층 내의 네트워크 상태 정보와 플로우 테이블을 읽고 쓸 수 있도록 해준다.

---

SDN 컨트롤러는 외부에서 볼 때 ‘논리적으로 중앙 집중된’, 잘 짜여진 하나의 서비스로 보일 수 있지만,

이 서비스들과 상태 정보를 보관하기 위한 데이터베이스는
장애 허용성(fault tolerance)과 높은 가용성, 또는 다른 성능상의 이유로 실제로는 분산된 서버의 집합에 구현된다.

근래의 컨트롤러는 논리적으로는 중앙 집중 형태이나 물리적으로는 분리된 컨트롤러 플랫폼 구조이다.

이런 구조는 제어되는 장치와 네트워크 제어 애플리케이션에게 늘어나는 장치 수에 따라 확장 가능한 서비스와 높은 가용성을 제공한다.

OpenFlow 프로토콜

• OpenFlow 프로토콜은 SDN 컨트롤러와 SDN으로 제어되는 스위치 또는 OpenFlow API를 구현하는 다른 장치와의 사이에서 동작한다.
• OpenFlow 프로토콜은 TCP상에서 디폴트 포트 번호 6653을 가지고 동작한다.

컨트롤러가 제어되는 스위치로 전달하는 중요한 메시지는 다음과 같다.

• 설정 : 이 메시지는 컨트롤러가 스위치의 설정 파라미터들을 문의하거나 설정할 수 있도록 한다.

• 상태 수정 : 이 메시지는 컨트롤러가 스위치 플로우 테이블의 엔트리를 추가/제거 또는 수정하거나 스위치 포트의 특성을 설정하기 위해 사용한다.

• 상태 읽기 : 이 메시지는 컨트롤러가 스위치 플로우 테이블과 포트로부터 통계 정보와 카운터값을 얻기 위해 사용한다.

• 패킷 전송 : 이 메시지는 컨트롤러가 제어하는 스위치의 지정된 포트에서 특정 패킷을 내보내기 위해 사용한다.
  이 메시지 자체는 페이로드 부분에 보낼 패킷을 포함한다.

SDN으로 제어되는 스위치에서 컨트롤러로 전달되는 주요 메시지는 다음과 같다.

• 플로우 제거 : 이 메시지는 컨트롤러에게 어떤 플로우 테이블 엔트리가 시간이 만료되었거나 상태 수정 메시지를 수신한 결과로 삭제되었음을 알린다.
• 포트 상태 : 이 메시지는 스위치가 컨트롤러에게 포트의 상태 변화를 알리기 위해 사용된다.
• 패킷 전달
  • 4.4절에서 스위치 포트에 도착한 패킷 중에서 플로우 테이블의 어떤 엔트리와도 일치하지 않는 패킷은 처리를 위해 컨트롤러에게 전달된다고 했다.
  • 어떤 엔트리와 일치한 패킷 중에서도 일부는 그에 대한 작업을 수행하기 위해 컨트롤러에게 보내지기도 한다.
    이 메시지는 그러한 패킷을 컨트롤러에게 보내기 위해 사용한다.

데이터 평면과 제어 평면의 상호작용: 예제

아래 그림은 SDN의 제어를 받는 스위치와 SDN 컨트롤러 간의 상호작용에 대한 것이다.

• 여기서는 다익스트라 알고리즘이 최단 경로를 결정하기 위해 사용되는데,
  다익스트라 알고리즘은 패킷 스위치 외부에서 별도의 애플리케이션으로 수행된다.

• 패킷 스위치들이 링크 갱신 정보를 서로 간이 아닌 SDN 컨트롤러에게 전송한다.

• 최단 경로 알고리즘이 사용되고 있다.
• 스위치 s1과 s2 사이의 링크가 단절되었다고 가정해보자.
  • 따라서 s1, s3, s4로 들어오고 나가는 플로우 포워딩 규칙은 변경되었으나, s2의 동작은 바뀌지 않았다고 가정한다.
• 통신 계층 프로토콜로는 OpenFlow가 사용된다.
• 제어 평면은 링크 상태 라우팅 외의 기능은 수행하지 않는다.

1. 스위치 s2와의 링크 단절을 감지한 s1은 OpenFlow의 포트 상태 메시지를 사용하여 링크 상태의 변화를 SDN 컨트롤러에게 알린다.

2. 링크 상태 변화를 알리는 OpenFlow 메시지를 받은 SDN 컨트롤러는 링크 상태 관리자에게 알리고,
   링크 상태 관리자는 링크 상태 데이터베이스를 갱신한다.

3. 다익스트라 링크 상태 라우팅을 담당하는 네트워크 제어 애플리케이션은 링크 상태의 변화가 있을 경우 알려달라고 이전에 등록해두었다.
   이 애플리케이션이 링크 상태의 변화에 대한 알림을 받게 된다.

4. 링크 상태 라우팅 애플리케이션이 링크 상태 관리자에게 요청하여 갱신된 링크 상태를 가져온다.

   • 이 작업은 상태 관리 계층에 있는 다른 구성 요소의 도움이 필요할 수도 있다.
   • 그 후 새로운 최소 비용 경로를 계산한다.

5. 링크 상태 라우팅 애플리케이션은 갱신되어야 할 플로우 테이블을 결정하는 플로우 테이블 관리자와 접촉한다.

6. 플로우 테이블 관리자는 OpenFlow 프로토콜을 사용하여 링크 상태 변화에 영향을 받는 스위치들의 플로우 테이블을 갱신한다.

   • 이 예에서는 s1, s2, s4가 이에 해당한다.
   • s1 : 이제부터 s2를 목적지로 하는 패킷을 s4로 보낸다.
   • s2 : 이제부터 s1로부터의 패킷을 중간 스위치 s4를 통해 받는다.
   • s4 : s1에서 s2로 가는 패킷을 전달해야 한다.

💡 컨트롤러가 플로우 테이블을 마음대로 변경할 수 있기 때문에
단순히 애플리케이션 제어 소프트웨어를 바꿈으로써 원하는 어떤 형태의 포워딩 방식도 구현할 수 있다.

SDN: 과거와 미래

과거

SDN이 많은 관심을 받게 된 것은 비교적 최근의 현상이지만,
SDN의 기술적인 뿌리, 특히 데이터와 제어 평면의 분리를 상당히 거슬러 올라간다.

• 2004년에 [Feamster 2004, Lakshman 2004, RFC 3746]은 모두 네트워크 데이터와 제어 평면의 분리를 주장했다.

• 에탄(Ethane) 프로젝트[Casado 2007]는
  (1) ‘매치 플러스 액션’ 플로우 테이블이 있는 간단한 플로우 기반 이더넷 스위치,
  (2) 플로우 수용 및 라우팅을 관리하는 중앙 집중식 컨트롤러,
  (3) 그리고 플로우 테이블의 어떤 엔트리와도 일치하지 않는 패킷을 스위치에서 컨트롤러로 전달하는 개념을 개척했다.

  
  
  • 300개 이상의 에탄 스위치로 구성된 네트워크가 2007년에 운영되었다.
  • 에탄은 OpenFlow 프로젝트로 빠르게 진화했다.

미래

SDN 혁명은 ‘단순한 상용 스위칭 하드웨어와 정교한 소프트웨어 제어 평면’으로
’모든 기능이 하나로 통합된 스위치와 라우터(데이터 및 제어 평면 모두)’를 교체해나가고 있다.

네트워크 기능 가상화(network functions virtualization, NFV)로 알려진 SDN의 일반화는 단순한 상용 서버, 스위칭 및 저장소를 가지고
복잡한 미들박스(전용 하드웨어 및 미디어 캐싱/서비스를 위한 고유의 소프트웨어를 가진 미들박스)를 혁신적으로 교체하는 것을 목표로 한다.

연구의 중요한 두 번째 영역은 SDN 개념을 AS 내부 설정에서 AS 간 설정으로 확장하려는 것이다.

SDN 컨트롤러 사례연구: OpenDaylight와 ONOS 컨트롤러

일부 SDN 컨트롤러는 특정 회사를 위한 고유 제품이다.

그러나 더 많은 컨트롤러는 오픈소스이며 다양한 프로그래밍 언어로 구현된다.

가장 최근에는 OpenDaylight 컨트롤러와 ONOS 컨트롤러가 산업계에서 상당한 지지를 얻었다.

이 둘은 모두 오픈소스이며, 리눅스 재단(Linux Foundation)과 공동으로 개발 중이다.

OpenDaylight 컨트롤러

아래 그림은 ODL(OpenDaylight) 컨트롤러 플랫폼[OpenDaylight 2020, Eckel 2017]의 간략한 구조다.

• ODL의 기본 네트워크 서비스 기능들은 컨트롤러의 핵심부에 있다.

• 서비스 추상 계층(Service Abstraction Layer, SAL)

  • 컨트롤러 구성요소와 애플리케이션이 서로의 서비스를 호출하고 그들이 생성한 이벤트에 대한 알림을 받을 수 있도록 한다.
  • OpenFlow와 SNMP(Simple Network Management Protocol) 및 NETCONF(Network Configuration) 같은,
    ODL 컨트롤러와 제어 장치 간 프로토콜들에게 균일한 추상 인터페이스를 제공한다.

• OVSDB(Open vSwitch Database Management Protocol)는 데이터 센터 스위칭을 관리하는 데 사용된다.
  (데이터 센터 네트워킹에 대해서는 6장에서 다룸)

가장 상단의 네트워즈 조정 및 애플리케이션부는
데이터 평면의 포워딩과 방화벽 및 로드 밸런싱 같은 서비스들이 제어 장치에서 어떻게 수행될지를 결정한다.

ONOS 컨트롤러

아래 그림은 ONOS 컨트롤러[ONOS 2020]를 간략화한 모습이다.

표준 컨트롤러와 유사하게 3개의 계층을 구분할 수 있다.

1. 노스바운드 추상화 프로토콜

   • ONOS는 의도(intent) 프레임워크이다.
     • 이는 애플리케이션이 해당 서비스가 구체적으로 어떻게 구현되는지 몰라도
       높은 수준의 서비스(e.g., 어떤 호스트 A와 B 사이의 연결을 설정)를 요청할 수 있게 해준다.
   • 상태 정보가 노스바운드 API를 통과하여
     네트워크 제어 애플리케이션에게 동기적(직접 질의를 통해) 또는 비동기적(e.g,. 네트워크 상태가 변화했을 때 알림 기능)으로 제공된다.

2. 분산 코어

   • 네트워크 링크, 호스트, 장치의 상태는 ONOS의 분산 코어에 유지된다.
   • ONOS 코어는 서비스 복제와 인스턴스 간 협력 메커니즘을 제공함으로써
     상부의 애플리케이션과 하부의 네트워크 장치에게 논리적 중앙 집중형 코어 서비스의 추상화를 제공한다.

3. 사우스바운드 추상화와 프로토콜

   • 사우스바운드 추상화는 하부의 호스트, 링크, 스위치, 프로토콜의 이질성을 숨겨준다.
   • 따라서 분산 코어가 장치나 프로토콜 종류에 상관없이 동작할 수 있다.
   • 이 추상화 때문에 분산 코어 아래의 사우스 바운드 인터페이스는 표준 컨트롤러나 ODL 컨트롤러보다 논리적으로 높다.