07:00 AM
Terry Slattery
Terry Slattery
Connect Directly

The Case For SDN Table Type Patterns

OpenFlow-based SDN controllers and switches need to communicate with each other. Terry Slattery explains how TTPs help.

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:


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.

Terry Slattery is a principal architect at NetCraftsmen, an advanced network consulting firm that specializes in high-profile and challenging network consulting jobs. Terry is currently working on network management, SDN, business strategy consulting, and interesting legal ... View Full Bio
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
12/17/2015 | 6:30:48 PM

I'm not very clear about what you're asking, but I'll try to answer what I think is your question.

A TTP definition specifies the set of tables that are needed and the order in which the tables are to be connected. For example, a source IP address filter might be the first table (to implement RPF checking), followed by a destination IP address table that selects an output interface, and then a protocol+port table to classify packets for QoS treatment. The IP address tables may need to be implemented in TCAM to allow wild-card matching while the protocol+port table could be a simple exact-match table using less expensive memory.

The switch vendor builds the hardware to support the tables in the defined order. A switch may support any of several TTP definitions, but may use only one TTP definition per virtual switch instance. Hardware is allocated to that switch instance, configured as defined in the TTP. The controller also knows the order of the tables and loads the appropriate data (source IP address, destination IP address, and protocol+port in our example) into the tables as flows are identified. The controller and switch must agree on the tables that are needed and the order in which they are connected to properly process packets.

Tables cannot be mixed between TTP definitions. If a different set of tables are needed or a different connection order, a new TTP definition must be created. Think of the difference in the packet processing of the following devices and how the tables and their interconnects would be different for each function:

* a Layer 2 switch
* a Layer 3 router
* a firewall
* a load balancer

Each of the above devices would require a different TTP definition.

I hope this answers your question.
User Rank: Ninja
12/17/2015 | 12:48:01 AM
Thank You @Marcia for support on this, i tried google to find the answer but could not find as this case is recently submitted and is under initial stages.
User Rank: Strategist
12/16/2015 | 5:19:25 PM
That's a good question @virsingh211, I'll try to see if I can find an answer.
User Rank: Ninja
12/16/2015 | 2:36:22 AM
I could not understand the concept completely, but yes reading overview of same was good, we can manage multiple tables independently, each of which can have different capabilities in terms of the fields.. But how to diffrentiate TTPs and where it will be required. If we make TTP into smaller services, the number and complexity might increase. 
White Papers
Register for Network Computing Newsletters
Current Issue
2014 Private Cloud Survey
2014 Private Cloud Survey
Respondents are on a roll: 53% brought their private clouds from concept to production in less than one year, and 60% ­extend their clouds across multiple datacenters. But expertise is scarce, with 51% saying acquiring skilled employees is a roadblock.
Twitter Feed