[CS/ Network] 컴퓨터 네트워킹 하향식 접근 8판 4장 네트워크 계층: 데이터 평면 4.4 일반화된 포워딩 및 소프트웨어 기반 네트워크（SDN）

목차
4.4 일반화된 포워딩 및 소프트웨어 기반 네트워크(SDN) 318
4.4.1 매치 320
4.4.2 액션 321
4.4.3 매치 플러스 액션 작업의 OpenFlow 예 322

4.4 일반화된 포워딩 및 소프트웨어 기반 네트워크（SDN）

• 두 단계의 목적지 기반 포워딩 : 목적지 ip 주소를 찾은（‘매치’） 후 패킷을 스위치 구조로 지정된 출력 포트로 전송（‘액션’）
• 위 목적지 기반 포워딩 개념을 일반화 하면, ‘매치 플러스 액션’ 방법에서 '액션'은 여러 행동일 수 있음
  • 하나 이상의 출력 포트（목적지 기반 포워딩과 같이）로 패킷 전달
  • 인터페이스에서 나가는 패킷을 로드 밸런싱
  • 헤더값을 다시 쓰기
  • 의도적으로 패킷을 차단/삭제（방화벽과 같이） 및 추가 처리 작업（DPI와 같이）을 위해 특수 서버로 패킷전송
  • 등의 작업들
• 포워딩 결정 장치(라우터, 스위치)를 일반화해서 패킷 스위치 라는 용어로 좀 더 정확하게 설명
• 그림 4.28 : 패킷 스위치의 ‘매치 플러스 액션' 테이블
  • 테이블은 원격 컨트롤러를 통해 계산，설치，갱신된다.
  • 개별 패킷 스위치의 제어 구성요소가 서로 상호작용할 수는 있음
  • ㄴ but 실제로는 일반화된 '매치 플러스 액션’ 기능이 원격 컨트롤러를 통해 구현되고 이 테이블을 계산, 설치，갱신함.

• 앞으로 계속 말할 흐름이란 패킷의 출발지와 목적지 정보를 가진 데이터를 뜻함

소프트웨어 기반 네트워킹(Software Defined Network, SDN)

• SDN 등장 배경
  • 네트워크 환경이 변화하고 트래픽이 데이터 센터를 중심으로 전환되는 트래픽 패턴의 변화
  • 가상화(VM)의 보편화 -> 호스트 이동량↗
  • 네트워크 관리 필요
• ㄴ-> 소프트웨어로 네트워크 경로 설정/제어/운용 관리 처리
• ㄴ-> 물리적인 하나의 네트워크 환경으로 여러개의 가상의 네트워크 환경 구축 가능
• SDN 방법 : 라우터의 제어 부분(제어 평면) 데이터 전송 부분(데이터 평면)을 분리하고 개방형 인터페이스를 외부에 제공
  • 즉, 데이터 흐름을 제어하는 것(매치)과 패킷을 전달하는 것(액션)의 역할 분리
  • 그러니까 네트워크 장비가 있는 인프라 계층에선 단순히 패킷 전달하고
    원격 컨트롤러(소프트웨어 제어기)에서 프로그래밍해서 데이터 흐름 제어 한다는거~
  • 그래서 위그림에서 패킷 스위치들이 냅다 원격컨트롤러로 가서 얘 어디로보내?? 물어보고 답듣고 ㅇㅋㅇㅋ 전달~
  • 위 과정인게 SDN

OpenFlow : 일반화된 포워딩에 대한 논의의 표준

• 엔트리는 테이블의 행을 의미함
• 일반화된 포워딩은 제어 영역에 의해 생성되는 매치 : 포워딩 테이블(플로우 테이블)을 참고하여 액션 : 패킷(데이터)를 전달함.
  • 얘도 곧 데이터 평면(OpenFlow 스위치), 제어 평면(OpenFlow 컨트롤러)로 구분해서 구성됨
  • OpenFlow 스위치에서 패킷 발생하면 플로우 테이블에 해당 패킷 정보가 있는 지 확인함
    • 정보 있으면 처리하고 없으면 컨트롤러가서 응애 알려줘해서 받은 정보로 다시 처리함
