Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

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.

Next Steps

SD-WAN can help SDN transformation

Why DevOps and SDN differ

SDN moves to the LAN

This was last published in September 2017

Dig Deeper on SDN architecture

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Why do you think complexity is inherently part of networking?
Cancel

-ADS BY GOOGLE

SearchNetworking

SearchEnterpriseWAN

SearchCloudProvider

SearchUnifiedCommunications

SearchSecurity

SearchDataCenter

Close