In depth: Software-defined networking

Virtualisation is everywhere. Over the past few years organisations have virtualised compute, consolidating servers in arrays of virtual machines, and storage, bringing disks together into thin-provisioned storage pools.

This has changed the way that CIOs buy hardware and management tools, with software abstracted away from infrastructure. Instead of data centres full of servers allocated to discrete applications, organisations are thinking about deploying private clouds, where policy-driven management tools automatically deploy business-aligned services as and when they are needed.

The private cloud is a grand vision, but there is one aspect of the data centre that’s hard to abstract, and hard to manage: the network. If virtualisation is to deliver on the vision of a dynamic, managed data centre, then the network must be virtualised too.

Instead of having to manage switches, routers and VLANs, users need tools that can take network definitions and apply them across entire networks, changing configurations on the fly. Currently, it takes time to deploy network resources for a new project or a new service – time that gets in the way of delivering the flexible response business that owners are demanding.

This is where software-defined networking (SDN) comes in. SDN takes the job of mapping the routes between network components out of the hardware and runs it in software instead. This promises far greater agility and automation in network management, promising some of the benefits already seen in the server space from virtualisation and cloud infrastructure.

Decoupling control

While server virtualisation has been around a long time, the full vision of a private cloud – in which server resources are provisioned automatically in response to demand – is still a work in progress. SDN, meanwhile, is still in its very early stages, so the benefits may be a few years away for most organisations.

Conventional network routers and switches serve two functions: the control plane and the data plane. The control plane manages the network map, dictating how packets of data are sent to specific addresses. It is also where network filtering takes place, and where quality of service rules are applied. The data plane, also known as the forwarding plane, assesses incoming traffic to decide what to do with packets as they enter the device. 

Both these functions are traditionally served by the networking hardware, but software-defined networking splits out the control plane as a software-based service, running on a separate server. This creates a software layer that manages and controls how a network behaves programmatically, allowing multiple switches and routers to be managed from a single location. 

The potential benefits are many and varied. In principle, SDN could allow an organisation to quickly configure an entire network without having to configure and control network hardware individually. It allows organisations to experiment with different types of network architecture, from networks where everything is centrally controlled to those where each element is identical, allowing rapid scaling. It means that new functionality, such as security and monitoring or quality of service management, can be added to the network infrastructure without having to add additional hardware.

SDN also allows network resources to be provisioned automatically and programmatically, akin to virtual server instances in a private cloud. This will enable organisations to allocate those resources according to peaks in demand. If a company needs extra bandwidth for an ecommerce site at Christmas, for example, or for backing up a large database, network resources can be assigned to those tasks without reconfiguring every router. 

All this supports the vision of the ‘software-defined data centre’, in which server, storage and network resources are assigned to business services as and when they are required, improving both the agility of the organisation and the utilisation of its IT investments. That phrase was front and centre at VMware’s recent user conference, as the company explained the rationale of its recent $1.3 billion acquisition of SDN pioneer Nicira. 

So far, it is web and cloud service providers that have made the most use of SDN. One example is Internap, a US-based hosting provider. The company’s Managed Internet Route Optimiser (MIRO) service, based on proprietary technology, allows customers to reroute traffic to their website through different network providers in order to minimise latency. MIRO monitors the network conditions and reconfigures routers to ensure that only the most effective routes are used.

However, there are myriad potential applications in the enterprise. For example, Clive Longbottom of analyst company QuoCirca explains that SDN could be used to optimise a voice-over-IP implementation. 

“A business with 1,000 VoIP phone lines could run them in a physical environment unmanaged,” he explains. “The VoIP call quality would be variable depending on the data workload against the network on a minute-by-minute basis.

“Alternatively, they could dedicate bandwidth just to VoIP, and so take a massive chunk out of their available network. They could prioritise the traffic, making the VoIP traffic of a higher priority than other traffic, but in a complex environment, trying to ensure that priorities are worked out correctly can be difficult.

“With a virtualised network, not only can the VoIP traffic be serviced as it happens, but the right codec at the right time could be chosen for dealing with the traffic.”

