1 Introduction

The increasing use of multimedia contents and the rising demand for big data analysis require higher networking connecting speeds fulfill the social needs of the world’s growing population. It is projected that annual global internet traffic may grow by compound annual growth rate (CAGR) of 23 % from 2014 to 2019, and it may exceed to 1.1 ZB per year or 88.4 EB (one billion GB) per month by 2016 and it is expected to grow 2.0 ZB per year or 168.0 EB per month by 2019 [1]. The increase in mobile connected devices is also being predicted to surpass the number of people on the earth by 2014 and is expected to be 1.4 devices per capita by 2018 [2, 3]. It is also estimated that traffic from wireless and mobile devices will increase manifold in future. This change in scenario of Internet traffic indicates that there will be increase in wireless traffic comprising Wi-Fi, mobile devices by 2019 to 66 % and that of wired traffic will decrease from 54 % in 2014 to 33 % in 2019 [1]. However, it may also be pointed out that by 2019 the Internet connections are estimated to be three times higher than that of global population and per capita Internet traffic will increases from 8 to 22 GB [1]. In India, it is estimated that at present about 980 million mobile users and about 300 million internet connections are operating [4]. The future endeavor will be to cover the remaining population through Digital India Mission. The existing and emerging trend in information and communication technology (ICT) is towards high performance applications, which include mobile computing, ultra high definition (UHD) video on demand, internet of things, cloud computing, fog computing and big data etc. may govern this traffic growth, which can only be controlled by high-capacity dense wave division multiplexing i.e., DWDM circuit switched optical networks [3]. To handle such a huge traffic as well as future Internet applications with efficient and economical delivery of packets is a big challenge for the network administrator. SDN has emerged as a well-organized networking technology in this fast changing scenario of networking, which is accomplished by providing the support to the dynamic characteristics of future network (FN) applications, while having less capital and operating cost through easy to control hardware and simplified software management [3].

SDN has three defining characteristics. First, the ability to decouple the data plane (i.e., forward packets as per the decision taken by the control layer) from the control plane (i.e., routing decision or which analyze the received packet and govern the decision in what way to handle the traffic in routers and switches). Second, SDN provides a unified control plane, in such a manner that a multiple data-plane elements can be controlled via a single software program. The SDN control plane extends direct control over network’s data plane elements i.e., switches and interfaces control and data plane via OpenFlow, which is most commonly, used application programming interface (API). Third, this archetype provides networking administrator, a worldwide view of entire network and allows making changes globally instead of making changes on each individual hardware unit (device-centric configuration). This innovative technology and concept was originally proposed by Nicira Networks, which was based on their previous development at UCB, Standford, CMU, Princwton [5, 6]. Recent work in the field of SDN explores application and extension to a wide range of networks which may include home networks, cellular core networks, enterprise networks, cellular, and Wi-Fi radio access networks etc.

In this article study has been carried out on the SDN literature elaborating its basic concept and architectural principle, indicating recent and future advancement in SDN. We also presented our proposed architecture. Due attention is also given on current researches being carried out. Accordingly, present article is organized as follows: in Sect. 2, we begin with the comparison to understand SDN as advancement over conventional network. Section 3, includes discussion on the motivation behind SDN for adopting it as a FN. Section 4, explains historical evolution in relation to SDN over the past 20 years. Section 5, provide a detail information about SDN technology and its three layer architecture with various techniques used to interface NEs with OpenFlow based SDN, which includes south and northbound APIs, east and westbound APIs. Section 6, covers the domain of Openflow and its advancement with the passage of time. Section 7, illustrate the working of SDN. Section 8, in this discussion is on selective SDN architecture design’s applications, technique used to interface NEs with centralized unified controller and their performance. Section 9, discusses in detail our proposed SDHN as FN architecture. Section 10, in this discussion is on SDN’s current research projects, indicating its progress towards standardization as NGN. Finally, Sect. 11 concludes with a discussion on “SDN: Architecture for NGN”.

2 SDN as an Advancement over Conventional Network

Conventional networks implement various dedicated algorithms and set of rules on hardware components like application specific integrated circuits (ASICs) to monitor and control the flow of data in the network, supervising routing paths and responsible for configuring various NEs with each other in the network path [5, 6]. When the packets are received by the routing devices, in a conventional network, it employs a set of rules, which are already entrenched in its firmware to detect the routing path for that packets as well as address of the destination device in the network. Generally data packets are handled in similar manner, which may be directed to the same destination and all this occurs in an inexpensive routing device. Moreover, special routing device i.e., Cisco router may have the ability to treat different packets depending on their nature and contents. It allows the administrator to mark out priorities of different flows through customized local router programming. Thus, the queue size in each router can manage packets flow directly. Such a customized local router setup allows the operators to handle traffic more efficiently in terms of congestion and prioritization control. The current network devices have the limitation on network performance due to high network traffic, which hinders the network performance in terms of speed, scalability, security, and reliability. The current network devices lack the dynamism in operation, which is related to different types of packets and their contents. It may be attributed to inability to reprograming of the network operation due to the underlying hardwired implementation of routing rules and various protocols [5, 7]. To overcome this, suitable handling of data rules are required in the form of software module. It will help in improving control over the network traffic by efficient utilization of network resources, which may lead to a state-of-the-art technology, known as SDN [8]. It also enables a cloud user to use cloud resources such as storage, processing (compute), bandwidth, and virtual machines (VMs) or conduct scientific experiments by creating virtual flow slices more efficiently. The goal of SDN is to provide a framework with open, user-controlled management for the forwarding devices in a network. In it, depending upon the scale of the network, the control plane may have one or multiple controllers. In case of multiple controller environments, a high speed, reliable distributed network control can be formed with peer-to-peer (P2P) configuration. In large-scale, high speed computing network, segregation of data plane from control plane plays an important role in SDN, wherein, switches use flow table for packet forwarding in data plane. Flow table comprise list of flow entries and each entry has three fields i.e., matching, counter and instruction. It leads to improved performance of network in relation to data handling, control and network management. It is due to the fact, that software module (applications) helps administrator to control data flow along with desired change in the characteristics of switching and routing device in network from central location without dealing with each device individually in the network [5]. The comparison between conventional network and SDN is shown in Table 1.

Table 1 Comparison between conventional and SDN [9]
Full size table

It may also, be stated that an advancement in SDN is to stay as an extra-ordinary evolutionary step, wherein, the OpenFlow standards are also employed along with new services by leveraging virtualization in particular to optical transport network control and management for further improving its capacity domain and efficiency. In view of technological advances of Internet, complex processes are involved and efforts are being made to solve diverse social problems. Research and development are currently underway to realize NGN. An all-optical network is promising technology for FN. In this optical packet and circuit integrated network (OPCInet) offer diverse services, increase functional flexibility along with efficiency in energy consumption with high speed switching in a packet based SDN system in the metro/core network [10].

3 Motivation

