CenturionStudio.it - Fotolia

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 Network protocols and standards

Join the conversation


Send me notifications when other members comment.

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