Data Centers

OpenDaylight: One open source SDN controller to rule them all?

The open source project OpenDaylight is on a mission to increase enterprise adoption of software-defined networking (SDN). Read about this ambitious effort to unite all SDN controllers.

fantastic-tux-linux-620x465.jpg

OpenDaylight, an open source software-defined networking (SDN) controller, aims to tear down the barriers to SDN adoption in the enterprise. SDN controllers allow the separation of flow control (i.e., how packets get from point A to point B) from the physical network hardware.

At a recent Software Defined Data Center (SDDC) symposium, Neela Jacques, the Executive Director of OpenDaylight, said enterprise network managers are fully aware of the benefits of SDN, but they are reluctant to commit to an SDN controller amongst the confusion. He says the two primary reasons for the lack of SDN adoption are technology fragmentation and duplication of efforts.

A number of controllers have hit the market, and there are many more in development. The list includes open source projects OpenFlow, OpenContrail, and the soon to be released Cisco Application Centric Interface (ACI), which is proprietary. VMware's NSX has its own controller as well.

Despite the long list of controllers, there are currently no standards that allow interoperability of controllers and underlying hardware. If a new open source project or vendor wants to create a new controller, it must work with each hardware provider independently. It has taken years for the major providers to support OpenFlow, the original SDN controller. Jacques' argument is that this has basically frozen enterprise network managers in their decision making process about SDN.

The OpenDaylight project's promise is to unite all of the controllers by offering a standard that network hardware providers and other software controllers can embrace. Once OpenDaylight becomes that standard northbound interface, other controllers can leverage OpenDaylight to gain consistency across multiple vendors. The argument is rooted in the fact that OpenDaylight is open source and, therefore, not a threat to traditional network vendors. The idea is to build an ecosystem similar to OpenStack, where vendors flock to OpenDaylight as part of a thought leadership land grab.

OpenDaylight's technical and political challenges

The question for early adopters is: How mature is the platform?

Similar to the early years of OpenStack (which is only four years old as of this writing), the OpenDaylight project is very ambitious; the effort to create a single controller to rule all other controllers is daunting, and there are technical and political challenges.

OpenDaylight is actively looking for contributors to help bring it to the maturity level where it can become a supported project. The project has to convince the industry that their vision is the right one to rally around. There has been some success with Extreme Networks recently announcing support and several vendors, including Cisco, as major contributors to the project. Supporters are quick to tell potential end users that this is still a beta-level solution.

Conclusion

If your organization is starting to look into SDN and isn't pressured to deliver on the promises of SDN, I think OpenDaylight should receive some of your research resources. However, if you want to gain the competitive advantages promised by SDN, I recommend looking at a more mature controller such as OpenFlow or NSX and keeping your eye on OpenDaylight and potentially integrating it into a future revision of your SDN infrastructure.

Automatically subscribe to TechRepublic's Data Center newsletter.

Also see

About

Keith Townsend is a technology management consultant with more than 15 years of related experience designing, implementing, and managing data center technologies. His areas of expertise include virtualization, networking, and storage solutions for Fo...

4 comments
knuthf
knuthf

Thanks for the tip Keith.
I have started the mission to knock the daylight out of "OpenDaylight" - we cannot have duplicate effort, and the Americans have to learn that open standards and technology should be used where it is available.


The ITU-T standards and the system that does just what they aim to do, but is up and running and configures networks as you read this is described http://www.univerself-project.eu/itu-t - and in numerous similar articles. 

Mike Bushong
Mike Bushong

There probably needs to be a little bit of precision here given that people are basing recommendations on this.


The overlay space (NSX, but also Nuage, Midokura, PLUMgrid, and the like) are about simplifying edge policy. Increasingly, NSX is even moving towards distributed firewalls in addition to just handling policy management. The point is that the use case and benefit are fairly specific. 


SDN generally solves a slightly different (though frequently related) problem. By centralizing control, SDN aims to provide more intelligence into the network, which allows for different types of network services and capabilities. Google is the best example of this. They wanted to drive utilization up on the links between their internal-facing datacenters. By using SDN, they were able to get utilization up over 90%. 


If you are looking for an aspirin for policy, then overlays make sense. If you are looking for a vitamin to help boost your strength around revenues, then SDN makes sense. From there, the different commercial controllers can be evaluated. On the aspirin side, look at ACI, NSX, and even my own company's policy-based products Plexxi. On the SDN controller side, you look at OpenDaylight, Big Switch, NEC, and a number of open source projects.


Mike Bushong (@mbushong)

Plexxi

keith19
keith19

@Mike Bushong Thanks for the additional color Mike. As noted, OpenDaylight isn't making the claim to displace any of the "aspirin" solutions but rather aggregate them.  


Interesting, it seems you make a distinction that the other vendor's don't.  VMware, Cisco, Nuage and etc. have classified their solutions as SDN. What industry term would you use for Overlays and ACI? 

knuthf
knuthf

@keith19 @Mike Bushong you should call them all "Proprietary and vain attempts to duplicate effort". These may have an impact in the US, but the day is over for the Daylight. They should now have to comply with international standards and industry standards. It is not up to a team of amateurs with a sound blabbermouth to define this.

The standards exists, the systems exists - but since these are already doing fine managing the mobile networks, international networks and high capacity fiber links, there is no reason to participate in discussions in a tiny market. The applications that expect to use "Daylight" should be modified to interface to the ETSI/ITU-T systems, see http://www.univerself-project.eu/itu-t


The terms to use is "Intelligent Networks" - IN, "Total Network Management" - TMN and for protocols and network states: SS7 - same as in ISDN - "Integrated Subscriber Digital Network" developed by among other Bell Labs. Optical interfaces are STM that allows usage of fiber at vastly higher capacity than the current IP based technologies allow.

Editor's Picks