Motivation for adopting SDN technology as NGN can be visualized from the facts given hereunder:

  • To accommodate the fast expending traffic, flow addition investment will be required in the network infrastructure to enhance the capacity of existing computer network. With this, network becomes enormous in size, even for small size organization would require 100-to-1000s of devices. As the nature of networks is heterogeneous, because of the deployment of equipment’s, applications and services are provided by different manufactures, vendors and providers, the management of the networks is very complex. Even human factor also contributes to network downtime (faulty) due to manual configuration of the network equipment (NE) as well as network devices outage may also be responsible. Due to these difficulties traditional approach for configuration, optimization and troubleshooting would become inefficient and in some cases insufficient. To overcome these aforementioned problems SDN is touted to provide promising solution by segregating the control logic from the data plane and allow flexibility, efficiency in operation and management of the network via software programs.

  • Scalability, reliability, and network performance are main concerns for efficient operation of software defined optical network (SDON) especially at the initial stage when control logic is off-loaded from the switching node. From the study on large emulated network with 100,000 endpoints and 256 switches it is observed that at least 50,000 new flow requests per second are managed by various OpenFlow controller implementations like NOX-MT, Maestro, Beacon etc. [11]. This indicates that surprising large number of new flow requests can be handled by single controller. Thus, the problems of scalability, reliability, and network performance are addressed efficiently.

  • For on demand mobility and migration of services optical-technology-based SDN can be deployed to simplify implementation of programmable traffic flow control and load balancing arrangements providing inside a data center (DC). Wherein, bandwidth and latency required for different applications (different traffic flow) are taken into consideration [12].

  • The current networks are mostly designed for optimum utilization of the underlying infrastructure and the assigned spectrum is overprovisioned. In view of this, new elastic-optical networking (EON) technology was proposed in SDON. Wherein, flexible spectrum bandwidth is allocated to each individual data link without using static wavelength grid. In this flexible bandwidth network, the adaptability is more because the spare spectrum is allocated to re-routed signals, which make it a smart network to utilize its resources with great optimization [13].

  • Moreover, SDN can integrate multiple transport technology and multi network domain efficiently and effectively [12].

4 Literature Survey on Historical Evolution of SDN

Take off in internet and its historical evolution in relation to SDN is just about 20 years old, which may be divided into various stages as depicted in Fig. 2 and each one has its role to play towards historical evolution. Each event as indicated in Fig. 2 was classified on the basis of working group, author’s name, techniques used to interface control-data plane, routing traffic control optimization and operating system. First stage relates to “Active Networks” (period from 1995 to 2001). In this period, programmable functions were introduced and that enabled the network operators to have greater innovations [14, 15]. Second stage relates to “Control and Data plane separation” (period started from1998 to 2007), wherein, during this period various open interfaces for communication between the control and data planes were developed. In third stage, the “OpenFlow API and network operating systems (NOSs)” (from 2007 to 2014), the extensive use of an open interface and other ways developed made scalability and segregation of control-data plane easy and practicable. During this period, various operating systems were also developed like NOX, Onix and open networking operating system (ONOS). Further, network virtualization (NV) (splicing) played an important role and primarily focused on to find better techniques for route traffic flow and for a wide range of applications [16–18]. However, advancement in NV goes in parallel along with other stages as indicated in the Fig. 2. The brief description to further elaborate the Fig. 2, on the nature of work carried out by various authors is given on Table 2.

Fig. 1
figure 1

Conventional network node compared with the SDN node [9]. a conventional approach (each individual network node has its own control and data plane management). b SDN approach (the control logic is off-loaded into controller from the network node)

Full size image
Fig. 2
figure 2

Illustrate selective historical evolution in relation to SDN over the past 20 years, with advancement in NV in chronological order [16]

Full size image
Table 2 Brief description of selective historical evolution in sdn architecture in chorological order
Full size table

Table 2 elucidate as to how, advancement was brought about in networking from active networking to OpenFlow based SDN and Virtualization, which helped in extending the domain of SDN.

5 Literature Survey on SDN Technology and Architecture

SDN a framework to allow network administrators to automatically and dynamically manage and control a large number of network devices, topology, services, packet handling quality of service (QoS) and traffic paths policies using high-level languages and APIs. Management includes provisioning, operating, monitoring, optimizing, and managing faults, configuration, accounting, performance and security (FCAPS) using optical media in a multi-domain environment [47]. The block diagram of SDN is as shown in Fig. 3. SDN emphasis on five main features:

Fig. 3
figure 3

Illustrate the functional architecture of SDN, which comprise of Infrastructure, controller and application layer [9]

Full size image

  • Segregate the data plane from the control plane.

  • Obtain global view of the entire network and provide it to the centralized controller.

  • Open interfaces between the devices in the data plane and those in the control plane i.e., controllers.

  • Network can be programed by external applications.

  • Ensure aggregate traffic management.

5.1 Infrastructure Layer

The bottom tier of Fig. 3 is known as infrastructure layer. It comprises physical NE like Ethernet switches, routers, optical switches, virtual switches and wireless access point (AP) to name a few and it forms the data plane. All these physical NE’s are interconnected to form a single network. The switching devices are interconnected through different transmission media, such as copper wires, wireless radio, and also optical fiber. In this layer, the researcher’s interest pertains to efficient operations of switching devices and optimizing utilization of transmission media.

5.1.1 Switching Devices

In a SDN, switching devices simply act as packet forwarding hardware, which is accessible through an open interface, where the control logic and algorithms are off-loaded to a controller. In SDN terminology, these forwarding devices are simply known as “switches”. There are two types of switches in an OpenFlow network, such as pure and hybrid. Pure OpenFlow switches completely depend upon a controller for forwarding decisions, whereas hybrid switches support traditional operation as well as protocols and are mostly in commercial use. As in a data plane, these switching devices communicate with the controller to receive the rules, which include packet forwarding rules at a switching level, and link tuning rules at a data-link level and stores the same in its local memory like ternary content addressable memory (TCAM) and static random access memory (SRAM). On the arrival of the packet, these switching device first matches to identify the forwarding rule of the packet and then forward the packet accordingly to next hop. Compared to the legacy networks the packet forwarding rules based on IP or media access control (MAC) addresses, whereas in SDN packet forwarding can also depend on other parameters, like transmission control protocol (TCP) or user data protocol (UDP) port, virtual local area network (VLAN) tag, and ingress switch port [3].

The one major design constraints related to these switches is the efficient utilization of the onboard/local memory. Memory usage depends on the network scale in case of Large scale network huge memory space is required, otherwise constant hardware up-gradation is required to avoid packet dropping or repeatedly directing packet to the controller for further necessary decisions on how to process them and this results in degradation of controller performance [48]. Several solutions are proposed for optimum utilization of the local/onboard memory including route aggregation or summarization and proper cache replacement policy. In this, the memory usage can be reduced by aggregating several routing records with a common routing prefix to a single new routing record having common prefix and with proper cache replacement policy that can improve packet forwarding hit rate. Thus the limited memory can be used effectively and efficiently. Secondly, by improving design of SDN switching devices carefully by integrating various storage technologies to get desired memory size, processing speed and flexibility with reasonable price and complexity. Different storage hardware display varied characteristics, such as SRAM is more flexible being easily scale up, whereas TCAM provides faster searching speed for packet classification, but they are expensive as well as power hungry. Both SRAM and TCAM are used to balance the trade-off between packet classification performance and flexibility [3, 49, 50].

