Ben-Mack Crane discusses why OpenFlow needs to evolve and how ONF plans to take it through evolution.
As ONF prepares to complete its planned merger with ON.Lab later this year, we have been thinking a lot about ONF’s ongoing work, including the OpenFlow standard. I recently shared some insight with Network Computing on where OpenFlow is today and where we believe that it needs to go in the future. You can read an excerpt from the contributed piece below:
The OpenFlow protocol has been instrumental to the logically centralized control and network programmability that underpins software-defined networking (SDN). Currently, OpenFlow provides a standardized interface between SDN controllers and switches or other data paths.
However, many SDN use cases have emerged that go beyond packet switching. Efforts are underway to use SDN to support technologies such as circuit switching, optical and wireless media, and new use cases, including network functions virtualization (NFV), layer-3 traffic management, WAN gateways, and central office re-architected as a data center (CORD).
The Open Networking Foundation recognizes that OpenFlow must evolve to reflect – and continue to support – the burgeoning SDN market. Consequently, the ONF will be working on a “refactored” version of OpenFlow that focuses on core control functions while supporting a broader spectrum of data planes and programmable forwarding engines.
Why OpenFlow must evolve
The current OpenFlow specification combines control functions and forwarding engine behavioral definitions into a single standard. Consequently, the entire specification must be revised to support each new data path protocol and use case. This approach worked fine when the SDN market was getting started. But it’s too monolithic for today’s maturing market. Addressing multiple distinct issues in one specification is unwieldy, impedes market innovation, and makes it hard to identify the required feature set for each use case.
OpenFlow’s strength is its ability to control any flow forwarding technology. To better support the burgeoning SDN market, it’s time for OpenFlow’s centralized control functions to become independent of the data path and other technology details. Paring OpenFlow down to a common core will make the protocol widely applicable, and help unleash SDN’s full flexibility and programmability.
Want to know more? I discuss how to evolve OpenFlow, benefits of making it modular, and more in the full article on Network Computing.
- Ben-Mack Crane, Specification Area Director and Principle Architect at Corsa Technology
