Sergey Nivens - Fotolia

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

Which SDN protocol should I use?

At the dawn of software-defined networking, there was one SDN protocol: OpenFlow. Today, users can select from a growing number of options.

Once upon a time, there was only one protocol for software-defined networking (SDN), and it was OpenFlow. Classic SDN depended on OpenFlow for communications between the SDN controller, the brains of the network, and the data plane devices that carried out its instructions.

SDN has come to have a broader meaning, however, with increasing emphasis on centralized network virtualization and programmability, not just control/data plane separation. As this shift has occurred, other protocols have become important in the space. Cisco introduced an SDN protocol for automating propagation of policy through a network composed of smart devices rather than "blank slate" data plane devices. The rise of VMware NSX and other solutions has brought to prominence the VXLAN protocol for overlaying logical networks across existing networks. NVGRE is a similar virtualization protocol and is gaining prominence as Microsoft and others take advantage of it in their cloud environments. Geneve is an even newer virtualization protocol aimed at unifying VXLAN and NVGRE.

Given the growing number of choices, how can you decide which SDN protocol is best for you? For most, the answer is going to boil down to this: Identify which SDN solution can do what you want and need it to do in the next few years, and then use whichever protocol it supports. Certainly, OpenFlow has the broadest ecosystem of supporting vendors and technologies, but if you can't get what you need using a software-defined network based on OpenFlow, look elsewhere. In the longer run, expect a convergence of one or two protocols and migration paths to get from any deprecated protocols you might have implemented (perhaps NVGRE) to those replacing them (e.g., Geneve).

Next Steps

OpenFlow not the only game in town

Plethora of protocols contribute to SDN uncertainty

Is OpenFlow still relevant?

This was last published in September 2015

Dig Deeper on Emerging software-defined networking protocols

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Join the conversation

3 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Are you more likely to use OpenFlow or an alternative SDN protocol?
Cancel
VXLAN and NVGRE are encapsulation protocols. They don't provide programmable flow instantiation, which is what OpenFlow does, and that is SDN. If we are to label VXLAN and NVGRE as SDN, then we must also accept that older encapsulation protocols are SDN, too. For example, 802.1q VLAN tagging, GRE, etc.

If we do loosen the SDN term to include non-OpenFlow programmable flow instantiation (I prefer to call this simply "Programmable Networking"), then this still doesn't include encapsulation protocols as there's no programmable element to them. May I humbly suggest that dynamic routing protocols are closer to SDN than encapsulation protocols, as they do alter flow. That said, I would have to add Advanced ADC’s to the mix as they make real-time context-based decisions using state (performance/security/app experience) that is constantly altering flow decisions.
Cancel
Thanks for your comment, Nathan -- great perspective and insight.
Cancel

-ADS BY GOOGLE

SearchNetworking

SearchEnterpriseWAN

SearchCloudProvider

SearchUnifiedCommunications

SearchSecurity

  • Passive Python Network Mapping

    In this excerpt from chapter two of Passive Python Network Mapping, author Chet Hosmer discusses securing your devices against ...

  • Protecting Patient Information

    In this excerpt from chapter two of Protecting Patient Information, author Paul Cerrato discusses the consequences of data ...

  • Mobile Security and Privacy

    In this excerpt from chapter 11 of Mobile Security and Privacy, authors Raymond Choo and Man Ho Au discuss privacy and anonymity ...

SearchDataCenter

Close