Data Centers

What SDN means to the network administrator

Software-defined networking is new enough that pinning down its practical use is still difficult to get our heads around. Here is some perspective on SDN from the net admin's point of view.

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.

About

Nick Hardiman builds and maintains the infrastructure required to run Internet services. Nick deals with the lower layers of the Internet - the machines, networks, operating systems, and applications. Nick's job stops there, and he hands over to the ...

3 comments
smvsousa
smvsousa

I'm completely in favor of simplifying and automating network management. Who isn't?!. I'm just not 100% sure (yet) that SDN is really the way to go. If I get it correctly SDN will decouple the control plane from the data plane and provide a single pane of management independent of the network gear underneath. However I see some challenges in here:

* Network gear still needs to be updated/managed. At least a firmware needs to be there. So, now you get 2 management points: the physical and the virtual. Are we simplifying?

* How do we get complete visibility of the network if SDN "doesn't care" about underlying hardware? How can we identify where a problem/bottleneck might be, if we don't have complete visibility from APP to hardware?

 * Cabling is still required as it is today ... and manual work will be there anyhow.

 * Increasing demand for bandwidth and lower latency will push new hardware with better performance every year. Hardware will have to be replaced or upgraded from time to time anyway.

 * One main advantage with server virtualisation was resource optimisation (most servers were running at 10% of their max capacity). This doesn't apply to networks which, in general, are oversubscribed.

Those are just a few points that let me to think that something is still missing on this SDN concept. For sure we need to simplify network management, no doubt on that. But, again, a few pieces are still missing ...


My 2 cents.

talk2sp
talk2sp

* I admire the promise of SDN* - from the below, I see a lighter concept of an Intelligent SDN " 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 " Intelligent Software Defined Network (I-SDN) will thus be a good research proposal.

ironcloudz
ironcloudz

This sounds conceptually analogous to VMware's distributed switch architecture insofar as it separates the data plane and control plane. Not a coincidence I would think...