- Sales & CRM
- Business Intelligence
There’s a new bandwagon in town known as Software-Defined Networking (SDN), and even though I don’t spend much time looking at infrastructure these days, I still need to get what it means. So I Google, of course, and face the usual raft of marketing materials and media reports that seem to do everything but say what the thing actually is.
According to the InterWeb, SDN separates the data plane from the control plane in network equipment, enabling policy and configuration commands to be delivered remotely, from a separate controller. This definition leaves me a bit bemused, particularly when reports suggest that, traditionally, such commands have needed to be configured on each network box individually.
Wow. If that were really the case, goodbye Internet, given the overheads that would cause! And goodbye telecommunications networks as well, at least had vendors from Cisco to Alcatel (my old employer) not been tackling exactly this problem many years ago. Indeed, as well as building proprietary consoles for centralised management, there have been many ‘waves’ of innovation on this subject, including for example Cisco’s Application-Oriented Networking or indeed, 3Com’s inclusion of a processing board in a switch.
So, what really is new? To understand this we need to delve behind the marketing and see what’s going on. The term SDN was coined following a Stanford University initiative to develop a more open framework for network device control. Known as OpenFlow, the idea was to enable different network elements from different manufacturers to be controlled from the same place.
But – here’s the difference – the devices would talk the language of the controller, rather than expecting the controller to understand how to talk to the device. Pundits are talking about "network APIs" to control network devices, as opposed to the proprietary control standards prevalent today. OpenFlow may not be the only game in town, but it’s currently the biggest.
This architectural tweak could have a pretty fundamental impact on how networks are designed and built. It does, in essence, commoditise network elements to greater extent than previously: this may be a scary prospect for the device manufacturers, but hanging on to revenues by preserving proprietary interfaces has never been a great long-term strategy.
Reduced proprietary control means more flexibility as organisations become able to consider running applications across equipment from different providers
Meanwhile, it suggests advantages to those trying to innovate up the stack – notably companies supplying dynamic resource management capabilities, such as VMware (who acquired SDN specialist Nicira last summer) and service providers such as Google (who is migrating across to SDN as we speak).
Reduced proprietary control means more flexibility, at least in principle, as organisations become able to consider running applications across equipment from different providers. One such "application" is a virtual network, which can decide on the appropriate route to send data through a physical network more easily than if dependent on pre-configured networking resources.
In practice, management of network resources has always been a can of worms, and this is unlikely to change. Equally, the amount of legacy equipment, complexities of existing rules, budget constraints, security challenges, vendor-linked channel models, ROI questions, training issues, all of these will put the brakes on any wholesale change.
We’re bound to see various vendors jumping on the SDN bandwagon, enormous claims of potential money savings, analyst attempts to size markets, discussions of business agility, predictions of brave new worlds and general media excitement in equal proportion – the industry loves a bandwagon. Behind it all however lies a subtle yet very important break with networking’s proprietary past, which should be seen as most welcome.