Open Flow 1.3.1 and TTP: Enabling SDN for Carrier Networks

Nicholas Ilyadis, VP & CTO, Infrastructure & Networking Group (ING), Broadcom Corporation

Nicholas Ilyadis, VP & CTO, Infrastructure & Networking Group (ING), Broadcom Corporation

Is there a way to deploy Software-Defined Networking (SDN) in existing switch networks without having to retrofit hardware? That’s the question long grappled by the Open Flow community. The firm wanted a switch that mapped to Open Flow; the industry’s first standard communications interface between the control and forwarding layers of SDN architecture. The question was how exactly to make that happen.

Here’s a problem. Open Flow 1.0 was not designed on switches. On the contrary, it was developed by Stanford on servers. All of the data structures for forwarding data flows through a network, and being able to do look-ups and make decisions on packet flows and forwarding were basically mapped into the server memory. Since servers have a great deal of memory, it was fairly easy to create a unified table that could be used to reference the packet headers coming in and make forwarding decisions.

What the Open Flow community had contemplated; however, was a uniform model to describe an Open Flow switch; that is, a single table with entries in it that could be used to design a switch with that construct. But switches don’t have that construct; they have several different constructs. And, rather than one massive table, they are typically made out of several smaller tables that are used to look up different parts of a packet header. Switches just don’t have the same resources as servers. Porting Open Flow 1.0 to switches became a challenge and limited its capabilities on real world switch hardware.

The variability in real-world switches prompted another possibility. Rather than redesigning all of the switches in the world to fit the Open Flow model, why not just modify Open Flow to be more applicable to real-world switches?

That task fell to the Open Networking Foundation’s (NF’s) Forwarding Abstractions Working Group (FAG). It was the NF, a consortium dedicated to promoting SDN, which took over the Open Flow project from Stanford. What

FAWG came up with is a way to describe a switch in a uniform manner, such that many different real-world switches could match that description. That description, referred to as Table Type Patterning (TTP), is today leveraged in the Open Flow 1.3.1 switch specification.

A TTP essentially describes a sequence of tables that have ingress port information coming in and match fields going out (Figure 1). Open Flow 1.3.1 specifies an Open Flow switch that defines a pipeline containing multiple tables with each table containing multiple flow entries.

Perhaps the best way to understand exactly what TTP does for existing switches is to consider the analogy of a car. Imagine there was a uniform way to describe a car—as having four wheels, two of which are steerable; a steering wheel, gear shifter, and brake and gas pedals—and that this description ensured you could drive a car, no matter what kind it was, as long as it met the key elements outlined in in that description. In other words, you could get in and drive a race car, pickup truck, sedan, or even a minivan, since all of these different types of cars fit the uniform car description.

That’s essentially what TTP does for the switch. It provides a uniform description of a switch that Open Flow understands. Instead of describing an ideal switch that was developed on a server, however, it describes a real-world switch in such a manner that many different kinds of switches can fit that description. Any variability outside of that description is covered as an extension to the TTP, in much the same way that you could go back to your car description and add in features like lights or two versus four seats.

By making Open Flow understand real-world switches, TTP and Open Flow 1.3.1 provide a number of critical benefits. You can now describe a class of switches from different vendors in terms of TTPs (Figure 2). With these TTP descriptions, you can program the switches to do their job without having to worry about the underlying details; the same way you could drive a race car or minivan without having to worry about whether it has a hemi or four-cylinder engine. Ultimately that will mean greater adoption of the Open Flow standard on hardware forwarding targets and, with broad adoption of common TTPs, will come easier controller implementation.

While TTPs provide a way for Open Flow to understand real-world switches in a homogenized model, they don’t make deploying Open Flow 1.3.1 in real-world deployments quick or easy. That requires a way to map the real-world switch, with all of its different capabilities, to the TTP model. One such solution is an open source abstraction layer known as Open Flow-Data Plan Abstract (OF-DPA) 1.0. The OF-DPA basically homogenizes the underlying switch so that it meets the Open Flow 1.3.1 model (Figure 3). It essentially takes a sports car or a pickup truck and makes it look like a generic model.

There is little doubt that SDN, with its ability to manage network complexity via a network-wide software platform, will have a transformative effect on the future of networking. Open Flow, as a key example of an instantiation of SDN, is hoping to play a pivotal role in bringing that vision to reality. Now, Open Flow 1.3.1 and TTPs are doing their part to enable Open Flow on industry standard switches. With the aid of developments like the OF-DPA, these advances are helping to ensure SDN can be quickly and easily be deployed in existing switch networks without having to retrofit hardware.