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 that 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 and network functions virtualization. Though only about 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 already 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 technologies:
- 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 API’s 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 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.
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 has previously referred to Cisco OpFlex as an “OpenFlow killer”, 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 protocols 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 at improving SDN and NFV orchestration and network DevOps.
About the Author/Alex Henthorn-Iwane
Alex Henthorn-Iwane joined QualiSystems in February 2013 and is responsible for worldwide marketing and public relations. Prior to joining QualiSystems, Alex was vice president of marketing and product management at Packet Design, Inc., a provider of network management software, and has 20+ years of experience in senior management, marketing, and technical roles at networking and security startups.
Through his roles at QualiSystems, Packet Design, CoSine Communications, Corona Networks and Lucent Technologies he has acquired expertise in cloud computing, software defined networking and network function virtualization, DevOps, ITaaS, and IT automation and orchestration. He has written for Embedded Computing, Virtual Strategy Magazine, Datamation, SDN Central, Datacenter Knowledge and InformationWeek.
These days, Alex focuses a lot of his writing around the intersection of new, programmable infrastructure technologies (cloud, SDx, NFV), DevOps and the orchestration and automation enablement needed to make all of them a reality, in both the enterprise and service provider/carrier space.
Connect with him on LinkedIn | Twitter | SlideShare
