P REVIOUS R ESEARCH IN SDN

As SDN is praised as “the next big thing” there has been a lot of research on the matter especially in 2014. Like this thesis, many people are trying to see “if it fits”

into various scenarios. Some have developed applications but that part seems fragmented; no de facto standard applications have arisen yet.

Before implementing SDN the concept must be understood, how SDN differs from traditional networking and what are the components it is made from. When considering applying SDN into an existing network the transition path must be first planned.

2.1 Previous Research in SDN

To see how the concept behind SDN evolved over the years “The Road to SDN:

An Intellectual History of Programmable Networks” by Feamster et al. (2013) goes through all previous technologies similar to current SDN and explains how each of them contributed to the idea. This is the paper quoted on many other research papers as the one that explains best how SDN came to be. It does a good job of explaining all the underlying concepts and what SDN is about and what it is not about. It also reminds that however good an idea SDN is many similar

technologies have been tried in the past and it won’t become a success unless people find real life use cases for it.

“Software Defined Networking Concepts” by Foukas et al. (2014) is a paper detailing the components of SDN and as such clarifies what a SDN system consists of. To understand what SDN does it is good to understand the components that do it. As is common SDN discussed in the paper is SDN

implemented by using OpenFlow. Some real life scenarios of SDN are mentioned, for example how SDN might be used in data center and cellular networks where it is at its best.

The applications and challenges of SDN are discussed in the paper “Software Defined Networking: State of the Art and Research Challenges” by Jammal et al (2014). The application detailed most is the data center network, how SDN is able to improve the performance and reliability over a traditional network. The relationship of SDN and NFV (Network Functions Virtualization) is discussed.

The challenges of SDN when implementing the concept to a real life use case are made apparent and how some of them have been solved. The case they make is that SDN works really well in some scenarios but not in all of them. Caution should be exercised when trying to implement SDN in enterprise networks.

The development of SDN software and hardware isn’t nearly finished but one aspect that is often forgotten as long as the system works is network security.

Schehlmann et al. (2014) have evaluated the safety of SDN architecture compared to traditional networking in the paper “Blessing or Curse? Revisiting Security Aspects of Software-Defined Networking.” Mainly the centralized nature of SDN is both its greatest strength and weakness; complete control of the network from a single point. It is concluded that SDN at this point looks to be more good than bad but as the products mature it should be taken care that network security is

considered in their functions.

Overcoming the challenge of moving to a SDN network can be done in various ways, Vissicchio et al. (2014) provide ideas on how to do it in the paper

“Opportunities and Research Challenges of Hybrid Software Defined Networks.”

As almost all existing network are not SDN enabled in anyway there will be a lot of trouble in the future for network administrators to figure out how their network can be most efficiently transitioned to SDN. Before the practical part of the transition a transitional model must be agreed on. The paper evaluates the usefulness of each model for a different scenario and how the model can be developed to be a long-term solution if needed. Running a hybrid network brings its own challenges but is necessary in most cases.

For testing SDN most research has been using the Mininet SDN network

simulator. De Oliveira et al. (2014) go through basic use and test the scalability of it in the paper “Using Mininet for Emulation and Prototyping Software-Defined Networks.” Mininet is a simple but powerful tool for simulating a SDN network.

When used as a supporting document to the official documentation this paper helps getting used to using Mininet. Mininet’s usability for simulation is

evaluated and alternative simulation programs presented. In the paper there is also a performance test of Mininet using a tree topology that supports the success of Mininet as the simulator of choice for SDN.

There hasn’t been a comprehensive comparison of SDN controllers, but “On Controller Performance in Software-Defined Networks” by Toontoonchian et al.

(2012) has a few of them performance tested which could help in selecting one even though it is a bit dated as the technology evolves so fast. It is concluded that the performance of the controllers, in requests per second, is surprisingly good.

However they state that measuring overall performance of SDN is not as simple as just seeing if a single controller can handle the workload and that multiple controllers should be used in larger networks.

Trying to fit SDN in the ISP network mold has been the subject of a few papers.

Kerpez et al. (2014) explore propagating SDN all the way to the access nodes in the paper “Software-Defined Access Networks.” According to the paper the benefits of extending SDN to access nodes are the same as with other networks:

cheaper hardware with better performance, scalable and flexible central

configuration. In addition it would enable new business models for ISP customers, like NaaS (Network as a Service) and better fault diagnostics assuming the CPE (Customer Premises Equipment) is also SDN enabled.

As performance of SDN in real-life applications is a concern Kong et al. (2013) have conducted experiments using real ISP traffic in the paper “ Performance Evaluation of Software-Defined Networking with Real-life ISP traffic” to see how SDN components fare under stress. The experiment was conducted using a traffic

capture from a real life tier 1 ISP network that was then run through a SDN enabled network. Then they analyzed the results with emphasis on SDN specific parameters like controller processing and flow entry installation delay. It was seen that the problem lies more in the performance of the switches rather than the controller.

2.2 The Concept of SDN  

The most common way to define the concept of Software Defined Networking is

“SDN separates the control plane (which decides how to handle the traffic) from the data plane (which forwards traffic according to decisions that the control plane makes)” and “consolidates the control plane, so that a single software control program controls multiple data-plane elements (Feamster et al., 2013).” In contrast to traditional inflexible networks where both planes are tightly connected and the control spread to individual devices (Foukas et al., 2014). In short:

centralized control over an abstracted network.

SDN brings new ideas to the old traditional networking world. Many would say nothing is wrong now, the current way of networking works. SDN doesn’t try to fix traditional networking but instead takes a different approach to how networks are defined. What SDN is promising is simpler centralized control of the network;

instead of proprietary text based configuration an intuitive graphic approach (Vissicchio et al., 2014), flexible logical and physical network topologies with more emphasis on what instead of how. Though in the SDN world the physical topology is not as important it allows the administrator to “slice” the network by allocating wanted nodes as part of a networks topology so that only those nodes will be used. As has been seen from server virtualization decreasing the amount of hardware in the network while increasing software can achieve many good things.

Also with traditional network equipment their capabilities are predefined by not only their hardware setup but also by their firmware; for a different purpose a different firmware might be required. The devices are (Commercial of the Shelf), the user can’t (with reasonable effort) modify the device’s functionality

(Vissicchio et al., 2014). This also leads to paying for too many features in the device when you only need some, with SDN the hardware will be cheaper as it does not have to have those features built in it (Santa Monica Networks, 2014).

What traditional networks do best is layer 2 and 3 hop by hop forwarding, the development of specialized hardware for that has been going on for a long time.