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

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)

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]

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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)

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)

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

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

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

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