research papers on software defined networking

Software-Defined Networking (SDN): A Review

Ieee account.

• Change Username/Password
• Update Address

Purchase Details

• Payment Options
• Order History
• View Purchased Documents

Profile Information

• Communications Preferences
• Profession and Education
• Technical Interests
• US & Canada: +1 800 678 4333
• Worldwide: +1 732 981 0060
• Contact & Support
• About IEEE Xplore
• Accessibility
• Terms of Use
• Nondiscrimination Policy
• Privacy & Opting Out of Cookies

A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity. © Copyright 2024 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.

Review of Software Defined Networking: Applications, Challenges and Advantages

• Conference paper
• First Online: 03 November 2019
• Cite this conference paper

• Upendra Singh 12 ,
• Vikas Vankhede 13 ,
• Shyam Maheshwari 13 ,
• Devesh Kumar 13 &
• Narendra Solanki 13  

Part of the book series: Lecture Notes in Networks and Systems ((LNNS,volume 98))

Included in the following conference series:

• International Conference on Inventive Computation Technologies

905 Accesses

In the modern era of the internet, the network facilitates the exchange of information which makes communication simple and faster. Due to change in an environment of the network, traditional IP suffers from some issues such as its management in a dynamic environment is not easy, complexity increases, can’t tolerate fault, workload balance and not easily adapted. So, to overcome these problems of the network, the concept of the programmed network came into existence. Software-Defined Network (SDN) is a programmed network which is proposed as a solution to overcome the problems that traditional networking suffers. It uses a software application to make network programmed for network management and to improve its efficiency in terms of performance. This paper consists of a systematic review of software-defined networking (SDN), advantages and detailed survey of its applications in various fields like cloud-based services, security services, etc. Although SDN overcomes the issues that traditional IP faces but it faces few challenges related to reliability, security, and management. It presents a brief of past research that has been done in the field of SDN and the scope of SDN in the future.

• Software Defined Networking
• Software defined environment
• Programming languages
• Programmed network

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

• Available as PDF
• Read on any device
• Instant download
• Own it forever
• Available as EPUB and PDF
• Compact, lightweight edition
• Dispatched in 3 to 5 business days
• Free shipping worldwide - see info
• Durable hardcover edition

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Jammal, M., Singh, T., Shami, A., Asal, R., Li, Y.: Software defined networking: state of art and research challenges. Comput. Netw. 72 , 1–25 (2014)

Article   Google Scholar  

Sezer, S., Scott-Hayward, S., Chouhan, P.K., Fraser, B., Lake, D., Finnegan, J., Viljoen, N., Miller, M., Rao, N.: Are we ready for SDN? Implementation challenges for software-defined network. IEEE Commun. Mag. 51 , 1–8 (2013)

Google Scholar  

Sood, K., Yu, S., Xiang, Y.: Software defined wireless networking opportunities and challenges for internet of things: a review. IEEE Internet Things J. 3 , 1–12 (2015)

Mousa, M., Bahaa-Eldin, A., Sobh, M.: Software defined networking concepts and challenges. In: 11th International Conference on Computer Engineering and Systems (ICCES), pp. 1–13 (2016)

Rana, D.S., Dhondiyal, S.A., Chamoli, S.K.: Software defined networking (SDN) challenges, issues and solution. Int. J. Comput. Sci. Eng. 7 , 1–7 (2019)

Dorsch, N., Kurtz, F., Georg, H., Hägerling, C., Wietfeld, C.: Software-Defined networking for smart grid communications: applications, challenges and advantages. In: IEEE International Conference on Smart Grid Communications, pp. 1–6 (2014)

Dorsch, N., Kurtz, F., Wietfeld, C.: On the economic benefits of software-defined networking and network slicing for smart grid communications. NETNOMICS: Econ. Res. Electron. Netw. 19 , 1–30 (2018)

Mishra, S., AlShehri, M.A.R.: Software defined networking: research issues, challenges and opportunities. Indian J. Sci. Technol. 10 (29), 1–9 (2017)

Xia, W., Wen, Y., Niyato, D.: A survey on software-defined networking. IEEE Commun. Surv. Tutor. 17 , 1–25 (2015)

Nunes, B.A.A., Mendonca, M., Nguyen, X.-N., Obraczka, K., Turletti, T.: A survey of software-defined networking: past, present, and future of programmable network. IEEE Commun. Surv. Tutor. 16 , 1–18 (2013)

Jarraya, Y., Madi, T., Debbabi, M.: A survey and a layered taxonomy of software-defined networking. IEEE Commun. Surv. Tutor. 16 (4), 1–26 (2014)

Feamster, N., Rexford, J., Zegura, E.: The road to SDN: an intellectual history of programmable networks. ACM SIGCOMM Comput. Commun. 44 , 87–98 (2014)

Hakiri, A., Gokhale, A., Berthou, P., Schmidt, D.C., Thierry, G.: Software-defined networking: challenges and research opportunities for future internet. Comput. Netw. 75 , 1–31 (2014)

Nadeau, T.D., Gray, K.: Software Defined Networks, pp. 1–384 (2013)

Ramesh, S., Smys, S.: A software-based heuristic clustered (SBHC) architecture for the performance improvement in MANET. Wirel. Pers. Commun. 97 , 6343–6355 (2017)

Download references

Author information

Authors and affiliations.

Shri Govindram Seksaria Institute of Technology and Science, Indore, Madhya Pradesh, India

Upendra Singh

Institute of Engineering and Technology, DAVV, Indore, Madhya Pradesh, India

Vikas Vankhede, Shyam Maheshwari, Devesh Kumar & Narendra Solanki

You can also search for this author in PubMed   Google Scholar

Corresponding author

Correspondence to Upendra Singh .

Editor information

Editors and affiliations.

Computer Science and Engineering, RVS Technical Campus, Coimbatore, Tamil Nadu, India

Faculty of Electrical Engineering, Czech Technical University in Prague, Prague 6, Czech Republic

Robert Bestak

Departamento de Engenharia Informática, Universidade de Coimbra, Coimbra, Portugal

Álvaro Rocha

Rights and permissions

Reprints and permissions

Copyright information

© 2020 Springer Nature Switzerland AG

About this paper

Cite this paper.

Singh, U., Vankhede, V., Maheshwari, S., Kumar, D., Solanki, N. (2020). Review of Software Defined Networking: Applications, Challenges and Advantages. In: Smys, S., Bestak, R., Rocha, Á. (eds) Inventive Computation Technologies. ICICIT 2019. Lecture Notes in Networks and Systems, vol 98. Springer, Cham. https://doi.org/10.1007/978-3-030-33846-6_89

Download citation

DOI : https://doi.org/10.1007/978-3-030-33846-6_89

Published : 03 November 2019

Publisher Name : Springer, Cham

Print ISBN : 978-3-030-33845-9

Online ISBN : 978-3-030-33846-6

eBook Packages : Intelligent Technologies and Robotics Intelligent Technologies and Robotics (R0)

Share this paper

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• Publish with us

Policies and ethics

• Find a journal
• Track your research

An official website of the United States government

The .gov means it’s official. Federal government websites often end in .gov or .mil. Before sharing sensitive information, make sure you’re on a federal government site.

The site is secure. The https:// ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.

• Publications
• Account settings

Preview improvements coming to the PMC website in October 2024. Learn More or Try it out now .

• Advanced Search
• Journal List
• Sensors (Basel)

Software-Defined Networking: Categories, Analysis, and Future Directions

Mudassar hussain.

1 Department of Computer Science, University of Wah, Wah Cantt P.O. Box 47010, Pakistan

2 Department of Computer Science, COMSATS University Islamabad, Wah Campus, Wah Cantt P.O. Box 47010, Pakistan; moc.liamg@28hahsridan (N.S.); moc.liamg@azarnashoms (S.M.R.)

Rashid Amin

3 Department of Computer Science, University of Chakwal, Chakwal P.O. Box 48800, Pakistan

Sultan S. Alshamrani

4 Department of Information Technology, College of Computer and Information Technology, Taif University, Taif P.O. Box 21944, Saudi Arabia; as.ude.ut@hsamasus

Aziz Alotaibi

5 Department of Computer Science, College of Computers and Information Technology, Taif University, Taif P.O. Box 21944, Saudi Arabia; as.ude.ut@ibiatoza

Syed Mohsan Raza

Associated data.

Not applicable.

Software-defined networking (SDN) is an innovative network architecture that splits the control and management planes from the data plane. It helps in simplifying network manageability and programmability, along with several other benefits. Due to the programmability features, SDN is gaining popularity in both academia and industry. However, this emerging paradigm has been facing diverse kinds of challenges during the SDN implementation process and with respect to adoption of existing technologies. This paper evaluates several existing approaches in SDN and compares and analyzes the findings. The paper is organized into seven categories, namely network testing and verification, flow rule installation mechanisms, network security and management issues related to SDN implementation, memory management studies, SDN simulators and emulators, SDN programming languages, and SDN controller platforms. Each category has significance in the implementation of SDN networks. During the implementation process, network testing and verification is very important to avoid packet violations and network inefficiencies. Similarly, consistent flow rule installation, especially in the case of policy change at the controller, needs to be carefully implemented. Effective network security and memory management, at both the network control and data planes, play a vital role in SDN. Furthermore, SDN simulation tools, controller platforms, and programming languages help academia and industry to implement and test their developed network applications. We also compare the existing SDN studies in detail in terms of classification and discuss their benefits and limitations. Finally, future research guidelines are provided, and the paper is concluded.

1. Introduction

Traditional networks are complex and hard to manage because all the functionalities of the data, control, and management planes are vertically and tightly coupled in forwarding devices [ 1 ]. In traditional networks, the control plane, with the help of routing protocols, forwards data packets as per network policies. Due to this vertical integration and the tightly coupled nature of forwarding devices, network management becomes difficult, and performance tuning becomes challenging. Moreover, the network applications and services of the current information age have become more complex and demanding, so it is necessary that the Internet be able to evolve to address these new challenges. To resolve such issues, the idea of “programmable networks” has been proposed to facilitate network evolution. In this regard, two concepts, active networking [ 2 ] and programmable networks [ 3 ], were explored. Active networking refers to network intelligence (as opposed to typical packet processing), where network nodes have the capability of performing customized operations on packets. Programmable networks permit the controlling of network nodes’ behavior and flow control through software. Later, the 4D project [ 4 , 5 , 6 ] proposed a clean slate design that is based on four planes: decision, dissemination, discovery, and data. It emphasizes the separation of routing decision logic and protocols governing the interaction between forwarding devices. The decision plane has a network-wide view of the network topology and installs configuration commands at the data plane for communication. The dissemination and discovery planes provides efficient communication between the decision and data planes. Ethane [ 7 ] proposed a new network architecture for enterprises that allows network managers to configure and control the whole network by using a centralized controller. These research works proposed a clear foundation for separation between the data and control planes, which resulted in the introduction of software-defined networking (SDN). SDN provides a real-world implementation of a suite of networking software that allows a network to be centrally controlled. It is not the first and only solution that accepts separation and programmability. However, it has wide acceptance in both academia and industry due to the rapid innovation in both the control and data planes. A group of network operators, service providers, and vendors have created the Open Network Foundation (ONF) [ 8 ], which is an industrial-driven organization to promote SDN and standardize the OpenFlow Protocol (OFP) [ 9 ]. On the academia side, the OpenFlow Network Research Center [ 10 ] has been created, with a focus on SDN research.

SDN [ 11 , 12 , 13 , 14 , 15 ] is an emerging form of network that resolves these limitations by separating network control and management from the data plane to reduce complexity and increase network management. This separation of the control and data planes leaves network switches as simple forwarding devices. However, the network control is shifted to the centralized logical entity called the controller, which acts as the network’s brain and maintains a global view of the network and programming abstractions. It offers a programmatic control of the entire network and provides real-time control of underlying devices to network operators. The management plane specifies network applications, such as network policies, network monitoring, load balancing, and so on, which are implemented by the network administrator based on the application environment and the user’s requirements. In this way, network management turns out to be simple, which reduces network rigidness. All three of the SDN planes interact with each other by using application programming interfaces.

1.1. Application Programming Interfaces

Application programming interfaces (APIs) [ 16 ] are very important in SDN; they provide communication between the data, control and management planes. The well-known APIs are southbound APIs (SBI), northbound APIs (NBI), and in the case of distributed controllers, east/westbound APIs. These APIs are architectural components of SDN, and they are used to configure forwarding devices or network applications. The SDN layered architecture, including APIs, is shown in Figure 1 .

SDN system architecture.

Southbound API proposals.

• OpenFlow-Dependent SBI Proposals: These include OpenFlow-based SBI proposals with the addition of new features or in its newer versions. DevoFlow [ 17 ] modifies the OpenFlow model to permit network operators to focus on flow rules, which are essential for network management, by breaking the coupling between network control and global visibility. It helps to reduce internal communication between the control and data planes. The Revised OpenFlow Library (ROFL) [ 18 ] provides an API that offers much better usability by hiding details of OFP versions to make application development easier. It utilizes the extensible datapath daemon (xDPd) framework, which facilitates creating SDN data path elements. The hardware abstraction layer (HAL) [ 19 ] separates hardware-specific control and management functionalities from the forwarding devices in order to make legacy network nodes such as OpenFlow compliant. It results in decreasing the complexity of network devices, and the problem of vendor-specific features is resolved. OpenState [ 20 ] states that a central controller should not be provided with full control. It also proposes that the programmers can implement states in the forwarding devices instead of the central controller. Protocol-oblivious forwarding (POF) [ 21 ] offers a reactive mechanism that requires forwarding devices to extract keys and process packets by using packet headers, which leads to overhead. The programming abstraction datapath (PAD) [ 22 ] reveals the programmability of switch capabilities and offers SBI for optical switches. The open virtual switch database (OvSDB) [ 23 ] and OpenFlow configuration protocol (OF-Config) [ 24 ] build an association between the control and data planes and facilitate configurations in OpenFlow.
• OpenFlow-Independent SBI Proposals: P4 runtime SBI [ 25 ] helps to solve the problem of OFP. It is an open, extensible, customizable platform that offers a new way for the control plane to control forwarding devices and solves the limitations of OFP. Forwarding and control element separation (ForCES) [ 26 ] aimed to replace OpenFlow. It enables the separation of control and forwarding elements that are in the same physical device without modifying the traditional networking architecture and without involvement of an external controller using a logical function block. OpFlex [ 27 ] supports communication between the controller and data plane; however, its provision of service is different in comparison with OpenFlow. It resolves the scalability problem by distributing load to the forwarding devices. NetConf [ 28 ] uses a remote procedure call paradigm to manage and configure network devices remotely. It was already present before the emergence of SDN and offers a very simple API to send and receive full or partial configuration datasets.
• OpenFlow-Based SBIs Emerging Technology: Sensor OpenFlow (SOF) [ 29 ] is upgraded as per the specifications of low-capacity sensor nodes. It is based on OpenFlow and aimed to address the challenges of flow and congestion control. It offers the ability to redefine flow tables as per the specific addressing schemes of wireless sensor networks (WSN) to install flow rules on sensor network devices. Software-defined wireless networks (SDWN) [ 30 ] aimed to decrease energy consumption in WSNs with the help of duty cycles and in-network data aggregation. Duty energy minimizes consumption by turning radio off in case of idle periods, and in-network data aggregation is also helpful in this regard. Its protocol architecture utilizes both generic and sink nodes. In addition, it supports elastic flow rules due to its nature, unlike traditional OpenFlow. SDN for wireless sensors (SDN WISE) [ 31 ], implemented in OMNet++, aimed at reducing sensor nodes’ communication with the controller, in addition to making sensor nodes programmable. SOF and SDWN utilize a central controller to provide theoretical details; however, SDN-WISE is based on a distributed controller paradigm, using an ONOS controller [ 32 ] to provide services based on practical implementations.
• Northbound API: Control and management planes use NBI to provide programmability to application developers. NBI is very important with respect to the ability of SDN adoption to support variety of SDN applications. A wide range of NBIs are offered by current controllers and programming languages due to the lack of standardization. In addition, some programmers and many controller platforms use the REST API as NBI. One of the initiatives of ONF is the Northbound Interface Work Group (NBIWG) [ 33 ], which was formed with the intention of standardizing NBI.
• East/Westbound API: Inter-controller communication of SDN domains is established using eastbound API. Westbound API is responsible for communication from the legacy domain to SDN domain. Central network control is the key feature of SDN; however, the single controller can handle only a limited number of forwarding devices. To accommodate the exponential increase in forwarding devices and for large-scale networks, distributed controllers have become a requirement. Eastbound APIs are used to import/export information among distributed controllers [ 34 , 35 , 36 ], and westbound APIs enable communication between legacy network devices and the controllers [ 37 , 38 , 39 ].