5.1.2 Optical Switching

Even today most of the networking equipment that are used in network are still working on the principle of electronic signals, that mean initially optical signals are converted into electrical ones and thereafter these signals are regenerated, amplified or switched, and then again converted back to optical ones. This phenomenon is usually referred as an ‘optical-to-electrical-to-optical’ (OEO) conversion and with this a significant delay will be generated in the transmission. Optical switches are used to replace the current electronic NEs with optical ones, so that, the necessity of OEO conversions can be eliminated. The benefits of avoiding the OEO conversion stages are significant, as optical switching are inexpensive because there is no need for lots of expensive high-speed electronics.

5.1.3 Virtual Switches

These are purposely built for use in virtualized environments and are referred as Open vSwitch. These switches are used to interface VMs with physical interface via Open vSwitch rather than directly connected to the NICs to manage flow of traffic efficiently. Open vSwitch is well-matched with almost Linux-based virtualization environments besides QEMU, Xen, KVM, and XenServer [43].

5.1.4 Transmission Media

As SDN includes all possible transmission media, such as wired, wireless and optical environments, in order to achieve a ubiquitous coverage, each transmission media have its own unique characteristics, which need specific configuration and management technologies. In order to increase its service area, SDN needs integration with wireless and optical network technologies.

5.1.5 Wireless Access Point

It permits wireless devices to have a connection with wired network using Wi-Fi or related standards, where it acts as a central transmitter and receiver of wireless radio signals. Old AP used to support only 20 clients which have now been increased to 255 clients and may further increase with advancement of technology. To increase spectrum utilization in the wireless networks, many advanced technologies have come into operation, which may include software-defined radio (SDR) that permits the control of wireless transmission strategy through software. Due to its similar nature, it can be easily integrated with SDN, wherein, the central controller can manage link association, channel selection, transmission rate and traffic shaping for both clients and APs through the API based on current and historical measurement information, which includes total number of packets, total packet size, and total airtime utilization [51].

5.1.6 Optical Fibers

Optical fibers work on the phenomenon of Total internal reflection. As they offer a high capacity with low power consumption, they are widely used in backbones of the network for aggregated traffic management. In optical network reconfigurable optical add drop multiplexers (ROADMs) devices are deployed as the idea of software reconfiguration used in wireless networks, which gives SDN controller a widespread control over all network behaviors including packet forwarding, wireless mode or channel, and optical wavelength [52, 53].

5.2 Controller Layer

As shown in the Fig. 3, the middle layer consists of the controllers that are responsible for setting up and tearing down flows and paths in the network. The controller obtains information about capacity and demand required by the networking equipment through which the traffic flows [9]. SDN controller deals with two types of entities, one related to network controlling and the other related to network monitoring. The network controlling includes policies imposed by the application layer and packet forwarding rules for the infrastructure layer. The other is related to network monitoring, in the format of local and global network status. Figure 4 depicts two counter-directional flows in the logical architecture. Wherein, through the downward flow the controller interprets the application policy into packet forwarding rules, in respect to network status. In the upward flow, the controller synchronizes network status collected from the infrastructure for networking decision making. SDN controllers can be segregated into four building components, (1) a high-level language, (2) a rule update process, (3) a network status collection process, and (4) a network status synchronization process [3].

Fig. 4
figure 4

Logical architectural design of controller which comprise of four building blocks namely, a a high level language for SDN applications to define their network operation policies, b a rule update process to install rules generated from those policies, c a network status collection process to gather network infrastructure information, and d a network status synchronization process to build a global network view using network status collected by each individual controller [3]

Full size image

5.2.1 High Level Language

The key function of the controller is to translate application requirements into packet forwarding rules. This function dictates a communication protocol i.e., a programming language between the control layer and the application layer [3]. Three important characteristics of SDN language are:

  1. 1.

    Network programming language should be capable to offer the resources that can enquire the state of network. The runtime environment of the language has the ability to collect the information about the state of network as well as statistics, and then provide this information to the application layer.

  2. 2.

    The language should have the capability to express policies of the network in relation to the packet forwarding behavior. It should be capable to combine policies of various network applications. It should also be able to resolve the conflicts, if so generated by the network applications.

  3. 3.

    Due to the existence of varied network policies; it is not convenient to reconfigure the network. Therefore, runtime environment of the language should activate the necessary update process of the devices so that it may assure the preservation of access control, avoidance of forwarding loops or other invariants are met. Frenetic, its successor Pyretic, and Procera are the common befitting SDN programming languages that are required to fulfill the present requirements [54].

5.2.2 Rules Update

SDN controller is accountable for generating packet forwarding rules. It also describes the guidelines for the packet forwarding and installs them into suitable switching devices for proper operation. At the same time, these forwarding rules in the switching devices are required to be updated due to changes in network configuration and dynamic control, such as directing traffic from one replica to another for dynamical load balancing [55] and network recovery after unexpected failure. Due to the dynamic nature of the SDN the consistency of the rules get updates and reserved to ensure the proper operation of the network, such as, loop free, no black hole, and security. Rule update consistency can be done in different way; however two of them are mentioned hereunder:

  • Strict Consistency It makes sure that either the original rule set or the updated rule set is used. This consistency is implemented at the level of processing each-packet or in a per-flow level, where all packets of a flow are processed by using either the original or the updated rule set.

  • Eventual Consistency It makes sure that the upcoming packets use the updated rule set eventually after the update procedure finishes and allows the earlier packets of the same flow to use the original rule set before or during the update procedure [3].

5.2.3 Network Status Collection

In this information about network status indicated by traffic statistics, which comprise packet number, duration time, data size and bandwidth share is collected by the controller through upward flow, and accordingly global view of entire network is constructed. This information i.e., network topology graph is to provide the application layer for further necessary decision [56]. In the working of network status collection, each switching device in the network collects and stores the statistics of local traffic in its onboard memory and this information is recovered by the controller via a “pull” mode or by the “push” mode [3].

5.2.4 Network Status Synchronization

Assigning control to a single centralized controller may lead to performance bottleneck and to overcome this multiple controllers are deployed in P2P acting as back-up or replicate controller [57]. To ensure proper operation of network, all controllers should have the ability to build and maintain a global network view using network status collected by each individual controller [3]. Tootoonchain and Ganjali [58] place in practice hyperFlow that permits sharing of global view of network among multiple controllers.

5.3 Control Layer Performance

In SND networks, performance rely on the control layer, whose performance is further limited by the scalability of the centralized controller. In such network, all the activities such as, on the arrival of first packet of each flow switching devices have to request for packet forwarding rules, collecting information about the network status and rules updates requires continuous communication between the controller and switches, which leads to unnecessary bandwidth consumption and latency of frequent communication and thus affects the control layer performance [3]. To address these aforementioned issues, to increase processing abilities of a single controller in the control layer and to decrease the frequency of request process by the controller following efforts are to be made:

5.3.1 Increasing Processing Ability

As controller is an essential part of the SDN, the conventional techniques such as parallelism and batch processing can be used for improving controller performance on request processing. These are already in use in Maestro [59, 60], NOX-MT [11], and McNettle [61] controllers.