• '매치 플러스 액션’ 포워딩 테이블(플로우 테이블)의 각 엔트리
  • 엔트리 : 매치 규칙과 연관된 패킷에 대한 액션? 엔트리? 을 정의
  • 들어오는 패킷에 대한 헤더값들의 세트가 매치
    • 플로우 테이블 엔트리와 매치되지 않는 패킷은 더 많은 처리를 위해 원격 컨트롤러로 전송될 수 있다.
  • 패킷들에 의해 갱신되는 카운터 세트는 플로우 테이블 엔트리들과 매치
    • 플로우 테이블 엔트리와 마지막으로 갱신된 테이블 엔트리 이후에 매치된 다수의 패킷을 포함
  • 패킷이 플로우 테이블 엔트리와 매치될 때 여러 가지 액션이 가능
    • 패킷을 지정된 출력 포트로 전달
    • 패킷을 삭제
    • 패킷의 복사본 생성 -> 여러 출력 포트로 전송
    • 선택한 헤더 필드를 다시 쓰는 것 등

💑 4.4.1 매치

• 그림 4.29 : OpenFlow 1.0 '매치 플러스 액션’ 규칙에서 매치될 수 있는 11 개의 패킷 헤더 필드와 수신 포트 ID
  • 생긴거 보면 전에 한 캡슐화 (링크계층 헤더에 네트워크 계층 패킷(데이터그램), 트랜스포트 계층 패킷(세그먼트) 합치는 것)
  • 패킷 스위치에 도달하는 링크 계층 프레임은 페이로드에 네트워크 계층 데이터그램, 트랜스포트 계층 세그먼트를 포함
  • 프로토콜 헤더의 세 계층에서 선택된 필드에 매치되도록 허용 -> 계층화 원칙 무시
  • 출발지 및 목적지 MAC 주소 필드: 프레임의 송신 및 수신 인터페이스와 연관된 링크 계층 주소
    • IP 주소가 아닌 이더넷 주소를 기반으로 전달
      => OpenFlow 지원 장치가 스위치（2계층 장치) 포워딩 프레임뿐만 아니라 라우터（3계층 장치） 포워딩 데이터그램과 동일한 성능을 발휘
  • 이더넷 타입 필드 : 상위 계층의 프로토콜, 즉 프레임의 페이로드가 역다중화되는 프로토콜（ex IP)에 해당
  • VLAN 필드 : 가상 로컬 영역 네트워크랑 관련
  • 진입 포트 : 패킷이 수신되는 패킷 스위치의 입력 포트
  • 패킷의 출발지 IP, 목적지 IP, IP 프로토콜 필드，IP 서비스 타입 필드 등
  • OpenFlow 1.0의 12개의 값 세트들의 특정 사항들은 최근에는 41개로 증가

• +) 위 필드에는 와일드 카드도 있을 수 있음
  • ex) 플로우 테이블의 128.119.. IP 주소는 128.119를 주소의 첫 번째 16비트로 갖는 데이터그램의 해당 주소 필드와 매치
• 각 플로우 테이블 엔트리에는 관련 우선순위가 있음
  • 패킷이 여러 플로우 테이블 엔트리와 매치되면, 패킷은 매치된 엔트리 우선순위에 따라 우선순위가 높아짐
• IP 헤더의 모든 필드가 매치될 수 있는 것은 아님
  • ex OpenFIow는 TTL 필드 또는 데이터그램 길이 필드에 기반한 매치를 허용X
• ㄴ 어떤 필드는매치되는 반면 어떤 필드는 매치되지 않는 이유
  • 기능과 복잡성 간의 절충과 관련

🏂🏻 4.4.2 액션

• 각 플로우 테이블 엔트리는 플로우 테이블 엔트리와 매치되어 패킷 처리를 결정하는 0개 이상의 액션 목록을 가짐.
  • 여러 액션이 있는 경우 목록에 지정된 순서대로 수행
