An In-Depth Look at Software-Defined Networking

The Joint Path: Vendor and Open Source SDN

As some of the above businesses and other parties move toward proprietary NaaS solutions and other SDN implementations as commercial services, the open source community is also taking a hard look at software-defined networking through a new project called OpenDaylight.

Pioneered in 2013, the OpenDaylight project is hosted by the Linux Foundation, and supports open-source collaborative work on software-defined networking and network functions virtualization progress.

While OpenDaylight supports OpenFlow, it also inherits aspects from the proprietary code bases of big tech companies like Cisco that traditionally offered network switches and other gear.

In a blog post about OpenDaylight, Tom Nolle, president of CIMI Corp., makes three points about software defined networking – first noting that OpenFlow as a protocol is available to achieve SDN goals – secondly, pointing to a central mechanism for packet forwarding or routing – and thirdly, calling for a service conception around that control infrastructure.

“In the SDN world, we’ve seen a polarization of solutions based on which of these points are most important,” Nolle writes. “Can you build 'SDN' if you can create services—'Networking-as-a-Service' or NaaS—regardless of how you do it? Can you do SDN without central control, without OpenFlow? All valid questions, since buyers of next-gen networking will buy or do what is useful to them, which might be any or all of these things.”

Calling OpenDaylight a “mind-opening experience,” Nolle portrays this new standard as a controller model that opens up network protocols and diversifies the types of legacy devices supported.

This type of progress is another aspect of how SDN is “taking over” the networking world, and why traditional, static networks in individual hardware rooms might soon be a thing of the past.

For an interesting look at proprietary systems and OpenFlow, it's helpful to go back to the example of Cisco, a top provider in the space, and Cisco's campaign to develop what it called OpFlex several years ago.

In 2014, tech media outlets were churning out articles differing over whether OpFlex was an “OpenFlow killer” or not.

“Cisco’s OpFlex protocol is intended to maintain control intelligence in the network infrastructure itself instead of centralizing it in a separate controller, which is the essence of the OpenFlow control/forwarding decoupling model,” Jim Duffy wrote in Network World that April, further explaining that Cisco was “reinventing the OpenFlow wheel, proposing a new protocol where one already exists, though its objective is different.”

Michelle McNickle at TechTarget pointed out that OpFlex was “meant to be embedded in the device or host via the policy agent.”

Experts pointed out how OpFlex proposed a different connection to Application Centric Infrastructure (ACI) than what was already available with OpenFlow.

This case study shows how the two different kinds of systems have collaborated in offering software-defined networking alternatives as SDN progresses.

Share this:
Written by Justin Stoltzfus
Profile Picture of Justin Stoltzfus

Justin Stoltzfus is a freelance writer for various Web and print publications. His work has appeared in online magazines including Preservation Online, a project of the National Historic Trust, and many other venues.

 Full Bio