Dan Pitt discusses two new abstraction frameworks to ensure interoperability for SDN.
Since the emergence of SDN, networks and their operators have become freer; SDN gives you the freedom to program your network, down to individual flows, based on business requirements. This freedom has also created the potential for greater industry interoperability. In my recent article on InformationWeek, I detail two SDN interoperability enablers – TTPs and flow objectives – and below is an excerpt from that piece. To read the full article, click here.
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.
For information about flow objectives, read the full article on InformationWeek here.
- Dan Pitt, Executive Director