5.3.2 Reducing Request Frequency

As all the transactions in the network are controlled by the controller, this frequent requesting to the controller may result in longer delay in response from the SDN controller side. Many strategies have been adopted to decrease request frequency. Two of them are given here: (1) modify switch devices, so that requests can be handled in or near the data plane. In this approach, Yu et al. [62] suggests that forwarding rules are distributed among each “authority switches” in the data plan, which can handle request and divert each packet through it, which need to access appropriate forwarding rules without requesting to controller for rules. (2) By proper organization of the structure in which switching devices are deployed, can also help in improving the overall performance of the control layer [3].

5.3.3 Performance Benchmarking

In SDN controller performance benchmarking can be used to indicate the performance bottleneck, which is an important parameter to increase the processing ability of controller. The two tools that are designed for measuring controller performance benchmarking are Cbench [63] and OFCbench [64].

5.4 Controller Interface

5.4.1 Protocol Options for the Southbound Interface

As shown in Fig. 3, link that connects control layer with the physical layer via API is referred as southbound API. OpenFlow is the most commonly used south bound interface. It was standardized by the ONF established in 2011. The main purpose of the OpenFlow is to standardize the communication between the switches and the software-based controller in SDN architecture [65]. Whereas, ForCES can also be used for exchange of information between control and data plane as a second southbound interface option. As compared to OpenFlow, ForCES is having more flexible mode and rich protocol features. But due to some disruptive business model and lack of open source support, it is not so widely adopted as OpenFlow. However, OpenFlow still has to learn more from both merits and shortcoming of ForCES for its future success [3].

In SoftRouter architecture, the control plane functions are segregated from the packet forwarding data plane functions and provide dynamic association between control and forwarding plane elements, which permit the dynamic allocation of control and data plane elements. This architecture has certain advantages over the border gateway protocol (BGP) with regards to its reliability [28]. Both ForCES and SoftRouter have resemblance in their operation with respect to OpenFlow and can be used as alternative southbound interfaces.

One of the most commonly used protocol between the control layer and the physical layer is PCE protocol, a special protocol that permits the path computation client (PCC) to request for path computation from PCE and PCE protocol also acknowledges for the same as shown in the Fig. 5. PCE may have the complete knowledge/picture of flow and path in the network. When a new client comes online, PCC sends request for path computation to the PCE as the PCE have a complete traffic engineering database. The client traffic requirement is calculated and superimposed on the current network’s topology. This protocol was developed by IETF PCE working group. Moreover, PCE may be centralized or may be distributed in many or every controller/router [47].

Fig. 5
figure 5

Illustrate the working of PCE protocol [47]

Full size image
Fig. 6
figure 6

OpenFlow agent abstraction [12, 66]

Full size image
Fig. 7
figure 7

Illustrate OpenFlow: a architecture of OpenFlow, b mechanism for packet forwarding in a switch with OpenFlow, and c flow table entry [54]

Full size image

5.4.2 OpenFlow Protocol Extension for Optical NEs Interface in OpenFlow-Based Optical Network

OpenFlow-based optical network uses the services of the centralized controller to manipulate the NEs i.e., optical switches in the forwarding data plane via a secured Open-Flow link protocols. In this network, OpenFlow switches are responsible for performing forwarding function according to the flow table entries and the controller host network application, such as path computation, energy management etc. OpenFlow protocols provide the abstract information related to the network, so that the control plane decision can be enforced by inserting flow rules or action into the flow table of OpenFlow switches. Three main messages are generated by the OpenFlow protocol; they are Switch feature, Flow_Mod, and CPort_status [66]. The detail of which is given in Table 3.

Table 3 Brief description of OpenFlow protocol messages [66]
Full size table

Presently, in the absence of provision of optical equipment vendor’s support for OpenFlow [66], the alternative techniques are proposed in literature and some of them have been described in brief in the Table 4.

Table 4 Describe alternative techniques to interface optical devices with OpenFlow-based SDN
Full size table

5.4.3 Northbound API for Network Applications

Like southbound interface, the control layer also provides a similar interface with application layer known as Northbound interface to extend services of the application running in the top layer. Service specific application like traffic engineering tells the controller about the path laid for the packets flow from beginning to end, whereas, controller modifies the flow table of the switches with the help of appropriate command. The famous programming languages that are used to write the application programs are flow-based management language (FML), frenetic, pyretic, and procera. FML [71] earlier known by the name flow-based security language (FSL) [72] is a language, which is used in SDN for describing network connectivity policies. Frenetic [73, 74] was introduced to remove complicated asynchronous and event-driven communication between the switching devices and SDN application. Sequential composition was introduced by pyretic [75], which permits superimposition of one rule to another rule while packet processing and it abstract the network topology information that contain maps between physical and virtual switches [3].

5.4.4 Interface Between Controllers Operate with East and Westbound APIs

Control plane has two arrangements: one is physically and second is logically centralized. Physically centralized control plane has a single controller in the control layer and communicate with large number of NEs to collect information of global network view for optimum and intelligent control of the underlying resources e.g. routing protocol design for controlling and managing flow of traffic, with centralized single controller, which may have possibility of failure and potential bottleneck while interacting with large number of NEs. Therefore, single controller deployment is not suitable solution due to lack of scalability and reliability. An alternative approach that is logically centralized control plane offers more scalability and reliability. It consists of physically distributed CEs and each CE is connected to each other through an interface so-called East and Westbound interface [54] as shown in Fig. 3. ALTO stands for application layer traffic optimization used to optimize P2P traffic and developed by IETF working group. Currently, problem with the P2P traffic is if two controllers have more compatibility, a lot of traffic will flow between two of them as compared to others, so ALTO server have the knowledge of all nodes in the network, which helps in defining where they are located, what are their characteristics, how far they are from each other, and what is link bandwidth they have, therefore ALTO provides guidance for peer selection. When ALTO client requests the server for appropriate peers, in response to this a best possible list of potential peers is provided to the client for better communication between them [47]. HyperFlow application that sits on NOX controller and activates with an event propagation system [9]. HyperFlow provide a platform to share synchronized global network view constantly with multiple controllers. It uses a publishing/subscribed system to report whenever a change is sensed in the network status e.g. when a link failure is detected by the controller in its domain, it immediately publishes an event about the change via publish/subscribe system so that other controller may know about the change in network status and with this effect a new updated status is forwarded to each controller [3, 58].

5.5 Application Layer

The top tier in the block diagram Fig. 3, that resides over the control layer is called Application layer. SDN applications continuously abstract information about the global network status via south and northbound using protocol like ALTO [76], and eXtensible session protocol (XSP)/eXtensible messaging and presence protocol (XMPP) [77] and manipulates the physical NEs using high level programming languages for writing various functional applications, such as energy-efficient networking, security monitoring, access control link, traffic engineering, PCE etc. The insight detail of the application layer is given as under:

5.5.1 Adaptive Routing

