Software Defined Networking (SDN) is a disruptive development whose time has come. It breaks open the closed, proprietary world of networking hardware and replaces it with superior functionality enabled by software and managed by IT. Google has already implemented the technology over its intercontinental WAN.
There is a robust business case for migrating to SDN, detailed in an earlier article. In a nutshell, SDN takes networking out of the rigid, mainframe-computing model of the '60s and propels it into an era of network virtualization in which computing and storage resources can be orchestrated by IT. The introduction of a centralized controller allows a Web portal to provide a single logical view of the whole network and thereby a single point of management.
The question for enterprises is becoming when and how to move forward, not if. How to embrace this new technology and migrate seamlessly to a virtual network architecture?
It's clear that forklift upgrades are not an option: it is not feasible to migrate to a centralized SDN framework in one step. Instead, migration will normally entail transitioning to a hybrid architecture that enables a traditionally configured network to provide SDN features. Extreme Networks talks about segments or sections of the network moving to a model based on SDN "islands" that interoperate with traditional networks and indeed work in unison. Dell talks about a new type of network virtualization, one that delivers low-cost private cloud solutions to enterprise data centers. And they emphasize that SDN has the potential to drive the next generation of IT services.
Right now, IT departments are trying to understand how SDN can be deployed and used in conjunction with a traditional network. A key enabler to understanding this migration is for network switches to run in a hybrid mode, i.e. run in both OpenFlow and traditional mode. This can be realized by partitioning the switch so that certain traffic can be forwarded using traditional technologies and certain traffic is forwarded based on rules programmed using SDN technologies such as OpenFlow.
That view comes from Extreme, an Ethernet switch vendor, and there is nothing intrinsically wrong with vendor-centric strategies. The company is an established player that supports OpenFlow/OpenStack, which are de facto standards (see "How Software Defined Networking Will Change Communications"). Dell, on the other hand, is a relatively new player and therefore they do not come with any legacy routers and switches; this allowed them to start with a clean sheet of paper. And on yet another hand, Cisco is taking a defensive position against the possibility that SDN technology could disrupt their leading role in switching and routing.
It's clear that virtual network architectures (VNA) should have a network virtualization overlay--one that encompasses the hypervisor computer environment of major players like Microsoft, VMware and Citrix as well as OpenStack, the SDN open source cloud operating system. Figure 1 is a somewhat simplistic schematic, but it illustrates Dell's top-down, holistic approach. The idea is to deliver the networking benefits and features via modular building blocks, thereby making it easy to access the compelling business benefits without forklift upgrades or complex integration.
Figure 1. Dell's top-down holistic approach is enabled by a Virtual Network Architecture: a framework that provides an evolutionary path leading from legacy networking technologies to OpenFlow and beyond to next-generation SDN applications and services.
Next page: Google's SDN WAN
Google's SDN WAN
Centralized control is a feature of the SDN concept, but when spread over an intercontinental WAN, it made more sense for Google to have central controllers at each datacenter linked into an overall traffic engineering controller for the whole network. This is analogous to having an intelligent police presence directing traffic at each major road junction. In addition, multiple OpenFlow controllers ensured there would be no single point of failure.
The centralized traffic engineering service collects real-time use and topology data from the network and calculates bandwidth demand from the applications and services. It then computes the best traffic flow path assignments and uses the OpenFlow protocol to program them into the switches. As demand fluctuates, or unanticipated events happen in the network, the service re-computes and reprograms the system.
With this OpenFlow control system in place, Google could have done some radical re-thinking and experimentation with new networking concepts, but instead they chose to begin with a fairly traditional system that was compatible with existing networks and familiar to the operations staff. The technology was new, so it was a safer bet to begin with a traditional feature set and then evolve from there, using the network's software definable capability.
SDN: An Expanded Term
There is nothing new about the concept of a software-defined network. It goes back to the early '90s, when Cabletron prototyped a secure VPN solution; more recently, HP was proposing an Adaptive Edge Architecture.
The difference this time comes from the enabling OpenFlow/OpenStack protocols. SDN has moved on and the term now embraces three categories: hypervisor, decentralized (hybrid), and centralized SDN.
Hypervisor-based SDN adds intelligent networking capabilities into hypervisor switching platforms, thereby enabling network virtualization. This feature allows applications with disparate topology and network service requirements to share a common private-cloud infrastructure.
Decentralized SDN takes the traditional, decentralized control plane architectures and adds more advanced application integration frameworks onto the traditional network-forwarding model. These solutions are built as an extension upon traditional networking technologies and simply enable applications to have greater access and control over standard networking control plane features. They do not provide the depth of application integration of centralized models, but they deliver some of the most compelling SDN benefits without having to make changes to the traditional networking control plane.
Implementing decentralized SDN would therefore seem to be the logical migration path to follow, but there are two caveats. One, the ingress and egress edge devices need to be SDN capable. And two, there must be a software upgrade path to OpenFlow.
Finally, the OpenFlow architecture provides the leading example of an advanced centralized SDN framework. Centralized SDN architectures offer several distinct advantages for driving real-time intelligence into an advanced fabric, thereby creating more robust network management tools.
...And Beyond
The industry talks about compelling network-centric benefits such as enabling IT to manage the enterprise WAN and the lower capital and operating expenditures. But there is more to SDN than that. One can argue that the biggest benefit will come from the ability to reverse the roles of infrastructure and business needs.
In the past, networking departments worked with their preferred vendors to map out the evolution of their network infrastructure, with minimal input from the company's application and business teams. Today there is more awareness than ever that infrastructure should fall in line with the needs of business rather than vice versa: networking strategy should not dictate or limit the application strategy.
Given the intense pace of business and the increasing degree to which business relies on applications, it is more important than ever that infrastructure support applications and facilitate their development. They should not be constrained by inflexible architectures and mainframe-type networking gear.
Next page: The four networking layers
The Four Networking Layers
In many ways, networking has always been defined by software, but networks have been constrained by the way software has been configured, delivered and managed. SDN removes that constraint. Juniper Networks emphasizes the importance of understanding the network software that operates in the four layers or planes: management, services, control and forwarding. The legacy software in today's network products uses code that was built monolithically, without cleanly defined interfaces. In SDN these interfaces are clearly separated, and their respective roles need to be understood:
1) Forwarding. This plane does the heavy lifting of sending the network packets on their way. It is optimized to move data as fast as it can; therefore it is typically built using application-specific integrated circuits (ASICs).
2) Control. This plane understands the network topology and makes the decisions on where traffic should go. It understands and decodes the various networking protocols and it learns everything it needs to know about the network by talking to its peers in other devices.
3) Services. This plane performs the complex operations on networking data that cannot be accomplished by the forwarding hardware. Services are the place where firewalls stop malware and where parental controls are enforced. Juniper suggests that the services plane is ripe for innovation.
4) Management. This plane provides the basic instructions of how the network device should interact with the rest of the network. While the control plane learns everything it needs from the network itself, the management plane has to be told what to do. Today's networking devices are often configured individually, using a command line interface, understood by only a small number of network specialists, which means that manual mistakes are made.
Four-step Migration
There are different ways to realize SDN, but the four-plane model indicates a logical set of steps: centralized management followed by service extraction and then the creation of a centralized controller. That is the basis of Juniper's migration strategy.
Step 1: Centralized network management, analytics, and configuration functionality provide a single master that configures all networking devices. This lowers operating cost and allows customers to gain business insight from their networks. The system is packaged in virtual machines (VMs) running on industry standard servers. They are orchestrated using systems such as VMware's vCloud Director, Microsoft System Center, or OpenStack.
Step 2: Extracting services from network and security devices by creating service VMs is important because services are an area that is underserved by regular networking. This enables network and security services to independently scale using industry-standard, x86 hardware.
Step 3: Creating a centralized controller is the big step. It enables multiple network and security services to connect in series across devices within the network. It's called "SDN Service Chaining" and it uses software to virtually insert services into the flow of network traffic. Today's physical approach to service chaining is quite crude: Ethernet cables physically connect separate devices and each device must be individually configured to establish the service chain.
Step 4: The final step of optimizing network and security hardware can proceed in parallel with the other three. As services are disaggregated from devices and SDN service chains are established, network and security hardware can be used to optimize performance based on the needs of the solution. The separation of the four planes helps to identify functionality that is a candidate for optimization within the forwarding hardware. This unlocks significant potential for innovation within the ASICs and the system design of networking and security devices.
Next page: Service chains
Service Chains
With SDN service chaining, networks can be reconfigured on the fly, allowing them to dynamically respond to the needs of the business, which is one of SDN's big promises. Service chaining can be employed in various ways, one of which is enabling communication between two components of a cloud application.
Figure 2. A key feature of chaining is the significant reduction in the time, cost and risk for customers to design, test and deliver new network and security services.
The traffic between these application components must be isolated from other traffic within the cloud data center and the load needs to be balanced across application instances with an Application Delivery Controller service.
In SDN, service chaining is done in software. The chain forms a virtual network where the endpoints are the virtual switches within the hypervisors of the servers that run the application VMs. The chain dynamically adjusts the links within it when the data center orchestration system moves a VM from one physical server to another. There is still a physical network underneath the chain but it does not need to be reconfigured when changes are made.
Programming the Network Through APIs
As indicated earlier, network software operates in the four layers or planes. Software defines the network, and it does so via APIs. The API is the control point for each component of the network: OpenFlow switches, SDN controllers, network management systems, and network analytics. Apigee is a leading vendor of the embedded components and management services that make it easy to program the network through APIs.
APIs are an abstraction model. Virtualization enables existing physical systems' descriptions to be reused in a logical environment. APIs enable complete resource abstraction. Virtualization is required in order to scale applications that otherwise would be bound to physical or logical systems. For applications written to an API, resource binding can be completely dynamic.
Apigee's technology therefore enables the creation of datacenters that adapt to shifts in demand for specific applications, and that optimize network resources, routes and services. This combination of networking, application, analytics, and enterprise capabilities elevates a software-defined network into an application-optimized datacenter.
Conclusions
SDN's impact will extend far beyond the data center. This disruptive technology will create new winners, and some incumbents will struggle to make the transition. But the business case is compelling and customer benefits are real. If 2012 was about establishing a foundation, then 2013 is about accelerating deployment, so that more businesses can achieve the CAPEX and OPEX advantages of OpenFlow and SDN.
