ONF Grabs a CAB for Next Leg of SDN Journey

by Curt.Beckmann on ‎07-29-2013 03:10 PM - last edited on ‎10-28-2013 09:22 PM by bcm1 (2,376 Views)

The ONF recently announced the formation of a Chipmakers Advisory Board (CAB) to help ONF leadership “grok” the chipmakers’ world view such that the ONF can more effectively encourage OpenFlow support in new networking silicon.  After a call for applications, the ONF selected thirteen individual from thirteen member firms that design their own chips. The firms include merchant silicon vendors, network processor vendors and system vendors that use internal ASICs for their systems. As an ASIC designer, I am both honored and excited to be able to represent Brocade on the CAB.  The honor seems self-evident; the CAB is a remarkable group of people gathered to positively influence the organization at the core of biggest disruption in networking since the Internet.  The excitement comes because the formation of the CAB highlights the ONF’s readiness to aggressively pursue broad adoption of OpenFlow.




Here are some of the leading challenges that I see the ONF and the CAB working to address in the coming weeks.


Aligning the Hardware / Software Camps


I’ve written before about the tension between the software-centric and hardware-centric camps in the OpenFlow community.  Not surprisingly, the dominant organization in the Software Defined Networking advocacy group (the ONF) has a heavy presence of software folks.  The CAB, on the other hand, is definitely hardware dominant.  The ONF, by creating the CAB, is aggressively seeking to bridge the hardware / software understanding gap, which is key to enabling a robust OpenFlow ecosystem.


Hybrid Devices

The customers that I’ve spoken to have a strong interest in products that are OpenFlow-capable, but which also support a rich collection of legacy protocols. Such hybrid devices are essential to providing a realistic transition picture for SDN deployment.  Without hybrid, customers would face high stakes binary architecture / purchase decisions at a time when applications are immature.  Without a transition story, few buyers can justify the risk, and the market can stall before it really gets started.  Without a healthy early market, it’s tricky to develop the apps, standards, interoperability and various other elements that characterize a robust market.  A chip that supports hybrid boxes provides vendors with win-win: access to the small-but-growing OpenFlow market while also serving the larger established legacy market.    OpenFlow-optimized silicon will be much easier to invest in down the road.




Today’s networking silicon is diverse for a variety of reasons.  OpenFlow Switch 1.0 was simple and supportable across a wide variety of chips because it depended only on basic common features present in most platforms.  But newer versions of OpenFlow go beyond those most common features. Many newer OpenFlow features are optional. That broadens the range of what OpenFlow can support, but it also makes implementations more diverse and makes it trickier for app architects to know which features they can count on.  This “interoperability challenge” was highlighted to some degree at the most recent ONF plugfest at Indiana University. This plugfest included multiple products with preliminary support for OF-Switch 1.3, and the diversity of implementation has been a topic of discussion. The Testing and Interoperability Working Group (TestWG) is working up a technical paper as they have for previous plug-fests.)  The Forwarding Abstractions Working Group (FAWG, of which I’m the chair) is working to mitigate challenges related to platform diversity, though some interoperability challenges, such as management, are outside the scope of FAWG.


Configuration and Management


The Configuration and Management Working Group (CMWG) defines the OF-Config protocol, including OFC1.0 and OFC1.1 (OFC-1.2 is in process at this time), but the adoption of OF-Config is behind that of OF-Switch.  Compounding matters, the leading virtual switch, OpenVSwitch, uses OVSDB as a management protocol.  ONF has not yet specified a management protocol as part of the OpenFlow Conformance Program, so a conformant product could use OF-Config, or OVSDB or some other management device.


The ONF established some aggressive milestone dates for the CAB, and the members are attacking the deliverables with gusto.  The CAB’s first opportunity to “synch up” with other ONF leadership comes on August 7, when the CAB, the Council of Chairs (CoC) and the Technical Advisory Group (TAG) will meet for the first such face-to-face conversation.  (The CoC and the TAG have already had several face-to-face meetings; they are very helpful.)

Today’s complex chips require 12 to 18 months to develop; revolutionary architectures are more toward the long end of that spectrum.  Add the time required to productize, test, train, etc, and we’re looking at 30 months from project start until real revenue begins.  With tens of millions of dollars required to get a new chip to market, firms require confidence that the spec is stable and that demand two to four years out will be big.  On the other hand, hybrid boxes based on existing or evolutionary chips cost less, are less risky, and provide a compelling transition story. The CAB will be working to explain how its members view all these topics. I’m confident that the resulting alignment will accelerate the delivery of compelling solutions.

Image credit: File:Cabs.jpg - Wikimedia Commons