The two main functions that are performed by any network are packet switching and routing. Currently, packet switching and routing design are based on distributed approach, but this approach has certain limitations which may include slow convergence, complex implementation and restricted capability to achieve adaptive control. On the other hand, SDN operates on the principle of closed loop control, wherein, global network status information is constantly fed to the applications so that adaptive control of the network is possible. Two popular adaptive routing applications in the SDN domain are Load balancing and cross-layer design.

5.5.1.1 Load Balancing

In DCs, most commonly used technique is load balancing to have efficient resource usage. To increase throughput, reduce response time and avoid overloading of network, a front-end load balance is deployed in the DC, so that each request of the clients is directed to a particular server. Allocating a dedicated load balancer is an expensive approach and may create bottleneck as all requests are processed by the same. Wherein, SDN load balancing is done by using various algorithms for packet forwarding rules. Koerner et al. developed and implemented differentiated load balancing algorithm to have control over different types of traffic, such as web traffic and e-mail traffic [3, 78].

5.5.1.2 Cross-Layer Design

In layered architecture, the cross-layer design is responsible for increasing the integration between various entities that are lying at different layers as in OSI reference model entities at different layers are permitted to exchange information within each other. Since, SDN applications have the capability to access the network status information, this cross-layer design is most suited to deploy for increasing the overall efficiency of the network. Wang et al. introduce a cross layer approach, which has the potential to dynamically configure the underlying network element taking the benefits of high speed and re-configurability of SDN switching devices including optical switches [3, 79].

5.5.2 Boundless Roaming

Mobile devices like tablet and smartphones have the wireless access to the internet, which need continuous connectivity for ubiquitous communication. To achieve un-interrupted services, seamlessness handover has to play a vital role for its applications. However, in the current literature, handover is limited to single carrier network having the same technology. Keeping this in view, SDN provides unified central plane possessing different carriers with varied technologies to enable boundless mobility. Researchers have developed various handover technologies based on SDN.

Yap et al. [80] workout a handover algorithms involving network between WiFi and WiMax, which includes hoolock, to exploit multi-interface on a device and multi-casting. In another study with Odin, where in unique basic service set identification (BSSID) has been allocated to each client connection. In this technique, BSSID of one Physical Wireless AP is swapped with another BSSID of nearby AP during handover, which display low delay in re-association, no throughput degradation and minimum impact on HTTP downloading in either a single or multiple handover [81].

5.5.3 Networking Maintenance

In configuration error, which leads to network failure, major contribution is of human factor. Wherein, individual diagnostic tools such as ping, traceroute, tcpdump and NetFlow fail to provide automatic and compressive network maintenance solution. The centralized and automated management techniques inherited in SDN help in reducing the configuration error. Xia et al. [3] introduce a fast restoration technique for SDN in which as soon as, failure of the network is detected, the controller immediately calculates a new path for un-interpreted traffic flow with update packet forwarding rules.

5.5.4 Network Security

Currently, for network security firewalls and proxy servers are deployed to protect the physical network breach, but due to heterogeneity in the network, architecture authentic implementation of these techniques is a great challenge for the network operators. Whereas, SDN provides unified centralized control plane, which makes it convenient to implement merge and check policies to prevent security breaches [3].

5.5.5 Network Virtualization

In NV, physical network is sliced into multiple virtual network entities and further allotted them to varied user and controllers. However, in SDN, FlowVisor is most commonly used tool which permits slicing of the physical network resources such as topology, flow space (data flow table in switching), bandwidth, switching devices CPU, and control channel to create virtual network for research experimentations [3, 82].

5.5.6 Green Network

In this, main concerned are economic and environmental benefits. Heller et al. proposed an energy-aware data link adaption mechanism to work out a minimum data link and switching devices for DC network for energy efficient operations [3, 83].

6 OpenFlow

OpenFlow was originally proposed by Nick McKeown in 2008 and was further, standardized by ONF in 2011. OpenFlow was developed to standardize the communication between OpenFlow switch and the software-based controller in SDN architecture. Figure 8 shows advancement in OpenFlow in chronological order and Table 5 illustrates brief description of selective OpenFlow controller. OpenFlow decouples the control plane from the data plane and most commonly used protocol for southbound interface. The architecture of OpenFlow comprises three main components as shown in Fig. 7a; (1) OpenFlow-compliant switches constitute the data plane; (2) the control plane has one or more OpenFlow controllers; (3) the control plan is connected with switches through a secure control channel i.e., OpenFlow interface. An OpenFlow-compliant switch in the data plane simply acts as device for forwarding packets according to its flow table. A flow table comprises list of flow entries. Each entry has match fields, counters and instructions as illustrated in Fig. 7c. The mechanism for packet forwarding with OpenFlow is illustrated in Fig. 7b. When packet is received by the switch, it analyses the packet header and matching is done with the entries in flow table of the switch. If the flow table entry is matched with the header of the packet, then that particular entry is considered. If several such entries are found, in that case packets are matched on the bases of prioritization i.e., most specific entry will have the highest priority as shown in Fig. 7c. After the matching and selection process is over, and then the counter of the flow table entry is updated. Finally, the switch executes the action on the packet in accordance with the entry in the flow table e.g. forward packets to the port, encapsulate and forward to the controller, drop packet and send to normal processing pipeline. In case, if the packet header does not find match with the flow table entry, then the switch notifies the controller and encapsulates the packet and sends it to the controller with PACKET-IN message as first byte of the packet. On receiving PACKET-IN notification from the switch side, the controller finds the exact action for the packet and installs one or more suitable entries in the requesting switch flow table and then packets are forwarded according to the rules. This is triggered by explicit PACKET-OUT messages. Usually, the controller lays the entire path for the packet by altering the entries in the flow tables of all switches on the path in the network. A software program, called the controller, all the flow table entries are manipulated and populated by the controller by insertion, removal of flow entries and modifications. With this, the controller is able to modify the behavior of the switch with respect to forwarding the packets. To communicate with the switches, the controller uses the secure channel [54].

Fig. 8
figure 8

Advancement in OpenFlow in chronological order [54, 65, 84–89]

Full size image
Table 5 Brief description of selective OpenFlow controller [54, 65]
Full size table

7 Working of SDN

In SDN, Control is taken out of the individual network nodes and placed at the separate centralized controller. This controller performs various functions, such as route management, network visibility, network provisioning, NV, and orchestrates network overlays. As shown in the Fig. 3, NOS controls the SDN switches that gather information using the API, which refers as southbound and manipulates forwarding plane by providing an abstract model of the network topology to the SDN controller hosting various applications. The controller can, therefore, use the detail know how of the network for optimizing flow management and support service-user requirements of scalability and flexibility. For example, dynamic allocation of bandwidth can be done into the data plane from the application.

As illustrated in the Fig. 9 when packet arrives at the switch from the sender as a first packet of a new flow (Step 1), for this packet SDN switch checks a flow rule by matching it with the flow tables entries in the SDN cache (step 2), if a matching entry is detected in the flow table of the switch, the instructions associated with the specific flow entry are executed e.g. packet/match fields, update counter, metadata and action set. Thereafter, packets are directed towards the concerned receiver (step 5). In case, there is non-availability of the match in the flow table of the switch, then packet is directed to the controller via a secured channel (step 3). Controller analyses the packet for the source and destination IP address and accordingly updates flow table entries of the switches in the path through the southbound API i.e., OpenFlow, ForCES and PCE Protocol (step 4). The switch then forwards the packet to the appropriate port to send the packet to the receiver (step 5) [9].