1.2. Network Configuration and Flow Rules Installation

Computer networks are mainly configured based on access control list (ACL) policies and routing protocols. The ACL policies are the set of rules that instruct network devices to function as per the requirements of users, applications, and/or organizations. The routing protocols help to find best path between source and destination. In SDN, the ACL policies are configured at the network control plane, and based on those policies, flow rules are generated and installed at forwarding devices. These policies often change in computer networks as per the demands of hosts or changes in network topology to allow or deny specific communication [ 40 ]. The SDN programming languages (for example, Pyretic [ 41 ], Frenetic [ 42 ], and Maple [ 43 ]) help to specify ACL policies as per the application environment via parallel and sequential composition operators for efficient implementation of policies. Whenever a host initiates a communication process, the forwarding device (switch) checks flow rules for that communication in its flow table. If a flow rule does not exist, then it sends a digest packet to the controller. The controller calculates the best path between the source and destination host according to the network topology and ACL policy. The flow rules are installed along the computed best path, and based on these flow rules, communication takes place. The switch stores these flow rules in its flow table until the timeout value expires due to inactivity. There are two types of timeout values. The first type is soft timeout, which states that the flow rule is deleted from the switch flow table if it is not used for a defined number of seconds. The second type is hard timeout value, which states that the flow rule is deleted a after certain number of seconds [ 44 ]. These timeout values depend on the application environment and controller platform [ 45 ].

The flow rules are installed based on reactive, proactive, and hybrid mechanisms [ 46 ]. In a reactive mechanism, when a packet is received at the switch, it looks up its flow table to initiate the forwarding process. In the case of flow rule matching, the respective packet is forwarded as per flow entry. However, in the case of non-matching, it sends a digest packet to the controller, which reacts by consulting the network topology, routing protocols, and ACL policies. It computes and installs the flow rule along the path between the source and destination via packet-out messages. All subsequent packets follow the same path without intervention from the controller. In this approach, only required flow rules are installed as per the request from communication hosts, so it helps to reduce the load in the flow tables of the data plane. This, in turn, efficiently utilizes ternary content-addressable memory (TCAM) resources. In a proactive approach, the flow rules are pre-populated, that is, populated before the first packet of a flow arrives at a switch based on network policies, routing protocols, and network topology [ 32 ]. This approach reduces the flow rules setup delay as well as the number of signaling messages due to the predefined actions and their flow rules installation before the arrival of packets. Therefore, the packets are forwarded just by matching flow rules, which saves a large amount of time. However, the TCAM resources of switches are not efficiently utilized due to the installation of flow rules for which communication is not desired. The hybrid approach is combination of reactive and proactive and is flexible in the sense that it includes the best characteristics of both proactive and reactive approaches. It offers flexibility and robustness and helps to reduce communication delays.

1.3. SDN Advantages

SDN has many advantages over traditional networks owing to the lower maintenance, ease of management, and implementation of ACL policies [ 47 , 48 ]. It simplifies network management and control by managing the whole network from the centralized controller. Moreover, forwarding devices (switches) become simplified as network intelligence is shifted to the controller; thus, these devices are left with very basic functionalities as they only need to act according to the instructions from the controller and do not require understanding and processing heterogeneous algorithms and protocols. In addition, the forwarding devices also help the controller for route computations and link/node monitoring, along with other tasks such as network management and diagnostics [ 49 ]. SDN has numerous advantages compared to traditional networking. Some of them are defined below:

• SDN Centralized Management and Control: SDN’s centralized management and control of networking devices helps to reduce complexity.
• Directly Programmable: The network control plane can be directly programmable as it is separated from the data and management planes.
• Easier Network Management and Automation: It offers easier network management and automation via common APIs to program the applications due to the provision of abstractions by the controller platform.
• Rapid Innovation: It allows rapid innovation, as there is no need to configure each device and no need to wait for new releases from vendors.
• Programmability: The network is programmable with the help of network applications that are installed at the control plane to offer vendor independence.
• Flexibility: It provides a flexible network architecture that protects existing investments while future-proofing the network.
• Flow-Rules-Based Forwarding: Forwarding decisions are based on flow rules (instead of destination-based addresses), which broadly implement flow rule matching and action criteria.
• ACL Policy Implementation: It allows network administrators to apply ACL policies at a more granular level in a highly abstracted automated fashion.
• Usability: It provides better user experience by centralizing network control and making state information available to higher-level applications as it can adopt dynamic user needs easily [ 50 , 51 , 52 , 53 ].
• Security: It provides centralized security control, which improves network visibility through security management. In addition, it offers robust control over network infrastructure to develop efficient and effective security mechanisms [ 54 , 55 ] to detect and prevent security attacks [ 56 , 57 ].
• On-Demand Quality of Service: It utilizes the SDN central control intelligence for the aggregation of services from long-term evaluation (LTE) and the wide area network (WAN) to tackle the increasing computational demands of mobile users [ 58 ].
• Traffic and Resource Categorization in Edge Network: The collaboration of network function virtualization (NFV) and SDN in virtualized network infrastructures (multiple NFV, virtual network function (VNF), service function chaining) provides a customized QoS for residential network requests via differentiated treatment of each clustered and tagged piece of traffic in the edge network. Traffic encompasses audio and video streaming. SDN assists in the realization of differentiated behavior of underlying hardware network resources [ 59 ].
• Mobility Support for Internet of Vehicles (IOV): SDN enables intelligent remote clouds for the computation of tasks offloaded by speedy vehicle to the roadside unit (RSU). The controller supports the RSU for implementing the communication path between the RSU and fog node with adequate resources in a predictive fashion. Consequently, the fog node capabilities log at the controller tends to the optimal computation of IOV jobs by fog nodes [ 60 ].
• Topology Discovery: SDN has centralized services for event-based topology discovery. Tree exploration discovery protocol (TEDP) outperforms the OpenFlow protocol and standard link layer discovery protocol (LLDP) in terms of the reduction of extra packets for topology discovery. The tree exploration discovery protocol (TEDP) leverages the topology graph mapping by using the probe packets that are responsible for signaling the SDN controller to a single forwarding device. As a result, the discovery mechanism is optimized in SDN compared to LLDP, which introduced load in IP networks [ 61 ].
• Load Balancing Support in Future Networking: Research work comprises enabling the SDN infrastructure among the multiple NFV nodes and service function chaining aiming to reduce the delay of state migration of VNF. Concretely, the objectives are to cope with the limited resource capabilities of NFV nodes, meeting the desired QoS by infrastructure, and ensuring the least end-to-end delay for computational states migration by confining the OpenFlow-enabled devices’ capabilities in 5G core networks [ 62 ].
• Fault Localization: In SDN, centralized management is used for localizing the failure and reconfiguration help to localize faults. It handles failures in a proactive fashion based on the prediction of service unavailability [ 63 ].
• Programmable Reachability Optimization: SDN handles firewall problems in term of conflicting rules automatically. Similar research works offer improvements with the least computational overhead in reachability optimization and conflict debugging problems [ 64 ].
• Support for Cellular 6G Network: Future networks such as 6G require SDN-enabled softwarization and management for remote and machine learning application decision-aware re-configurations in network resources [ 65 , 66 , 67 ].
• Security-Aware Communication in Future Autonomous Networks: Softwarized policy implementation architecture can enhance the security among autonomous systems that have the least human interactions, and consequently, it can mitigate the security risk of inter-domain communication [ 68 , 69 ].

1.4. Organization

The rest of paper is organized as follows. Section 2 compares network testing and verification studies, which look at mechanisms for testing and debugging techniques. Section 3 includes flow rule installation mechanisms that comprise reactive, proactive, and hybrid flow rule installation mechanisms. In Section 4 , network security and management issues related to SDN implementation in different scenarios are discussed, along with solutions to the problems. Section 5 comprises memory management studies, which help to utilize precious TCAM resources in an efficient way. Section 6 includes emulators and simulators for SDN that help to implement, test, and simulate research problems. Section 7 comprises SDN programming languages, which facilitate programmers to develop network applications for effective communication. Section 8 consists of SDN controllers that provide a platform to control the data plane by installing flow rules via southbound APIs and network applications via northbound APIs. The categorization hierarchy is shown in Figure 3 . Section 9 discusses existing SDN studies. Finally, Section 10 includes the future research guidelines, and Section 11 concludes this paper.

SDN studies categorization hierarchy comprised of seven sections ( Section 2 , Section 3 , Section 4 , Section 5 , Section 6 , Section 7 and Section 8 ).

2. Network Testing and Verification

NDB [ 70 ] is a network debugging tool to debug SDN via breakpoints, watches, and packet backtraces. It works like GNU debugger (GDB) [ 71 ], which pauses execution at a breakpoint and shows the sequence of events that led to that breakpoint. Proxy and collector are its two major components. The proxy creates a postcard message received from the data plane and sends it to the control plane. On receiving this message, the collector saves postcards and produces backtrace for the listed data packets. Finally, by using the hash table data structure, the collector keeps the postcards from where these can be recovered effectively.

Veriflow [ 72 ] detects network-wide invariants in real time and generates alerts or blocks the occurrence of events. On generation of flow rules from the controller, these flow rules are sent to VeriFlow for checking the network-wide invariants. It generates a notification on detection of network-wide invariants for the network admin or the flow rules are blocked. Otherwise, the flow rules are sent to the data plane. It verifies the flow rules for network-wide invariants in the following three steps. First, the network is segmented in a collection of equivalence classes (ECs) by using network routing policies. Secondly, VeriFlow creates individual graphs for the specific equivalence class that denotes the respective network behavior. Thirdly, with the help of these graphs, the status of the network invariant is identified. It stores network information, for example, ACL policies, in trie data structures [ 73 ] and computes ECs in a systematic way. In addition, other research works [ 74 , 75 , 76 ] have also resolved issues of debugging and testing in traditional as well as SDN networks. These can detect network anomalies, ensure data plane consistency [ 77 , 78 ], and remove conflicts of different network applications to execute in a parallel manner [ 79 ].

In [ 80 ], the problem of flow rule installation from controller to switches is addressed. Due to this problem, the packets may deviate from their intended paths, which results in access control violations. The rule enforcement verification (REV) mechanism enables the controller to ensure the correct installation of flow rules along the correct path at the switches. It proposes a compressive message authentication code (MAC) to compress switch-to-controller communication traffic, which reduces a significant amount of bandwidth cost. Finally, it presents a heuristic flow selection algorithm, which allows the controller to verify many fewer flows for rule coverage. This results in avoiding adversity to the temper flow rule installation, thereby ensuring proper implementation of access control. NICE [ 81 ] detects network-wide invariants via model checking and symbolic execution. To detect network-wide invariants, NICE generates a stream of packets under various conditions to test SDN. In SDN, the details of topology, including switches and hosts, are available at the controller. After that, the space of possible system behavior and network-invariant conditions are tested. The required search strategy can also be configured by the programmer. NICE provides an output of instances of network invariants. Additionally, it provides traces of the inevitable consequence of property violations to reproduce them.

FPB [ 82 ] offers an efficient buffer management scheme at the data plane to avoid packet disorder and minimize the packet drop ratio by forwarding only the first packet of a flow to the controller while subsequent packets are buffered. HSA [ 83 ] is beneficial for system admins, as they can statistically examine their networks for invariants, for instance, network violations, black holes, loops, traffic isolations, and so on. HSA has the ability to check various hosts, network traffic, and the isolation of users. For example, it can provide details regarding questions such as “Can host A be prevented from talking to host B?” and so on. In this tool, a geometric approach is opted for as generalization for packet classification. PyResonance [ 84 ] utilizes the Pyretic language to implement state-based network policies. It uses Pyretic composition operators to express these policies and to compose multiple tasks by determining the state of their forwarding behavior with the help of a finite state machine. In this way, multiple independent states can be defined along with their forwarding behavior to handle the state change of multiple events.

PGA [ 85 ] provides automatic and conflict-free policies, for example, network policies, load balancing [ 86 ], and so on. It examines various network policies that are individually stated for any conflict. In different situations, network policies conflict with each other due to various perspectives. The graph composition is very helpful to express conflict-free network policies. As a next step, these policies are forwarded to a graph composer through a PGA user interface (UI). It resolves conflicts or gives some possible suggestions to the network admin in this regard. Finally, it generates error-free/conflict-free graphs. A service function chain-based approach to specify and verify ACL policies is presented in [ 87 ] to detect anomalies in ACL policies prior to deployment. In order to achieve the desired goal, the forwarding policies are formally represented, and a set of anomalies are detected against the set of flow rules for the respective policies. In addition, it also provides a provision for network administrators to specify their own anomalies. The results state that the proposed approach can verify anomalies of a reasonably sized network in milliseconds. Moreover, the research works in [ 75 , 76 ] are useful to troubleshoot, debug, and detect anomalies in communication networks.

Summary and Lessons Learned

