Original URL: http://www.theregister.co.uk/2013/06/18/datacentre_sdn/

Let the software run the network

Go configure

By Danny Bradbury

Posted in Data Centre, 18th June 2013 00:16 GMT

Across the IT industry, vendors are increasingly looking at defining datacentre operations in software.

Whether it is VMware with its software-defined datacentre concept or Microsoft with its Virtual Machine Manager product, they are bringing home the benefits of abstracting key datacentre functions away from the hardware.

Software defined networking (SDN) is one of the most recent developments in this process. How does it work?

As technology cycles speed up and demands on datacentre networks increase, it is becoming more difficult for networking teams to maintain performance without escalating costs.

Can't get the staff

It is all very well raising the hardware budget to cope with user demand, but if you don’t have the people to manage that hardware it can make the challenges worse.

As more devices are added to the network, management becomes more complicated. Admin staff find themselves logging into a panoply of command line interfaces to configure different routers, switches and other devices.

The management costs may be considerable: ITCandor, a tech market analyst firm, estimated that datacentres spent almost half of their budgets on internal staff in the year ending June 2012. Proliferation can also create security problems by making it harder to configure devices with the same policies.

This is where SDN comes in. The technology changes the way networks are configured and operated by separating out the control plane from the data plane.

Usually, networks mix data with the forwarding instructions needed to send it. The same devices that deliver the data packets, such as switches and routers, also handle the control packets.

So a switch not only has to deliver vast quantities of application data but also understand and manage the rules for sending it. And admin staff, in turn, have to manage the switch or other device.

SDN changes that by separating the two. The control information that defines how the network operates is communicated on a layer that is separate from the data delivered between nodes and applications.

In practice, this means the devices delivering application data have to worry only about that task. The policies for operating the network, along with information about its current state, are centralised and managed by a single device.

The idea is to configure a range of network services from a central point, including not only routing but also security, access control, bandwidth management and quality of service.

An Open Networking Foundation paper discusses the policy problems facing modern networks. Every time a new virtual machine comes online, it can take a long time for IT staff to configure access control lists across the entire network because in many cases they have to make those changes manually.

Room with a view

Instead of having to configure and monitor each device separately, a well-implemented SDN environment provides a single pane of glass, enabling the IT department to manage all devices from a single point and giving it a unified view.

In addition to reducing the management overhead, SDN can also make networks more agile, improving performance and lowering costs.

The larger and more complex a network becomes, the more it has to adapt to changing conditions. Application traffic may spike, or a collection of users may begin thrashing the network in a particular region or department. The easier it is to configure a network centrally, the more the administrators will be able to adapt it and keep it running.

Adaptability also means efficiency. Instead of providing a pipe with 200 to 250 per cent extra capacity to allow for peak traffic, SDN allows you to configure the network more dynamically, scaling back low-priority traffic during high load times. This is particularly important in WAN environments, where capacity costs can be high.

This is something that network equipment vendors have been tackling for decades with traffic-shaping technology, but SDN is likely to make it far easier. Chris Weitz, director of technology strategy and architecture at Deloitte Consulting, believes that firms using SDN could potentially cut their networking bills in half.

Thinking out of the boxes

SDN becomes particularly important as we move to a virtualised environment. These days, a company may find itself running hundreds of virtual machines across a few physical boxes, all of which have their own software-based interfaces and all of which need configuring and monitoring to ensure that they don’t break the physical network.

There are three tiers in an SDN architecture. In the middle is the SDN controller, which manages the devices on the network and controls the polices used in the forwarding plane. In the bottom layer are other network devices that take instruction from the SDN controller. The control interface between these two tiers is known as the southbound API.

In what format is this information sent? The ad hoc standard for SDN is OpenFlow, which was published by the Open Network Foundation at the end of 2009. It programs the control plane, effectively telling network devices what to do, and it must be implemented both on the SDN control side and on the device side.

The OpenFlow protocol enables administrators to define traffic flow paths based on application and resource usage, breaking the current hard links between network devices.

The beauty of SDN is that the applications can interact with the controller

Of particular interest is the top tier of the SDN architecture, populated by IT applications. The beauty of SDN is that the applications can interact with the controller, defining the forwarding plane themselves and enabling them to request appropriate traffic paths.

The communications pathway between these applications and the SDN controller is known as the northbound API. It becomes particularly important when using network applications such as virtual switches or orchestration systems for cloud services.

Different vendors have their own approaches to – and definitions of – SDN. VMware has been touting its software-defined datacentre strategy, in which architectures are defined in software rather than physical hardware. Last year, the company acquired Nicira, a developer of open-source SDN software.

The company has used this software effectively as a network hypervisor, creating a virtual layer between the physical and logical networks, defined in software. It is merging the Nicira software with its vCloud Networking and security product line to create a single product family, called NSX,which is designed to work with any hypervisor and cloud management system.

Cisco is focusing on large enterprises with its SDN strategy, which features its Open Network Environment controller at the centre. Although it is supporting third-party controllers and protocols including OpenFlow in its southbound APIs, it is focusing on implementing SDN using its own hardware.

The company is offering equipment with application-specific integrated circuits (ASICs), which collect network application data and exchange them between routers. Controllers can communicate with these ASICs using its onePK platform.

Microsoft has an advantage over VMware and Cisco: a server and desktop operating system. It is capitalising on this, talking up the idea of configuring endpoints in addition to physical network devices in a virtualised environment.

The idea is to program end hosts and make real-time changes in response to changing conditions such as virtual machine migration. Microsoft wants to marry the concept of SDN with end-to-end software control.

Restricted traffic

Microsoft has built SDN functionality into its Hyper-V hypervisor and its System Center 2012 Virtual Machine Manager. Hyper-V, working inside Windows Server 2012, uses SDN policies to control traffic flow in virtual networks.

Each tenant in a multi-tenant cloud-based environment can use multiple virtual subnets, controlled via the SDN capabilities in Hyper-V. Microsoft wants users to build virtual networks running atop the physical network, each serving collections of specific virtual machines.

Certain network flows can be routed towards particular virtual machines, and the traffic performance between virtual machines can be protected simply by configuring the appropriate network flow in software according to where the machines are migrating.

Microsoft has also built SDN into its Hyper-V virtual switch. This can be programmed with traffic control and security policies to restrict traffic to specific types between virtual machines, and to isolate groups of virtual machines altogether.

Microsoft’s virtual switch can also be extended, enabling third-party software providers to enhance its operations with their own features. These include traffic monitoring and OpenFlow connections to virtual appliances on the network.

Vendors naturally have their own approaches to SDN, some focused on end-to-end control, some on hardware and others purely on network abstraction. As with all new developments, the real challenge will be in persuading users to take the plunge and give SDN a try.

It is still a relatively new and poorly understood concept. Engineering user awareness will be as important as defining and implementing protocols. ®