The role of software-defined networks in cloud computing

It may seem ironic, but the most difficult thing about software-defined networking is actually defining it. Given the elasticity of views about what a software-defined network is, it's hardly surprising that SDN's specific role in the cloud is elusive.

There are two software-defined networking models and two different SDN missions in cloud computing. Since networks create the cloud, managing the interplay between these two factors could be the key to cloud efficiency and success.

As an information service, the Internet treats the network as a transparent partner. With the cloud, a user's applications reside in, and become part of, the cloud. And most agree that means at least some of the network must be integrated with the cloud. The current consensus is that the data center has to be made cloud-specific, but should the WAN also be a "resource" to the cloud?

To answer that, let's first look at why SDN must include the data center.

In cloud computing, the user joins a community the cloud creates. Cloud computing service providers face the issue of multi-tenancy at the network level as much as they do at the CPU/server and database levels. Shared resources must be shared in such a way that one user's applications do not affect another user's apps. Therefore, the resources of all users have to be partitioned so they are private and secure. While network technologies such as IP and Ethernet each have virtual network capability, these capabilities are limited in terms of how many tenants can be supported and limited how isolated each tenant is.

Cloud software providers see the network as a partnership between the data center network and the cloud. Amazon Web Services' Elastic IP addresses an application-driven approach to integrating the network and the cloud; OpenStack includes network services as one of the resources it virtualizes, along with storage and CPU/server. OpenStack's Quantum interface defines how a virtual network can be created to "host" CPU and database elements, for example. However, Quantum doesn't define the technology used to create that virtual network. Each vendor is responsible for mapping its technology to the virtual network models that Quantum defines.

Two SDN models for cloud computing
The need to first accommodate multi-tenancy and support cloud control of network services second brings us to the technology side of SDNs. Two models of SDN have emerged: the "overlay model" and the "network model."

In the overlay model, software (often cloud-linked software) creates a virtual network; in the network model, network devices create those virtual networks.

Overlay SDNs, such as VMware's recently acquired Nicira technology, use software to partition IP or Ethernet addresses into multiple virtual subnetworks, similar to what TCP does with ports. A new set of network APIs allows applications to access these subnetworks as though they were IP or Ethernet networks. The software keeps the traffic of multiple subnetworks secure and isolated. Network devices don't "see" overlay virtual networks, so they don't treat traffic differently.

Network-hosted SDNs are built from network devices; therefore, they manage SDN traffic directly. Some network vendors -- Cisco in particular -- propose to add software control to current devices and networks by adapting current network technology and devices that conform to SDN principles, creating the "evolutionary SDN."

Others network vendors, including most SDN startups, propose to evolve network devices to a simpler form, removing routing intelligence and path/traffic management that are in devices and centralized in cloud-hosted software.

But both the overlay and network models and missions collide in the WAN. If cloud virtual networks have to extend beyond data centers in the cloud and outward to the user, then it's difficult to see how network-hosted SDN implementations of virtualization could be avoided, for three reasons:

• Overlay SDNs rely on a software element to create the virtual networks. It's harder to ensure a user has the required software to participate.
• Network appliances with software that can't be easily updated cannot use overlay virtualization at all.
• WAN quality of service (QoS) can't be assured with an overlay SDN because the SDN can't manage traffic handling. A network-hosted SDN can offer exactly the same interfaces and services to users as it did before, requiring no changes to software or devices. It could also manage traffic and insure QoS. Therefore, end-to-end SDN missions favor an SDN model that is implemented in the network not over it.

SDN is increasingly accepted as the path to "cloud networking," meaning the transformation of networks and services to support the use of cloud computing on a massive scale. Navigating the various missions and technology models of SDNs is critical to properly position cloud services and realize advantages of cloud computing. For cloud users, knowing their cloud providers' SDN plans, as well as the plans of private cloud software stack vendors, is the most critical element in assessing these providers' long-term value.