Control-Data Plane Separation

1. Overview

제어-데이터 평면 분리(Control-Data Plane Separation)는 똑똑하지만 느린 '두뇌(Control Plane)'와, 멍청하지만 미친 듯이 빠른 '근육(Data Plane)'이 하나의 라우터 깡통 안에 섞여 있던 수십 년간의 하드웨어 종속성을 뜯어내고, 두뇌만 구름(Cloud/Controller) 위로 뽑아 올려 네트워크 전체를 소프트웨어로 지배하는 **SDN(Software-Defined Networking)**의 핵심 철학을 해부합니다.

학습자는 라우터 1,000대의 설정을 바꾸기 위해 엔지니어가 1,000번 로그인을 해야 했던 **분산 제어(Distributed Control)**의 참사를 뜯어봅니다. 나아가 패킷이 들어오면 "이리 가라, 저리 가라" 표지판(Routing Table)만 보고 무지성으로 빛의 속도로 던지는 하드웨어 **데이터 평면(Data Plane)**과, 전체 지도를 내려다보며 그 표지판을 실시간으로 그려서 라우터들에게 뿌려주는 중앙 집중형 **제어 평면(Control Plane)**의 완벽한 역할 분담 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Plane Architecture: Control Plane (경로 계산, 라우팅 프로토콜) vs Data/Forwarding Plane (패킷 포워딩, ASIC).
• SDN (Software-Defined Networking): 두뇌(Control)의 중앙 집중화와 멍청한 스위치(Data)의 분리 모델.
• Southbound API (OpenFlow): 중앙 컨트롤러가 밑에 있는 스위치들의 포워딩 테이블을 조작하는 표준 통신 규약.
• Northbound API: 개발자가 파이썬 스크립트로 네트워크 전체의 라우팅 룰을 프로그래밍할 수 있게 해주는 인터페이스.

Out-of-Scope

• BGP / OSPF 깊은 알고리즘: 제어 평면이 경로를 '어떻게' 계산하는지에 대한 그래프 이론 $\rightarrow$ 08-03 IP, Routing 영역에서 기학습.
• NFV (Network Functions Virtualization): 방화벽이나 로드밸런서를 가상 머신으로 띄우는 기술 $\rightarrow$ 컨트롤 플레인 분리와는 결이 다른 인프라 가상화 개념.

Boundaries

• Legacy Router vs SDN Switch: 레거시 라우터는 1대마다 머리와 몸통이 다 붙어있어 똑똑합니다. 자기가 직접 BGP를 돌려 경로를 찾고 패킷을 던집니다(자치권 보장). 반면 SDN 스위치는 머리가 잘린 좀비입니다. 스스로 길을 찾을 지능이 0이며, 오직 중앙에 있는 'SDN Controller(마스터)'가 뇌파(OpenFlow)로 "1번 포트로 온 건 2번으로 던져라"라고 명령을 내려줘야만 움직입니다. 개별 지능을 뺏어 중앙 독재를 이룩하는 아키텍처적 경계를 명확히 긋습니다.

3. Counterexample

• CLI 하드코딩과 1,000번의 야근: 회사 데이터센터에 새로운 보안 룰("IP A에서 온 건 다 버려라")을 적용해야 합니다. 레거시 환경이라 네트워크 엔지니어가 라우터 1,000대에 일일이 SSH로 붙어서 CLI(Command Line Interface) 명령어를 쳤습니다. 999번째 라우터에서 오타를 냈고, 트래픽이 꼬여서 사내망 전체가 마비되었습니다. 중앙 컨트롤러(두뇌)에서 API 한 방을 쏘면 1,000대의 스위치(몸통)에 보안 룰이 1초 만에 쫙 뿌려지는 SDN의 분리 철학을 몰랐던 노가다의 비극입니다.
• 뇌(Control)에 패킷(Data)을 부어버린 DDoS: 라우터의 뇌(Control Plane)는 BGP를 계산하느라 CPU를 쓰고, 몸통(Data Plane)은 전용 하드웨어 칩(ASIC)으로 패킷을 고속으로 던집니다. 해커가 라우터 뇌가 직접 처리해야 하는 특수 패킷(예: 라우팅 업데이트, ICMP)을 초당 10만 개 쐈습니다. 라우터의 두뇌(CPU 100%)가 뻗어버렸습니다. 뇌가 죽으니 몸통(하드웨어 칩은 멀쩡한데)이 멈춰 라우터 전체가 죽는, 평면 분리(Plane Separation) 보호 장치가 없던 구시대의 취약점입니다.

