As I look over the research being presented at the Sigcomm HotSDN workshop this week, I am amazed at the activity the software-defined networking (SDN), network virtualization, and specifically, OpenFlow standard has catalyzed.  Creative energy is being applied with gathering speed to characterize and solve real problems of network configuration and management, control and monitoring, architecture and application.  Healthy debate is taking place over the merits of the standard and future directions it might take.  I, for one, believe OpenFlow remains on the right track to deliver on the promise of software-defined networking, even as necessary enhancements to the protocol continue.

Although OpenFlow was always intended to operate on physical network infrastructure, the original vision was in many ways theoretical, treating switching elements as software abstractions rather than hardware components optimized for wire-rate switching.  This allowed the selection of flows as the basic operating element, rather than packets.  As a result, OpenFlow can operate on user and application sessions, rather than only switched or routed data paths, opening the door to SDNs.

To a switching guy, this seems kind of crazy.  It’s pretty easy for the number of sessions to exceed the capacity of integrated merchant silicon TCAMs.  Doesn’t this make real-life, low-cost implementations of OpenFlow impractical?  Let’s break this down.

First, it’s not clear that OpenFlow was ever going to reduce the cost of switching.  Unless you’re one of the top-tier internet service companies, with the R&D budget and talent to build, debug, and test your own protocol stacks, the economics of commoditization don’t add up.  And in the OpenFlow world, vendors delivering hardware with bigger TCAMs, more flexible packet processing, and deeper packet buffers will still be able to command a premium over less capable products.

Likewise, although a software-based vSwitch could in theory eliminate the need for OF support in hardware, only a subset of SDN applications lend themselves exclusively to server-resident designs.  Processing power may be increasing at a faster rate than switching speeds, but there is still no comparison between the cost and performance of a general-purpose CPU and dedicated packet handling hardware.

So let’s look at this from the customer perspective.  With decades of distributed switching and routing protocol development under our belts, why does OpenFlow matter?  As a product manager for many years, one of my biggest frustrations was trying to help customers solve application or business-specific problems with generic distributed protocols.  It usually wasn’t that solutions didn’t exist, or that the hardware couldn’t support the required functionality.  In fact there were typically several semi-proprietary protocols that had been developed to meet similar needs—but not with the mix of capabilities the customer required.  If the customer was significant enough, this would set off a round of feature requests, prioritization meetings, resource negotiations, and release scheduling.

The right answer isn’t for network companies to build more highly specialized, over-featured widgets.  Instead, using the OpenFlow infrastructure, the customer, application developer, or service provider can create their own customizations.  This is one of the reasons that the transition from OpenFlow 1.0 to 1.3 is so important – it provides the necessary toolset to execute the actions these experimenters, vendors, and customers need, leveraging the features already present in most existing networking silicon.

By selectively leveraging hybrid mode architectures or stateless packet matching to handle general-purpose traffic, customers can use packet or flow-based OpenFlow rules to capture sessions of special interest for directed routing, processing, or monitoring.  As intelligent (and by necessity, silicon-specific) TCAM rule compilation capabilities and actions become available for OpenFlow 1.3, the application space broadens dramatically.

There’s a lot more to the story here, of course, with challenging practical considerations that switch and router vendors have spent years learning to deal with, and will provide them with ongoing opportunities to differentiate their solutions.  But OpenFlow is bringing researchers, vendors, customers, and suppliers together in a new way.  The pace of innovation can only accelerate now, to the benefit of those who join and support the emerging SDN community.

Guest Blogger Disclaimer:  The views, opinions and positions expressed within these guest posts are those of the author alone and do not represent those of SDNCentral.com and SDNCentral, LLC. The accuracy, completeness and validity of any statements made within this article are not guaranteed. We accept no liability for any errors, omissions or representations. The copyright of this content belongs to the author and any liability with regards to infringement of intellectual property rights remains with them.

Checkout more from our Guest Bloggers:

• Featured Video: The SDN Journey #4 With Jim Metzler. The Changing Nature of Networking (5/23/2013)
• SDN And The Forgotten Data Plane – Is My Flow Equal To Your Flow? (5/11/2013)
• OpenDaylight Project: The Speed Promise By Kelly Herrell (5/10/2013)
• SDN: Software Defined Everything: Infrastructure Integration Will Never Be The Same (5/6/2013)
• A Taxonomy For SDN Solutions (5/4/2013)

About the Author

.

David Hawley

Highly experienced product executive with more than 20 years of success in bringing leading edge solutions… More

Connect with the AuthorLinkedIn