Two pioneers of SDN — Jennifer Rexford and Nick McKeown — have officially launched a consortium around P4, a language that allows for programming the data plane. If successful, P4 could widen the scope of the movement that started with OpenFlow.
The P4 language has been discussed for more than a year, but it become more “real” on Friday, when the P4 Consortium’s plain web site was replaced with a spruced-up version expounding on P4’s goals and openness. It also featured a new P4 logo and the obligatory cute mascot — a polar bear.
Rexford slipped a mention of P4 into her Twitter stream on Friday afternoon. Maybe it’s coincidence, but by Friday evening, Pacific time, P4.org was temporarily unreachable, as if it had been overwhelmed by traffic.
P4 — the name comes from the title of a paper: “Programming Protocol-Independent Packet Processors” — is noteworthy because of its backers. Rexford is a Princeton University professor who’s been involved with the Open Networking Foundation since its early days; she joined the board in October. McKeown, a professor at Stanford University, helped guide the OpenFlow protocol into being, kicking off the current wave of SDN mania.
They’ve got equally high aspirations for P4. “We think it’s going to change how networking devices are designed forever,” they write in P4’s introductory blog entry.
An SDN Language
P4 isn’t a protocol. It’s a language for programming the network’s data plane, and it’s used for telling equipment what to do with packets. We described it in March 2014 as a harbinger of what “OpenFlow 2.0” might look like.
That was during the Open Networking Summit, where Rexford gave a talk introducing P4. (Her presentation is posted on SlideShare.) Having witnessed the trajectory of OpenFlow, researchers wanted to intercept some trends that seemed to be approaching the danger zone, such as the rising number of header fields OpenFlow was checking.
You could consider P4 the next evolution of OpenFlow. It’s certainly got the same goal: freeing network design from the bonds of the chip.
Before SDN and OpenFlow, semiconductor design dictated much of what a switch or router could do. It wasn’t necessarily easy, or even possible, to try out a new packet format or a radical packet-processing method.
That left networking at the mercy of the years-long cycle of chip design. These chips aren’t easy, especially at the high end, which is why Cisco, Juniper, and Alcatel-Lucent continue to design ASICs, and why it’s been so long since Broadcom has had a strong competitor in Ethernet switching chips.
OpenFlow began to change that by allowing for arbitrary types of packet processing. These new rules would be fitted into match-action tables: “If the packet matches condition X, then do Y.”
P4 broadens that idea by providing an entire language for telling the switch or router what to do. Rather than fill out tables, you would write a P4 program to control the equipment. The program could include add-ons such as analytics.
And while it might sound ambitious to claim that P4 could start a revolution, Rexford and McKeown point out that chips are already heading in this direction. They’ve become protocol-independent, as far as the hardware goes. And support for OpenFlow has become ubiquitous, meaning the chips are prepared to follow unconventional switching rules.
What About Intent
Intent — the idea of policy-driven networking — is getting a lot more of the spotlight than OpenFlow these days, but it looks like P4 can fit into that world.
The idea behind intent-driven networks is that an application would state its requirements (“connect Point A to Point Z and add a firewall”), leaving it up to the network equipment to decide how this will get accomplished.
You’ll notice a gap there. Somehow, the equipment has to translate this intention into, say, entries in a switching table. P4 could be a language for communicating those changes. The details are still a matter of research, Rexford and McKeown note in their blog entry.
P4 also could be considered the conduit for giving a switch its personality — telling it to run OpenFlow 1.4 or throttle back to OpenFlow 1.0, for instance.
Keeping P4 Open
P4 is just getting off the ground, so the web site is calling for community help to cultivate the new language and investigate its implications. The P4 code is openly available, and the work that goes into developing it will be open as well — all available under an Apache license. P4 Consortium membership is free as well.
The P4 programs that users write will not be open, however — so it will still be possible for vendors or users to amass some intellectual property that doesn’t have to be shared.