SDN: Software-Defined Networking

This is an introductory article on SDN with link on where to search for further information.
Tech Articles
Introduction
Systems that work well have modularity based on abstractions. While networking provides excellent examples of this with the OSI and TCP/IP models, networking infrastructure does not use abstractions and is not modular.

In other words, much of networking is hardware-specific and does not use abstractions to provide modularity. SDN and NFV introduce the concepts of abstraction layers to what we think of as networking infrastructure.

Background Information
For an introduction to abstraction layers, click here . More information is also available on the OSI and TCP/IP models, which are based on abstraction layers. Click here for a comparison of the OSI and TCP/IP models.

Why SDN was Needed
  • Networks are hard to manage
  • Networks are hard to evolve
  • Network design not based on formal principals  

Example of Hardware that Supports SDN
The Cisco ASR 6000 (often nicknamed the ASR9K) is a router that supports SDN and the OpenFlow protocol.


The OpenFlow Protocol
The OpenFlow protocol specifies basic primitives that can be used to program the forwarding plane of network devices. 

Note that the network equipment, like the Cisco ASR 6000, will run an OpenFlow agent. In these cases, the equipment is not designed purely to work with SDN / OpenFlow.

Software external to the network equipment will use the OpenFlow protocol to control network equipment like routers and switches. This software is called the Controller and runs on x86 equipment, perhaps within a VM (Virtual Machine), rather than proprietary hardware. 

The x86 equipment is referred to as referred to as commodity equipment to emphasize that the equipment can be purchased from a number of vendors.

Control Plane and Data Plane
Conceptually, network equipment configuration is referred as being organized into more than one “plane” (perhaps because of its similar definition to “level”).

Control plane: makes high level routing decision. 
normally on same device, on an OpenFlow switch, these two are separate

Data plane: still resides on network device, handles forwarding of the data.


OpenFlow Tables
Each entry in an OpenFlow table can match on factors such as:
  • Source address (layer 2 or layer 3)
  • Destination address
  • VLAN tag

If a packet cannot be matched, the device will send the packet to the controller. The controller will determine what to do with the packet. It may simply drop the packet. Or, it may update the flow table so that the device knows what to do next time.

OpenFlow compliant switches must support the following fields:

match field: a field against which a packet is matched, including packet headers, the ingress port, and the metadata value. A match field may be wildcarded (match any value) and in some cases bitmasked. 

priority: matching precedence of the flow entry. 

counters: updated when packets are matched. 

instructions: to modify the action set or pipeline processing. 

timeouts: maximum amount of time or idle time before flow is expired by the switch. 

cookie: opaque data value chosen by the controller. May be used by the controller to filter flow statistics, flow modification and flow deletion. Not used when processing packets. 

flags: any flags that are used to alter the way flow entries are managed
 
SDN Controller Example
An example of an SDN controller is VDS (vSphere Distributed Switch).

VDS includes an SDN controller and an agent implementation. 

Within VDS, VMware has abstractions of the physical card (vmnic), link properties (teaming, failover, and load balancing), and networking attributes such as VLAN assignment and traffic shaping that can used by the administrator as reusable configuration templates.

 

Suggestions for Future Learning

William Stallings: Foundations of Modern Networking

SDN by Nadeau, Thomas D. and Ken Gray, published by O'Reilly.

Cisco ASR 9000 SDN Openflow Whitepaper


Welcome Page
Tech Articles
Welcome Page