Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

14.1 Introduction

The continuous growth of the Internet, smart applications, e-commerce, multimedia applications, social networks, etc. poses a continuous challenge for networks on keeping up with such evolution in terms of bandwidth, information overload, complexity, etc. Enterprises such as Google, Facebook, Microsoft, eBay, and Amazon use a very large number of data centers. A huge volume of data is exchanged in those centers. Data centers include tenants or virtual machines (VMs) to divide virtually or logically the network into different nodes, clusters, or slices. New services based on user or customer demand may cause new VMs to be created. For each newly created VM or tenant, resources, management, control, security, etc. are all should be allocated dynamically to accommodate that particular VM needs.

One of the serious challenges in cloud computing or the Internet traffic is that demand varies widely from day to day or even from hour to hour. This fluctuation makes it very hard to manage this process manually. On the other hand, traditional switches are vendor specific and the administration and configuration/reconfiguration of those switches are labor intensive. Similarly, the management of security controls such as firewalls is labor intensive as the process to add, update, or maintain access control lists (ACLs) in those firewalls is accomplished manually by network administrators.

OpenFlow is an algorithm developed to define interaction between controller and switches. Specifically, OpenFlow (OF) includes detailed specifications on how the controller should communicate with its OF switches. OF switches are different from traditional switches in that they are built to be very basic with no control functions and include only data or forwarding elements. Most newly designed switches start supporting both modes: traditional and OF. Controller is a software program that acts as a networking operating system (NOS) for the control and administration of OpenFlow switches.

SDN has several initiatives that came to solve specific problems in networks. Switches, routers, or other network components are vendor specific. Networking companies , for business not technical purposes, do not allow users to program applications on top of those networking components. One of the main goals of SDN is to have an open networking architecture that is not vendor locked-in or specific. Further, this network architecture should also be developers or network administrators to interact with the switches and, for example, use or customize flow or access control algorithms.

In this paper, we conducted an SLR on SDN. We followed SLR systematic research investigation process. Key terms that can distinguish publications in SDN are formulated. Key questions that can best extract recent research trends in SDN are formulated. To the best of our knowledge, there is no research that discusses SLR in SDN. The closest to the scope of SLR in SDN will be survey papers. There are some papers that conducted surveys in SDN (e.g., [10, 48, 207–211, 280]).

14.2 SDN Road Map

While SDN is new as an architecture, no new networking technologies were invented, and the architecture coined old concepts and combined some new practices. Most references considered the work of Casado, his PhD thesis, Nicira networks’ establishment, SANE, and ethane papers [212, 214] as the starting hype. However, existing research papers before that (e.g., [213]) discussed the core idea in SDN which is to split the routing or the intelligence knowledge from router and switches and include it in a separate control unit. What was interesting in SDN story is that its advances accelerated almost in parallel in both the academia and the industry. Similar to Google story, researchers in SDN and graduate students from Stanford established new startups, Casado: Nicira networks (2007) with his two advisors, Nick McKeown and Scott Shenker and Kyle Forster and Guido Appenzeller, BigSwitch networks (2010). In this road map, however, we will focus only on the advance at the research and publications’ level. Members from the University of California, Berkeley, such as Scott Shenker, were also early contributors in SDN. OpenDaylight is currently an open source project to build the controller and SDN architecture around in which most vendors come together to support it.

Nicira later on introduced OpenFlow as an instance of SDN and a protocol to regulate the communication between SDN controller and switches. Nicira (later became part of VMware) contributes also to the development of the Open Virtual Switch project (Open vs. Switch, 2008), an open source virtual switch that enables software applications to interact with switches. While protocols other than OpenFlow can be used in SDN, however, currently OpenFlow is associated with SDN. We showed that in our string search, the two words that mostly define SDN in literature related to SDN are the abbreviation SDN and OpenFlow. GENI is established in the USA in 2009 as a national project to promote SDN research through an SDN-based networking lab that is open for all researchers. Open Networking Foundation (ONF) , the company behind OpenFlow standards, is established in 2010.

