Programming networks with P4

Posted by Mihai Budiu mbudiu@vmware.com – VMware Research

P4 is a domain-specific programming language designed for expressing how packets are processed by the data plane of a programmable network element such as hardware or software switches, network interface cards, routers or network function appliances. This is the first blog post in a series that will provide an introduction to the P4 programming language, using the P416 version of the language, which is currently a draft specification.

One of the most active areas of computer networking today is Software Defined Networking (SDN). SDN has separated the two core functions of a network-processing element (router): the control plane and the data plane. Traditionally both these functions were implemented on the same device; SDN decoupled them and allowed a variety of control plane implementations for each data plane. The poster child for SDN is the Open Flow protocol, which specifies the API between the control plane and the data plane. Despite the additional flexibility brought by separating these functions, SDN still assumes that the behavior of the network data plane is fixed. This is a significant impediment to innovation; for example, deploying a new network protocol (such as VXLAN) can take up to 4 years between the initial proposal and its commercial availability in high-speed devices.

What’s in it for me?

As a reaction to this state of affairs, there is a new impetus to make computer networks even more programmable by making the behavior of the data plane expressible in software. Industry and academia are converging on a new domain-specific programming language called P4 (Programming Protocol-Independent Packet Processors). The P4 specification is open and public. The P4 language is developed by the p4.org consortium, which includes more than 60 companies in the area of networking, cloud systems, and network chip design and academic institutions.) While initially P4 was designed for programming network switches, its scope has been broadened to cover a large variety of packet processing systems.

Compared to the state-of-the-art method of programming network processing systems (e.g., writing microcode on top of custom hardware ASICS), P4 provides significant advantages:

• Flexibility: P4 makes many packet-forwarding policies expressible as programs; contrast this to traditional switches, which expose fixed-function forwarding engines to their users.
• Expressiveness: P4 programs may express sophisticated hardware-independent packet processing algorithms using solely general-purpose operations and table lookups.
• Resource mapping and management: P4 programs express resource usage in symbolic terms (e.g., IPv4 source address); compilers map such user-defined fields to available hardware resources and manage resource allocation and scheduling.
• Software engineering: P4 programs provide important benefits such as type checking, information hiding, and software reuse.
• Component libraries: P4 supports the creation of libraries that wrap hardware-specific functions or standard protocol implementations into portable high-level P4 constructs.
• Decoupling hardware and software evolution: P4 is to a large degree architecture independent, allowing separate hardware and software upgrade cycles.
• Debugging: Manufacturers can provide their customers’ software models of target architectures to aid in the development and debugging of P4 programs.

P4 brings programmability to the network data plane, similar to the way the CUDA language brought programmability to the graphics cards. We expect that this additional flexibility will unleash a wave of new and unforeseen applications. Here are some of the emerging ones:

• Specification of network protocols: P4 is a formal programming language, which has a precise semantics. P4 can be used to specify some network protocols more precisely than using English prose.
• Implementation of new network protocols: P4 makes the deployment of new protocols much simpler – just the matter of a software upgrade. For example, a VXLAN implementation in P4 requires 175 lines of code.
• Network monitoring: The killer application for P4 is the ability to write software programs that extract dynamically information from network devices. For example, the INT proposal (In-Band Network telemetry) allows for network switches and endpoints to insert additional custom headers into the packets that cross the network; these additional headers carry network measurement information (timestamps, queue occupancy, congestion, etc.)
• Simpler network devices: when using a P4-programmable device, users can not only implement new protocols, they can also remove unused protocols, using the available hardware resources for other purposes.
• Intellectual property protection: with P4 network protocols can be written and deployed by network operators, and not by network device manufacturers.

P4’s pedigree

The original paper that proposed the P4 programming language was written in July 2014. The first version of the language, including a specification, a reference implementation of a compiler, and various tools, including a simulator, were released in the fall of 2015. The currently accepted version of the language is 1.0.3, also named P4₁₄. Most of the initial release was spearheaded by Barefoot Networks, a start-up that is working on building a high-speed programmable network ASIC.

Following the initial release, the p4.org consortium grew rapidly. The p4.org consortium organized a series of P4 workshops at Stanford and several P4 developer days; hundreds of participants from industry and academia have attended these events. The next workshop is scheduled for May 17, 2017.

Meanwhile, a formal design committee was assembled that worked towards designing the next version of the language, based on initial feedback from users. The committee has released a draft specification for the next version of the language, dubbed P4₁₆, in December 2016. This new specification is accompanied by a reference implementation for a new reference compiler. While P4₁₆ is syntactically incompatible with P4_14, the new language should be a superset of the old one in expressivity, and the reference compiler can convert P4₁₄ programs into P4₁₆ programs. The design committee will attempt to keep future versions of the language backwards-compatible.