4. Prerequisites

• Routing Protocol (Basic): 라우팅 테이블이 만들어지는 원리. (08-03-03 OSPF)
• Hop-by-Hop Forwarding (Basic): 라우터가 패킷을 받아 다음 홉으로 던지는 행위. (08-03-02 Hop-by-Hop)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 한 몸뚱이의 한계 (The Hardware Monolith)

• Why to Learn: 소프트웨어(SDN)가 네트워크를 집어삼키기 전, 시스코나 주니퍼 같은 하드웨어 벤더가 라우터 하나에 모든 논리를 때려 박아 벤더 종속성(Lock-in)과 끔찍한 유지보수 비용을 발생시켰던 폐단을 통찰하기 위함입니다.
• What to Learn:
  • Concepts: Distributed Control (분산 제어), Vendor Lock-in, Legacy Router Architecture.
  • Skills: 라우터 3대(A, B, C)가 있을 때, A가 목적지까지 가는 길을 알기 위해 B와 C에게 쉴 새 없이 질문(OSPF/BGP 통신)하며 각자 자기 머리를 굴려 '부분적인 지도'만 겨우 완성해 내는 분산 제어의 맹점 파악.
• How to Learn:
  • 1단계: 분산된 두뇌들: 기존 네트워크는 개미 떼와 같습니다. 중앙 통제소가 없습니다. 100개의 라우터가 "너 길 알아?", "나 이쪽 길 알아!" 하면서 서로 끊임없이 대화(Routing Protocol)를 나누어 각자의 머릿속에 지도를 그립니다.
  • 2단계: 관리의 지옥: 망을 업데이트하려면 100마리 개미의 뇌를 다 뜯어고쳐야 합니다. 게다가 시스코 개미와 주니퍼 개미는 뇌 구조(CLI 명령어)가 달라서 서로 제어도 안 됩니다(벤더 종속). 네트워크가 커질수록 개미들끼리 대화하는 데 트래픽과 CPU를 다 써버리는, 두뇌와 몸통이 합쳐진 아키텍처의 비극을 해부합니다.
• Implement: 분산 제어 vs 중앙 제어 수렴 시간(Convergence Time) 비교 모사. Distributed Mode: 링크 끊어짐 $\rightarrow$ 라우터 A가 B에게 알림 $\rightarrow$ B가 C에게 알림 $\rightarrow$ 수렴까지 O(N) 시간 소요, 일시적 루핑(Looping) 발생. Centralized Mode (SDN): 링크 끊어짐 $\rightarrow$ 뇌(Controller)가 즉시 전체 지도 갱신 $\rightarrow$ 즉각 100대에게 새 룰 하달 $\rightarrow$ 수렴 시간 O(1) 달성 애니메이션.

Recommended

Core Topic 02: 머리와 몸의 절단 (Decapitation & Separation)

• Why to Learn: 라우터 안에서 뇌(지도 그리기)와 몸(패킷 던지기)을 완전히 쪼개버려, 두 기능이 서로의 자원(CPU vs ASIC)을 뺏어 먹어 시스템이 다운되는 현상을 막는 물리적/논리적 분리술을 장악하기 위함입니다.
• What to Learn:
  • Concepts: Control Plane (제어 평면 - 뇌), Data Plane / Forwarding Plane (데이터 평면 - 몸), ASIC (주문형 반도체), FIB (Forwarding Information Base).
  • Skills: 라우터에 BGP 계산 요청이 초당 10만 번 폭주하여 제어 평면 CPU가 100%를 쳤을 때, 데이터 평면의 전용 칩(ASIC)은 이와 무관하게 초당 1,000만 개의 데이터 패킷을 드롭(Drop) 없이 무사히 포워딩하는 격리 메커니즘 도해.
• How to Learn:
  • 1단계: Control Plane (두뇌, CPU): 지도를 그립니다(OSPF, BGP). 똑똑해야 하지만 아주 빠를 필요는 없습니다. 1초에 기껏해야 수십 번 경로가 바뀝니다. 범용 CPU(인텔, AMD)로 연산합니다.
  • 2단계: Data Plane (몸통, ASIC): 패킷이 들어오면 두뇌가 만들어준 지도(FIB)를 보고 "아, 이 목적지 IP는 3번 포트로 던지래" 하고 빛의 속도로 던집니다. 1초에 1억 번을 던져야 합니다. CPU로는 어림도 없고 무식하게 빠른 깡통 하드웨어 칩(ASIC)을 씁니다.
  • 3단계: 절단의 이학(理學): 이 둘을 분리해 놓으면, 해커가 라우터 CPU(두뇌)를 마비시키는 특수 패킷을 쏴도 몸통(ASIC)은 이미 가지고 있는 낡은 지도를 보면서라도 유저들의 일반 데이터 패킷을 꿋꿋하게 계속 포워딩합니다. 즉, 관리가 멈춰도 서비스는 멈추지 않는 궁극의 안정성을 뜯어봅니다.
