Kurhan - Fotolia

News Stay informed about the latest enterprise technology news and product updates.

Multiple SDN protocols eclipse OpenFlow

An overabundance of SDN protocols are expected to dim OpenFlow's importance and eventually lead to less flexible network controllers for corporate data centers.

OpenFlow has failed to fulfill its promise of becoming the universal protocol within software-defined networking (SDN). As a result, incompatible protocols developed to fill the void are contributing to the uncertainty that's keeping companies away from SDN.

Experts have predicted for several years that OpenFlow had too many weaknesses to become the only protocol that lets an SDN controller tell network switches where to send traffic. Consequently, vendors are using five other protocols to replace OpenFlow.

The use of multiple SDN protocols means controllers, switches and routers will have to support the same technology in order to interoperate. "They [enterprises] should choose their SDN controller carefully, because it's unlikely one controller will ever be able to communicate with any switch or router," said Andre Kindness, analyst at Forrester Research Inc., based in Cambridge, Mass.

Proponents claimed OpenFlow, managed by the Open Networking Foundation, would ease interoperability. However, it failed to gain traction because many switch makers decided the cost of using the SDN protocol outweighed the benefits, according to Doug Marschke, CTO at professional services company SDN Essentials in Newark, Del. Vendors that manufacture chips used in switches also found OpenFlow too cumbersome.

OpenFlow weakness spawns rivals

The SDN protocol's difficulties created an opening for organizations to use other protocols in approaches that compete with OpenFlow. Rival protocols include Border Gateway Protocol (BGP), NETCONF, Extensible Messaging and Presence Protocol (XMPP), Open vSwitch Database Management Protocol (OVSDB) and MPLS Transport Profile (MPLS-TP).

Which, if any, of the half dozen protocols will dominate the SDN market is anyone's guess. These kinds of uncertainties have prevented most corporations, other than service providers and financial institutions, from using SDN in their data centers. "Infrastructure and operations professionals aren't willing to place a bet that could get them fired," Kindness said.

Infrastructure and operations professionals aren't willing to place a bet that could get them fired.
Andre Kindnessanalyst, Forrester Research

A technology shakeout will eventually occur. In the meantime, Joe Skorupa, analyst at Gartner Inc., based in Stamford, Conn., expects to see a lot more product innovation before the network architecture becomes mainstream.  

"As competition heats up and companies are increasingly forced to compete for the business, we will see new, interesting and previously unaccepted business models coming into play," Skorupa said. "We're seeing lots of opportunity for market disruption."

Talk to multiple vendors

To stay abreast of technology changes, companies that want to test SDN should talk to their current vendor and at least two others -- an established vendor and a startup, said Skorupa. "You will learn what is possible by looking at the alternative providers."

Companies that talk to several vendors will have the opportunity to compare products, while also putting the incumbent on notice that it has to earn new business. "It's not loyalty that gets rewarded; it's the potential risk that someone might lose an account," Skorupa said.

Next Steps

Why IT pros are not ready to recommend SDN

CIOs approaching SDN slowly

How SDN differs from NFV

Dig Deeper on Software-defined networking

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Has confusion over SDN protocols delayed testing SDN in your organization?
The confusion will remain until a standards body like the IEEE comes up with a standard that the industry can follow
You've got your facts wrong. First several of the protocols you mention are part of the OpenFlow Standard: OFConfig (and instantiation of NetConfig) and OVSDB are part of the OpenFlow Standard!
Check out David Jacobs' TechTarget article: OpenFlow configuration protocols: Understanding OF-Config and OVSDB for some clarity on the issue.
Also, BGP is supported using OpenFlow was actually demonstrated LIVE at the Open Networking Summit! See this blog on the ONF Atrium project, where OpenFlow switches from 5 different manufacturers were used with the ONOS SDN controller with the exact same BGP stack!
While it's true OpenFlow supports some of the other protocols, vendors have the option of using a combination of these technologies in place of OpenFlow. The story argues that many vendors are likely to choose OpenFlow alternatives.
My objections to your story are as follows:
1) You stated that OpenFlow was competing with protocols that are actually included in the OpenFlow standard! This is either an outright mistake or a misrepresentation. Take your pick!
2) Other protocols that are not part of OpenFlow (such as BGP) that you listed are actually used in conjunction with OpenFlow and have been deployed using OpenFlow switches and controllers (i.e the Atrium Project, Project Vandervecken, etc...) These protocols can be replaced by SDN/OpenFlow based solutions, but this is not an either/or situation, and the decision to implement BGP, or LDP, or ISIS, (or name any number of the myriade IP networking protocols out there) can be done in harmony with SDN/OpenFlow. Suggesting otherwise, as you do in your article, shows a rather incomplete understanding of SDN and OpenFlow.
The article's premise, backed by quoted experts, is many vendors will choose to drop OpenFlow in favor of the many alternatives. Therefore, it is unlikely a universal protocol will ever become reality, which was the original promise of OpenFlow.
I think there is a misunderstanding of the role Openflow plays in the SDN stack. None of the protocols mentioned can actually replace Openflow universally. On the other hand, many of the limitations of Openflow are being addressed in various ways.
Again, the basic premise you state is wrong. OpenFlow was never intended to replace all other network protocols! OpenFlow provides an efficient, open standard mechanism to separate the control plane from the forwarding plane. Via the OpenFlow Controller, applications can implement either existing protocol stacks (such as BGP) or could be used to create entirely new strategies to do the same thing. 
To state that OpenFlow is intended to replace these protocols is false. Of course, all the vendors of proprietary network solutions will dump FUD onto OpenFlow because it provides an Open standard way to deploy these protocols, severely limiting their ability to enforce vendor lock-in. To get an accurate picture of what OpenFlow actually does and how it can be used go to www.opennetworking.org.
Thanks for raising some of these concerns about OpenFlow. I do, however, have quite a different perspective based on my daily, deep interaction with vendors and operators alike who have implemented and deployed OpenFlow or are planning to do so. I have today posted a fairly complete response on the ONF blog at https://www.opennetworking.org/?p=1830&option=com_wordpress&Itemid=316. Dan Pitt, Executive Director, Open Networking Foundation
Hi Dan. I read your response and made note of your perspective. Thanks for jumping into the discussion.