by Nicholas Ilyadis
Vice President and Chief Technology Officer, Infrastructure & Networking Group (ING), Broadcom
Software Defined Networking (SDN) is a trend that continues to garner widespread industry attention these days due to its ability to manage network complexity via a network-wide software platform. Perhaps the most well-known of all SDN instantiations is OpenFlow; the industry’s first standard communications interface between the control and forwarding layers of an SDN architecture. Originally introduced by Stanford and later taken over by the Open Networking Foundation (ONF) consortium, the technology has steadily amassed a growing community of users. And it’s those users who have helped guide the technology’s evolution through the years.
A perfect case in point is the introduction of the OpenFlow 1.3.1 switch specification. It was developed in direct response to the community’s need for a switch that mapped to OpenFlow; a capability that would help enable SDN for carrier networks. The problem was figuring out just how to make it happen. That task fell to the ONF’s Forwarding Abstractions Working Group (FAWG).
At the outset FAWG faced a key challenge: OpenFlow 1.0 was not designed on switches. It was developed on servers and that meant that 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. Servers have a significant amount of memory so it was fairly easy to create a unified table that could be used to reference the packet heade
rs coming in and make forwarding decisions.
This approach; however, was at odds with what the OpenFlow community wanted. It wanted a uniform model that could be used to describe an OpenFlow switch; 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 they are typically made out of several smaller tables that are used to look up different parts of a packet header, rather than just one massive table. 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.
Faced with this reality, FAWG began to consider another possibility. Rather than redesigning all switches to fit the OpenFlow model, perhaps it could just modify OpenFlow to be more applicable to real-world switches.
As an example, consider that when we say the word “car” today, it quickly conjures up an image of a vehicle with four wheels, a steering wheel, gear shifter, and brake and gas pedals. This uniform description ensures that you have the ability to drive a car, regardless of its types (e.g., SUV or sedan), as long as it meets the key elements specified in that description. This same type of uniform description is exactly what FAWG set out to create, only for the switch.
What it came up with is a way to describe a switch in a uniform manner using Table Type Partitioning (TTP) that OpenFlow understands and that is inclusive enough to allow many different real-world switches to fit that description. TTP is leveraged in OpenFlow 1.3.1.
A TTP is an abstract switch model that describes specific switch forwarding behaviors that an OpenFlow controller can program via the OpenFlow-Switch protocol. The switch forwarding behaviors are described via 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. Any variability in the switch that is outside of the TTP is covered as an extension, in much the same way that you could add features to the uniform car description, such as special lights or two versus four seats.
Because real-world switches from different vendors can now be described as a set of TTPs, they can be easily programmed to do their jobs, without users having to worry about any underlying details, such as how they were built or with what components. It’s really no different than being able to drive say, a sports car, without having to be concerned with what type of engine it has. At the end of the day, that means greater adoption of the OpenFlow standard on hardware forwarding targets and, with broad adoption of common TTPs, easier controller implementation will surely follow.
While the OFN’s FAWG was able to come up with a way for OpenFlow to understand real-world switches in a uniform manner, its efforts do nothing to address how to map the real-world switch to the TTP model in OpenFlow 1.3.1. And, that means deploying OpenFlow 1.3.1 in real-world deployments is neither quick nor easy.
One resolution to this dilemma comes from an industry source and it takes the form of an open source abstraction layer known as OpenFlow-Data Plan Abstract (OF-DPA) 1.0. OF-DPA essentially homogenizes the underlying switch so that it meets the OpenFlow 1.3.1 model. Or more simply put, it takes an SUV or sedan and makes it look like a generic car model.
With little doubt, OpenFlow is hoping to play a critical role in transforming the future of networking. OpenFlow 1.3.1 and TTPs, by enabling OpenFlow on industry standard switches, also aims to contribute to that transformation. Now, developments like OF-DPA are taking things one step further by making deployment of SDN in existing switch networks quick and easy. These advances bode well for enabling SDN on carrier networks, and that means network administrators will be able to roll out new services and functionality faster and with fewer errors, and more easily balance network loads. It’s capabilities like this that make SDN such a compelling answer to the complex challenges facing today’s networks and data centers.
About the Author
Nicholas (Nick) Ilyadis serves as Vice President and Chief Technical Officer of Broadcom’s Infrastructure and Networking Group (ING), where he is responsible for product strategy and cross portfolio initiatives for a broad portfolio of Ethernet chip products including network switches, high speed controllers, PHYs, enterprise WLAN, SerDes, silicon photonics, processors and security. Prior to Broadcom, Ilyadis served as Vice President of Engineering for Enterprise Data Products at Nortel Networks and held various engineering positions at Digital Equipment Corporation and Itek Optical Systems. Ilyadis holds an MSEE from the University of New Hampshire and a BTEE from the Rochester Institute of Technology. Ilyadis is a senior member of the IEEE and contributes to both the IEEE Computer and Communications Societies.
Vice President and Chief Technology Officer, Infrastructure & Networking Group (ING), Broadcom
Software Defined Networking (SDN) is a trend that continues to garner widespread industry attention these days due to its ability to manage network complexity via a network-wide software platform. Perhaps the most well-known of all SDN instantiations is OpenFlow; the industry’s first standard communications interface between the control and forwarding layers of an SDN architecture. Originally introduced by Stanford and later taken over by the Open Networking Foundation (ONF) consortium, the technology has steadily amassed a growing community of users. And it’s those users who have helped guide the technology’s evolution through the years.
A perfect case in point is the introduction of the OpenFlow 1.3.1 switch specification. It was developed in direct response to the community’s need for a switch that mapped to OpenFlow; a capability that would help enable SDN for carrier networks. The problem was figuring out just how to make it happen. That task fell to the ONF’s Forwarding Abstractions Working Group (FAWG).At the outset FAWG faced a key challenge: OpenFlow 1.0 was not designed on switches. It was developed on servers and that meant that 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. Servers have a significant amount of memory so it was fairly easy to create a unified table that could be used to reference the packet heade
rs coming in and make forwarding decisions.
This approach; however, was at odds with what the OpenFlow community wanted. It wanted a uniform model that could be used to describe an OpenFlow switch; 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 they are typically made out of several smaller tables that are used to look up different parts of a packet header, rather than just one massive table. 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.
Faced with this reality, FAWG began to consider another possibility. Rather than redesigning all switches to fit the OpenFlow model, perhaps it could just modify OpenFlow to be more applicable to real-world switches.
As an example, consider that when we say the word “car” today, it quickly conjures up an image of a vehicle with four wheels, a steering wheel, gear shifter, and brake and gas pedals. This uniform description ensures that you have the ability to drive a car, regardless of its types (e.g., SUV or sedan), as long as it meets the key elements specified in that description. This same type of uniform description is exactly what FAWG set out to create, only for the switch.
What it came up with is a way to describe a switch in a uniform manner using Table Type Partitioning (TTP) that OpenFlow understands and that is inclusive enough to allow many different real-world switches to fit that description. TTP is leveraged in OpenFlow 1.3.1.
A TTP is an abstract switch model that describes specific switch forwarding behaviors that an OpenFlow controller can program via the OpenFlow-Switch protocol. The switch forwarding behaviors are described via 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. Any variability in the switch that is outside of the TTP is covered as an extension, in much the same way that you could add features to the uniform car description, such as special lights or two versus four seats.
Because real-world switches from different vendors can now be described as a set of TTPs, they can be easily programmed to do their jobs, without users having to worry about any underlying details, such as how they were built or with what components. It’s really no different than being able to drive say, a sports car, without having to be concerned with what type of engine it has. At the end of the day, that means greater adoption of the OpenFlow standard on hardware forwarding targets and, with broad adoption of common TTPs, easier controller implementation will surely follow.
While the OFN’s FAWG was able to come up with a way for OpenFlow to understand real-world switches in a uniform manner, its efforts do nothing to address how to map the real-world switch to the TTP model in OpenFlow 1.3.1. And, that means deploying OpenFlow 1.3.1 in real-world deployments is neither quick nor easy.
One resolution to this dilemma comes from an industry source and it takes the form of an open source abstraction layer known as OpenFlow-Data Plan Abstract (OF-DPA) 1.0. OF-DPA essentially homogenizes the underlying switch so that it meets the OpenFlow 1.3.1 model. Or more simply put, it takes an SUV or sedan and makes it look like a generic car model.
With little doubt, OpenFlow is hoping to play a critical role in transforming the future of networking. OpenFlow 1.3.1 and TTPs, by enabling OpenFlow on industry standard switches, also aims to contribute to that transformation. Now, developments like OF-DPA are taking things one step further by making deployment of SDN in existing switch networks quick and easy. These advances bode well for enabling SDN on carrier networks, and that means network administrators will be able to roll out new services and functionality faster and with fewer errors, and more easily balance network loads. It’s capabilities like this that make SDN such a compelling answer to the complex challenges facing today’s networks and data centers.
About the Author
Nicholas (Nick) Ilyadis serves as Vice President and Chief Technical Officer of Broadcom’s Infrastructure and Networking Group (ING), where he is responsible for product strategy and cross portfolio initiatives for a broad portfolio of Ethernet chip products including network switches, high speed controllers, PHYs, enterprise WLAN, SerDes, silicon photonics, processors and security. Prior to Broadcom, Ilyadis served as Vice President of Engineering for Enterprise Data Products at Nortel Networks and held various engineering positions at Digital Equipment Corporation and Itek Optical Systems. Ilyadis holds an MSEE from the University of New Hampshire and a BTEE from the Rochester Institute of Technology. Ilyadis is a senior member of the IEEE and contributes to both the IEEE Computer and Communications Societies.
Got an idea for a Blueprint column? We welcome your ideas on next gen network architecture.
See our guidelines.
See our guidelines.
