1. P4: Programming Protocol-Independent Packet Processors
Pat Bosshart, et al.
ACM SIGCOMM Computer Communication Review, July 2014

2. Introduction SDN gives operators programmatic control over networks
Common, open, vendor-agnostic interface (e.g., OpenFlow) enables control plane to control forwarding devices from different hardware and software vendors
OpenFlow started simple (1.0), with abstraction of single table of rules that could match packets on a dozen header fields → more header fields and multiple stages of rule tables (1.4)
DCN deploys software switches to extend with new functionality with new forms of packet encapsulation (new packet format/header fields)

3. Motivations
Need flexible mechanisms for parsing packets and matching header fields → allowing controller applications to leverage these capabilities through a common, open interface
Recent chip designs demonstrate that such flexibility can be achieved in custom ASICs at terabit speeds
But programming such chips is not easy because each chip has its own microcode programming
➡ Higher-level language for Programming Protocol- independent Packet Processors (P4) [or to configure switches]

4. P4 vs. OpenFlow raises level of abstraction for programming networks
allow controller to tell switches how to operate, rather than be constrained by a fixed switch design
P4 configures switch - telling it how packets are to be processed
OpenFlow populates forwarding tables in fixed function switches

5. Challenge
Balance expressiveness with ease of implementation across a wide range of hardware and software switches

6. Design Goals
Reconfigurability: be able to redefine the packet parsing and processing in the field (e.g., FPGA)
Protocol independence: switch should not be tied to specific packet formats; controller be able to specify
a packet parser for extracting header fields with particular names and types
a collection of “typed” match+action tables that process these headers
Target independence:
Controller programmer does not need to know details of underlying switch, similar to writing C code for any processor
a compiler should take switch’s capabilities into account when turning a target-independent description (written in P4) into a target-dependent program (used to configure switch)

7. How? How do you design a programming language? What does a switch do?
abstract model of processor (or computation)
language syntax and semantics
What does a switch do?
introduce an abstract switch forwarding model
Design new language to describe protocol-independent packet processing
match and action (forward)
Motivating example: support new packet-header field and process packets in multiple stages
how P4 program specifies headers, packet parser, multiple match+action tables, and control flow through these tables
how a compiler can map P4 programs to target switches

8. Abstract Forwarding Model
in P4
Three extension from OF
OF assumes fixed parser, whereas P4 model supports programmable parser to allow new headers to be defined
OF assumes match+action stages are in series, whereas in P4 they can be in parallel or in series
In P4, actions are composed from protocol-independent primitives supported by switch
switches forward packets via a programmable parser followed by multiple stages of match+action, arranged in series, parallel, or a combination of both

9. Abstract Model and Hardware
Abstract model generalizes how packets are processed in different forwarding devices (e.g., Ethernet switches, load-balancers, routers) and by different technologies (e.g., fixed-function switch ASICs, NPUs, reconfigurable switches, software switches, FPGAs)
This allows to devise a common language (P4) to represent how packets are processed in terms of common abstract model
Programmers can create target-independent programs that compiler can map to a variety of different forwarding devices, ranging from slow software switches to fastest ASIC-based switches

10. Abstract Forwarding Model
Controlled by two types of operations
configure: program parser, set order of match+action stages, and specify header fields processed by each stage; determines which protocols are supported and how the switch may process packets
populate: add (and remove) entries to match+action tables that were specified during configuration; determines policy applied to packets at any given time
Goals:
Implementations allows packet processing during partial or full reconfiguration enabling upgrades with no downtime
Model deliberately allows for, and encourages, reconfiguration that does not interrupt forwarding

11. Forwarding Model
Configuration phase has little meaning in fixed- function ASIC switches
for this type of switch, compiler’s job is to simply check if chip can support P4 program
To capture general trend towards fast reconfigurable packet-processing pipelines from Intel and other vendors

