eugenesergeev - Fotolia


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