Most network users have an uneasy relationship with their equipment vendors. No matter how happy they are, or how long they took making a vendor selection, most harbor doubts about whether they're getting their gear at a fair price, and nearly all think their vendors are trying to lock them in. Things like software-defined networking (SDN) or hosted router software, once hoped-for insurance, don't seem to have helped. Well, now there's a new hope, with the cryptic name "P4," and it can handle the past, present, and even future of networking.
P4, from the P4 Language Consortium, is a kind of programming language that lets you run forwarding instructions written on a P4-equipped server or appliance -- a "white box." Think of it as "forwarding-Java."
Unlike Java and other ordinary programming languages that let you build software that does pretty much anything, P4 lets you define forwarding behavior. A P4 instruction might say something like, "If the IP header of a packet looks like THIS, then forward it to THAT port." Like Java, which needs software to interpret it for different hardware, P4 needs a complier/interpreter for each special device configuration. "Special" means not only each different CPU chip, but also any special chips in use. This includes things like application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs) sold by generic chip vendors -- "merchant silicon," as it's called.
Special Sauce
One of the things that makes P4 special is its ability to support merchant silicon that's optimized for routine forwarding tasks. It's that special sauce that makes routers faster than routing software running on servers, so if P4 can exploit whatever specialized merchant silicon is built into white boxes, it can make open devices nearly equivalent to proprietary switches and routers. The vendors themselves can supply "plugins" for P4 to link with their custom chips, making it easy to add in new chips when they're developed. This is how P4 helps us deal with legacy network applications.
The industry is now grappling with the question of how to create an open ecosystem for P4 without creating so many incompatible strategies that nothing ever interworks. P4 itself defines standard plugin processes for extension, and in addition the Open Networking Foundation and the Linux Foundation both have open-device operating system projects (Stratum and DANOS, respectively) that aim to standardize P4 hosting much as Linux has standardized server operating systems.
Another benefit of P4 is that while it can define forwarding based on SDN and OpenFlow rules, it can also be used to build nothing more than a hardware-optimized legacy Ethernet switch or router. That might turn out to be the most revolutionary thing about P4, even though it sounds dull compared with the potential to support new forwarding technologies like SDN. An open P4 router implementation could run on servers and open switches (Dell has already offered some such products), and P4 software written according to the rules should be portable across products with minimal changes.
The support for legacy router/switch implementations will surely dominate early P4 adoption, but P4 is also a powerful way of creating new devices with totally different forwarding rules. If software-defined WAN (SD-WAN) products were to be structured as P4 applications, they could be portable across multiple devices beyond basic servers, making them much more useful. In addition, P4 SD-WAN might take advantage of hardware acceleration provided by merchant networking silicon, enhancing both the features and performance of SD-WAN.
And There's More!
SDN and SD-WAN illustrate the fact that P4 can also support the current thrust of network transformation, but what about the future? Are there things that we really need, that P4 could provide, and that perhaps we've not thought about? There sure are.
Let's take an example from UC/UCC. Think about a VoIP call center, something that has to route hundreds or thousands of calls per minute. In the old days, this might have been done with a PBX or even a small central office switch. In the future, a P4 box could provide exactly what's needed. P4 could also be used in cloud load-balancing, a major challenge as we try to match up mobile workforces with virtualized, scalable, distributable resources.
What hurdles will P4 need to jump, beyond the usual ones of getting early traction and delivering on the promises? The biggest technical issue isn't P4 itself, but what P4 runs in. You need a kind of operating system and compiler, as I've already said, and there are initiatives to provide them, but should we think of "forwarding" as a task for a dedicated box or software element? Why couldn't P4 route packets to other processes, even complex processes, within the box? The organizations promoting P4 open-box operating systems should think about this broader mission.
Did SDN meet your expectations? Probably not, but P4 could be a game-changer because it doesn't demand massive forklift network upgrades to validate open infrastructure strategies. You can be as conventional, or unconventional, as you like. Best of all, you can expect to see P4 boxes on the market this year. Vendors will probably sell P4 programs, and there will surely be open-source P4 programs as well. Watch this space for the next network revolution!
Follow Tom Nolle on Google+!
Tom Nolle on Google+
