[컴퓨터네트워크2] 하향식 접근법 5장 (5) - SDN

📌 SDN(Software-Defined Networking)이란?

SDN(Software-Defined Networking)은 네트워크의 컨트롤 플레인을 중앙에서 제어하는 네트워크 아키텍처

기존 네트워크에서는 각 라우터가 자체적으로 경로를 계산했지만, SDN에서는 중앙 컨트롤러가 전체 네트워크를 관리하고 라우팅을 결정

 

- 데이터 평면과 제어 평면을 명확히 분리

- 제어 평면 기능을 자신이 관리하는 라우터의 전달 기능 요소와 분리된 별도의 원격 ‘컨트롤러’ 서비스에 구현

 

1️⃣ 기존 네트워크 (Per-Router Control Plane) vs. SDN

🔹 기존 네트워크 (Per-Router Control Plane)

• 각 라우터가 개별적으로 라우팅 테이블을 계산
• 라우터 간 분산된 프로토콜(OSPF, BGP 등)을 사용해 경로 결정
• 라우터마다 설정이 필요하므로 구성이 복잡하고 오류 발생 가능성 증가
• 모놀리식 라우터에는 스위칭 하드웨어가 포함되어 있으며, 독점 라우터 OS(예: Cisco IOS)에서 인터넷 표준 프로토콜(IP, RIP, IS-IS, OSPF, BGP)의 독점 구현을 실행
• 서로 다른 네트워크 계층 기능에 대한 다른 "미들박스": 방화벽, 로드 밸런서, NAT 박스 등.

 

📌 미들박스(Middlebox)란?

미들박스(Middlebox)는 라우터나 스위치가 아닌, 특정 네트워크 기능을 수행하는 장비를 의미해.
예를 들어, 방화벽(Firewall), NAT(Network Address Translation), 로드 밸런서(Load Balancer) 같은 장비들이 있어!

---

1️⃣ 미들박스는 왜 필요할까?

기본적으로 네트워크는 패킷을 목적지로 전달하는 것이 핵심 역할이야.
하지만, 현실에서는 추가적인 네트워크 기능이 필요해!

✅ 보안(Security) → 방화벽(Firewall)

• 악성 트래픽을 차단하고, 허용된 트래픽만 전달

✅ 트래픽 관리(Traffic Management) → 로드 밸런서(Load Balancer)

• 여러 서버에 트래픽을 분산해서 부하를 줄임

✅ IP 주소 변환 → NAT(Network Address Translation)

• 사설 IP를 공인 IP로 변환해 인터넷과 통신 가능하도록 함

✅ 데이터 압축, 콘텐츠 캐싱 등

➡️ 이러한 기능을 수행하는 별도의 장비나 소프트웨어를 "미들박스"라고 부르는 거야!

---

2️⃣ 미들박스와 기존 네트워크 장비(라우터, 스위치)의 차이

🔹 기능 🔹 라우터/스위치 🔹 미들박스

주요 역할	패킷을 빠르게 전달	특정 네트워크 기능 수행
위치	네트워크 경로(데이터 플레인)	네트워크 중간에서 특정 역할
예시	L2/L3 스위치, 라우터	방화벽, NAT, 로드 밸런서

👉 즉, 미들박스는 패킷을 단순히 전달하는 것이 아니라, "특정 기능을 추가"하는 장비야!

---

3️⃣ SDN과 미들박스의 관계

기존 네트워크에서는 미들박스를 물리적인 장비로 추가해야 했지만,
SDN에서는 소프트웨어적으로 네트워크 기능을 정의할 수 있어!

 

🚀 SDN의 장점
✅ 방화벽, NAT, 로드 밸런서를 하드웨어 대신 소프트웨어로 구현 가능
✅ 중앙에서 모든 네트워크 기능을 소프트웨어로 관리 가능

💡 즉, SDN을 사용하면 미들박스를 물리적으로 설치하지 않고, 네트워크 기능을 "프로그래밍"할 수 있게 돼!

 

🔹 SDN (Software-Defined Networking)

• 컨트롤 플레인을 중앙 집중식으로 관리 (SDN 컨트롤러)
• 라우터는 단순한 포워딩 역할을 하고, 경로 결정은 SDN 컨트롤러가 담당
• 네트워크 설정이 간단하고 유연성이 높음

 

2️⃣ SDN의 핵심 개념: 중앙집중형 컨트롤 플레인 (Logically Centralized Control Plane)

기존 방식과 다르게, SDN에서는 컨트롤 플레인이 중앙에서 동작해.

 

✅ 1. 네트워크 관리가 쉬워짐 (Easier Network Management)

• 라우터마다 설정할 필요 없이 중앙에서 한 번에 관리
• 잘못된 설정(미스컨피규레이션)을 방지할 수 있음