Fig. 9
figure 9

Illustrate the operation of SDN controller and switch [9]

Full size image

8 Architecture Survey

Some of the selective architectures are discussed as follows:

  1. 1.

    Since presently optical equipment does not provide any support to OpenFlow and to control a wavelength switched optical network using OpenFlow protocol has not been investigated so far. Liu et al. presented a proof-of-concept to control a wavelength path in transparent optical network by using two different approaches for lightpath setup i.e., Sequential and delay approach and two different approaches for lightpath release i.e., active and passive approaches. To setup lightpath between sender and receiver, various optical nodes are interconnected to form optical network. In this paper, optical node comprising of OpenFlow switch and PXC. This combination is referred to as OpenFlow-enabled PXC (OF-PXC). In order to control this optical node through the OpenFlow protocol, they introduce “veths” concept and then this optical node is connected to the NOX controller as shown in Fig. 10. On the arrival of first packet of a new flow, OpenFlow switch encapsulates the packet and forwards it to the NOX controller. The controller analyses the packet to obtain source and destination IP address and accordingly assign route using k-shortcut path routing algorithm and assign wavelength using routing and wavelength assignment algorithm (RWA) on the basis of abstracted information. After this, NOX inserts new flow entry in the flow table of the OpenFlow switches, in response to this OpenFlow switch automatically generates transaction language-1 (TL-1) commands that instruct the PXC to cross-connect the corresponding ports using TCP interface to lay the lightpath.

    Fig. 10
    figure 10

    OpenFlow-based optical nodes [67]. a Virtualization of the physical interfaces of a PXC to virtual ethernet interfaces (veths) of an OpenFlow switch. b Architecture of an OF-PXC

    Full size image

    Sequential Approach In this approach, OpenFlow protocol controls the NEs sequentially as shown in the Fig. 11. When packets of new flow arrive at the OF-R1, it encapsulates and forwards these packets to the NOX controller, and the NOX calculates the route using PCE and accordingly assigns wavelength to the optical network and update flow entries are inserted in the flow table of OF-R1, OF-PXC1, and OF-PXC2 respectively. OpenFlow switch of OF-PXC1 and OF-PXC2 sends TL-1 command to PXC for setup of cross-connects. Due to this, the lightpath is established between OF-R1, OF-PXC1 and OF-PXC2 successfully and light flow reached at OF-R2. OF-R2 checks the flow entry in flow table. If it does not find match, it sends the new flow packet to the NOX controller and NOX accordingly updates the flow entries of the OF-R2 and with this packet reaches to the destination.

    Fig. 11
    figure 11

    Sequential approach for lightpath setup [67]

    Full size image

    Delay Approach In this approach, on the arrival of packet at the ingress OF-R1 node, matching is done, if does not found flow entry in the flow table of OF-R1, OF-R1 encapsulate and forwarded the packet to the NOX controller. NOX calculates the routing path between the source and the destination using PCE and accordingly assigns wavelength in the optical network. In delay approach after this, NOX adds flow entries in the flow table of the OF-PXC1 and OF-PXC2. Firstly, it establishes the light path in the optical network and after this, NOX deliberately adds a delay of few nano/milli second and then enters the flow entries in the ingress OF-R1 router. As the control of ingress node (OF-R1) is delayed due to this, this approach is called as delay approach as shown in the Fig. 12.

    Fig. 12
    figure 12

    Delayed approach for lightpath setup [67]

    Full size image

    Active Approach This approach is used when the amount of the data to be transferred is known well in advance, therefore the connection holding time can be predicted in the optical domain. NOX controller adds “hard timeout” field in the flow entry of the OpenFlow switch. This indicates the connection holding time. When the “hard time” is expired, flow entry in the OpenFlow switch is automatically deleted and cross-connection of the PXC is released and therefore, no further transmission of packets takes place.

    Passive Approach In this approach, at the completion of packet transmission, the client sends packet to the ingress router/switch i.e., OF-R1 which consists of source and destination TCP/UDP port indicating the completion of flow transmission. After that the OF-R1 forwards this packet to the NOX controller as a first packet of new flow. NOX after analyzing, the destination TCP or UDP of these packets and predicts that it is not a first packet of new flow, but these packets indicate the transmission flow completion, therefore accordingly NOX controller deletes the flow entries from the flow table of OF-R1, OF-PXC1 and OF-PXC2. In response to this, OpenFlow switch sends TL-1 command to PXC for release of cross-connection.

    Liu et al. [67] proposed an architecture, which consists of four PXC, connected in mesh topology, two IP router/switch i.e., ingress and egress nodes and two clients i.e., sender and receiver. Four different wavelengths are assigned to the optical link. Authors quantitatively analyses the network performance by considering various parameters, such as dynamic allocation of bandwidth by using RWA algorithm and light path setup and release latency in optical network. They observed that delay approach has an advantage as compared to sequential approach, as delay approach provides guaranteed successful end-to-end packet transmission without loss of any packet as light path in optical domain is well established before the arrival of the new flow packet at the ingress node. In passive approach lightpath released latency increases, as optical network complexity increases as compared to the active approach. With the help of OpenFlow protocol centralized controller has to inform more OpenFlow switches for the release of the cross-connection which increases signal processing latency.

  2. 2.

    Future internet is visualized to have characteristics that can have the potential to deliver packets globally using high performance network application like cloud computing, Big Data, Fog Computing, UHD video on demand etc., and bandwidth allocation depends on the traffic generation by these applications. When aggregated to transport over backbone/core network high-capacity Wave Division Multiplexing (WDM) circuit switching network is the only alternative.

    Siamak Azodolmolky et al. proposed an architecture that consists of unified control plane platform to integrate the electronic packets and optical networks for access, metro and core network segments. For this, it uses the services of OpenFlow protocols and GMPLS control plane to control and manage the software defined packets over the packet switching and circuit switching optical network as shown in Fig. 13. In this, authors consider the use-case of on demand UHD video content access and the corresponding timing diagram illustrates the various events that occur in a sequential way as shown in the Fig. 14. Client sends request for UHD video access to ingress OpenFlow switch, while the ingress OpenFlow switch treats it as first packet of a new flow. Ingress switch encapsulates and forwards packet to the extended OpenFlow controller. Controller processes this packet and identifies the endpoints or resolves the destination address and generates a request via OpenFlow gateway (OFGW) to GMPLS control plane using user network interface (UNI) for a new optical light path setup between the client and the server. After establishing a light path, GMPLS control plane acknowledges the extended OpenFlow controller. After this, controller updates their flow table of the ingress and egress OpenFlow switches and request is forwarded to the video server. In response to this server acknowledges to the client by providing the access to the UHD video contents.

    Fig. 13
    figure 13

    Integrated architecture of OpenFlow-GMPLS control plane [97]

    Full size image
    Fig. 14
    figure 14

    Timing diagram illustrating the various events occurs for the light path setup [97]

    Full size image

    Experimental Setup and Results Experimental network setup comprises two packet switches network and one circuit switching optical network. The flow of packets is controlled and managed by using OpenFlow protocols and GMPLS control plane services that is OpenFlow is used to separate the data path of the generic switching elements e.g. routers, switches, and APs from the control plane, whereas GMPLS control plane is used as a control for core optical network. In their work they consider parameter that is number of hops per optical flow versus average end-to-end flow setup time (s) to evaluate the performance of the unified control plane network and concludes that as number of hops per optical flow increases the average end-to-end flow setup time also increases [97].

  3. 3.

    With the advancement of time optical technologies are being deployed to scale and flexible services, which are cloud, based and are encompassing network to new boundaries in SDN. The two key technologies such as SDN and flexible grid optical transport technology play a major role for the network operators to customaries their infrastructure which reduces the extra capital and operation cost while hosting new application. Channegowda et al. developed a unified control plane architecture approach as shown in Fig. 15, for multi-domain and multi-transport network based on SDN framework with OpenFlow. OpenFlow protocols are extended with a view to support fixed and flexible grids optical DWDM network along with multi-domain operation. With the help of OpenFlow protocol and GMPLS control plane and the networking devices, capabilities and constraints are abstracted and provided to the OpenFlow controller. By using this abstracted information, controller builds a technology and domain specific topology database. The information stored in the topology database is used by OpenFlow controller to facilitate the application of SDN related to PCE and virtual optical network provider (network slicer) to provide a path or network slice across varied technology and domain. Authors in their proposed architecture integrate multi-domain such as packet switches, fixed grid optical network, and flexible grid optical network and multi-transport technology, such as, electronic packets for campus/access/local and metro network and optical packets for backbone/core network for controlling and managing packet flow. In fixed grid domain, the network operators allocate fixed size optical spectrum ranging from 50 to 100 GHz for each channel spacing, whereas, in case of flexible grid optical domain, both channel spacing and channel bandwidth are variable and flexible.

    Fig. 15
    figure 15

    Architecture of multi-domain multi-technology control plane [12, 66]

    Full size image

    In their proposed work they develop a bundle of algorithm and selection of the algorithm depends on domain (i.e., fixed grid or flexi-grid) e.g. if it’s a flexible grid request, then the path is calculated using routing and spectrum assignment algorithm (RSA) and if it’s fixed-grid domain then RWA is selected. The algorithm such as hop count shortest path routing is mostly used to trace a physical path for each single virtual link in order to reduce the number of NE involvement or domain. They also propose how new bandwidth is allocated in single/multiple or fixed/flexible domain. In fixed-grid domain, the first-fit wavelength assignment is used afterwards to allocate the required channels. In flexi-grid domain, among all the available spectrum slots, the one that can have the minimum residual spectrum after the spectrum assignment for the requested bandwidth is chosen.

    They experimentally evaluate the performance of the proposed architecture, which is geographically distributed and comprises heterogeneous multi-domain, such as, flexible and fixed grid optical domain along with layer-2 packet switched domain. In their experimental setup, they use both hybrid i.e., GMPLS and OpenFlow agent and standalone OpenFlow approach, which includes OpenFlow agent on each NE. On the basis of above two approaches, they evaluate the performance by considering various parameters, such as, different path setup times, blocking rate of approaches, controller throughput performance and hardware setup time versus load. From this study they concluded that the hybrid approach is better than the standalone OpenFlow agent approach [12, 66].

  4. 4.

    In this paper, Guo et al. proposed a generic architecture as shown in Fig. 16 that supports various applications like DC, cloud computing and large-scale scientific computation, wherein, huge amount of data is transferred between end-systems, which are geographically distributed. In their work they introduce extended SDN controller, which is constructed by adding three application specific modules in it, like performance monitoring module, flow convergence module and rate control module. Control plane of the optical circuit switching network uses the services of GMPLS protocol to communicate with optical switches. Whereas, in case of packet switch network extended SDN controller uses the services of OpenFlow protocol to communicate with the OpenFlow switches. With the help of these protocols extended SDN controller abstract the network information (logical mapping of the network), so that dynamic allocation and optimized utilization of the bandwidth can be done with guaranteed transmission performance without packet loss.

    Fig. 16
    figure 16

    The architecture of extended SDN controller [98]

    Full size image

    In their experimental demonstration they evaluated the performance of the complete network by allocating different bandwidth to different services provided by the network at different flow rate. From the experimental result they observed that with their extended SDN controller bandwidth utilization is improved or bandwidth wastage reduces, total/aggregate data transfer time reduces, therefore, latency and packet losses during the transmission are also reduced [98].

  5. 5.

    Applications like cloud computing, video gaming, UHD video streaming, live concerts, remote medical surgery and other applications are offered by DCs. These DCs are geographically distributed and connected via a network. Many decisions are made in the Application space without any concern of the underlying network. On the other hand, in order to achieve the optimization of application and network resource, cross stratum optimization (CSO) is proposed, which can enable a joint optimization of application and network resources.

    Yang et al. proposed centralized control architecture i.e., enhanced software defined network (eSDN) in place of elastic Grid (eGrid) optical network with a view to have migration of DC services by implementing a strategy known as transport aware cross stratum optimization (TA-CSO). eSDN can have the ability for CSO of application and eGrid optical network stratum resources and can also have the provision of adjusting elastic physical layer parameters e.g. bandwidth and modulation format. The distributed DC networks are connected among themselves with eGrid optical networks, which install network stratum resources and application respectively. Each stratum resources are software defined with OpenFlow and controlled by application controller (AC) and transport controller (TC) respectively in a unified manner as shown in Fig. 17. The proposed architecture consists of two controllers namely TC and AC. In this TC collects the information about the network status and accordingly constructs the global view of the entire network i.e., network topology graph and makes available this abstracted resource information to AC, whereas AC is responsible for controlling and discovery of the modulation format and spectrum bandwidth.

    Fig. 17
    figure 17

    The architecture of OpenFlow-enabled SD-OTN (eSDN) comprise of AC and TC [99]

    Full size image

    When request is arrived from the DC services, AC agrees to apply TA-CSO strategy of application and network resource information that is stored in internal database and directs the results to TC through application-transport interface (ATI). TC on getting service request from AC, calculates software defined path (SDP) from source-to-destination using extended OpenFlow Protocol. The authors evaluated the performance of the proposed architecture under dense traffic load situation and compared TA-CSO algorithm with individual CSO and physical layer adjustment strategies (PLA) in relations to resource occupation rate and blocking probability. They observed that when the network is heavily loaded the blocking probability decreases effectively by using TA-CSO as compared to CSO and PLA [99].

