[Network] Network Layer(Control Plane) 3 - SDN

chxghee·2024년 12월 5일
네트워크

컴퓨터 네트워크 🗂️

목록 보기
23/27

Per-router control plane

지금까지 우린 per-router control plane에 대해 공부했다.

위의 방식은 각 라우터의 라우팅 알고리즘을 통해 테이블을 생성하고, 데이터를 주고 받았다.

SDN (Software-Defined Networking) control plane

외부의 logically centralized 컨트롤러가 각 라우터의 플로우 테이블을 만든다.

  • 각 라우터가 다양한 기능 수행할 수 있도록 서비스를 제공한다.

  • 각 라우터는 컨트롤 에이전트(CA)를 통해 자신의 상태정보, 통계정보, 링크 coat정보, DV값 등을 외부 컨트롤러에 전달하고
    그 컨트롤러에서 라우팅 알고리즘을 통해 만든 플로우 테이블을 받는다.

SDN 방식을 왜 사용하는 걸까?

  1. 쉬운 네트워크 관리
    각 라우터의 misconfigurations을 피할수 있고,
    원하는 설정 및 서비스로 트래픽 플로우 관리의 유연함을 얻을 수 있다.
    (기존 방식은 각각의 라우터마다 분리되어 동작하기에 설정이 꼬일 수 있다..)

  2. 프로그래밍 라우터
    플로우 테이블을 외부 centralized 컨트롤러에서 만들기 때문에
    각각의 라우터에서 분산된 알고리즘으로 테이블을 만드는 것보다 훨씬 쉽다.

  3. 오픈된 컨트롤 플랜의 구현
    이전 방식에서는 하나의 라우터를 하나의 회사가 만들어 생산했다면 (Cisco),
    여러 회사에서 하드웨어 SW을 개발가능 하여 발전이 빠르게 이루어 진다.

Traffic - 기존 per-라우터의 문제점과 SND에서의 해결

Q1. path를 uvwz에서 uxyz로 바꾸고 싶다면??

  1. 기존 방식
    각각의 링크코스트를 조정하여 path를 바꾸어야 한다.
    ➡️ 많은 링크중 어느 링크의 비용을 바꿀지, 또 얼만큼 바꿀지 여러 링크가 얽혀 있으니 어렵다.
  2. SDN
    centralized 컨트롤러에서 라우팅 알고리즘을 만들기 때문에 경로의 변경이 쉽다.

Q2. 트래픽을 여러 path로 분산하고 싶다면?? (load balancing)

  1. 기존 방식
    불가능하다, 혹은 라우팅 알고리즘을 새로 짜야 한다.
  2. SDN
    외부 컨트롤러에서 조정할 수 있다.

Q3. 하나의 라우터가 다른 트래픽을 다른 경로로 포워딩 하고 싶다면??

  1. 기존 방식
    destination-based forwarding과 LS, DV 에서는 불가능 하다.
  2. SDN
    외부 컨트롤러에서 조정할 수 있다.

SDN의 구성

  • 라우팅, 억세스 컨트롤, 부하 분산 또는 메일박스의 NAT, 방화벽 같은 서비스는
    어플리케이션에서 구현이 가능해 진다.
    ➡️ control plane은 data plane의 스위치의 밖에서 이루어 진다.
  • 또한 이렇게 나뉘어 있어, 독립적으로 개발이 가능하고 발전가능하다.
    (어플리케이션과 컨트롤러는 분리되어 있다.)
  • 각 컨트롤러 또한 분산된 형태로 서비스 할 수 있다.

1. Data-plane 스위치

  • 하드웨어로 구성되며, 빠르고 간단하게 generalized data-plane 포워딩을 지원한다.
  • 컨트롤러의 테이블을 install하여 포워딩 하게 된다.
  • 컨트롤러와의 통신을 위해 OpenFlow를 사용한다.

2. SDN 컨트롤러 (네트워크 OS)

  • 네트워크(라우터)의 상태 정보를 갖고 관리한다.
  • northbound API를 통해 위의 어플리케이션 계층과 통신을 한다.
    ➡️ 컨트롤러는 네트워크의 상태정보를 주고,
    그에 따른 동작을 어플리케이션에서 처리하여 컨트롤러에 내려준다.
  • southbound API를 통해 아래의 네트워크 스위치와 통신한다.
  • 컨트롤러 또한 여러 시스템으로 분산될 수 있다.

3. 네트워크 컨트롤 어플리케이션

  • 컨트롤의 주체
    ➡️ 컨트롤 기능을 구현하여 컨트롤러에 전달한다.
    (플로우 테이블 생성, 부하 분산, NAT, 방화벽...)
  • 여러 회사에서 기능을 개발하여 공급가능
    ➡️ SDN 컨트롤러와 별개로 발전이 가능하다.

SDN 컨트롤러의 구성요소

세가지 부분으로 나뉜다.

  1. 네트워크 컨트롤 애플리케이션의 인터페이스 계층
    SDN 컨트롤러가 애플리케이션과 상호작용할 수 있도록 하는 추상화 API를 제공한다.

  1. 네트워크 전체 상태 관리
    네트워크 링크, 스위치, 서비스 등의 상태를 유지하며 이를 기반으로 결정을 내린다.
    분산 데이터베이스로 설계된다.
    (호스트 정보, 플로우테이블, 링크상태정보, 통계데이터를 유지한다.)

  2. 통신
    SDN 컨트롤러와 네트워크 장치(스위치) 간의 통신을 담당. (OpenFlow, SNMP)

