Software Defined Networking (SDN) Paradigm

The first time I heard about Software Defined Networking (SDN) was back in 2012 through a colleague in Orange Labs. Today, SDN is not a R&D subject anymore, Google has already deployed SDN for the WAN interconnecting their datacenters. Our clients are already asking us in Orange Business Services about SDN. I have watched  some conferences (check Scott Shenker) on this hot and interesting topic, and I would like to share my understanding of it in this article.

Let’s start by a concrete case which is the WAN of one of my clients. It is based on a main layer 3 VPN which is backed up and partially deloaded by a layer 2 VPN, connecting agencies, critical sites and partners to a datacenter where information system is hosted. Below is a simplified network diagram: 

In today’s provider approach, for each new required feature, or a change in the client’s flow matrix, we have to implement a specific mechanism by considering three issues in the control plane:
 

·         [Issue 1] Compatibility of network hardware

·         [Issue 2] Global network consistency to avoid side effects

·         [Issue 3] Configuration of network devices

Feature	Mechanism	Issue 1	Issue 2	Issue 3
Orange and grey agencies should not be able to see each other	Multiple VRF: create two distinct routing tables in the backbone for each type of agency	Check if its validated by engineering	Put Datacenter in both routing tables since it is reachable by both types of agencies	Configure Backbone edge routers (PE)
Partners can only reach certain servers on the datacenter	ACL: filter partner IP packets using access lists on the client routers (CE)	Check if the CE can handle the number of ACL	Avoid that some unidentified but required partner IP packets are blocked	Configure the CE
Critical sites reach datacenter through Ethernet VPN. In case of a fault on this link, they reach the datacenter through MPLS VPN	BGP: complex dynamic routing	Check if CEs from different constructors can establish BGP sessions	Avoid routing loops	Configure different CEs and PEs
Critical sites and agencies breakout to internet and to cloud telephony platform through MPLS VPN with adequate Class of Service (CoS)	Traffic shaping: prioritize real time traffic over internet traffic and respect CoS policy	Check if CE can handle CoS	Guaranty CoS on backup paths	Configure different CEs and PEs

The major difficulty with this feature-equal-mechanism approach on the networking control plane is trying to solve too many problems at the same time!! If we make an analogy with programming, it would be like asking a software engineer to write a high level program (website) using a low level programming language (Assembly)!!!!!

Of course our friend would only accept developing using high level programming language (PHP) , which abstracts the underlying HTTP server (Tomcat), which abstracts by its turn underlying the operating system (Linux), which finally abstracts machine’s hardware. This is what SDN is trying to reach: reorganizing and separating problems through modular layered abstractions.

Today, control plane in networking is not designed with this philosophy, but data plane is. Indeed, data plane is layered according to the OSI model.  As an example, we can implement OSI model with TCP/IP over Ethernet:

As each layer solves a specific problem, we can adapt the protocol implementing a layer according to the situation without side effects on other layers. For example, for link layer we can use either Ethernet or ATM.

We have already seen a similar shift in the telecom industry with IP Multimedia Subsystem (IMS) in core network. IMS enables rich and converged services through its layered architecture instead of historical vertical design:

So how does SDN layers control plane?  SDN isolates different issues through three proposed abstractions:

· Forwarding: In this abstraction, we decouple forwarding from switching. Indeed, forwarding is computed separately and then forwarding tables are pushed to switching elements (for example through OpenFlow protocol). This abstraction tries to solve Issue 1, by hiding the complexity of the underlying hardware.

· Global network view:  This layer abstracts the complexity of distributed mechanism by providing a global view of the network with real time annotations such as link capacity, delay, loss rate. This can be achieved by a separate platform on the network that probes network elements to constitute network view/graph.  This layer addresses Issue 2.

· Network virtualization: This abstraction simplifies network topology, so the control program can express his intent easily, focus on functionality and avoid getting stuck with network elements problems. This layer tries to solve Issue 3.

Let’s get back to my client’s case and imagine how a new feature would be implemented with an SDN approach. The client subscribes a telephony as a service solution on a critical site. This application would express to control plane its requirements in terms of VoIP bandwidth and QoS on the path between the critical site and the cloud telephony platform. The control layer has a high level view of the network thanks to virtualization abstraction:

The control layer will validate the application requirement (in red) according to network capacity, rights.. then provision it in the information system for management and charging, and finally ask the network to implement it.

The network has a more detailed view on the different paths between the critical site and the telephony platform, thanks to global network view abstraction:

The network will compute on a graph different possible paths and then compute necessary forwarding rules on all of the network elements on these paths in order to respect VoIP requirements. Paths and rules computing is continually performed in real time. Finally forwarding rules will be pushed to dumb switching network elements thanks to forwarding abstraction (Openflow protocol).

In my upcoming article, I will talk about the advantages of SDN and the opportunities it presents to telecom providers and thus to clients.