The summary of network testing and verification studies are presented in Table 1 , and the following conclusions are drawn based on these studies. NDB [ 70 ] helps to debug SDN networks via breakpoints and packet backtraces. These primitives help in locating the order of events that led to error conditions. Though NDB can identify error conditions, it does not fix the error conditions. VeriFlow [ 72 ] checks network invariants in real time and generates an alarm or blocks these events from occurring. It checks network invariants in real time. However, it does not work in multi-controller architecture, and its verification process does not support delay-sensitive applications in which flow rule installation is continuously in flux, which is most likely desired for the least delay in forwarding devices. NICE [ 81 ] uses model checking and symbolic execution to detect bugs and invariant conditions in SDN applications. However, it is unable to test a controller implemented in the same language. FPB [ 82 ] provides an efficient buffer management mechanism at the switch level to avoid per-flow packet disorder, which helps to minimize the packet drop ratio. HSA [ 83 ] facilitates network administrators to statistically analyze their networks for network-wide invariants. However, it only works for static networks and lacks the ability to detect network policy change with dynamic change in ACL policies.

Summary of network testing and verification studies.

PyResonance [ 84 ] utilizes the composition operator of the Pyretic language to implement state-based network policies to predict a possible network’s forwarding behaviour. PGA [ 85 ] provides automatic and conflict-free policies by examining various network policies that are individually stated for any conflict. In PGA, the focus is on implementation of various policies in such a way that conflict does not occur. The research works [ 75 , 76 ] debug traditional as well as SDN environments to detect network anomalies, ensure consistency of the data forwarding plane [ 77 , 78 ], and allow several applications to run in parallel in a non-conflicting way [ 79 ]. However, all these mechanisms lack the ability to detect network policy change and delete conflicting flow rules along with installation of new flow rules as per new network policies to avoid packet violations. There is still a need to develop tools that can detect bugs in real time, along with the mechanisms to correct those bugs. This will help to avoid network inconsistencies, which will result in increasing network efficiency and QoS.

3. Flow Rule Installation Mechanisms

ORPP [ 88 , 89 ] provides two flow rule placement frameworks: OFFICER and aOFFICER. It helps to define and install flow rules at the data plane by following all technical and non-technical requirements. The first framework, called OFFICER, helps to define and install flow rules for the set of known requirements at a specific time internal. The second framework, aOFFICER, helps to compute and install flow rules for unknown sets of requirements, which vary over a specific time interval. Both these frameworks are quite useful and effective to place flow rules at the data plane. vCRIB [ 90 ] provides a mechanism that proposes an abstraction for specifying and managing flow rules for network operators at data center networks. In addition, in order to achieve better performance and resolve scalability issues, it helps to partition and install flow rules at hypervisors and switches. DevoFlow [ 17 ] presents a model to modify the OpenFlow model that permits network operators to focus on flow rules, which are essential for network management, by breaking the coupling between network control and global visibility. This mechanism helps to reduce internal communication between the control and data planes. Firstly, it minimizes the need to transfer statistics for tedious flows. Secondly, it minimizes the need to invoke the control plane for most flow setups. This helps to maintain a certain level of visibility by minimizing communication overhead between the control and data planes. However, the prototype is not simulated on actual packets.

Infinite CacheFlow [ 91 ] proposes a hybrid switch design that depends on flow rule caching to increase the flow rule tables space of switches at quite a low cost. However, it may result in more packet violations for flow rules that are stored at the data plane if corresponding ACL policies change at the controller. SwitchReduce [ 92 ] proposes a technique with the assumption that the number of flow match rules at any switch should not exceed the set of unique processing actions to decrease the switch state and controller involvement in SDN. The proposed approach can reduce flow entries up to 49% on first hop switches, and up to 99.9% on interior switches. In addition to that, flow counters are also reduced by 75% on average. It shows some failures due to topology changes. However, analysis of packet violations in case of change in policy is not performed on larger data centers. In [ 93 ], a cache algorithm strategy to store flow rules at switches called “least recently used" (LRU) is proposed, which reduces communication overhead between the control and data planes. This technique helps to avoid the cache-miss problem by keeping recently used flow entries in the switch flow table, which increases the flow entry matching ratio. This approach also ignores the case when network flow rules change for the flow entries present at the data plane.

In [ 94 ], a flow rule multiplexing approach is proposed that optimizes both the flow rule allocation as well as the traffic engineering. It works by installing identical set of flow rules at different calculated paths for a whole session instead of installing at each switch. It is tested via the ITALYNET network topology, and results reveal that the proposed mechanism saves TCAM resources and guarantees high QoS satisfaction. DomainFlow [ 95 ] presents a flow level control and granularity-based mechanism in ethernet switches by using the OpenFlow protocol. This research utilizes exact matching and network slicing to enable practical flow management. It only supports a limited number of flows with commodity switches and cannot be implemented with a large number of flows. SourceFlow [ 96 ] presents a mechanism that can handle many flows without affecting flow granularity, in addition to minimizing the problem of costly and power-consuming search engine devices from the core nodes. Moreover, it facilitates growing networks without compromising scalability. In [ 97 ], an SDN-based proactive flow rules installation mechanism is proposed for efficient communication in the Internet of things (IoT). It resolves the problem of flow installation delay as well as congestion due to packet-in messages, which save energy and other potential resources of network nodes.

In SDN, flow rules are installed at the data plane based on exact matching [ 98 ] or wildcard-based matching [ 99 ]. The wildcard-based matching improves the reusability of flow rules and reduces packet-in messages. It improves scalability at both the data and control planes. However, in the case of exact matching, almost every flow passing the switch will generate a packet-in message to the controller, which exhausts precious resources. To resolve this problem, some researchers suggest using a load-balancing mechanism by installing proactive flow rules on multiple switches [ 100 ] or reactive caching flow rules in each switch. In [ 101 ], an SDN-based wildcard rule caching mechanism, namely caching in buckets (CAB), is proposed by partitioning the field space into buckets and caching those buckets along with respective flow rules for efficient flow rules placement. This mechanism resolves the flow rule dependency problem with much less overhead, along with reducing flow setup time and saving network bandwidth and flow setup requests. In SDN, most of the operations are performed at the central controller, such as network topology management, flow rules installation, load balancing, and so on. These tasks sometimes overburden the controller, which becomes unavailable for some required operations. DIFANE [ 102 ] is a solution to this problem in which most of the functionality is placed on the network switches. For this purpose, the controller delegates the flow rules to some of the network switches that are called authority switches. These switches give the flow rules to the other switches for a specific path. In this way, entire-network communication becomes possible.

Mobi-Flow [ 103 ] presents a system architecture for the movement of mobile nodes in SDN by using two components: path estimator and flow manager. The path estimator helps to find the possible positions of end users in the network based on the location history of the node. For this purpose, we keep track of the previous positions of the nodes in the network in the database. By using the order-k Markov prediction method, the next possible position of end users is predicted. If we have possible location information of the end user, then the flow manager determines the set of access points in the path for communication between source to destination. In [ 104 ], a novel technique is proposed to install flow rules at the SDN data plane before reaching packets at network devices. In SDN, it sometimes happens that subsequent data packets arrive at the switches where flow rules are not found, causing the discarding of packets. To solve this issue, a new technique is proposed that computes packet arrival delay and flow rule installation time. After this computation, if there is a delay between flow rule installation and packet arrival, then some delay is introduced to the packet at the predecessor switch.

In the current research work, in order to improve the flexibility and scalability of the entire network, a novel mechanism is proposed in which network policies are deployed on the network devices in a wildcard format. Only the most important policies are cached in the flow table, while unnecessary policies are removed as soon as possible. By using this mechanism, the risk of flow table overflow is reduced, and it also simplifies the network policy enforcement. The wildcard used in this technique requires a standard way of being adopted in the entire network. To cope with this problem, a network-wide wildcard rule engine is introduced for SDN that is known as BigMac [ 105 ]. BigMac works by advertising a layered model to publish the higher-level network policies. The policy model consists of a big switch abstraction and a logical network plane that specifies the different forwarding and management policies. When a new flow needs to be installed, the policy caching and mapping engine of BigMac is accessed to install flow rules on the entire path. Similarly, when scheduled traffic needs to be forwarded, BigMac deploys the requested flow rules on the entire path. The research works in [ 106 , 107 ] proposed mechanisms to effectively install flow rules at the data plane in case of policy change without packet violations due to old installed flow rules as per old policies. To implement these mechanisms, the generated flow rules as per policies are cached at the controller. In case of policy change, the proposed mechanisms detect this change and compute the shortest path to install the computed flow rules, in addition to deleting the old flow rules. ROCA [ 108 ] proposes a novel mechanism to detect and resolve network conflicts along with policy overlapping for effective communication in SDN. The proposed approaches help to resolve network policy conflicts and efficiently install flow rules at the data plane.

The summary of flow installation mechanisms is presented in Table 2 , and we draw the following conclusions based on these studies. ORPP [ 88 , 89 ] resolves the problem of the placement of flow rules by using two frameworks: OFFICER and aOFFICER. Both frameworks provide efficient mechanisms to install flow rules. vCRIB [ 90 ] provides abstraction to define and manage flow rules for data center operators by portioning and placing flow rules on switches and hypervisors. DevoFlow [ 17 ] helps to amend the OpenFlow protocol by allowing network operators to focus on only selected flows for network management to reduce overhead between the control and data planes. Infinite CacheFlow [ 91 ] solves the issue of the limitation of flow rules at switches due to the limited TCAM resources by proposing a hybrid switch design (hardware and software). SwitchReduce [ 92 ] minimizes the switch state and controller involvement in SDN. The mechanism in [ 93 ] reduces the communication overhead between controller and switches by storing flow rules at the data plane. In [ 94 ], a flow-rule-based multiplexing approach is proposed, which optimizes both the flow rule allocation as well as the traffic engineering. DomainFlow [ 66 ] presents a flow-level control- and granularity-based mechanism in ethernet switches by using the OpenFlow protocol. SourceFlow [ 96 ] presents a mechanism that can handle many flows without affecting the flow granularity, in addition to minimizing the problem of costly and power-consuming search engine devices from the core nodes.

Summary of flow rules installation mechanisms.

In [ 97 ], a proactive flow rules installation approach is proposed for efficient communication in the Internet of things (IoT), which resolves the problem of flow installation delay and congestion due to packet-in messages. DIFANE [ 102 ] proposes a mechanism of relaxing the control plane by sharing control plane tasks with network switches. For this purpose, the controller delegates the flow rules to some of the network switches that are called authority switches. These switches give the flow rules to the other switches for a specific path. In this way, entire-network communication becomes possible. All these mechanisms help in installing efficient flow rules at the data plane, better utilizing precious TCAM resources, reducing communication overhead between control and management planes, and minimizing the communication load on the controller. These approaches help to install and manage flow rules at the data plane, reducing the load on the controller and effectively utilizing TCAM resources in SDN. There is still a need to investigate flow rule installations by utilizing proactive, reactive, and hybrid mechanisms in the case of ACL policy change to avoid maximum packet violations.

4. Network Security and Management

In this section, we discuss network security and management strategies in SDN. In [ 110 ], a token-based authentication mechanism is proposed that guarantees exclusive access of network resources to a certain flow for which the user/app has made the reservation. The proposed SDN-based system automatically reserves the resources of the users/apps for certain flows and creates a strong binding between them. Moreover, it resolves the reservation problem of dedicated access to specific resources in distributed environments and high-speed networks. In [ 111 ], the problem of network verification of middleboxes (for example, caches and firewalls) is proposed by checking all possibilities to verify the network reachability properties as per ACL policies. It works by slicing complex networks into small networks according to the correctness properties of network-wide verifications. In [ 112 ], a troubleshooting workflow is presented that is comprised of two phases. In the first phase, a binary search through the control stack is conducted to check for the occurrence of mistranslation. In the second phase, the scope of those elements that are responsible for the invariant violation is reduced. In this way, it makes it easy to identify the root causes of bugs, which helps network admins to troubleshoot their networks in an effective manner.

In [ 113 ], a priority-based flow rules security problem is highlighted, and a solution to the identified problem is presented. The problem is that the low-priority malicious flow rules can manipulate the whole OpenFlow network by making the high-priority flow rules fail. This, in turn, affects the whole data communication process. To solve the identified problem, the authors proposed a solution that is called switch-based rules verification (SRV). It works by leveraging the SDN controller to obtain the overall network view of the whole topology and detect the malicious flow rules. On detection of a malicious flow rule, the SRV module forwards warning messages and refuses the identified flow rule instantly. This solution helps to detect a large number of flow rules in an efficient way. In [ 114 ], a framework comprised of actor-based modeling is presented for network verification in SDN. In this framework, the network behaviors are predicted on the basis of the network application’s behaviors and existing model’s correctness properties. The actors in this model are the basic unit of computation, which contain their own memory and have a communication mechanism using asynchronous messages.

In [ 115 ], a formal-model-based reverse update mechanism is presented that ensures the maintenance of flow rules characteristics during the transition time in such a way that in-transit packets are processed at the next hops by the same or the latest ACL policy. In addition, it provides a per-packet consistency relaxation concept in the data plane and offers a consistent and efficient policy update technique. This model is compared with two phase update schemes [ 78 ], and the results suggest that the proposed model provides much better performance by minimizing overheads while maintaining consistency in flow tables and reducing complexity with the help of wildcard for the composition of flow rules. In communication networks, attackers often attack networks via bandwidth and system/application resource utilization, which leads to the popular denial of service (DoS) attack. How to detect such kinds of attacks is a very interesting research topic in networking. In SDN, deep learning algorithms are implemented according to the information received from the controller to model the attack behaviors. In [ 116 ], a distributed DOS (DDOS) attack model is created in Mininet Emulator and Floodlight SDN controller by combining the support vector machine (SVM) classification algorithms. This model detects DDOS attacks with an accuracy rate of 95.24% on a limited number of flow rules. In [ 117 ], a network management approach called “Smart-Net System” is proposed in which each data plane device keeps a flow rule in its flow table. If a packet reaches the data plane for the flow rule that exists in the flow table, then it is forwarded to the controller. The controller verifies the behavior of that packet and takes preventive measures to avoid attacks. In [ 118 ], a software-defined security (SDS) architecture is presented that is open and universal. It offers an open interface for security services, devices, and management, which is quite helpful for network security vendors to implement network security products and solutions. In this research work, various attack types to which networks can be vulnerable are analyzed, which is helpful for disabling such attacks by modifying the security configuration mechanism at the server.

