I've been hearing about 'software defined networking' (hereafter SDN) for a while, but it's never been entirely clear just what it was and what people meant when they talked about it. Partly this is because by the time I started hearing about SDN it had already become encrusted in a thick layer of marketing and insider jargon due to being the hot new thing. I've recently been poking around some things and this is what I've gathered (after a misstep and a correction or two).

At least on a conceptual level a modern piece of network gear can be divided into two parts, the data plane and the control plane. The data plane moves packets around really fast (possibly mangling them slightly); it's usually a lot of custom ASICs and high bandwidth internal cross-connects and so on. The control plane tells the data plane where to put all of those packets and otherwise, well, controls the switch or router. At the top of the control plane is an embedded processor that handles things like SNMP, the overall device configuration, the web interface, the serial console (if there is one), and so on. On routers this processor will also handle things like OSPF and BGP routing (which means that on high end routers it's pretty powerful).

(See, for example, the OpenFlow description of this split.)

Software Defined Networking is the idea of splitting the data plane and the control plane apart and putting them on different pieces of hardware. The data plane is the core of the actual network hardware (the switch or router), the control plane runs on some general server, and the two talk to each other through (standard and open) protocols that let you replace both sides (or use one control plane server to talk to a whole bunch of different sorts and makes of network hardware). It is software-defined in the sense that the control plane software, running on your server, defines the network topology of what gets routed or forwarded where. The OpenFlow people describe this as a programmable network.

(In practice I imagine vendors sell (or will sell) dedicated 'appliance' control plane servers and software that you can just plug in and use, just as vendors today sell, eg, iSCSI appliances even though you can build your own.)

There are a number of advantages (or potential advantages) to SDN. In no particular order:

• The hardware becomes more generic, with all that implies; you'll have more choice, you can mix and match it, you can replace it in pieces, and it will probably get cheaper because vendors will lose the ability to charge extra for what are basically control plane features.

• Central management of the network configuration (what I initially mistook SDN for). If you want to make a change such as adding a VLAN or changing network topology you no longer need to go off and touch a bunch of switches and routers individually; instead you can make the change centrally and everything gets pushed out from there.

• Your control plane software can do more sophisticated things (including interacting with things like your database of DHCP registrations) because it's now just software running on a server, not special firmware in a magic embedded hardware.

• You can dynamically manage how data moves through your networks based on a global view of the state of all your networks and links. In the process you have a central spot to track and troubleshoot things (and to see that global network picture).

That's pretty abstract so let me try a concrete example (based on my understanding). Suppose that you have a bunch of routed networks and a bunch of routers to route them. Today those routers probably work out network reachability (and routes) through a distributed protocol like OSPF, with each router advertising its links to its peers, building up a picture of its surroundings, and routing things accordingly. You may or may not get much insight into how your routing changes over time and what exactly happens if something goes wrong, depending on how (and if) routers log things. In the SDN future all of the routers will simply report link state information to your central control plane server; the control plane software will then build a central picture of what links are available (and possibly how much traffic is trying to go over them) and tell all of the routers how they should route things. In the process you can have the control plane software keep good track of what was going on when, what it saw, and why it made the decisions it did.

The bit of SDN that's most interesting to me is the centralized management. I eagerly look forward to a future where you'll no more log into an individual switch to set up a new VLAN than you would log into an individual server to configure an application. Artisanal hand-crafted switch configurations are as annoying as the server equivalents.

(Managing network devices and automating their configuration has been terrible for a very long time. When expect and web scraping are close to the state of the art, you are not in a good place. I'm sure you can get expensive 'enterprise' single-vendor management solutions from the big vendors, but we've never had that kind of money.)