SDN (Software Defined Networking)

Software-defined networking (SDN) may be the technology du jour, but as of yet it is largely conceptual — and those concepts vary depending on the approach. Vendors talk about their own SDN architectures, OpenFlow, SDN APIs, and overlay networks either as if they are interchangeable, or without ever mentioning the other options. It’s no wonder that SDN leaves many folks in IT with no grasp of the “definition” at all.

The basis of SDN is virtualization, which in its most simplistic form allows software to run separately from the underlying hardware. Virtualization has made cloud computing possible and now allows datacenters to dynamically provision IT resources exactly where they are needed, on the fly. To keep up with the speed and complexity of all this split-second processing, the network must also adapt, becoming more flexible and automatically responsive. We can apply the idea of virtualization to the network as well, separating the function of traffic control from the network hardware, resulting in SDN.

Whether out of a need for self-preservation or a desire to improve technology, the networking industry is embracing SDN with surprising enthusiasm. Legacy networks have serious limitations and old methods that simply will no longer work. As virtualization, cloud, and mobility create more complex environments, networks must be able to adapt in terms of security, scalability, and manageability. Most enterprise networks, however, rely on fixed boxes and appliances requiring a great deal of manual administration. Changing or expanding these networks for new capabilities, applications, or users requires reconfiguration that is time consuming and expensive.

Software-defined networks take a lesson from server virtualization and introduce an abstraction layer separating network intelligence and configuration from physical connections and hardware. In this way, SDN offers programmatic control over both physical and virtual network devices that can dynamically respond to changing network conditions using OpenFlow or some other programmable and controllable packet/flow processing protocol.

There are several approaches to SDN, but the most common components and concepts are covered in the following slides. Though the technology is very much in the midst of its development, vendors and industry organizations are working to make the technology open and flexible while adhering to existing Internet standards. At its core, SDN promises to enable network technology innovation and versatility while reducing complexity and administrative overhead.

Will SDN really catch on?
The past few months have produced a flurry of SDN activity in the networking industry, culminating with Cisco announcing its Application Centric Infrastructure (ACI). But is anyone really buying any of this stuff?

If they aren’t, that will be changing soon. According to a recent report from Transparency Market Research, the global SDN market is expected to reach $3.52 billion by 2018, growing at an astonishing annual growth rate of 61.5 percent from 2012 to 2018. The report classifies SDN technologies into four categories: SDN switching, SDN controllers, cloud provisioning and orchestration, and security and services.

Basic SDN architecture
An SDN architecture consists of three layers. At the top is the application layer, which includes applications that deliver services, such as switch/network virtualization, firewalls, and flow balancers. These are abstracted from the bottom layer, which is the underlying physical network layer. In between lies the SDN controller, the most critical element of SDN. The controller removes the control plane from the network hardware and runs it as software, but must integrate with all the physical and virtual devices in the network. In this way, the controller facilitates automated network management and makes it easier to integrate and administer business applications.

OpenFlow enables SDN
Several vendors have adopted the OpenFlow protocol, originally developed at Stanford University, as the basis of their SDN strategies. But OpenFlow is not the only way to do SDN and should not be equated with it. The OpenFlow specification is now in version 1.4 and is managed by the Open Networking Foundation (ONF). The goal is to create a common “language” for programing network switches. OpenFlow is used between a controller and a switch to tell the controller about traffic flows and communicate to the switch how to forward those flows.

OpenFlow first gained popularity with service providers including Google, and many hardware and software vendors, including Alcatel-Lucent, Brocade, Cisco, Dell, F5, HP, Juniper Networks, NEC, Plexxi, and VMware, support it as members of the ONF. The foundation has not released the standard as an open source spec, but instead allows members to license it for use in products.

SDN using APIs
Application programming interfaces (APIs) are an alternate way to provide the abstraction necessary for SDN along with a highly programmable infrastructure. APIs provide a channel by which instructions can be sent to a device to program it. Programmers can read API documentation to understand the device and code the appropriate commands into their applications. In SDN, APIs are called “northbound” or “southbound,” depending on where they function in the architecture.

APIs that reside on a controller and are used by applications to send instructions to the controller are northbound, because the communication takes place north of the controller. Southbound APIs reside on network devices such as switches. These are used by the SDN controller to provision the network, with the communication taking place south of the controller.

SDN network overlay
Another SDN option is a network overlay. In this case, rather than building an entire logical SDN network from scratch, the SDN implementation is built as an overlay in order to leverage a physical network that already exists. The overlay is created using virtual switches inside hypervisors. These set up tunnels that make use of the underlying physical network, but don’t need to actually configure the hardware to send traffic to its destination.

Emerging protocols including VXLAN, STT, and NVGRE make this possible by using network encapsulation. Several vendors, most notably VMware, offer overlay network solutions.

Benefits of SDN
Why should you consider SDN, especially if it is still in development? The technology has the potential to make significant improvements to service request response times, security, and reliability. It could also reduce costs by automating many processes that are currently done manually and by allowing IT departments to replace (at least in some cases) high-margin devices with commodity hardware.