On the day in early August when the ONF announced the formation of the Forwarding Abstractions Working Group (FAWG), and my role as chair, several people asked me what, exactly, FAWG will be doing. My responses at the time rivaled a Higgs boson detector output in clarity and brevity. Now, after a bit of practice and FAWG progress, I aspire to cram fit a meaningful answer comfortably into a blog post. Soon, I’ll be able to tweet my response! By, er, linking to this post. As it happens, that simple idea is relevant here.
Flexibility meets Diversity
FAWG is mainly focused on encouraging adoption of newer versions of OpenFlow® on existing hardware platforms based on ASICs or merchant silicon. Starting with version 1.1, OpenFlow® has been based on a flexible new multi-table switch “pipeline” to express the packet processing functionality required by the controller and application. Soft platforms (based on servers or NPUs) can mimic that new pipeline, but today’s diverse hardware platforms aren’t so lucky. Their software must map the requested behavior from a multi-table model to the underlying chips. A straightforward chore with a single table turns out to be much trickier with multiple tables. I’ll go through that a little more after a bit of FAWG history.
Origins of FAWG
For me, the roots of FAWG go back to the first ONF workday in June of 2011, just a few weeks after the release of the OpenFlow® 1.1 spec and the launch of ONF itself. At that meeting, OpenFlow® newcomers rubbed elbows with old-timers active in the spec development since well before the formation of the ONF. Many voices competed for air time that day, but I recall some Google folks talking about some challenges related to the new OF1.1 multi-table switch model, and hinted that they had new proposals. (At that time, Google was quietly in the midst of their internal OpenFlow® project, described in this PDF and this video.) Soon others, myself included, joined in discussing the issues and learning about the proposals. The Google team’s ideas were beyond the scope of only active working group (Extensibility), so in October the ONF’s Technical Advisory Group (TAG) asked the Google folks to share their proposals. Soon the ONF created a “discussion group,” called OpenFlow® Future, where folks could gather and discuss where OpenFlow® might go. By November, about thirty interested individuals were active, and by early 2012 we had consensus on a new approach called “Forwarding Plane Models,” or FPMODS, for boldly addressing two broad issue categories that we had identified, 1) challenges of mapping multi-table OpenFlow® on available ASIC-based platforms (which we see as impeding near term adoption), and 2) expressing new features that don’t align to the multi-table pipeline (which we see as increasingly important over time). In April, we moved to formalize our effort by sending a draft FPMODS working group charter to the TAG for consideration.
OpenFlow® adoption
ONF leadership was also looking into OpenFlow® adoption, which it has identified as core to its mission. ONF’s Testing and Interoperability WG had coordinated an OpenFlow® plugfest in March with a dozen products, many at a beta stage, but testing was focused on OpenFlow® 1.0 even though the 1.1 spec had been out for a year and OpenFlow® 1.3 was nearing release. ONF leaders looked at ways to encourage adoption of the newer specs. They concluded that a stable release would potentially do more to encourage adoption than a drumbeat of releases with new features. Since the upcoming OpenFlow® 1.3 spec had added key features like IPv6 and meters, the board opted to pause further development on the wire protocol for a while and encourage adoption of that version. This was the context as the TAG began reviewing the FPMODS charter.
The original FPMODS draft charter mixed the “implementation challenges” and “new features” issues together. Nudges from the TAG prompted us to recognize the possibility of a phased approach. We revised our charter. Phase 1 is formalizing pre-defined table-based switch behaviors (called TTPs for “table typing patterns”) to simplify implementation on ASIC and merchant silicon platforms. New feature flexibility will be deferred until Phase 2, which will require a new charter and board approval. We wanted an umbrella term to cover both TTPs and FPMODs, and with virtually no debate, we chose “Forwarding Abstractions.”
As I was saying…
I took us on that mini tour of recent ONF history to highlight a few points. First, the FAWG Phase 1 activity is part of a larger whole, with a gradualist approach. Early on, the OpenFlow® Future discussion group realized that OpenFlow® 1.1 was both “too flexible” and “not flexible enough” since some important switch functions (e.g. MAC learning) just don’t fit. Both complaints are valid depending on the assumptions we begin with. Tweaking clearly wouldn’t resolve this. We needed a new approach with new assumptions. One implicit assumption has been that switches get no advance knowledge about what the controller will ask. Instead, we expect the OpenFlow® messages (often called “flowmods”) to convey two kinds of information, 1) specific flow details, such as IP addresses, to be matched in the packet, and 2) partial hints about the required overall switch behavior (in contrast to the single-table situation where flowmods hold the full switch behavior for the flow in question). When multiple tables are involved, the switch may not have enough information to handle Messages #1 to #10 until Message #11 (or even Message #1011) arrives. And mileage may vary widely depending on many factors, so a tested system may work one day and fail the next, or work in one environment but fail in another because the mapping algorithm in the switch doesn’t have quite enough information to do its job.
Change the assumptions
The group realized that we could keep flowmod messages for passing flow details. We just needed a separate and earlier way of passing the big picture of packet handling, what I’ll call a “pre-defined switch profile” or PDSP, before the flowmods arrive. (“Pre-defined switch profile” is my new-and-improved umbrella term for TTPs and FPMODs.) Sharing the big picture early will dramatically lighten the burden on switch run-time software, making code development less risky and thus easier to embark on. To pass the earlier switch behavior info, the FAWG and ConfigWG will jointly add a new protocol (in OFConfig1.2) for negotiating an agreed switch behavior model between the controller and switches soon after they connect. After that, the flowmod messages can be sent just as before. After the PDSP negotiation, the whole operational run-time interaction between controller and switch is unchanged.
Like tweeting a link to a blog post, the above negotiation uses PDSP identifiers as shorthand for a larger thing, in this case a detailed description of the switch behavior. That PDSP will be shared with the switch providers at implementation time, which puts switch providers on the same footing as the controller or application providers. Sharing in advance allows the coders to deliver hardware-based support for those interesting PDSPs that require the expressiveness of our newer multi-table OpenFlow® pipeline. On the other hand, on-the-fly changes to the overall switch behavior are not available with PDSPs. But recognizing the diversity of equipment and OpenFlow® feature support, platform support for on-the-fly changes to overall switch behavior won’t be deterministic. That is a problematic notion for production network operators, who require predictably robust interoperability. Considered in that light, on-the-fly changes to overall switch behavior may be regarded as a niche requirement. But if you need that, fear not. Soft platforms and simple single-table switch behaviors will continue to be available to support the on-the-fly approach of “traditional” OpenFlow.
Where do these PDSPs come from?
The FAWG is already developing the first few PDSPs, and we expect these to be widely used. But we also intend for the behaviors to serve as enabling examples for others, because our framework is architected so that any interested market participant can define new PDSPs. We especially do not want the ONF or FAWG to be a bottleneck. Our deliverables will include instructions for defining the PDSPs, and we expect both application providers and equipment providers to propose new and interesting PDSPs. Market forces will encourage the providers to use the most popular PDSPs, so we would expect a small number to cover the mainstream applications, with a few more developed for niches. We expect the market to move faster and on more fronts than the FAWG could, but FAWG will also be responsive to member requests if market dynamics get stuck.
Bonus: Clear interoperability
The initial motivations for FAWG were adoption and features, but the resulting framework brings other benefits, too. PDSPs offer a clear indication of interoperability between controller and switch. Buyers can see what works with what, and vendors can see what they need to do to support another vendor. We will encourage testing and certification based on PDSPs so that interoperability is even more robust. The interesting upshot will eventually be that, even though PDSPs were initially pursued to allow support of complex behaviors on ASIC-based platforms, I have heard several unexpected comments suggesting that the interoperability benefit will make PDSPs attractive even for single-table switch behaviors, and for soft platforms. Cool!
Navigating OpenFlow® toward broader adoption while providing a unifying framework? That’s win-win-win as far as I’m concerned.
I hope this longish post brought some clarity to the FAWG picture. We will use our sessions at the ONF member workday to dig into these topics in more detail. I look forward to seeing you there! If you have comments or questions before then, drop me a note at beckmann@Brocade.com.
-Curt Beckmann, Principal Architect at Brocade
Curt Beckmann is a Principal Architect and Brocade's lead representative at the ONF. He entered networking as an ASIC architect at Bay Networks (later Nortel Networks) in 1995, where he worked on 10/100 Ethernet switching and early Layer 3 gigabit switches. He moved on to manage and architect Fibre Channel storage virtualization and iSCSI/FCIP protocol-conversion system-on-a-chip ASIC designs at Rhapsody Networks, which was acquired by Brocade in 2003. He spent some years in product management before returning to engineering, where he now focuses on enhancing OpenFlow® to accelerate hardware adoption of new features.
