by Nick McKeown & Jen Rexford
A few people have asked us what the difference is between P4 and OpenFlow. Is P4 just another version of OpenFlow? In this blog we'll explain why P4 addresses a much more general problem than OpenFlow. In P4, OpenFlow is one of many possible programs to describe what the forwarding plane does. P4 is NOT OpenFlow 2.0 as some have suggested. Although they are both focused on opening up the forwarding plane, P4 addresses a different need in the network, the need to program the data plane.
Back in 2007, when OpenFlow was first conceived, we wanted a common way for software control planes to remotely control lots of different switches. We noticed that - in most networks - the switches do pretty much the same things: Ethernet, IPv4, Access Control Lists (ACLs), VLANs, etc. If we could define a standard, open interface to populate the forwarding tables in these switches (i.e., the hash tables for Ethernet address lookup, the longest-prefix match tables for IPv4 and the wildcard lookups for ACLs), then we could create control planes to control switches from a variety of different vendors. The idea was very simple (although some vendors got scared that it would commoditize their switch products and threaten their comfy margins - which perhaps it did a little). The main goal was to make it easier for those who own and operate networks to write better control planes. We can see that it worked, as many big data centers today are built using homegrown control planes, that leveraged open interfaces to the data plane in part or in whole.
It's important to remember that OpenFlow assumes the switches have a fixed, well-known behavior, typically described in the datasheet of a switch ASIC. Traditional high-performance switch chips supported a fixed set of protocols because they directly implemented IEEE and IETF standard protocols in silicon. You couldn't change their behavior and add new protocols, or new ways to measure and control the datapath. (Today, it takes about four years to add a new protocol to a fixed-function ASIC!) So, the first version of OpenFlow could populate tables only for four common protocols (Ethernet, VLANs, IPv4, ACLs). As interest grew, more header-types were added to OpenFlow, such as IPv6, MPLS and VXLAN. Today, OpenFlow lets us add and delete forwarding entries for about 50 different header types. Switch vendors can tell the control plane which headers they support using the Table Type Patterns (TTP) standard from the Open Networking Foundation (ONF). OpenFlow doesn't really control the switch behavior; it gives us a way to populate a set of well-known tables.
You've probably looked at OpenFlow and wondered if it will keep supporting more and more headers. It's a problem many people worry about. It came about because OpenFlow was a compromise forced on us by a rather strange property of the switch chips. It's a property that we have taken for granted: Switch chips are not programmable. If they were programmable, we would not need a fixed protocol like OpenFlow. Instead, we would simply tell the switch how to process packets, and what tables to keep. Programmers could define whatever API made sense to populate the tables they created in the switches.
So why are switch chips fixed-function? It's a good question, and is one of those "conventional wisdoms" (or sacred cows) of networking that it's important to revisit from time to time. In the past, programmable switch chips could only process packets at about 1/10th or 1/100th the rate of fixed-function ASICs (remember NPUs?). But today, there are reconfigurable switch chips on the market that process packets just as fast as the fastest fixed-function switches. We took this one step further and showed how you could make even more programmable switch chips that run just as fast as fixed ones. We called this type of programmable chip a "PISA" chip (Protocol Independent Switch Architecture). If programmable PISA chips run just as fast as fixed-function ones, then we can open up a new era in networking in which we can define exactly how packets are processed in the switches. Moreover, if we define a language to program fast switches, we can use the same language to program slower switches too, the ones built using NPUs, FPGAs or software switches (e.g., vSwitches). We thought: If we could find a common language to program every switch in the network, then interoperability between switches follows almost immediately - we can program them all the same way. Heck, we could even use the same language to unambiguously describe fixed-function switch ASICs too, rather than having to depend on interpreting ambiguous datasheets written in English (e.g., interpreting SHOULD and MAY in standards docs).
And so in 2013, with these goals in mind, a group of us from Google, Intel, Microsoft, Stanford, Princeton, and Barefoot set out to define the P4 language.
P4 turns this "bottom-up" model of networking on its head. Rather than have the switch tell us the limited set of things it can do, P4 gives us a way to tell the switch what it should do, and how it should process packets. P4 lets us define what headers a switch will recognize (or "parse"), how to match on each header, and what actions we would like the switch to perform on each header. For example, we might tell the switch to process IPv4 headers by performing a longest-prefix match on the 32-bit destination address, send it to the next hop, decrement and check the TTL, update the checksum, and encapsulate in a new Ethernet header. The protocol is just a program expressed in P4. P4 unambiguously specifies the precise way in which headers are matched, and the actions to be performed on them. In fact, you can compile a P4 program to directly generate an executable switch - open-source compilers already exist and allow new switch features to be tested. A number of companies have joined P4.org to help move the ecosystem along; some have demonstrated P4 solutions and started offering toolsets to their customers.
P4 therefore let's us control switches "top-down" by first specifying their forwarding behavior, then populating the tables we've defined. In addition, P4 compilers typically auto-generate the API needed to populate the tables, too. This makes it also possible to do away with the fixed, closed APIs that switch chips have today. Instead of the switch chip vendor defining our API for us, and locking us into using their next chip as well, P4 let's us define the API we need to populate the switch. We say that P4 is "top-down" because it puts the network architect, programmer, and developer in charge, rather than the chip vendor.
OpenFlow is definitely still useful for networks built from a mixture of programmable switches and older fixed-function switches supporting the OpenFlow protocol. In fact, there already exists a P4 program called openflow.p4 that programs a PISA chip to support OpenFlow. In other words, in the P4 language, OpenFlow is a program. In this way OpenFlow and P4 can work together for networks. While OpenFlow is designed for SDN networks in which we separate the control plane from the forwarding plane, P4 is designed to program the behavior of any switch or router, whether it's controlled locally from a switch operating system, or remotely by an SDN controller.
There is no particular reason to think that P4 will make OpenFlow obsolete any time soon. There are plenty of fixed-function switch ASICs on the market, and quite a few of them can be controlled using OpenFlow. In fact, as more TTPs are written for fixed-function switch chips, there is good reason to think OpenFlow will be around for a while. P4 gives a seamless way to build networks using a mix of programmable and fixed-function switches, and lets us introduce new features and protocols into the network in software, rather than waiting for new hardware. And P4 coders can keep those differentiating features to themselves, rather than sharing everything with chip and box vendors and, through their vendors, with their competitors.
To learn more about P4, check out P4.org and take a look at the open-source P4 programs, compilers and tools. You can also attend one of the P4 Workshops and Tutorials we hold at Stanford (links and proceedings from previous workshops here: June 2015 and November 2015). The next tutorial, P4 Developer Day 2016, is on Monday May 23rd, 2016, to register click here. The next P4 Workshop is on Tuesday May 24, 2016, to register click here.