Tables 14.1 and 14.2 show the top 22 papers published in SDN based on citation. In order to collect the top ten papers in terms of citation, we used the same two terms that most distinguish research papers related to SDN: SDN and OpenFlow. Those two terms were selected after several trials of combinations between different key terms. Results, in terms of the number of citations, vary from one website to another. We focused on the most agreeable ones between the five research indexing websites: IEEE Xplore, ACM Digital Library, Google Scholar, Microsoft Academic Search, ScienceDirect, and CiteSeerX.

Table 14.1 Top 1–11 SDN/OpenFlow published papers (based on citation)
Full size table
Table 14.2 Top 12–22 SDN published papers (based on citation)
Full size table

The top cited papers can give us indication what are the top research trends in SDN. We can see that the first 11 most cited papers can be classified into:

  1. 1.

    Early contributions by Stanford team [214–216].

  2. 2.

    Cloud data center-related issues (e.g., scalability, fault tolerance) [217–219].

  3. 3.

    SDN scalability and distribution issues [220, 223].

  4. 4.

    Other trends: optical/firmware [221, 222, 224].

One more notice is that there are some other trends that have been evolving more recently. However, they are not getting yet the size of research as those earlier subjects. The new most recent subjects shown in Table 14.2 include SDN security issues, SDN testing and QA, SDN wireless, etc.

Table 14.2 shows the next 11 research papers in terms of citation count.

We think that while research focuses in Table 14.1 will continue to exist in the future, we think that security and testing issues in particular will get more research focus in the new future especially as those two areas include both most significant SDN opportunities and challenges.

14.3 Goals, Research Questions, and Metrics

In conducting this SLR about SDN, we aimed at achieving the following goals:

  1. 1.

    To classify the research papers published in SDN and be able to summarize research trends in SDN.

  2. 2.

    To show the different challenges and opportunities that are posed or opened based on this new networking paradigm.

  3. 3.

    To show how SDN evolves and how can new researchers find open research areas in SDN.

  4. 4.

    To identify, for SDN, most active researchers, teams or groups, conferences, workshops, and journals.

Based on the previously defined goals, we formulated the following questions that our SLR investigated. We divided some research questions into further sub-questions:

  • R1: What are the main SDN research areas investigated in published papers?

  • R2: What tools have been used or developed in SDN? How can those tools be classified?

  • R3: What are the current investigated security issues in SDN?

  • R3.1: What are the security problems related to SDN architecture?

  • R3.2: What are the security opportunities SDN can bring to networking, cloud computing, etc?

  • R4: What are the obstacles and limitations of SDN?

  • R5: What are the strengths and opportunities in SDN?

  • R6: Research dissemination and trend issues:

  • R6.1: What are the most cited papers, authors, popular conferences, and journals publishing about SDN?

  • R6.2: Who are the top ten authors in terms of the number of publications?

  • R6.3: Who are the top ten authors in terms of citation counts?

  • R6.4: Where are the top ten most active teams located?

  • R6.5: What are the top ten conferences in terms of SDN publications?

  • R6.6: What are the top ten journals in terms of journal publications?

14.4 Article Selection

Selecting the right articles based on the research questions is a major step in SLR. The following steps summarize article-selection stage.

14.4.1 Step 1: Article Identification

We started the process by conducting several combinations of search for SDN key terms in the following academic research libraries: IEEE Xplore, ACM Digital Library, Google Scholar, Microsoft Academic Search, ScienceDirect, and CiteSeerX. Initially we tried different combinations of the following SDN key terms: SDNs, SDN, SDN, SDNs, OpenFlow, OpenFlow, and SDN. In each combination, we compared results in terms of the percentage of relevant papers to the total number of papers. Finally, we noticed that the best combination that retrieved all papers that are relevant to the subject is when using SDN as an abbreviation together with OpenFlow as one term. Initial results retrieve (208 articles in IEEE Xplore, 236 in ACM, 3030 in Google Scholar, 16 MS Academic Research, and 223 in CiteSeerX).

14.4.2 Step 2: Exclusion Criteria

