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:
Raw Performance
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.
Only those flows that are not yet recognized/programmed require that step, and those will typically be the exception, not the rule.
In fairness to vendors, the challenge of flow setup performance in OpenFlow networks is well known. Vendors have a number of strategies to mitigate the potential controller bottleneck. Therefore, don't dismiss a given controller out of hand simply because of raw performance numbers.
A vendor might have a strategy that maps well to your network environment that minimizes the flow setup requirements. Among these mitigation techniques is flow wildcarding, which allows many microflows to be handled by a single flowentry.
Topology
Another consideration when evaluating SDN controllers is that of your network topology. Let's start by considering the LAN vs. the WAN. What segments of your network do you wish to software define? While the LAN, or at least pockets of the LAN, is the typical SDN use case, what happens if you wish to perform network virtualization across a WAN? How will the controller work in that model? This is largely a question of functionality. When your SDN environment becomes too large for a single controller to effectively manage, what options does your vendor offer to help you scale to the wide area network?
SDN solutions that map to the centralized controller model scale out by going sideways. In other words, you add controllers to handle additional switches. Here's the tricky bit -- how do those controllers communicate with one another? The answer to that varies by vendor.
While there are some very early discussions in the industry around standardizing how controllers will talk to one another, for the most part, solutions in this space are controllerspecific. A common federation technique uses BGP for controllers to exchange information. In this way, controllers know how to find different software defined sections of the network and forward traffic between areas. If this functionality is important to you, it's a key question to ask the vendors you are considering.
Many SDNs can stand alone under a single controller, but the notion of a centralized controller model is still a potential concern. There are two considerations. The first is how control plane traffic (i.e. instructions from the controller to network switches) is carried. In-band communications means that the control plane traffic follows the same path that all normal network traffic follows. Out-of-band (OOB) communication means a separate physical network is used to carry control plane traffic.
In band is favored by vendors who wish to learn about a break in the network topology via reachability. The idea is that, if a network device can no longer be reached by the controller, then a topology change has happened, and the controller can proceed to discover the change and make adjustments. Out of band is favored by vendors who wish to guarantee latency times between the controller and the switches, improve security, and eliminate the risk of data traffic causing control plane traffic to be lost.
In band vs. OOB network management is not a new discussion, but for the SDN consumer, it's an important point to raise with your vendors. If the controller being considered requires an OOB control plane network you don't have, that's another significant element in the acquisition process.
The second concern around a centralized controller is just how it's centralized. Centralized intelligence doesn't necessarily mean there's only one physical device or a cluster of two redundant devices that equal the SDN controller. Some vendors have spread control plane intelligence into distributed virtual machines that communicate and share a common database.
These components may report back to a central piece of controller software, but that might also be a virtual machine. Both models -- a physical controller or controller cluster as well as distributed virtual machines performing control plane duties -- exist in SDN products you can buy from vendors today.
Capability
Significantly, all SDN controllers are not equal in capability. By capability, we don't mean raw performance such as controller flow setups, but rather the actual sorts of manipulation of the network the controller can accomplish. Most network operators are not looking for merely an Open-Flow controller. Network operators want to automate the provisioning of as many of their network elements as possible, whether they are OF-capable switches or not. In that context, here are some questions to ask your vendor.
What devices will this controller talk to? You want to know if the controller can talk not only to your network switches, but also to your firewalls, load balancers, virtual switches, cloud orchestration package, and anything else that meets your business objectives. What partnerships does the vendor have? A number of SDN controller vendors have strategic alliances with popular network vendors. These partnerships facilitate communication between the SDN controller and partner appliances. That said, not all SDN partners have the same partnerships.
Therefore, it's key to be sure you understand what partnerships exist, and what fruit has come from those partnerships as you evaluate your SDN controller. What applications exist today? Some SDN controllers are like empty sketchpads. They are capable of displaying anything, but they need someone to compose a drawing on them first. Other SDN controllers have an application ecosystem that already exists -- someone's already drawn quite handsome pictures for you. Understanding the applications that exist will go a long way to determining how effective a role the SDN controller can play in your specific network.
How well documented are the controller APIs? APIs are the mechanism for getting information to and from the controller. Network applications tell the controller what they require via northbound APIs. APIs are the keys to automation and orchestration. As such, how effectively will your organization be able to leverage the controller APIs? For those seeking a turnkey solution, this will be less of a concern. But for those who wish to write custom network applications of their own, this is a crucial point. APIs being either both open to customers and well documented is not a foregone conclusion.
Openness vs. Vendor lock-in
In networking, we are comfortable today knowing that network protocols are largely interoperable among vendors. For example, BGP spoken by one vendor's device will be understood by another vendor's BGP device. Vendors might extend a protocol with a few proprietary features, but there's always a standard baseline of commonality vendors are expected to match.
With SDN, the landscape is not so stable. There is no singular way to build an SDN controller; there's no required set of features. The more you dig into controllers and their architecture, the more you discover how different they are. This is to be expected. SDN is an emerging technology, so a lot of vendors see an opportunity for differentiation and market leadership by releasing controllers that best represent their SDN point of view.
For the consumer, this lack of standardization raises some awkward questions around controller acquisition. The first is an obvious one: is this controller locking you into a particular solution? That is a really important question to answer. While a number of SDN solutions are incredibly powerful, they are solving a single problem, aimed at a specific kind of network consumer, and assume you're running a particular set of applications and network devices.
While that solution might work for you today, it can be confining for the future. Let's say a few years from now you'd like to change your load balancer vendor to reduce opex, but your SDN controller and associated applications don't work with any other load balancers. Ouch. That's a serious risk that might leave you at the mercy of your SDN controller vendor. That sort of risk might be worthwhile in the context of immediate problems it solves, but taking that risk on is a decision worth careful consideration.
Along those lines, will it be possible to migrate to a different controller? If so, how would that transition take place? On the surface, this isn't much different from any other operational consideration. For example, changing from router vendor A to router vendor B carries with it functional and operational considerations. Can vendor B's router do what you need it to do? Will your network team be able to manage vendor B's router? The answers to those questions get baked into the overall acquisition plan, and you move ahead.
With an SDN controller, a transition challenge could be a bit more complicated. This goes back to the notion of what the controller is actually doing for you. While risk of switching router vendors is mitigated greatly by standards compliance, we've already established that there's no such thing in the SDN world. Will your network applications work with a different controller? Apps written for one controller might not work on a different controller without considerable modification. While Open-Daylight can potentially change that, right now network consumers must take the time to understand SDN controllers well to know what they are locking themselves into.
In conclusion, buying an SDN controller is not a trivial exercise. Such a technology investment requires awareness of not only capability and performance, but also a strong understanding of how that controller will solve specific network problems.
You must have an intimate familiarity with your network functions before adding SDN controllers into the mix. A little research now will go a long way to preventing a large investment mistake.
Banks heads Packet Pushers Interactive. He can be reached at ethan.banks@ packetpushers.net
Read more about lan and wan in Network World's LAN & WAN section.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.