|LWN.net needs you!|
Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing
OpenDaylight is a Linux Foundation–hosted project (launched in early 2013) to develop a common platform for Software Defined Networking (SDN) and Network Functions Virtualization (NFV). On February 4, the project made its first release, "Hydrogen," which consists of an SDN framework and a set of tools for testing and deploying an SDN network. Despite the fanfare surrounding OpenDaylight, it is a project that has so far struggled to find recognition and attention from developers. Now, perhaps, its first code release will clear up some of the latent confusion, even if SDN itself remains at least a few years away from revolutionizing the computing industry.
Understandably enough, a significant portion of the confusion about OpenDaylight comes from the unfamiliarity of SDN itself—although the project's choice of names is certainly not free from blame either. SDN is an effort to abstract away the physical details of a network: the topology and the underlying hardware. The resulting virtual network layer can then be centrally monitored and managed, and can adapt to best serve the needs of whatever applications are running at the moment. For example, reassigning newly spun-up database servers to the IP subnet already occupied by the existing database servers would make routing traffic between them simpler (and hopefully faster), but is hardly possible if the various subnets in the datacenter are statically configured.
An SDN controller platform should allow administrators to alter facets of the network configuration like switching and routing to adjust to changing demand, without having to manually reconfigure the actual switches and routers. And, of course, applications that place a lot of demand on the network (such as video streaming) should ideally be able to trigger the necessary adaptive behavior from the SDN controller on their own, rather than requiring administrators to do it.
In essence, SDN moves the "where do I forward this packet" decision from the router that encounters the packet up to a higher-level plane, where the SDN controller can make the decision based on multiple factors at multiple places in the network. The SDN community's terminology for this separation is the "control plane" and the "data plane." With that abstraction in place, of course, a host of other assumptions about networking suddenly become worth re-examining, such as which nodes are connected to which. In cloud environments, where virtual servers can be spun up or powered down at will, having a network topology that can adapt to changing circumstances and demand is of immense benefit, so there is significant work being done on SDN by industry—as well as by academics, where SDN originated and for whom the concept raises plenty of other interesting questions about security, routing, and so on.
OpenDaylight was announced in April 2013, spearheaded initially by Cisco and IBM, but with several other big names soon joining, including Juniper Networks, Citrix, Ericsson and (strange as it may seem for a project hosted by the Linux Foundation) Microsoft. Officially, the project is committed to "advancing" SDN in an open, community-driven manner—rather than, say, producing a monolithic SDN stack. Most of the platinum-level member companies donated pieces of existing code, and the project has staked out support for some external standards as part of its strategy as well, most notably the OpenFlow protocol for communicating between the SDN controller layer and the hardware layer beneath it. OpenFlow is a standard maintained by the Open Networking Foundation, which has several member companies in common with OpenDaylight but is otherwise distinct.
OpenDaylight's software includes a collection of modular components. The central component is an SDN controller layer that provides interfaces for other pluggable components (such as applications above the controller and the data plane beneath the controller). The Hydrogen release packages up these components into three different editions: Base, Virtualization, and Service Provider. All of the code is published under the Eclipse Public License (EPL), and it is primarily written in Java (so that it will, at least in theory, run on any platform). Most of the plugin modules available so far implement controller support for different brands and varieties of routers and switches, but there are also some components aimed at getting some work done higher in the stack.
The Base Edition includes the controller, an OpenFlow implementation (for communicating between the controller and the data plane), support for the Open vSwitch virtual switch, and tools for managing network equipment with YANG. The Virtualization Edition adds the Affinity metadata service (which is described as a set of APIs to express workload relationships and service levels), a DOVE (distributed overlay virtual Ethernet) plugin for building virtual networks as overlays, a security framework called Defense4All that is designed to detect and respond to distributed denial-of-service attacks, and Virtual Tenant Network (a network virtualization application using OpenFlow).
Finally, the Service Provider Edition includes the Base Edition plus Affinity, Defense4All, a traffic engineering plugin supporting Border Gateway Protocol with link-state extensions (BGP-LS) and Path Computation Element Communication Protocol (PCEP), a Simple Network Management Protocol (SNMP) plugin for managing legacy Ethernet switches, and a different network virtualization plugin called LISP Flow Mapping (which is no relation to the Lisp programming language; rather, it is a tool that maps virtual networks with the Locator/identifier Separation Protocol).
All three editions of the Hydrogen release are experimental toolkits at this stage. The release announcement advertises the Base Edition as being geared toward academia or those exploring SDN concepts. It similarly says that the Virtualization Edition is targeted at data centers managing "tenant networks" (that is, networks leased to customers) and the Service Provider Edition is targeted at carriers and other providers hoping to migrate their existing networks to SDN.
Given the large-scale networks that OpenDaylight is aimed at, it may not be easy for a novice to jump in and start experimenting with Hydrogen. But the new release does paint a clearer picture of what OpenDaylight project members have in mind. The Virtualization and Service Provider editions incorporate tools designed to manage networks of application servers being hosted for customers. That is more of interest if one owns and runs a cloud computing service than if one simply rents time on such a service. However, all of these tools occupy what OpenDaylight calls the "southbound" interface—between the SDN controller and the underlying data plane. OpenDaylight's architecture also covers the "northbound" interface, between the SDN controller and the applications running on the virtualized network.
At present there is less to see on the northbound interface side—Defense4All is a northbound application, and the Virtualization Edition documentation mentions support for OpenStack's Neutron as a northbound application. OpenDaylight does support two different APIs for northbound applications; the Java OSGi API for applications running in the same IP address space as the controller (as opposed to tenant networks), and a REST API for outside applications. The first OSGi-speaking applications are likely to be tools for monitoring and reconfiguring the network.
That said, it could be quite some time before deployable applications begin to surface for OpenDaylight. Judging by the code contributions made by the various member companies, right now the majority of the work is focused on supporting a wide range of vendors' networking hardware in the data plane through a wide range of management and configuration protocols—not a small task, to be sure. But the premise of SDN is a compelling one for anyone who manages large-scale network applications. To everyone who simply makes use of large-scale network applications, the important aspect of OpenDaylight is that it is such a collaborative effort—hopefully insulating customers from the woes of vendor lock-in, which is unpleasant whether it is software-defined or not.
Copyright © 2014, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds