Tunnel + Daylight

So, What’s Happening With The Open Daylight Consortium?

Tunnel + DaylightDoes the existence of the Open Daylight consortium mean that the goals of SDN will be achieved sooner than they might have otherwise been, or does it mean that SDN has been co-opted by a few large players?  That question was hotly debated back in April of this year when the consortium was first announced.  Given that several months have passed and some of the emotion that surfaced back in April has died down, this is a good time to take a look at where the consortium is today and what we can expect from it in the near term.

The consortium’s stated mission is to facilitate a community-led, industry-supported open source framework, including code and architecture, to accelerate and advance a common, robust Software-Defined Networking platform.  Some of the enterprise IT organizations I have talked to have expressed some confusion about how the mission of the consortium compares with the mission of the Open Networking Foundation (ONF).  One of the key roles of the ONF is to create standards, such as the OpenFlow standard; in comparison, the Open Daylight consortium does not produce standards, it produces code.  One place where there is potential overlap between the two organizations is that they both see themselves as producing SDN-related architectures.

As of today, the consortium has eight platinum members, two gold members and seventeen silver members.  Platinum members of the consortium pay an annual fee of $500K and provide at least ten developers.  While the commitment of the gold members and silver members is less, with the current membership the Open Daylight consortium has annual revenues of roughly five million dollars and the full time equivalent of almost ninety developers.  The bottom line is that the consortium has the resources it needs to achieve its mission.

While the expectation is that the platinum members will make significant contributions of intellectual property, anybody can contribute code and a lot of code that has already been contributed.  For example, Radware has contributed code that can be used for the detection and mitigation of Distributed Denial of Service (DDoS) attacks and IBM has contributed a version of its established network virtualization technology, called Distributed Overlay Virtual Ethernet (DOVE).  Plexxi contributed code that allows both the Open Daylight controller and higher-level applications to create and share an abstract, topology and implementation independent description of the infrastructure needs, preferences and behaviors of workloads.

Over the last couple of months, I had the opportunity to talk to a couple of the members of the Open Daylight consortium individually, and I also had the opportunity to speak to the consortium itself.  In each of these conversations the participants all stated the same mantra:  “We (the members of the consortium) will collaborate on what we have in common and provide our unique differentiation on top of that.”  We are yet to see how that will play out, but at least for now it appears as if everyone is on the same page.

The approach that the consortium is taking to the base architecture for the OpenDaylight controller is to combine two code bases that were brought together through a collaborative proposal by Colin Dixon of IBM and David Erickson of Stanford.  That’s the same David Erickson who is credited with creating Beacon, the Java-based OpenFlow controller that is now the basis of much of the current Open Daylight controller.  I recently talked with Dixon and Erickson and they stated that their goal is to take the existing contributions, shape them into the best controller possible and get a release out this year.  They hope to get this release into development networks and give people the opportunity to build applications that run on top of it.  When I asked them about the northbound API, they briefly discussed the capability that they currently have but added that “The northbound API is really really fuzzy.”  While I would have liked a more definitive answer, I appreciated their honesty.

One thing that we can expect from the consortium in the next few months is their first code drop.  Right now it is still too early to say how much of an impact this code drop will have on the industry.  Cisco, for example, has been quite clear that it will base its SDN controller on the code that is produced by the Open Daylight consortium.  Some other vendors, such as HP, are taking the approach of waiting to see what the consortium produces before committing to how they might use the code in their products.

Image credit: Thomas Nielsen (flickr)

About the author
Jim Metzler
Jim has a broad background in the IT industry. This includes serving as a software engineer, an engineering manager for high-speed data services for a major network service provider, a product manager for network hardware, a network manager at two Fortune 500 companies, and the principal of a consulting organization. In addition, Jim has created software tools for designing customer networks for a major network service provider and directed and performed market research at a major industry analyst firm. Jim’s current interests include both cloud networking and application and service delivery. Jim has a Ph.D. in Mathematics from Boston University.