Oftentimes, new trends and technologies get away from their roots. Just look at the telephone and the way millennials and younger generations use it to talk to each other without ever opening their mouths to speak. The communication is still there, but the talking – the thing the telephone was invented to do – has begun to fade.
Similarly, SDN and NFV are evolving away from their roots. Look no further than their connection to each other to see what I mean. When NFV was first introduced by 18 carriers at Mobile World Congress in 2012, it was positioned as a technology that would benefit from, but not depend on SDN. Today, the two technologies are practically married through a strong relationship between the Open Networking Foundation (ONF) and the European Telecommunications Standards Institute (ETSI). ONF is working on the first ONF-sponsored NFV proof of concept on service chaining using OpenSDN technology. With a strong liaison relationship in place, OpenSDN will now be driven by NFV use cases that will take OpenFlow beyond the data center into carrier networks and into the customer premise.
But that’s not the only way SDN is changing and not all of it is for the better. Increasingly, I’m seeing more and more OEMs talk about SDN in a way that sounds great, but is really just a perpetuation of the closed network. They’re creating a network that is more software-driven, but it still operates like a black box, keeping operators out of the networking equipment. This is appealing because it seems simpler to manage than a full SDN network, but it also reduces the benefits that SDN can deliver. Even OpenDaylight, which has a strong community behind it, might be limited on this front.
But all hope is not lost. ONF has increasingly been talking about OpenSDN, a standard that all the different OEMs can adhere to. This creates interoperability between the hardware vendors, but maintains the decoupling between data path and control path so that the programmability and flexibility that SDN promises is still available. ONF’s new reference designs for OpenSDN will emphasize both OpenDaylight and ONOS. This prevents one single entity from driving the architecture and the technology in a certain direction, hence helping maintain the community’s openness. This will also allow SDN to develop in a way that allows applications to tell the network what it needs (its intent), rather than direct the network what to do, and then let the control plane of the network determine how it meets the applications needs.
ONF has also created an open source community for code development, allowing anyone to participate. This will allow network operators to become increasingly involved and have some sense of ownership over the code, putting in the support and the man effort needed to develop it further. As the code continues to develop in this community, I expect that within 3-5 years, we’ll start seeing a healthy software community to manage the hardware without the need for an embedded solution OEM to dominate the market. This will also allow for network operators to have a heavy hand in deciding how the network behaves.
After all, SDN started in universities, where it was a very open environment. In a way, this is SDN getting back to its roots. If an open source community can do 80 percent of the work, software developers can focus 100 percent of their time on the remaining 20 percent of the code, focusing exclusively on innovation and differentiation. By sharing, we’ll move the networking field forward faster than if we create our own silos.