Helium, the second code release for the OpenDaylight Project, is available for downloading as of today, and obviously, that means the OpenDaylight Technical Steering Committee (TSC) has decided what's in and what's out.

Among the casualties: OpFlex, the southbound interface that Cisco is proposing for communicating policy information to network equipment.

OpFlex is part of the plan for Cisco's Application-Centric Infrastructure (ACI), and it's used for having the Application Policy Infrastructure Controller (APIC) talk to Nexus 9000 switches. But according to discussion on the TSC mailing list, OpFlex in OpenDaylight had more lines of code than any other Helium project and wasn't likely to be even half completed by release time. So, the OpFlex team withdrew the project from Helium.

That OpFlex is not being shoehorned into Helium is a "sign of maturity" for OpenDaylight, says Colin Dixon, a TSC community representative. (While he works for Brocade, Dixon has been selected as one of the communitywide representatives to the TSC). "There's a lot of code there [in OpFlex], and you can do a lot of things with it. It just wasn't as feature-complete as you'd want it to be," Dixon says.

But a different project crucial to ACI did make it into Helium: group-based policy."It's no secret Cisco is very much behind it, but others have joined in," including IBM and Midokura, says Neela Jacques, the OpenDaylight Project's executive director.

Group-based policy, which is also being developed for OpenStack, involves telling groups of network devices how to interact with other groups. Instructions are given at a high level, and it's up to those devices — switches, routers, and the like, in physical or virtual form — to configure themselves to make that happen.

Source: OpenDaylight Project

OpenFlow, not just OpFlex, will be a southbound interface for communicating those policies — but really, the specifics of how policy will be implemented are still in flux. "I don't think it's the final answer, but it's the first good stab at how we're going to do policy," Dixon says.

For a full look at Helium, click on the diagram at right.

OpenDaylight Helium is only the second code release for the project, and while the organization hasn't perfected the process yet, it's shown some definite progress since the release of Hydrogen, which came out in February, a few months behind schedule.

"When Hydrogen came out, I think people thought, 'These guys are gonna fall over dead and it'll be funny' — and it didn't happen," Dixon says.

"Hydrogen was about proving this project had legs — that we were a project worth betting on," Jacques says. With Helium, more companies have gone all-in. "I think the best example is probably Brocade," he says, as that company has gone out of its way to amass talent specifically to work on OpenDaylight. Dixon would be one example.

"I've been happy to see folks like Dell, who wasn't very engaged, getting more engaged," Jacques adds.

One thing that might have changed is the "gravitas" around the project. A growing chunk of the equipment industry seems to be counting on OpenDaylight for providing the basics of software-defined networking (SDN), and OpenDaylight participants are starting to feel more of that weight, Dixon says.

The focus hasn't changed, though. It's still about developing an SDN controller and the ecosystem that goes around it. So while OpenDaylight is touching on areas such as network functions virtualization (NFV) and Layer 4-7 functions, that work is being done with the SDN controller in mind.

Neither has the core group of people changed. IBM's participation has shrunk as that company has gone through its reorganization, including casting off its blade networking to Lenovo. But IBM's people are still involved — albeit with some having moved to Brocade, as we mentioned above. In all, about 200 developers are working on OpenDaylight on a regular basis, Dixon says. (UPDATE: The Lenovo deal is due to close this week, IBM announced today.)

Some of the less glamorous bits going into Helium involve hardening the code, making it better prepared for real-world usage.

The controller can now be clustered and scaled out for high availability. Authentication, authorization, and accounting (AAA) capabilities are also included in Helium. AAA lets the network decide who has permission to do which actions.

"It would be very difficult to commercialize or deploy this without those two things, so we really nailed them down," Dixon says.

Helium also brings OpenDaylight closer to OpenStack. The controller can now understand OpenStack security groups and OpenStack Neutron's Layer 2 networks.

And then there are table type patterns (TTPs), a pet project of Dixon's. He recently detailed the concept in this post on SDxCentral, and he explains it further in a video posted earlier this month.

TTPs let an OpenFlow hardware switch expose more of its capabilities to an OpenFlow controller, allowing for clearer communication between the two.

"These things are going to be fun toys to have in your toolkit, but they're not going to drive a sea change in how you do networking. Policy might," Dixon says.

Among the other pieces left out of Helium are IBM's DOVE technology for network virtualization and Plexxi's concept of network affinities. Neither really got to the starting line, due to factors that probably have more to do with the companies' internal priorities than with the technologies, Dixon says.