P4₁₆: the newest family member

P4₁₆ is a relatively simple programming language. It is a statically-typed, strongly-typed and memory safe programming language. A one-line description of P4 could be: “it is similar to a simplified C or Java, without support for: pointers, dynamic memory allocation, floating-point numbers, and recursive functions, and with very limited support for looping constructs; in addition, it offers built-in hash-tables, which are written by the control plane and read by the data plane.”

Figure 1: Workflow for programming a network device using P4.

P4₁₆ is designed to be implementable on a large variety of target platforms such as programmable network cards, FPGA switches, software switches and programmable ASICs. The language is restricted to constructs that are efficiently implementable on all these platforms. P4 also accommodates hybrid packet processing devices, where some functions are programmable, while other functions are hardwired (e.g., using special hardware acceleration units). Figure 1 shows the workflow for programming a network device using P4; a P4 compiler synthesizes not only the data plane functionality, but also the API between the control plane and the data plane.

The core abstractions provided by the P4 language are:

• Header definitions describe the format (the set of fields and their sizes) of each header within a packet.
• Parsers describe the permitted header sequences within received packets, how to identify those header sequences and the headers to extract from packets.
• Tables associate user-defined keys with actions. P4 tables generalize traditional switch tables; they can be used to implement routing tables, flow lookup tables, access-control lists, and other user-defined table types, including complex multivariable decisions.
• Actions are code fragments that describe how packet header fields and metadata are manipulated. Actions can also include data, which can be supplied by the control plane at run time.
• Match-action units perform the following sequence of operations:
  • Construct lookup keys from packet fields or computed metadata,
  • Perform table lookup using the constructed key, and selecting an action (including the associated data)
  • Finally, execute the selected action
• Control flow expresses an imperative program describing the data-dependent packet processing within a target pipeline, including the data-dependent sequence of match-action unit invocations. Deparsing (packet reassembly) can be performed using a control flow.
• Extern objects are library constructs that can be manipulated by a P4 program through well-defined APIs, but whose internal behavior is hardwired (e.g., checksum units) and hence not programmable using P4.
• User-defined metadata: user-defined data structures associated with each packet.
• Intrinsic metadata: metadata provided or consumed by the architecture associated with each packet (e.g., the input port where a packet has been received).
• Architecture definition: a set of declarations that describes the programmable parts of a network processing device.

Will it solve world hunger?

Unfortunately, the answer to this question is “no”. In addition to P4’s inability to solve all of the worlds’ problems, as a general-purpose programming language, it is very limited. P4 is not a Turing-complete language; it is narrowly defined for performing data-path packet processing. Surprisingly, there are even many packet-processing tasks that cannot be expressed in P4.

• P4₁₆ supports extern functions or methods; these are computational functions that are implemented outside of P4 and can be invoked from P4 programs. There is currently an effort to standardize a set of such methods; however, each P4 target platform can provide additional extern methods, e.g., to model hardware accelerators. Invoking extern methods is one way that P4 programs can perform otherwise impossible tasks.
• There is no iteration construct in P4. Loops can only be created by the parser state machine. There is no support for recursive functions. In consequence, the work performed by a P4 program depends linearly only on the header sizes.
• There is no dynamic memory allocation in P4. Resource consumption can be statically estimated (at compile-time).
• There are no pointers or references.
• There is no support for multicast or broadcast. These must be achieved by means external to P4. The typical way a P4 program performs multicast is by setting a special intrinsic metadata field to a “broadcast group”. This triggers a mechanism that is outside of P4, which performs the required packet replication.
• P4 has no built-in support for queueing, scheduling or multiplexing.
• P4 is unsuitable for deep-packet inspection. In general, due to the absence of loops, P4 programs cannot do any interesting processing of the packet payload.
• P4 offers no support for processing packet trailers.
• All the state in a P4 program is created when a packet is received and destroyed when the processing is complete. To maintain state across different packets (e.g., per-flow counters) P4 programs must use extern methods. We expect the standard library to contain support for such persistent arrays (counters, registers, meters). Even given support for registers, one cannot iterate over all counters to compute statistics.
• There is no standard way to communicate between the data plane and the control plane; this is usually offered using extern methods (e.g., to implement “learning”).
• There is no support for performing packet fragmentation or reassembly; thus protocols such as TCP cannot be described in P4.
• There is no support for generating new packets (e.g., an ICMP reply), only for processing existing ones.

Despite these limitations, P4 is a remarkably useful language. We also expect that future evolution will expand its capabilities.  To get started go here to download P4.  To learn more about other research efforts at VMware look here.

Coming next,  Show me the code please!