12. Operations Arriving packets are first handled by parser
Packet body is buffered separately, and unavailable for matching
Parser recognizes and extracts fields from header, and thus defines protocols supported by switch
Model makes no assumptions about meaning of protocol headers, only that parsed representation defines a collection of fields on which matching and actions operate

13. Operations
Extracted header fields (values) are then passed to the match+ action tables
Match+action tables are divided between ingress and egress; both may modify packet header
ingress match+action determines egress port(s) and determines queue into which packet is placed; based on ingress processing, packet may be forwarded, replicated (for multicast, span, or to control plane), dropped, or trigger flow control
egress match+action performs per-instance modifications to packet header, e.g., for multicast copies
Action tables (counters, policers, etc.) can be associated with a flow to track frame-to-frame state

14. Operations
Packets can carry additional information (termed metadata) between stages, which is treated identically to packet header fields
examples of metadata: ingress port, transmit destination and queue, timestamp that can be used for packet scheduling, and data passed from table-to-table that does not involve changing parsed representation of packet such as a virtual network identifier
Queueing disciplines are handled in same way as OpenFlow: an action maps a packet to a queue, which is configured to receive a particular service discipline
service discipline (e.g., minimum rate, DRR [Deficit Round Robin scheduler]) is chosen as part of switch configuration

15. P4 Example - mTag
L2 network with top-of-rack (ToR) switches at edge connected by two-tier core
Routes through core are encoded by 32-bit tag composed of four single-byte fields as source route
Each core switch need only examine one byte of tag and switch on that information

16. P4 Concepts P4 program contains definitions of following components
Header: define sequence and structure of a series of fields, including specification of field widths and constraints on field values
Parser: specify how to identify headers and valid header sequences within packets
Tables: match+action tables are mechanism for performing packet processing; P4 program defines fields on which a table may match and actions it may execute
Actions: P4 supports construction of complex actions from simpler protocol-independent primitives; these complex actions are available within match+action tables
Control Programs: determines order of match+action tables that are applied to a packet; imperative program describes flow of control between match+action tables

17. Header Format - Ethernet
dest.
address
source
data (payload)
CRC
preamble
Type (of payload)
Each header is specified by declaring an ordered list of field names together with their widths
Optional field annotations allow constraints on value ranges or maximum lengths for variable-sized fields

18. Header Format - VLAN 802.1 frame 802.1Q frame
type
source
address
802.1 frame
preamble
dest.
address
data (payload)
CRC
type
dest.
address
source
preamble
802.1Q frame
data (payload)
CRC
2-byte Tag Protocol Identifier (value: x8100)
Tag Control Information (3-bit Priority Code Point field, 1-bit Canonical Format Indicator, and 12-bit VLAN ID field)

19. Header Format - mTag
Field names indicate that core has two layers of aggregation
Each core switch is programmed with rules to examine one of these bytes determined by its location in the hierarchy and direction of travel (up or down)

20. Packet Parser
P4 assumes underlying switch can implement a state machine that traverses packet headers from start to finish, extracting field values as it goes
The extracted field values are sent to the match+action tables for processing
P4 describes this state machine directly as set of transitions from one header to the next
Each transition may be triggered by values in current header

21. Packet Parser - Example
Parsing starts in start state and proceeds until an explicit stop state is reached or an unhandled case is encountered (marked as an error)
Upon reaching a state for a new header, state machine extracts header using its specification and proceeds to identify its next transition
Extracted headers are forwarded to match+action processing in back-half of switch pipeline

22. Table
Table describes how defined header fields are to be matched in match+action stages (e.g., exact matches, ranges, or wildcards) and what actions should be performed when a match occurs
For mTag, edge switch matches on L2 destination and VLAN ID, and adds an mTag to header
Programmer defines a table to match on these fields and apply an action to add mTag header
// declare which fields to match
// qualified by match type
// list actions
// how many entries table supports

23. Action
P4 defines a collection of primitive actions from which more complicated actions are built
Each P4 program declares a set of action functions that are composed of action primitives; these action functions simplify table specification and population
P4 assumes parallel execution of primitives within an action function