OpenFlow 프로토콜

SDN 컨트롤러와 네트워크 장치(스위치) 간의 통신을 지원하는 프로토콜.

  • TCP 기반 통신 (옵션: 암호화 제공)
  • 스위치 컨트롤러 사이의 통신을 지원한다.(양방향 가능)

하지만, OpenFlow API와 구별된다.
(OpenFlow API는 generalized포워당 작업을 지정하는 데 사용된다.)

컨트롤러 -> 스위치 메세지

컨트롤러에서 스위치로 보내는 제어 메세지에는 4가지 종류가 있다.

  1. 상태(features) 메세지
    컨트롤러가 스위치의 상태정보를 얻기 위해 쿼리 메세지를 보낸다.

  1. 상태 수정(modify-state) 메세지
    컨트롤러가 스위치 플로우 테이블(openflow table)의
    엔트리를 추가/제거/수정을 위해 해당 메세지를 보낸다.

  2. 설정(configure) 메세지
    이 메시지는 컨트롤러가 스위치의 설정 파라미터들을 얻거나(쿼리),
    설정할 수 있도록 한다.

  1. 패킷 전송(packet-out) 메세지
    컨트롤러가 제어하는 스위치의 특정 포트에 특정 패킷을 내보내기 위해 사용한다.

스위치 -> 컨트롤러 메세지

스위치에서 컨트롤러에 보내는 메세지는 3가지 종류가 있다.

  1. 패킷 전달(packet-in) 메세지
    패킷을 받았는데, 플로우 테이블 엔트리에 매칭되지 않을 때(어디로 보낼지 모를 때)
    패킷을 컨트롤러에 보낸다.
    ➡️ 추후 컨트롤러에서 오는 패킷 전송(packet-out) 메세지 를 기다린다.

  2. 플로우 제거(flow-remove) 메세지
    플로우 테이블 엔트리가 삭제되었음을 알린다.
    (테이블은 시간이 만료되었거나, 상태 수정 메시지를 수신한 결과로 삭제될 수 있다.)

  1. 포트 상태(port-status) 메세지
    스위치가 컨트롤러에게 자신의 포트 상태 변화를 알리기 위해 사용된다.

control/data plane의 상호작용 예제

Q. s1과 s2의 사이의 링크가 고장이 나면??

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

  2. 메시지를 받은 SDN 컨트롤러는 링크 상태 정보를 갱신한다.
    (데이터베이스 갱신)

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

  4. 링크 상태 라우팅 애플리케이션이 링크 상태 관리자에게 요청하여 갱신된 링크 상태를 가져온다.
    ➡️ 그 후 다시 새로운 최소 비용 경로를 계산한다.

  1. 링크 상태 라우팅 애플리케이션은 갱신되어야 할 플로우 테이블을 결정하는 플로우 테이블 관리자와 접촉한다.
    (새로 계산한 경로로 플로우 테이블을 바꾸기 위해)

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

s1 s2의 링크 고장으로 해당 경로를 사용할 수 없어, 플로우 테이블이 다시 생성되었다.

위의 7번에 링크 상태 변화에 영향을 받는 스위치란 s1, s2, s4을 뜻한다.

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

OpenDaylight 컨트롤러

  • 서비스 추상 계층(Service Abstraction Layer, SAL)
    내부의 컨트롤러 구성요소와, 외부의 애플리케이션이 서로의 서비스를 호출하고
    그들이 생성한 이벤트에 대한 알림을 받을 수 있도록 한다.

ONOS 컨트롤러

ONOS는 분산 코어를 통해 고가용성과 성능 확장,
Intent 프레임워크를 통해 고수준의 제어를 제공한다.

ONOS는 분산 코어를 통해, 서비스 안정성, 복제 성능, 확장성등을 제공한다.

SDN의 해결할 과제

1. Control Plane 강화 (Hardening the Control Plane)

제어 평면은 신뢰할 수 있고, 성능 확장성이 우수하며 보안이 강화된 분산 시스템으로 설계되어야 한다.

  • 장애 복원력 (Robustness to Failures)
    장애가 발생했을 때 이를 견딜 수 있는 강한 분산 시스템 이론이 필요하다.

  • 보안과 신뢰성 (Dependability, Security)
    "보안이 기본적으로 내재되어 있는가?“를 고민해야 한다.

2. 네트워크 및 프로토콜의 특정 요구 사항 충족

각 어플리케이션 혹은 네트워크 마다 특정 요구 사항을 만족해야 한다.

  • 실시간성 (Real-Time)
    특정 응용 프로그램에서는 네트워크와 프로토콜이 실시간 통신을 지원해야 한다.

  • 초고신뢰성 (Ultra-Reliable)
    네트워크가 항상 작동해야 하는 상황에서 높은 신뢰성을 유지해야 한다.

  • 초고보안성 (Ultra-Secure)
    보안이 최우선으로 중요한 환경에서도 이를 충족해야 한다..

3. 인터넷 확장성 (Internet Scaling)

네트워크가 단일 AS를 초과하는 환경에서도 문제없이 동작하고, 대규모 인터넷 확장을 지원해야 한다.

4. 5G 셀룰러 네트워크에서의 SDN

profile
chxghee
다 같이 화이팅! 🙋‍♂️
이전 포스트

[Network] Network Layer(Control Plane) 2 - OSPF와 BGP

다음 포스트

[Network] Network Layer(Control Plane) 4 - ICMP와 SNMP

0개의 댓글