Table Type Patterns (TTPs) Simplified

There is a new idea on the horizon for faster adaptation of OpenFlow (OF) by different network devices or nodes. It is called Table Type Patterns (TTPs). Forwarding Abstractions Working Group (FAWG) of Open Networking Foundation (ONF) is the responsible body for TTPs. But before understanding what TTP is, let us try to figure out what exactly TTP is trying to achieve.

Network devices provide forwarding, routing and many other services. But these services can be viewed as collection of some primitive network functions which affect/alter the packets during their journey inside the device. These primitives such as VLAN tagging, TTL decrement etc needs to be mapped to the ASICs to support a specific pipeline on the device. Pipeline is nothing but the path of the packet through the device before it is forwarded via an output port. For example L2 switching can be explained as a pipeline which is mapped to the switch ASICs.

The development of ASICs were always dependent on the protocol development in L2 or L3 layers to support the corresponding pipeline on the ASICs. This makes the data plane development as protocol dependent. Also every ASICs may have their own proprietary implementation of these network primitives. OF tries to define these primitives in vender independent manner using its own primitive as TABLES. Theoriticaly OF can make the ASICs development as protocol independent. If a device supports OF, then it should be able to configure the data plane to support any protocol using OF primitives only. Each primitives can be defined as a Table in OF which need to be mapped to ASICs. OF1.0 started with support of one table and was adopted by many network vendors as mapping single table pipeline was somewhat easier on ASICs.

Pipeline term is used while explaining internal switch architecture. Pipeline describes the path a packet takes through the hardware. It refers to the internal steps each packet has to follow before it leaves the device. For example almost every packet has to follow some basic steps such as to update L2 header , to identify next-hop, to decrement TTL etc.

But OF1.3 starts supporting multiple tables. OF1.3 specifies that multiple protocols can be supported using multiple tables such as one table for VLAN tagging while another for ECMP and it also specifies how the tables interact among each other. This results with numerous pipelines in OF1.3 which makes it difficult to map in entirity to ASICs. But software switches can reconfigure itself to support complete set of pipelines of OF1.3. The current problem can be defined in two ways.

Firstly consider that an OF agent on switch need to configure the data plane depending on the instructions from controller. OF agent may fail if the ASIC doesn’t support the required number of tables or it doesn’t have required resources available. This results in incompatibility among the controller and the switch. These kind of situations can only be identified at the runtime. Currently each pipeline needs to be mapped with ASIC with careful consideration of the supported ASIC features. There is no inherent mechanism to identify if a specific OF pipeline can be supported on the ASIC. To address this issue, we need a negotiation process to validate the pipeline supported by the network nodes and controllers before they start working together.

Secondly there need to be a clear definition of what features of OF is supported by controller and OF nodes such as types of messages, number of tables etc. before runtime. Then if a controller and a switch agree that they support a pipeline then they are compatible and they have to use only the predefined control messages and tables defined for the pipeline. This restricts any new surprise control message from controller to nodes restricting any unexpected behaviour.

It is not necessary to support complete set of OF pipelines. We can define some constrained pipeline with clear definition of supported OF messages, tables etc. Then if a controller and a switch specify that they support a specific constrained pipeline then they are compatible and they use only the predefined control messages and tables defined in the constrained pipeline. This constrained pipeline definition is vendor agnostic. This constrained pipeline can be considered as a Table Type Pattern (TTP). TTP tries to address the two issues explained above.

TTP tries to define set of pipeline (constrained pipeline) undertaking all kinds of flow mod messages necessary into account. Each specific use case or multiple use-cases in OF1.3 can be defined as a TTP. Hardware devices will be programmed to support a specific TTPs with clear details about the number of tables, types of messages and how the flow entries across tables interact. To remove the runtime uncertainty, switches should be configured beforehand instead of configuring at runtime. Hence at runtime only the flow entries will be updated. This way the devices are agreed to support specific features with predefined OF messages. This clear definition of network primitives allow better interoperability among different SDN controller and network devices. It is the responsibilities of network vendor how to support the TTP over the ASICs. Similarly the developers are responsible to support the TTPs in their controller. This leads to a more flexible development of both data plane and controllers where TTPs are considered as reference. The streamlined predefined behaviour of controller and network devices allow to develop better testing profiles targeting TTPs. Hence testing OF devices and controller will be more easier.

In a more general way we can say that TTPs are nothing but data path models defined by using a specific language specified by FWAG. Currently the OF1.x can be supported by TTPs. But in future we may need a different type of data model than TTPs to support new OF protocol versions. Hence a more general congregation of data path models is defiend which is knows as Negotiable Datapath Model (NDM). TTP is one type of NDM.

Some important points about TTP:

SDN controllers and switches will work perfectly together if they support same TTP.
TTPs needs to be negotiated by controller and data plane using OF config protocol.
TTPs don’t have any importance after a switch and controller negotiated a TTP.
Only the OF messages defined in TTP will be valid after a TTP becomes active.
TTPs are predefined pipelines. Switches and controllers are configured before runtime for a specific TTPs.
Each logical Switch supports only one type of TTP at any instant. If a switch supports multiple logical switch, then it can support multiple TTPs each per one logical switch.
Controllers can support multiple TTPs.
Controllers will only use OF messages defined in TTP with the corresponding logical switch.
TTP doesn’t add any new functionality. It just defines a subset of features of OF to define specific use cases of OF like VID mapping L2 switch, VXLAN Gateway etc..
TTPs allows the creation of accurate test profiles due to the clear definition of features supported.
TTPs are described using JSON currently.
TTP is the first generation Negotiable Datapath Model (NDM).