목적지 IP 주소를 찾은(매치) 후 패킷을 스위치 구조로 지정된 출력 포트로 전송(액션)하는 두 단계의 목적지 기반 포워딩을 앞서 설명했다.
프로토콜 스택의 다른 계층에서 다른 프로토콜과 관련된 여러 헤더 필드에 대해 매치를 수행할 수 있는 일반적인 매치 플러스 액션 방법을 생각해보자.
액션은 하나 이상의 출력 포트로 패킷을 전달하고, 인터페이스에서 나가는 패킷을 로드 밸런싱(load balancing)하고 헤더값을 다시 쓰고, 의도적으로 패킷을 차단/삭제 및 추가 처리 작업을 위해 특수 서버로 패킷을 보내는 등의 작업을 수행한다.
일반화된 포워딩에서는 각각의 패킷 스위치는 원격 컨트롤러에 의해 계산 및 분포된 매치 플러스 액션 테이블을 포함하고 있다.
위 그림은 매치 플러스 액션 테이블을 보여준다.
명확하고 간결한 방식으로 SDN 개념 및 기능을 도입한 OPenFlow 1.0을 살펴보자.
OpenFlow의 플로우 테이블로 알려진 매치 플러스 액션 포워딩 테이블의 각 엔트리는 다음을 포함한다.
- 들어오는 패킷에 대한 헤더값들의 세트가 매치될 것이다. 하드웨어 기반 매치는 TCAM 메모리에서 가장 신속하게 수행되며, 백만 개가 넘는 목적지 주소를 동반한다. 플로우 테이블 엔트리와 매치되지 않는 패킷은 더 많은 처리를 위해 원격 컨트롤러로 전송될 수 있다.
- 패킷들에 의해 갱신되는 카운터 세트는 플로우 테이블 엔트리들과 매치된다. 이러한 카운터는 플로우 테이블 엔트리와 마지막으로 갱신된 테이블 엔트리 이후에 매치된 다수의 패킷을 포함하고 있다.
- 패킷이 플로우 테이블 엔트리와 매치될 때 여러가지 액션이 가능해진다. 이러한 액션은 패킷을 지정된 출력 포트로 전달하고, 패킷을 삭제하고, 패킷의 복사본을 만들어 여러 출력 포트로 보내거나 선택한 헤더 필드를 다시 쓰는 것일 수 있다.
위 그림은 OpenFlow 1.0 매치 플러스 액션 규칙에서 매치될 수 있는 11개의 패킷 헤더 필드와 수신 포트 ID를 보여준다.
진입 포트는 패킷이 수신되는 패킷 스위치의 입력 포트를 나타낸다.
플로우 테이블 엔트리에는 와일드카드도 있을 수 있다. 예를 들어, 플로우 테이블의 128.119.*.* 의 주소는 128.119를 주소의 첫 번째 16 비트로 갖는 데이터그램의 해당 주소 필드와 매치된다.
또한 각 플로우 테이블 엔트리에는 우선순위가 있어 여러 플로우 테이블 엔트리와 매치되면, 선별된 매치 엔트리에 해당하는 패킷이 가장 높은 우선순위가 된다.
IP 헤더의 모든 필드가 매치될 수 있는 것은 아니다.
예를 들어 OpenFlow에서는 TTL 필드 또는 데이터그램 길이 필드에 기반한 매치를 허용하지 않는다.
플로우 테이블 엔트리는 플로우 테이블 엔트리와 매치되는 패킷 처리를 결정하는 0개 이상의 액션 목록을 갖고 있다.
여러 액션이 있는 경우 목록에 지정된 순서대로 수행된다.
가장 중요한 액션들은 다음과 같다.
- 포워딩
- 들어오는 패킷은 특정 실제 출력 포트로 전달되거나 모든 포트를 통해 브로드캐스트되거나 선택된 포트 세트를 통해 멀티캐스트될 수 있다.
- 패킷은 캡슐화되어 원격 컨트롤러로 전송될 수 있다.
- 컨트롤러는 새 플로우 테이블 엔트리를 설치하고 해당 패킷에 대한 조치를 취하거나 갱신된 플로우 테이블 규칙에 따라 포워딩을 위해 패킷을 장치로 반환할 수 있다.
- 삭제
- 아무 액션이 없는 플로우 테이블 엔트리는 매치된 패킷을 삭제해야함을 나타낸다.
- 필드 수정
- 패킷이 선택된 출력 포트로 전달되기 전에 10개의 패킷 헤더 필드의 값을 다시 쓸 수 있다.
위 그림의 상황을 가정하고 다음 예시들을 보자.
아주 간단한 예로 포워딩 동작이 h3 또는 h4로 예정된 h5 또는 h6 패킷이 s3에서 s1으로 전달된 다음 s1에서 s2로 전달된다고 가정한다.
위 상황에서 s1의 플로우 테이블 엔트리는 다음과 같다.
s3에 플로우 테이블 엔트리가 필요하므로 h5 또는 h6에서 전송된 데이터그램은 인터페이스 3을 통해 s1으로 전달된다.
마찬가지로, s1에 도착한 데이터그램을 호스트 h3 또는 h4로 전달할 수 있도록 s2에 플로우 테이블 엔트리가 필요하다.
위를 바탕으로 직접 채워보길 바란다.
두 번째 예로 h3에서 10.1.*.*로 향하는 데이터그램이 s2와 s1 사이의 링크를 통해 전달되는 반면, h4에서 10.1.*.* 로의 데이터그램은 s2와 s3 사이의 링크를 통해 전달되는 로드 밸런싱 시나리오를 고려해보자.
이 동작은 IP의 목적지 기반 포워딩으로 수행될 수 없다.
이 경우 s2의 포워딩 테이블은 다음과 같다.
s2에서 수신한 데이터그램을 h1 또는 h2로 전달하려면 s1에서 플로우 테이블 엔트리가 필요하다.
인터페이스 4에서 수신한 데이터그램을 s3에서 인터페이스 3을 통해 s1로 전달하려면 s3에서 플로우 테이블 엔트리가 필요하다. s1및 s3에서 이러한 플로우 테이블 엔트리를 파악할 수 있는지 확인하자.
s2가 s3에 연결된 호스트에서 보낸 트래픽만 수신하려고 하는 방화벽 시나리오를 생각해보자.
s2 플로우 테이블에 다른 엔트리가 없으면 10.3.*.*의 트래픽만 s2에 연결된 호스트로 전달된다.
매치 플러스 액션 플로우 테이블은 제한된 형태의 프로그래밍 가능성이다.
데이터그램의 헤더값과 매치 조건 사이의 매치를 기반으로 라우터가 데이터그램을 전달하고 조작하는 방법을 명시한다.
따라서 더 풍부한 형태의 프로그래밍 가능성을 상상할 수 있다.
미들 박스의 정의
💡출발지 호스트와 목적지 호스트 사이의 데이터 경로에서 IP 라우터의 정상적이고 표준적인 기능과는 별도로 기능을 수행하는 모든 미들박스
미들 박스가 수행하는 세 가지 유형의 서비스를 광범위하게 식별할 수 있다.
- NAT 변환 : NAT 박스는 사설 네트워크 주소체계를 구현하여 데이터그램 헤더 IP 주소 및 포트 번호를 다시 작성한다.
- 보안 서비스 : 방화벽은 헤더 필드 값을 기준으로 트래픽을 차단하거나 DPI(Deep Packet Inspection) 같은 추가 처리를 위해 패킷을 리다이렉션한다. 침입 탐지 시스템(IDS)은 미리 결정된 패턴을 탐지하고 그에 따라 패킷을 필터링할 수 있다.
- 성능 향상 : 미들박스는 압축과 같은 서비스를 수행한다. 즉, 원하는 서비스를 제공할 수 있는 서버 집합 중 하나에 대한 서비스 요청의 로드 밸런싱을 하는 주체다.
미들 박스는 네트워크 계층과 트랜스포트계층, 애플리케이션 계층을 명확히 구분하는 이전 네트워크의 분리를 명백히 위반한다.
예를 들어, 라우터와 호스트 사이에 위치한 NAT 박스는 네트워크 계층 IP 주소와 트랜스포트 계층 포트 번호를 다시 쓴다.
네트워크 내의 방화벽 블록은 IP 데이터그램 헤더 뿐만 아니라 애플리케이션 계층, 트랜스포트 계층 헤더까지 사용하여 데이터그램을 의심한다.
미들박스를 아키텍처적으로 혐오스럽다고 간주하는 사람들도 있지만, 다른 이들은 이러한 미들 박스가 '중요하고 영구적으로 존재한다'는 철학을 채택하고 있다.
포워딩 테이블(목적지 기반 포워딩의 경우)과 플로우 테이블(일반화된 포워딩의 경우)이 네트워크 계층의 데이터 평면과 제어 평면을 연결하는 수요 요소였는데,
이 테이블들이 라우터의 로컬 데이터 평면에서의 포워딩을 지정했다.
바로 이전 장에서의 그림을 상기해보자.
일반화된 포워딩의 경우에 라우터가 취하는 행동은 다양한 형태로 나타날 수 있었다.
- 라우터의 출력 포트로 패킷을 전달
- 패킷을 버리거나 복제
- 2, 3, 4계층의 헤더 필드를 재작성
이 장에서는 포워딩 테이블이나 플로우 테이블이 어떻게 만들어지고 유지 및 설치되는지를 알아볼 것이다.
💡 개별 라우팅 알고리즘들이 제어 평면에서 상호작용한다.
아래 그림은 라우팅 알고리즘들이 모든 라우터 각각에서 동작하는 경우를 나타낸다.
- 포워팅과 라우팅 기능이 모두 개별 라우터에 포함되어 있다.
- 각 라우터는 다른 라우터의 라우팅 구성요소와 통신하여 자신의 포워딩 테이블의값을 계산하는 라우팅 구성요소를 갖고 있다.
- OSPF, BGP 프로토콜이 이 라우터별 제어 방식을 기반으로 한다.
💡 일반적으로 원격에 위치한 별개의 컨트롤러가 지역의 제어 에이전트(CA)와 상호작용한다.
아래 그림은 논리적 중앙 집중형 컨트롤러가 포워딩 테이블을 작성하고, 이를 모든 개별 라우터가 사용할 수 있도록 배포한 경우를 나타낸다.
일반화된 ‘매치 플러스 액션(match plus action)’ 추상화를 통해
라우터는 기존에는 별도로 장치로 구현되었던 다양한 기능(부하 분산, 방화벽, NAT) 뿐만 아니라 전통적인 IP 포워딩을 수행할 수 있다.
컨트롤러는 프로토콜을 통해 각 라우터의 제어 에이전트(control agent, CA)와 상호작용하여 라우터의 플로우 테이블을 구성 및 관리한다.
라우터별 제어 방식과는 다르게, CA는 서로 직접 상호작용하지 않으며, 포워딩 테이블을 계산하는 데도 적극적으로 참여하지 않는다.