The trend of increasingly massive IoTs and continuous streaming traffic is driving the demand for increasing computations. Cloud–fog hybrid systems support delay-intensive applications in a distributed computing manner. On the other hand, SDN supports various network infrastructures and inter-controller communication models (flat, horizontal, vertical, hybrid, or T-model) for distributed network management [ 119 ]. In addition, the vulnerability and consistency challenge in distributed architecture is more likely to be seen, in contrast to central control. Currently, to support the applications in 5G networks and beyond, the SDN distributed frameworks need to be more sophisticated [ 120 ]. Rahman et al. [ 121 ] proposed SmartBlock-SDN for efficient resource management and security assurance in blockchain-enabled IoT networks. The proposed framework addresses the challenge of distributed control security and energy-efficient cluster head selection in controllers. SmartBlock-SDN is mapped for a layered approach (IoT, edge, cloud), and cloud-enabled blockchain is considered to cope with the various common network vulnerabilities. Distributed homogeneous controllers and enforced network policies are recorded using immutable blockchains. This stored policy configuration can be accessed using the REST API for various operations in line with network security and resource management. To address flooding attacks, BSDNFilter and blockchain-enabled SDN is proposed in [ 122 ]. This work reduces the data packet violations in the SDN network. By employing trust-based filtration, the proposed works outperform a realistic industrial network against network security attacks. In [ 123 ], a BMC-SDN architecture is proposed to confine the SDN and blockchain in a network, where control is distributed for failure tolerance and redundant control resources. The proposed work employed blockchain for redundant controllers in various segregated domains. East/west (inter-controller) communication and network operations are recorded using blockchains.

The resource management shortcoming of distributed computational resources (such as NFV, data centers, fog nodes at edges in fog computing) is that energy, storage, and computational resources are limited. With the increase of massive IoT, the 5G and beyond networks will employ more constraints in their resources. 5G mainly has three service use cases: ultra-reliable and low-latency (URLLC), massive machine type computing (mMTC), and enhanced mobile broadband (eMMB). In addition, 6G is a revolutionary initiative in the history of the wireless network, which promises to support a wide geographical region with ultra-high data rates, massive enabled IoTs, connected drones, virtual reality, and network autonomy (by leveraging the machine learning components in the pipeline) [ 124 ]. SDN softwarization, southbound interface, east/west interface and on-the-fly management aspects can support the 5G and 6G networks to support a wide area of applications and massive IoTs across the globe. The aspect of resource-limited nodes of edge networks requires efficient resource provisioning in the network for QoS. Phan et al. [ 125 ] proposed a dynamic job-offloading mechanism among resource constraints for fog nodes. To enable intelligent offloading for appropriate fog nodes, the SDN controller is utilized, which can support the offloaded task at a minimum cost. The controller can dynamically investigate the resource capabilities, link congestion, and network statistical log files. Using computational offloading among fog nodes decreases the end-to-end latency, traffic detouring to oblivious links, and fog computational resources. In [ 126 ], a software-defined network function virtualization (SDNFV) network is presented, in which stateful firewall services are deployed as VNFs to increase network performance, security, and scalability. It utilizes machine learning algorithms to identify potentially malicious linkages and probable attack targets.

To handle a TCP SYN attack, FUPE is proposed in [ 127 ], which handles DDOS attacks in a distributed environment. It integrates SDN into its architecture for security objectives. FUPE implements the security-aware task scheduling at the fog gateway. FUPE amalgamates the multi-objective particle swarm optimization algorithm and fuzzy logic for security enhancement. An SDN central resource management unit helps the FUPE with instantaneous decisions in IoT–fog networks. To maintain the security status, FUPE assigns a trusted user’s application tasks to a trustworthy fog computational device in its scheduler architecture. The authors in [ 128 ] exploited the SDN and blockchain’s efficiency for network security. Blockchain helps to identify informational alteration at any stage when completed transactions or information are preserved in the form of linked blocks. This study proposes a modified blockchain leveraged with the SDN controller. The SDN controller helps to register the devices in each domain, and the registration information cannot be changed. The SDN controller maintains the public blocks for the registration of devices, while the architecture maintains a private blockchain mechanism at the device level of communication. Each controller is assisted with a blockchain and storage to keep a record of distributed ledgers. Therefore, public and private key-based domain identification of devices supports inter-domain mobility, security, and energy-consumption-aware communication in cyber-physical systems (CPS). The architecture proposed in [ 129 ] represents a similar architecture for blockchain-enabled security and energy consumption reduction.

A comprehensive study of SDN-enabled security is conducted in [ 130 ]. According to this research, it is hard to tackle cyber-attacks using traditional security mechanisms. The traditional network equipment and network functions cannot support an efficient defense against the attacks because of the network function’s rigidity. The SDN controller supports programmable cyber defense applications in various centralized and decentralized networks. SDN employs detection, localization, proactive, and reactive mitigation against cyber-attacks. SDN controllers can gauge the congestion, port, flow rule entry, and attached end-user device behavior. To ensure security, softwarized control functions of different domains can collaborate and defend against cyber-attacks. DHCPguard [ 131 ] exploits DHCP attacks in networks and provides a mechanism to defend against such attacks. It handles the attacks by utilizing the SDN controller—specifically, a security module on top of the POX controller, which is designed for mitigation of DHCP starvation attacks. It also facilitates IP pool recovery, DHCP server availability, snooping, and rate-limiting. The traditional DHCP mechanism lacks a security mechanism (i.e., discovery flooding message of the DHCP client program). Compared to the traditional network forwarding devices, SDN architecture can decide the DHCP client application messages at the central controller and block the suspected or malicious nodes at forwarding devices.

In [ 132 ], security assurance is guaranteed through protocol dialects extension. The protocol dialect carries the objectives to provide robustness against downgrade attacks and specializes the network protocol in the context of network security. The OpenFlow protocol dialects have derivatives of MAC-based authentication and complete production packet security without message modifications. In [ 133 ], the optimal packet forwarding decisions in fog computing or the optical network need to be reconsidered periodically for efficient network management. Trust and security parameters in fog computing need to be reconsidered in future networks. A malicious fog node can have forged links with other fog nodes and suspicious activities in production packets. It is possible that this sort of node can lock the resources of connected services or alter the topology view at the central SDN controller. Therefore, the resultant computation and energy consumption ratio of fog computing infrastructure also increases. Similarly, in [ 134 ], the authors revealed that the current SDN standardization, especially in the form of OpenFlow, needs to be upgraded for flawless integration in fog resources. Fog computing represents a geographical distribution of resources and host applications, which makes the network more vulnerable. To tackle this vulnerability of the fog paradigm, the distributed architecture of the SDN needs to be more defensive.

In [ 135 ], vehicular ad hoc networks’ (VANETs) integration with SDN is analyzed. This integration supports efficient resource management for the computational offloading of moving vehicles. Likewise, this is an edge for the various network security issues. VANETs must confront such attacks, such as man-in-the-middle, DDOS, and jamming. If the SDN layer is vulnerable, then the SDN-enabled VANETs are more complex and have poorer defense mechanisms. Moving vehicle applications always trust the nearest roadside unit for computational offloading. In the case of information fabrication or privacy leaks, end-user trust declines for the infrastructure. If the central single control functions are under various attack conditions, then the SDN forwarding devices in VANETs cannot defend and classify the malicious activities or malicious hosts [ 136 ]. In IoT-enabled healthcare infrastructures, device authentication is important. The traditional network devices are deficient for authenticating or bootstrapping the fresh connected end devices securely. In [ 137 ], the objectives of SDN-supported authentication, routing from the end device to edge server, and inter-edge servers’ communication (routing for the load balance) is analyzed. The proposed framework has an IoT device authentication method that is supported by the probabilistic k-nearest neighbor. The framework uses the probabilistic k-nearest neighbor to evaluate the validity of end IoT devices residing in the healthcare systems. Using p-KNN, an edge server investigates the legitimacy of healthcare IoT devices, and SDN performs efficient collaboration among the edge servers that are close to the computation resources.

To localize the DDOS, a convolution neural network (CNN) is used in [ 138 ]. The study claims that the CNN can perform better for DDOS detection compared to logistic regression, multi-layered perceptron, and dense multi-layered perceptron. Furthermore, this work uses game theory to drop malicious activities. As a result, it saves the central SDN controller deployed in any ISP from the IoT devices that are intended for DDOS. If the IoT devices are impairing the central controller, then it increases the vulnerability degree of the SDN-managed ISP. This proposed approach in [ 139 ] deals with the SDN security issues to overcome DDOS in a controller and communication switch. It integrates the online learning method to limit the packet-in rate, while tending to the controller queue and switch space capacity. Traditionally, there are straight forwarding approaches to limit the packets rate, but these cannot be trustworthy for bandwidth-sensitive applications in a real network. The proposed parallel online deep learning (PODL) algorithm envisions the two important aspects and adjusts the weight for queuing the controller packets (packet-in) and flow rule installation capacity in a forwarding device.

In [ 140 ], SDN-based load-balanced opportunistic routing is proposed for duty-cycled WSNs. In this study, the controller computes and controls the candidates. It prioritizes the candidates by considering the average of three distributions, that is, transmission distance, expected number of hops, and residual energy. It helps to guide the network in such a way that more traffic can flow through the nodes with higher priority. The results show that the proposed approach improves network lifetime, routing efficiency, energy consumption, sender waiting time, and duplicate packets compared with existing approaches. The study in [ 141 ] explores the prospects of offloading the 3GPP radio access network (RAN) traffic through WiFi access networks with the help of wireless mesh networks (WMNs). This study reveals an IP wireless mesh network using an SDN-based NFV controller to control and manage the network from the central controller, which results in configuring network devices and services deployment in a fast and effective manner. The study in [ 142 ] offers an edge-cloud framework for electric vehicles (EVs). It presents an intelligent network for collaboration between cloud and edge devices to make intelligent decisions regarding charging and discharging of EVs and anticipated demand–supply balance. The proposed solution based on opportunistic SDN (Opp-SDN) exploits the use of EVs in two ways: as energy reservoirs for instantaneous DRM and as forwarding nodes in Opp-SDN.

The summary of network security and management studies is presented in Table 3 . In [ 110 ], a token-based authorization mechanism is presented that guarantees exclusive access of network resources to a certain flow for which the user/app has made the reservation. This scheme provides an effective mechanism to ensure exclusive access for network resources. However, resource scheduling and path calculation for flows and the QoS parameter are not considered, which may affect network resource utilization. In [ 111 ], network verification is performed, which consists of middleboxes whose forwarding behavior depends on previously observed traffic. It provides a network verification tool that can verify the networks that comprise middle boxes. However, it lacks the ability to verify middlebox code. The research work in [ 112 ] helps network administrators so that they can troubleshoot bugs, including root causes of bugs, in their networks to verify that networks are operating correctly. However, it does not suggest integrating the program semantics into network troubleshooting tools or knowledge into network control programs. The research in [ 115 ] helps to update and manage network policies in an effective manner. However, it does not investigate the effects of network policy change by analyzing packet violations. The research works in [ 113 , 116 ] detect security issues in the network and warn the network admin to deal with those identified issues. However, the above presented approaches do not deal with the problem when the access rights (network policies) are changed. In addition, these also do not consider the flow rules already installed at the data plane as per old polices. Another SDN approach discussed above is to enable blockchain in the network and record the operations of the network to enhance the network’s security. In particular, in the case of distributed SDN infrastructure(i.e., multiple controllers in cloud-fog infrastructure), blockchain can enhance the network’s efficiency against common vulnerabilities.

Summary of network security and management.

The current standardization of the SDN architecture is lacking in terms of security. In particular, ever-increasing delay-aware applications demand vendor lock-in and agnostic security models from various geographical locations in a network. SDN-integrated security can help in centralized and distributed network infrastructure. Although various algorithms are available to make the network secure, mature algorithms are still needed in distributed SDN controller placement. The distributed controller placement makes the SDN-enabled infrastructure more scalable and inclined to the objectives of distributed and fog computing. Security assurance using multiple controller placements in an SDN network requires new solutions for hierarchical, horizontal, and hybrid (T-model) controller synchronization. Similarly, to tackle the various types of attacks in a network, control application autonomy is highly appreciated in ultra-reliable low-latency communication (URLLC). Blockchain technology supports the control layer of the SDN in determining the transactional behavior; however, it can cause end-to-end latency. While machine learning and artificial intelligence can help handle SDN security autonomously and efficiently in 5G and beyond networks, the machine-learning-supported control SDN layer makes the network more reliable. We know that reliability encompasses various performance parameters (i.e., security, failure resiliency, multiple controller placement), but the current era’s main concern is security. With the emergence of fog computing, fog nodes are more vulnerable due to limited resources. On the other hand, it is hard to replicate the control layer applications in fog nodes in a similar context to the cloud. Moreover, local and global (i.e., distributed) network security policies need to be synchronized semantically, which can help to block malicious intentions close to the source network elements. Currently, SDN is lacking in this aspect because the network typologies are in flux in terms of making the SDN-integrated networks more scalable.

5. Memory Management Studies

In SDN, flow tables of OpenFlow-enabled switches include controlling functionalities for communication to the SDN controller in addition to flow rule entries for communication in the network. Recent research works revealed that flow rules in data center networks are from 10,000 to 40,000 per second per server rack. In SDN switches, the forwarding table memory is much less than in traditional routers. Most SDN switches have limited on-chip TCAM memory, in which 750 to 2000 flow rules can be stored [ 144 ]. These switches utilize a state-of-the-art Broadcom chipset switch that can accommodate 2000 flow rules [ 145 ]. This has become big barrier for network management as well as industrialization. The reason behind this fact is that flow tables of these switches are implemented in TCAM due to its better lookup time compared to software-based packet matching. However, TCAMs suffer from large power consumption [ 146 ] and expensiveness compared to other memory, for example, static random access memory (SRAM) [ 147 ]. The idea is to reduce flow rule entries in the switch flow table by maintaining performance. One approach is to efficiently utilize the forwarding information base (FIB) by compression mechanisms to reduce TCAM requirements. It proposes the ESPRESSO heuristic [ 148 ] to minimize the logic to compress prefix-based match fields, which are generated by the optimal routing table constructor (ORTC) algorithm. The simulation results show that FIB size is reduced by 17%, which helps to save TCAMs [ 149 ].

Another approach in [ 150 ] solves the problem by a flow table reduction scheme (FTRS) by reducing flow table congestion, which helps to reduce flow table size. The simulation results suggest that FTRS reduces flow rules in the flow tables by 98% without compromising network performance and efficiency. In [ 151 ], a proactive eviction of flow rule entries is proposed for the efficient utilization of TCAM resources inside OpenFlow-enabled switches. It is based on an intelligent flow management strategy in the SDN controller that combines adaptive idle timeout values for flow rule entries with proactive eviction mechanism on the current TCAM utilization level. In case of non-matching of packets for a defined idle time period, the respective flow rule is removed from the switch flow table. This idle time period is set by the SDN controller before flow rule installation at the data plane. The experimental results show that the proposed scheme, SmartTime, provides 58% better results in terms of cost as compared to static timeout values or random eviction techniques. The authors in [ 152 ] investigate the effect of flow rule timeout value based on miss rate performance and flow table occupancy of switches. They observe that with an increase in timeout value, miss rate decreases; however, flow table size increases roughly linearly. They also observe that there is an ideal timeout value, where the miss rate is ideal and the flow table size is also optimal, and with an increase in that particular timeout value, the flow table size increases in addition to its effect on the miss rate. In this research work, a hybrid flow table management mechanism is proposed that combines timeout value with explicit control plane eviction messages. The proposed scheme is able to reduce the flow table size by a lower bound of 57% without affecting the miss rate. However, in the case of TCP-based applications, the flow table size decreases by around 42%.

