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.
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.”
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.