A survey of open networking standards, part 1: OpenDaylight
February 12, 2015
Open source standards hold a lot of potential for networking. Already, initiatives such as OpenStack and OpenDaylight have gained a fair amount of mom...
Open source standards hold a lot of potential for networking. Already, initiatives such as OpenStack and OpenDaylight have gained a fair amount of momentum due to the contributions of major vendors such as Intel who recently joining OpenDaylight as a platinum member. That momentum is even spurring telecoms like AT&T to start their own open source efforts like the Open Networking Lab.
Beginning with this entry, I’ll examine various open networking standards and how they are impacting telecom businesses, IT strategy, and network engineering. At a meta level, it’s fair to say that due to the influence of open source development, networking teams are becoming more concerned with APIs, DevOps automation and the need to move away from manual towards automated ways of engineering and operating networks. Of course, each standard brings something different to the table. Let’s look at OpenDaylight.
OpenDaylight: The Open SDN Control Plane Project
The Linux Foundation manages OpenDaylight, the goal of which is to accelerate the development of software-defined networking (SDN) and network functions virtualization (NFV). Though not even two years old, OpenDaylight is already one of the largest open source projects in the world, with 266 developers contributing in the past year or so, and the project blowing past 1 million lines of code in early 2014.
What does OpenDaylight specifically address? It is perhaps best understood as offering an open control plane solution to enable multiple layers of SDN technology:
- The data plane layer consists of the physical and virtual devices in the network that speak various protocols northbound to the control layer. This includes but isn’t restricted to OpenFlow.
- Above that is the OpenDaylight controller platform with northbound APIs to the application/orchestration layer, plus a multitude of southbound protocols and APIs exposed to the underlying data plane layer hardware
- At the top is orchestration and the application layer. This layer could look like a plug-in for OpenStack Neutron, for example.
OpenDaylight is trying to function as a sort of “Switzerland” of controllers, allowing compatibility with any type of switching hardware via many different protocols and interfaces such as OpenFlow, Path Computation Element Protocol (PCEP), NetConf, etc. The OpenDaylight controller runs on its own Java Virtual Machine and supports the Open Service Gateway initiative (OSGi).
Vendors and the future of OpenDaylight
A ton of networking vendors have piled onto OpenDaylight to such an extent that detractors are arguing that the project, despite its open source moniker, may end up actually preserving the position of networking incumbents. Cisco and IBM founded OpenDaylight and were followed as members by Brocade, Juniper, Microsoft, Intel, and others. A huge portion of OpenDaylight’s code contributions are made by large networking vendors.
With OpenDaylight in particular, the contributions of Cisco have often been scrutinized due to Cisco’s unique take on SDN and what type of controller should be used. Network World’s Jim Duffy referred to Cisco OpFlex as an “OpenFlow killer” last spring, which may be an exaggeration, but it’s clear that Cisco has something other than OpenFlow in mind for the future of OpenDaylight’s core. OpFlex could be a key part of the Lithium release that will succeed OpenDaylight Helium. However, Guru Parulkar, director of the Open Networking Lab, cited OpFlex’s exposure of device specifics to applications as a needless complication and one of the reasons for creating an alternative to OpenDaylight.
Of course, itís a difficult balance for vendors to achieve between innovating in their own product and service lines and participating in the open source community. Projects like OpenDaylight demonstrate the promise of open source software in enabling SDN orchestration, the “Wild West” nature of openness, and the risks of having incumbent vendors become the de facto new sheriffs in that Wild West landscape due to sheer muscle. A middle path is clearly needed.
“The vendor’s role in open source networking projects should be a symbiotic one with other members of the community,” wrote Mike Cohen for TechCrunch. “This includes contributing to open source efforts for the good of the community while continuing to innovate and build differentiated products that better meet user needs. Vendors should also contribute some of those innovations back to the community to help promote new standards that will help the market continue to grow.”
The upshot
OpenDaylight, initiated by Cisco and IBM in 2013 and now hosted by the Linux Foundation, is not only a significant open networking standard but one of the most prominent open source software movements. Period. It defines an open controller with a wide set of southbound protocol APIs for different types of infrastructure and northbound integrations. The shape that vendor contributions to and relationships with OpenDaylight take will be critical both to its rapid progress in delivering features, but also to its future as an inclusive effort to improve SDN and NFV orchestration and network DevOps.
