What to Look for in an SDN Controller
One of the key challenges confronting potential users of software-defined networking is discerning the specific value of particular SDN controllers. Controllers, after all, play critical role as the key arbiter between network applications and network infrastructure.
Mon, December 02, 2013
Network World — One of the key challenges confronting potential users of software-defined networking is discerning the specific value of particular SDN controllers. Controllers, after all, play critical role as the key arbiter between network applications and network infrastructure.
Yet there's no model for exactly what an SDN controller should be, no standards an SDN controller must adhere to. Despite the advent of the Linux Foundation's multi-vendor Open-Daylight project that hopes to bring to the industry a unified SDN stack built around a modular controller architecture, there remain varying opinions among vendors as to the specific services a controller should offer. The pressure is therefore on the consumer to determine what SDN controllers are capable of, and then map those capabilities to their goals.
[ALSO:Planning for SDN]
Even in that context, it may prove difficult for a consumer to buy a standalone SDN controller. The reality is that vendors are frequently bundling controllers into the context of an entire SDN package: software applications, controller, and possibly network hardware as well. But even if you're considering a turnkey solution from a vendor, the controller's capabilities matter. After all, there's life in a software-defined network long after the initial turnkey application is old hat. Here are some things to consider:
To talk about raw performance, we first need to define the role the SDN controller is playing in this context. Traditionally, an SDN controller is the piece that allows for the decoupling of the control and data planes in a network environment. In other words, the controller tells the network devices how to forward traffic (control plane), but doesn't actually forward the traffic (data plane). This scenario is common with OpenFlow (OF) networks, where the SDN controller is chiefly used for the programming of OF tables in network devices.
In an OpenFlow network, an OF switch receives a packet and acts on it in accordance with its flow tables. But what happens if there is no matching entry for the packet in the flow table? In that case, the OF switch will send the packet to the OF controller, in essence asking, "What do I do with this?" The OF controller determines what the switch should do when encountering packets matching that flow, and programs the switch. This process is called a flow setup.
For reasons of scale, the number of flow setups per second an SDN controller can support is important to pay attention to. Traditionally, flow setups have been a performance bottleneck for SDNs, so don't take this aspect for granted. Coupling a large number of switches with a large number of microflows you wish to control could quickly max out your controller's flow setup capabilities. But, keep in mind that not every flow will require a call to the controller.