THANK YOU FOR SUBSCRIBING
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 OpenFlow community. The firm wanted a switch that mapped to OpenFlow; 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. OpenFlow 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 OpenFlow community had contemplated; however, was a uniform model to describe an OpenFlow 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 OpenFlow 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 OpenFlow model, why not just modify OpenFlow to be more applicable to real-world switches?
That task fell to the Open Networking Foundation’s (ONF’s) Forwarding Abstractions Working Group (FAWG). It was the ONF, a consortium dedicated to promoting SDN, which took over the OpenFlow 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 OpenFlow 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. OpenFlow 1.3.1 specifies an OpenFlow 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 OpenFlow 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 OpenFlow understand real-world switches, TTP and OpenFlow 1.3.1 provide a number of critical benefits. You can now describe a class of switches from different vendors in terms of TTPs. 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 OpenFlow standard on hardware forwarding targets and, with broad adoption of common TTPs, will come easier controller implementation.
While TTPs provide a way for OpenFlow to understand real-world switches in a homogenized model, they don’t make deploying OpenFlow 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 OpenFlow-Data Plan Abstract (OF-DPA) 1.0. The OF-DPA basically homogenizes the underlying switch so that it meets the OpenFlow 1.3.1 model. 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. OpenFlow, as a key example of an instantiation of SDN, is hoping to play a pivotal role in bringing that vision to reality. Now, OpenFlow 1.3.1 and TTPs are doing their part to enable OpenFlow on industry standard switches. With the aide 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.