Software-defined networking (SDN) is a hot topic, but like many emerging technologies, the concept is subject to many interpretations. Product companies are going to war to define what this term means and what it will do. Unfortunately, the core concept behind the idea often gets distorted or revised in the process. This brief overview of SDN is intended to help you cut through the rhetoric.
Through the history of Ethernet and the Internet Protocol (IP) there has been the need to create virtual networks and control their behavior. Virtual network approaches such as VLANs and IP encapsulation allow us to segregate systems that run on the same physical infrastructure. We put in rules (Access Control Lists) between these virtual networks, and in many cases we put in manual route/switch entries for specific types of traffic (encapsulation or source route bridging). The problem is these approaches don't scale in highly virtualized environments.
At the most basic level, SDN is a way to centrally create, manage and apply these customizations to your entire communications infrastructure. If you moved your e-mail servers from one data center to another, it's likely you would have to reprogram all the network infrastructure at the new location before the transfer. You might take on this manual effort for a one-time move, but what would you do if you wanted your email system to dynamically relocate itself? Conceptually, an interface between your email system and the SDN could move the servers and the network rules together without all the manual router/switch configuration. This is a long way off, but it helps to understand the potential of SDN.
While each vendor is going to tell a different story about SDN, there are three attributes that generally constitute an SDN deployment. First is a central mechanism that provides control over the network infrastructure (usually called a controller). It can be as simple as a single server or as complex as a distributed cluster of systems, but this mechanism is outside the routing algorithms and device-specific embedded operating systems. Second is a method for the controller to communicate with the devices participating in the SDN. This communication can be in-band or out-of-band, depending on how the SDN being implemented. The OpenFlow protocol is most commonly associated with an SDN, but it's not the only option. Third is the ability for all of the devices participating in the SDN to change their behaviors based on communication with the central SDN controller. The types of control and features that are available on specific device types and products is where the vendors have different opinions.
Another key challenge that SDN solves is the route traffic takes through the network. Corporations, carriers and cloud providers have been fighting to control their traffic flow for years. How do I keep my traffic destined for Malaysia from passing through China? How do I have my data center in Chicago and Las Vegas on the same VLAN while keeping the route of the IP encapsulated data on the special low-latency communication links? If those links fail, can I route the IP traffic over whatever other link is available? One of the key features that make SDN so effective is that it is not restricted to Ethernet VLANs and the IP protocol. The concept can be applied to other Layer 1 communication protocols (think re-allocation or dynamic multiplexing of DWDM links).
SDN is emerging as a hybrid of the concepts of centralized vs. distributed control of the network. SDN is not central control of every routing/switching decision; it is more of a "meta" control with the ability to handle fine grained control in one part of the network without controlling every part of the network. It has the potential, for example, to allow simple time-of-day changes to a route table. Or it could enable sophisticated pricing and demand based control of traffic routes and resources. Imaging putting in the pricing rules for your Internet and cloud providers and having your network change your traffic flows based on real-time demand, not just route failures or congestion. This capability is also a long way off, but SDN could make this a reality.
Like many problems with the Layer 1, 2 and 3 communications protocols, it is hard to work on them with a large installed infrastructure. You just can't talk about changing the way IP works without dealing with the amount of equipment that would have to be changed. Thankfully, SDN partially sidesteps this problem by focusing on new protocols such as OpenFlow to control and manage the distributed decision-making in the network. Many networking vendors support OpenFlow or have pledged to, which makes SDN adoption possible without the need to abandon your installed equipment base.
IP routing protocols have been so static that no one could mess with them. SDN allows experimentation and innovation at a higher level that reaches down into the basic routing/switching decisions that are made in public and private networks. I personally look forward to this hybrid approach and the flexibility that it will bring to the network.
Ken Miller is data center architect with the IT Infrastructure and Operation Services division of Midwest ISO, developing mission-critical facilities.