9 Software Defined Heterogeneous Network (SDHN) Architecture

Our proposed SDHN as a FN architecture is as shown in Fig. 18a, b comprises of controller, OpenFlow switch, packet switching network, optical circuit switching network, and base station/AP which provides seamless interfacing to N number of clients. In our proposed SDHN architecture the control plane contain centralized unified SDN controller that performs various functions such as route management, network visibility, orchestrates network overlays etc. and also communicate with data plane which further consist of heterogeneous network devices like Packet switching, optical switching and wireless devices as shown in Fig. 18a, b via a south-bound interface i.e., OpenFlow protocol and OpenFlow agent/GMPLS.

Fig. 18
figure 18

a Block diagram of proposed SDHN, b the proposed architecture of the SDHN

Full size image

When data is send from source to destination i.e., from Client-1-to-Client-4, the ingress router/switch i.e.Router-1first analyses the packet header and matching is done with the entries in flow table. If the flow table entry is matched with the header of the packets, then that particular entry is considered. Finally, the routers/switches in the data plane execute the action on the packets in accordance with the entry in the flow table i.e., forward packets to the destination. In case, if the packet header does not find match with the flow table entry of ingress router/switch i.e., Router-1 to forward these packets, then it encapsulate the first flow packet in PACKET_IN message as first byte of the new flow to the controller. On receiving PACKET_IN notification from the ingress router/switch, the controller calculates the route from Client-1 to Client-4 using PCE and sends PACKET_OUT message to the OpenFlow switch which holds the inter domain flow tables entries and accordingly update flow entries are reflected into the flow tables of routers/switches on the path in the network of data plane. Simultaneously, the controller sends OFPT_FLOW_MOD messages (OpenFlow messages mapping solution) or OFPT_CFLOW_MOD message (OpenFlow extension solution) to the OpenFlow agent/GMPLS in order to allocate wavelength to the optical network. On receiving this message from the controller OpenFlow agent/GMPLS translate it into appropriate TL1 commands and send it to the ROADM switches for creation of appropriate lightpath for packet flow. Finally the packet is received by the destination i.e., Client-4 via Router-1, Router-3, Router-ROADM-1, Router-ROADM-3, Router-4 and Router-6 respectively.

