First Impressions of the OpenDaylight Helium Release

OpenDaylight introduced Helium last month, which is a major upgrade to its open source SDN controller. Here’s my take on its features, shortcomings and strengths from an engineering perspective.

Helium is the second software release from the OpenDaylight project and includes the following notable enhancements and new features:

    1. Support for the Apache Karaf container to allow network operators to customize installation using only the features they want
    2. A new user interface, dlux (the OpenDayLight User eXperience) for client-side MVW (Model View Whatever)
    3. Group Base Policy for an application-centric way of expressing policy
    4. Accounting, authorization and authentication for enhanced security
    5. The BGPCEP project now supports provisioning segment routing through PCEP

With Helium there are no base, virtualization or service provider editions. Instead, bundles are supported through karaf features. Unlike the first (Hydrogen) release, Helium is targeted towards production environments.

Out of the Box Experience

After downloading the pre-built zip file, it is straightforward to run the karaf container with the ‘bin/karaf’ script. The ‘help’ command in the console provides a list of karaf commands and ‘info’ provides the platform and environmental information. The ‘feature:list’ command lists all the features that are available in Helium. The ‘log:tail’ command tails the karaf log and helps in debugging. The log is also available at ./data/log/karaf.log. The log level can be changed with the ‘log:set’ command. Karaf supports a subset of shell commands. Similar to UNIX shell commands, the karaf console command outputs can be piped to ‘grep’ or ‘more’ for further processing.

The Helium Installation Guide provides the list of karaf features that must be installed for each project. The features are built in such a way that the dependent features are also installed automatically.

Packet Design’s Network Access Broker, which has been updated for Helium, uses BGPCEP features for provisioning traffic-engineered paths. Enabling these features, as described in the Helium BGPCEP installation guide, brings up the BGP-LS and PCEP peering with compatible routers. The topologies in OpenDaylight are visible through the following RESTConf APIs: http://<odl>:8181/restconf/operational/network-topology:network-topology/. The RESTConf APIs can also be explored using API explorer, which is available at http://<odl>:8181/apidoc/explorer/index.html.


Similar to Hydrogen, the Helium documentation is lacking. There are many documents that are not up-to-date and some contain broken links. OpenDaylight engineers maintain the documentation and do make some updates upon request.

Though Helium supports high availability and clustering, these are rudimentary in nature. For any production-quality controller deployments, high availability is of utmost importance and required by most customers.

We have also requested, via the OpenDaylight user group, that https support for RESTConf be added in the next release of the controller, labeled Lithium.


OpenDaylight has a very robust and committed engineering community. They answer any question about the project and Helium deployment promptly. The OpenDaylight meet-ups that are being organized in various locations are making it easy to source technical help and bounce ideas off fellow users.