We defined several exclusion criteria including:

  1. 1.

    An article paper published in a language other than English.

  2. 2.

    Our intention was to exclude articles published before 2006 with our assumption that Casado et al. paper 2006 can be considered as the start of coining SDN architecture. As we mentioned earlier, SDN is not new in terms of technology or invention, it is rather a new way of designing network architecture. However, it should be mentioned that there are some important papers before Casado et al. paper in 2006 (e.g., [213]) that are considered significant in the road map of SDN. In our search collection, OpenFlow protocol focused the search for the most recent publications in SDN after adopting OpenFlow protocol (i.e., after 2010). We accepted this assumption to focus our search to the most relevant research publications to the current SDN architecture. We will have a separate section for SDN road map focusing on papers published between 2004 (Feamster paper till 2011).

  3. 3.

    We excluded technical reports and selected only papers published in conferences, journals, or workshops. We excluded also articles, presentations, etc., although some of those included significant information and contribution. SDN has a unique research stand. This is since it is one of those few research fields that is growing almost in parallel between the academia and the industry. Both sides are trying to get a share in this new field.

  4. 4.

    Research papers indexing websites may include also indexed references to editorial introductions or prefaces. We excluded those also from the retrieved results.

14.4.3 Step 3: Inclusion Criteria

In the selection of proper search terms we described earlier, we ended up with two specific terms that we thought that they can best include the most current relevant papers to SDN. Those were SDN and OpenFlow. We also noticed that since OpenFlow protocol was proposed years after embracing SDN, there are publications between the years 2007 and 2011 that were discussing SDN without including any reference to OpenFlow. Hence we decided manually to include those papers after investigating them and their relevancy to our paper subject. The final number of papers included in our literature survey ended up to be 237 papers. ACM and IEEE included the largest percentage of relevant papers from the general retrieved results. This is based on the inclusion/exclusion criteria we described earlier.

14.4.4 Step 4: Final Article Set

In evaluating the difference in publications and statistics between the different websites, we noticed several issues. We tried to combine or aggregate results from the different websites, for example, when considering top papers, authors, publications, etc. We noticed that websites are indexing different papers. Hence we combined all articles from all different websites to get the top counts based on the five indexing websites that we used. As described earlier, based on the inclusion/exclusion process described earlier, many retrieved results were eliminated.

14.4.5 Iterative Development of Literature Mapping

The process of evaluating the different statistics is an iterative one. If we find a problem in the selection in one website, we will modify it and repeat the new process across all websites. Results published in this paper are according to the last process of gathering data collected from the different websites before the submission of this paper for publication. We acknowledge, however, this is a very recent evolving field where even a very short period such as a month can possibly change the statistics related to this subject.

14.5 Mapping Research and Evaluation

In this section, we will answer research questions based on the collected data.

R1: What are the main SDN research areas investigated in published papers?

We made our own classification of the collected papers and their classification. Table 14.3 shows examples of papers that discussed SDN and network security attacks.

Table 14.3 Security attacks/vulnerabilities
Full size table

Table 14.3 showed that there are some subjects such as DoS, flooding, or DNS amplification that have a significant amount of publications. In those papers, researchers showed challenges and opportunities that SDN can present in terms of those attack detections and preventions. In comparison with traditional networks that can be considered IP-based networks, SDN can be considered as flow-based networks where programs can be developed on top of the network to customize collecting flow-based statistics that can help detect and deal with those attacks at finder details’ levels.

In terms of security applications , we classified those security controls into firewalls, access controls, IDS/IPS, provisioning, load balancing, policy management, traffic monitoring, wireless or mobile networks, and home or Wi-Fi networks. Some of those types can be classified as indirect security controls or security controls supporting tasks. For visibility purposes, we divided those controls among two tables: Table 14.4 and Table 14.5.

Table 14.4 Security controls/applications (1)
Full size table
Table 14.5 Security controls/applications (2)
Full size table

Our own classification of security controls shown in Tables 14.4 and 14.5 is proposed based on SDN literature as well as predicting future security controls and services with the evolution of SDN in particular and programmable networks in general.

Table 14.6 shows research publications related to SDN-cloud-security issues. We further classified this area into general, data centers and visualization, monitoring, orchestration, control, and migration.

Table 14.6 SDN-cloud security
Full size table

