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.
This paper presents a novel high-level language for programming packet processors, aiming explicitly at shaping the future of OpenFlow. Motivation is clear: OpenFlow is the de facto standard to control the network. Originally targeting local area networks, and data centers in particular, now OpenFlow covers all scenarios. This comes at a cost: complexity. For instance, the original list of OpenFlow supported “fields” has now grown to more than 40 protocols, mostly due to packet encapsulation that must be processed by switches when looking for the label. In this context, the authors take a revolutionary process: instead of keeping extending the supported field list, they define an open, high-level, flexible interface to define mechanisms for parsing packets and matching header fields: the P4 language. P4 raises the level of abstraction for programming a network, offering an oblivious API to the actual hardware implementation of the switch. Reviewers found this paper to be intriguing, well motivated and clear. Reviewers did give a number of suggestions to improve the presentation of the paper, both to make the ideas more concise, as well as to clarify explanations. This improved the quality of the contribution, hopefully making it a milestone toward OpenFlow 2.0.