This post is also available in: Japanese
The real question is can OpenFlow be used to build large scalable networks. To answer the question, we need to first understand OpenFlow. The ONF is responsible for the OpenFlow specification which defines the following components:
- Remote Controller
- Flow-based Switches
- Protocol between the Controller and Switches
The following picture shows the components of an OpenFlow 1.3 switch.
Figure 1 – Components of an OpenFlow Switch
The specification does not specify the number of switches controlled or the proximity of the Switch and Controller. In fact, the specification does not even tell us how to set up flows across a network. These are important points because OpenFlow does not dictate network design. Rather, it is a tool for enabling SDN (i.e. separation of control and data planes).
OpenFlow detractors like to highlight the following items as reasons OpenFlow doesn’t scale
- Number of switches managed by a controller
- Number of flows a switch can support
What’s needed is a review each of these items to determine if they are real issues and, if so, how they can be solved.
Number of switches managed by a controller
The number of switches which can be controlled by a single OpenFlow controller is determined by the number of TCP sessions and CPU performance.
Given today’s server architecture, we can realistically expect a server to handle tens of thousands of TCP connections. This indicates a single server could connect with many thousands of switches. If more connectivity is needed, then additional servers can be added to form a cluster. The number of connections should not be an issue with good connection architecture.
Current generation Intel Xeon class servers have the ability to support 2 or more processor sockets with up to 16 cores per socket, providing massive amounts of processor cycles. Intel claims a single server can handle 160 million packets per second which translates to 100+ Gbps performance. This type of performance should be sufficient to cover thousands of switches. And, when the controller is architected and implemented correctly it will be capable of scaling up as servers are added to the network.
For the sake of argument, let’s assume a single controller could only manage a thousand switches. We can then take a page from either Network Management or IP/MPLS network designs, which must also scale to large numbers of nodes. In the case of Network Management, large networks are controlled by a “Manager of Managers” design (i.e. hierarchical design). The same design could be leveraged for OpenFlow (i.e. “Controller of Controllers” model) to scale out a network as shown below.
Figure 2 – Controller of Controllers
Another approach is to take the lesson from the IP/MPLS networks where Autonomous Systems become peers as shown in the following diagram.
Figure 3 – Autonomous Systems
In this case, the OpenFlow controllers would peer with each other using a peering Protocol. This type of design is used today to interconnect worldwide IP networks.
While the use of hierarchy and peer-to-peer networking can be used for scalability, other approaches similar to current Web Scale database technology could also be used to scale out an OpenFlow controller. These are proven techniques that allow enterprises to support millions of customers today. The point is that a proper network and controller architecture is the key factor for scalability, which is not, in fact, limited by the OpenFlow protocol.
Number of Flows Handled by a Switch
The number of flows a switch can handle is limited by the size of its flow table. OpenFlow 1.0 specifies a single flow table for the switch must match on 12 fields. Because of this requirement, most early implementations used a ternary content addressable memory (TCAM) for the flow table. These TCAM-based tables were limited to just a few thousand entries. If the table was exceeded, the packets would be handled by the switch’s software. This severely limited the scalability and performance of early OpenFlow switches. Many of these scalability limitations have been resolved by using existing lookup tables when matching strictly at L2 and L3.
The ONF recognized the scalability issues imposed by having a single flow table and, with the OpenFlow 1.1, they introduced the concept of multiple flow tables. The specification went even further and allowed each different flow table to match different fields. This flexibility provides a pathway for more flows per switch, as TCAMs could be replaced with large lower cost RAM devices.
The ability to move away from the TCAM limitation allows switch designers to now scale their data plane for targeted applications while still supporting OpenFlow control. For example, a switch typically used to create MEF Carrier Ethernet services requires the ability to match packets on ingress port and VLAN ID. This can now be implemented using OpenFlow 1.1 with direct memory access to a large RAMs, which is consistent with how today’s Carrier Ethernet Platforms operate.
Modern switches and routers support forwarding information bases (FIB) in range of 64K to 512K entries. With OpenFlow 1.1, a switch can now use these same FIB tables for flows managed by an off-board controller, which alleviates the second concern about the number of flows a switch can support.
OpenFlow – It Can Scale!
So the answer is “yes!” With proper network design and intelligent controllers, OpenFlow can be used to build very large networks.
Guide to Acronyms:
FIB – Forwarding Information Base
MEF – Metro Ethernet Forum
MPLS – Multi-Protocol Label Switching
Check out more from Contributors on SDNCentral:
- How Message-Bus Event Processing Created an Agnostic SDN Solution
- Talking Turkey: A Snapshot of our Network Virtualization Pilgrimage
- Using Overlay SDN to Integrate Public Cloud Environments
- NFV, NV, and SDN: Past the Vernacular, Getting to the Spectacular
- There’s a Context for That: How Smartphone Apps Relate to SDN and NFV
CONTRIBUTED ARTICLE DISCLAIMER:
Statements and opinions expressed in articles, reviews and other materials herein are those of the authors; the editors and publishers.
While every care has been taken in the selection of this information and reasonable attempts are made to present up-to-date and accurate information, SDNCentral cannot guarantee that inaccuracies will not occur. SDNCentral will not be held responsible for any claim, loss, damage or inconvenience caused as a result of any information within this site, or any information accessed through this site.
The content of any third party web site which you link to from the SDNCentral site are entirely out of the control of SDNCentral, and you proceed at your own risk. These links are provided purely for your convenience. They do not imply SDNCentral’s endorsement or association. The copyright and any other intellectual property right any third party content belongs to the author and/or other applicable third party.