Will OpenDaylight evolve to dominate the SDN/network management market for the next 25 years in the same way X did with Unix workstation GUIs?
X refers to X11, the first portable window system for bitmap displays. X11 was released in 1987 by the MIT Athena project, which then formed the X Consortium to continue development. This was done with the support of DEC and IBM who were looking for window systems to support their newly developed workstation hardware.
At the time, I was working at Sun Microsystems. Those of us at Sun viewed X as a strategic threat to Sun’s acknowledged lead in workstation GUIs. Sun had a kernel-based window system, like Microsoft Windows, with a collection of productivity tools on top of it.
X was designed with an architecture that isolated the device-dependent parts in device drivers, what today, would be called “plug-ins.” The device drivers were accessed through an API that abstracted the device specific functions. This allowed the device-independent code to operate with device-dependent code for graphics hardware and input devices from many different manufacturers. The design was unique and novel.
The X Consortium quickly gained members from other companies in the thriving Unix workstation market. Eventually, Sun also joined the X Consortium and abandoned their kernel-based window system, with little or no impact on the market uptake of Solaris and Sun’s industry-leading workstations.
When Linux was developed, X became the window system of Linux, and has dominated the Unix workstation GUI market for the last 25 years. X was instrumental in promoting portable applications between workstation manufacturers and in supporting desktop GUI applications research during the 1990’s.
Now fast forward to 2013 and another, completely different market: networking. In spring, under the purview of the Linux Foundation, Brocade, Cisco, Citrix, Ericsson, IBM, Juniper, Microsoft, and RedHat, joined together with other vendors to form the OpenDaylight consortium.
The goal of OpenDaylight is to produce an open source, software defined, networking controller that is technology-agnostic on its southbound interface and supports multiple, northbound interfaces for different applications. Similar to what X did for graphics hardware, the OpenDaylight design recognizes that there are different models of networking hardware. The OpenFlow switch model, which the Open Network Foundation has standardized, requires the switch to support a TCAM, or to abstract the network hardware so that it looks like a TCAM. Other models for networking hardware commonly used are optical cross connects and longest prefix matching ASICs. By supporting multiple different southbound protocols, OpenDaylight broadens the scope of networking hardware that can be supported to include existing switches and routers as well as future switches with OpenFlow support.
In addition, OpenDaylight provides a platform to unify the network management plane and the control plane. This is a goal that has eluded networking technology for many years due to the centralized nature of the management plane and the distributed nature of the control plane. The result promises to simplify the management and delivery of operator networks.
Above is a diagram illustrating the architecture of the OpenDaylight controller, showing the components in the first release, called “Hydrogen.” The Hydrogen release will come in three editions (acronyms explained in the figure):
- The Base Edition: This includes only OpenFlow and NetConf southbound with only the Base Network Service functions.
- The Virtualization Edition: includes the OVSDB protocol southbound and the Affinity Service, VTN, DOVE, and the OpenStack Service.
- The Service Provider Edition, which does not include OVSDB, VTN or DOVE, but does include SNMP, BGP-LS, PCEP, and LISP southbound and the Affinity Service and the LISP Service northbound and is designed for network operator use.
The Service Abstraction Layer (SAL) is an ambitious attempt to simplify the programmatic interface development in OpenDaylight. The idea behind the SAL is to specify a programming language independent model for the services, using a specification language called YANG. This approach is called “model driven development.” An abstract specification of the SAL should allow the unification of the northbound and southbound APIs of the controller, the various data structures, reducing the amount of code duplication and allowing northbound services to be developed in a variety of languages (REST, Java, etc.). YANG facilitates the data structures and functionality of the controller components to be modeled and the semantics of the controller elements and their relationships to be defined.
The model driven approach is still under development and will appear post-Hydrogen, a migration plan from the current programming language dependent interfaces has been defined. When the SAL is complete, applications written on the northbound APIs will be much more portable. They will be able to access vendor specific as well as standardized southbound interfaces.
There has been much discussion in the SDN community about Cisco’s role in founding OpenDaylight. After all, wasn’t SDN supposed to be a way to dethrone Cisco’s dominance of networking? But this response really misses the point. OpenDaylight is being run by the Linux Foundation, who, with the participation of vendors, has an excellent history of running vendor- neutral, open source projects.
Indeed, there are contributions from some independent developers, from the University of Kentucky, in the Hydrogen release. This is done in the same way as independent developers often contribute to Linux releases. Without Cisco’s participation, OpenDaylight would never address the bulk of the existing enterprise networks. The important point is that, from the start, OpenDaylight is designed to be multivendor and multiprotocol. The inclusions into the open source code base will depend on technical merit. Yet, just like with X, vendors are free to include product specific support in their own release, with the northbound APIs and SAL providing abstractions to allow generic access to the vendor specific support.
Will OpenDaylight evolve to dominate the SDN/network management market for the next 25 years in the same way X did with Unix workstation GUIs? Time will tell. But given the energy and enthusiasm shown over the last 9 months, as well as the budding participation of independent developers, the future for OpenDaylight looks promising.
James Kempf, Ericsson Research