Software Defined Networking (SDN) stakes

As promised, in this post I will talk about the stakes of SDN paradigm in networking. The consequences of SDN would be similar to those of introducing abstraction layers into computing (virtualization, generic less expensive hardware, cloud computing, innovation, new pure software players...).

For service providers, the advantages are many:

• As switching hardware will be decoupled of control plane, hardware would become cheaper and interchangeable according to Moore's law. This forecasts reducing CAPEX of networks and dependence of  equipment vendors.
• Software orchestration in OSS forecasts reduction in network operation (OPEX) costs, and faster service implementation thus improving Time To Market for introducing new services.
• As networking becomes software oriented, innovation will happen at software speed!

Clients will also benefit from SDN paradigm according to what was mentioned previously, in terms of costs, flexibility and innovation. Clients will consume networks on demand through a real time digital experience. Check as an illustration the amazing functionalities enabled on the portal of the WAN solution proposed by NTT :

In this evolving ecosystem, the traditional vertical business model of equipment vendors will be highly impacted.  Decoupling hardware from software will let these vendors face low cost switching vendors from one side, and emerging players from software world. 

As previously said, SDN does not remove complexity, but only reorganize and separate problems through modular layered abstractions. It means that some issues should be considered such as interoperability, scalability, reliability... 

In Orange, SDN roadmap is resumed in 4 topics:

• Network virtualization in Orange datacenters
• IT driven networks for VPN to IaaS interconnection
• Deploy SDN PoPs in order to deliver on demand cloud-based networking services (connectivity, security, optimization...)
• Deploy switching-only CEs controlled by SDN PoPs

I am truly excited to witness the major shift in networking and be a part of it!

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.

The impact of language in culture and business

Language can not be reduced to a simple tool of communication. In fact, language not only shapes communication and its content but also influences the communicating persons.

The impact of language on culture and behavior is a very interesting subject. Here is an article on TED's blog explaining five examples of how our language can affect the way we think. In one of the examples, an expert in linguistic-cultural connections thinks about the English justice that aims to punish criminals rather than compensate victims. The expert argues that this is deeply tied to English language. Indeed, in English, we’ll often say that someone broke a vase even if it was an accident, but in some other languages we tend to say that the vase broke itself.

This subject reminds me strongly of the famous dystopian novel "1984" by George Orwell. The story happens in a country deeply controlled by a tyrant totalitarian political system. In order to better control the population, the ruling party has developed a new language called the "newspeak". Newspeak is a minimalist language meant to ideologically align thought and action to the principles of the party. Newspeak:

• Removed words referring to dangerous concepts such as freedom, diversity...
• Minimized dictionary by removing synonyms and words with ambiguous meaning
• Removed subjectivity from words and gave them strict meaning
• Created new words illustrating new concepts of the party such as "doublethink"
• Shortened words length so that people don't get time to think about what they are saying, and speak rather like robots.

Even in programming, the choice of language has a strong impact on the way the programmer designs software. For example, an object-oriented language will drive you eventually to design object based architectures and use advanced concepts such as design patterns paradigms.

Finally, i think that the same dependence exists between the behavior of employees and their company's internal language. In illustration, I will give some examples:

• The absence of a disparate honorific addressing among employees might help them communicate more easily.
• The intensive use of internal specific words makes it more difficult for the employees to imagine new ideas requiring other terms in order to be described. For example, when listening to a client expressing his needs, a sales representative might only capture the needs that can be matched with internal words of his company.
• Another consequence of intensive use of internal words and acronyms is a more significant barrier for quitting the company, thus affecting the loyalty of employees.

The culture and behavior of a company, and thus its success or failure, can be tied to its internal language. Do companies consciously manage this aspect?