byCurt.Beckmann11-08-201306:34 PM - edited 11-11-201309:53 AM
These are exciting days in my Forwarding Abstractions Working Group (FAWG); the past 15 months of work is just now producing results that will be instrumental in enabling our SDN future. Past is meeting future in my extended present, and each week brings us closer to fruition.
Some weeks ago, FAWG produced a “preliminary final” document about our framework enhancements for the OpenFlow ecosystem. This past Thursday I met the crowd of participants at our latest OpenFlow plugfest, which was focused on the 1.3 version of the OpenFlow Switch protocol (OFS1.3). This coming Thursday, I’ll speak at “Gogonet Live! 4” about how SDN (in the form of OpenFlow) is becoming IPv6-ready. On the following Thursday, I’m participating in an NFV / SDN panel at the Software Telco Congress.
What’s the thread (or perhaps ribbon) that ties all this together? The future. Allow me to explain. Starting back in 2011, the ONF community pushed out a good number of products with support for the 1.0 version of the OpenFlow Switch protocol (OFS1.0). Indeed, the ONF just announced the first product to achieve certification with OFS1.0. That version has been of tremendous value as both as a proof of concept, and as a practical, if limited, protocol. (You can build real world OFS1.0-based solutions, such as Internet2’s 100G OpenFlow-enabled network, as long as you can live with a simple switch datapath and no MPLS or IPv6.) More features and a richer datapath have been introduced since OFS1.0, and OFS1.3 is the first such version that the ONF has pushed for broad adoption. As such, OFS1.3 is the first OpenFlow protocol version that is truly future-ready, given that we know NFV and IPv6 will be central to the future of networking.
How does FAWG get wrapped into this whole “future of networking” bundle? Glad you asked! (You were asking, weren’t you?) Here goes: OFS1.3 (like OFS1.1 and OFS1.3 before it) supports a multiple flow table datapath (or “pipeline”). This powerful new OpenFlow datapath is all goodness on soft networking devices (based on servers or networking processing units), because those soft devices can effectively implement the OpenFlow datapath “natively”, meaning that such devices can happily gobble up multi-table OFS1.3 without any translation. But ASIC or FPGA-based switches (typically much cheaper and faster) can only offer deterministic support for basic datapath solutions, unless some datapath translation mechanism is available. That mechanism was not part of traditional OpenFlow, but FAWG has defined one, and its members are engaged in writing “working code” to prove out the details, as well as doing various other activities to “put a bow on” adding the translation mechanism to the OpenFlow framework. Part of that is getting the word out to set the context for what will be coming early next year. Hence my burst of chattiness at upcoming venues, including those mentioned earlier in this post.
I hope to see you at, gogoNET Live! 4 and Software Telco Congress. If you can make it, you won’t be surprised if all I want to talk about is how my extended present is enabling the Future of Networking.