The First Glimpse of Open Daylight

Operating systems are boring (for most people); it’s the applications that make everyone excited. SDN is no different. Controllers are boring – someone has to reinvent all the wheels that the networking vendors have been inventing for the last 30 years before you can develop the sexy stuff ... but not many people outside of ivory towers would start developing the (supposedly) sexy SDN apps until being sure the underlying platform will not disappear into thin air.

It seems at least some of the major networking vendors decided we don’t need another round of operating system or browser wars (or the VHS/Betamax debacle) and joined forces to develop an open-source SDN platform – the Open Daylight SDN controller. They chose an interesting home for their project – the Linux Foundation is a perfect fit, as the Open Daylight aims to become a networking Linux.

The list of the project participants reads like the who’s who of the networking industry, but it’s very clear some companies made serious investment (the platinum members), while others decided to sit on the fence (while being very vocal about their importance in the OpenFlow world).

Somewhat baffling, the Daylight controller isn’t based on one of the many other existing open-source SDN controllers; Cisco contributed the core components of their Cisco ONE controller. Once you look at the architecture, it all starts to make sense – the crucial part is the Service Abstraction Layer, which allows individual vendors and future open-source projects to plug in modules for their proprietary protocols (example: OnePK), new versions of OpenFlow (currently available: OpenFlow 1.0), or other SDN technologies (example: I2RS).

Some of the other controllers I’ve looked at were so tightly coupled to OpenFlow 1.0 that you’d probably have to overhaul your application code just to support a new OpenFlow version, let alone another technology or protocol.

Like all recently-released software, the Open Daylight controller has REST API, but what services that API offers remains to be seen. Before getting a good look at the code and accompanying documentation, it’s impossible to tell whether the API will be abstracted enough to give us an easy programming environment (having to deal with topology discovery and end-to-end path establishment is Really Boring).

Apart from the core controller, NEC seems to be contributing its Programmable Flow virtual tenant network code and SDN Central claims IBM’s contribution includes its SDN for Virtual Environment (hopefully there’s more behind the scenes than just the Thought Leadership Whitepaper, which was the only thing I could find on IBM’s web site).

All in all, an open-source SDN controller supported by all major networking vendors sounds almost too good to be true and I’m positive there will be some posturing, bickering and backstabbing in the Daylight’s future. Based on today’s public announcements it definitely looks more like Linux than Internet Explorer, but my cynical half keeps wondering – did the networking vendors really get their act together, or is this an industry-wide conspiracy ;)

6 comments:

  1. Given your past comments, I thought you might particularly appreciate at least a part of this video from the Linux Foundation. Rainbows, unicorns, *and* bacon --- what more can you want!

    http://www.youtube.com/watch?v=ZWzMT5KLEtY
  2. Funny how they list Cisco's UCS under the SW/HW requirments :)

    source: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Overview
  3. I see four layers of extra fat on the diagram.
    What kind of problem is this going to actually solve?
    By the time a so-called App will talk to the network, there will be a new component to comply with in at least one layer...
    I get the openflow idea; SDN is how to give the power to App guys rather than Networking guys but really the OpenDaylight thingy is hard to relate to simpler/quicker/better solution
    Replies
    1. Ah, so you want your app to program the network devices directly without going through the extra fat.

      I guess you're also programming SCSI/ATA adapter on your server directly from your web app to avoid the extra fat of Linux file system and device driver.
    2. Is it fair to say that OpenDaylight can be seen as full and modular Networking Operating System for SDN?

      It looks like a massive piece of work to do only for some valid scenarios.

      When do you see Open Daylight in a position to play a role and compete with existing traditional networking solutions? If you ask which ones, I would say the 90% which are not covered by Google, FB, Amazon, and the other big SDN contributors.

      Last but not least, how IPSec would be handled in such model? Would it need to be added to Openflow?
    3. No comment. Have to see it running first ;)
Add comment
Sidebar