It's easy to see the role of SDN in the data center context, where it is an adjunct to the evolution of private...
clouds and of data center virtualization generally. For years, the network has been the sticking point there, slowing or making more difficult efforts to fully virtualize, automate and orchestrate data centers. SDN brings the network fully up to speed. It separates control decisions (about how to handle network packets and flows) from actual packet handling. By putting a standard interface between the two functional units (controller and data plane) SDN simply fulfills the promise hinted at when chassis-based routers first separated controller cards from line cards. By putting an API in front of the controller, SDN makes the network fully susceptible to programmatic control, automation and orchestration.
SDN won't stop in the data center, though, and why should it? The enterprise faces network traffic challenges outside the data center as well as inside it. The most expensive gear may be in the data centers, but in most environments the bulk of the gear is not, and where an organization relies on having lots of branches, each specialized network device added to the standard "branch stack" can represent both a significant capital expense and an impediment to growth, thanks to the overhead of configuring, deploying, maintaining and operating the device in every location.
The appeal of SDN
For the WAN, then, the appeal of SDN rests as much on the ability to consolidate branch-stack services onto a smaller number of cheaper, more manageable generic devices as it does on the idea of programmatic control. Smaller stacks, because SDN allows a data-plane device to implement policies in security, optimization and other roles at the same time. Cheaper and more manageable devices, because each is essentially the same: a generic switch, in essence, without much native intelligence but not restricted in function to switching, ready to move packets according to whatever rules the controller passes down. In this way, each device requires little or no unique configuration of its own and becomes easier to maintain.
The SDN branch, then, instead of being composed of a router and unified threat management device and WAN optimizer and a DLP appliance, would contain generic data-plane devices. Each would be pretty much the same as the others, although some could be equipped for higher or lower bandwidth than others, or greater or lesser port density. They would be distinguished mainly by whether an external link is plugged into them (making it a WAN edge device), or into servers or users or some combination of the two.
Security and optimization provide two of the most compelling use cases for SDN in the WAN. On the security front, for example, a security application would tell the SDN controller things like “Subnet A cannot talk to the Internet, but subnet B can” or “No device on the desktop VLAN should be talking directly to any other; if they try to, sound an alarm.” The controller would instruct the branch devices on how to move packets by setting up flow tables and make decisions about any new flows as needed. In optimization, an application could, for example, dynamically prioritize voice packets going from data center to branch endpoint, or from one endpoint in one branch to another endpoint in a different branch, then tear down prioritizations when the call completes.
Given the possibilities for making the WAN and branch networks both more functional and less expensive, every organization with a WAN should be keeping its eyes on developments in SDN applications, controllers and switching gear, and planning to test possible new WAN architectures within the next two years.
About the author: John Burke is a principal research analyst with Nemertes Research, where he advises key enterprise and vendor clients, conducts and analyzes primary research, and writes thought-leadership pieces across a wide variety of topics. John's expertise lies within the realm of virtual networks and software-defined networking (SDN) technologies, standards and implementations.