• Implement: Plane Isolation 부하 테스트 스크립트. 라우터 1대 내부에 Control Process (CPU)와 Forwarding Process (ASIC 모사) 분리 가동. 공격: ping -flood -routing_updates. Control Process CPU 점유율 100% 도달 후 뻗음. 방어: 일반 유저 트래픽(HTTP GET)은 Forwarding Process가 기존 캐시(FIB)를 보고 Latency 0.1ms로 지연 없이 전송 성공하는 격리 장벽 렌더링.

Practical

Core Topic 03: 뇌파 통신 규약, 오픈플로우 (OpenFlow & Southbound API)

• Why to Learn: 허공에 떠 있는 중앙의 거대한 뇌(SDN Controller)가 어떻게 땅에 있는 수천 대의 깡통 스위치(Data Plane)에게 "이렇게 길을 바꿔라"라고 뇌파(API)를 쏘는지 그 표준 통신망을 장악하기 위함입니다.
• What to Learn:
  • Concepts: SDN Controller, OpenFlow Protocol, Southbound API, Flow Table, Match-Action Rule.
  • Skills: OpenFlow의 Match-Action(조건-행동) 구조를 이용해, "출발지 IP가 10.0.0.1이고 TCP 포트가 80이면(Match) 무조건 포트 5번으로 던져라(Action)"라는 플로우 테이블(Flow Table) 엔트리 설계.
• How to Learn:
  • 1단계: 좀비와 뇌파 (Southbound API): 뇌(Controller)는 구름 위에 있고 스위치는 바닥(South)에 있습니다. 뇌가 바닥으로 명령을 내리는 API가 Southbound API이고, 그 가장 대표적인 글로벌 언어가 'OpenFlow'입니다.
  • 2단계: Match-Action (조건반사): 뇌가 스위치에게 플로우 테이블(Flow Table)을 내려줍니다. 아주 단순합니다. "Match: 이런 패킷이 오면 / Action: 이렇게 해라." 예: [Match: IP=192.168.1.10] -> [Action: Drop(버려라)]. 깡통 스위치는 패킷이 들어오면 이 표만 보고 무지성으로 행동합니다.
  • 3단계: 표에 없는 패킷이 오면? (Packet-in): 처음 보는 놈이 왔습니다. 스위치는 표(Table)에 없으니 당황합니다. 이때 스위치는 패킷을 뇌(Controller)에게 쏘옥 올려 보냅니다(Packet-in 이벤트). "형님, 이거 어쩔까요?" 뇌가 분석해서 "어, 그거 3번으로 던져" 하고 새로운 표(Rule)를 내려주면 스위치는 그제야 3번으로 던지고, 다음부터는 뇌에 안 물어보고 자기가 알아서 3번으로 던지는 놀라운 중앙 통제 메커니즘을 해부합니다.
• Implement: OpenFlow 기반 방화벽(Firewall) 시뮬레이터. Controller: 중앙 Python 스크립트. Switch: 깡통 라우터.
  1. 해커 IP 10.9.9.9 감지.
  2. Controller가 OpenFlow API 호출 $\rightarrow$ Switch에 [Match: SrcIP=10.9.9.9, Action: DROP] 룰 삽입.
  3. Switch는 이후 10.9.9.9에서 오는 초당 10만 개 패킷을 뇌(Controller)에 묻지도 않고 ASIC 칩 레벨에서 빛의 속도로 갈아버리는 선제적 방어 렌더링.

Advanced

Core Topic 04: 네트워크를 코딩하라 (Programmable Network & Northbound API)

• Why to Learn: 네트워크 장비를 직접 만지는 노가다 엔지니어의 삶을 끝내고, 외부의 비즈니스 로직 앱이 컨트롤러의 뇌를 프로그래밍하여 트래픽 망 전체를 실시간으로 살아 움직이게 만드는 궁극의 소프트웨어 통제술을 장악하기 위함입니다.
• What to Learn:
  • Concepts: Northbound API, Programmable Network, Intent-based Networking (의도 기반 네트워크), Traffic Engineering.
  • Skills: "오전 9시부터 6시까지는 모든 트래픽을 보안 방화벽 장비로 우회(Service Chaining)시키고, 퇴근 후에는 직통으로 쏴라"라는 비즈니스 룰을 파이썬 스크립트로 짜서 컨트롤러(Northbound API)에 먹이기.
