OpenFlow

Intro

SDN의 본격적인 시작이 OpenFlow라고 보아도 무방하다. OpenFlow는 2007년 Stanford 대학에서 개발이 시작되었고, 지금도 de facto standard(사실상의 표준)으로 받아들여지고 있는 Protocol이다. 해당 Protocol의 핵심은 기존 Switch/Router를 data plane(데이터 평면)과 control plane(제어 평면)으로 나누고, 제어 평면을 OpenFlow Protocol에 따르는 Controler로 대체하면서, OpenFlow Protocol을 따르는 Switch는 data plane만을 포함하여, 둘 간의 통신을 통해서 제어 평면을 구성하자는 것이다. 여기서 데이터 평면은 실제로 interface로 packet이 들어오고, 내보내는 역할을 하는 계층이라고 보면 되고, 제어 평면은 packet에 어떤 동작을 수행시킬지 그리고 어느 interface로 내보낼지를 결정하는 역할을 하는 계층이라고 보면 된다. 이러한 구성을 통해서, 결국 SDN을 구축할 수 있는 토대를 제공하게 된 것이다.

OpenFlow Switch

OpenFlow Switch는 다음과 같은 형태로 구성되어진다.

OpenFlow Protocol

해당 사항은 reference에 기반한 version 1.3.1의 기능을 요약한 내용이다.

기본적으로 OpenFlow Protocol을 지원하는 Switch의 구조부터 알아보아야 한다. Switch는 기본적으로 외부와 연결이 가능한 Port, Routing을 위한 여러 개의 Table, 그리고 Controller와의 의사소통을 위한 Channel을 가진다. 각 요소의 역할을 간략히 하나하나 알아보도록 하자.

1. Port

OpenFlow에서 packet이 Switch로 왔다갔다하는 통로라고 볼 수 있다. 대게 Switch를 가르키거나 packet의 진입 위치를 식별할 때 사용된다. 이는 실제로 존재하는 것이 아닌 추상화된 개념으로, 총 3가지의 Port를 통해서 Switch를 가르킬 수 있다. 각 Switch는 여러 개의 Port를 가지고 이를 통해서 다른 Switch들과도 연결되어진다.

• Physical Port : 실제 Switch의 interface와 일대일로 대응되는 가상 Port이다. 즉, 해당 interface로 packet이 들어왔다면, OpenFlow에서는 이와 대응되는 port로 packet이 들어왔다고 판단한다.
• Logical Port : OpenFlow를 쓰지 않고, Switch 자체적으로 정의한 Tunnel과 Loopback과 같은 가상 Port이다.
• Reserved Port : OpenFlow Protocol에 의해서 정의된 Port이다. 이를 통해서, Controller, All, Table의 맨 처음, IN_PORT 등을 쉽게 가르킬 수 있다.

2. Table

Switch는 여러 개의 Table을 가지고 있다. Table을 통해서 Switch는 Routing을 수행하는 것은 기본적인 Switch의 동작과 동일하다. Switch의 특정 Port로 packet이 들어왔을 때, packet의 목적지와 진입한 Port, 그 외에 metadata에 기반하여 matching을 수행하여 일치하는 대상을 찾아서, 해당 Table에 기술된 동작을 수행하는 것이다. 대게 무슨 동작을 수행할 것인가에 따라서 종류가 나뉘어지며, v1.3.1에는 총 3가지의 종류가 존재한다.

1. Flow Table : 대게 어떻게 Packet을 어느 Port로 Routing할 것인가를 다룬다. 뿐만 아니라 Packet의 Header를 변경하거나 MPLS Label과 같은 추가 정보를 더하는 등의 동작을 수행할 수 있다. (각 Switch는 하나 이상의 Flow Table을 소유한다.)
2. Group Table : 패턴과 일치하는 packet에 대해서 여러 동작을 수행하게 하거나 상황에 따라 다르게 적용하도록 하기 위해서 사용할 수 있다. (각 Switch는 1개 이하의 Group Table을 소유한다.)
3. Meter Table : packet의 빈도(rate) 조절과 측정을 수행할 수 있다. (Meter Table은 Controller에 의해서 관리된다.)

3. OpenFlow Channel

OpenFlow Switch 내부에서 Controller를 연결하는 Interface로 Switch의 상태를 Controller에게 알리거나 Controller로 부터 변경사항을 전달 받기 위한 통신 채널이다.

이렇게 이루어진 OpenFlow Switch들은 서로 연결되어 있으며, 하나 또는 여러 Controller와 각 각 연결되어 있다. Controller는 각 OpenFlow Switch로 부터 상태 정보와 인접 Switch 정보 등을 전달받아서 내부적으로 Flow Table을 구축한다. 그리고, Controller에서 중앙 통제를 통해서 전체 네트워크를 관리할 수 있는 것이다. 이를 수행할 때에는 Controller에서 각 Switch의 Table을 지정함으로써 구현이 가능하다. 그렇다면, Switch에 Table을 설치하였을 때, 어떻게 Packet을 처리하는지에 대해서 알아보자.

Pipeline

Switch 내부에는 여러 개의 Table이 존재하는데, Packet이 Switch의 특정 Port로 들어오면, 먼저 Flow Table을 거치게 된다. Switch 내부의 여러 Flow Table 중에서 index($\ge 0$)가 작은 값부터 시작하여 Flow Table에서 일치하는 pattern의 Flow Entry를 찾게 된다(Flow Table의 하나의 열). 해당 Entry에 적힌 Instruction에 따라 Action을 바로 수행하거나 Action Set에 추가한 후에 다음 Table 또는 Port를 통해서 다음 Switch로 이동하게 된다. 이때 Port 밖으로 나가기 이전에 Action Set에 모아둔 Action을 한 번에 수행한다.
만약, Flow Table의 어떤 pattern과도 일치하지 않는다면, 이를 Table Miss라고 하고, 미리 지정해둔 miss flow entry에 따라 Action을 수행한다. 아무 설정도 하지 않았다면 default로 해당 packet을 drop한다.