In addition, this research work analyses the performance of various flow table eviction techniques and finds that the LRU strategy outperforms all others. However, it cannot be implemented in current SDN switches. Moreover, the first-in first-out (FIFO) strategy does not provide better results than LRU, but it is still better than random replacement strategies by 0.1%. The research work in [ 153 ] addresses the problem of flow rule placement in firewalls on the basis of ACLs. It aims to reduce the number of flow rules in flow tables of switches by considering conflicts as well as redundancies along with the relationships between neighboring devices. There are two key challenges to implementing it. The first challenge is to check whether a flow rule that is going to be placed in a device is part of a specific rule set or not. The second one is to check whether the flow rule can be merged with the other flow rules or not. This research resolves these challenges by proposing a novel data structure called OPTree to check whether the flow rule belongs to another and whether it can be merged or not. In addition, it proposes flow rule insertion and search algorithms to resolve the identified problem. The results indicate that the proposed approach considerably reduces number of flow rules.

In [ 154 ], a mechanism to provide per-flow statistics to the SDN controller is proposed that enhances network performance. The proposed mechanism comprises three phases. In the first phase, a max-flow/min-cost, which is an optimization problem, is formulated to find the optimal forwarding paths. In the second phase, forwarding flow rules for the identified optimal paths are computed via formulating an integer linear problem (ILP) in order to minimize exact-match flow rules in the flow tables of switches to reduce rule-space utilization and to accommodate more flow rules. This is achieved with the help of two greedy heuristic approaches to solve the problem in polynomial time. In the third phase, a flow rule redistribution mechanism is proposed by detecting flow rule congestion at the switches so that new flows can be accommodated in the network. The results of the proposed mechanism are compared with existing mechanisms, such as ReWiFlow [ 155 ] and ExactMatch, and show clear improvement in network performance. The research work in [ 156 ] proposes a flow rule placement mechanism called “hybrid flow table architecture” that utilizes the advantages of hardware and software flow table implementations. The proposed mechanism handles the decision logic of the placement of flow rules by dynamically placing flow rules in software-based flow tables instead of expensive TCAM modules of switches, without degrading network performance with respect to packet delay or packet loss. Packet classification is very important in networking to perform different tasks (e.g., routing, load-balancing, policy enforcement, etc.).

The research work in [ 157 ] proposes a packet classification approach to create packet classifiers based on lossy compression whose representations are semantically equivalent. It helps to find a classifier of optimal size to categorize the network traffic so that appropriately sized TCAM switches can be used for the communication. In [ 158 ], fundamental analytical tools are presented that are based on independent sets and alternate paths for better utilizing the TCAMs switches. Moreover, it is useful to validate the optimality of existing coding schemes. In [ 159 ], a compression technique is proposed based on random access for forwarding tables. In this mechanism, each forwarding table column is encoded separately via dedicated variable-length binary prefix encoding. The system evaluation reflects that it provides much better results in the compression of forwarding tables compared to existing techniques. In [ 160 ], a TCAM update optimization mechanism is presented that ensures consistent packet forwarding. This mechanism is based on a modified-entry-first write-back scheme that considerably decreases TCAM entries’ movement overhead and detects reordering cases with the help of efficient solutions.

The summary of memory management studies is presented in Table 4 , which describes the efficient utilization of TCAM resources of switches. In [ 148 ], an ESPRESSO heuristic approach is proposed, which is based on the optimal routing table constructor (ORTC) algorithm to optimize routing table size for better utilization of TCAMs. This mechanism is quite effective in traditional networking; however, it needs to be tested in an SDN environment. The research in [ 151 ] presents a flow management strategy in an SDN controller that offers a proactive eviction mechanism in TCAMs by preventing table misses at an optimum level. This work is based on idle timeout values for flow rules and does not consider other parameters, such as initial idle timeout, max idle timeout, or rate of timeout increase, which are quite helpful in flow rule management. In [ 152 ], a hybrid flow table management scheme is presented that combines timeout value with explicit control plane eviction messages by considering both the miss rate and flow table size. This strategy is implemented by using same timeout values for all flow rules, and dynamic timeout values are not considered, although they impact real-time networks.

Summary of memory management studies.

OPTree [ 153 ] and FlowStat [ 154 ] represent two flow rule placement strategies to reduce the number of flow rules in the flow tables of switches by considering the relationships between network devices. In addition, the flow rules are installed on optimal paths to avoid network congestion. These approaches lack an investigation into the network topology and policy change to install flow rules. In [ 157 , 159 ], flow rule compression mechanisms are proposed for efficient memory management of switches by classifying the network traffic to accommodate more flow rules. However, these approaches do not consider flow rules compression based on a limited-size longest prefix match classifier, which can correctly classify a high portion of traffic. In addition, managing massive flows in limited-size switch flow tables remains a challenge. Moreover, proactive flow rule installation in delay-sensitive applications and non-delay applications or best-effort traffic should benefit from reactive flow rule installation. It is yet another interesting research area to explore and propose a scheme considering traffic variability.

6. SDN Simulators and Emulators

To analyze the network performance, instead of implementing a large experimental testbed, there are two commonly used methods; these are called simulation and emulation. The simulation method provides an application environment where we can test our implemented software program without real deployment. The emulation method utilizes a software program to perform executions with real devices by interacting with them as when required. To analyze network performance by simulation is inexpensive, flexible, controllable, and scalable compared to an emulator. In addition, the simulators allow researchers to analyze and test network behaviors as per defined workload. In SDN, with the development of OpenFlow protocol, the simulation tools have extended support to additional network components for the testing and experimentation of OpenFlow-based network applications. Moreover, network emulators based on software switches have also been developed to test and analyze network applications, for example, Open vSwitch (OvS) [ 161 ], ofsoftswitch13 [ 162 ], Indigo Virtual Switch (IVS) [ 163 ], and so on.

The Mininet SDN emulator [ 164 ] offers a rapid prototyping workflow and virtualization functionalities along with command line interface (CLI) and API on one physical machine that allows network developers to configure, manage, and test their networks. It helps to create a network topology for a network scenario that consists of virtual hosts, switches, links, and controller platforms. It supports research and development, learning, prototyping, testing, debugging, and any other task related to network experimentation on a computer. In the basic implementation of Mininet, the performance fidelity is not included. In Mininet-HiFi [ 165 ], these improvements are implemented. It also has a cluster edition prototype [ 166 ], and other releases include Maxinet [ 167 ] and Mininet-CE [ 168 ], which fixes the limitations of large-scale implementation of SDN emulations. Finally, two experimental frameworks for SDN data centers are also developed; these are datacenter in a box [ 169 ] and SDDC [ 170 ]. The distributed OF testbed (DOT) [ 171 ] is a highly scalable emulator that provides an emulated network across a cluster of computers that guarantees computation and network resources to switches, hosts, and links.

The OFNET [ 172 ] emulator provides built-in functionalities to test and debug, and traffic generation and monitoring tools, which help researchers in the debugging process. The virtual network overlay (ViNO) [ 173 ] network emulation tool provides functionalities that help to create arbitrary network typologies via Open vSwitches and virtual machines. The overlay interconnection between virtual machines (VMs) is provided by VXLAN encapsulation [ 174 ]. EstiNet [ 175 ] provides the benefits of both simulation and emulation tools by offering each host a real Linux OS environment, and any real application program can run on a simulated host without any modification. FS-SDN [ 176 ] is a simulator that is based on the FS [ 177 ] simulation platform and is built in Python language. OMNeT++ [ 178 , 179 ] is a network simulator that is developed in the C++ language for network modeling, multiprocessors, and different distributed or parallel systems. It utilizes the INET framework [ 180 ] for the simulations in the SDN environment by integrating OpenFlow components, basic switch functions, basic controllers, and OpenFlow messages. The NS-3 network simulator [ 181 ] is implemented in C++ and can use OpenFlow switches. In addition, it also offers the use of external modules to extend NS-3, such as OFSwitch13 [ 182 ], which helps for OpenFlow 1.3 compatibility.

The summary of network simulators and emulators is presented in Table 5 . It provides a comprehensive overview of simulators and emulators that are developed in various programming languages, such as C, C++, Java, Python, and so on. These tools help in developing and simulating SDN applications in an SDN environment. Mininet [ 164 ] is an innovative emulation tool that allows network developers to configure, manage, and test their networks. These networks cannot exceed single-server bandwidth and cannot run non-Linux-compatible OpenFlow switches or applications. The DOT [ 171 ] emulation tool ensures computation and network resources for switches, hosts, and links in large SDN deployments. It can be used in an environment where a fixed number of physical machines are used to emulate a given network and does not support dynamic scalability and multi-user support. OFNET [ 172 ] is an open-source emulator to test and debug networks for analyzing network traffic. This tool does not support cloud platforms and large-scale implementation of layer-2 networks. ViNO [ 173 ] helps to create arbitrary network topologies via Open vSwitches and virtual machines. However, its scalability and OpenFlow support are not specified, and these can be helpful for experimentation and testing.

Summary of SDN simulators and emulators.

The EstiNet [ 175 ] network emulator provides accuracy, quickness, repetition, and scalability and is based on a kernel-reentering simulation methodology that allows researchers to test their applications. The FS-SDN [ 176 ] simulator is developed in the Python language for realistic testing and validation of standard networks. It can be extended for debugging and tracing capabilities, which can be helpful for developing new SDN applications. The OMNeT++ [ 178 , 179 ] simulator is helpful for network modeling, multiprocessors, and different distributed or parallel systems. However, its kernel is implemented in C++ and can only run with a modern C++ compiler. The NS-3 network simulator provides the capability to add new protocols and allows integration and customizability without remaking the core of the simulator. However, it is lacking a visual interface for creating a topology and for visible capability on an experimental level. This study provides a feature-based comparison of SDN simulators and emulators including a brief description, implementation language, and the strengths and weaknesses. It can be extended to conduct a performance-based comparison of these tools under specific scenarios. Finally, new simulators and emulators need to be developed for hybrid SDN, wireless networks, fog/edge computing, cloud computing, and so on, to meet the needs of future networks.

7. SDN Programming Languages

SDN programming languages consist of compilation and validation tools that are helpful for the translation of high-level constructs into messages understandable by the SDN controller API. The following section explains some SDN programming languages. One of the languages is Frenetic [ 183 , 184 ], which is a high-level language for the programming of OpenFlow networks and is useful for the categorization and accretion of network traffic. Moreover, it is also helpful for defining packet forwarding policies on the basis of a functional reactive combinator library inspired by Yampa [ 185 ], and its implementation is based on FlapJax [ 186 ]. By providing a Frenetic runtime environment, facilities pertaining to installation and querying low-level details are managed. In addition, it provides compositional constructs that facilitate modular reasoning and enable code reuse. As NetCore [ 187 ] is the successor of Frenetic, it carries an enhanced policy management library. Moreover, it has the capacity to compile ACL policies and handle the interaction between controller and switch. In addition to this, for the efficient generation of flow rules, the run-time system of NetCore is designed. Nettle [ 188 ] is a low-level programming language that deals with streams and does not deal with events. It is quite appropriate for various functions such as programming controllers, and programming discrete and continuous operations. Moreover, dynamic policies, including traffic engineering and load balancing, are also generated through it. As it is declarative in nature, functions that are time sensitive and varying can be demarcated. Moreover, the sequential operator provided by Nettle can also be used for creating compound commands.

Procera [ 189 ] is a high-level programming language that is helpful to delineate ACL policies in communication networks. It is quite a resource for the operators as it provides an expressive and extensible compositional framework. Moreover, it is also quite useful for designing network applications that not only react to the events produced by OpenFlow switches but also to external events, for instance, user authorization and bandwidth usage. Procera was used in several campus networks, as well as home network prototype deployments [ 190 ]. Flow-based management language (FML) [ 191 ] is a high-level declarative programming language that is based on non-recursive Datalog [ 192 ] for handling a network whose aim is to provide efficient and flexible policies. Moreover, it is also helpful for the operators, as it provides them with eminent management facilities for configuring ACL policies straightforwardly. Flog [ 193 ] is an event-driven programming language that adopted ideas from FML and Frenetic and is based on logic programming for the SDN environment, similar to FML. It is composed of three components that are similar to Frenetic. These components include a mechanism for network state collection, information processing, and policy generation. Like NetCore, Frenetic-OCaml [ 194 ] is also a successor of Frenetic. It is beneficial in providing mechanisms for network-wide policy implementation. NetCore is used and is replaced with NetKat for forwarding decisions. Moreover, its query language permits querying statistics that include traffic and topology. Being an imperative programming paradigm-based language, Pyretic [ 195 ], by specifying the static and dynamic forwarding policies, assists in developing network applications. By utilizing the sequential and parallel operators provided by Pyretic, the forwarding policies can be specified.

FlowLog [ 196 , 197 ] is a declarative language for programming SDN network applications. Being a finite state language, for the various types of analysis, the model checking can be applied quite competently. FlowLog has two versions. One is based on NetCore, whereas the other is built on the packet-handling capability of Frentic-OCaml. The FatTire [ 198 ] SDN programming language is used for writing fault-tolerant network applications. It is designed for the purpose of specifying the path for packet routing and fault tolerance. Moreover, it can also be helpful for the programmer who, by using regular expressions, declaratively states the sets of necessary paths. NetKat [ 199 , 200 , 201 , 202 ] uses Kleene algebra with tests (KAT) [ 203 ]. This programming language is based on equational theory, for programming and reasoning about the networks. A regular expression can be used for describing end-to-end paths, and its semantics are inspired by NetKat. Moreover, NetKat is also beneficial for defining virtual topologies. Merlin [ 196 , 197 , 204 , 205 ] is a declarative language that is useful for distributing and managing the ACL policy implementation process. Its run-time monitor is used to examine incoming and outgoing network traffic. Being a policy specification for SDN, PonderFlow [ 198 ] aims to extend the Ponder language [ 206 ] for describing OpenFlow flow rules. It is used to define management and security policies in distributed systems.

PonderFlow provides mechanisms for implementing access control and network abstractions. NOF [ 207 ] is a programming language with the objective of enabling network application to design the network according to the application requirements. It comprises sets of operations and services, and these are categorized into three groups, namely matching, timing, and query. Operations can be applied to conventional network fields that are based on host information. Timing includes information about the services, that is, when they will be installed and how long they will remain functional in the network. Query operation helps to obtain the network state information, that is, link state, bandwidth usage, transmission errors, and so on. Kinetic [ 208 ] is a domain-specific language that helps network operators control the dynamic state of their network. In addition, it offers facilities to validate the accuracy of control programs. The network policies may be stated with respect to finite state machines (FSMs), which aids in encapsulating the dynamic state of the network.