✅ 2. 트래픽 흐름을 더 유연하게 제어 가능 (Greater Flexibility of Traffic Flows)

• 특정 트래픽을 우선 처리하거나, 특정 경로를 사용하도록 프로그래밍 가능
• 필요에 따라 동적으로 라우팅을 변경할 수 있음

✅ 3. 테이블 기반 포워딩으로 라우터 "프로그래밍" 가능 (Table-Based Forwarding & OpenFlow API)

• 라우터가 라우팅 프로토콜을 실행하는 대신, 중앙에서 계산된 테이블을 사용
• OpenFlow 같은 API를 사용하면 소프트웨어적으로 경로를 설정 가능

✅ 4. 중앙 집중형이 분산 방식보다 간단함

• 중앙에서 테이블을 계산해서 배포하는 것이 훨씬 간단
• 기존 방식(Per-Router Control Plane)처럼 각 라우터가 분산 알고리즘을 실행할 필요 없음

 

3️⃣ SDN의 개방성 (Open Implementation)과 혁신 (Innovation)

SDN은 기존 네트워크 장비 제조업체(Cisco, Juniper 등)의 독점 기술에서 벗어나, 개방적인 네트워크 관리 방식을 제공해.

 

🚀 SDN의 개방성이 가져오는 변화

• 벤더 종속성 감소 → 네트워크 장비 제조업체에 의존하지 않고 다양한 기술을 사용할 수 있음
• 새로운 네트워크 기술 실험 가능 → 다양한 연구와 혁신이 활발하게 진행됨
• 비유: 메인프레임에서 PC 혁명으로!
  • 과거에는 중앙에서 모든 컴퓨터를 관리하는 메인프레임 방식이었지만,
  • PC가 등장하면서 개방형 기술이 발전했듯이,
  • SDN도 기존 네트워크 장비 중심에서 개방형으로 변화하고 있음

🔍 SDN을 한 문장으로 정리하면?

👉 "네트워크의 두뇌(컨트롤 플레인)를 중앙에서 제어하고, 라우터는 단순한 실행 역할을 하게 만드는 기술"

🚀 이렇게 하면 네트워크 관리가 쉬워지고, 유연한 트래픽 제어가 가능해짐

 

 

---

 

Traffic engineering: 기존 라우팅으로는 불가능했던 것들

 

Q: what if network operator wants u-to-z traffic to flow along uvwz, rather than uxyz? 만약 네트워크 운영자가 u에서 z로 가는 트래픽을 uvwz 경로로 보내고 싶다면?

A: need to re-define link weights so traffic routing algorithm computes routes accordingly (or need a new routing algorithm)!

link weights are only control “knobs”: not much control!

 

-> 기존의 라우팅 알고리즘은 "최단 경로"를 계산하기 때문에, 우리가 원하는 경로를 직접 지정하기 어렵다는 문제

-> 전통적인 라우팅 방식에서는 "링크 가중치(Link Weight)"가 경로를 조절할 수 있는 거의 유일한 방법(knob)이야.
즉, 네트워크 운영자가 할 수 있는 일은 링크 가중치를 조정해서 경로를 우회하도록 유도하는 것뿐

 

왜 knobs(조절할 수 있는 요소)가 부족할까?

• 전통적인 라우팅 프로토콜(OSPF, RIP 등)은 기본적으로 링크 가중치를 기반으로 동작
  하지만 링크 가중치만으로는 특정 트래픽을 원하는 경로로 보내는 세밀한 제어가 어렵다
• "knobs"가 제한적이라는 말은, 우리가 트래픽을 제어할 방법이 부족하다는 의미
• 링크 가중치를 조정하면 경로를 바꿀 수 있긴 하지만, 모든 트래픽에 영향을 주기 때문에 원하는 대로 세밀한 조정이 어렵다.

 

u-to-z 트래픽을 uvwz와 uxyz 경로로 분할하는 것이 왜 불가능할까?

-> 전통적인 라우팅 방식(예: OSPF, RIP)은 단일 경로만 선택하기 때문

• 기존 라우팅 알고리즘(링크 상태 라우팅, 거리 벡터 라우팅)은 "단일 최단 경로"를 기반으로 동작
• "로드 밸런싱(load balancing)"을 하려면 트래픽을 두 개의 경로(uvwz & uxyz)로 나눠야 하는데, 전통적인 라우팅 프로토콜에서는 하나의 경로만 선택할 수 있음
• 기존 방식에서는 트래픽을 특정 비율로 나눠서 보내는 기능이 없기 때문에 불가능한거임
• 로드 밸런싱을 하려면?
  • ECMP(Equal-Cost Multi-Path) 같은 기술을 사용해야 하는데, 이는 기존 라우팅 프로토콜만으로는 지원되지 않음
  • 또는, SDN(소프트웨어 정의 네트워킹)처럼 프로그래머블한 라우팅 방식이 필요

 

 

