Crossroads for OpenFlow?

010716 sdn 2

In SDN’s early days, possibility abounded. The thought of what could be excited practitioners and tantalized developers. OpenFlow was an early SDN star, a proof of concept from Stanford that demonstrated a new way to program a network. Many even conflated SDN and OpenFlow, as if one could not exist without the other.

That’s not the case, but early in the SDN hype cycle, it was an understandable perception. OpenFlow progressed quickly, as the Open Networking Foundation drove OpenFlow development ahead, publishing several iterations of the OpenFlow specification in rapid succession.

Lately, OpenFlow progress seems to have stalled. Industry fervor over OpenFlow has quieted. ONF releases of major OpenFlow specifications have slowed. Vendors making SDN announcements don’t emphasize OpenFlow terribly much these days.

SDN has created an industry of its own with several classes of products, some of which don’t leverage OpenFlow at all. At the spring 2015 Open Networking User Group meeting in NYC, OpenFlow was not a major topic of discussion. Some vendors have shown little interest in, and even an aversion to, adding OpenFlow support to their products — notably Cisco and Juniper. While others, like HP and Brocade, have made OpenFlow an important part of their ecosystem.

OpenFlow seems to be at a crossroads. Depending on your point of view, this might seem surprising, and it leads to a question: Does OpenFlow have a significant role to play in SDN, long-term?

The answer to that question lies in understanding what OpenFlow is really for. OpenFlow is simply a tool for programming forwarding tables in network devices.
But … that’s it.  OpenFlow is simply a tool. That said, don’t sell OpenFlow short. OpenFlow may be a tool, but it is both a useful and powerful tool. OpenFlow is compelling in that it offers the following:

  • A standardized interface that abstracts vendor-specific hardware away. A controller that speaks OpenFlow should be able to
    program a device that supports OpenFlow.
  • A means to program the network centrally.
  • An easy way to do “exception programming,” the handling of unusual traffic flows that cannot follow the normal best path through the network.

Those who keep up with OpenFlow’s use will rightly point out that OpenFlow isn’t exactly standardized, in the sense that some vendors have extended OpenFlow to give it additional capabilities. This is true, but it’s worth pointing out that vendors (including Big Switch, NEC, and VMware) are working with the ONF to bake these extensions into standard OpenFlow. This process is similar to how other vendors have handled proprietary extensions to standards in the past. It seems unlikely that the industry will fracture when it comes to OpenFlow. Vendors using OpenFlow are trying to stay on the same page as their industry peers.

Others might point out that OpenFlow sells some hardware short, in that OpenFlow as a standardized interface can’t expose every capability a given chunk of silicon might have. After all, vendors like Cisco and Juniper differentiate themselves by their silicon. That is also true, but this doesn’t change the fact that all networks have a root set of common functions related to traffic forwarding and access control, no matter the silicon in question.

So, if OpenFlow is just a tool, is there any particular reason to emphasize it?

SDN in its early days was excited about tools, because SDN could not move beyond ideas without them. As an industry, we’ve started the process of moving beyond the tools and into the realization of what those tools can bring to networking. And thus, the focus is beginning to shift into use cases, products, and operationalization of the software defined network. Put another way, the average networking consumer isn’t buying SDN or OpenFlow. Rather, as SDN moves slowly into the mainstream, consumers are buying the capabilities these tools bring.

How vendors are using OpenFlow

As an industry, we know now that SDN means more than OpenFlow. We also know that software programming the network doesn’t have to use OpenFlow to get the job done. OpenFlow is just one tool among many that has proven useful to the software defined paradigm. But let’s not make the mistake of putting OpenFlow out to pasture, or minimizing the impact that the tool has had. For example, vendors are using OpenFlow in several commercial products. Here are just a few examples.

  • HP uses OpenFlow in several products. HP’s VAN controller leverages the protocol to program network switches in applications such as its Network Optimizer, which offers dynamic QoS programming for Microsoft Skype for Business (formerly Lync).
  • Brocade’s Vyatta Controller runs with OpenDaylight code and uses OpenFlow as one of the programming options.
  • Even Cisco offers some OpenFlow support on a limited number
    of its switching platforms.
  • And lest we forget, OpenFlow is an important tool in Open vSwitch, which continues to grow in popularity.

