Dealing with network machines on an industrial scale is a bit of a nightmare. They are big, specialized, expensive pieces of kit that cause enterprise headaches. One of the new buzz terms in the tech world is software-defined networking (SDN), which is being touted as a next-generation way to simplify networking. But what exactly does it mean and will it ease the pain?
The network administrator’s life is an endless cycle of head-scratching, grunt work, configuration, upgrades, and replacement. It’s an expensive business for enterprises and carriers.
There was no networking equivalent of the PC revolution to commoditize hardware, provide a choice of OS, and create a market of competing applications. All network machine manufacturers have developed very complicated and very incompatible systems. It’s still largely a world of vendor lock-in — an enterprise picks one supplier, such as Cisco, Huawei or Juniper, and sticks with them for all purchases.
How is SDN going to make a difference to the state of the network market? What is SDN, anyway?
Head-scratching
Many questions must be answered before buying a new network machine.
- How is the existing network laid out?
- What network bits are struggling?
- What machines are needed where?
- Since the RFPs all came back looking technically perfect for the job, which is the most appropriate network equipment vendor?
Network grunt work
When a network machine does arrive, grunt work is required.
- Get it to the data center.
- Plug it into a rack and the power network.
- Run a thick wad of patch cables from the data network to the network machine.
Configuration
Is that the end? No, that’s just the beginning. Once a network machine is installed, it needs a lot of configuration. Many Internet protocols allow many millions of IP networks to connect by providing the languages that network machines use to talk to each other. Internet protocols don’t tell the machines what their jobs are – people do. A network administrator has a lot to figure out.
- Which Internet protocols does this machine need to talk?
- What does it need to know about its neighbors?
- Where do packets arrive from and where do they get sent?
- What changes need to happen? Will putting video messages behind e-mail give better QoS (Quality of Service)? What’s a DOS attack as opposed to just a busy day? Where do activity logs go?
A network machine is a complicated computer. It has a data plane, which is all the hardware that shifts data between ports. It has a control plane, which is the software which decides what to do with data. There are so many network protocols and so many options to configure that network machine manufacturers decided long ago to use general-purpose operating systems to build on. It is just too big a job to program the whole thing from scratch.
The BSD OS is a long-time favourite for network machine vendors to build on because its permissive license means a manufacturer could do loads of work, put its own badge on it, protect its new IP by not sharing the software, and not mention BSD is in there at all.
Machine upgrades and replacement
Network machines get old and need replacing. Networks change and machines end up in the wrong place.
Every OS is updated frequently, but you can’t really do frequent upgrades with traditional network machines. When a network machine’s OS is an image on a little SD card stuck in a rack somewhere, it’s a nightmare to replace. You have to get everyone’s permission to upgrade, re-route all traffic, get to the machine and turn it off, turn it back on and figure out how to test its complicated configuration, then bring it back into service. And then sleep nervously by your mobile phone.
The promise of SDN
When you think of all this current network administration at carrier scale – telecoms companies are by far the biggest purchasers of network machines – you can sense the vast amounts of time and money all this consumes.
SDN started as a way of opening up the control plane so administrators can try changing protocols for better results. SDN has grown into a promise to take much of the pain away from that endless cycle of head-scratching, grunt work, configuration, upgrades and replacement
At the heart of the SDN approach is a pretty simple idea – make the control plane more flexible. The implication is making network machines act more like commoditized PCs.
Things in an SDN world
You put lots of stripped down network machines all around your network, which contain the data plane and a way of receiving control instructions. This collection of network machines allows you to send any data anywhere in your network. Once you’ve done the head-scratching and grunt work, these machines can stay put. You can reconfigure the whole network and these machines won’t have to be moved or re-cabled.
Each machine talks a common language for receiving instructions. The control plane is located anywhere you like — locally on the machine, somewhere in the same building, or at the head office in a network operations center. You can create push-button deployments to the whole network, change the control software on the fly, and integrate it with your enterprise applications. The constant requests and responses flying back and forth between data plane and control plane can be copied to monitoring systems, and those monitoring systems can be bought from any vendor and work with all network machines.
SDN toys to play with
That’s the idea. Problem is, it doesn’t exist yet. Progress is being made.
- This future is desired by the big network machine consumers so all the big suppliers are working hard to get products to market.
- The Open Daylight project is working on an open source framework for vendors to use.
- Companies like Big Switch have been working in the SDN market for a while now.
You can feel the benefits of this new approach in the cloud world. If you have created a firewall and load balancer, you have driven a cloud vendor’s home-grown SDN system. There may be a network appliance, or an add-on card in a switch, somewhere behind the scenes, but when you edit a load balancer or firewall configuration you are working with control software — not hardware.
That’s the idea in a nutshell. Now, we can start figuring out what real-world solutions might make it into our own networks.