Paving The Way For SDN Interoperability

The beauty of software-defined networks is that they give you the freedom to program your network, down to individual flows, based on business requirements. However, too much freedom can be overwhelming.

The OpenFlow protocol provides a rich set of control capabilities, not all of which are supported by all switches. To date, SDN applications, controllers, and switches have had to sort out feature options at run-time, which has made interoperability (and predictable operation) difficult. For example, a switch typically includes one or more flow tables, which are organized as a pipeline. Currently, applications must be “pipeline aware,” which effectively makes them dependent on specific hardware.

The Open Networking Foundation and other SDN innovators recognized that some type of abstraction layer was needed to support hardware independence, and two major interoperability enablers have been developed: Table Type Patterns (TTPs) and flow objectives. These abstraction frameworks provide a foundation for full interoperability between OpenFlow v1.3-enabled switches -- including hardware-based switches--making it safe for network operators of all types to start investing in SDN built on such hardware.

TTPs and flow objectives

TTPs are an optional mechanism for enhancing usability of the OpenFlow protocol. Functioning like a control profile or OpenFlow template, a TTP explicitly describes a logical forwarding pipeline in OpenFlow terms. A controller and switch negotiate which TTPs to use at connection time, making it clear before run-time what OpenFlow messaging needs to be supported.

TTPs can be created by SDN application developers to describe functionality they need. They also can be used by switch vendors to describe what their devices can do or by interest groups such as the ONF Open (formerly Optical) Transport Working Group to describe functions needed for specific use cases. Since each TTP has a unique name (for example, “basic overlay TTP”), switches and controllers can advertise which TTPs they support, which promotes interoperability. Switches can host TTP agents to support various use cases.

Support for TTPs is already building. For example, Broadcom’s OpenFlow Data Plane Abstraction software leverages TTPs to expose switch features via OpenFlow v1.3. ONF is working with switch and chip makers to define a set of TTPs that can be supported across many product lines.

Meanwhile, flow objectives technology abstracts the OpenFlow-level actions into application-level services that are above even the generic device level. Flow objectives are supported in the Open Network Operating System (ONOS) embedded within the Atrium 2015/A release; an upcoming version of Atrium is expected to implement a similar abstraction layer using OpenDaylight. The flow objective service is implemented above the device adaptation layer and offers services-oriented abstraction for the benefit of applications.

This summer, ONF introduced Atrium, an open SDN software distribution that integrates the Border Gateway Protocol (BGP), ONOS, and Open Compute Project components. As part of that release, we demonstrated interoperability among seven hardware-based switches (two white-box switches and five proprietary switches) all running OpenFlow v1.3 and the Atrium stack. Participating vendors included Accton, Centec, Corsa, Netronome, NoviFlow, Pica8, and Quanta.

Essentially, we showed a common application and a common control plane operating across the diverse hardware. Specifically, we built seven BGP-peering routers, all with different forwarding planes, and demonstrated them interoperating with each other. We also ran a test deployment that included the Atrium stack running on hardware in Australia peering with other Atrium-based hardware as well as traditional Cisco and Juniper routers based in the U.S.

Freedom of choice 

This kind of interoperability is a major turning point for the OpenFlow protocol and SDN in general. Customers can now buy OpenFlow v1.3-enabled switches from different vendors to meet specific use cases or network requirements (for example, provider edge, enterprise core, or data center top-of-rack) and be assured they’ll interoperate.

Likewise, SDN applications and controllers no longer need to be written to specific hardware. Based on business needs, you can decide what you want in the forwarding plane and know it will work with the software and control structure above.