21. Programmable Data Plane

개요

이전 Control plane을 Programmable하게 한 SDN과 달리 이번에는 Data Plane을 Programmable하게 한 p4에 대해서 학습한다. 좀 더 유연한 방식으로 SDN보다 더 최신 기술이다.

SDN의 문제점

각각의 Switch, Router는 OpenFlow등의 API를 사용해서 Logically centralized된 controller로부터 table을 받아서 처리하는 방식이었는데 중요한 부분은 각 Switch, Router는 해당 spec을 만족해야 한다는 점이다. API(Packet-in, out, feature, configuration etc)와 호환이 되어야 하고 Controller와도 정상적으로 통신이 가능해야 한다. 근데 이게 문제가 OpenFlow도 점점 거대화되면서 만족해야 할 Spec이 너무 많아진 것 결국 Bender들도 좀 빡쳤는지 이것에 대한 불만이 많았다. 이에 PISA(Protocol Independent Switch Architecture)를 제안하여 OpenFlow에 대한 종속성을 제거하려고 시도했다.

대충 이런 Architecture를 고안해냈다.

P4

위와 같은 구조로 전체 Spec을 다 구현할 필요 없이 필요한 부분만 Programmable하게 API로 구현이 가능하다. 기존의 Fix된 ASIC으로는 전체 Spec을 다 지켜서 구현한 다음 이를 생산해야 하는데 이러한 방식과 달리 사용자가 필요한 API 부분에 대해 알아서 구현하고 나머지 필요 없는 부부은 구현을 하지 않고 두어 Bender는 생산하기 편하고 사용자는 원하는대로 구축할 수 있는 보다 더 유연한 Data Plane을 구축할 수 있게 된다.

1. New Features: 새로운 프로토콜에 대처가 빠르다.

2. Reduce complexity: 사용하지 않는 부분은 제거하고 필요한 부분만 Programming 하면 된다.

3. Efficient use of resource: 2번과 같은 맥락으로 필요한 부분만 사용하면 되기 때문

4. Greater visibility: 새로운 기술이나 측정에 대해 더 가시적으로 변경이 가능하다(무슨 말인지 잘 모르겠다;;)

5. SW style development: 빠른 디자인, 개발, 디버깅 등이 가능하다.

6. You keep your own ideas: 원하는 대로 Program이 가능하니 연구 분야에서도 용이하다.

PISA

위에서 봤다시피 PISA는 Protocol에 독립적으로 동작할 수 있는 Switch에 대한 Architecture를 말한다.

간단하게 설명하자면 먼저 Packet은 Parser를 통해 Header 정보가 Parsing된다. 그리고 해당 정보를 통해 Match Action을 수행하고 Header의 정보는 추가되거나 삭제되는 등 변경이 가능하다. 이후 직렬화되어 전송된다. 여기서 각 요소 Parsers, Controls 등은 Programmable하기에 사용자가 임의로 설정이 가능하다. 위와 같은 모델은 V1 모델이고 이것 말고도 SimpleSumeSwitch, Portable Switch Architecture 도 있는데 각각 사용하는 Target이 다르다. 상황에 맞춰 사용하면 된다.

Programmable a P4 Target

위 그림은 P4 Programming 모델로 여기서 중요한 건 저기 Runtime 부분으로 OpenFlow와 유사하게 상위 Control Plane과 아래 Data Plane으로 API를 제공하는 역할을 한다.

P4

이게 가장 흔히 볼 수 있는 IP forwarding 그림으로 각각의 Table을 보고 적절한 곳으로 forwarding 하는 것이 일반적인데 P4는 여기서 저 Router를 위에서 배운 PISA 형태의 Router로 변경하는 것이다. 위에서 배운 Parser, Match-Action Pipeline, Deparser(serialization) 모든 부분을 실제 코드 짜듯이 함수를 기반으로 Programming 할 수 있다. 

Parser

기본적으로 State machine 방식을 사용하며 크게 3가지 State를 가진다. Start, Accept, Reject로 이 사이 TCP, UDP 등 여러 상태를 임의로 Programmable하게 설정할 수 있다.

Match-Action Pipeline

패킷이 어떻게 처리되어야 하는지, Header의 필드를 나누어 drop할 지 pass할 지 action과 key로 설정하여 Control Flow, Actions, Tables로 하여 Control 구조체를 만든다.

Control Flow

이는 Packet이 어떻게 process되어야 하는지를 선언하는 부분으로 forwarding하거나 address swap, ttl -1, Update MAC Address 등을 수행하는 함수를 선언해놓는 부분이다.

Actions

위에서 선언해놓은 Control flow를 통해 실제 Packet이 왔을 때 해당 함수를 호출하거나 인자를 전달하여 Action을 하는 부분이다. 

Tables

Match-Action 을 Key Value pair로 저장해놓는 부분으로 Control Plane으로부터 정보를 받아 저장한다. 여기서도 기존 table과 같이 Key에 해당하는 값이 Match 부분으로 가 Longest prorix match를 통해 해당 조건을 검사한다. 이를 통해 헤더에 대한 사용자 정의 조건으로 Action을 수행하게 할 수 있다. 

Deparser

Packet의 Header를 다시 직렬화 하는 부분으로 문자열로 Parsing한 부분을 다시 전송할 수 있는 형태로 바꾸는 작업이다. Payload는 Switch에서는 굳이 볼 필요 없으니까 여기는 그냥 뒤에 붙이기만 하면 되고 Header만 직렬화 하면 된다.