Programmable Networks: Separating the Hype and the Reality

Each year MIT Technology Review presents its annual list of 10 breakthrough technologies that can change the way that we live. These are technologies that outstanding researchers believe will have the greatest impact on the shape of innovation in years to come. In 2009, Software Defined Networking (SDN) was one more in that list. This is a significant fact because this technology promises to make more programmable computer networks, changing the way that we have been designing and managing them. But, let’s start from the beginning: What is a Programmable Network (PN)?. According to SearchSDN website, PN is defined as a network “in which the behavior of network devices and flow control is handled by software that operates independently from network hardware. A truly programmable network will allow a network engineer to re-program a network infrastructure instead of having to re-build it manually”.

Till now, a lot of water has passed under the bridge, but it doesn’t mean that SDN is currently a consolidated technology. According to Gartner Hype Cycle (2013), SDN and other related technologies like NFV (Network Function Virtualization) are still at the peak of inflated expectations stage waiting to fall at trough of disillusionment (see Hype Cycle definitions). Although it seems to be a recent topic, it isn’t. In this point I recommend to read an interesting report called “The Road to SDN: An Intellectual History of Programmable Networks” by Nick Feamster et al. (Dec 2013) where authors remark that SDN and NFV aren’t novel ideas at all, but an evolution of a set of ideas and concepts in relation to PNs over at least the past 20 years.

Particularly, PNs interest me because for years I have had the opportunity to work on networking from two points of view: industry (Telco) and academia (research university), and in both areas I have checked “in situ” some limitations of the current network infrastructures, which have already been described widely in the literature (e.g. report).  Therefore, I consider interesting to explore the current network capabilities and which are industry/academia proposals (and challenges) to tackle the migration problem towards PN.

For example, in order to improve diverse network aspects such as speed, reliability, management, security, and energy efficiency, researchers need to test new protocols, algorithms, and techniques in a real large-scale scheme. It’s a tough work to do it over existing infrastructures, because routers and switches run a complex, distributed, and closed (in general, proprietary) control software. Moreover, to try a new scheme or approach can result a cumbersome task specially when each time you need to change the software (firmware) in each network element.

On the other hand, network administrators, for both management and troubleshooting, need to configure each network device individually, which also is an annoying task when there are many devices. However, it’s true that in the market there are some management tools to manage these elements in a centralized manner, but they typically use limited protocols and interfaces, and therefore, it’s common to find interoperability problems between vendors, which adds complexity to the solution.

Without going further, last June I attended SDN World Conference & Exhibition in Barcelona where the telecom community discussed several aspects about SDN and Network Virtualisation in general (Note: two next events this year will be on May/London and on September/Nice). Well, I remember, among other things, a recurrent idea in the talks: “In last years, computing industry has actively evolved towards an open environment based on abstractions thanks to the cloud paradigm. It has allowed to progress in various aspects: virtualization, automation, and elasticity (e.g. pay-per-use and on-demand infrastructure).  On the contrary, networking has evolved towards a complex, rigid, and closed network scheme, lacking of abstractions (e.g. control plane) and open network APIs.”

In consequence, from Telco’s point of view it’s necessary to consider a change in the network design that facilitates the network management. It’s also urgent to work in the integration between computing and networking by means of virtualization and so to see the network as a pool of resources; not as separated functional entities. Also it’s desirable to avoid hardware-dependent and vendor lock-in. All this suggests that the simple idea or promise of a PN that helps to solve these drawbacks would be a big leap in quality and a great opportunity towards network innovation.

Currently there are two main approaches in the field of PNs that industry is fostering: SDN and NFV. The former is mainly (though not exclusively) focused on Data Center Networks and the latter on Operator Networks. Next, some definitions about SDN and NFV are given for a better understanding of the text, however, the main goal of this post is to review some characteristics of SDN and NFV from an innovation point of view. Therefore, I am not reviewing technical aspects in depth. For more detail, I recommend to review the following websites: ONF, SDNCentral and TechTarget (SearchSDN). For experienced readers, I recommend to check this website for academic papers.

Some definitions: What is SDN?

According to Open Networking Foundation (ONF), an organization dedicated to the promotion and adoption of SDN through the development of open standards, SDN is an approach for a network architecture where the control plane and data plane (forwarding plane) are decoupled. In simple terms, the control plane decides how to handle the traffic and the data plane forwards traffic taking to account the decisions that the control plane performs.

In SDNCentral, Prayson Pate describes SDN as “Born on the Campus, Matured in the Data Center”. Effectively, SDN began on campus networks at UC Berkeley and Stanford University around 2008, and thereafter, it made the leap to data centers where currently has been showing since then, to be a promising architecture for cloud services. In a simplified way, he indicates that the basic principles that define SDN (at least, today) are: “separation of control and forwarding functions, centralization of control, and ability to program the behavior of the network using well-defined interfaces”. Through the Figure 1, I will try to clarify, as far as possible, these concepts.