R2: What tools have been used or developed in SDN? Table 14.7 shows the number of papers about used proposed and implemented tools in the SDN area. We have divided the tools into ten types (protocol, control architecture and platform, middle box, simulation, testing, framework, programming and debugging, visualization, security, and system). Programming and debugging seem to be the hottest area in the SDNs’ tool. Control architecture and platform and framework can be ranked as second as an attractive research area. Table 14.7 shows publications in SDN tools.

Table 14.7 Software defined network tools
Full size table

Cabral et al. [236] propose a protocol and technique to enhance the forwarding plane called Protocol-Oblivious Forwarding (POF) . This protocol assists in reducing the network cost through employing commodity forwarding element.

An experimentation tool is presented in Voellmy et al. [237] called Mini-CCNx for the Named Data Networking (NDN) . This tool is able to reproduce the experiments on the test bed for NDN through using dynamic routing protocol and multicast content delivery. SDN control architecture called Procera is expressed and explained in Qazi et al. [238, 258].

Procera contains a declarative policy language derived from the information of functional reactive programming. Fayazbakhsh et al. [239] introduce SIMPLE which is an SDN-based strategy enforcement layer intended for enhancing the middle box especially the traffic steering. In Monaco et al. [240] a new architecture is developed in SDN called flow tags . This architecture improved middle box export tags in order to supply the need and essential casual context.

In McGeer [241] a controller platform called Yanc is introduced for SDN; it depicts the state and configuration of the network as a file system which allows and permits system and user applications to cooperate and work together via standard and typical file I/Os. In Gupta et al. [242] a protocol for the safe update for OpenFlow network is explained. The protocol meets the weak flow and packet consistency conditions. In Kuzniar et al. [243] a simulation tool called FS-SDN is proposed in order to deal with the problem of evaluating and prototyping applications in SDN precisely and correctly at high level.

In Vishnoi et al. [244] a testing approach called SOFT is proposed to test the interoperability of OpenFlow switches. The main thing about SOFT is to recognize and create input test that makes the various OpenFlow implementation to act and perform in an irregularity way. In Haw et al. [245] a smart flow management policy in an OpenFlow controller system called SmartTime is introduced. It merges the proactive eviction rule flow with adaptive time-out heuristic. A framework for SDN is proposed in Voellmy et al. [246] to decrease the delivery time of the contents through enhancing network control, network management, and content delivery in Long-Term Evolution (LTE) . A system called Maple is presented in Choi et al. [247] that makes SDN programming simple through using a standard programming language for determining the whole network behavior.

In Nelson et al. [248] a new architecture is proposed for SDN called software-defined unified virtual monitoring (SuVMF) . This framework is used to afford and support the processes of monitoring and controlling management abstraction. An SDN controller programming language is presented in Erickson [249] called FlowLog . The main difference between FlowLog and other languages is that in OpenFlow there is a unified abstraction for the control plane tier, controller state tier, and data plane tier. Beacon is a quick, open source Java-based OpenFlow controller that assists threaded operation and event based together. It has been produced in 2010 and used in research and teaching [250].

In Reitblatt et al. [251] a visualization layer called AutoSlice is presented which computerizes the process of SDN slices and the deployment as well. In Porras et al. [252] a programming language called FatTire is presented. This language is used to write software for fault-tolerant network. FatTire allows programmers to determine the paths through the network with the required level of fault tolerance. Security software called FortNox is presented in Monsanto et al. [253]. This framework offers constraint enforcement and role-based authorization intended for the OpenFlow controller (NOX). In Georgopoulos et al. [254] declarative programming language called NetCore is defined for articulating policies on SDN regarding packet forwarding. This high-level language is compositional and communicative and includes formal semantic.

A framework is presented in Handigol et al. [255] using OpenFlow to increase the QoE fairness through increasing the technology efficiency in SDN. A debugger in SDN is proposed in Vanbever et al. [256] called NDB which is stimulated and encouraged by GDB. Two helpful primitives are implemented in NDB (backtraces and breakpoints) for debugging SDN. Hotsawp is a system used to upgrade the SDN controllers in correct manner and without disruption [257]. Hotswap preserves and retains the network events history. NetKAT is a mathematical base programming language for network presented in Qazi et al. [238, 258]. Atlas is a framework which encompasses the application awareness in SDN. It permits precise and scalable categorization of applications in SDN [259].

