Source-linked AI summary
Programming Protocol-Independent Packet Processors
Pat Bosshart, Dan Daly, Martin Izzard, Nick McKeown, Jennifer Rexford, Cole Schlesinger, Dan Talayco, Amin Vahdat, George Varghese, David Walker
TL;DR
OpenFlow targets fixed-function switches with predetermined headers and actions, limiting how controllers express packet processing. This paper proposes P4, a protocol- and target-independent configuration language whose compiler maps forwarding programs to diverse switch targets, illustrated by hierarchical tags.
Problem
OpenFlow exposes fixed-function switches with predetermined headers and actions, limiting controllers’ ability to express how packets should be processed.
Method
P4 specifies packet parsing and forwarding behavior at a higher abstraction, while a compiler analyzes dependencies and generates configurations for diverse targets.
Results
P4 expresses mTag, a 32-bit hierarchical tag combining source routing or destination location information for core-switch forwarding.
Takeaways & Limitations
The proposal points toward OpenFlow interfaces that let controllers define and change packet-processing behavior without depending on specific protocols or hardware.
Takeaways & Limitations
As a straw-man proposal, P4 leaves congestion-control primitives, queuing disciplines, and traffic monitoring undefined.
Abstract
from arXiv · showhide
P4 is a high-level language for programming protocol-independent packet processors. P4 works in conjunction with SDN control protocols like OpenFlow. In its current form, OpenFlow explicitly specifies protocol headers on which it operates. This set has grown from 12 to 41 fields in a few years, increasing the complexity of the specification while still not providing the flexibility to add new headers. In this paper we propose P4 as a strawman proposal for how OpenFlow should evolve in the future. We have three goals: (1) Reconfigurability in the field: Programmers should be able to change the way switches process packets once they are deployed. (2) Protocol independence: Switches should not be tied to any specific network protocols. (3) Target independence: Programmers should be able to describe packet-processing functionality independently of the specifics of the underlying hardware. As an example, we describe how to use P4 to configure a switch to add a new hierarchical label.
1. INTRODUCTION
The introduction argues that OpenFlow’s growing complexity and fixed protocol assumptions motivate a more flexible switch-programming interface. It presents P4 as a higher-level language for protocol-independent packet processors and a possible controller–switch interface.
- Motivation: OpenFlow evolved from a simple single rule table matching about a dozen header fields into a more complex specification with additional fields and multiple table stages.The added stages expose more switch capabilities to the controller.
- Motivation: New encapsulations such as NVGRE, VXLAN, and STT are increasing demand for flexible packet parsing and header-field matching.Operators have resorted to software switches because they are easier to extend with new functionality.
- P4 proposal: P4 is proposed as a higher-level language for programming protocol-independent packet processors and as a general interface between controllers and switches.The proposal raises the abstraction level above chip-specific low-level interfaces akin to microcode programming.
- Design goals: The design aims for reconfigurability, allowing controllers to tell switches how to operate rather than constraining them to fixed switch designs.The introduction identifies balancing expressiveness with ease of implementation across diverse hardware and software switches as the key challenge.
2. ABSTRACT FORWARDING MODEL
The abstract forwarding model uses a programmable parser and configurable match+action stages to process packets independently of protocols and hardware targets. Separate Configure and Populate operations define processing capabilities and current packet policy, while supporting reconfiguration without interrupting forwarding.
- Abstract forwarding model: P4 models forwarding as a programmable parser followed by match+action stages arranged in series, parallel, or combinations of both.The model generalizes OpenFlow’s fixed parser and serial stages, and composes actions from protocol-independent primitives.
- Abstract forwarding model: The common model spans Ethernet switches, routers, load-balancers, and diverse targets including ASICs, NPUs, reconfigurable switches, software switches, and FPGAs.This enables P4 programs to describe packet processing independently of the target, with compilation mapping programs to different forwarding devices.
- Control operations: Configure operations program the parser, order match+action stages, and specify processed fields, while Populate operations modify the resulting table entries and packet policy.Configuration determines supported protocols and processing capabilities; population determines the policy applied at a given time.
- Reconfiguration: The model separates configuration from population and encourages partial or full reconfiguration that allows packet processing to continue during upgrades.The paper assumes packets need not be processed during configuration, but anticipates implementations enabling upgrades with no downtime.
- Packet processing: The parser extracts header fields without assuming their meaning, and match+action tables operate on those fields plus metadata carried between processing stages.Metadata can include ingress port, transmit destination and queue, timestamps, and virtual network identifiers.
- Packet processing: Ingress processing determines egress ports and queues and may forward, replicate, drop, or trigger flow control, while egress processing performs per-instance header modifications.Queue service disciplines such as minimum rate and DRR are selected through switch configuration.
3. A PROGRAMMING LANGUAGE
P4 defines packet processing through declared header types, imperative control flow, and primitive actions, while compiling programs into dependency-aware representations that map to specific switch targets.
- 3. A PROGRAMMING LANGUAGE: P4 declares legal header types so the parser knows which packet formats to expect.This provides the basis for processing packet headers in the language.
- 3. A PROGRAMMING LANGUAGE: An imperative control-flow program describes header-field processing using declared types and primitive actions such as decrementing TTLs, adding tunnel headers, and computing checksums.The language supports expressing how packet headers are processed after parsing.
- 3. A PROGRAMMING LANGUAGE: P4 mirrors parse-match-action pipelines in dedicated hardware rather than offering Click’s unconstrained C++ module model.Click is expressive for CPU-kernel packet processing but does not provide the constraints needed to infer hardware-oriented processing structure.
- 3. A PROGRAMMING LANGUAGE: Header-field dependencies determine which tables can execute in parallel, with data-dependent IP routing and ARP tables requiring sequential execution.Table Dependency Graphs capture table field inputs, actions, and control flow for dependency analysis.
- 3. A PROGRAMMING LANGUAGE: Compilation first translates the imperative P4 program into a Table Dependency Graph and then maps that graph to a specific switch target.P4 is designed to make translation into TDGs straightforward.
4. P4 LANGUAGE BY EXAMPLE
This section illustrates P4 through mTag, a custom hierarchical-tagging solution for simplifying a growing core L2 network without changing existing header declarations. It then shows how P4 specifies headers, parsing, match+action tables, and control flow for the processor.
- mTag example: P4 addresses overflowing core L2 tables by expressing mTag, which combines PortLand-style hierarchical routing with simple MPLS-like tags.The example avoids PortLand’s MAC rewriting and new ARP agents while requiring minimal architectural changes.
- mTag example: mTag uses a 32-bit tag with four single-byte fields, allowing each core switch to examine only the byte determined by hierarchy and travel direction.The fields represent two upward and two downward aggregation layers; the tag can carry a source route or destination locator.
- P4 processor components: A P4 program defines headers, parsers, match+action tables, and a control program that determines table order and packet-processing flow.Header declarations specify ordered fields, widths, and optional constraints; tables define matches and actions.
- P4 processor components: P4 parsers describe header-traversal state machines whose extracted fields feed match+action processing, stopping explicitly or on an unhandled case.The mTag parser has only four states, whereas a real-network parser example expands to over one hundred states.
- P4 processor components: In the mTag example, an edge switch matches the L2 destination and VLAN ID, then applies an action that adds and parameterizes the mTag header.The action inserts mTag after VLAN, copies the VLAN ethertype, sets VLAN ethertype to 0xaaaa, fills tag fields, and sets the egress port.
5. COMPILING A P4 PROGRAM
The P4 compiler maps target-independent programs onto specific switch hardware or software by allocating resources and generating device configuration. It analyzes parsing and forwarding behavior, including dependencies and parallelism, then adapts the result to diverse target architectures.
- Compilation process: The compiler maps a target-independent P4 description onto a switch’s specific hardware or software platform by allocating resources and generating configuration.This compilation step is required for a network to implement the P4 program.
- Parser compilation: For programmable parsers, the compiler generates a parsing state machine; for fixed parsers, it verifies parser-description consistency with the target.Parser state-table entries specify the current state, matched field value, and next state.
- Control-program compilation: The compiler analyzes imperative control flow to identify table dependencies and opportunities to process header fields in parallel before generating target configuration.It uses a two-stage process: an intermediate table-dependency graph followed by target-specific resource mapping.
- Target-specific mapping: Software switches allow direct mapping of the mTag table graph, while RAM and TCAM hardware can respectively support efficient exact matching and subset-of-tag-bit matching.The compiler uses table types to constrain widths, heights, and matching criteria, and may optimize ternary or prefix matching in software.
- Target-specific mapping: The compiler adapts P4 tables to target pipeline constraints by arranging dependent tables in parallel or series, using metadata for final writes, or composing rules into fewer physical tables.For the mTag example, local switching and the mTag table can run in parallel, actions can be represented in metadata, and two P4 tables can be combined.
6. CONCLUSION
The paper proposes programmable switches whose packet-processing functionality can be changed in the field and compiled for different hardware targets. It presents this as a first-step straw-man proposal for OpenFlow 2.0, while leaving several switch aspects undefined.
- Motivation: Today’s OpenFlow targets fixed-function switches with predetermined header fields and predefined actions, limiting what the control plane can express.The control plane cannot specify packet processing tailored to control applications.
- Contribution: The proposal lets programmers decide how the forwarding plane processes packets without exposing implementation details, enabling functionality to change in the field.This addresses the paper’s goal of more flexible switches whose functionality is specified and modified after deployment.
- Contribution: A compiler transforms an imperative program into a table dependency graph that can map to many target switches, including optimized hardware implementations.The compilation approach is intended to separate packet-processing descriptions from specific target implementations.
- Limitations and outlook: The proposal is explicitly a first-step straw-man for OpenFlow 2.0, with congestion-control primitives, queuing disciplines, and traffic monitoring left undefined.The authors argue that configuration languages and target-specific compilers can lead to more flexible future switches.