DATA CENTERS

  • 01/12/2017
    8:30 AM
    Ben Mack-Crane, ONF Specifications Area Director and Principal Architect at Corsa Technology
  • Ben Mack-Crane, ONF Specifications Area Director and Principal Architect at Corsa Technology
  • Commentary
  • Connect Directly
  • Rating: 
    0 votes
    +
    Vote up!
    -
    Vote down!

What's Next For OpenFlow

As SDN use cases expand, OpenFlow must become independent of specific applications and data-path protocols.

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.

How to evolve OpenFlow

The current OpenFLow specification defines an abstract switch model; a wire line protocol for establishing and maintaining a control relationship between an external controller and an SDN switch; protocol features for populating switch tables and retrieving information about data path operation; and a specific set of required data path protocols.

Going forward, ONF will separate OpenFlow’s core standards functions from application- and data path-specific elements. The OpenFlow specification will be revamped to specify a generic protocol for establishing and maintaining a control relationship, making it easy to establish control channels, insert entries to control flows, and acquire telemetry from the data path, for example.

 

 

The details of data path architectures and specific technologies would be defined separately in a data path model. These models can be expressed as OpenFlow table type patterns (TTPs) or as a data path program.

Benefits of going modular

Making OpenFlow modular has numerous benefits:

  • Allowing data plane and application-specific elements to be developed independently of each other and of the OpenFlow protocol will speed delivery of SDN solutions to customers by enabling developers to work in parallel on diverse products and solutions.
  • Simplifying the development process will allow a new ecosystem of players to emerge.
  • It will be easy to modify the behavior of a data path -- for example, to add new network monitoring or debugging capabilities -- without impacting the OpenFlow specification.
  • Network operators will gain greater control over network behaviors and have a broader range of software interactions with data paths, making it easy to customize SDN applications for their environment, reprogram the network, and directly manage table entries to control their own flows.

Embracing open source

In addition, the ONF is fully embracing the open source development model and community, which are key to supporting the growing SDN market.

Open source development allows for a rapid, iterative development process, which enables new capabilities to be quickly incorporated into software, code to be modified in response to real-world usage, and open source solutions being made available for a wide range of SDN use cases.

Likewise, when the open source community works collaboratively with standards bodies, a standard can be quickly implemented, tested, and propagated, enabling customers to deploy a wide range of interoperable SDN solutions.

The maturing SDN market

As SDN matures, the ONF is taking numerous steps to continue to nurture and accelerate this revolution in data networking. In addition to the refactoring of OpenFlow, the ONF is merging with ON.Lab, which is the steward of the very successful open source projects ONOS and CORD. The combined entity will focus on bringing proven, interoperable SDN products to market quickly.

Standards development will remain a critical component of this new combined entity, and the ONF community will continue to drive enhancements to the open network ecosystem, including OpenFlow and other standards developed in tight collaboration with open source projects.


Log in or Register to post comments