The OpenDaylight Project has released Helium, the next version of its open source SDN software stack.
OpenDaylight Helium is more secure than the previous Hydrogen release, supports group-based policy, and is more tightly integrated with the OpenStack cloud orchestration system. Developers have also made the software more modular so users can download and install only the OpenDaylight elements they need.
While the Hydrogen code release was more of a developer edition of the software, OpenDaylight Helium is the release that vendors will start building products and services around, said Andrew Lerner, research director for Gartner Inc. in Stamford, Conn.
"You are seeing vendors wrap their commercial offerings around it," Lerner said, including Extreme Networks Inc., Meru Networks and Brocade Communications Systems Inc. "I think it has the promise to deliver some of the most innovative stuff in the networking market."
Cisco and VMware have emerged as the two major SDN ecosystems on the market today, but OpenDaylight has a chance to become an alternative to them, Lerner said.
One essential element missing from SDN today is application portability. An SDN application or service designed for one SDN controller does not translate easily to another. If multiple vendors embrace OpenDaylight, the project's northbound APIs could emerge as a de facto standard, Lerner said.
While vendors will start commercializing the Helium release, very few enterprises are good candidates to download it themselves and put it into production, said Brad Casemore, research director for IDC in Framingham, Mass.
"In that respect, it’s very similar to what’s happening with OpenStack, and it helps explain why vendors are so interested in those open-source projects," Casemore said. "These aren’t ready-made product architectures; they are frameworks that encompass disparate components, some of which interest one group of vendors and some of which interest others."
OpenDaylight Project's security enhancements
Developers have introduced two security enhancements in the Helium release. They have added an authorization, authentication and accounting (AAA) service to the software. AAA is a fundamental security architecture that enforces who has access to which services in the software stack. The AAA service also has plugins and extensions that allow it to interact with other systems that an enterprise or service provider already has in place, said Neela Jacques, executive director of OpenDaylight.
OpenDaylight also added a secure network bootstrapping infrastructure (SNBI) to Helium, which ensures that security is enabled upon booting up network devices and controllers, Jacques said.
Group-based policy with OpenFlow now, OpFlex later
Helium is the first release to support group-based policy, a mechanism for "defining a way to attach policy information to network elements and then communicating that down to the hardware," Jacques said. "It defines an application-centric model that separates the application details from the underlying hardware."
In other words, group-based policy allows an SDN control to optimize the network for application workloads. The concept is a major element of Cisco's Application Centric Infrastructure (ACI), and Cisco developers kicked off the sub-project inside of OpenDaylight. However, the initial implementation of OpenDaylight's group-based policy will rely on OpenFlow as a southbound messaging protocol between the controller and network devices, rather than Cisco's preferred, homegrown OpFlex protocol, which relies more on the network hardware to implement policy than a central controller.
"Cisco has its own view of how [group-based policy] will be done," Jacques said. "Cisco believes a lot of intelligence can and should remain in the hardware, which isn't surprising given that they make high performance networking gear. There are other views in the industry for how it should be done."
OpenDaylight will add OpFlex-flavored group-based policy in its next release (Lithium), Jacques said.
"There was always the intention to support both [OpenFlow and OpFlex] to show that group-based policy was really about the policy, not the mechanism by which you enforce that policy," said Colin Dixon, principal engineer at Brocade and a leading contributor to the OpenDaylight Project. "It just happens to be the case that OpenDaylight has a mature driver for OpenFlow and the OpFlex driver didn't wind up being ready for release in Helium."
There is a group-based policy project emerging within the OpenStack project, too. Dixon said OpenDaylight's efforts are loosely coupled to the OpenStack effort. OpenDaylight also enhanced its OpenStack integration with new support for parts of the Neutron API, including load balancer as a service and security groups, Dixon said.
OpenDaylight modularity through Apache Karaf
The OpenDaylight Project has further modularized its code in the Helium release via an Apache Karaf package, Jacques said.
"It's a way of packaging Java code in an OSGI framework," he said. "Each piece is in its own container and you're able to install only the pieces you want."
Karaf will allow users to download the modules that fit their specific use cases without the overhead and complexity of elements they have no use for. OpenDaylight has also identified which modules work together and which won't.
"Karaf allows you to pick the elements that make sense to you and ignore everything else. You're slimming down the code base for just the functionality you want to do," Jacques said.
OpenDaylight is still vendor-driven
Although the number of contributors to the OpenDaylight Project has broadened, it remains a vendor-driven initiative, Casemore said.
OpenDaylight is taking a bit longer than other open source projects to cultivate a "community beyond the campuses of the networking vendors [who] founded it," he said.
The lack of non-vendors in the community is partly due to the fact that SDN is still new to most networking pros, but that doesn't erase the fact that OpenDaylight is dominated by vendors who compete with each other. This could lead to disagreements in the future.
"So the agendas that OpenDaylight must accommodate are principally those of the major vendors at the platinum level of membership," Casemore said. "Each of them wants OpenDaylight to serve a purpose as a framework or a platform, but the agendas can diverge based on each vendor's product portfolio, strategy and long-term objectives."