w에서 z로 가는 "파란색/빨간색 트래픽"을 다르게 라우팅할 수 없는 이유는?

-> 기존 라우팅은 "목적지 기반(destination-based)"이기 때문!

• 전통적인 라우팅 프로토콜(OSPF, RIP, BGP 등)은 "목적지 주소"만 보고 경로를 결정
  • 트래픽이 어떤 종류인지(예: QoS, 서비스 유형, VLAN, 애플리케이션 종류 등)는 고려하지 않음
• 왜 w가 파란색/빨간색 트래픽을 다르게 라우팅할 수 없을까?
  • 기존 방식에서는 z로 가는 최적의 경로를 하나만 선택할 뿐, 트래픽의 종류를 기반으로 다르게 라우팅할 수 없기 때문
  • 모든 트래픽이 같은 목적지(z)로 가는 경우, 같은 경로를 따라가야 함
• 트래픽의 종류에 따라 다르게 라우팅하려면?
  • SDN에서는 패킷의 종류, 애플리케이션 유형, QoS 등의 다양한 기준을 기반으로 라우팅할 수 있음
  • ex) OpenFlow 같은 프로토콜을 사용하면 출발지, 목적지뿐만 아니라 트래픽 타입까지 고려한 라우팅이 가능

 

전통적인 라우팅 방식에서는

1. 원하는 경로를 직접 지정하기 어려움 (링크 가중치(Link Weight)가 경로 조절의 유일한 방법, 최단 경로 선택)
2. 로드 밸런싱을 지원하지 않음 (하나의 최적 경로만 선택)
3. 트래픽 유형에 따른 차등 라우팅이 불가능함 (목적지 기반 라우팅만 가능)

 

 

SDN 구조

 

 

 

Data-plane switches

1. 빠르고 단순한 범용(commodity) 스위치

- 하드웨어에서 일반화된 데이터 플레인 포워딩 수행 (섹션 4.4 참고)

 

2. 컨트롤러의 감독 아래 플로우 테이블(flow table) 계산 & 설치

- 컨트롤러가 경로를 계산하고, 스위치에 전달함

- 스위치는 단순히 컨트롤러의 지시에 따라 패킷을 전달

 

3. 테이블 기반 스위치 제어 API 제공 (예: OpenFlow)

- 어떤 기능이 제어 가능하고, 어떤 것은 불가능한지 정의

- 컨트롤러와 스위치 간 통신 프로토콜 (예: OpenFlow 사용)

 

 

 

수업 때 들은 추가 내용

- 네트워크 기능 가상화(NFV)와 연계 가능: 방화벽, 로드 밸런서 같은 기능을 소프트웨어로 구현하여 유연한 네트워크 구성 가능

- 과거 네트워크는 Lock-in 문제

예전에는 한 회사의 전용 하드웨어와 소프트웨어만 사용 가능 -> 폐쇄적(Lock-in 현상)

이후 마이크로프로세서 등장으로 여러 OS & 애플리케이션 실행 가능

네트워크도 SDN을 통해 하드웨어와 소프트웨어 분리 → 개방성 증가

- SDN을 활용한 네트워크 제어 사례

접근 제어 리스트(Access Control List) : 특정 트래픽 차단/허용

로드 밸런싱 : 트래픽을 여러 노드에 분산해 한 노드에 과부하가 가지 않도록 조정

 

• SDN에서는 데이터 플레인 스위치는 단순한 패킷 전달 장치
• 컨트롤러가 모든 경로를 계산 & 설정
• API(OpenFlow 등)로 컨트롤러와 통신
• 기존 폐쇄적 네트워크 구조(Lock-in)에서 개방적 SDN 구조로 변화

 

 

SDN controller (network OS)

1. 네트워크 상태 정보 유지
   • 어떤 장치와 연결되어 있는지 등의 정보(network state information)를 테이블로 관리
2. Northbound API (컨트롤 애플리케이션과 상호작용)
   • 상위 애플리케이션과 연결하여 정책 및 제어 기능 제공
3. Southbound API (네트워크 스위치와 상호작용)
   • 하위 스위치와 연결하여 데이터 플레인 제어
4. 분산 시스템으로 구현
   • 성능, 확장성, 장애 내성, 견고성 확보
5. 논리적으로 중앙 집중식 구조
   • 네트워크 전반을 하나의 시스템처럼 관리

 

 

 

network-control apps

1. 제어 기능 구현
   • SDN 컨트롤러가 제공하는 API와 서비스 활용
2. 유연한 기능 구현
   • 다양한 정보를 활용하여 맞춤형 네트워크 제어 기능 구현
