Colin Dixon is part of a group of developers working on the Table Type Patterns (TTP) project within the OpenDaylight Project. TTPs are the first tangible output from the Open Networking Foundation’s (ONF's) Forwarding Abstractions Working Group (FAWG). The group’s goal is to allow for an OpenFlow controller and OpenFlow switch to agree on a set of functionalities to help manage the increased diversity made possible with OpenFlow versions 1.1+ within OpenDaylight.

Using a Q&A format, Dixon explains TTPs and their implications.

Can you tell us a bit about the Table Type Patterns proposal?

Since its inception, OpenFlow has evolved from a relatively simple way to manage one logical “flow table” (in OpenFlow 1.0 and before) to a much more capable and flexible protocol. OpenFlow now allows for managing multiple tables, each of which can have different capabilities in terms of the fields it can match on, fields it can modify and the next tables packets can flow to. Along the way, OpenFlow has also picked up the ability to work with additional protocols (e.g., MPLS and IPv6) as well as better abstractions (group tables) for handling things like ECMP, LAG and multicast.

These capabilities have made OpenFlow a much more interesting tool in two major ways:

1. Better for developers. Simply put, the new features allow developers to do more interesting things: handle IPv6 traffic, provide better multipathing, and separate logical concerns into different tables. Of course, this is all limited to software switches if hardware doesn’t expose these features via OpenFlow, and it can’t do that if OpenFlow provides poor abstractions for hardware.

2. Better mapping onto hardware. The original model of OpenFlow (a single, very flexible table) was actually a poor fit for real network hardware. The new model allows for an OpenFlow table pipeline that can much more closely match the pipelines in real networking ASICs. This allows hardware to both expose more of its capabilities and expose them to controllers (and thus developers) in a way they can efficiently take advantage of.

The crux of making these newer versions of OpenFlow (dominantly OpenFlow 1.3, since it seems that's the version with the most interest from both hardware vendors and controller developers) useful comes down to getting these two to meet in the middle. That is, coming up with patterns for using OpenFlow 1.3 that are both useful to developers and amenable to being implemented on real hardware.

This is exactly the problem TTPs are aimed at solving. Recent versions of OpenFlow implicitly create a forwarding pipeline by allowing a single packet to be processed by multiple tables as it traverses a switch. However, they define the pipeline incrementally as FlowMod messages describing the behavior of each table. This incremental definition works well for software switches which have as many tables as needed, each with whatever capabilities are required, but it works poorly for hardware switches.

With hardware switches, not only is the implicit pipeline unlikely to match the capabilities of the switch unless it’s been carefully crafted using prior knowledge, but any mismatch can crop up with a rejected FlowMod in the middle of operation. The end result is that controller-switch compatibility for OpenFlow 1.3 in multiple-table scenarios is exceedingly poor except when the controller and switch have been co-designed or pre-tested together.

Instead, a TTP explicitly describes a logical forwarding pipeline in OpenFlow 1.3 terms. This description can then be negotiated when a switch and controller connect, providing both with much-needed context about what is needed and expected. Further, these TTPs can be named, and then switches and controllers can explicitly advertise support for given TTPs, easing compatibility and interoperability.

All of this has been released as a standard by the ONF’s Forwarding Abstractions Working Group.

The goal of the TTP project in OpenDaylight is to take advantage of and demonstrate this new standard in solving real problems — in particular, enabling OpenDaylight to better use a wider variety of OpenFlow-enabled hardware switches.

What challenges will TTP overcome?

Meaningfully supporting TTPs will require overcoming a variety of challenges, but I’ll highlight two.

The first challenge is how to expose TTPs and to whom. Requiring applications or network operators to be aware of TTPs seems like a bad idea since the number of TTPs could be large and the added development or management burden would be large as well. Instead, our current thought is that network services in OpenDaylight will act as a “narrow waist” by aggregating a larger number of TTPs into a smaller number of services, all in support of a larger number of applications.

Even with this approach, the number of TTPs that a network service might have to think about could be larger than makes sense for the developers of that service. To help this, we’d like to build tools that allow for fuzzy matching between different TTPs. In particular, we’d like to be able to tell when the TTP service wants a subset of a TTP that a device offers, and do the mapping for them. This might be something we tackle a bit later on, though.

A second challenge is keeping an inventory of TTPs for developers to use. This inventory should track all of the available TTPs, the ones each network service and switch supports, the currently active TTP for each device, as well as the ones services would like most. Tracking this registry and making it usefully available to the parts of OpenDaylight that will use it is probably the most important challenge to overcome.

Who is the target audience for this?

At the deepest level, TTPs are targeted at two groups. First, developers building and maintaining network services in OpenDaylight that would like to make better use of OpenFlow-enabled hardware. Second, hardware vendors or firmware developers who would like to make switches more useful to OpenFlow controllers.

These are the people who are most likely to work with TTPs where the rubber meets the road, but we expect that nearly anyone working with the OpenDaylight controller will benefit from the features they offer.

How will TTP impact hardware/software in OpenDaylight?

At first, the TTP project will likely have limited impact on the behavior of OpenDaylight, instead providing information for OpenDaylight applications and services about the capabilities of OpenFlow 1.3. Going forward, we think that almost all network services and OpenFlow-enabled hardware will want to think about TTPs and how they will play well with OpenFlow in OpenDaylight by using them.

How will TTP interact with OpenFlow?

TTPs were designed to get out of the way after a switch and controller negotiated a TTP. As a consequence, they only explicitly affect the negotiation that happens at first connection. However, the negotiation implies that only a subset of the possible OpenFlow messages should be valid after a TTP becomes active. Going forward, enabling the TTP project to verify that these promises are kept would be useful in preventing bugs and ensuring compatibility.

It’s also worth noting that in the short run, devices capable of TTP negotiation may be somewhat uncommon and so we’re also exploring ways to negotiate TTPs out-of-band by manual configuration, inference based on the switch model and vendor, or other mechanisms.

For those looking to get involved or follow the project’s progress, what do you recommend?

Please join our mailing list, [email protected], by going to lists.opendaylight.org and following the link for ttp-dev. You can also participate in the ONF side of things by attending the FAWG meetings most weeks on Wednesdays at 9:00 a.m. Pacific time. Since these meetings are run by the ONF, you’ll need to first make sure you or your company is a member of the ONF. Lastly, the most compelling project I’ve seen to provide TTP support on real hardware is Broadcom’s OpenFlow Data Plane Abstraction (OF-DPA), and you can find and contribute to that on GitHub here.

If you really want to get involved, you can grab the code here.

Additional resources for learning about TTPs?

The best place to start would be the OpenDaylight wiki page, and the project proposal page has good information including links to slides, talks, and specifications concerning TTPs.