< back to overview

To Standardize? Or Not.

Mar 25, 2013

As the explosion of interest in SDN continues to grow, we have seen a variety of vendor and industry-association responses that reflect various approaches to the technology.

As newly developed forums and groups emerge, ONF is afforded the opportunity to reinforce the original motivation behind its formation and that of the SDN movement: to bring software programmability to networks worldwide via open standards designed to meet the needs of users.

As an organization created and driven by users, ONF is dedicated to advancing the commercial implementation of SDN through open standards development, market education, and the cultivation of a community of suppliers and consumers of the ingredient technologies. In the two years since our public launch, ONF has established itself as the industry’s recognized expert body on SDN, having already produced versions of the key foundational standards upon which SDN is built. Through its keen understanding of how networking becomes software-defined, ONF is careful about which components of SDN require de jure standardization and which do not. Over the last several decades the networking industry has grown accustomed to creating a new standard protocol for every new capability, and when this required communication between physically and geographically separate equipment it made sense, though the ad hoc way these developed has led to the “bucket of protocols” that plague networks today.

In the case of SDN, the physical separation of the control plane and the forwarding plane mandates a networking protocol for their communication, and ONF has standardized OpenFlow® for that purpose. (Along with the OpenFlow® protocol, which we continue to evolve based on market requirements, we work on the OpenFlow® Configuration protocol, conformance test suites, interoperability testing, and related matters like security, management, and capturing network state.) Having such an open standard created expressly for SDN gives IT administrators a widely-applicable and future-proof tool and frees them to integrate best-of-breed technology as it is developed. Much of the industry talks about the importance of open standards, but the reality is that in the context of SDN, OpenFlow® is the only vendor-neutral, standard protocol that provides the communication between the control and forwarding functions that is required for SDN. Its adoption already allows network operators to simplify their networks, reduce Capex and Opex, and create new services and revenue streams.

In the software layers above and within the control plane, interfaces are not and should not be the subject of standardization by committee. The software world innovates rapidly and most standards are de facto, emerging from market preference after considerable experimentation. Take, for example, the so-called Northbound API between an OpenFlow® controller and the applications above it. There are at present over two dozen OpenFlow® controllers available, and they all employ different Northbound APIs. For nearly two years we have heard – and resisted – demands to standardize the Northbound API. Our view is that there is no one right answer for the Northbound API, at least at present, and that to standardize one now would stifle the innovation that is going on in the market and that the market needs as it works out its requirements. If popular Northbound APIs emerge from any source, be it proprietary or open-source, they will reflect evolution from experience, which cannot be gained in a smoke-filled room of standards-makers. The networking industry thus has a lot to learn from the software industry and ONF is serving the users of SDN by helping to lead this fundamental change in thinking.

ONF therefore believes that it is already standardizing the essential parts of SDN that require standardization, and that the remainder should be left to the legions of software developers to try out and iterate in the market. The user community stands behind ONF in this belief.

Dan Pitt, Executive Director

Share this post:
Dan Pitt