The summary of SDN programming languages is presented in Table 6 . Different SDN programming languages are developed to handle specific problems or to provide specific functionalities in network applications in a more refined and abstract manner. Most of the languages, (i.e., Procera [ 189 ], Pyretic [ 195 ], FlowLog [ 209 , 210 ], FatTire [ 157 ], NetKat [ 158 , 159 , 160 , 161 ]) provide basic-level flow matching. Pyretic [ 195 ] implements native flow matching and virtualizations, unlike other languages. Frenetic-OCaml [ 194 ] and Frenetic [ 183 , 184 ] provide enhanced monitoring based on query language and windowed history as well as flow matching. Kinetic [ 208 ] provides inherited flow matching and monitoring services, and it implements the modules in a parallel fashion. We have described these languages along with their programming paradigms.

Summary of SDN Programming Languages.

These languages help network administrators to implement access control, and to develop and test network applications on the basis of low-level constructs as well as high-level abstractions. However, there is still a wide scope for researchers to offer new abstractions and also contribute to the advance of NBI standardization. The future programming languages may include functionalities of load balancing to avoid congestion on specific resources. Researchers may be interested in using language constructs to scale-up the resources in an elastic way. Moreover, future programming languages should incorporate NFV to manage the virtualized functions and OpenFlow updates to take advantage of the new features offered by OFP. Network forensics are quite useful to collect information on network devices to verify the evidence of crimes. However, this important area is also lacking in research with regard to SDN programming languages. Finally, the current programming languages still do not provide an open interface to allow new modules to be developed and incorporated into the language, which is also an interesting future research area.

8. SDN Controller Platforms

The controllers are the brains of SDN networks and act as a strategic control point. These contain collection of modules that can perform different network tasks including network topology, network statistics, and so on. Different network applications such as network policies are installed on the controllers for data communication between end nodes. In this section, we discuss some controller platforms, which are described below.

Beacon [ 212 ] is implemented in the Java programming language and uses centralized architecture. Moreover, it uses ad hoc northbound API and southbound API with OpenFlow 1.0, which supports CLI and web user interface (WebUI). It also supports multi-command-line threading and modularity functionality. It serves as the basis of Floodlight, with a focus on being developer friendly and high performance, and with the ability to start and stop existing approaches. It has explored areas of OpenFlow controller design. Beehive [ 213 ] is a distributed control platform implemented in the GO programming language with a distributed hierarchical architecture. It utilizes REST northbound API and southbound API with OpenFlow 1.0 and 1.2. It utilizes the Linux supporting platform and supports CLI. The implementation of DCFabric [ 214 ] is based on the C and Java script programming languages, and it has a centralized architecture. It utilizes the REST northbound API and southbound API with OpenFlow 1.3. It uses the Linux supporting platform and supports CLI and WebUI. Moreover, it supports multi-threading and has a good modularity functionality with good consistency. Disco [ 215 ] is implemented in the Java programming language with a distributed flat architecture. It utilizes the northbound, southbound, and east/westbound API with REST with OpenFlow 1.0 and AMQP, respectively. It supports proprietary licenses. It has good modularity with limited documentation. The implementation of Faucet [ 216 ] is based on the Python programming language, and it has a centralized architecture. It utilizes SBI with OpenFlow 1.3. It employs the Linux supporting platform and supports CLI and WebUI. It supports Apache 2.0 licenses and multi-threading with good consistency.

Floodlight [ 217 ] is implemented in the Java programming language, and it has a centralized architecture. It utilizes REST, Java, RPC, and Quantum northbound API and southbound API with OpenFlow 1.0 and 1.3. It utilizes a Linux-, MacOS-, and Windows-supporting platform and provides CLI and WebUI. It supports Apache 2.0 licenses, which supports multi-threading, and has a fair modularity with good consistency and documentation. Flow Visor [ 218 ] is implemented in the C programming language with a centralized architecture. It utilizes JSON and RPC northbound API and southbound API with OpenFlow 1.0 and 1.3. It utilizes a Linux supporting platform and supports CLI interface. Moreover, it supports proprietary licenses and has no consistency; however, its documentation is fair. HyperFlow [ 219 ] is implemented in the C++ programming language with a distributed flat architecture. It utilizes SBI with OpenFlow 1.0 and east/westbound API with publishing and subscribing messages. It supports proprietary licenses and multi-threading and has no consistency. Kandoo [ 220 ] is implemented in the C, C++, and Python programming languages, and it has a distributed hierarchical architecture. It utilizes Java RPC northbound API and SBI with OpenFlow 1.0–1.2 and east/westbound API with messaging channel. It utilizes a Linux supporting platform and supports CLI and proprietary licenses.

Loom [ 221 ] is implemented in the Erlang programming language and has a distributed flat architecture. It utilizes JSON NBI and SBI with OpenFlow 1.3–1.4. It utilizes a Linux supporting platform and supports CLI. It supports Apache 2.0 licenses and multi-threading and has a good modularity with good consistency. However, its documentation is limited. Maestro [ 222 ] is implemented in the Java programming language with a centralized architecture. It applies ad hoc northbound API and southbound API with OpenFlow 1.0. It utilizes Linux, MacOS, and Windows supporting platform and supports WebUI. It supports LGPL 2.1 licenses. It supports multi-threading and has a fair modularity with no consistency, and its documentation is also limited. MsNettle [ 223 ] is implemented in the Haskell programming language and has a centralized architecture. It utilizes southbound API with OpenFlow 1.0. It utilizes a Linux supporting platform and supports CLI. It supports proprietary licenses and multi-threading and has a good modularity with no consistency. Meridian [ 224 ] is implemented in the Java programming language and has a centralized architecture. It utilizes REST NBI and SBI with OpenFlow 1.0 and 1.3. It utilizes a cloud-based supporting platform and supports WebUI. It supports multi-threading and has a good modularity with no consistency.

Microflow [ 225 ] is implemented in the C programming language with a centralized architecture. It utilizes Socket NBI and SBI with OpenFlow 1.0–1.5. It utilizes a Linux supporting platform and supports CLI and WebUI. It supports Apache 2.0 licenses and multi-threading. Nodeflow [ 226 ] is implemented in the JavaScript programming language with a centralized architecture. It utilizes JSON northbound API and southbound API with OpenFlow 1.0. It utilizes a Node.js supporting platform and supports CLI. NOX [ 227 ] is implemented in the C++ programming language and has a centralized architecture. It utilizes ad hoc NBI and SBI with OpenFlow 1.0. It utilizes a Linux supporting platform and supports CLI and WebUI. It supports GPL 3.0 licenses and multi-threading (Nox-MT) and has low modularity with no consistency. ONIX [ 228 ] is implemented in the C++ programming language with a distributed flat architecture. It utilizes Onix API northbound API and southbound API with OpenFlow 1.0 and OVSDB and east/westbound API with Zookeeper. It supports proprietary licenses and multi-threading and has a good modularity with no consistency.

ONOS [ 229 ] is implemented in the Java programming language with a distributed flat architecture. It utilizes REST and Neutron NBI and SBI with OpenFlow 1.0 and 1.3 and east/westbound API with Raft. It utilizes a Linux, MacOS, and Windows supporting platform and supports CLI and WebUI. It supports Apache 2.0 licenses and multi-threading functionality and has a high modularity and consistency. OpenContrail [ 230 ] is implemented in the C, C++, and Python programming languages with a centralized architecture. It utilizes REST NBI and SBI with BGP and XMPP. It utilizes a Linux supporting platform and supports CLI and WebUI. It supports Apache 2.0 licenses and multi-threading functionality and has a high modularity with good consistency. OpenDaylight [ 231 ] is implemented in the Java programming language with a distributed flat architecture. It utilizes REST, RESTCONF, XMPP, and NETCONE NBI and SBI with OpenFlow 1.0 and 1.3 and east/westbound API. It a utilizes Linux, MacOS, and Windows supporting platform and supports CLI and WebUI. It supports EPL 1.0 licenses and multi-threading functionality and has a high modularity with consistency. OpenIRIS [ 232 ] is implemented in the Java programming language with a distributed flat architecture. It utilizes REST NBI, SBI with OpenFlow 1.0–1.3, and east/westbound API with custom protocol. It utilizes a Linux supporting platform and supports CLI and WebUI. It supports Apache 2.0 and multi-threading functionality, with fair modularity and no consistency. OpenMul [ 233 ] is implemented in the C programming language and has a centralized architecture. It utilizes REST NBI and SBI with OpenFlow 1.0, 1.3, OVSDB, and Netconf. It utilizes a Linux platform and supports CLI. It supports GPL 2.0 licenses and multi-threading functionality and has a high modularity with no consistency. However, its documentation is good.

PANE [ 234 ] is implemented in the Haskell programming language with a distributed flat architecture. It utilizes PANE NBI, SBI with OpenFlow 1.0, and Zookeeper east/ westbound API. It utilizes Linux and MacOS platforms and supports CLI. It supports BSD 3.0 licenses and has a fair modularity with no consistency, but with documentation. POF Controller [ 235 ] is implemented in the Java programming language and has a centralized architecture. It utilizes SBI with OpenFlow 1.0 and POF-FIS. It utilizes a Linux platform and supports CLI and WebUI. It supports Apache 2.0 licenses, and its documentation is limited. POX [ 236 ] is implemented in the Python programming language with a centralized architecture. It utilizes ad hoc NBI and SBI with OpenFlow 1.0. It utilizes a Linux, MacOS, and Windows platform and supports CLI and WebUI. It supports Apache 2.0 licenses; however, it does not support multi-threading functionality and has a low modularity with no consistency. Ravel [ 237 ] is implemented in the Python programming language and has a centralized architecture. It utilizes ad hoc NBI and SBI with OpenFlow 1.0. It utilizes a Linux platform in CLI mode. It supports Apache 2.0 licenses, and its documentation is fair.

Rosemary [ 238 ] is implemented in the C programming language with a centralized architecture. It utilizes ad hoc NBI and SBI with OpenFlow 1.0, 1.3, and XMPP. It utilizes a Linux supporting platform and supports CLI. It supports proprietary and multi-threading functionality and has a good modularity with no consistency. RunOS [ 239 ] is implemented in the C++ programming language with a distributed flat architecture. It utilizes REST NBI, SBI with OpenFlow 1.3, and Maple east/westbound API. It utilizes a Linux supporting platform and supports CLI and WebUI. It supports Apache 2.0 licenses and multi-threading functionality and has a high modularity with consistency. Ryu [ 240 ] is implemented in the Python programming language and has a centralized architecture. It utilizes REST NBI and SBI with OpenFlow 1.0–1.5. It utilizes a Linux and MacOS supporting platform in CLI mode. It supports Apache 2.0 licenses and multi-threading functionality. SMaRtLight [ 241 ] is implemented in the Java programming language with a distributed flat architecture. It utilizes REST NBI, SBI with OpenFlow 1.3, and BFT-SMaRt east/westbound. It utilizes a Linux supporting platform in CLI mode. It supports proprietary licenses and has no consistency. TinySDN [ 242 ] is implemented in the C programming language with a centralized architecture. It utilizes SBI with OpenFlow 1.0 and a Linux supporting platform in CLI mode. It supports BSD 3.0 licenses and has no multi-threading functionality or consistency. Trema [ 243 ] is implemented in the C and Ruby programming languages with a centralized architecture. It utilizes ad hoc NBI and SBI with OpenFlow 1.0. It utilizes a Linux supporting platform in CLI mode. It supports GPL 2.0 licenses and has good modularity, but it has no consistency. However, its documentation is fair. Yanc [ 244 ] is implemented in the C and C++ programming languages and has a distributed flat architecture. It utilizes REST NBI and SBI with OpenFlow 1.0–1.3 capabilities. It utilizes a Linux supporting platform and supports CLI. It supports proprietary licenses, and its documentation is limited. ZeroSDN [ 245 ] is implemented in the C++ programming language and has a distributed flat architecture. It utilizes REST NBI, SBI with OpenFlow 1.0 and 1.3, and ZeroMQ of east/westbound API. It utilizes a Linux supporting platform in both CLI and WebUI modes. It supports Apache 2.0 licenses and has high modularity with fair documentation.

The summary of SDN controller platforms is presented in Table 7 . These controllers manage flows to the switches/routers via SBI and the applications/business logic via NBI to deploy intelligent networks. The controllers install flow rules at the data plane devices (switches/routers) to perform required functionalities, such as forwarding, dropping, and so on. There are different kinds of SDN controllers (centralized and distributed), which are developed to perform various functionalities in different programming languages (Python, C, C++, Java, etc.). Some of the controllers are java-based (i.e., Beacon [ 212 ], Disco, Opendaylight, SMaRtLight [ 241 ], etc.). Some of them are based on distributed approaches. Ryu is very easy and straightforward to program. Beginners can easily deploy and use this controller for their network.

Comparison of SDN controller platforms.

Opendaylight is complex, and it is difficult to model new ideas. For experts, it is good option to use because it provides a dozen southbound APIs and protocols, such as NetConf, OVSDB, and PCEP, for managing and configuring forwarding devices. If someone want to rank these controllers on the basis of simplicity, the order would be as follows: Ryu, Floodlight, ONOS, ODL. The scalability, consistency, reliability, and security are very important to consider in designing an efficient and robust SDN controller. The current SDN controllers lack standard data models, anomaly detection, and security mechanisms. It is observed that developing a brand new SDN controller may not be the best solution; however, the existing SDN control frameworks need to be enhanced, refined, and improved to address the above-mentioned issues.

9. Comparison with Existing Studies

SDN is a new networking paradigm that influences the network operations and management, gaining the attention of the research community and other organizations [ 246 ]. The papers have been written to discuss different issues and challenges of SDN, and these are shown in Table 8 . Akyildiz et al. [ 247 ] wrote a survey related to fault management, fault tolerance, topology update, and traffic analysis. They explained different aspects of the SDN architecture and their interactions. Several studies are classified according to their specific problems. Xie et al. [ 248 ] compile techniques such as routing optimization, QoS, and resource management security to fill the gaps left by the previous paper. Their main focus was on blending the QoS-aware techniques and presenting their work in a comprehensive manner. Meanwhile, Matlou et al. [ 249 ] surveyed the same topic to improve on the paper written by Xie et al. [ 248 ]. They targeted wireless sensor networks and SDNs to explain this topic. They achieved their target, as wireless networking in SDN was considered a unique topic at that time, and they accepted the challenge to complete the survey. In the same year, Jose et al. [ 250 ] wrote a comprehensive review related to traffic classification and security. Network intrusion detection is also considered as a point in traffic engineering, and it was not included in any of the papers mentioned above, so to describe it in a comprehensive manner, Sultana et al. [ 251 ] focused on the four learning algorithms included in the paper. Similarly, traffic profiling is also an important area of traffic classification. Cui et al. [ 252 ] considered all four learning algorithms and explained several machine learning models, including traffic profiling and its functioning in SDN networking. It was considered an important topic at that time due to its uniqueness. Moreover, Loung et al. [ 253 ] focused on the topic of network virtualization, which was explained and included in a survey related to traffic engineering. They achieved their target by reviewing network virtualization and ensuring QoS in virtual networks.