The use case that may prompt widespread adoption of SDN, however, is in virtual server environments. 

Virtual servers need networking resources too, of course, and the job of configuring network resources to connect virtual machines is a management overhead that constrains the flexibility of virtual environments.

According to Alex Smith of telecommunications analyst Canalys, switching to an SDN approach simplifies things, allowing network resources to be managed as single virtual environment that can be allocated to both physical and virtual servers automatically. That virtual networking environment is not limited to a single LAN, but can spread across multiple data centres, making WAN connections part of the networking fabric.

The end-state that this is all pointing to, Smith says, is “a centralised approach to managing a networking infrastructure that now has virtual, mobile endpoints. The idea is that networking intelligence (routing maps, network policies, etc) occurs at this software layer, and the hardware (switches, routers, servers) carries out the commands.”

What is OpenFlow?

One initiative that is greatly improving the viability of SDN is OpenFlow, an open SDN network switching protocol. Initially developed as part of a Stanford University research project, OpenFlow was the first widely available SDN protocol, adding software to routers in order to open access to the flow tables at the heart of a router’s or a switch’s data plane.

One reason that OpenFlow is proving popular is that coupling the controller from the hardware has the useful side effect of allowing commodity hardware to be used in enterprise networks. As OpenFlow is an open source project, it is easier for hardware vendors to add support. Similarly, third-party management tools can support OpenFlow without needing to connect to proprietary APIs.

The OpenFlow project is overseen by the Open Network Foundation, a standards body of which most of the key networking industry players are members. With the backing of such a body, plus endorsements from companies such as Google – which recently revealed that it is experimenting with OpenFlow in its own networks, and has found it useful in reducing both complexity and costs – OpenFlow looks likely to become a key SDN standard. 

Network equipment vendors are likely to face additional competition as a result, with new-entrant equipment providers able to build on open standards and commodity hardware. 

Open standards will also increase competition between management platforms, simplifying their access to the network. A combination of these effects should result in reduced infrastructure costs, both for hardware and for software.

As the importance of such a standards body implies, however, SDN is still a work in progress. This is one reason why adoption has been muted so far. According to Radek Dymacz, head of R&D at online backup service provider Databarracks, most SDN technology is not ready for mainstream consumption.

“One of the reasons that the speed of adoption for SDN hasn’t been great is that, for now, configuration is programmatic,” he says, adding that this will change as simpler, graphically driven SDN tools become available.

Dymacz also believes that there is work to be done on the security surrounding SDN. “As SDN is new and not yet widely adopted, there are certain security concerns, as there are with any new technology,” he says. “Specifically, the protocol is still changing a great deal and there is still work to do around the junction between the new SDN and traditional networking. Until this is completely locked down, there are still some areas for concern.”

That said, once it is in place, SDN will offer organisations greater visibility of their networks and therefore greater security, he argues. “You now can have a single point of view of the whole network,” Dymacz explains. “Security-wise, this makes it much quicker and easier to react to any security threats. You can make all your changes quickly and in one place rather than across multiple switches.”

QuoCirca’s Clive Longbottom notes that awareness of SDN is still low. He recently asked attendees at a networking event how many had heard of SDN, and none of them raised their hand. At this early stage in its development, the immaturity of SDN is compounded by the paucity of SDN-related skills.

Longbottom argues that if SDN functionality is likely to make its way into mainstream IT environments in the near future, it will be through integrated server, storage and networking systems, such as Cisco’s UCS or IBM’s PureSystems range, which incorporate many SDN-like features as standard.

When it comes to applying SDN across the data centre, organisations will be limited both by the lack of available skills and the fact that legacy infrastructure may not support SDN standards such as OpenFlow. This means that adopting widespread SDN would involve infrastructure investment that few IT organisations currently have the budget for.

SDN is not a technology that stands on its own; it is one component of the vision of a software-defined data centre, where management policies and service definitions describe the virtual infrastructure required to deliver a service – and then deploy it.

It may not be ready for mass consumption today, but any organisation hoping to inject their data centres with the flexibility and agility of the cloud should keep one eye on the technology as it develops.