그렇다면, 각 Table을 구성하는 요소(entry)들이 어떻게 구성되는지를 확인해보자.

1. Flow Entry

• Match Field : 일치하는 Packet을 찾기 위하여 Ingress Port / Egress Port / Packet Header / 다른 Table에서 생성된 Metadata 등을 사용한다.
• Priority : 일치하는 대상이 많을 경우, 높을 수록 조회 시에 우선시 되어진다.
• Counters : match가 수행된 횟수를 마킹한다.
• Instructions : packet에 대해서 특정 Action을 수행시키거나 Action Set을 변경한다.
• Timeout : 최대 처리 시간 또는 남은 시간 등을 표시한다.
• Cookie : Controller에 의해 설정된 데이터로 대게 해쉬 / 암호화 되어진다. 이는 Controller에서 Flow 관측 및 조절 시에 사용한다.

2. Group Entry

• Group Identifier : Group 식별자
• Action Buckets : 여러 개의 action과 이에 해당하는 parameter를 담은 bucket들을 정렬 후 보관
• Group Type : Group의 동장 방식을 선택
  • all : 모든 bucket을 실행
  • select : bucket을 번갈아가면서 실행하여 Load Balancing을 실행
  • indirect : bucket 하나만 실행하며, bucket을 여러 개 두는 것을 허락하지 않는다.
  • fast failover : 가장 먼저 켜져있다고 판단되는 port를 가진 bucket 하나만 실행
• Counters : Group에 의해 처리된 packet의 수

3. Meter Entry

• Meter Identifier : Meter 식별자
• Meter Bands : packet rate와 이에 따른 packet 처리 방법을 가진 여러 meter band를 순서없이 저장. band를 선택할 때에는 측정된 rate보다 작으면서 가장 큰 rate를 가진 band를 선택한다. 각 band는 아래와 같이 구성된다.
  • Band Type : rate를 넘긴 후의 packet 처리 방식을 선택
    • drop : packet을 버린다.
    • dscp remark : IP header에 drop 우선순위를 높인다.
  • Rate : packet rate의 하한선
  • Couter : 처리된 packet의 수
  • Type Specific Arguments : 부가 정보
• Counters : Meter에 의해 처리된 packet의 수

마지막으로, Instruction과 Action 그리고 Action Set의 구성을 살펴보자.

1. Instruction

Instruction은 다음과 같은 종류가 있다. 이를 통해서 명령을 적용하거나 Table을 이동하고, ActionSet을 변경하는 것이 가능하다.

1. meter meter_id : packet에 특정 meter를 적용
2. apply-actions action(s) : packet에 해당 action(s)를 즉각적으로 수행
3. clear-actions : Action set을 바로 비우기
4. write-actions action(s) : Action Set에 해당 action(s)를 추가
5. write-metadata metadata/mask : metadata를 추가
6. goto-table next-table-id : 특정 table로 이동. 단, 반드시 현재 Table index보다 더 큰 index로 이동해야 한다.

2. Action Set

pipeline이 종료 된 후에 실행되는 action이 저장되어 있다.

action은 기본적으로 아래 순서대로 실행되지만, 동일한 action은 들어온대로 실행되는 것이 아닌 임의로 실행된다.

1. copy TTL inwards : TTL을 체크하는 action을 실행
2. pop : 만약, packet에 tag가 존재한다면, 모두 제거한
3. push MPLS : MPLS tag(=label)을 추가
4. push PBB : PBB tag를 추가
5. push VLAN : VLAN tag를 추가
6. copy TTL outwards : TTL을 체크하는 action을 실행
7. decrement TTL : TTL을 감소시키는 action을 실행
8. set : set-field에 해당하는 action을 실행
9. qos : qos 관련 action을 실행
10. group : 연관된 group bucket의 action을 실행
11. output : output action으로 명시된 port로 packet을 forwarding

3. Action

실제로 packet을 처리하는 방법에 대한 방법이다.

1. output : OpenFlow port 중 어디로 forwarding할지를 지정
2. set-queue : QoS 지원을 위해 packet을 내보낼 Switch의 queue Id를 지정
3. drop : 직접 호출할 수는 없지만, output이 없거나 clean-actions 수행 시에 내부적으로 수행한다.
4. group : group을 통해 packet을 처리하도록 group table로 packet 전달
5. push-tag : MPLS / VLAN 등의 tag를 추가
6. pop-tag : MPLS / VLAN 등의 tag를 삭제
7. set-field : header의 가장 끝에 특정 값을 추가
8. change-ttl : ttl값을 수정

표준화 현황

현재에는 OpenFlow 표준화는 중단된 상태이다. 모든 요구사항을 받아들이다보니 match field의 크기가 너무나 커졌기 때문이다. 따라서, 이용자의 요구에 따라서 programming 할 수 있는 환경을 제공하기 위한 P4(Programmable Protocol-Independent Packet Protocol)을 제작하였다.

즉, 기존에는 Protocol과 이를 지원하는 Switch를 주요 서비스로 삼았다면, 이제는 Programming이 가능한 언어와 이를 이용할 수 있는 Switch를 제공하는 방향으로 전환하였다.

Reference

• Openflow specification, ONF, 2012
• Thumbnail: Photo by Maksym Tymchyk 🇺🇦 on Unsplash