Figure 1a shows a traditional network scheme where each network device (e.g. router, switch, firewall, etc.) has its own control plane and data plane, which are currently vertically integrated. This supposes extra cost and incompatibilities among manufacturers. Moreover, each device has a closed and proprietary firmware/control software (Operating System) by supporting diverse modules (Features) to perform some protocols related to routing, switching, QoS, etc.

Figure 1: Traditional Scheme vs. SDN Architecture

On the other hand, Figure 1b depicts a logical view of the SDN architecture with its three well-defined layers: Control, Infrastructure, and Application. The first layer consolidates the control plane of all network devices in a network control “logically” centralized and programmable. Here, the main entity is the SDN Controller whose key function is to set the appropriate connections to transmit flows between devices and therefore to control the behavior of all network elements. Also, there may be more than one SDN controller in the network, depending on configuration and attending to scalability and virtualization requirements. In contrast, the second layer involves the infrastructure formed by the packet forwarding hardware of all network devices, which is abstracted to the other layers, this is, physical interface from each device is seen just as a generic element by applications and network services. Finally, the third layer is the most important from innovation point of view because contains the applications that will provide added-value to the network. Applications such as: access control (e.g. firewall), load balancing, network virtualization, energy efficient networking, failure recovery, security, etc.

In this architecture, an important aspect to be highlighted is the communication between layers, which is carried out via APIs (Application Programming Interface). Conceptually, in computer and telecom science two terms are used to describe these interfaces: Southbound Interface and Northbound Interface. The former refers to an interface to communicate with lower layers. In the case of SDN, Openflow is a prominent example of this type of API. Conversely, the latter refers to an interface to communicate with higher layers. Today, however, there isn’t a consolidated standard for this kind of interface, which is the key to facilitate innovation and enable efficient service orchestration and automation.  Later, I will comment some things about this.

What is NFV?

In simple words, NFV is a new approach to design, deploy and manage networking services. Its main characteristic is that some network functions are decoupled from specific and proprietary hardware devices. This means network functions such as Firewall, NAT (Network Address Translation) IDS (Intrusion Detection System), DNS (Domain Name Service), DPI (Deep Packet Inspection), etc. are now virtualized on commodity hardware, i.e. over high performance servers of independent software vendors. It’s applicable to any data plane or control plane function in both wired and wireless network infrastructures. (see Figure 2).

Figure 2: Vision for Network Function Virtualization (source ETSI)

Although SDN is perhaps the buzzword when talking about PNs, currently the term NFV hasn’t lagged far behind in popularity. In fact, it turns to be a recurrent term between Services Providers, given that a group of them formed in October 2012 a consortium dedicated to analyze the best way to provide a solution of PNs in the field of operator networks. This consortium afterwards created a committee under the umbrella of ETSI (European Telecommunications Standards Institute) in order to propose and promote virtualization technology standards for many network equipment types. In the paper called “Network Functions Virtualization: An Introduction, Benefits, Enablers, Challenges & Call for Action” (October 2012), NFV ETSI Working group describes the problems that are facing along with their proposed solution.

Trends and some comments

Beyond the obvious differences between SDN and NFV, such as: focus (Data Centers / Service Network Providers), main characteristic  (Separation of control and data plane / relocation of network functions), etc. Analysts agree that both approaches can co-exist and complement each other (i.e. there is synergy), but each one can operate independently (Note: I recommend to read “The battle of SDN vs. NFV“ for more detail). In fact, Service Providers understand there are too “works in progress” (and open problems) and nothing completely defined, and therefore it wouldn’t be logical to dismiss out of hand any solution, more even when they have a broad portfolio of services in several fields. Telefónica, Colt, and Deutsche Telekom, are just three examples of Service Providers from ETSI that are working actively in these topics developing pilot programs.

SDN and NFV are just tools and they don’t specify the “killer application” that hypothetically could boost its use. Actually, SDN is meant to give support for every new coming application. Here, a key element in the development of applications is the Northbound API. In recent months there has been movement in ONF to form a group in order to accelerate the standardization of this interface, but it isn’t clear that this effort will bear fruit in the short/medium term.  At this moment there isn’t a common idea and many discordant voices. In this link there is an interesting discussion about this topic. For instance, it’s mentioned that apparently ONF is more interested in developing Openflow protocol than a Northbound API, because “standardizing a northbound API would hamper innovation among applications developers”. Dan Pitt from ONF said in this sense: “We will continue to evaluate all of the northbound APIs available as part of our commitment to SDN end users, but any standard for northbound APIs, if necessary, should stem from the end users’ implementation and market experience”. It’s clear that finally, as in other many occasions, the market will give its verdict.

