Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

SDN and Openflow: Is the protocol dead?

SDN and OpenFlow were once practically synonymous, but today the protocol is conspicuously absent. Its evolution offers an important lesson for networking pros.

For a while, SDN and OpenFlow were two peas in a pod. When networking professionals first started throwing around...

the term software-defined networking (SDN), it was usually in the same breath as OpenFlow. However, in today's conversations about SDN, we often don't even mention OpenFlow. What happened to the once ubiquitous SDN protocol? Was it a bad idea? Is OpenFlow dead?

To answer that question, let's first start with what OpenFlow set out to do. The Open Networking Foundation (ONF), which controls the OpenFlow protocol specifications, says:

"OpenFlow is the first standard communications interface defined between the control and forwarding layers of an SDN architecture. OpenFlow allows direct access to and manipulation of the forwarding plane of network devices such as switches and routers, both physical and virtual (hypervisor-based)."

In essence, OpenFlow allows us to dive deep into the forwarding plane and set rules on how traffic should be forwarded, based on flow rules sent from an SDN controller. This means it was able to bypass the control plane of a switch, as a result creating a more open, simplified switch. There were some great early OpenFlow deployment success stories, built around such big names as Google, NTT, Goldman Sachs and more. Venture capitalists threw a lot of money at OpenFlow-capable devices, and many thought that by 2015 OpenFlow would take over the world. However, one problem … it didn't.

Always concentrate on the problem to solve, rather than on a protocol to solve it.

Here are a few reasons for the lack of wide-scale adoption of OpenFlow to date:

Lack of switch interoperability for OpenFlow: While many switches worked with OpenFlow 1.0, vendor support for OpenFlow 1.3 has diminished. That's due in part to how the current protocol is crafted; many of its attributes are defined as type length values, and many vendors elected not to support those TLVs. The ONF did its best to try and achieve more interoperability with its testing and conformance program, but many switch vendors felt that the costs outweighed the benefits.

Delay in silicon to support large OpenFlow tables: Custom chip and merchant chip makers had to make modifications in their silicon to support the large flow tables (or even just multiple tables) within OpenFlow. As a result, many of these chips were not engineered with high-speed ternary content-addressable memory. This delay in compatible silicon hurt OpenFlow adoption rates.

The average network engineer does not understand how to deploy the OpenFlow protocol: While network engineers are used to learning new protocols, before SDN and OpenFlow, most engineers were learning protocols that govern the control plane rather than the forwarding plane. Deploying OpenFlow requires a different understanding of items like switch pipeline processing, which is a foreign concept to most network engineers.

While the industry worked to solve these OpenFlow issues, other interfaces became defined and muddled the playing field. Meanwhile, most of the vendors that were making OpenFlow switches hired marketing teams that quickly realized OpenFlow itself is a tough sell. Many of these marketers therefore reframed their OpenFlow offerings as broader SDN "solutions." Although these approaches still used the OpenFlow protocol, users just saw a solution use case. They were able to operate and configure at a higher abstraction layer, which means they didn't have to dive under the hood to learn the protocol.

The future of SDN and OpenFlow

So, is OpenFlow dead? Certainly not, but it has attracted some friendly competition from a few other protocols. Where it does exist, vendors have often repackaged and hidden it with marketing jargon. However, that doesn't mean it isn't leaving its mark. I have seen estimates that OpenFlow will be in 10% to 20% of networks by 2017. If that prediction does hold true, I would say that the protocol is a successful and important player in the SDN space -- although perhaps not the defining option we once thought it would be.

Ultimately, the lesson we need to learn is this: Always concentrate on the problem to solve, rather than on a protocol to solve it. OpenFlow is alive and well and might be in more places than you realize. However, it is very use case-driven and is just one piece of the growing SDN picture.

About the author
Doug Marschke is the founder and CTO of 
SDN Essentials, a professional services company focused on SDN education and training, professional consulting and managed services. Prior to starting SDN Essentials, he founded, built and sold network services company Proteus Networks and created many of the Juniper Networks certification exams.

Next Steps

OpenFlow is not the only game in town

How to choose a southbound protocol

OpenFlow plays key role in Google's internal data center networks

What OpenFlow inventor says they got wrong

This was last published in July 2015

Dig Deeper on Network protocols and standards

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Has your view of OpenFlow changed in the last several years? If so, how?
I've seen this exact same cycle happen with many standards over the last thirty years. The essential lesson I've learned is this: any truly successful technology is one that has become invisible! The reason this is so is quite simple: a successful technology becomes eclipsed by the solutions that use it because these solutions are what truly drive value for users.
OpenFlow is not yet at the invisibility stage, but by my own reckoning it usually takes about ten years (yes, even in internet time!) for this to happen. The increasing focus we are seeing on SDN solutions, rather than on the underlying protocols used by SDN including OpenFlow, is a healthy indicator that this process is underway!

Regarding the "Delay in silicon to support large OpenFlow tables" you mention above, that is not a limitation of OpenFlow, but rather of the legacy silicon most switch vendors are using that was never designed to implement the flexible pipeline architectures that really let SDN and OpenFlow shine. For example, NoviFlow makes network processor based switches that deliver the FULL OpenFlow 1.3/1.4 specification AND millions of flow table entries. Such switches have already been commercially deployed around the world.

Let's keep in mind that SDN stands for SOFTWARE Defined Networking, and not SILICON Defined Networking as in the ASICs typically used previous generations of networking gear. To shine SDN needs to be delivered on truly programmable forwarding plane substrates such as Network Processors.
So, I'm curious how you think your prediction has panned out?Is Openflow in 10-20% of networks today? Has the competition from other protocols taken over? To be honest, I hear less and less about Openflow and more and more about Netconf, Restconf and Yang. I also hear Openflow is too complicated, but really have no personal experience with it. In your opinion, are these competing protocols starting to take over?
From a commercial perspective, we are certainly seeing a lot of OpenFlow sales at NoviFlow! More specifically in response to your question, the decrease in press is to be expected as the focus of SDN-based solutions shifts more to the specific jobs being done than the fact that it uses OpenFlow. The Gartner Hype Curve on SDN places SDN in the "slope of enlightenment", where you expect more pragmatic individuals less obsessed with the technology and more focused on the results. We've noticed this trend within the market and have adjusted our marketing approach in consequence. We have also seen a major increase in partnering activities (you'll see a whole bunch more press release from NoviFlow with partners in the coming months!) in a number of application areas, particularly SD-WAN, SD-CORE, Cybersecurity, Load Balancing, Broadcast IP, BNG GW, H-QoS, and others. In all these cases OpenFlow is a key enabler, but the real show are the applications whose costs/performance/capacity have all been greatly enhanced by use of OpenFlow-based programmable forwarding planes. 
Thanks for your response! I'm just trying to figure out where to focus my efforts in the industry, and that's helpful.