The report of my death was greatly exaggerated. If OpenFlow were as melodramatic as Mark Twain, it may well have uttered those words back in mid-2012 when Network Computing predicted its ultimate demise by the year 2014. This was both a bold statement and prescient, for it was only a year later that OpenFlow’s founding fathers starting doubting the future of their creation. This was summed up best by Scott Shenker in statements made at various events over the next 18 months: "This one is unforgivable. We just ignored current systems We should have... recognize(d) that MPLS was right. We should have incorporated it in SDN." This was a clear acknowledgement that while the admirable goal of OpenFlow was a fresh start, in reality we can’t just flick a switch to eradicate the past. It was an admission that we, as an industry, needed to look toward SDN2.

OpenFlow was designed with simplicity in mind, abstracting a single table of rules that could match packets on 12 header fields -- things like MAC address, IP Address, Protocol, TCP/UDP port number, and so on. It was quickly apparent, however, that the switches wanted to expose more of their functionality to the controller, representing the complex functions they were performing in multiprotocol networks. With these pressures at play, the number of header fields supported was aggressively extended over a four-year period from those original 12 in OF 1.0 to 41 in OF 1.4, dramatically increasing the complexity of the OpenFlow specification. So much so that an embargo, of sorts, was placed on the introduction of new headers between 1.3 and 1.4 -- the only worthy addition during that timeframe being IPv6 Header Extensions.

The rise of OpenFlow (OF) header fields

While the addition of new headers ground to a halt, the desire to add new protocols and encapsulation techniques, supporting growth areas and prime SDN markets like data centers, continued unabated. Being easier to extend, pure software switches were deployed as stop-gaps to support tunneling and overlay techniques such as NVGRE, VXLAN, STT, OTV, etc. With native OpenFlow constructs lacking any ability to flexibly add new headers, it remains a significant bottleneck. The current predicament of OpenFlow and these workarounds has served to highlight the continuing problem with network switch design, however, in that they are still fundamentally custom-silicon-centric.

Hence our interest in this topic here at Metaswitch, in case you were wondering why you are now 400 words into this article on our site. Network functions virtualization (NFV) infrastructure will undoubtedly demand the continued evolution of such overlays in the data center.* Furthermore, we have the whole issue of service function chaining (SFC). What if we need to implement and then evolve an SFC overlay as described in previous posts? Are today’s switches up to the task?

While a good hardware design will provide some flexibility, the core functionality of a networking device, comprising thousands of IETF RFCs and the like, is almost exclusively implemented in the switching chip itself. In the fast-paced networking world, this can result in significant lapses between standardization and commercial availability. Moreover, as the industry moves from a model of broad standardization to a philosophy favoring rough consensus and running code, hardware implementations will increasingly stifle innovation. While SDN promised to empower network operators, switch vendors are still effectively calling the shots.

Silicon vendors have not been just sitting around, however, with the likes of Intel and Cavium** (through their 2014 acquisition of Xpliant) delivering programmable switch architectures such as the Reconfigurable Match-Action Table (RMT).*** RMT provides the foundation for genuine software defined switching platforms. First, the fixed protocol parsers are replaced by programmable ones. Secondly, serial pipelines, which are typically "burned-in-silicon" are eliminated and, instead, a dynamic pipeline, capable of handling packets in parallel, is implemented. This also has the obvious benefit of improving overall performance. So now the entire switch forwarding plane can be changed, ad-hoc and on-demand, without any modifications to the hardware itself.

Classic hardware switch architecture

In order to support this new programmable switch architecture, we must extend the current control plane, which is where P4 comes in. In yet another admission that OpenFlow was breaking or broken, P4, a high-level language for programming protocol-independent packet processors, was developed by some of the same people who originally created OpenFlow. It essentially provides an abstraction layer that simplifies the programming of these new chips. In the P4 proposal, the forwarding model is broken down into two distinct types of operations: configure and populate.

The domain of P4, "configure" operations determine which protocols are supported and how the switch processes the packets. This is, of course, in stark contrast to the classic hardware-centric switch operation, where such functionality is hard-wired, as described previously. P4 is used to program the parser with a dynamic (versus static hardware) parse graph whose state can be stored in either ternary content-addressable memory (TCAM) or standard SRAM.

P4 is also employed to configure the order of the match/action stages, specifying the header fields to be processed at each stage. The populate operation adds and removes entries in the match/action tables specified during configuration, which essentially determines the policies that should be applied to a packet at any given time. Installing and querying these rules can be accomplished using classic OpenFlow. Decoupling configuration and population operations in this model enables reconfiguration of the switch without disrupting the forwarding plane.

New programmable switch architecture

P4, itself, is a new programming language that can express how a switch is to be configured and how packets are to be processed. The authors note in their introductory white paper (P4: Programming Protocol-Independent Packet Processors) that after considering options such as Click (circa 2001) they, not surprisingly given its age, found it lacking specificity in key areas. They summarize P4 as being in the sweet spot between the generality of Click and the inflexibility of OpenFlow to reconfigure protocol processing.

The ONF has taken up this effort under the title OF-PI: A Protocol Independent Layer, with a view to combining previous work in the area of Protocol Oblivious Forwarding (POF) to create a protocol-neutral flow/forwarding instruction set, which (I was excited to learn) they call POF-FIS, and P4, which covers all the forwarding plane packet processing attributes. Whether the outcome is ultimately OpenFlow 2.0 remains to be seen, but either way, it is clear that P4 may just be the thing that saves OpenFlow.

You can learn all about P4 by visiting their website at http://p4.org/.

_{*This relationship was highlighted in a feature proposal for NFV Switch Control, presented by Huawei, 6WIND, Orange and China Telecom at NFV#12 in New Jersey (Oct 2015).
** Our friends at Pica8 recently announced the introduction of a Cavium Xpliant-based White Box switch. Their VP Marketing, Steve Garrison was quoted as saying: “Cavium brings a lot of new knobs that you can turn in the ASIC that give people more choice. We think the mass market’s going to move in this direction in general.” Which is a brilliant line and one that would have probably saved me writing - - and you reading - - 1,000 words.
*** We can also safely assume that the stealth-mode (as of this post) startup Barefoot Networks - - one of the originators of P4 - - are also architecting such silicon.}