The real question is can OpenFlow be used to build large scalable networks. In other words, can OpenFlow scale? 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 SDN 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 SDN 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 Scale!

So the answer is “yes!” OpenFlow does scale. With proper network design and intelligent controllers, OpenFlow can be used as a SDN scalability tool to build very large networks.

Guide to Acronyms:

FIB – Forwarding Information Base

MEF – Metro Ethernet Forum

MPLS – Multi-Protocol Label Switching