We could cite more examples, but the key is to recognize that many vendors are using OpenFlow either in an SDN application or supporting it in a hardware platform. Still, OpenFlow is not ubiquitous. As an industry, we’re not at a point where we can assume OpenFlow availability in a given switch platform. Even when OpenFlow is a supported feature, we can’t be certain which specific features are supported, or whether a supported feature will be useful at scale.

To address these concerns, and make OpenFlow more predictable going forward, the ONF has created a variety of working groups, communities and proposals.

One ONF working group is the Forwarding Abstractions Working Group (FAWG). The FAWG is working on ways to describe OpenFlow capabilities that will make it easier for hardware abstraction layer (HAL) writers to implement OpenFlow in their silicon.

A major FAWG focus is Table Type Patterns (TTP). FAWG Chair Curt Beckmann says, “The (optional) usage of a TTP clarifies two things: what forwarding capabilities will be used in a given context, and how those capabilities can be controlled via OpenFlow.”

In short, TTPs are paving the way for easier consumption of complex OpenFlow directives, something that became an increasing challenge in OF versions after 1.0.

The FAWG is an illustration of how the ONF is working with the industry to make even complex OpenFlow capabilities easier to consume. While that cooperation is taking time, there is early fruit.

For example, Broadcom, a leading supplier of Ethernet silicon, announced a “next generation” open switch pipeline specification in December 2014 called OF-DPA 2.0. OF-DPA 2.0 uses TTPs, as well as many of the rich features found in OF 1.3.1. The point is that progress is being made that makes OpenFlow easier to use as a highly capable network programming tool able to articulate complex application demands.

OpenFlow’s future seems bright Research by this author into SDN use cases for enterprises reveals that, broadly speaking, companies are turning to the tech for traffic manipulation, security and network virtualization. What’s intriguing is the many solutions within these categories use OpenFlow as the programming tool in the majority of cases.

Interestingly, OpenFlow interoperability is also becoming something vendors can discuss without smirking. For example, NEC recently announced a partnership with Alcatel Lucent Enterprise in which NEC’s long-standing ProgrammableFlow controller uses OpenFlow to program ALE switch hardware.

With all of this in mind, I see OpenFlow’s future as bright indeed. OpenFlow is getting ready to be the great equalizer - a key element in the growing open networking movement.

By “great equalizer,” I mean that if OpenFlow is able to be used to consume complex, feature rich silicon at scale across many, if not all, hardware platforms, then the vertically integrated stack becomes less important. While networkers are used to network hardware that comes with special silicon, a companion CLI, and some sort of API, those components have always been tightly aligned. If OpenFlow breaks through in ubiquity, then the switching platform itself will matter less than the applications that run on top of it.

This plays well into open networking’s central theme of disaggregation, where an enterprise or service provider can choose a whitebox switch that runs a compatible network operating system of their choosing. This offers them operational choice, reduces vendor lock-in, and may well create a cost savings.

OpenFlow dovetails nicely with those values, offering SDN controller writers a predictable way to program hardware. As the network industry moves into this open world, an explosion of innovation should take shape. Markets for novel SDN applications, operational flexibility, and overall IT efficiency will open up, once there’s a predictable, abstracted network platform to work with.

OpenFlow may be at a crossroads, but it’s not going away. I strongly suspect that the best is yet to come. 

Ethan Banks has been managing networks for higher ed, government, financials and high tech since 1995. Ethan co-hosts the Packet Pushers Podcast. With whatever time is left, Ethan writes for fun & profit, studies for certifications, and enjoys science fiction. @ecbanks

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Must read: Hidden Cause of Slow Internet and how to fix it
Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.