CenturionStudio.it - Fotolia

Q
Get started Bring yourself up to speed with our introductory content.

What is 'open' SDN?

Author Chuck Black explains what 'open' means for SDN, and considers open SDN controllers, protocols and APIs.

What is real "open" SDN?

If you consult Merriam-Webster's dictionary for a definition of the word "open," you won't find a single clear and concise definition -- in fact, you will find 19 of them. So it's no surprise the landscape of SDN is also a bit confusing when it comes to the same concept of "open," which gets enthusiastically thrown around by vendors and standards-bearers alike. Looking at a few categories of "open" may help to demystify the landscape.

Open protocols

OpenFlow is an open protocol that promises solutions that are non-proprietary and should be applicable in heterogeneous environments.

NETCONF, XMPP and YANG are open standards that anyone can implement, but as with Simple Network Management Protocol (SNMP) Management Information Bases (MIBs), devices supporting these protocols will implement their own information model, which can result in proprietary solutions.

Cisco onePK is a proprietary protocol that is implemented on Cisco devices, but any customer can write SDN-type centralized applications to it.

Open controllers

OpenFlow-based controllers can be open source (e.g. Beacon, Floodlight, Ryu) or commercial (e.g. HP or NEC). These controllers should interoperate with any Openflow-supporting device, resulting in the possibility of a multi-vendor network environment.

Multi-protocol controllers are mostly open source, the most prominent being OpenDaylight, which allows multiple southbound protocols (e.g. Openflow, NETCONF). Using the Openflow plug-in on these controllers allows for a multi-vendor device environment. Using other protocols with proprietary information models will often yield only a single-vendor device environment.

Open APIs

Closed SDN solutions such as VMware provide no API for programmability, and are therefore not intended for SDN application development by customers or device vendors.

Open APIs are provided by just about every SDN or SDN-like controller or solution, including Openflow-only controllers; OpenDaylight-based controllers; proprietary open source controllers, like OpenContrail; and Cisco's various SDN systems, like onePK and APIC. Anyone can write applications to these APIs, but the proprietary versions will only work with that vendor's devices.

All of these facets of openness have their strengths and weaknesses. When your friendly neighborhood networking vendor comes calling and begins to wax eloquent on the exceptional "openness" of their product, it would be wise to understand just what type of "open" he or she is talking about before you whip out your fountain pen and sign on the dotted line.

Next Steps

Is the EMC-Dell merger good for open software-defined networking?

This was last published in September 2014

Dig Deeper on OpenFlow

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

4 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.

The discussion on open is confusing largely because being open for the sake of open is not actually a goal. Typically, people use open to mean one of five different things: interoperable, interchangeable, standard, open access, and open source. While people gravitate towards standards, the real business objective is usually more about interchangeability and interoperability. You can, in fact, be standard and not be interchangeable (people choose to implement standards in often fantastically unique ways). The point is that the real conversation is not about open but about something more precise. Without that precision (the business objective behind the request), the discussion isn't terribly meaningful.
Cancel
Great answer Chuck, and welcome as a new SearchSDN expert! Also, excellent point Mike. I agree that we need interoperable more than we need open at this point. But what is the difference between interoperable and interchangeable? I don't think I've ever considered this. (As another pet peeve, there is so much confusion between open and open source -- or the ability to accept community contribution.
Cancel
I think that the point is, today people don't come in and say "is your solution interchangeable"; instead they tend to ask whether it is "open". Whether we like it or not, the word "open" is what people are using today, and so starting from that point, and driving the discussion towards more precision, is what is required. One way to do that is to refine "open" into more precise terms, as suggested in the comment. Another approach is to explore the different domains in which the word "open" is used (and sometimes misused), which is what I have done. I believe that both approaches help to lend clarity to the discussion..
Cancel
Hi Rivka, thanks for the welcome and comment. To briefly address your question regarding the difference between "interoperable" and "interchangeable": one way to look at this is to consider what part of the SDN solution the word is addressing. I think of "interchangeable" most often in terms of network devices; if you have a network device that supports an "open" protocol in the same way as another vendor's device, it is "interchangeable". I think of "interoperable" as applying more to things such as SDN controllers or network management solutions - e.g. an interoperable solution will support devices from a number of vendors. In the SDN context, for example, NEC tested the "interoperability" of their Openflow controller with about a dozen different vendor devices. In that situation, the SDN controller is "interoperable"; the vendor devices supporting Openflow, in that test environment anyway, were "interchangeable."
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