Comparison of existing papers in SDN.

Kreutz et al. [ 254 ] started their discussion by defining the SDN, its major concepts, and its differences compared to traditional networks. The architecture of an SDN is presented in a bottom-up approach. Deep analysis is performed at its architecture, APIs, network programming, and network layers. They also focused on the major problem of cross-layering and its solutions. Keeping in view security, performance, scalability, and resilience, the design of the controller and switches are addressed in this study. Wang et al. [ 255 ] provide a review of diverse problems in networking, including traffic classification, traffic prediction, self-configuration, and network management, as well as performance inspection and prediction. They focused on a small number of studies to showcase different aspects of the workflow. Jamshidi et al. [ 256 ] explained applications based on machine learning (ML) methods and techniques by dividing them into six categories of networking, which are traffic prediction, network security, cloud services, application identification, domain name system, and QoS. For all these categories, they determined the ML methods and input datasets. They also summarize the various challenges and major findings of these input data and ML methods. In particular, they discovered multiple new aspects of ML in networking. They ended their study by discussing research gaps and challenges. Mohammed et al. [ 257 ] review existing different ML and deep learning (DL) algorithms in the context of SDN networking for the measurement of traffic classification and traffic prediction. DL approaches are used for traffic prediction. Tam et al. [ 258 ] directed their attention to ML-based security solutions for SDN. ML models used in network prediction and prevention are identified to be deficient, so attackers can control or avoid the model. Attackers are also versed in ML capabilities to predict the defending model’s behavior. The authors suggest some specific recommendations that are helpful for SDN security. They recommend that a secure development process must be followed. They made an auditable ML model. This is important to give attention to threat models, instead of scheming ML solutions, and there must be an operational cost model that is produced at the initial level. These recommendations are helpful to improve the properties of ML-based solutions for SDN.

Amin et al. [ 259 ] discuss the deployment of SDN among legacy networks. Due to the speedy growth of the Internet, network structures have become huge and complicated. This complexity initiates a huge amount of traffic data, and it becomes a challenge to take traffic measurements such as traffic classification and prediction, in a network. To manage networks efficiently, the SDN paradigm is adopted, and it has already been adopted by several organizations. This survey presents a comprehensive study on a specific topic. For hybrid SDN, some efficient algorithms are needed to measure and deploy the SDN alongside traditional networking. Priyadarsini et al. [ 260 ] provide a comprehensive review and report of state-of-the-art progress on productive traffic management, including load balancing and energy-efficient routing. The introduction and deployment of SDN controls, network safety, and optimum positioning of controllers affecting traffic management are also discussed. This paper also addresses a few unexplored SDN challenges, such as modular implementation, convergence with the legacy network, and possible analysis charts. Although there are multiple studies on SDN, most of them are old and do not cover the state-of-the-art approaches. Some of them just cover one or two aspects of the SDN environment (i.e., SDN controller placement [ 261 , 262 ], SDN programming languages [ 263 , 264 ], SDN simulators [ 265 , 266 ]).

In all of the above-mentioned studies, none of them evaluate the state-of-the-art approaches related to different classifications of SDN. We categorize the approaches as network testing and verification, flow rules installations, SDN controllers, SDN simulators, network security and management, programming languages, and memory management. Moreover, we provide comparisons of all these categories in the form of tables and discuss limitations of each technique, which require attention in future research. In SDN, network devices are controlled using flow rule installations, and there are several methods for rule installations in different circumstance (i.e., path failure, new rules, rules update). This is an important aspect that needs to be considered for evaluation of different approaches. Network devices in SDN are equipped with TCAM memory, which is very limited. It is necessary to use this memory very efficiently, so many approaches are adopted for memory management in SDN devices. We cover all these studies and compare their performance and efficiency.

10. Future Research Directions

This paper focuses on different techniques found in OpenFlow-based SDN. We observe that most existing techniques that appear in the literature complement the methods and subordinate them. Following are the possible future research directions for the research community. SDN controllers handle communication traffic, and as network traffic grows, the mapping of flow rules between controller and switches becomes overburdened, while a few controllers become unburdened. Due to poor throughput and long reaction times, such an imbalance impairs the performance of the SDN network. It is difficult to manage the load across several controllers dynamically. In SDN security, several SDN-based defensive primitives are addressed. To cope with contemporary cyber dangers, both novel primitives and modular protection systems that employ various primitives are required. Researchers should focus on improving the security of established network protocols (such as address resolution protocol (ARP), dynamic host configuration protocol (DHCP), domain name system (DNS), etc.), as well as novel protocols such as neighbour discovery protocol (NDP) in Internet Protocol Version 6 (IPV6).

With respect to controller scalability, separation of control and data planes, quantity of events/requests handled by a controller, and controller–switch communication delay are all bottlenecks in SDN. The relationship between different approaches used to optimize controllers and scalability difficulties are also examined. The majority of current storage systems have been evaluated on small-size networks, such as those with 7–28 nodes and 7–43 connections. As a result, these figures are incomparable to a large number of devices in a wide-scale network environment, such as Telco, Internet of things (IoT), and so on. In resource management (i.e., network components such as switches and controllers), ML approaches are extremely successful. The majority of ML algorithms, on the other hand, are focused on flow categorization and monitoring. Much less study has been done on estimating traffic flow for real-time applications and best-effort traffic and deciding which traffic flow to install ahead of time. These are multiple research areas to explore. In addition, the energy-efficient SDN networks, wireless networks, network virtualization techniques, cloud computing platforms, and SDN migration mechanisms are recommended for more detailed exploration.

Information-centric networking (ICN) [ 267 ] is gaining popularity for the future Internet to increase the efficiency of content delivery and availability. With the increasing demand for video streaming of public users through mobile devices, the Internet speed is significant to fulfill the desired need for end-users through efficient use of bandwidth. Nowadays, different applications of ICN are very popular, such as SDN-based ICN [ 268 ], IoT-based ICN [ 269 ], ICN with edge computing [ 270 ], green ICN [ 271 ], and so on. These areas need to be explored in more detail to help the ICN community reach the next step of implementation in live deployments. The network programmability feature of SDN is used to enrich response functionality. The data plane provides the possibility of adding new functions that are more competent to secure the entire network. In prevention systems, security policies are defined to stop attackers from contacting targets, which require investigation once policies change. The dynamic flow control features of SDN enhance the detection of attacks without adding middleboxes and virtually turn switches into network security devices that can prevent attacks dynamically. Moreover, ML-based SDN includes network optimization, improving network security, and high-quality training datasets. Some other broader perspectives on SDN, such as software-defined mobile networks and software-defined vehicular networks, are also important areas to explore. Regarding QoS, researchers are carrying out experiments with real matrices through different network topologies so that each flow may have different QoS requirements. If DROM [ 272 ] is extended with QoS routing, more efficient and enhanced results can be generated. The QoS measures the traffic conditions and traffic classification, while DROM dynamically measures the reliability, effectiveness, and awareness of QoS. The queuing delay of the switches and the processing delay of the server improves the QoS.

For traffic engineering, some machine learning techniques provide fundamental improvements compared to the traditional traffic engineering paradigm. Many researchers have devoted their skills to developing efficient systems for traffic classification, routing, and traffic optimizations. Network policies are formed intelligently using some machine learning algorithms, for example, random forest, support vector machine (SVM) [ 273 ], k-nearest neighbors (KNN), and so on. Apart from machine learning, deep learning models such as the artificial neural network (ANN) or convolutional neural network (CNN) may also be adopted. For example, if we can predict the change in network policies before its occurrence and take the needed measures, then much better throughput can be achieved. These approaches will make the controller more intelligent, which results in more efficient handling of network policy change phenomena. Moreover, quality of service (QoS) parameters also need to be considered to manage the network traffic to improve network throughput. However, machine learning algorithms have their own limitations, such as false negatives [ 274 ]. For traffic classification, most of the research conducted so far has been on labeled datasets using a supervised learning approach. Few works are done using semi-supervised learning, where some of the data are labeled and some are not given labels. The same applies to the scenario with unsupervised learning. Another important learning approach is reinforcement learning, which is a black box approach when we consider traffic classification. In this regard, algorithms can be designed to classify the data traffic in such a way that the new classified information can help the algorithm learn from the experience.

11. Conclusions

The SDN architecture has shifted network control and management to a centralized controller, which provides a variety of benefits including programmability, innovation, and ease of security policy implementation. In this paper, we briefly reviewed the traditional networking and SDN structure along with its background, application programming interfaces, network configurations, and benefits of the SDN paradigm. Afterwards, we organized this paper into seven groups, namely network testing and verification, flow rule installation mechanisms, network security and management issues related to SDN implementation, memory management studies, SDN simulators and emulators, SDN programming languages, and SDN controller platforms. We discussed each category in detail along with the implementation mechanisms and analyzed these mechanisms by summarizing and comparing each technique along with the lessons learned from the proposed techniques. Furthermore, we analyze and discuss the latest studies and compare these papers with our research paper. Finally, comprehensive future research guidelines are provided, and the paper is concluded.

Funding Statement

Taif University Researchers Support, project number TURSP-2020/302, Taif University, Taif, Saudi Arabia.

Author Contributions

Conceptualization, M.H. and N.S.; methodology, M.H. and R.A.; software, M.H.; validation, M.H. and N.S.; formal analysis, N.S.; investigation, M.H., A.A. and S.S.A.; resources, M.H. and R.A.; data curation, M.H. and N.S.; writing—original draft preparation, M.H. and N.S.; writing—review and editing, M.H., S.S.A. and S.M.R.; visualization, M.H., S.S.A. and S.M.R.; supervision, N.S.; project administration, A.A., S.M.R. and R.A.; funding acquisition, A.A. and S.S.A. All authors have read and agreed to the published version of the manuscript.

Institutional Review Board Statement

Informed consent statement.

Informed consent was obtained from all subjects involved in the study.

Data Availability Statement

Conflicts of interest.

The authors declare no conflict of interest.

Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

• P-ISSN 0974-6846 E-ISSN 0974-5645

Indian Journal of Science and Technology

• Full-Text HTML
• Full-Text PDF
• How to Cite

DOI : 10.17485/ijst/2017/v10i29/112447

Year : 2017, Volume : 10, Issue : 29, Pages : 1-9

Original Article

Software Defined Networking: Research Issues, Challenges and Opportunities

Shailendra Mishra 1* and Mohammed Abdul Rahman AlShehri 2

1 Department of Computer Engineering, College of Computer & Information, Majmaah University, Saudi Arabia; [email protected]                                                                 2 Department of Information Technology, College of Computer & Information Sciences, Majmaah University, Saudi Arabia

*Author For Correspondence Shailendra Mishra                                                                                                                      Department of Computer Engineering, College of Computer & Information, Majmaah University, Saudi Arabia;                                                                                                    [email protected]  

Objectives: This paper focuses on challenges, opportunities and research issues of software defined networking (SDN), as well as how to select the best possible SDN controller, which in result will help to reduce the complexity of a network, price of implementation and maintenance of the network in any big organization. Methods/Statistical Analysis: In order to meet the objective, the review of literature has been carried out in the following contexts; Software defined networking, SDN protocol (Open Flow) and SDN research challenges. Software defined networking is one of the most discussed topic these days. This technology is being considered one of the favorable technologies for isolation of control plane and data plane and logical placement of centralized control from SDN controller. This research focuses on major issues, challenges and current requirements of network implemented in any big organization where traditional network is being implemented. Findings: To solve the issues of multiple located branch networks, cost, technical resources at each location, expertise, separate control plane for configurations, decentralized visibility of network devices, separate VLANs for each branch, complex traffic engineering, limited physical access of branches w.r.t working hours, bandwidth bottleneck at each branch, we surveyed literatures and web resources for the existing SDN controllers like NOX, POX, Ryu, Floodlight, and Open Daylight etc. All these controllers are based on Open Flow protocol. The primary concern is that a conventional system develops gradually, it has a generally abnormal state of operational expenditure and moderately static in nature. SDN holds the guarantee of overcoming those confinements. Major issues which are being faced are increasing requirements from user side, bandwidth availability, hardware (switches requirement at every place), technical resources are required at remote site for configurations, scalability issues, cost, high level processing power at each device, traffic engineering, resiliency against failures, decentralized visibility of hardware devices etc. SDN will helps to improve centralized visibility as all the underlying open flow switches are connected to controller, all switches can be configured from SDN controller without accessing individual switches. Research papers referred in this paper provide a bird eye view of what may cause hurdles further in development and technology integration of technology. Application/Improvements: This research will help how to select the best possible SDN controller which in result will help scalability, less hardware and software requirements, less technical resources requirements, centralized visibility, hassle free traffic engineering and high availability of network.

Keywords: AHP, MCDM, Openflow, SDN, SDN Controller

• 22 April 2020

How to cite this paper

Mishra and AlShehri, Software Defined Networking: Research Issues, Challenges and Opportunities . Indian Journal of Science and Technology. 2017: 10(29);1-9

More articles

Non-invasive Estimation of Oxygen Saturation Level in Blood

07 April 2020

Serum Tissue Non Specific Alkaline Phosphatase Isoenzyme Level and ...

25 May 2020

Tao-Mason equation of state for refractory metals

20 April 2020

Productivity of Labor based on Labor Intensive Work for Small Group...

Modeling and Deformation Analysis of Piezoresistive Cantilever for ...

29 May 2020

Strong Gamma Group

28 June 2023

Design and Development of Linear Velocity Measurement System using ...

26 May 2020

Computer Assisted QSAR/QSPR Approaches – A Review

04 May 2020

The Study on the Analysis System of Effective Attack Patterns in Ke...

Archaeogenetics: advent of genetics in field of archaeology

06 April 2020

DON'T MISS OUT!

Subscribe now for latest articles and news.

Help | Advanced Search

Computer Science > Cryptography and Security

Title: an incremental hybrid adaptive network-based ids in software defined networks to detect stealth attacks.

