The story of SDN: Control planes, OpenFlow protocol and disaggregation
When discussing SDN, control planes and programmability are often lumped into the conversation -- along with a dose of OpenFlow protocol and disaggregation.
Software-defined networks seem to be everywhere. In fact, according to internet legends, all the hyperscale service providers are already using SDN, or they will be soon. Vendors have jumped on the bandwagon, as well, offering a wide variety of software-defined everything -- from networks to storage to, well, everything.
The wide range of uses for the term software-defined networking, however, reflects a fundamental confusion about what SDN actually is. Often, it's best to go back in history to understand what a term meant when it was invented, and then consider how those origins might provide a better understanding of the term now.
In the old days -- which were really just a few years ago, but dogs age slower than networking technology -- networks were built of appliances. A vendor like Cisco, Juniper or Arista would sell an appliance that could be mounted in a rack, cabled in, powered on and configured. These devices certainly involved software, which could be upgraded, replaced, have bugs and fail. But the software was designed for a particular device, or a particular product line. The software was embedded.
Embedded software is somewhat fine for commercial use. But for researchers, the idea of embedded software is problematic. If you want to write a new control plane, you can reverse-engineer the physical hardware and write a new operating system that can run on that hardware from scratch. Or, you must ask the vendor for a copy of the original code -- "for research purposes" -- that you can use for experiments. Neither of these options is attractive, however. Reverse-engineering is a difficult task, if even possible, and a vendor will not likely respond positively regarding commercial source code for research purposes.
SDN, OpenFlow protocol and disaggregation
With SDN, control planes were no longer embedded in the operating system; rather, the control plane could live anywhere in the network.
But there's certainly another option. The vendor can offer an external interface that allows the researcher to install routes in the hardware forwarding table just like local control planes do -- hence, the development of OpenFlow protocol. With OpenFlow, for example, routing decisions are moved from individual switches to a separate controller that informs the switches on how to direct routes. Once something like OpenFlow protocol -- or even the idea of something like OpenFlow -- is available, however, it steers the market in a different direction.
In OpenFlow's case, the market steered toward the commercialization of systems where the hardware is just hardware and the software is disaggregated from the hardware. The appliance is broken up into its components. Many other streams of disaggregation exist in the network engineering world, but they are all similar to the SDN model in somehow breaking up the parts that were originally sold as an appliance and selling each piece as a separate component.
SDN, control planes and complexity
Why was this called a software-defined network? Because with SDN, control planes were no longer embedded in the operating system; rather, the control plane could live anywhere in the network. In fact, the larger assumption in the SDN world is the control plane doesn't run on the switching hardware; the switching function and control plane functions instead run on separate devices in the network, connected either in or out of band to one another. Thus, the centralization of the control plane functionality is built into the SDN story.
The underlying assumption, in many circles, was control plane centralization would work to reduce, or even solve, complexity. The reality, however, is far different: Complexity is not only a difficult beast to slay, but there are clear arguments for the necessity of complexity to solve hard problems. Transporting packets between two hosts might seem like an easy problem to solve, but it is actually a difficult problem. Centralization does not solve complexity so much as it moves complexity from one place to another in the network. Why not? This is a tale for another tech note.
