SDN 101: What It Is, Why It Matters, and How to Do It

Despite all the buzz about software-defined networking (SDN), many organizations don’t yet have a clear idea of how it will benefit them. In this blog, I’ll tackle the what and why of SDN, and explain the different approaches you can consider.

What: A Disruptive Approach to Network Control

For the last quarter century, network devices have performed two types of processing:

• The data plane looks at a routing table to decide where to forward packets. This processing takes place in dedicated hardware ASICs.
• The control plane takes care of everything else, such as spanning tree, AAA, exporting NetFlow statistics, SNMP, and more. The control plane is implemented in software, and you can think of it as the brains of the network element.

So, if your network includes 200, 2000, or 20,000 network devices, that means you’re managing 200, 2000, or 20,000 control planes and keeping all of them up to date.

This network architecture remained about the same until 2007. That’s when Stanford University created a program called Clean Slate, which challenged program participants to propose how they would design the Internet if they could start with a clean slate and 20-30 years of hindsight. One of the ideas that took hold was SDN, defined as decoupling the control plane from the data plane. The control plane is implemented not on the network element, but on a centralized appliance or server. Applications can directly access the control plane—either to harvest network information or to program network behavior such as reserving bandwidth, assigning priority to traffic from certain IP addresses, and so on (Figure 1).

Figure 1  Traditional SDN Architecture: Control Plane Resides on a Centralized Server Instead of on Each Network Element

The standard SDN architecture shown in Figure 1 includes four components. One is the control plane, which resides on a server. Northbound APIs on the controller allow applications and the network to communicate. Agents on the network devices fulfill requests from the controller. Finally, OpenFlow is the Layer 2 protocol that the controller and agents use to communicate.

OpenFlow is part of the SDN story, but not the whole story. I’ll get back to that later in this blog.

Why Should You Care About SDN?

The goal of SDN is to let each business application (and not you) program the network to optimize its own performance. Use cases for SDN are still unfolding, but here are some of the more popular ones:

• “Network slicing,” referring to partitioning the physical network into logical slices for different research teams, often in university settings.
• Centralizing policy control for all devices on your network, to save time and reduce the chances of configuration errors.
• Segmenting cloud service provider networks for hundreds or thousands of tenants.
• Examining traffic flowing into massive data centers (for content providers, for instance) to improve network performance.
• Helping service providers more quickly introduce new, revenue-generating services.
• Enabling individual applications to directly program the network to acquire the resources they need to optimize performance in any set of network conditions 

How Cisco Is Advancing Network Programmability

Cisco provides several approaches for network programmability, and all of them together are called Cisco Open Network Environment (ONE). The three approaches are:

• The traditional SDN approach, using a controller, northbound API, agents, and OpenFlow.
• A set of APIs called onePK (for One Platform Kit). Application developers can use onePK APIs so that their applications can gather network statistics or program the network. You can use onePK to program the network in ways not possible with the traditional SDN approach. For example, in a university dorm, the router can assign priority to each student’s traffic based on the service level they purchased. Or, an application can reserve bandwidth in advance for special events, such as company-wide video announcements.
• Virtual overlay. By adding a logical overlay on top of your physical network fabric, you can allow  different tenants can create, modify, or tear down their own virtual networks without your having to make any changes to the physical network. Today’s technologies behind virtual overlays are Cisco Nexus 1000V virtual switches and Quantum APIs, an OpenStack technology that Cisco helped develop. Here’s a good white paper: Cisco Open Network Environment: Network Programmability and Virtual Network Overlays.

Figure 2  Virtual Overlays Provide Another Approach to Network Programmability

Summing Up

SDN and network programmability are an important advance for IT teams as well as users because they:

• Simplify the network by letting you manage one or a few control planes instead of one in every network element.
• Make it simpler to optimize application performance by automating network provisioning and related configuration activities.

Keep in mind that SDN is more than OpenFlow. Depending on your business needs, the best solution might be a traditional OpenFlow controller architecture, or it might be onePK APIs or virtual overlays.