Development
OpenDaylight emits "Hydrogen"
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.
Software what?
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.
The component parts of Hydrogen
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.
Brief items
Quotes of the week
grep-2.17 released
Version 2.17 of the GNU grep utility is out. "This release is notable for its performance improvements: we don't often see a 10x speed-up in a tool like grep." Other changes include the removal of the long-deprecated --mmap option.
SyncEvolution 1.4 released
Version 1.4 of the SyncEvolution PIM-synchronization framework has been released. This update is the first to support in-vehicle infotainment (IVI) systems, including GENIVI's Diagnostic Log and Trace (DLT) system. Google CardDAV support has also been added, but the release notes say "The biggest change for normal Linux users is Google CalDAV/CardDAV authentication with OAuth2. These are the open protocol that Google currently supports and thus the recommended way of syncing with Google, replacing ActiveSync and SyncML (both no longer available to all Google customers).
"
Brython 2.0 available
Version 2.0 of Brython, an implementation of Python 3 in the browser, has been released. "Its goal is to be able to write client-side programs in Python instead of Javascript, with code inside tags <script type="text/python>...</script>. As opposed to solutions such as Pyjamas or Py2JS, the translation from Python to Javascript is done in the browser, it doesn't require a precompilation by a Python program.
"
Git v1.9.0 available
Git 1.9.0 has been released. This update incorporates numerous changes to various subsystems and features, as well as performance improvements, clean-ups, and documentation fixes. Backward-compatibility notes are also included.
virt-manager 1.0.0 available
Version 1.0.0. of virt-manager, the desktop application for managing KVM, Xen, and LXC virtual machines, has been released. The new build adds support for snapshots, new defaults, and many other new features.
Newsletters and articles
Development newsletters from the past week
- What's cooking in git.git (February 12)
- What's cooking in git.git (February 14)
- What's cooking in git.git (February 19)
- LLVM Weekly (February 17)
- OCaml Weekly News (February 18)
- OpenStack Community Weekly Newsletter (February 14)
- Perl Weekly (February 17)
- PostgreSQL Weekly News (February 17)
- Python Weekly (February 13)
- Ruby Weekly (February 13)
- This Week in Rust (February 15)
- Tor Weekly News (February 19)
How OpenStack parallels the adoption of Linux (opensource.com)
Over at opensource.com, Red Hat's cloud evangelist Gordon Haff looks at the adoption of OpenStack through the lens of the adoption of Linux (and surrounding projects). "Early Linux success didn’t come about because it was better technology than Unix. For the most part it wasn’t. Rather it often won because it was less expensive than proprietary Unix running on proprietary hardware. It also gave users a choice of both distributions and hardware vendors as well as the ability to customize the code should they so choose. However, what has truly distinguished Linux and open source broadly over time is the power of the open source development models and the innovation that comes from communities around projects."
Page editor: Nathan Willis
Next page:
Announcements>>