Abstract: Network attacks have became increasingly more sophisticated and stealthy due to the advances in technologies and the growing sophistication of attackers. Advanced Persistent Threats (APTs) are a type of attack that implement a wide range of strategies to evade detection and be under the defence radar. Software Defined Network (SDN) is a network paradigm that implements dynamic configuration by separating the control plane from the network plane. This approach improves security aspects by facilitating the employment of network intrusion detection systems. Implementing Machine Learning (ML) techniques in Intrusion Detection Systems (IDSs) is widely used to detect such attacks but has a challenge when the data distribution changes. Concept drift is a term that describes the change in the relationship between the input data and the target value (label or class). The model is expected to degrade as certain forms of change occur. In this paper, the primary form of change will be in user behaviour (particularly changes in attacker behaviour). It is essential for a model to adapt itself to deviations in data distribution. SDN can help in monitoring changes in data distribution. This paper discusses changes in stealth attacker behaviour. The work described here investigates various concept drift detection algorithms. An incremental hybrid adaptive Network Intrusion Detection System (NIDS) is proposed to tackle the issue of concept drift in SDN. It can detect known and unknown attacks. The model is evaluated over different datasets showing promising results.

Submission history

Access paper:.

• HTML (experimental)
• Other Formats

References & Citations

• Google Scholar
• Semantic Scholar

BibTeX formatted citation

Bibliographic and Citation Tools

Code, data and media associated with this article, recommenders and search tools.

• Institution

arXivLabs: experimental projects with community collaborators

arXivLabs is a framework that allows collaborators to develop and share new arXiv features directly on our website.

Both individuals and organizations that work with arXivLabs have embraced and accepted our values of openness, community, excellence, and user data privacy. arXiv is committed to these values and only works with partners that adhere to them.

Have an idea for a project that will add value for arXiv's community? Learn more about arXivLabs .

Thank you for visiting nature.com. You are using a browser version with limited support for CSS. To obtain the best experience, we recommend you use a more up to date browser (or turn off compatibility mode in Internet Explorer). In the meantime, to ensure continued support, we are displaying the site without styles and JavaScript.

• View all journals
• Explore content
• About the journal
• Publish with us
• Sign up for alerts
• Published: 27 March 2024

A global timekeeping problem postponed by global warming

• Duncan Carr Agnew   ORCID: orcid.org/0000-0002-2360-7783 1  

Nature ( 2024 ) Cite this article

7425 Accesses

1 Citations

2387 Altmetric

Metrics details

• Applied physics
• Electrical and electronic engineering
• Information technology

The historical association of time with the rotation of Earth has meant that Coordinated Universal Time (UTC) closely follows this rotation 1 . Because the rotation rate is not constant, UTC contains discontinuities (leap seconds), which complicates its use in computer networks 2 . Since 1972, all UTC discontinuities have required that a leap second be added 3 . Here we show that increased melting of ice in Greenland and Antarctica, measured by satellite gravity 4 , 5 , has decreased the angular velocity of Earth more rapidly than before. Removing this effect from the observed angular velocity shows that since 1972, the angular velocity of the liquid core of Earth has been decreasing at a constant rate that has steadily increased the angular velocity of the rest of the Earth. Extrapolating the trends for the core and other relevant phenomena to predict future Earth orientation shows that UTC as now defined will require a negative discontinuity by 2029. This will pose an unprecedented problem for computer network timing and may require changes in UTC to be made earlier than is planned. If polar ice melting had not recently accelerated, this problem would occur 3 years earlier: global warming is already affecting global timekeeping.

This is a preview of subscription content, access via your institution

Access options

Access Nature and 54 other Nature Portfolio journals

Get Nature+, our best-value online-access subscription

24,99 € / 30 days

cancel any time

Subscribe to this journal

Receive 51 print issues and online access

185,98 € per year

only 3,65 € per issue

Rent or buy this article

Prices vary by article type

Prices may be subject to local taxes which are calculated during checkout

Similar content being viewed by others

The global historical climate database HCLIM

Elin Lundstad, Yuri Brugnara, … Stefan Brönnimann

Smooth velocity fields for tracking climate change

Iaroslav Gaponenko, Guillaume Rohat, … Jérôme Kasparian

ClimateEU, scale-free climate normals, historical time series, and future projections for Europe

Maurizio Marchi, Dante Castellanos-Acuña, … Annette Menzel

Data availability

The J 2 data are C20LongTerm.txt, downloaded from https://filedrop.csr.utexas.edu/pub/slr/degree_2/ on 25 October 2023. The Earth rotation data are eopc0420.1962-now, downloaded from https://datacenter.iers.org/products/eop/long-term/c04_20/ on 24 October 2023. The atmospheric angular momentum data are from https://datacenter.iers.org/products/geofluids/atmosphere/aam/GGFC2010/AER/ , downloaded on 1 February 2023. Other parameters are taken from the papers referenced.  Source data are provided with this paper.

Code availability

The code for analysing the residual series, est.noise v.1.2, was downloaded from https://github.com/langbein-usgs on 25 June 2023. The seasonal-adjustment code stl was slightly modified from a version downloaded from https://netlib.org/a/ in June 2008.

McCarthy, D. D. & Seidelmann, P. K. Time: From Earth Rotation to Atomic Physics (Cambridge Univ. Press, 2018).

Levine, J., Tavella, P. & Milton, M. Towards a consensus on a continuous coordinated universal time. Metrologia 60 , 014001 (2023).

Article   Google Scholar  

Nelson, R. A. et al. The leap second: its history and possible future. Metrologia 38 , 509–529 (2001).

Loomis, B. D., Rachlin, K. E. & Luthcke, S. B. Improved Earth oblateness rate reveals increased ice sheet losses and mass-driven sea level rise. Geophys. Res. Lett. 46 , 6910–6917 (2019).

Cheng, M. & Ries, J. C 20 and C 30 variations from SLR for GRACE/GRACE-FO science applications. J. Geophys. Res. Solid Earth 128 , e2022JB025459 (2023).

Lombardi, M. A., Novick, A. N., Neville-Neil, G. & Cooke, B. Accurate, traceable, and verifiable time synchronization for world financial markets. J. Res. Natl Inst. Stand. Technol. 121 , 436–463 (2016).

Addomine, M. in A General History of Horology (eds Turner, A. et al.) 137–152 (Oxford Univ. Press, 2022).

Glennie, P. & Thrift, N. Shaping the Day: A History of Timekeeping in England and Wales 1300–1800 (Oxford Univ. Press, 2009).

Kinns, R. Visual time signals for mariners between their introduction and 1947: a new perspective. J. Astron. Hist. Herit. 25 , 601–713 (2022).

Ellis, W. Lecture on the Greenwich system of time signals. Horol. J. 7 , 85–91, 97–102, 109–114, 121–124 (1865).

Google Scholar  

Nye, J. & Rooney, D. in A General History of Horology (eds Turner, A. et al.) 495–531 (Oxford Univ. Press, 2022).

Nelson, G. K., Lombardi, M. A. & Okayama, D. T. NIST time and frequency radio stations: Www, WWVH, and WWVB. NIST Special Publication 250-67 (U.S. Department of Commerce, 2005).

Agnew, D. C. Time marks and clock corrections: a century of seismological timekeeping. Seismol. Res. Let. 91 , 1417–1429 (2020).

Bullard, E. C. An atomic standard of frequency and time interval: definition of the second of time. Nature 176 , 282 (1955).

Guinot, B. & Arias, E. F. Atomic time-keeping from 1955 to the present. Metrologia 42 , S20–S30 (2005).

Leschiutta, S. The definition of the ‘atomic’ second. Metrologia 42 , S10–S19 (2005).

Munk, W. H. & McDonald, G. The Rotation of the Earth: A Geophysical Discussion (Cambridge Univ. Press, 1960).

Ray, R. D. & Erofeeva, S. Y. Long-period tidal variations in the length of day. J. Geophys. Res. 119 , 1498–1509 (2014).

Gross, R. S. in Treatise on Geophysics: Geodesy (ed. Herring, T. A.) 215–261 (Elsevier, 2015).

Haigh, I. D. et al. The tides they are a-changin’: a comprehensive review of past and future nonastronomical changes in tides, their driving mechanisms, and future implications. Rev. Geophys. 58 , e2018RG000636 (2020).

Williams, J. G. & Boggs, D. H. Secular tidal changes in lunar orbit and Earth rotation. Celest. Mech. Dyn. Astron. 126 , 89–129 (2016).

Article   MathSciNet   Google Scholar  

Whitehouse, P. L. Glacial isostatic adjustment modelling: historical perspectives, recent advances, and future directions. Earth Surf. Dynam. 6 , 401–429 (2018).

Peltier, W. R., Wu, P. P.-C., Argus, D. F., Li, T. & Velay-Vitow, J. Glacial isostatic adjustment: physical models and observational constraints. Rep. Prog. Phys. 85 , 096801 (2022).

Mitrovica, J. et al. Reconciling past changes in Earth’s rotation with 20th century global sea-level rise: Resolving Munk’s enigma. Sci. Adv. 1 , e1500679 (2015).

Article   PubMed   PubMed Central   Google Scholar  

Kim, A. J. et al. Ice age effects on the satellite-derived \({\dot{J}}_{2}\) datum: mapping the sensitivity to 3D variations in mantle viscosity. Earth Planet. Sci. Lett. 581 , 117372 (2022).

Article   CAS   Google Scholar  

Seago, J. H. in Requirements for UTC and Civil Timekeeping on Earth (eds Seago, J. H. et al.) 107–125 (Univelt, American Astronautical Society, 2013).

Cheng, M., Tapley, B. & Ries, J. Deceleration in the Earth’s oblateness. J. Geophys. Res. Solid Earth 118 , 740–747 (2013).

Lau, H. C. P. et al. Inferences of mantle viscosity based on ice age data sets: Radial structure. J. Geophys. Res. Solid Earth 121 , 6991–7012 (2016).

Mitrovica, J. X. & Peltier, W. R. Present-day secular variations in the zonal harmonics of Earth’s geopotential. J. Geophys. Res. Solid Earth 98 , 4509–4526 (1993).

Cox, C. M. & Chao, B. F. Detection of a large-scale mass redistribution in the terrestrial system since 1998. Science 297 , 831–833 (2002).

Article   CAS   PubMed   Google Scholar  

Roy, K. & Peltier, W. R. GRACE era secular trends in Earth rotation parameters: a global scale impact of the global warming process? Geophys. Res. Lett. L10306 (2011).

Fox-Kemper, B. et al. in Climate Change 2021: The Physical Science Basis. Sixth Assessment Report of the Intergovernmental Panel on Climate Change (eds Masson-Delmotte, V. et al.) 1211–1362 (Cambridge Univ. Press, 2021).

Barnoud, A. et al. Revisiting the global mean ocean mass budget over 2005–2020. Ocean Sci. 19 , 321–334 (2023).

Wilson, C. The Hill-Brown Theory of the Moon’s Motion: Its Coming-to-Be and Short-Lived Ascendancy ( 1877–1984 ) (Springer, 2010).

Kono, M. (ed.) Treatise on Geophysics, Vol. 5: Geomagnetism (series ed. Schubert, G.) (Elsevier, 2015).

Olson, P. (ed.) Treatise on Geophysics, Vol. 8: Core Dynamics (series ed. Schubert, G.) (Elsevier, 2015).

Langbein, J. Methods for rapidly estimating velocity precision from GNSS time series in the presence of temporal correlation: A new method and comparison of existing methods. J. Geophys. Res. Solid Earth 125 , e2019JB019132 (2020).

Constable, C. & Constable, S. A grand spectrum of the geomagnetic field. Phys. Earth Planet. Inter. 344 , 107090 (2023).

Stephenson, F. R., Morrison, L. V. & Hohenkerk, C. Y. Measurement of the Earth’s rotation: 720 BC to AD 2015. Proc. R. Soc. A 472 , 20160404 (2016).

Article   CAS   PubMed   PubMed Central   Google Scholar  

Huber, P. J. Modeling the length of day and extrapolating the rotation of the Earth. J. Geod. 80 , 283–303 (2006).

Morrison, L. V., Stephenson, F. R., Hohenkerk, C. Y. & Zawilski, M. Addendum 2020 to ‘Measurement of the Earth’s rotation: 720 BC to AD 2015’. Proc. R. Soc. A 477 , 20200776 (2021).

Bell, S. A., Bangert, J. A. & Kaplan, G. H. in The History of Celestial Navigation: Rise of the Royal Observatory and Nautical Almanacs (eds Seidelmann, P. K. & Hohenkerk, C. Y.) 263–311 (Springer, 2020).

Burnicki, M. in Requirements for UTC and Civil Timekeeping on Earth (eds Seago, J. H. et al.) 35–46 (Univelt, American Astronautical Society, 2013).

Seidelmann, P. K. & Seago, J. H. Time scales, their users, and leap seconds. Metrologia 48 , S186–S194 (2011).

Seago, J. H., Seaman, R. L., Seidelmann, P. K. & Allen, S. L. (eds) Requirements for UTC and Civil Timekeeping on Earth (Univelt, American Astronautical Society, 2013).

Birth, K. in Law and Time (eds Benyon-Jones, S. M. & Grabham, E.) 196–211 (Routledge, 2018).

Cleveland, R. B., Cleveland, W. S., McRae, J. E. & Terpenning, I. STL: a seasonal-trend decomposition procedure based on loess. J. Off. Stat. 6 , 3–73 (1990).

Johnson, H. & Agnew, D. C. Monument motion and measurements of crustal velocities. Geophys. Res. Lett. 22 , 2905–2908 (1995).

Download references

Acknowledgements

I thank R. Ray, L. Morrison, A. Borsa, J. Mitrovica and M. King for their comments.

Author information

Authors and affiliations.

Institute of Geophysics and Planetary Physics, Scripps Institution of Oceanography, University of California San Diego, La Jolla, CA, USA

Duncan Carr Agnew

You can also search for this author in PubMed   Google Scholar

Corresponding author

Correspondence to Duncan Carr Agnew .

Ethics declarations

Competing interests.

The author declares no competing interests.

Peer review

Peer review information.

Nature thanks Jerry Mitrovica and the other, anonymous, reviewer(s) for their contribution to the peer review of this work.

Additional information

Publisher’s note Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Source data

Source data fig. 1, source data fig. 2, rights and permissions.

Springer Nature or its licensor (e.g. a society or other partner) holds exclusive rights to this article under a publishing agreement with the author(s) or other rightsholder(s); author self-archiving of the accepted manuscript version of this article is solely governed by the terms of such publishing agreement and applicable law.

Reprints and permissions

About this article

Cite this article.

Agnew, D.C. A global timekeeping problem postponed by global warming. Nature (2024). https://doi.org/10.1038/s41586-024-07170-0

Download citation

Received : 04 August 2023

Accepted : 06 February 2024

Published : 27 March 2024

DOI : https://doi.org/10.1038/s41586-024-07170-0

Share this article

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

This article is cited by

Climate change has slowed earth’s rotation — and could affect how we keep time.

• Elizabeth Gibney

Nature (2024)

By submitting a comment you agree to abide by our Terms and Community Guidelines . If you find something abusive or that does not comply with our terms or guidelines please flag it as inappropriate.

Quick links

• Explore articles by subject
• Guide to authors
• Editorial policies

Sign up for the Nature Briefing newsletter — what matters in science, free to your inbox daily.