Several decades ago, computer scientist and networking author Andrew S. Tanenbaum famously quipped that the nice thing about standards was that there were so many to choose from. The same could be said today, perhaps, about the number of software-defined networking models that lay before cloud providers.
But before providers can even consider a software-defined networking (SDN) deployment or even a pilot test, they must first choose which model or models of SDN to support. However, the wrong choice could waste time, strand assets and even put the provider's service offerings at competitive disadvantage. In this tip, we will discuss the three primary models of SDN, explaining the basic goals, mechanisms, benefits and drawbacks of each.
SDN explained: The network virtualization model
The simplest model the market considers SDN is the network virtualization model popularized by Nicira, a startup acquired by VMware in 2012. The primary goals of network virtualization are to eliminate the restrictions on local area network (LAN) partitioning that exist in the Ethernet virtual LAN (VLAN) standards and to address the scalability issues with multicasting in some Ethernet-based virtual network architectures.
If OpenFlow switches become pervasive over time, then it's possible that future networks could be built with open hardware at much lower cost.
To accomplish this, network virtualization platforms augment a software element -- usually the hypervisor, but cloud-building software like OpenStack could also be modified -- with an interface that creates VLANs that are based on tunnels running on top of traditional Ethernet. Network equipment and operations are not affected, and tens of thousands of virtual networks (or more) could be created this way, in theory.
The greatest benefit of network virtualization is it supports multi-tenant clouds without requiring changes to the network itself. This SDN model maps easily to popular virtualization interfaces in cloud networking mechanisms, such as OpenStack's Quantum or most cloud DevOps tools that support network provisioning. As a result, it becomes easy to integrate network provisioning with cloud service provisioning.
The greatest disadvantage is that the virtual networks, being "above" the network layer, simply appear as traffic to the network devices. Those devices can't prioritize individual virtual networks or report on their status unless deep packet inspection is used to identify the virtual network header. Finally, since software that's part of the cloud server stack creates the virtual networks, the virtual networks can only link virtual machines -- not users and devices.
SDN explained: The 'evolutionary' approach
The second model of SDN can be called the "evolutionary" model. With this model, the goal is to enhance software control of the network and its operations but within the boundaries of current networking technology. To achieve this, networking vendors are likely to align themselves with specific standards -- such as VXLAN, GRE, BGP and MPLS -- and use them to partition the network into virtual communities and to manage traffic and Quality of Service. The vendors may then combine their solutions into a set of management interfaces that can be exercised from the cloud -- again, through DevOps tools or a cloud virtual interface like OpenStack Quantum.
Network devices implement this SDN model, making it fully integrated with network operations, FCAPS management and network monitoring. Conventional traffic engineering principles can be applied, and the virtual networks can theoretically extend from server to user, as long as the devices support the selected standards.
Most SDN vendors currently implement all of the network standards above, but some may not be available on all devices. This latter point is the first of several disadvantages with these evolutionary models, as providers will need to validate the standards existing equipment supports. A greater problem is that so far specific vendors offer these evolutionary SDN models, which may not fully interoperate with equipment from other vendors. This approach will also likely require special integration between the management systems and the cloud virtual networking or DevOps interfaces, and if the vendor doesn't provide this, then the operator will have to undertake the task.
SDN explained: The OpenFlow model
The final model is the OpenFlow model of SDN, the one most people associate with the term SDN. OpenFlow replaces the traditional, discovery-based creation of forwarding tables in switches and routers with centrally controlled forwarding, meaning that a central controller programs each device's forwarding table. This gives that central control point complete rule over how the network is segmented or virtualized, how traffic is managed and so forth. Any combination of controllers and switches that support compatible versions of OpenFlow (versions that support the network features needed) can be used in this model of SDN.
More on SDN for cloud providers
Slideshow: A peek at cloud providers' SDN plans
Find out how OpenFlow can make cloud management easier for providers
SDN + OpenFlow = The key to cloud automation?
The greatest benefit of this final SDN model is that it's the model on which the concept of SDN was originally built. Early pilot tests and deployments suggest that OpenFlow can improve network availability and reliability while increasing network utilizations, thus reducing both capital infrastructure costs and operational expenses. If OpenFlow switches become pervasive over time, then it's possible that future networks could be built with open hardware at much lower cost.
The disadvantage of this model is the current lack of functional detail for all of the necessary components. OpenFlow is supported on most mainstream switches and routers, but not always with the same throughput traditional protocols could achieve. And, of course, this mechanism of OpenFlow support doesn't do much to drive down the cost of switching.
There are both open-source and commercial OpenFlow controllers available, but these do little more than send commands to switches to create paths, manage capacity and so forth. A set of higher-layer management applications are needed. These must connect through northbound APIs to the OpenFlow controllers, and these APIs are not standardized. The early implementations of OpenFlow demanded operators integrate multiple components to create a functional software-defined network; there was no complete commercial package available.
Three models, but which is best?
Cloud providers struggling with VLAN limits on segmentation -- 4,095 VLANs per network -- or facing multicast issues in VLAN routing may want to look first at the virtual network model of SDN. This model can be overlaid on the evolutionary SDN model too, though there may be some issues of harmonizing the management interfaces. Providers that have a large investment in data center networking equipment may want to look at this approach to avoid redundant costs.
The future is likely to mean at least some accommodation to OpenFlow, and so providers should look for OpenFlow support from their network equipment vendors, particularly when deploying new equipment. Fortunately, nearly all networking vendors have explicitly committed to supporting OpenFlow as part of their evolutionary SDN approach, which means that cloud providers can actually hope to use two or even three of the SDN models at once. As always, careful trial and test procedures are essential to ensure stable and profitable operation.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecom and data communications since 1982.