Is P4 Programming the Future of SDN?

Why Software Defined Networking needs P4

One of the key problems that Software Defined Networking (SDN) community is trying to solve is reducing the  time required to implement new protocols or extend their functionality. The logical question is – why does it take so long?

Firstly, every protocol needs to go through the IETF board, which is a long process in itself. After an official standard is defined, chip designers need to implement it in their ASICs (real world examples such as VXLAN show that this part might take up to a couple of years). Moreover, there’s no guarantee that no protocol modifications will be needed over time.

Apart from the fact that companies which operate large networks must wait for hardware to support these protocols, there’s another significant issue – network chip vendors are the only guys who oversee defining how a feature will work. Enterprise networks understand that they cannot dictate their wishes and are instead stuck with solutions pushed by vendors. The appearance of P4 language is a result of the joint effort of programmable forwarding plane community to turn this bottom-up approach into a top-down, letting enterprises define how switching silicons must forward packets.

Why your network needs P4

P4 (Programming Protocol-Independent Packet Processors) is a domain-specific language for expressing how packets are processed by the data plane of a programmable forwarding element, such as a hardware or software switch, network interface card, router, or network appliance [1]. P4 provides the developer with a basic set of instruments to implement a network stack in switching hardware. One can operate with such abstractions as header types (sets of fields and their sizes), parsers (how headers are organized together, how to distinguish between them, etc.), tables for associating user-defined keys with actions, counters, meters etc. But no more than that.  P4 language doesn’t know how Ethernet or IP headers look like. The developer is the one who tells silicon what Ethernet header is and how to parse it, match it, deparse it (construct a header for outgoing packet) and to which port(s) to forward the packet, etc.

This programmability opens entirely new possibilities for businesses: flexibility of network stack as opposed to traditional fixed-function switches; upgradability (something that hardware solutions will never have) that allows adding functions and protocols to network devices by updating P4 software running on them, instead of purchasing new switches.

Will P4 replace OpenFlow?

OpenFlow is one of the most widespread SDN protocols nowadays. It has an established infrastructure, community and controllers working on top of it. What else  can you wish for? Although it is misleading to think that everyone will ditch OpenFlow and start deploying switches with P4 support in their networks, there is still a few significant drawbacks to OpenFlow that data center people might take into consideration.

OpenFlow functions based on a set of defined protocol headers [2] (AKA TTPs – table type patterns) that a vendor might or might not support. Moreover, adding a new TTP is not a trivial task and requires a large amount of work, as well as community’s involvement. This might not be a suitable use case for academic research or dynamic environment in data centers where requirements are rapidly changing or even unknown.  P4 instead allows hardware to be programmed in a generic way and redeployed in a matter of days.

Interestingly, OpenFlow software can also be written in P4 [3], which makes OpenFlow essentially a subset of what P4 can offer the world. P4 is a protocol-independent tool that can implement a switch pipeline for any purpose, and provide an API for a controller to populate tables. The problem with Openflow is that it requires a revision of specification, while P4-based solutions (e.g. P4Runtime) are more agile and dynamic.

Another thing that’s worth paying attention to is OF-DPA (OpenFlow data plane abstraction) [4] – a hardware abstraction developed by Broadcom to map OpenFlow specification to their chip pipeline. The more OF-DPA will be adopted by networks, the more OpenFlow will be coupled with Broadcom chips. OpenFlow fails upon an original SDN promise to stay open and vendor-agnostic. Other companies have a different pipeline implementation and will struggle to follow the OF-DPA specification, seeking other options like P4 where they can still compete.

P4 use cases

P4Runtime. P4Runtime is gaining more and more popularity in a world of SDN controllers, white box solutions etc. It is a project for enabling autogenerating of application interface for populating P4 tables via control plane. It is, like P4, completely protocol independent and vendor independent.

One of ongoing projects involving P4 is ONOS [7]. The project announced about the support of P4Runtime as a protocol to control P4-defined pipeline in programmable switches and NICs. P4Runtime-enabled devices have capabilities of provisioning P4 pipelines and working with match-action tables via existing ONOS APIs. ONOS already supports Tofino-based and Spectrum-based devices on top of P4Runtime API.

Stratum [8] is an open source project by Google to develop a reference implementation of white box switches. This platform also uses P4 as a tool of their choice for defining switch pipeline along with P4Runtime for dynamic programming of tables.

Inband Network Telemetry. INT is a framework designed to allow the collection and reporting of network state by the data plane, without intervention of the control plane [5]. INT is a good candidate for P4 adoption because it can change over time and may require extensions. P4 enables a completely flexible approach, allowing to collect theoretically any kind of data in a network. Users themselves decide what data should be appended and what nodes should collect it. Using this approach, one can trace a packet’s route in a network, latency, buffer occupancy, and many other metrics.

Behavioral Model. P4 language can be used for defining a so called “gold standard” for a community telling hardware vendors how their silicon must behave. A P4 software switch allows compiling and running switch simulations written in P4 to develop new features without having any packet processing hardware [6].

SAI. P4 was shown to be used to not only in defining a pipeline from scratch, but to extend an existing one. As an example, Microsoft and Mellanox showcased an extension to open source NOS SONiC. SONiC uses SAI (Switch Abstraction Interface) as an open API that vendors must comply to. Since P4 doesn’t care what kind of API a compiler generates, it can also generate (or extend) an already existing API, like SAI. This is highly beneficial for businesses  whose network requirements are satisfied with legacy protocols, but who still require, to extend switch functions for a specifically tailored case. Like with SAI headers, a new feature can be added to an ASIC via P4, and configured via SAI extensions.

What is the future of P4?

P4 is in its early stages of adoption, but it already shows a positive dynamic of interest among the market players. Organizations with enough internal expertise to program network chips can now turn their switches into anything they want. They don’t have to wait any more for their ASIC vendor to support a new protocol or change a specific parameter, it can be done through in-house innovation. This flexibility potentially results in cost-effectiveness, allowing networking companies to buy hardware components directly from original manufactures, without resorting to a third party. Chip suppliers in their turn don’t want to miss the train and invest into support of P4 to stay in the game. Even though it is not certain if P4 will become an industry standard, initiatives from companies like Google, Microsoft and others are bringing it closer to being one.