An SDN framework called iSDF is introduced in Jafarian et al. [260] to overcome and assist the limitations of service delivery in ISP regarding deployment flexibility, cost, operational ease, and scalability. OpenFlow Random Host Mutation (OF-RHM) is a procedure to mutate the addresses of IP host with excessive randomness and speed, while preserving the integrity of configuration and reducing the overhead operation [261]. ElastiCon is a stretchy disseminated controller architecture wherein the pool of controllers shrinks or expands dynamically according to the traffic circumstances and the load that is moved across controllers dynamically [262]. GatorCloud is an architecture for cloud resource management which facilitates sharing resources among various service models dynamically. It uses balloon abstraction to encapsulate the related resources of the services and the execution context [263]. Snap is a packet processing framework that improves packet processing in comparison with conventional software router through utilizing the available parallelism on modern GPU [264]. An SDN framework called Odin has been introduced in order to present programmability in WLANS through simplifying the client management procedures [162, 265]. In Nelson et al. [266] SWAN system is presented to improve and increase the inter-data center network utilization through directing and managing centrally the traffic of every service and reconfiguring the data plane to accommodate the existing traffic demand frequently. FlowLog is a declarative programming language for developing SDN controller programs [267]:

R3: What are the current investigated security issues in SDN?

Based on our investigation of SDN security subject in SDN, we noticed that this subject should be further divided into two sub-questions:

R3.1. What are the security problems related to SDN architecture?

Several papers discussed security problems related to SDN architecture . As a new architecture, it is expected that such architecture will pose both security challenges and opportunities.

In research papers, there are some focused areas and concerns in this regard. We can summarize them as the following:

  1. 1.

    Several papers showed concerns related to OpenFlow communication protocol security and how much such protocol is secure or vulnerable for external intrusion. In particular, many authors pointed out that encryption method offered in OF protocol for the communication between the control and its switches (TLS) is left optional, and in fact many developed controllers do not use it (Namal et al. 2010; Kloeti et al. 2012; Benton et al. 2013; Meyer and Schwenk 2013). OF manual is further described that users can decide their own encryption method. We think that this is a security concern mentioned in many research papers and should be handled properly in the next OF versions.

  2. 2.

    The controller as a central security and control is another very serious security concern described in many research papers. The concerns are not only from security perspective but also from scalability and fault tolerance perspectives. This is why distributed controllers and load balancing approaches are proposed in many SDN research papers and as we saw in previous statistics where getting a major focus.

There are some serious concerns that if controller is compromised, then the whole network will be at risk as the controller in SDN contains the complete network picture and intelligence. In addition to distributed controller architecture proposals, there are other proposals to secure the controller and the communication with the controller through much secured encrypted channels.

  1. 3.

    Upper level applications or middle boxes can communicate and interact with the controller. This is another security concern where such applications can be used intentionally or unintentionally to compromise the controller or its modules. Another protocol in addition to OF should be proposed and made standard in this region to regulate the communication between upper level applications and the controller in such manner that prevent exposing controller resources.

  2. 4.

    SDN network includes a large number of traffic that is communicated between the controller and its switches. There are some serious concerns that DoS or flooding attacks can be made easy to flood SDN network with new flows from new sources. This makes all traffic be forwarded to the controller to make decision about which may eventually cause DoS. Effective methods are proposed to allow controller to monitor the possible occurrence of such DoS activities and be able to stop or counterattack it.

  3. 5.

    Middle man attacks or information leak problem is also another security concern especially as the controller sends control messages to OF switches remotely. If this channel is compromised, controller or legitimate hosts can be impersonated which may lead to serious information leakage.

Those are examples of security concerns listed in surveyed research papers related to SDN architecture.

R3.2. What are the security opportunities SDN can bring to networking, cloud computing, etc.

