Software Defined Networks: You Keep Using those Words…
Software Defined Networks (SDNs), are everywhere, and everyone is either building one, selling one, or using one. Everyone, that is, except—probably—you. Don’t feel too bad if you’re feeling left out, because it’s hard to know, precisely, what you’re actually being left out of. After all, can you actually define what an SDN is?
“Oh, I know—it’s a network that uses a software based control plane, rather than a hardware based control plane!” But—the first CGS and AGS routers, built by Cisco, and every router since, have had some sort of general purpose processor on board that ran the control plane. The control plane that was, by the way, written in C, compiled, and then run as an application in user space for the network operating system. Every implementation of every routing protocol is actually software running on a general purpose processor, so every network deployed today, under this definition, is a software defined network.
Okay, so maybe that definition doesn’t work—let’s try another. Maybe an SDN is— “a software based centralized control plane that distributes forwarding information to each network device.” There’s one small problem with this definition, though. When I first started in networking, I was installing TN3270 terminal emulation cards in Zenith Z100’s. The Burris mainframes, back then, had front end and remote processors that could “route” traffic from terminals and terminal emulators, as well as other devices (tape and magnetic storage decks, for instance) into and out of the processor. Another system I worked on for a short while, the telephone network, had a centralized control plane of this type called SS7.
So if centralized control plane and software based control plane don’t cover the meaning of SDN, then what can we say is the real meaning? Perhaps it doesn’t need to be different—it’s okay for SDN to just mean “something we’ve done before, but we’re trying it all again.” But this really isn’t the problem we face at all, is it? In reality, SDN has come to mean:
- An overlay with software based switching controlled by a centralized controller
- An entire data center with hardware controlled by a centralized controller
- Groups of physical devices federated into a single device at a controller
- Centralized topology gathering and distribution combined with distributed best path calculation
- Distributed route calculation with policy provided by a centralized controller
It’s no wonder the average engineer finds SDNs so confusing—sprinkle a little on just about any offering, and “boom,” it’s somehow “cool” (or “hot,” or whatever). How can we wade through this morass of marketing and really understand SDNs, where they’re valuable, and where there's a hype?
Perhaps it’s time to build a model that will help clear the air a little. There are, in fact, two specific questions we can ask about any control plane technology that will help sort out fact and fiction. To understand the questions, though, we need to understand the context.
In my next post, then, I’ll start with the context—a short overview of how routers and switches are put together. From there we can figure out how to understand software defined, and what the fuss is all about.