3. Unbundled(비번들링) 개념
   • 소프트웨어를 개별적으로 추가하여 확장 가능
   • 라우팅 벤더나 SDN 컨트롤러와 분리되어 제3자가 제공 가능
   • 컨트롤 프로토콜 활용: OpenFlow 외에도 여러 프로토콜을 활용 가능

 

 

 

 

---

 

SDN Controller 구성요소

 

 

 

1. 추상화 API

2. network-wide state management : 상태관리, 누가 연결 되어있고 끊어져있는지 등 정보 받아서 forwarding table = flow table 에 저장 : 분산된 DB -> 서버를 분산, single point of failure problem을 해결할 수 있다

3. communication : simple network management protocol 사용해서 SDN컨트롤러와 컨트롤된 스위치들(라우터)를 통신

 

 

 

Distributed database가 SPOF 문제를 해결할 수 있는 이유?

Single Point of Failure (단일 장애점, SPOF) 문제 해결 방법으로 분산 데이터베이스(DB)를 사용하는 이유:

1. 이중화 및 복구 가능
   • 한 서버가 다운되더라도 다른 서버가 데이터를 보유하고 있어 네트워크 운영이 중단되지 않음
2. 부하 분산 (Load Balancing)
   • 여러 서버에 데이터를 나눠 저장하여 특정 서버에 과부하가 걸리는 것을 방지
3. 고가용성 (High Availability)
   • 여러 노드에서 동일한 데이터를 관리하여 장애 발생 시 다른 노드가 즉시 대응 가능
4. 데이터 일관성 유지
   • 네트워크 전체 상태를 지속적으로 동기화하여 최신 정보를 유지
5. 지리적 이중화 가능
   • 여러 지역에 서버를 배포하면 특정 지역 장애에도 네트워크가 정상적으로 운영됨

즉, 단일 서버가 모든 데이터를 관리하면 해당 서버가 고장 날 경우 전체 네트워크에 문제가 발생하지만, 분산된 DB를 사용하면 장애가 발생해도 다른 서버가 이를 대체할 수 있어 SPOF 문제를 해결할 수 있음.

 

OpenFlow protocol

 

1. 기본 개념
   • 컨트롤러와 스위치 간 통신을 담당
   • 메시지 교환에 TCP 사용
   • 보안을 강화하려면 암호화(Optional) 가능
   • OpenFlow 메시지는 세 가지 유형
     1. Controller-to-Switch (컨트롤러 → 스위치)
     2. Asynchronous (스위치 → 컨트롤러)
     3. Symmetric (양방향, 기타 메시지)
   • OpenFlow API와 구별됨 (API는 일반화된 포워딩 동작을 지정하는 용도)
2. Controller-to-Switch Messages
   • features: 컨트롤러가 스위치의 기능 조회(queries), 스위치가 응답
   • configure: 컨트롤러가 스위치 설정(configuration parameters) 조회(queries)/변경(sets)
   • modify-state: OpenFlow 테이블의 플로우 엔트리 추가, 삭제, 수정(add, delete, modify)
   • packet-out: 특정 스위치 포트로 패킷 전송
3. Switch-to-Controller Messages
   • packet-in: 패킷(and its control)을 컨트롤러로 전달, 컨트롤러부터의 packet-out 메시지를 봄.
   • flow-removed: 플로우 테이블에서 삭제된 엔트리를 컨트롤러에 알림
   • port status: 포트 변경 사항을 컨트롤러에 보고
4. 추가 개념
   • 네트워크 운영자는 OpenFlow 메시지를 직접 작성할 필요 없음
   • 컨트롤러에서 고수준 추상화된 방식으로 스위치를 제어할 수 있도록 지원

 

SDN: 주요 과제 및 미래 전망

1. SDN의 앞으로의 과제들
   • 제어 평면 강화: 신뢰성, 확장성, 보안이 뛰어난 분산 시스템 구축
   • 장애 복원력: 신뢰할 수 있는 분산 시스템 이론 적용
   • 의존성 및 보안: 처음부터 보안을 고려한 설계
   • 특정 요구사항 충족: 실시간, 초고신뢰성, 초고보안 네트워크 구현
   • 인터넷 규모 확장: 단일 AS를 넘어선 확장성 고려
   • 5G 네트워크에서 SDN 활용이 critical
2. SDN과 기존 네트워크 프로토콜의 미래
   • 라우터가 직접 계산하는 방식 vs. SDN이 계산하는 방식 비교
   • SDN 기반 혼잡 제어 가능:
     • 라우터가 컨트롤러에 혼잡 상태를 보고 -> 컨트롤러가 송신 속도 조정
   • NAT, 보안, 방화벽, 로드 밸런서 기능도 SDN에 포함이 될 수 있다

p.98~p.102: interaction 예제~ 추가 컨트롤러 예제들은 나중에 피피티로 따로 가볍게 보기

 

• 이미지 출처 : https://gaia.cs.umass.edu/kurose_ross/ppt.php