As we mentioned earlier, as a new architecture, SDN is posing both security concerns and opportunities. In this section, we will focus on some of the opportunities that were mentioned in surveyed research papers:

  1. 1.

    Existing research papers indicated that SDN can offer the ability to deal with security controls in completely different manners in comparison with traditional security controls (e.g., [211, 230, 252]; Clark et al. 2009; Naous et al. 2009; Katta et al. 2012; Wen et al. 2013). For example, SDN programmability feature may help build customized security services on demand. In other words, the same security service can be provided to the different customers or clients differently. Attributes related to this security control can be user defined. For example, an ISP may give home users of the Internet service the ability to run customized firewalls where users can decide bandwidth limitations, websites to filter, number of users to allow, rate limit traffic in a day or a month, and many other parameters that can be customized per user. This is largely possible since SDN architecture is flow based and not IP based. Network administrators can hence have more fine-grained control on traffic compared with traditional security measures.

  2. 2.

    In relation to flow-based management in SDN rather than IP management, SDN can allow network security measures to rely on more specific attributes other than IP, MAC addresses, or ports typically permitted or denied in traditional firewalls or IDSs. OpenFlow earlier versions allow 12 attributes in packet headers, and new OpenFlow protocol versions (i.e., 1.2 and above) have up to 40 different attributes in which flows can be defined, categorized, or filtered. Those extra attributes are related to the exact network protocol, dealing with IP version 6 and many other new attributes that can give network administrators more control on flow management.

  3. 3.

    Research papers indicated that most traditional security controls will need to be revisited based on SDN to evaluate the required changes and how could those security controls be modified to optimize the usage of SDN. SDN programmability and the ability to give users more controls on switches and network traffic seem to receive conflicting opinions from security perspectives. On one side, such control is an important tool with network and security administrators to have ultimate control and management in the network. On the other hand, allowing such information to be exposed may risk such information to be compromised by illegitimate users, and hence risk on the network can be far more serious in comparison with traditional networks that hide control and routing protocols in switches.

  4. 4.

    Insider threats are also getting more focused in SDN security (Juba et al. 2013; Popa et al. 2010). This is since an insider, intentionally or unintentionally, can have more power and control under OpenFlow networks in comparison with traditional networks. As we mentioned earlier, such power can play in both sides, positive and negative impacts.

Those are few of the security concerns and opportunities that are discussed in research papers of SDN security subject in particular.

R4: What are the challenges of SDN?

Although SDN provides evidences in facilitating, developing, maintaining, and providing automation to network management, there are technical challenges that can limit its operation and performance in cloud computing, information technology organizations, and networking enterprises. The following are examples of the barriers mentioned and described about SDN adoption:

  • SDN supports both centralized and distributed controller’s models. Having both models in SDN is considered as a challenge; several articles argued about the pros and cons of the SDN centralized and distributed models, i.e., the centralized control plane pledges the consistency of network status by offering only one management point. This brings one main limitation; the controller should update OpenFlow switches more than traditional routers, which might incur overload [213, 279].

  • Network visibility and management is another challenge that was addressed in the selected papers. In spite of the powerful monitoring tools that are provided by SDN, the debugging, troubleshooting, and enforcing security compliance are still considered hard missions in distributed SDN [269].

  • Many research articles explored the most important scalability concerns as a challenge of SDN; they determine and discussed different metrics that can potentially be affected as the network grows [220, 223, 270–272, 275, 277]. The centralized model can increase the cost of control plane scalability. Pooling all the activities in one node requires more computation power, data storage, and throughput to manage the traffic all that could increase the response time.

  • Deficiency of standards is another challenge that was addressed in the research articles. Although OpenFlow protocol provides only one specification for each version, still the variety of network hardware and software platforms drives providers and users to implement and deploy compatible OpenFlow libraries for each and every platform of OpenFlow implementation.

  • Like any new technology SDN, enterprises’ economic and necessary technical experts’ issues could be the main limitation of building and deploying it. Robustness, resilience, and scalability are limiting the SDN deployment in terms of logic centralization warrantees. Several articles showed that SDN could reduce reliability. This is largely due to the centralization of control functions into the controller.

Table 14.8 shows most of the SDN challenges and limitation issue that were addressed and discussed in several surveyed papers.

Table 14.8 Highlighted SDN challenges and obstacles
Full size table

R5. New Possible Opportunities of SDN

