Curt Beckmann of the ONF Open Datapath Working Group provides an update on TTP development and how they’re accelerating the adoption of open SDN.
Table Type Patterns (TTPs) are an optional mechanism for enhancing the OpenFlow® framework. With traditional OpenFlow® (i.e., without the TTP framework), applications, controllers, and devices attempt to sort out all feature options and interoperability at run-time. Given the variability in the protocol, in network devices, and in SDN applications, attempting to resolve these details at run-time makes interoperability (and predictable operation) very difficult. This poses a potential obstacle to OpenFlow® adoption, which TTPs are designed to address. I’ll describe TTPs a bit more, then show how the architecture for deploying TTPs has become more adoption-friendly.
TTPs are an open mechanism for settling, before run-time, what OpenFlow® messaging will need to be supported. That is, TTPs are like “control profiles” or “OpenFlow® templates” with unique names that describe flow processing control in OpenFlow® terms. The TTP specification was published in June 2014 by the Forwarding Abstractions WG (whose members and responsibilities have recently been reorganized into the Open Datapath WG). When an SDN controller and an SDN-enabled device are synchronized on using the same TTP (that is, they are in agreement about things like how many flow tables will be needed, and what matches and actions are used in each table), then interoperability and predictable operation are much more assured. In addition, as awareness of TTPs grows, TTPs will be useful for conversations about interoperability. Market participants can use the TTP names as a shorthand for detailed feature sets: “This SDN app works with controllers and devices that support the ‘Basic Overlay TTP.’”
TTPs can be created by a variety of players: by SDN application developers to describe the functionality that they need; or by switch vendors to describe what their devices can do; or by an interest group, like the Open Transport WG, to describe a set of functionality needed for a category of use cases. The original architecture envisioned for TTPs is shown below:
[caption id="attachment_1812" align="aligncenter" width="300"]
Click for larger image[/caption]
In that early model, we expected that most TTPs would be use-case-based. Because devices are often capable of supporting a variety of use cases, devices would host multiple TTP agents in order to support the various use cases. While fleshing out this picture, we encountered some obstacles, each of which was annoying but not insurmountable.
1) It was hard to anticipate which use cases would be “killer apps” in SDN space
2) The use cases we did choose were tricky to define using OF1.3
3) Switch code releases may be infrequent, so switches are suboptimal hosts for evolving beta-stage TTP agents
Nevertheless, we believed it would be helpful to move forward with the TTP concept. The best way to improve the idea was to test it out and get feedback. And sure enough, after we published the spec some things happened that shifted the early thinking on the TTP architecture. Broadcom recognized the power of TTPs, and published a very rich TTP, OFDPAv2, that exposes a lot of device functionality accessible via OpenFlow. (The device pipeline represented by the OFDPA TTP has roughly 20 flow tables.) In parallel, the OpenDaylight TTP project was focused on using software to map application requests onto TTPs. That same software can map TTPs to other TTPs. Other options, such as specialized apps directly leveraging device TTPs, are still useful. Thus the revised architecture emerges:
[caption id="attachment_1813" align="aligncenter" width="300"]
Click for larger image[/caption]
This model has important advantages. Very flexible (e.g. NPU-based) devices like Device Q can still support use case TTPs directly. Other devices can host a single device-optimized TTP agent, probably the same OpenFlow® agent used when no TTP is agreed. As a device vendor, investing in a device-optimized agentless TTP is much easier than predicting which use case TTPs will be popular, then trying to provide responsive support. (“Let the controller’s auto-mapper implement the trendy TTPs on our device TTP!”) In addition, as vendors publish device TTPs, use case TTP designers can see what features are commonly supported and tailor their TTPs toward them.
This new architecture is already gaining traction. In parallel with this evolution on TTP thinking, ONF was quietly investing in the Atrium project, just demonstrated at the recent ONS conference. This ONOS-based round of Atrium also used a two-layer approach to interoperability, and involved TTPs. Although “flow objectives” (rather than TTPs) were used to represent the use case requirements in ONOS, some members of the Open Datapath WG feel that TTPs can be readily extended to include the flow objectives concepts. Similarly, some members of the ODWG are seeking to use TTPs for both layers in the upcoming OpenDaylight-based Atrium release.
To learn more about TTPs, read the ONF solution brief, join the Open Datapath WG, contact me, or come to the OpenDaylight Summit TTP Tutorial (Monday, July 27th, 3:50pm).
- Curt Beckmann, Chair of the ONF Open Datapath Working Group and Brocade's Chief Technology Architect for EMEA