• 가장 중요한 액션들
  • 포워딩
    • 들어오는 패킷은 특정 실제 출력 포트로 전달
      or 모든 포트를 통해 브로드캐스트（선택한 포트를 제외하고）
      or 선택된 포트 세트를 통해 멀티캐스트
      or 캡슐화되어 원격 컨트롤러로 전송될 수 있음
    • 이 후, 컨트롤러는 새 플로우 테이블 엔트리를 설치하고
      해당 패킷에 대해 조치를 취함（하지않을 수도 있음）
      or 갱신된 플로우 테이블 규칙에 따라 포워딩을 위해 패킷을 장치로 반환
  • 삭제: 아무 액션이 없는 플로우 테이블 엔트리는 매치된 패킷을 삭제해야 함을 의미
  • 필드 수정: 패킷이 선택된 출력 포트로 전달되기 전, 10개의 패킷 헤더 필드의 값을 다시쓸 수 있다.
    • ㄴ(IP 프로토콜 필드를 제외한 그림 4.29의 모든 2, 3, 4계층 필드)

👁‍🗨4.4.3 매치 플러스 액션 작업의 OpenFlow 예

첫 번째 예: 간단한 포워딩

• h6(h5) -> h3(h4) 로 가기위해 : s3 -> s1 -> s2 (s3->s1 경로 피함 가능)

두 번째 예 : 로드 밸런싱

• h3에서 10.1..로 향하는 데이터그램이 s2와 s1 사이의 링크를 통해 전달되는 반면，
  h4에서 10.1..로의 데이터그램은 s2와 s3 사이의 링크를통해 전달되는 로드 밸런싱 시나리오를 고려
  • 이 동작은 IP의 목적지 기반 포워딩으로 수행될 수 X
    • ㄴ-> IP 목적지 기반 포워딩이면 냅다 목적지만 향해가는데 로드밸런싱은 우회하는 느낌이니까 못한다는 듯
  • 이 경우 s2의 플로우 테이블은 다음과 같다
  • s2에서 수신한 데이터그램을 h1(h2)로 전달하려면,
    s1의 플로우 테이블 엔트리가 필요
  • 인터페이스 4에서 수신한 데이터그램을 s2 -> 인터페이스3 -> s1로 전달하려면,
    s3의 플로우 테이블 엔트리 필요
  • 아래 그림에서 Ingress port는 라우터에서 들어오는 포트 번호를 나타내는 것 같음.
    

로드 밸런싱이란?
= 부하분산, 중앙처리장치 or 저장장치와 같은 컴퓨터 자원들에게 작업을 나누는 것을 의미
아마도 똑같이 10.2..에서 10.1..로 가는데 다른 경로로 가서 분산하는 거같음

세 번째 예: 방화벽

• s2 : s3에 연결된 호스트에서 보낸 트래픽만 수신하려고 하는 방화벽 시나리오
  • s2의 플로우 테이블에 다른 엔트리가 없으면 10.3..의 트래픽만 s2에 연결된 호스트로 전달
  • 10.3.. 애들말고 다른 애들이면 액션이 안대니까 그 자체가 방화벽역할을 한다는 느낌인 듯

• 일반화된 포워딩은 암튼 다양성과 장점이 명백함
• '매치 플러스 액션’ 플로우 테이블은 사실 제한된 형태의 프로그래밍 가능임
  • 데이터그램의 헤더값과 매치 조건 사이의 매치를 기본으로 라우터가 데이터그램을 전달하고 조작하는 방법을 명시
  • ㄴ=> 더 풍부한 형태의 프로그래밍 가능성을 상상 가능
  • ㄴ=> 변수, 범용 산술，진릿값 연산과 같은 높은 수준의 구조를 가진 변수, 함수 및 조건문뿐만 아니라 라인 속도로 데이터그램 처리를 위해 특별히 설계된 구조체를 가진 프로그래밍 언어