If Client-2 sends request for on demand UHD video access to the server, the various events that occur in a sequential way are as shown in the Fig. 19.

Fig. 19
figure 19

Illustrate various events that are initialed when client-2 sends request for on demand UHD video access to the server

Full size image

10 Current Research and Standardization of SDN as NGN

The underlying paragraph will enlighten about SDN technology, which is advancing towards standardization and deployment as NGN:

In 2011, Deutsche Telekom, Google, Facebook, Verizon, Microsoft, and Yahoo established an ONF to endorse deployment of SDN and OpenFlow-based networks [65]. Due to release of OpenFlow-enable products and solutions from time to time by various leading vendors, both academia and industry has shown keen interest in developing software project and deploying of OpenFlow-based networks, as a well-organized ecosystem around OpenFlow [100]. With the advancement of time the each new release of OpenFlow version, its specifications are uninterruptedly growing with new features as mentioned in Fig. 8. During the progression of OpenFlow standardization several OpenFlow compliant switches and controllers came into existence [101]. The detail of the current available OpenFlow compliant switches is given in Table 6.

Table 6 Currently available OpenFlow compliant commodity and its manufactures [ 3, 33, 65, 102 ]
Full size table

Current controller implementations compliant with OpenFlow standard is given in Table 5.

10.1 Ongoing Research Efforts

In most of the studies so for carried out experiments are laid in local area network (LAN). However, with the advancement of time wide area network (WAN) could also find its place. Das et al. [123] show that WAN could be implemented by deploying OpenFlow and the same is endorsed by further studies such as [124, 125].

Similar studies have also been carried in the field of mobility and wireless networks; it seems that the distributed control plane approach is an inefficient in managing limited resources such as spectrum, handover mechanisms, load balancing amid cells etc. Whereas, SDN-based approaches/methodologies make it more efficient, flexible, simpler to implement and easy to manage wireless networks like cellular and WLAN [126–131] via dynamic spectrum allocation [132], on-demand virtual access points (VAPs) creation [126, 132], well-organized handovers techniques [126, 130, 133], allocate efficiently base station resources management per client i.e., in long term evolution (LTE)/orthogonal frequency-division multiple access (OFDMA) resources are frequency and time slots [128, 129, 131] etc. and provides a platform, which helps in deployment of novel applications easily [126, 129, 134]. SDN could enables vital functions such as virtual network management and operation, network function virtualization (NFV) etc. that helps in development and deployment of huge capacity and gigantic connectivity of complex and powerful heterogeneous 5G wireless network [135, 136]. First example, OpenRoad can be viewed as Wireless version of OpenFlow to carry research in mobile networks. OpenRoads’ architecture includes several wireless technologies such as WiMAX and WiFi [127, 137], deployment of the same in Stanford University is elucidated in [138]. For group communication on phones an infrastructure is proposed using PhoneNet as illustrated by Huang et al. [139]. The detail of the current research projects are given in Table 7.

Table 7 Current research project
Full size table

10.2 Standardization Efforts

Recently, various efforts are being made to standardize the SDN-based network via SDOs/community consortia, the detail of which is given in Table 8.

Table 8 Activities carried out by various SDOs that lead to the standardization of SDN as NGN
Full size table

11 Conclusion

With the advancement of time, manifold increase in networking traffic may be inevitable and it may not be feasible to provide efficient services with existing technology. Ever improvement in technology is a continuing process. In this survey paper, SDN as advancement over the conventional network, wherein control plane has been separated from the data plane is highlighted, which helps in increasing scalability, reliability and network performance. The journey of programmable network from its infancy to recent development spread over about last 20 years has been presented with brief description and contribution of authors. SDN architecture is also specifically discussed in all its facets of operation (technology), including OpenFlow standards/protocols in relation to interfacing NEs. As per one of the study, it has been observed that optical devices do not support OpenFlow standards/protocol, for which alternative approaches have been sought, that includes veths, OpenFlow agent, GMPLS and hybrid technique. Further, critical survey has been carried out on selective SDN architecture on the basis of services provided by the architecture, techniques used to interface the network element and various approaches used for optimum utilization of the underlying infrastructure and resources.

Our proposed SDHN as FN architecture comprises centralized unified SDN controller that performs various functions such as route management, network visibility, orchestrates network overlays etc. and also communicates with data plane, which further consist of heterogeneous network devices like Packet switching, optical switching and wireless devices. Besides, the technology involved in SDN has been duly elaborated through some of the current running projects indicating that how this technology moves towards standardization.

It may further be pointed out that Future Internet architecture will have to be based on infrastructure as a service (IaaS) commercial model that segregate the contribution of the existing internet service providers (ISPs) into twin novel roles, first related to infrastructure provider (InP), which deploys and maintains the NE and second deals with service provider (SP), which provides end-to-end service by deploying network protocols. Whereas, SDN via NV splits the roles of the SP into three key players: first, the virtual network provider (VNP) gathers virtual resources from single or multiple InPs, Second the virtual network operator (VNO) installs, manages and operates the VN as per the requirements of the SP, and third the SP that offers customized services using the VNs [178, 179]. From this, it may be concluded that SDN is one the most promising technology that permits the network administrators and service providers to customize their infrastructure dynamically based on the application requirements; so that capital expenditure and operation cost can be minimized by optimizing utilization of the underlying infrastructure and the resource. Thus, the SDN: architecture for NGN is to stay for undefined longer period, whose applications and implementations have yet to be fully exploited for use on wider scale on global basis.