Meanwhile, it’s gaining relevance a consortium called OpenDaylight formed by “important” network hardware and SDN vendors, which have launched on April 2013 an open source SDN controller with its respective framework through which is possible to develop SDN applications.  OpenDaylight supports the OSGi framework and bidirectional REST-API for Northbound API. They expect this initiative gains momentum but for now, they rejected to say that are an universal standard, although seeing the power of its members, it isn’t excluded that they have a high market share in the future.

Taking into account this previous idea, we already know that the heart of SDN is the SDN controller and today there are other many alternatives to OpenDaylight. Personally, I have worked with NOX/POX (C++/python-based) and Floodlight (java-based). The former is suitable to learn about SDN controller because has, say, an academic character, meanwhile the latter has a focus more professional and works with REST-API, which is a more common interface. On the other hand, in addition to startups whose focus is to develop a SDN controller, there are many others related to SDN applications (some people use the term ADN-Application Defined Networking) in areas as diverse as security, management, energy-saving systems, etc. With all this, I want to say there are many available open source tools and it’s possible already to begin the development of SDN applications or applications on top able to work on top.  Some interesting startups are mentioned in CIO and IT World. In Spain, at startup level (by excluding Service Providers) there are few examples to mention. In fact, the first one and unique that comes to mind is Intelliment Security based in Seville, which provides a centralized network security management offering “an abstract and intelligent control plane where changes are automatically orchestrated and deployed to the network without human intervention”.

Going to another topic, SDN and Big Data analytics are two technologies that are destined to understand each other.  It’s expected that SDN makes certain network management tasks easier and therefore will be necessary to have a technology that takes advantage of the huge amount of data about the network and so Big Data will enter to scene. For instance, issues such as traffic patterns analysis, traffic demand prediction analysis will help to enable an intelligent management. On the other hand, a prickly topic that certainly will be on the table, for anonymity reasons, is the use of DPI (Deep Packet Inspection) techniques. So, in general, as we are talking about to centralize the communications, it’s logical to think that SDN and Big Data will meet soon. One first approach can be found in the paper called “Programming Your Network at Run-time for Big Data Applications” (2012), G. Wang et al. where authors explore an integrated network control architecture to program the network at run-time for Big Data applications based on Hadoop using optical circuits with an SDN controller.

Another pertinent issue to be commented is how PNs will affect the development of OTT providers.  Currently they are, say, helpless at network control level due to they cannot guarantee by themselves the delivery of their services. I know “it’s Internet and many Service Providers come into play”, but today, OTT providers like Skype, Netflix or Wuaki-TV in Spain just can make some QoS network measurement with your client in order to adapt the delivered content (transcodig) or simply to indicate minimum requirements to guarantee a suitable quality of experience (QoE). Usually SDN and NFV promise to help Service Providers improving the management and control of “their own” networks, but perhaps in the future this control can also be extended to third-parties. OTT providers are injecting increasingly traffic to the network becoming in major players in the Internet wherewith likely they demand more control and SDN or NFV can be the key to reach it as well as to generate new business models.  So, OTT providers will be able to give better services with better QoE, Service Providers will be able to adapt to the requirements of OTT providers, and Apps OTT will be able to talk to the network in real time.

On the eve of MWC 2014 at February in Barcelona, undoubtedly SDN and NFV will be buzzwords again. Matthew Palmer in SDNCentral said about SDN and its trends in 2014: “2012 was the year for people to learn what is SDN?, 2013 was the year for people to understand how they use SDN, and 2014 will be the “show me” year; the year of the proof-of-concept for SDN, NFV, and Network Virtualization”.  SDN and NFV have a huge potential but are still in early stage; we must to be expectant to the news in the upcoming months. SDN is much more than a “match/action” scheme in switches and a logically centralized control of multiple network devices. Moreover, there are still a lot of open problems to solve such as: Northbound API, control orchestration, security, etc.

Finally, for people who want to learn more about SDN and implement some practical examples by using open source SDN controllers, network simulator, python programming, etc., I strongly recommend to take the free MOOC by Cousera called “Software Defined Networking” from Georgia Tech that begin at June 24th. I took the same course the last year and really it’s an excellent starting point for understanding this topic. The course lasts only 6 weeks and has 10 quizzes and 4 programming assignments, approximately. Nick Feamster, the instructor, said the content will be updated according to new developments and trends in the field.

 

Photo credits

Concept of man in mirror via Shutterstock