Cloud computing takes an important role in the market. The opportunity of having SDN to support cloud-based networks is investigated by several researches. The papers showed how SDN can be considered as a new supplementary technology for virtualization. In cellular network field, 35 articles out of 200 proposed SDN-based architecture as a solution for several networking issues. SDN is expected to improve how networks are developed, operated, and maintained. After scanning the selected papers, we identified the following five profits which an enterprise can gain by deploying SDN:

  1. 1.

    SDN provides Software-Defined Wireless Networking (SDWN) as a technology to supplement the wireless networks. It offers radio resource and mobility management, routing, and multi-home networking. Employing SDN functionalities to the relay between the home network and edge networks could solve multi-homing in wireless networks.

  2. 2.

    Realizing traffic offloading: Employing SDN architecture allows to aggregate offloading data centers in the mobile network and triggers the chosen traffic to these data centers without modifications to the functionality of network elements in the core mobile network.

  3. 3.

    New services are provided quickly and flexibly: SDN allows creating several VM instances, and the way SDNs can be set up is a far better complement to VMs than plain old physical networks.

  4. 4.

    Flexibility and comprehensive network management: SDN offers network experimentation tolerance. Even if one can exceed the limits forced by SNMP, the experiment can be done along with the new network configurations without being disabled by their consequences. Moreover, SDN divides the control plane (which manages the traffic) from the data plane (which forwards traffic based upon the decisions that the control plane takes).

  5. 5.

    Better and more granular security: VM’s management in dynamic and complex environments is very tedious. SDNs can provide the kind of fine-grained security for applications, endpoints, and BYOD devices that a conventional hard-wired network cannot provide.

Table 14.9 shows most of the SDN strengths and opportunities. The table demonstrates some published or preprint articles that addressed and discussed the mentioned opportunities.

Table 14.9 SDN opportunities
Full size table

R6: What are the most popular conferences and journals publishing about SDN?

Table 14.10 shows publications in SDN in the last 3 years (based on our selection, inclusion, and exclusion process).

Table 14.10 Number of published articles in each year
Full size table

Table 14.11 shows distribution of publications based on venues. Conferences get the large percentage of publications. As a new field, researchers want to publish their contribution early where, for example, publication in journals and magazines typically takes much longer time in comparison with conferences, workshops, or symposiums.

Table 14.11 Number of articles in each venue
Full size table

14.6 Mapping Demographics

Because IEEE Computer Society staff will do the final formatting of your paper, some figures may have to be moved from where they appeared in the original submission. Figures and tables should be sized as they are to appear in print. Figures or tables not correctly sized will be returned to the author for reformatting.

In demographic statistics, we aggregated results from the five indexing websites. Table 14.12 shows top authors published in our specific surveyed area. In all statistics, we did not include the complete counts in the tables, but on those in the top according to a cut off we decided in each table separately.

Table 14.12 Top authors in SDN by number of publications
Full size table

Interestingly that while Rexford is listed as the top author in this specific area, he is the first or the only author in only two papers out of the 17 included in our collection. Table 14.13 shows the top institutions publishing in SDN area within the list of papers that we collected.

Table 14.13 Top institutions publishing in SDN
Full size table

Table 14.13 shows that SDN is getting focused from universities ranked as top-ranked universities in the world. This is a typical trend for such universities focusing on new research areas. Table 14.14 shows top conferences or journals publishing in SDN. ACM SIGCOMM seems to be taking the lead in this category. We noticed however that many conferences and workshops accept papers for work in progress or for very short papers (1–2 pages). Possibly this is the trend given that this is a very new emerging area. We noticed also that publication cycle is very short and many conferences publish their papers before the time of the actual conference or event.

Table 14.14 Top SDN conferences
Full size table

14.7 Conclusion

This systematic literature review (SLR) investigated SDN literature and research dissemination. Five indexing agencies are surveyed for SDN research publications. First, we presented different challenges and opportunities that are evolving as a result of SDN emergence. Second, we highlighted active research areas in SDN according to the collected dataset.

Finally, we provided current and future research tracks in SDN. The large amount of publications in SDN given the relatively short amount of lifetime and the extensive industrial support to SDN showed that this area will continue to expand in both the academia and industry in the few coming years. SDN can act as an enabler or a steroid where most applications built on top of networks (e.g., security services, monitoring, distribution services) will have to evolve in response to the evolving architecture.