The phrase software-defined networking (SDN) was coined when it was necessary to distinguish the concept from the hardware-based variety. Since that time, "SDN" has come to mean the type of dynamic configuration that takes place whenever software-based services in a data center network are made accessible through an Internet Protocol (IP) address. More to the point, SDN is networking now.

How SDN came to be

In the third edition (1996) of his authoritative textbook Computer Networks , Prof. Andrew S. Tanenbaum provided perhaps the first "accidental" definition of SDN. "A good way to think of the network layer," he wrote, "is this. Its job is to provide a best-efforts way to transport datagrams from source to destination, without regard to whether or not these machines are on the same network, or whether or not there are other networks in between them."

Software-defined networking today is precisely this. Over the last 22 years, "machines" have become virtual entities. There are software-based constructs that communicate the way a physical machine did in the 20th century. VMware popularized the notion of a virtual machine (VM) fulfilling the same task as a physical PC or server, though entirely in software. But these VMs communicated over a real network. So, at first, hardware routers had to be reconfigured to make VMs available over a local loop. That meant network controllers and routers had to treat VMs differently from physical machines.

In other words, physical IP networking suddenly violated Tanenbaum's canonical definition: Routing had to pay attention to the route, if any packet in a network of virtual machines was ever to reach the right destination.

The solution, if there was to be one, appeared at first to involve VMware's early encapsulation of the principal functions of PC hardware, as virtual infrastructure. The first hypervisors incorporated not just the BIOS, but the NIC as well. Perhaps inadvertently, VMware demonstrated that the role of controlling the network visibility for the machine running an application, did not have to reside on hardware itself.

Yet this wasn't really the creation of SDN, just one of its major seeds. The true virtue of SDN is its programmability -- that it is truly software.

 

What SDN actually does

You can tell when software-defined networking has impacted a data center through a cursory examination of its hardware. SDN dramatically intensifies the processing ability of servers. Utilization rises, and storage is more condensed. The physical switches are replaced with radically simplified models, many of which do not carry brand names. The Open Compute Project -- started in 2011 by Facebook as an effort to drive simpler specifications for network data center hardware -- is an exercise in designing servers for SDN.Much of the logic for SDN is moved inside the servers' central processor, as just another user function. Some of it is moved inside simple switch and router appliances, where software is comprised of open-source operating systems and open-source controllers. Yet all of these phenomena are the side-effects of SDN, not the purpose. These changes happen because the real purpose of SDN is to move networking logic to a place where it can be more directly controlled and managed, and even more importantly, changed to suit the dynamics of variable workloads.

The basis of SDN

Here are SDN's principal architectural tenets:

The flow of user data is separated from the flow of control instructions. In a physical network, data packets that belong to an application take the same route as internal instructions the network components need to coordinate their actions. As SDN engineers put it, the control plane is separated from the data plane. This makes it feasible for there to be one controller in a network making routing decisions for any number of devices, rather than a plurality of devices, each of which with its own handle on the control plane, and all of them having to coordinate -- a job that requires quite a bit of messaging, which places stress on the network.

(Some diagrams show the addition of a third plane, often called the "management plane." Usually this upper tier is added by a vendor that wants to demonstrate a competitive edge. A management plane may not necessarily be a bad thing, but in actual SDN architecture, it may not really be a separate thing.)

With the data plane separated, the flow of packets in that plane may be tailored, and altered when necessary, based not just upon their eventual destination but also the most efficient route to reach that destination. When Internet Protocol was first devised, the basic job of a network device was forwarding -- passing packets on in the general direction of their respective end goals. There appeared to be a peculiar logic to it all, but there really wasn't -- and for a time, that was the beauty of it. But in a more sophisticated data center, the abstraction of the data plane gives software the opportunity to apply reason to its logic -- for example, building data flows based on security policy, rather than adapting security policy to fit unalterable data flows.

The device that controls network functions is replaced with an operating system. That network operating system (NOS) may run on a plain, zero-frills, non-branded server, such as an x86. It communicates with other components by way of an open protocol, the original and most prominent of which -- devised by the creators of modern SDN, many of whom hail from Stanford University -- is Open-flow.