The Open Networking Foundation (ONF) is the organization that is most closely associated with the development and standardization of SDN. As of September 2015, the ONF had over 140 members. Given its size and its tight association with SDN, in order to understand where we are with the evolution of SDN we have to be able to answer the question: What is the ONF currently doing to drive SDN adoption?
OpenFlow development and use
Most networking professionals associate the ONF with the OpenFlow protocol. That’s reasonable because OpenFlow was developed at Stanford, with v1.0 published at the end of 2009 and v1.1 at the beginning of 2011. In March of 2011, the ONF was created and the intellectual property rights of OpenFlow were transitioned to it. Part of the oft-stated vision of the ONF is to make OpenFlow-based SDN the new norm for networks.
While the ONF is bullish on the future of OpenFlow, not everyone in the industry is. In a recent blog, Dan Pitt the executive director of the ONF addressed the future of OpenFlow. According to Pitt, “OpenFlow is the standard southbound protocol designed for SDN and it is vendor neutral. Nothing else is. It’s now appearing in chipsets, white-box switches and branded switches, in addition to the hypervisor switches where it’s been pervasive. With forwarding and control separate, OpenFlow-based switches offer amazing price-performance, while separate control software allows operators to tailor the network’s behavior to their business priorities. This, of course, is the goal of SDN.”
In that blog Pitt went on to discuss some of the large, highly visible current implementations of OpenFlow, including:
- Google’s replacement of its worldwide data-center interconnection network with a pure OpenFlow network;
- Google’s use of OpenFlow within their data centers;
- AT&T’s use of OpenFlow to configure the Open vSwitch (OVS) that it uses in its universal customer premise equipment (uCPE);
- Alibaba, the Chinese e-commerce giant whose business exceeds the combined total of all the big US e-commerce companies, uses OpenFlow within its hybrid SDN cloud network.
In order to accelerate the adoption of OpenFlow, the ONF continues to drive OpenFlow conformance testing and certification. One of the goals of testing and certifying OpenFlow is to get to a state where users can get a controller from one vendor and switches from another. However, in a recent conversation I had with Dan, he said that we haven’t reached that state yet, and that — at least in the short term — network organizations that implement an OpenFlow-based SDN solution need to buy the controller and the switches from the same company.
The proliferation of open source
During my conversation with Dan he said that he thought that the growing interest in SDN-related open source projects would accelerate the adoption of SDN. His belief in the importance of open-source-based solutions is the reason why in February 2015 the ONF launched an open source community and code repository called OpenSourceSDN.org. The role of this community is to sponsor and develop open SDN solutions in order to provide greater adoption of open SDN. According to Dan, the work of OpenSourceSDN.org is complementary and interoperable with work being done by open source organizations such as OpenDayLight, ONOS and OPNFV.
In June of this year the ONF announced Atrium, one of the programs that falls under the OpenSourceSDN.org umbrella. One of the issues that Atrium is designed to address is that most open source initiatives are stand-alone activities. Atrium’s mission is to integrate existing open source solutions and to possibly add some additional functionality with the goal of responding to user-defined use cases.
Atrium issued its first release, called Atrium 2015/A, in June of this year. Some of the functionality included in that release includes:
- a BGP peering application that runs on ONOS and includes the Quagga BGP stack;
- a collection of OpenFlow v1.3 device drivers, meant for talking to vendor equipment with different hardware pipelines;
- an Indigo OpenFlow client along with other support for white-box switches;
- a full testing suite for functionality tests.
The group intends a second release in December of 2015. That release will include porting the first release to run on open source SDN controllers developed by the OpenDaylight project.
One of the things that I enjoyed most about my conversation with Dan is that he didn’t try to oversell me on the current and near-term adoption of SDN. What he did do was to discuss a number of topics that enabled him to lay out his vision for what has to happen in order for SDN to become a mainstream architecture. In future blogs I will touch on a number of those topics including the interest that network professionals have in using OpenFlow and a discussion of multiple open source SDN controllers. I will also analyze another one of the programs that falls under the OpenSourceSDN.org umbrella. That program, referred to as Boulder, is attempting to develop a consensus and collaboration around a community-developed approach to SDN’s northbound interface.