The Case For SDN Table Type Patterns

The Open Networking Foundation earlier this year released a new abstraction framework -- Table Type Patterns (TTPs) -- to facilitate interoperability. Using TTPs increases the flexibility of OpenFlow software because it can dynamically learn the pipeline characteristics of each OpenFlow-based switch. In practice, customers will be able to verify that an OpenFlow switch will be supported by a given OpenFlow controller prior to purchasing either one. However, like all standards, we should expect differences in the implementation of a TTP that will have to be validated through operational testing.

In this article, I explain the reasons behind the creation of Table Type Patterns and how they work. 

Why Table Type Patterns?

OpenFlow (OF) 1.0 had one match-action table. The single table was easy to use, but it had a problem. Generating flow entries for multiple actions caused a combinatorial explosion. A simple example is handling reverse path forwarding check in conjunction with determining the forwarding interface, as described in the Open Networking Foundation document "The Benefits of Multiple Flow Tables and TTPs."

The source IP address must be checked against the routing table to make sure that the ingress interface is the best path to the source. The destination IP address must also be checked to determine the egress interface. Using one table means that it would have to support the cross product of all possible source addresses times all possible destination entries (S x D entries). Suddenly, the simple match-action table becomes unwieldly. In addition, adding one destination address would require adding entries for all possible source addresses (or subnets), making the flow update process lengthy.

The solution is to decouple match tables, but that creates another complication: Which table does what function and how large are the tables? Some tables can be an exact match, which is easy to build in hardware, while other tables need to use TCAM memory, which is expensive in terms of capacity, power, and complexity. The sequence of tables defines the packet-processing pipeline. This pipeline can be built into ASICs to make it run fast.

Each vendor’s switch may have a different set of tables in its pipeline and the tables in one switch may have more entries than in a less expensive switch. What we need is a way for SDN controller developers to determine each switch’s table pipeline. Conversely, if a hardware vendor is designing a new switch that should work with an existing SDN controller, what table pipelines will the controller support?

The exchange of pipeline information between the OpenFlow controller and switch is called a Negotiable Datapath Model (NDM). The controller and switch negotiate or exchange information about the pipeline tables, their capacity and connectivity. OpenFlow Table Type Patterns v1.0 (OF-TTP) is the first NDM implementation that has been defined by the Open Networking Foundation’s Forwarding Abstractions Working Group (FAWG). Only one TTP, identified by a unique identifier, may be used at any time between an OpenFlow controller and an OpenFlow switch. Once the controller and switch have agreed upon a TTP, only the set of flow messages defined in that TTP can be used.

Table Type Patterns v1.0

The TTP specification allows switches and controllers to be manually configured to use a selected TTP in order to allow the standards to move forward without needing the wire protocol defined. However, the controllers and switches will still need a mechanism to verify that they both support the same TTP.

A TTP may be created using encodings in JSON, XML, or YAML. The initial versions are using JSON encoding. Here is an example coding of the metadata from the OF-TTPv1.0 specification:

"NDM_metadata": {

  "authority": "org.opennetworking.fawg",

  "type": "TTPv1",

  "name": "L2-L3-ACLs",

  "version": "1.0.0",

  "OF_protocol_version": "1.3.3",

  "doc": ["Example of a TTP supporting L2 (unicast, multicast, flooding), ”,

  "L3 (unicast only), and an ACL table."]

}

The first four items in the metadata form the unique TTP identifier. The TTP with the above metadata would be identified as:

org.opennetworking.fawg/TTPv1/L2-L3-ACLs/1.0.0

The rest of the TTP definition specifies required OF features, a table map, meter table, flow tables, group table entries, PACKET_OUT actions, TTP parameters, flow paths, and security considerations. The communications between the controller and switch will typically be based on a REST- style interface.

Overall, TTPs are an example of trading one complexity for another. However, the complexity of the TTPs translates into greater scaling and improved interoperability -- that’s the goal, and how well TTPs are implemented will directly influence achieving that goal.

You can learn more about Table Type Patterns by reading parts of the v1.0 specification. It's 55 pages, but you’ll only need to read 20-30 pages, some of which you can skim. I found Appendix A, "Benefits of TTPs and the TTP Lifecycle" especially helpful in understanding the OF-FAWG’s viewpoint and objectives. It will be interesting to see how TTPs work in the real world.