• How to Learn:
  • 1단계: 뇌 위(North)의 지배자: 컨트롤러가 스위치를 지배(South)한다면, 그 컨트롤러는 누가 지배할까요? 바로 '개발자가 짠 프로그램'입니다. 프로그램이 컨트롤러의 윗단(North)으로 찌르는 API가 바로 Northbound API입니다 (REST API 등 사용).
  • 2단계: 트래픽 엔지니어링의 예술: 비즈니스 앱이 컨트롤러에게 명령합니다. "지금 서버 A에 트래픽이 몰리니까, 네트워크 30%는 우회도로로 돌려!" (Load Balancing). "특정 VIP 고객의 패킷은 가장 빠르고 쾌적한 전용차선(QoS)으로 보내!" (Traffic Engineering). 라우터 1,000대에 로그인해서 설정하던 과거를 버리고, 파이썬 코드 몇 줄로 거대한 100만 평짜리 네트워크 고속도로의 차선을 실시간으로 뗐다 붙였다 하는 '의도(Intent)' 기반 네트워크의 경이로움을 뜯어봅니다.
• Implement: Python Northbound API 호출 동적 라우팅 스크립트. while True: Bandwidth = Monitor.get('Link_A'). if Bandwidth > 80%: requests.post('http://controller/api/flow', json={"match":"Video", "action":"Route_B"}). 링크 A가 터지기 직전, 앱이 뇌(Controller)를 찔러 동영상 트래픽만 B 링크로 싹 빼버리는, 사람이 1초도 개입하지 않는 자동화(Self-Healing) 인프라 구축 렌더링.

7. Terminology

8. References

Primary

• [P1] CS2023 - Networking and Communication (NC) - Software-Defined Networking (SDN)
• [P5] SFIA - Network Design (NTDS) - Control and Data Plane Separation

Secondary

• [Computer Networking: A Top-Down Approach] Kurose & Ross - Software-Defined Networking (SDN)
• [SDN: Software Defined Networks] Thomas D. Nadeau - How SDN Works, OpenFlow

Industry

• [Open Networking Foundation (ONF)] - OpenFlow Switch Specification
• [Cisco Architecture] - SDN Controller and Southbound/Northbound APIs

9. Final Checklist

Primary

• 수백 대의 라우터가 각각 OSPF/BGP를 돌리며 귓속말로 지도를 짜깁기하던 분산 제어(Distributed Control)의 한계를, 중앙의 SDN Controller가 전체 망을 내려다보는 중앙 제어로 어떻게 해결했는지 설명할 수 있는가?
• 라우터 안에서 CPU가 담당하는 '제어 평면(Control Plane)'과 ASIC 하드웨어 칩이 담당하는 '데이터 평면(Data Plane)'의 역할 분담을 설명하고, 제어 평면 마비 시 데이터 평면의 생존 여부를 증명할 수 있는가?

Secondary

• 중앙 집중형 SDN 컨트롤러(두뇌)와 하위 스위치 장비 간을 연결하는 Southbound API(예: OpenFlow)의 'Match-Action' 플로우 테이블 구조를 통해 깡통 스위치가 동작하는 원리를 해부할 수 있는가?
• 스위치 플로우 테이블에 매칭(Match)되지 않는 미지의 패킷이 들어왔을 때, 스위치가 이를 컨트롤러로 쏘아 올리는 Packet-in 메커니즘과 그로 인한 컨트롤러 부하(Overhead)의 맹점을 지적할 수 있는가?

Industry

• 개발자가 파이썬 스크립트를 작성하여 컨트롤러의 Northbound API를 찌름으로써, "특정 시간대에는 VIP 고객의 트래픽 경로를 최적화하라"는 의도(Intent) 기반 네트워크 프로그래밍 자동화를 설계할 수 있는가?
• SDN 컨트롤러 자체가 단일 장애점(SPOF, Single Point of Failure)이 되는 것을 막기 위해, 3대 이상의 컨트롤러를 클러스터링(Raft 합의 등)하여 논리적으론 하나지만 물리적으론 분산된 뇌를 구축하는 고가용성 아키텍처를 논증할 수 있는가?