Abstract
Optical networks offer a wide range of benefits to the telecommunication sector worldwide with their provision of higher bandwidth, which leads to faster data speed, longer transmission distance, and improved latency. Currently, the complexity associated with advancements in optical networks poses problems to network flexibility, reliability, and quality of service. Over the years, many reviews and proposals have been implemented by several literature studies to provide solutions for optical networks using software-defined networks and network service orchestrators. This study reviews the significant challenges in current optical network applications, the various solutions rendered by software-defined networks, and network service orchestration, impediments, and gaps in these software-defined networks. This study will go a step further to look into the various improvements and implementations of software-defined networks tailored to solve specific optical network problems. This study further proposes a flexible orchestration architecture for software-defined networks for solving flexibility and scalability problems in optical networks. This proposal uses an open network system (ONOS) SDN controller, leveraging on dockerisation and Kubernetes clusterisation and orchestration. This solution presents a more flexible, reliable, customable, and higher quality of service, which is an improvement upon current solutions in the literature.
1. Introduction
Telecommunication has made it possible to send vast amounts of data over long distances. Nowadays, the Internet has developed into a massive World Wide Web that has pervaded almost every aspect of human culture and profoundly altered our way of life. The total amount of data sent over the Internet has surpassed one zettabyte 1021 bytes in 2016 and is still rapidly increasing [1]. The low transmission loss and ultrawide spectral bandwidth have undoubtedly made optical fiber an obvious alternative for long-distance and high-speed communication. Optical networks serve as the backbone of the broadband Internet worldwide, utilising the use of optical fiber [2]. The increase in bandwidth and data hungry applications and the exponential growth of Internet traffic and its diversified services require optical networks’ capacity to expand accordingly [1]. As explained by [3], optical networking uses light to send data over fiber cables at light speed, making it suitable for long-distance low-latency middle-mile connections. In ensuring user communication quality, an optical network also considers the efficiency and flexibility of resource sharing when multiple users access the same network simultaneously. For an optical network to be efficient and provide various services to many users, network developers, operators, and users must agree upon a set of rules and regulations. Across the globe, Internet protocol traffic is expected to triple between 2017 and 2022, with the number of users subscribing to Internet protocol networks exceeding three times the global population (Cisco Visual Networking Index, 2017). It is critical to improve the automation and intelligence of communication networks in response to the rapid increase in network traffic and growing network operation complexity [4]. Various optical network architectures are developed and standardized based on application requirements. With the many desirable properties of optical networks, including a low likelihood of traffic jams and blocking, the telecommunication sectors and stakeholders have had a wide useable communication capacity for users and high reliability. In recent optical networking technologies, the evolution has added to the complexity of connectivity among many users in various places, using various services and applications, making the scale and coverage of today’s optical networks enormous. On the other hand, some switching features pose challenges for optical network control [5]. These network control problems also stem from networks handling massive amounts of data, posing numerous challenges for operators and vendors in terms of network management and control [5]. The ultimate approach for optical networks in terms of deployment, control, and management requires an advanced architecture. Since 2016, network operators and researchers in this field have shown a sharp interest in adopting software-defined network (SDN) solutions to traditional networks as a possible design principal solution to these control problems. Although SDN is a relatively new area of study, it has already spawned several comprehensive studies. The concept of exploiting the advantages provided by SDN in optical networks was first proposed in 2010, and it is now being utilised to address network infrastructure problems [6]. The authors provided a concise overview of SDN, including detailed definitions and features. Current communication networks differ from one another. SDN is characterised by some fundamentals [6, 7], i.e., the partitioning of the tasks and roles to be executed in the control plane and the data plane, (ii) centralization, and (iii) programmability. The first two architectural principles are related, and they work together to provide a wider vision of the network and network management. The theory is that by shifting away from widely distributed control, networks would be easier to handle through control and virtualisation. Control centralization has a trade-off that balances the simplicity of management with the scalability problems that come with it. The optical network field, as well as software-defined networks, has shown to offer significant innovation and benefits to the areas and sectors in which they are used. Current optical network infrastructures take advantage of SDN control’s versatility to facilitate networking applications. Although SDN can handle network control at the initial stages of a network, as the network scales and becomes more complex, SDN shifts its paradigm to an orchestration-based control, which adds up to the hierarchy of controls and increases network flexibility. SDN on its own can operate without network orchestration, but this limits users the full advantage they can derive from SDNs [8]. Network orchestration can be defined as “the automated configuration, management, and coordination of computer network systems, applications, and services” [9]. Incorporating orchestration into SDN allows for more extensive automation of network choices in the event of traffic congestion, malfunctioning devices, or security issues.
This study covers all SDN-related pathways for optical networks including network orchestration that have been researched to date. This study also seeks to offer a thorough explanation of how software-defined networking in optical networks works, the history of software-defined optical networks, the technology’s advantages and disadvantages, and how they are applied to solve problems in the various facets of its usage. We would also seek to give key considerations to problem-solving approaches in various taxonomies in both optical and software-defined networks. Readers may be able to identify new usage cases in the optical industry that are yet to be applied as a result of this. This would also allow those involved in developing a software-defined optical network project to understand what to do and make better choices while doing so. Supposing the project must be begun from scratch, the research presented in this study would provide a strong basis for making the right technological decisions. To summarise the objective of this study, this review paper will seek to address the following and answer questions regarding the following:(1)What achievement or benefits has SDN brought to optical network implementation?(2)What are some of the developed SDON algorithms or architectures in recent implementations?(3)What are the improvements and gaps in the literature regarding software-defined optical networks?
The following is the outline of the study: Section 2 provides detailed information on how the data were gathered for this research, the search criteria, the journals considered, and the number and type of literature studies that were taken into consideration in the writing of this research paper. Section 3 introduces optical networks, evolution of optical network technology, and how modern optical networks possessing reconfigurability extend and accommodate software-defined networks. This section then delves into essential and detailed information on software-defined networks, their standard architecture, properties, interfaces, protocols, application areas, benefits, and current add-ons to the standard architecture. Furthermore, the section will explain how software-defined networks integrate and merge into the optical network concept. The section concludes with a classification of several popular SDN techniques and applications. Section 4 examines and delivers to readers an in-depth discussion on previous SDON implementations. Furthermore, the primary technical considerations for any SDON implementation are outlined in this section. Network management algorithms and other relevant algorithm classification needed to integrate software-defined networks into optical networks were addressed. Section 4 goes into the issues that current software-defined optical network deployments have run into so far, as well as the questions that optical network stakeholders, manufacturers, markets, and researchers should keep in mind when introducing software-defined optical network solutions. Section 5 delves further into the current problems that have bedevilled and challenged other SDON applications, including flexibility and adaptability, throughput, and latency, security and privacy, and most importantly scalability, as well as several proposals for providing solutions to them in various literature studies. Section 6 provides recommendations for future work and certain future directions and advice to keep in mind when implementing SDON solutions. Section 7of this study summarises all our contributions. In Section 8, we present our findings and make conclusions.
2. Methodology
This study employs a systematic search approach that includes the leading electronic databases well known and acknowledged in research and academia, primary journal searches, and reference and lookup list searches. This study examines a variety of application situations in which the use of software-defined networks for applications in optical networks has been suggested and even implemented. The systematic review was planned, organized, conducted, and reported according to the process in Preferred Reporting Items for Systematic Reviews and Meta-Analyses (PRISMA) guideline work [10]. For the scoping analysis procedure, the PRISMA flow diagram is used, as shown in Figure 1. This study includes an analysis of optical networks in software-defined networks after identifying appropriate literary works.
2.1. Data Sources
Between March and May of 2021, a systematic search plan was implemented. Main electronic archive scans, core article searches, and hand searches of reference lists from previous systematic studies and meta-analyses were also part of the search plan. The electronic files were scanned using a combination of main words and optical technology topic headings. Starting with the framing of the study questions, the approach used in the article selection process begins. The compilation and search procedure are supported by framing the search string. The papers that have been written and published in English are taken into consideration. In ensuring the survey’s completeness, the search process ends by categorising the software-identified optical networks thoroughly. Most of the publications were discarded because their titles did not meet the requirements or because abstracts were not included in this study. After scanning through the various databases as mentioned earlier, the search yielded 112.000.00 results. The remaining findings were found in the four chosen electronic databases, while Google Scholar yielded 15,900 results. We only looked at the first 122 true and suitable findings for our evaluation and interpretation since the search returned some irrelevant results.
2.1.1. List of Strings and Keywords
The keywords mentioned in this study directed our search through these databases. From these keywords, search strings were developed. The following keyword in Table 1 was used as a search term.
The total records obtained after the combined database searches yielded 120,000,000 records and 1,800,000 records from other sources. Following the removal of duplicates, a scan was performed on 1200 records considering the titles of the papers and their abstracts. Of the shortlisted journals for consideration, one hundred and ninety-one (191) papers were found to be eligible for systematic review after the full-text screening. The entire procedure and search results are summarised in the PRISMA flowchart in Figure 1. The paper looks at the most interesting development areas currently being researched by academics, as well as several application areas that are yet to be explored in depth by other surveys. Some papers were grouped and evaluated together.
2.2. Inclusive and Exclusive Selection Methods
No external filters were used to restrict research participants based on publication, the scope of paper, or type of paper; all related experiments were included. The time limit for Google Scholar was specified to be not earlier than 2016. Table 2 lists the qualifying criteria for research to be included for inclusion in the analytically ordered review. Duplicates were excluded from the search results using the Mendeley Citation Manager, and the rest of the citations also examined the title of the paper and its abstracts as to the requirements. Where abstracts were unavailable or explanatory, full-text reviews were used to decide the studies’ eligibility. Furthermore, all searches that were validated at the preliminary title-abstract scanning stage were thoroughly investigated.
2.2.1. Obtaining and Selecting Relevant Information
A five-year temporal criterion was used to pick the literature that we considered in our search. The studies that were considered ranged from 2016 to 2021. “Since 2016” filtering feature on “Google Scholar search engine,” for example, was employed. Only studies that were available at the time this research was performed were considered in 2021. The five-year criterion was chosen to ensure that researchers have accessibility to the most current and significant findings that are affecting future research. This review focused its attention on a list of studies and papers to be reviewed thoroughly centered on a five-year full-text read, and the articles selected for this study’s current implementation section offered a thorough understanding of the fundamental technologies that makes up optical networks and networks in general. The remainder of the study focused on the literature that offered novel SDON implementation solutions, systems, and architectures. Studies that were not associated with the given research subject in any way were not considered and thus were not included in this study. Since some of the literature studies existed as duplicates in four separate libraries, only a publication is considered. During the final screening process, which concentrated on complete text comprehension, just 82 publications were left. Since some of the knowledge provided was rather general, and others lacked full implementation or principal details, this was the case.
3. State of the Art
This section summarises vital principles and offers sufficient context information about optical network technology, concept and architecture behind software-defined networks, and how it integrates with optical networks. This section would then merge both technologies to make up software-defined optical networks. Each layer of the software-defined network architecture will be clarified and expanded on.
3.1. Modern Optical Network Technology
The pace at which the optical networks are expanding provides significant benefits for services rendered by ubiquitous applications. Services that benefit from the optical networks include Internet-related services, cloud applications, edge computing applications, fourth-generation (4G) applications, fast video-based applications, video streaming, and most importantly the current fifth-generation network (5G) implementations. Optical networks have a shared backbone for delivering a wide range of services. These networks are now increasingly capable of providing bandwidth on demand wherever and whenever it is needed [11]. One of the most relevant technologies in optical networks that has advanced exponentially in contemporary times is the wavelength division multiplexing (WDM) technology, which underpins optical network technology. In public information networks, WDM serves as a primary carrier network for traffic, including its high anti-interference capabilities, broad bandwidth, and low latency. Optical networks can be categorised as first-generation and second-generation networks, which route and switch optical network wavelengths including circuit-switched light paths [12]. To achieve greater capacity, first-generation networks replace the copper cable with optical fiber. The key elements that make this possible are optical line terminals (OLTs), optical add/drop multiplexers (OADMs), and optical cross-connects (OXCs). While optical packet switching is improving, it still faces a number of technological challenges. Increasing the bit rate and using more wavelengths on the fiber like how wavelength division multiplexing operates are complementary approaches to increasing the transmission power (TDMA). According to the ITU-T G.984.3 standard in 2020 [4], optical transmission network infrastructure is a layer 1 networking model that resides in the Open Systems Interconnection (OSI) and is divided into two tiers. In recent times, one of the vital concepts is the dense wavelength division multiplexing (DWDM), which is referenced to the layer in the optical network technology, while the remaining layer, which is the electrical part, is known as digital packaging. The electrical layer is in charge of invoking, sharing, and handling the client signals. Optical channels are created, multiplexed, and managed by the optical layer. Exchanges also occur in this layer [13]. The optical networks have the bandwidth for various infrastructure requirements and services and must allocate resources in several dimensions, the first parameter considered is connection, and another essential requirement is the wavelength, which determines the frequency of the spectrum. The remaining requirement is the slot allocated to time and the fiber core [14]. There is no fixed architectural structure for optical networks, and they take on architectures based on the type of technology adopted. This leads us to the other section, where the current technology in optical networks is being expatiated.
3.1.1. Emerging Optical Network Technology
The emerging and more advanced optical network technologies are very vital for the current state of communication industry. With the emergence of fifth-generation (5G) networks [15], it is very vital to consider the various technologies that suit this current state of the telecommunication and network industry, and a paper by Miladic-Tesic et al. [14] in a 2021 publication expounded on a few technologies in the current state of optical networks. The first technology in optical networks is the P2P (point-to-point) technology. This technology enables bidirectional propagation over a distance of not more than 21 kilometers using single or double pairs of fibers [16]. Transmission distances affect latency, which necessitates the use of additional resources such as erbium-doped fiber amplifiers or other power components to supply more power for transmission. The traffic demands of 5G cellular networks are not met in this way. PON, as opposed to point-to-point connection, uses a single signal source to connect multiple devices or point to multipoint. Because of its accessibility, it is suitable for smart cities, decreasing the amount of fiber and equipment needed. In modern times, PON is setting the pace for IoT integration since traditional copper transmissions are gradually making way for these optical network technologies, which make use of fiber transmission. A typical PON technology has an optical network unit, optical line terminal, and distribution unit. Institute of Electrical and Electronics Engineers (IEEE) in conjunction with Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T) established the criterion for PON architectures (ITU-T). Table 3 shows the ITU-T and IEEE’s standardization of some of the most recent generations of PON technologies [17]. Other emerging PON technologies are in the direction with 100-gigabit-per-second PON technology, time division multiplexing PON is one of the most used technologies in the PON family, wavelength division multiplexing PON is currently the most adapted PON technology, other PON technologies are optical code division multiplexing, optical code division multiplexing PON, orthogonal frequency division multiplexing PON, last but not the least is hybrid systems, which are high-speed TDM-PON or WDM-PON [18]. Depending on the useable wavelengths, WDM-PON is made up of dense wavelength division multiplexing (DWDM), and coarse wavelength division multiplexing (CWDM) [18] examined a variety of implementation methods for WDM-PON.
With the growing sophistication of optical networks, the conventional manual operation takes too long and can lead to local preferable over global optimization. As a result, traditional control and maintenance technologies for future optical networks will fall short of the mark in terms of low latency, scalability, and precision. More intelligence is needed to integrate into optical network monitoring, control operations, and management to reduce human interference and improve network reliability and automation to satisfy the demands of future optical networks. Figure 2 shows the transition stages of optical network technology, and intelligence in communication networks has been a hot subject in optical industry, standardization, and academics as a way to simplify network operations and increase network performance. The next section will look into another aspect of optical networks, which is reconfigurable optical networks.
3.1.2. Reconfigurable Optical Networks
A more advanced invention in optical network technology is the reconfigurable optical network. Reconfigurability is an intriguing innovation, and it offers an exciting breakthrough for optical networks. Reconfigurable optical networks allow for changes to the topology of data centers or network capacity related to the case of wide area networks. Per time this study has been put together, the paper considers the first survey and the most recent studies on the evolution of optical networks and their reconfigurability, taking notice of data center network and wide area network scenarios. A couple of surveys in these settings provide detailed descriptions of reconfigurable optical systems [19]. This study discusses an overview of reconfigurable optical networks from start to finish, highlighting how different algorithms and structures interact with optical systems. This section groups these surveys into five and runs a clustering study on published papers from five “optical and system network journals” over the past five years to see how much correlation between the two areas (WAN and data centers). Since 2015, Table 3 shows the journals and their total number of publications. A lot of publications on how next-generation networks utilise reconfigurable optical networks and use their adaptations to increase performance and productivity are also briefly expounded. Current developments focused on optical circuit switches and the quick topology changes in data centers [20]. The various sections or settings in reconfigurable optical networks can be categorised as software-defined optical network, routing and spectrum allocation systems, wavelength switching structures, functioning systems, reconfigurable metropolitan networks, and data center networks [21–23]. This study will look at the various solutions implemented for solving optical network issues. Reconfigurable networks open the way for lots of useful technologies to be implemented in optical networks, which would be expatiated in other sections of this study.
3.2. Understanding Software-Defined Networks
Reconfigurable optical networks provide a path to introduce different standard networking technologies. One of such technologies is the software-defined network technology, which is primarily used for standard networks. This section would provide essential and detailed information on SDN technology. Even though SDNs present an innovative framework for designing optical networks, their primary aim is to provide network control for standard networks by separating the control plane from the data plane, and SDN technology helps to initialize, track, alter, and control network behaviour through open interfaces and representation of lower-level functionality. Since its inception in 2011, the OpenFlow protocol [24], which is a major protocol used in software-defined networks, communicates with network plane components [25] and, irrespective of the distance, decides how packets should be sent over a network switch [26]. The roots of software-defined networking can be traced back to the year 1995, and sixteen years later, Sun Microsystems released “Java Open Networking Foundation (OFN),” which was used in 2011 to expedite SDN and OpenFlow. In 2014, “Interop” and “Tech Field Day” showcased the operations and concept of software-defined networking. SDN decouples or distances the system that decides where the operation should be sent from, i.e., the basic mechanism of an SDN controller to route traffic from the source, i.e., the control plane to the data plane, which in this case is the destination. SDN had become a pointless marketing word by 2016, according to those in the industry [27]. To appreciate SDN, the section below will throw more light on various aspects of SDN.
3.2.1. Architecture of SDN
This section would describe the architecture of an SDN and briefly introduce the layers of an SDN. An SDN architecture describes the construction, operations, and behaviour of a computer network system based on various software-based technologies and networking hardware. The SDN architecture, which has three planes, separates the control plane and data plane of the SDN in the networking stack. The various planes of an SDN architecture are elaborated below. The architecture of SDN consists of three separate planes as presented in Figure 3. Application Plane: specification parameters and desired network characteristics are influenced by the application layer of the SDN controller. These systems include an intuitive view of the network by collecting input from the controller for decision-making and task execution. The application areas of usage in this plane include security, network analytics, and management. Control Plane: the SDN controller is very vital in this plane. The controller is a conceptual body that is directed to the network equipment to obtain particular effects from the application plane. The controller collects network data from the sensors and returns the network and actual traffic information to the application plane in an abstract manner. Data Plane: this plane is in charge of forwarding all data inside the network. It consists of SDN switches that consult the controller before making any decisions that a traditional router can make independently. At the arrival of new traffic, the transfer informs the controller the measures to be taken and after the plane stores information for subsequent flow packets in the table containing the flow information.
SDNs cannot be directly matched to the OSI layer because it operates from layer 2 and layer 3 up to layer 7 of the OSI layer, but in terms of network devices that function at the transport layer of the OSI model, software-defined networking (SDN) operates as a centralized management unit [28].
Architectures of traditional networks have both control and data planes integrated, and the dynamics involved in the system depends on the configuration of physical network devices, the protocols, and the openness of software. There are countless limitations to system changes due to the network device bottlenecks for the flow of traffic. SDNs, on the other hand, have some features that distinguish them from the traditional network as it brings on board various vital properties.
3.2.2. Properties of SDN
The key that unlocks the potential of an SDN is embedded in its properties. With the controller separation for both the control and data planes of an SDN architecture, the two planes logically centralize the network intelligence to enable users to determine which programmable to move from network devices to the application server or controller. Logically centralized and disconnected controller operations enable companies in the area of network infrastructure to automate, upgrade, monitor, maintain, manage, extend, provide, and troubleshoot. This section elaborates on the various properties of an SDN.
(1) Programmable/Configurable. By dynamically automating SDN applications, SDN helps network administrators to simply deploy, administer, safeguard, and maximize network capabilities that can be programmed due to the fact that applications do not rely on software in the custody of other enterprises or companies. Since network control is independent of sending ability, the network control can be directly programmed [29], as shown in Figure 4.
The outline of network programmability of software-defined networks is shown in Figure 4, and the networking administrator will use the components from SDN OpenFlow’s data plane to schedule, change routes, and spoil traffic over links to satisfy user requirements and specifications via the SDN controller [30].(i)Centralized Control: special software SDN controls retain a global network vision, which appears as a single conceptual transfer to software and policy engines.(ii)Agile: administrators can dynamically change network-wide traffic flow to satisfy evolving needs by abstracting power from sending.(iii)Open-Source and Vendor-Neutral: SDN is vendor-neutral and built on open standards, simplifying network architecture and service by allowing SDN controllers to contain instructions rather than different protocols and equipment unique to the manufacturer.
The SDN architecture isolates the data transmitting and control planes. The network control plane is centralized in the context of logical network service. In this architecture, the SDN controller could be organized to serve as a place of control with features such as topology, routing, traffic engineering, and recovery path. Many of these features were previously provided by routers, multiplexors, and other types of equipment. SDN is a ternary architecture comprising the topmost layer, which is the application layer, a control layer with SDN control software in the middle, and the infrastructure layer (networks, nodes, links, and data networks) at the bottom. There is an additional SDN layer, which lies right in the middle of the application layer and the control layer. A control protocol such as OpenFlow protocol also lies in between the infrastructure layer and the control layer. With QoT on demand, SDN architecture can provide network virtualisation and dynamic networking functionality. In contrast to “traditional” multilayer network control, an advantage of SDN architecture is the flat representation of the control layer. A hybrid centralized/distributed SDN architecture can be implemented. In a centralized model, the SDN controller can support and update information about network topology, bandwidth and latency, connection faults, and link additions in a single database. A centralized SDN controller can provide better computation paths for all networks with wavelength and circuit constraints compared with a distributed model with isolated nodes.
3.2.3. SDN Interfaces
The interfaces in SDN are also very essential regarding functions and applications of particular interfaces. This section would provide vital information on the various SDN interfaces and their place in the SDN architecture. SDN has two interfaces, which are the northbound and southbound interface. The northbound, which is the SDN application program interface, is mostly referred to as the RESTful API of an SDN. The northbound interface is used to interact and serves as a means of communication between the SDN controller and the applications and services on the network. SDN northbound also enhances effective network orchestration and automation. The southbound interface, on the other hand, deals with the data plane and the services involved with it. This section elaborates on how SDN interfaces work and their role in SDN architecture.(i)Northbound Interface (NBI): a northbound interface links the application of the network to the SDN controller. This enables the application to communicate with the network with the required data, storage, bandwidth, or any network resource. The network then delivers based on the request from the application. The logically constructive communication between the SDN controller and a software object running in an application layer is the northbound interface (NBI), also called the “application-controller plane interface (A-CPI)” or commonly the NBI API. The NBI, which utilises REST, that is, representational state transfer (REST) [31], is an architectural program structure designed to facilitate scalability, versatility, and interoperability. REST is generally described as an architectural REST-like API in the context of SDN NBI [32], referred to as a “RESTful API” on a client server. Two software entities should follow this model. A SDN controller may be a server, and the program may be a client. As a result of this, a single SDN controller will run multiple programs rendered by SDN applications together. Moreover, the statelessness property of REST involves the client who oversees all state management, and the server responds to requests of the client. In the SDN program, the network status is collected and managed, while the controller uses the commands of the application. Furthermore, caching, to increase efficiency and scalability, the client must allow the local temporary collection of information to minimize client-server interactions. An underlying technical interface must be followed for all REST API resources. All communications sharing the same interface can, for example, use the same data structure as “JavaScript Object Notation” (JSON) and “Expanded Language Markup (XML).” The layered architecture is another aspect: the interface in a multifaceted approach should be focused only on the next immediate node, not beyond that. This will incorporate, alter, or delete additional layers without impacting the remainder of the system.(ii)Southbound Interfaces (SBIs): this section in SDN is the interface that links the SDN controller with the network aspect running on the infrastructure layer (data plane) or is widely referred to as the “southbound interface (SBI)” or “data controller plane interface (D-CPI).” While a more advanced link, including UDP or TCP, enables communication between two SDN architectures such as controller and network modules, special SBI protocols are implemented. These SBI protocols are usually not compatible with other protocols, and it restricts its use to network properties that specify SBI protocols (e.g., the NETCONF protocol can work together with an OpenFlow switch).
(1) SDN Protocols. SDN operates under standardization and protocols, and this section is also very relevant for having a comprehensive overview of SDN and how SDN architecture and interfaces cooperate with the various SDN protocols. In the southbound interface, a variety of protocols are implemented. The most accessible and used protocol is the OpenFlow protocol, which is “ONF TS‐024 (OpenFlow Switch Specifications 1.4.1)” and “ONF TS‐022 (Optical Transport Protocol Extensions Ver 1.0),” or its updated rendition standards may conform with the network components in the OpenFlow protocol. Reports can be issued for resources and customized network devices using the OpenFlow protocol. Additionally, it is used to configure OpenFlow network equipment as a complement to the OpenFlow protocol. The protocol also backs up the informing of the resource and the setting up of the components in the network. “Qx, SNMP, TL1,” etc., are examples of conventional protocols for management. The signalling protocol should be with “GB/T 21645.42010 (ASON)” and “Request for Comments (RFC) 3471.” The protocol that supports network navigation or routing must be in conformity with GB/T 216545.82012 and RFC4203. GB/T 21645.72010 and RFC4204 can be used with the automatic discovery protocol. Path computation factor protocol (PCEP) should be compliant with RFC 5440 and derivational RFC documentation from the Internet Engineering Task Force (IETF). In today’s information engineering, SDON NBI can be enforced using the SDN protocol, RESTCONF, PCEP, etc. In some cases, NBI needs to send current information to clients using the notification functionality. One of the solutions to help the notification situation of the YANG model is the RESTCONF, where its clients receive alerts by subscribing to the resource of the update message. To achieve the functions mentioned above, the NBI protocol can use the RESTCONF protocol specified in IETF [33]. Table 4 summarises the relevant protocols mostly used in SDN.
3.2.4. Application Areas and Functions of SDN
The SDN concept has been adapted, and it has been used and has been utilised in a lot of application areas. This study will present just three major application areas of SDN functions.(i)Orchestration: SDN can adapt an orchestration property and can be combined with a network function virtualisation (NFV). The combined NFV/SDN systems offer solutions and have already been tested and implemented in existing deployments in a variety of research areas from how networks operate in wide area networks (WANs), customer premises equipment (CPE), wireless environments, and even private enterprise environments. Recently, much attention has been given to forming an orchestrator with SDN-NFV integration. In 2016, a paper from [39] presented a very detailed survey in this area discussing how SDN and NFV can be combined to serve a purpose. In that same year, [40] also made an exposition of this integration. The current fifth generation (5G) also makes very good use of SDN/NFV integration. Chen et al. [41] in 2019 identified some issues in middle box and network virtualisation, virtualised customer premises equipment (vCPE), and stability. NFV/SDN technologies are attempting to address the issues of network expansion and scaling and consistency. Basic characteristics are needed in SDN/NFV implementation areas, such as NFV interface architecture and mechanisms, northbound and the southbound APIs of the software-defined network, and its components positioning in conjunction with what the network function virtualisation structure brings onboard. In this integration, there are a lot of controllers in the SDN part, which are being utilised, all of which are targeted at designs based on target environments and general goals as shown in Figures 5 and 6.(ii)Load Balancing: this technique is an intelligent congestion control method for software-defined networking. SDN techniques for shedding of loads as surveyed and systematically reviewed by [42] examined and analysed various researchers’ load balancing approaches and architectures and their algorithms and classified them according to the methodologies employed on the basis of 76 papers chosen from one of the two groups. Belgaum et al. also said that the switches in SDN have only a data plane and the control plane is isolated from the switching components in the network, which is later transported to a centralized processor, as opposed to conventional networks. The Internet’s vast technical resources are helping Industry 4.0 [43] plan, with most existing businesses pushing toward smarter and more intelligent operations. A large amount of data must be stored and sent to the cloud to achieve this. Networking services can be dynamically and effectively dispersed to access data to achieve greater customer satisfaction and reliability. To be able to serve as an effective distributed system, there is an intelligent component in a load balancer that makes decisions based on analyses. The load balancer may be a software module or a hardware unit. It is a very vital component for enhancing the scaling and reliability capabilities of an application in network settings based on SDNs. Furthermore, there is a very effective utilisation of these load balancing systems in data centers, and an example is the equal cost multipath (ECMP) load balancing application systems and application system of a valiant load balancer (VLB). For loading balancing, there are no restraints as to whether it is a software component that operates in the architecture of an SDN at the control layer for dynamism or functions as a hardware component, which most of the time has a static property.(iii)Using SDN for cloud/edge computing The inception of cloud and mobile edge computing has revolutionized human-machine interactions affecting the manner in which even business is executed. With cloud and network virtualisation, it provides a repository for data and information and computation of both on-demand computing power and usage-based prices. For more scalability in conjunction with effective cloud infrastructure, SDN has the potential to expand the IaaS content delivery model for supply, external processing, and storage of the respective network infrastructure. SDN is capable of meeting the core criteria and scalability standards required by datacenter networks.
3.2.5. Benefits of SDN in Computer Networking
SDN technology provides vast benefits to the networking world, and such benefits are briefly touched on in this section as shown in Figure 7 as follows:(i)Programmability, Agility, and Automatic Network Control: the most notable strengths and benefits of SDN are its speed, custom programmable capabilities, flexibility, its conducting policy-based networking oversight [44], and how it can be implemented to converge and integrate various networks [45].(ii)Dynamic Management, Scalability, and Easy Administration: it simplifies the process of accessing the physical hardware. Managers can also program and make decisions more quickly [46]. SDN offers remote control for switching, network provision and easy maintenance, and application development [47].(iii)Virtualisation: SDN in conjunction with a network function virtualisation (NFV) forms a network orchestrator to allow several virtual machines to operate on the same physical hardware, reducing costs and increasing resource performance. Moreover, the centralization property of SDN also enables virtualisation and physical network provisioning.(iv)Vendor-Free Setup: irrespective of the vendor, SDN offers a common environment where management and control have a single source and a particular interface where all others can be implemented.(v)Quality of Service (QoS) and Content Delivery: SDN helps with traffic management and, for example, voice over IP (VoIP) and high-quality video and how audios are sent over a channel.(vi)Reduction in Capital Expenses: improving current components assists in avoiding the purchase of proprietary switches, which would intend to reduce any additional capital expenditure.(vii)Security: it is the ability to control access policies from a single global control point [8].
3.3. Using SDN for Network Orchestration
A few literature studies refer to network orchestration as software-defined network, which can be technically justified depending on how the network is implemented or automated. However, SDN is a type of network orchestration [48]. The most fundamental type of orchestration is the policy-based automation. SDN orchestration is an essential add-on to the standard SDN infrastructure and architecture. SDN can be fully implemented without adding any form of network orchestration to it [49], and this hinders the SDN from its full capacity and functionality depending on the application area. SDN without orchestration has been used to solve several problems in the telecommunication industry. The fundamental concept underneath the implementation of network service orchestration is to separate the services rendered by a network from network components while still automatically configuring the network according to the supplied service criteria. This section will introduce SDN orchestration, expounding on the benefits of network orchestration in SDNs and how orchestration works in SDN.
3.3.1. SDN Orchestration Systems
With the introduction of SDN in monitoring, management, and control, mobile network operators and stakeholders in communication networks demand a more customized and customer service order-based, where networks can be automated and tailored to suit specific customer and business demands. The service demand solution has been found in network orchestration, which is subsequently provided by the application or service using SDN orchestration technology by either setting up virtual network layers or server-based virtualisation [50]. Network orchestration in general is referred to as policy-based or event-driven automation. Network automation and network orchestration are two different concepts. Network orchestration can be defined as a next step in network automation. While automation is having a single job run without human involvement, orchestration takes things a step further by automating the whole “processes” or “a series of connected activities.” A collection of rules or regulations established by the organization define the orchestration system. An orchestrator intelligently controls and shares resources effectively while also providing a wide range of network functions. In communication engineering, network orchestration handles a variety of network resources, such as those from data centers, cloud services, and network provider services. Network orchestration organizes various operations in a systematic manner using automated services and manages various components offered by physical infrastructures that run software modules [51]. However, the inception of network orchestration provides a solution for only static and coarse-grained services and processes. In situations where the network is dynamic and network resources correlate with specific network slices, it becomes extremely challenging.
3.3.2. Flexible Orchestration Systems
A flexible network orchestrator adds up to the control of normal network orchestration by providing a more versatile control to SDNs. A flexible network orchestrator allows for more dynamic and fine re-grained operations, which makes necessary adjustments in case a customer is roaming. Flexible network orchestration adds up to the solution provided by the conventional network orchestrators by giving access to network dynamism and fine-grained operations. A flexible network has features that accommodate network elasticity and “elastic orchestration” of “network slices.” This characteristic of flexible network orchestration improves the network efficiency and the utilisation of network resources. There are two concepts and conditions, which render a network orchestrator to be flexible, which is dynamic reorchestration and fine grain reorchestration. These concepts provide a more modular software-based architecture [52].
3.3.3. How Orchestration Works in SDN
Several SDN orchestrations have proposed different implementations and SDN architectures. This section will summarise how SDN orchestration works in general and what changes in the architecture of an SDN. In most SDN orchestration architectures, the SDN orchestrator sits on top of the SDN controller, which can be several depending on the service customization and business demand. The remaining southbound layer falls remain the same and change based on the vendor-specific description, which was either affected by the northbound architecture or by customer specifications. Several types of open-source software may be used to create orchestration platforms, which are developed using common APIs that can connect to conventional networking technologies. Big Switch, CENX, Cyan, Overture Networks, and Anuta Networks are just a few of the businesses that create and provide SDN orchestration solutions. SDN orchestration entails software coordination with an SDN controller, which is created using open-source technologies such as OpenDayLight. In the event of network congestion, security issues, or malfunctioning devices, the controller may be designed to make automated network choices [53]. Below is the diagram of an SDN architecture with SDN orchestrator on top of the architecture. A different host has different virtual machines (VMs) and open flow switches and Open vSwitch, which are labelled as OFS and OvS, respectively, as shown in Figure 8. The orchestrator provides different SDN controllers to perform specific functions.
4. Software-Defined Optical Networks
As optical networks are becoming more sophisticated in their structure and implementation, the manual operations take longer time leading to upsurge locally. These optimizations do not occur at the global. As a result, traditional control and maintenance technologies for future optical networks will fall short of the mark in terms of low latency, scalability, and precision. There is a need for improving and integrating smartness into the tracking, administration, and management of an optical network to reduce human interference and improve network reliability and automation so that the demands of future optical networks can be met and satisfied. Intelligence in this area has been a very essential and trending subject in optical research and academia fields to assist in standardizing to simplify network operations and increase network performance. Because of operation and maintenance, an optical network is more difficult than operating and maintaining other types of networks. When considered, it can be realised how optical networks and other networks (such as 5G cell networks and IP networks) are converging, and this makes it become even more extreme. In general, challenges can be categorised into three main parts, which are confronted by the operation, maintenance, and development of optical networks.(i)Network Complexity: to begin with, as the size of optical networks grows, so does the number and variety of optical network equipment. The variety of network interfaces and protocol vendors adds to the challenge of network management. In communication systems, the optical network also serves as the bearer network, carrying various shades in the recent 5G implementations, edge and cloud computing, and IoT integration. Initially, the optical networks had issues pertaining to network provisioning and management. These problems make it hard to figure out and embrace different traffic exuding from various network systems.(ii)Complex Services: various standards of quality of service (QoS) provide the delivery of separate services across optical networks. Furthermore, an essential implementation and approach that offer real-time assistance is the “network slicing,” which results in providing a modular infrastructure with a framework to provide various amounts of QoS to various service domains within a limited span of time that is unlikely with a larger network.(iii)Resource Management Complexity: the link between two layers is made easy and possible with optical networking components and concepts, which results in taking charge and overseeing allocating physical layer resources for traffic supply. However, physical infrastructure such as fiber, wavelength, and different spectrums and formats must be assigned in different dimensions. The assignment of several tools at the same time is time-consuming and computationally intensive.
4.1. Using SDN Functionalities for Optical Networks
SDN, as explained in the previous sections, is a network control and management software framework [54]. It offers multiple solutions in an interconnected manner, while conventional systems will need multiple interfaces. The following functions can be given by SDN in optical networks.(i)Allocation of resources in primary and sublinks and cloud computers(ii)Flexible and resilient network and diverse network adaptability(iii)Service availability secures network stability and resilience(iv)Cross-layer management issues such as debugging and checking
Besides the above listed, we sometimes encounter in optical networks a lack of consistency between equipment from two separate vendors. The SDN can easily deal with this. Scalability is becoming a top requirement for core and metro networks due to the heterogeneous subunits in the center. SDN can have scalability and automatic resource partitioning. The SDN-based optical network hierarchy is depicted in Figure 9. The features of the individual network planes have been demonstrated.
4.2. Optical Networks with SDN Implementation
An exciting feature in software-defined networks is the network virtualisation feature, which allows it to be applied to optical networks. The NFVs are virtualised and represented in the framework as software codes [55]. These codes collect, disseminate, monitor, perform, and handle various optical network functions. The responsibility is executed by two different planes. The control and data planes sometimes also work together in optical networks. In cases where the network has little complication, a collaborative solution is preferable.
4.2.1. Using SDN to Control Optical Infrastructure
Taking into consideration an SDN protocol (e.g., OpenFlow protocol) to monitor optical transceivers and utilise digital signal processing techniques for recent generations of optical transceivers, this allows software monitoring of certain transceiver parameters. The authors in [56] developed a testbed that allows SDN to monitor superchannel optical transponders and optical amplifiers. The authors in [57] also developed a proving ground, which allows SDN to monitor the amplification of the optical link and the signal transponders. To monitor these machines, an OpenFlow extension is proposed. OpenFlow will monitor and make the approach used for modulating each carrier subset in the main medium for transcendence. This also carters for amplification and power balancing and allows the control plane’s controller to adjust the amplifiers for channel deficiencies. Testbed shows how the power in SDNs has been utilised by a transponder and an optical amplifier in an erbium-doped fiber amplifier. On the other hand, [58] suggested an implementation with new transponder-specific fields in flow table entries. They also suggest that optical transponder failure warnings be captured and hand it over to the controller in the SDN using the “packet of messages” property of the OpenFlow protocol.
4.2.2. Using SDN Protocol to Monitor Optical Circuit Switches
One of the most essential concepts of SDN as mentioned in the previous sections is SDN protocol. Considering the most used SDN protocol (OpenFlow) can allow circuit switching by topping up the database of the flow table, and it is elaborated in the appendix in paper [59]. The circuit switches’ entries in the table are programmed using OpenFlow messages. The following fields are used to describe the cross-connect inputs: “input port, input wavelength, input time slot, and virtual concatenation group,” and the following fields are used to identify the output, “virtual concatenation group, output port, output wavelength, and output time slot.” The OpenFlow circuit switching addendum is extended in [60] to enable the adaptive and gridlessness and flexible property of the optical link. The University of Bristol did a test on how DWDM works on wavelength grids, which can scale, and this operates on OpenFlow setup with SDN controller in optical networks [61]. A similar application too was developed by South Korea Telecom.
4.2.3. Using SDN Protocol to Monitor Optical Packet and Burst Switches
The packet switch in conjunction with the burst switch allows data exchange between the forwarding table in optical packet switches and some computations from the control plane of the SDN mostly by the controller. The process is mostly referred to as offloading, and it makes extremely complex optical packet switches easier to design [62]. An extension to the OpenFlow protocol that allows it to operate with components that accelerate the switching of packets in an optical network is created. Generally, an SDN controller would be a more effective means of addressing the conflict that would otherwise result in packet loss in optical packet switches, compensating for either the lack of any optical buffering or partial optical buffering. Engineers from “Japan’s National Institute of Information and Communications Technology” [63] with an SDN power over packet component part have built an optical circuit and packet switched demo project.
4.2.4. Retro-Fitting Devices to Support SDN Protocols
Capitalising on an optical switching component, which is not SDN-based, can be turned into OpenFlow controllable switching devices using an abstraction layer [64]. The abstraction layer, as shown in Figure 7, serves as a translation layer between the two. An SDN protocol (e.g., OpenFlow protocol in this situation) setup message and the native control interface of optical switching systems. The abstraction layer is completed by a virtual SDN protocol (OpenFlow protocol in this instance) [63]. Outflow access is a connection between two virtual ports that is created by inserting a flow entry between them. The abstraction layer in the virtual SDN protocol (specifically OpenFlow protocol) switch adds the flow input amidst the double ports. A two-port SDN protocol (i.e., OpenFlow protocol) transfer and a hardware abstraction layer that transforms OpenFlow forwarding rules to monitor messages understood by the non-SDN-OLT can be added to a non-SDN PON-OLT. This OLT retrofit for SDN control via OpenFlow is shown in Figure 8.
4.2.5. Using SDN to Control Network Operations
Firstly, this section will be taken into consideration the commonly used SDN protocol (OpenFlow) considering OpenFlow management of passive optical networks. A passive optical network that is controlled with SDN could be constructed by enhancing the optical line terminator into “SDN-OLT,” which could be operated via a southbound interface, such as the OpenFlow [64]. One or more SDN-OLTs are managed by a centralized PON controller, which may be in a data center. OpenFlowPLUS is explicitly defined to broaden up the OpenFlow southbound interface for Gigabit PON. Via a programmable flow table, OpenFlowPLUS expands the flexibility and control of SDN to be used for the optical network units and its correspondent optical line terminator components allowing them to serve as OpenFlow switches. OpenFlowPLUS does not cover nonswitching features such as ONU registration or dynamic bandwidth allocation. OpenFlowPLUS adds directions for PON-based information to follow concerning data entries in the flow table and channel OpenFlow communications via the program-based interface for the optical network unit of the Gigabit PON for the administration of the interface. The division of bandwidth is done by the carriers that contribute to the spectrum of the optical line, with these carriers being part of the orthogonal frequency division multiple access. Defragmentation of this spectrum under DN control with elastic optical networking contrasts with the already allocated wavelength frequency space under “ITU-T G.694.1” standard utilising the optical spectrum. This versatility will help to improve the spectral performance by preventing the overall preallocated wavelength channel from being exhausted at the time it is not required and avoiding unwanted guard bands in some cases. However, when variable grid light paths are formed and terminated over time, this complexity fragments the optical spectrum. Spectrum fragmentation occurs where there is adequate spectral bandwidth to meet a requirement, but it is distributed in several sections rather than integrating it inside the neighboring spectrum, as necessary. An SDN controller will have a wide network viewpoint, allowing for more efficient periodic optical spectrum defragmentation. Optical spectrum defragmentation operation will minimize light path blocking odds by up to 75% in general. Multicore fibers have more spectral energy by allowing for more transmission. Furthermore, in regard to metro and access: the large viewpoint is that SDN can have to control tandem networks. To increase the bandwidth distribution, SDN controllers have two cooperating stages: (i) an entry phase that manages and administers the OLT-based SDN separated from the influence of each other, alongside considering the second (ii) phase in management where the entire SDN has been managed and controlled. Simulation studies show that national coordination increases network bandwidth usage by 40% as opposed to the operational allotment of bandwidth for various wireless and access networks based on passive optical networks.
4.3. Application of SDN Concept for Optical Networks
Applying SDN-based solutions for optical networks is a very innovative approach in this field, which offers a platform for further research [65]. In the sense of logical network operation, the network control plane is centralized. The “SDN controller” as part of this architecture is structured like a control center, with features such as topology exploration, routing, traffic engineering, and recovery routes. Many of these capabilities were formerly provided by routers, multiplexors, and other types of equipment. As already expatiated in the previous sections, SDN architecture is made up of three layers, that is, the device layer at the top, the management layer with SDN control tools in the middle, and the infrastructure layer (network nodes, connections, and communication networks) at the bottom. With the quality of transmission (QOT) on call, SDN architecture can have network virtualisation and dynamic networking capabilities proposing general SDON as shown in Figure 10. The authors in [66] proposed an innovative alternative to Wang et al. because its architecture is more novel and detailed than Zhao et al. [65]. The SDN access is centralized and manages more than most existing networks remotely. This would revolutionize the sector of networking, allowing the integration of SDNs with optical networking to be flexible and adaptable to the daunting nodes of today.
4.3.1. Early Adoption of SDNs in Optical Networks
This section introduces SDN solutions for optical networks and their current state in the optical network paradigm. An optical network is merged with the SDN of each other for the benefits of one to compensate for the disadvantage of the other. The flexibility and programmability of SDNs then compensate and add up to the high transmission speed of optical networks. The SDON architecture is supposed to provide an easily adaptable, flexible, and cost-effective system network, which will help SDON to have an optimum performance. A general SDON architecture in recent times with ONOS controller and NETCONF protocol, which does automatic creation of agents, is shown in Figure 10.
In early SDN architectures for optical networks, the control plane has just one single and centralized controller, that is, the SDN controller that controls, monitors, administers, and serves as the intelligent component for the entire. The proposed SDN architecture for optical networks by [56] consists of two clients, namely client A and client B, interacting with each other via OpenFlow switches managed and administered by an SDN controller. The OpenFlow switches perform forwarding of network packets. The architecture section that handles the optical part is implemented in the ROADM components. Coarse optical add and drop multiplexors (COADMs) are also used in this architecture to substitute for the ROADMs in case of few wavelength add/drop scenarios. An opto-electro-convertor (o-e-c) is done when an optical switch exchanges information with a ROADM. Generally, in standard SDONs, both electrical and optical signal packets are handled by the SDN. With standard SDONs, the interface for packet switches does not need one of the optical switches to translate electrical messages from the SDN controller to optical signals in the other to control the optical switches (ROADM). Since an interface for packet switches is not needed in this architecture, in optical switches an OpenFlow agent is used. This agent and controller can then be programmed with programming tools such as MATLAB with the OpenFlow protocol. Figure 11 demonstrates the operation of this type of SDN implementation for optical networks, and the table shows the pros and cons of this kind of architecture and the need for the optical and SDN stakeholders to bring up new concepts and ideas. Table 5 summarises the advantages and disadvantages of the standard SDN architecture as already expatiated.
4.3.2. Virtual Optical Network-Based SDN Architecture
One of the early SDN architectures for optical networks was virtual optical network-based SDN architecture. In this type of SDN architecture for optical networks, the control plane is virtualised and mostly grouped into virtual slices such as a master controller and local controller. The main advantage of VON-SDN-based architecture is the distributive property it offers to elastic optical network (EON) in data center networks. This gives a wide range of control and automation since the entire architecture does not solely rely on the SDN controller. This also gives room for other SDN protocols to be utilised. In VON-SDN-based architectures, an SDON architecture is integrated with data centers (DCs) and considers the SDON working with geographically distributed data centers where the “DC networks” [66] (DCNs) comprise different domains and network technologies like OTN for each of the domains in the network. SDN controllers mostly work in conjunction with SDN protocols, which are executed. Moreover, the control of the VNF interface and the common SDN protocol, which is the OpenFlow protocol, is made available and utilised in these types of architectures. In other cases, [67] considered PCEP and SNMP to be prospects in the future. A master controller, as shown in Figure 11, is also referred as a father controller and does the orchestration alongside the individual local domain controllers for managing the network resource. Optical network stakeholders and service providers have been paying sharp attention to virtual optical network (VON). VON promises to deliver several dedicated virtual networks in place of infrastructures that are shared in the networking domain. Each application can be tailored to demand for customers. In VON, the network can be partitioned or integrated into virtual resources that are not dependent on each other but can perform the same functions just as a physical resource would perform. In optical network deployment, one of the most essential agents is the data centers. What VON does is, because putting up a dedicated service for data centers is not feasible due to the wide distribution of network resources across the board, it prevents network “ossification” for network resource subordinate to a central service provider. VON solutions can provide access for operators to manage several other VONs on a single infrastructure. Currently, designing a VON and its resource manager is very challenging as indicated in Table 6. For a VON design to be successful, much attention should be given to traffic demand models and topological data from physical networks [66] (see Figure12).
The control plane in bandwidth on demand virtual optical network is structured in a hierarchical order with the master controller, which is the “father controller” and the individual controllers for managing network resources. Considering the scenario in the paper [68], it expounded on the evolvement of SDON from just switching techniques to a detailed, more intelligent, and overview of SDON automation. Virtual optical networks consider a flexible sliceable transponder and programmable switches without explicitly specifying the number of transponders or interface cards to be used. VON-SDN uses wavelength selective switch (WSS) components, multidimensional bandwidth variable wavelength selective switch (BV-WSS), splitters, and optical cross-connect components as demonstrated in Figure 13.
4.3.3. Challenges in the Reviewed Early SDN Architectures for Optical Networks
The proposed SDN architecture in early implementation has lots of downsides to its implementation. With the standard SDN architecture for optical networks, it offers a level of security, reliability, and quality of service from the time of its inception. Moreover, bandwidth demand, service provisioning requirement, and network complexity have increased greatly. This exposes some performance flaws in architectures where the centralized control relies solely on the SDN controller. Most researchers test their architecture with a few client components [69], and when bandwidth, demand, request pressure, and decisions are mounted on the SDN controller, its computational power will reduce drastically affecting the intelligence of the system. Another problem with standard SDON is the inconsistencies it has on EON and routing and wavelength allocation. An example of such SDON architecture is that of the authors in [70], as shown in Figure 14. SDON without virtualisation will not employ the flexible grid and other functionalities requested by current ROADM components. Although VON offers solutions to standard SDON as stated in 4.1.2., VON offers an easy way to gain network dedication [71], but resource utilisation is reduced because dedicated bandwidth capacities are mostly given to physical connections within the VON domain [72]. On the other hand, the remaining bandwidth is shared by the rest of the VON connection [70]. Another downside of recent VON is the issue of burden on providers [73] and controllers to provide different policies for individual resources (“shared resources and dedicated resources”). Notwithstanding, the implementation becomes very tough and cumbersome [73]. The proposed architecture will focus on the northbound API of a standard SDON, consider implementing a more flexible orchestrator, build upon the fundamentals of standard SDON and VON, make some eradications from the reviewed SDON architecture, and add some functionality to it. Recent 5G networks have introduced the concept of network virtualisation and orchestration [74].
4.3.4. Using SDN Orchestration for SDONs
SDN orchestration adds a new component on top of the SDN controller, which then enables the creation of several SDN controller instances to perform different tasks [6]. Adding an SDN controller does not directly affect the southbound interface. Based on different policies and standardizations, the data plane of an SDN can still retain its functionality using reconfigurable optical add and drop multiplexors. With the solution SDN orchestration brings to SDON, recent and various use cases are still in development [75] like how there is interconnection between several geographically separated data centers, which provides dynamic end-to-end service provisioning across numerous and heterogeneous optical network domains. This heterogeneity is not only generated by numerous data transmission and switching methods [76], but also from the many control plane approaches available. Given the scalability and confidentiality restrictions, the problem of heterogeneous control plane interworking must be well dealt with, and the resolved issues must satisfy the unique difficulties of multidomain networks, such as restricted domain topology visibility. OpenFlow-controlled DC connectivity [77] through optical transport networks highlights the necessity for multidomain service and connection provisioning, as well as heterogeneous control plane interworking, demanding overarching, and orchestration control. The adaptation models are restricted, in terms of either scalability or flexibility, and they can be utilised in a number of ways. A single SDN controller model, multiple SDN controllers in a mesh, and multiple SDN controllers in a hierarchical context are described for the DC interconnection network [78] with multiple SDN/OpenFlow domains [79] or multiple generalized multi-protocol label switching (GMPLS) heterogeneous domains [80]. SDN orchestration still has a lot of gaps and hindrances due to vendor incompatibility, self-provisioned requirements, and different orchestration tool implementations. Since SDN orchestration is originally used for conventional networks, a few literature studies have implemented SDN orchestration in optical networks [5, 81]. Most of these orchestrations are custom made by different vendors and companies who are bounded by specific requirements and use predefined orchestration tools. In the SDN orchestration for optical network implementation made by individuals and independent bodies, they all focus on standard ROADMs, which are limited in optical network flexibility. The next chapter of this study will summarise and reveal the gaps in the current literature pertaining to the implementation of SDN orchestrators for optical networks.
4.4. State of the Art of SDON Implementations
SDON is pushing the boundaries of optical network intelligence. It denotes the transition of an optical network’s control panel from switching intelligence to a completely automated one that takes into account service diversity and management automation. Currently, SDON has advanced in important technologies such as service assignment techniques, heterogeneous networks, and programmable optical transmit devices to adapt to this transformation. For SDON in advance, current reviews reveal a new concept to reduce optical network inflexibility and multivendor incompatibility, which has been a major problem in earlier SDON implementations. This concept is the disaggregation of SDN in optical networks. This section elaborates on the new concept of disaggregation, the variety of disaggregation, and other vital technologies and concepts used in current SDON implementations.
4.4.1. Concept of Disaggregation for SDN in Optical Networks
In the modelling of next-generation networks, especially at the metropolitan level, disaggregation is a very vital concept and one of the key driving forces. The future of optical networks is embedded in the creativity that can be done with SDN-controlled packet optical network, which leads to significantly increased efficiency, reliability, flexibility, and performance of the network. In this section, various types of disaggregation are discussed, as well as the state of the art and unresolved concerns in this field, with a particular emphasis on the future opportunities for disaggregation beyond current optical networks. Disaggregation in optical networks is intended to maximize the use of optical transport while providing flexibility and freeing network operators from vendor lock-in. From this review, traditional SDON architectures had problems with different SDN vendors operating together, and this led to the concept of disaggregation. Disaggregation may be used vertically that is the most typical SDN strategy to decouple the control and data planes, or horizontally to decompose the optical data plane into its constituent components. The first step in enabling a vertically disaggregated optical network is standardizing well-defined interfaces between the data plane and the network controller, obviating the need for proprietary network management tools. For this purpose, work on disaggregated device YANG models is still underway and several projects are currently working on these YANG models. Examples of ongoing projects are “OpenROADM, OpenConfig, and Telecom Infra Project.” All these projects use the YANG models in the administration of SDN for optical network uniformity. One of the key benefits these models are bringing to mobile operators and service providers is to quickly expand their capabilities by inculcating custom applications into SDN controllers. Operators can upgrade transponders on their own, extending the life of the transponder. Alternatively, the data can also be broken down into transponders and reconfigurable optical add-drop multiplexers (ROADMs), with each ROADM being separated into degrees or even more elementary. There have been several open-source control initiatives by the conventional SDN community in recent years (e.g., OpenDayLight). ONOS disaggregation is preferred over fragmentation because it promotes homogeneity, as this section explains in detail. The present condition of the two primary optical disaggregation types is summarised on this Web page. The remaining part of this section elaborates on the two disaggregation varieties, which are full disaggregation and partial disaggregation. Full disaggregation is far more appealing than partial disaggregation, which is actively supporting standardization projects.
4.4.2. Partial Disaggregation of SDNs in Optical Networks
This section expatiates on partial disaggregation and introduces new and vital protocols for the concept of disaggregation. This section precedes to discuss open models for partial disaggregation in optical networks. Lastly, the section will cover QOT estimation for ONOS with an important estimation tool called GNPy, which would be expounded on later in the section. Conventional optical network designs were created with traditional services in mind, such as predictable traffic patterns. However, in recent times, a service-oriented optical infrastructure is urgently needed, which leads to solving the optical network by detaching the network software from the network hardware by partly disaggregating the optical layer. This method of disaggregation then provides network architects the flexibility they need to introduce new service types, quicker boost capacity on the fly, and delegate maintenance to discrete parts of the network while keeping operations centralized. In partial disaggregation, the optical transport infrastructure has a single vendor that is maintained while vendor-neutral NETCONF/YANG-based management is used for transponders [82].
4.4.3. Enabling Technology for Current SDONs
In this section, discussion on efforts to develop a framework for emulating SDON agents and disaggregated optical network agents is made. Furthermore, this section summarises the most significant features and APIs for interacting with optical equipment in real-world applications and the interaction between the NETCONF protocol and its YANG modules. NETCONF makes use of XML data serialization using an RPC protocol defined by the Internet Engineering Task Force (IETF). The use of XML in NETCONF sessions enables device-specific information to be obtained that conforms to formal standards such as YANG modules [83]. The XML format organizes the data on each device into a tree structure. SDN controllers frequently provide a driver library that enables clients to communicate with network agents through this protocol. Netopeer2 servers support server-side NETCONF API [84], which includes the user YANG model and the development of an engine that permits connectivity to other systems and an operational database that holds configuration information. Another component, which is libyang [81], is used to build and verify the YANG data in the database. The suggested system includes an SDN controller, specifically ONOS, software agents that imitate Cassini transponder interactions, and an API gateway.
4.4.4. Open Models for Partially Disaggregated in SDON
As a result of the present constraints of optical device and system models, it is difficult to implement northbound interface optical planning tools since these models do not reveal all of their parameters to the SDN controller through southbound interface and to applications that use NBI [85]. Currently, only system manufacturers’ proprietary tools, or network management systems (NMS), which regulate vendors, may be used to plan based on in-depth analysis of the optical/physical layer. There are a number of optical layer characteristics that must be sent to NBI applications to enable the use cases of impairment-aware routing and spectrum assignment, as well as the designing of optical lines. In examining the completeness of the OpenConfig [86], OpenROADM [87], and OpenDevice [88] models for delivering information to the SDN controller, Net2Plan-based NBI application communicates with an SDN controller specifically an ONOS controller [89] that provides access to two muxponders through OpenConfig-based NETCONF SBI on a testbed at Telefonica premises. This implementation was done by a recent review did it as part of this paper’s proof of concept (PoC). This proof of concept focuses on a point-to-point transmission connection with no intermediary ROADM nodes as the initial part of a research program as shown in Figure 15. For SDN applications, to produce accurate QoT calculations based on the architecture in Figure 15, [89] compiled a list of the minimal network model information needed and emphasised a QoT engine that can calculate per-channel optical signal-to-noise ratio (OSNR), chromatic dispersion (CD), and polarization mode dispersion (PMD) at the input and output of each network element. While the accuracy of the estimates increases with the amount of information in the model, this also increases its complexity and makes it difficult to keep track of various optical factors with any degree of certainty. From reviews, it was realised that one of the most important aspects of OSNR is its linear contribution, which comes from optical amplifiers; the other is its nonlinear contribution, which comes from high optical power in fibers. When the optical channel launch power is optimized, the OSNR decline induced by nonlinearity is comparably minor. A typical example is 1.8 dB but may arbitrarily expand when optical channels are overpowered. GNPY, an open-source framework proposed by the Telecom Infrastructure Project [90], uses the Gaussian noise model to estimate OSNR.
Recently, validation findings from large-scale testbeds have been presented [91]. In this work, we augment Net2Plan with GNPY-inspired [92] computing for assessing the impact of nonlinear impairments on OSNR. Table 7 summarises the minimal information required for the two kinds of NBI optical planning tools. The operational data depend on the channel injection power and the present configuration of the device. Inventory data are static and are derived from WDM’s plant and equipment catalogues, which are required to conduct the study. Notably, the nonlinear contribution to OSNR greatly extends the model’s needs. Some of these may be difficult to get in dark fiber production networks, where carrier information such as the fiber’s nonlinear coefficient may be missing. Incorporating some inventory data into the YANG model of the equipment might ease the network operation. For example, if the amplifier’s noise figure information is incorporated in the model, NBI applications will have it immediately accessible, rather than having to search through a collection of amplifier datasheets [93]. We constructed a custom NBI in this effort with the goal of allowing QoT parameters from the SBI as mentioned in Table 7.
4.4.5. Full Disaggregation in Optical Networks
The second disaggregation type, which is full disaggregation, breaks down the OLS, allowing ROADMs to be handled in a vendor-neutral manner. OpenROADM is explained in the previous section, headed by AT&T, which is the most significant standardization endeavor for complete deidentification and decomposition. It is a full multisource agreement (MSA) that covers both data and control. DWDM optical line interface standards for the transponder’s add/drop port to the ROADM device are defined by single-wave (W) interfaces. Digital coherent optic CFP-DCO, CFP2-ACO, or CFP2-DCO connections [96] must be used for line-side pluggable types. OpenROADM provides models for describing the device, network, and the service level on the control side. As an example, the YANG model has a tree structure that contains nodes for devices such as transponders, ROADMs, and amplifiers, all topological information related to external connections with other ROADMs. There are node identification numbers, shelves, circuit packs, interfaces, two lists for internal and external linkages, and a list of degrees in the YANG model’s tree structure. The tree structure also contains node identification numbers. Shelf name, shelf type, rack, administrative state, vendor, model, serial id, hardware version, operational status, and a list of slots are provided for each shelf. Circuit packs [97] also comprise a list of ports with various descriptors (such as port name, port direction, label, circuit id, administrative status, operational status, and partner port data used to include bidirectional connection details). This section lists all possible virtual interfaces, between optical transport systems, optical management systems, and their associated general information and the physical/virtual ports supporting them. Detailed information about ROADMs’ external connections is available through the external link list.
4.4.6. Comparing Partial Disaggregation to Full Disaggregation
Partial disaggregation intrigues both operators and manufacturers since it ignores most of the optical data plane’s complexity without compromising the transmission performance. Despite partial disaggregation being provided as a pair, the transponders in this type of disaggregation can be configured to operate on proprietary transmission systems. The primary transponder control standard is OpenConfig. The economic model supporting partial disaggregation considers OLS a mature technology that can be applied and maintained for over 10 years. A disaggregated OLS may be difficult to build, control, and administer, especially if the system is planned to survive a long time. Symbol rates in transmission techniques have skyrocketed in recent years. Some networks may need to update transponders every three years to keep up with the data volume. Due to partial disaggregation, new transponder installations are no longer tied to a single provider, albeit the OLS remains the same [97]. Initially, only two suppliers are participating in each metro network, one supplying the OLS and the majority of transponders and the other providing the remaining transponders (e.g., 20–30 percent). From the operator’s standpoint, the first OLS provider will run the whole optical metro network. In regard to disaggregation, the ability to manage the disaggregated optical network is critical for the operators. In the long term, disaggregation is less beneficial. It is because of this that OpenROADM multivendor capabilities are now dependent on proprietary solutions [98].
4.5. Prospects of Disaggregation in Optical Networks
Open network operating system for packet white boxes with YANG model standardization has been the primary emphasis of the optical community in recent times. By making use of these initiatives, it has become possible to integrate open software across all network devices. A single manufacturer may provide distinct hardware, firmware, and software versions, yet operators employ network gear from numerous suppliers in different domains. In this case, network administration becomes a lot more difficult. Additionally, because of the lengthy process of designing, developing, testing, and deploying a conventional monolithic or proprietary program, it is sometimes difficult to add new features. The deployment of additional features on top of the abstraction base would be accelerated if the network devices had a standard, organized, and open software stack. Considering the southbound interfaces with respect to the future directions of optical network disaggregation, YANG model and the NETCONF protocol are generally accepted as the foundation for the interface between controller and network devices, known as the southbound interface (SBI). NETCONF has evolved as the preferred protocol for optical device control, despite the fact that other YANG models exist to define the devices and architecture. Disaggregated solutions may be adopted much more easily because of this. However, the protocol technology of NETCONF is not the most efficient, and other alternatives, notably at the IP level, are fast gaining agreement. A good example of this is the Google-developed open-source gNMI (gRPC network management interface) framework, which is based on the remote procedure call (RPC) framework built on top of HTTP/2 and allows for a wide range of efficient options such as unary, server streaming, client streaming bidirectional streaming RPCs, and multiplexing of RPCs over a single channel provided by libraries. On the other hand, many commercial SDN controllers are based on the OpenDayLight (ODL) framework, which was initially popular. In the current technological state, the open-source community has now turned its focus to ONOS, an open SDN controller defined by the ODTN working group [67] led by the Open Networking Foundation (ONF). There are still significant challenges with open solutions being ready for adoption in optical networks, however. Furthermore, the addition of new features usually results in challenges with complexity and scalability. It seems that a radical new implementation method is necessary to achieve tremendous progress while maintaining scalability. One way to prevent monolithic SDN controller implementations is to decouple intent actions from database management. It is now possible to construct databases as standalone systems that are able to gather data (e.g., via telemetry) and communicate network characteristics (for reliability and information sharing) and conduct basic operations on the obtained data. The SDN controller solution would only implement queries to the DB and enforce intent-related activities.
4.5.1. Current Implementation of Disaggregation in Optical Networks for SDN Using ONOS
When ONOS was first developed, it was intended for use in typical SDNs based on layer 2 switches [99] (i.e., OpenFlow-enabled devices). The most prevalent weaknesses of an SDN architecture with a centralized controller, including reliability and scalability, have not been natively addressed by other SDN controllers. Because of this, it is one of the finest options for optical network control in terms of reliability has been used in the ONOS community, and ONOS is set up such that the controller functions execute on a number of synchronized instances on several physical machines, each operating on its own independent physical machine. As a result, the system’s scalability is significantly improved using this method with an advanced multithread software architecture. It has been thoroughly tested in simulated situations [100, 101], as well as in the deployment of actual networks, such as China Unicom’s commercial deployment and a global deployment of research networks (Internet2, GÉANT, etc.). As a result of the high bandwidth and latency requirements, the multi-instance architecture calls for the controller instances to be situated on the same LAN as the other instances as shown in Figure 16. A number of ONOS implementations are aiming to employ multi-instance controllers, each of which is assigned a separate geographical or technical domain. Consequently (e.g., electronic and optical), E-CORD (enterprise CORD) uses two different ONOS controllers for each CO and a separate ONOS controller for the network linking the orchestrator. This project is being investigated by various international operators, including TIM. The network orchestrator interfaces with a parent ONOS, which manages all those controllers. As another example, one may point to the metro-haul project’s control plane design, in which each metro-node is equipped with a separate ONOS controller, as well as a separate ONOS controller for each optical metro/regional disaggregated optical network that connects them. A paper by Bob et al. also used a different approach where they made a demonstration, and in their approach, it could be inferred that the optical network emulation gains numerous crucial new features. SDN-controlled packet optical network emulation includes an optical switching and transmission layer, as well as a model of the transmission layer. Devices such as transceivers, amplifiers, optical fiber stretches, and ROADMs that can be controlled and monitored using SDN topologies with several optical nodes may be easily implemented. SDN controllers are compatible with packet network emulation programmes. For instance, Mininet, an open-source tool can be connected with commercial SDN controllers like ONOS to emulate packet optical networks.
4.5.2. Disaggregation: YANG Models and Related Work toward Open SDN
Optical disaggregation, a recent development, gives network operators the option of opening their networks up to several vendors. As a result, optical networks have traditionally been implemented as a single-vendor solution, delivering optical line systems, nodes (e.g., ROADMs), and transceiver cards as black boxes that have proprietary and closed technologies and APIs, severely restricting interoperability. The SDN paradigm has recently opened the door to a standard API that may define, abstract, configure, and obtain the status of an optical device using common YANG models. The open API to each component of the node and the ability to add equipment from different vendors are two reasons why nodes may be opened (i.e., white box). As an example, partial disaggregation allows multiple manufacturers’ XPonders (sometimes referred to as transponders or muxponders) to be deployed within a ROADM from a third party, as long as the light path endpoints are all from the same company. Network devices and controllers communicate via the NETCONF protocol, which allows for both setup and monitoring operations in EON. To communicate information between controller and devices, NETCONF uses the edit-config (configuration) and the collection of state parameters (state parameters). The data sent are formatted in XML and often follow data models that are described using the YANG syntactic structure (i.e., YANG model). To allow the SDN paradigm and abstract network devices, various device suppliers might depend on the NETCONF protocol and custom/proprietary YANG models. Custom setup settings and monitoring features allow for complex and customized transmission methods to be established. SDN controllers need to be able to communicate with optical devices that come from a wide range of vendors to construct a disaggregated optical network. In fact, in the case of several vendors providing the essential elements of an optical network, including ROADMs, amplifiers, and links, the adoption of common models selected by all involved vendors is critical to ensure device compatibility and to enhance vendor-neutral control planes. The work done by open-source multivendor initiatives such as OpenROADM (promoted by Big Telco and cloud operators), OpenConfig (promoted by Google), and the Telecom Infra Project (TIP) [102] has recently proposed white box disaggregation design, development, and control strategies in access, metro, and core optical network segments. There have been two types of implementations of optical disaggregation proposed in research and industry activities. Partial disaggregation presupposes that the optical transport infrastructure is handled by one vendor and transponders, which come in pairs and depend on vendor-neutral management for their operation. OpenConfig is the most significant YANG paradigm for partial disaggregation standardization project. As a result, ROADMs are considered white boxes in the entire disaggregation method. OpenROADM serves as a model for comprehensive disaggregation in this context. As long as transponders are offered in pairs, many operators and manufacturers find partial disaggregation to be a desirable solution for reducing optical data plane complexity. Although it is widely accepted for transponder control, OpenConfig is not ideal for a completely disaggregated network. It is also possible to operate optical devices as white boxes using OpenROADM, although this technique comes with a significant increase in control complexity.
4.5.3. ODTN Working Group
The open and disaggregated transport network (ODTN) initiative brings together network operators to construct data center interconnects based on open standards and free software. Making open-source software accessible to manage a multivendor network assembly is one of ODTN’s declared aims in becoming the optical network of choice. Unlike the bulk of the preceding use cases and deployments, ONOS as an optical network controller is still under development and testing in research environments. ONOS’s initial attempt at optical network control extends the OpenFlow protocol [103, 104], making OpenFlow protocol inflexible for optical plane configurations. On the other hand, additional creation of initiatives started implementing YANG for thorough optical component simulation and setup. Due to the necessity for network control and monitoring, the NETCONF protocol [105] was established. The OTDN working group’s major purpose is to assist ONOS regulate, check, and administer disaggregated optical networks [106]. The ODTN is built in three phases. Phase 1.0 provides NBI and SBI controller interfaces. The NBI in this phase of ODTN applications accepts proper optical connection requests, while SBI ODTN drivers create transponder pairs on the SBI platform. In phase 1.5, an OLS is installed in each pair of transponders, necessitating the construction of an OLS driver. An SDN may build a meshed network topology utilising ROADMs in phase 2.0, and all ONOS accessory functions must be converted to operate in the optical domain. Phase 3.0 in OTDN considers the disaggregation of fundamental optical devices such as optical filters, the degrees of nodes, and devices for optical amplification. However, disaggregation may overwhelm the controller without contributing much in terms of resource efficiency; therefore, phase 3.0 is still unknown. ODTN is still in development phases 1.0 and 1.5. The NBI already uses TAPI 2.0 model to process connection requests and manage the network topology [107]. ONOS uses RESTCONF [104] to support TAPI [105]. Users request light pathways using the TAPI connection YANG model, as shown in Figure 17. (1) The ONOS core gets a connection request and maps the TAPI service interface to an ONOS port on the transponder. (2) For example, the ODTN project recently adopted the intent-based approach to reuse existing ONOS functionality. These comprise basic routing and spectrum assignment algorithms, processes for compiling intents into flow rules, and device driver components. The device drivers deliver the configurations to the data plane. (3) Several NETCONF protocol drivers are presently being developed for this end aim. It depends on the YANG model and device (e.g., transponder and ROADM) [83]. Under the present release, drivers are used for OpenConfig transponders, while drivers for ROADMs based on OpenROADM models are still in development but have been tested by academics and industry. The ONOS extension to optical disaggregated networks also creates serious concerns that must be addressed soon.
4.6. General Advantages and Benefits of SDON
Optical networks have a number of advantages in regard to software-defined network management of land control networks. SDN’s programmability makes it possible to administer and control the network with ease. Considering the commonly used protocol, the OpenFlow protocol and NETCONF allow essential features to be managed by the software interface. This controllability also improves the system’s performance. The key goal was to examine the multilayer structure and implementation in the network, demonstrating the solved problems and their prospects when integrated with the SDNS. The integration provides a more easy, scalable, and less expensive. Overall, the software-defined networks allow for the most efficient use of machine energy. Any of the advantages are quantifiable and can be calculated. Others, on the other hand, are subjective and may only be quantified qualitatively. The most efficient utilisation of energy lowers the network’s maintenance costs (by lowering the amount of electricity available for operations). Analytically, it can be clarified. When designing a network architecture, we consider resource utilisation, protection, and resilience, as well as network element provisioning.
Furthermore, the examination of the extra top-up of data is generated by controllers and orchestrators, which is crucial and vital to optimize a network. The SDNs used for the DCS between and the DCS within were examined using the presented criteria. Software specified networking (SDN) is a concept introduced by [108] that decouples the secret foundation abstracted for programs and network administration, enabling network management to become clearly straightforwardly programmable. A rational estimation of management spending is also possible.
4.6.1. Proposed SDON Architecture
The section of this study will elaborate more on the proposed architecture. Considering the paradigm and principles employed by optical network disaggregation, this research presents a flexible SDON architecture for enhancing network flexibility and vendor neutrality. The SDON orchestrator will leverage on docker containerisation with ONOS SDN controller connected to a Kubernetes cloud. This architecture could be tested and executed on a virtualised platform, which simulates real-life networking tools and instances. The proposed SDON architecture in this study is sectioned into an orchestration plane, which also includes the control plane and data plane, and the topmost layer or section is the application plane, which is connected with OSS/OBB services. The architecture can be harnessed together that any other application network providers may deem fitting and appropriate for service. From the various reviews and implementations, it could be inferred that major stakeholders in telecommunications worldwide are adapting to cloud native solutions in their data centers for flexibility and scalability purposes capitalising on containerised network functions (CNFs). Since lots of works have been done by the ONF and OTDN in this area, this architecture leverages on various strengths of different implementations to compliment the weakness of another implementation and vice versa. The topmost plane of the proposed architecture, shown in Figure 18, utilises these cloud-based data centers. In the proposed architecture, the database is connected to the Kubernetes node infrastructure. This architecture will manage network resources by considering bandwidth and improve CPU utilisation, and these would be implemented in the network orchestration. The control plane where network orchestration happens takes charge of the SDN control, OpenFlow switch management, and various controls for the different hosts on the SDON. This means that the orchestration plane serves as a higher hierarchy of control over the entire network. SDN open virtual switches will be deployed using ONOS containers, which will control the different network hosts at the data plane level. The data plane contains both optical and traditional network devices. In virtualised simulation, since ONOS is deplorable to docker containerisation, the various OpenFlow switches will use TCP/IP and can also use UDP for communication making ONOS accessible using IP addresses. This architecture will join together various open switch control instances with a docker container. To face the SDON and 5G challenges, the proposed architecture will serve to provide a scalable, full automation, flexible self-healing, and self-optimization to improve network resource utilisation in a more flexible way. This proposed architecture will be extensible to various data center architectures and compatible with current colourless, directionless, contentionless, and gridless ROADM components. This will also make decision-making by the SDN controller faster. In terms of security, the virtualisation can create different policies for different implementations as mentioned in [109].
Researchers and stakeholders will gain from this upgraded architecture with hybrid functionality for a variety of reasons listed as follows:(1)High flexibility and scalability This architecture relies on cloud native principles, making it very efficient for network scalability. The Kubernetes master node implemented on top of the architecture has a wide range of support for network flexibility by providing network orchestration and load balancing capabilities. Since containers are lightweight and very scalable, this will help stakeholders to utilise the pay-as-you grow strategies for their network infrastructure and have several options for network orchestration. The architecture would be tested on various scalability instances using the different number of hosts and different case scenarios to see the elasticity of the architecture.(2)High service reliability The architecture has a redundancy built into both the control plane and orchestration plane such that when an SDN controller loses connectivity, the link and data plane components will be redirected to another SDN controller. At the orchestration plane, the architecture leverages on containerisation, and components such as the etcd in the Kubernetes master node are used to store and replicate the Kubernetes cluster state. The implementation of Kubernetes at the orchestration plane opens more room for reliability and persistence in network state and accessibility. The control plane has backup controller, which automatically takes over when an SDN controller is down. This improves service reliability and accessibility for the network host.(3)Cost-effective and high utilisation of resources The architecture considers the utilisation of network bandwidth and CPU utilisation to save cost. This capability is inbuilt at the orchestration layer where the Kubernetes master node provides load balancing to the SDN controller and orchestrates the SDN controller to shed its load when it reaches a percentage utilisation. Moreover, when an SDN controller is not in use, it will automatically be put into an idle state based on CPU usage for the entire network architecture. When a bandwidth and CPU are on hold and not in use, it saves a lot of power, which is indirect to the cost of production and usage for telecommunication companies.(4)Quality of service and feasible in real-time applications The architecture is built on an open-source ONOS controller, which imitates real-time scenarios. The architecture replicas host network devices at the data plane, which can communicate with each other and operate in real time. The entire virtual setup can be accessed via an IP address and a port, which can be implemented by applications. When pinging different data plane network devices, the time of response and delay time are set to replicate similar instances in real-life scenarios.(5)Accommodation for high bandwidth and demand This study elaborates the proposed architecture and sets the mark for cost-effectiveness from its inception. The cost-effectiveness, high network resource utilisation, and scalability of this architecture enable it to accommodate more bandwidth and resources.
The proposed architecture with SDN controller acting as an orchestrator is presented in Figure 18. There are three planes in the proposed architecture. The NETCONF connects the data plane with the network components. The NETCONF protocol provides primitives for viewing and manipulating data while adhering to the data encoding model’s requirements. Data are organized into one or more configuration data stores (a collection of configuration information needed to transform a device from its default state to a desired operational state). The network components, such as transponders and ROADMS, are linked to the control plane through NETCONF. A YANG module specifies a data model, which contains a header, import, statements, type, definitions, configuration, operational data declarations, and actions (RPC), and notifications. Using encapsulation of containers and lists, the language is expressive enough to arrange data into data trees inside so-called data stores. The ONOS SDN controller’s YANG models are linked to the SDN agent, which has a driver model and an open YANG model. This design, which includes a multivendor driver, has to be more programmable to handle multiple suppliers and provide more flexibility. A cluster of three-instance ATOMIX partition is established at the network orchestration plane, which is already in place thanks to the ONF and OTDN initiatives. This ATOMIX cluster is set up in a three-instance configuration with three or more docker containers running a JVM. To overcome the split-brain issue of distributed systems, both ONOS and ATOMIX are deployed with an odd number of instances. SDN controllers provide applications and network orchestrators with proprietary interfaces, a practice known as “vendor domains or islands.” The network devices are linked to the server through a separate management network in this configuration. To eliminate single points of failure in actual deployments, a number of servers or a Kubernetes cloud native environment may be utilised to host each needed docker container. There is a requirement for a consistent interface with common models to operate as a controller, NBI as a driving motivator, and unambiguous issue explanation. The ONF’s transport API (T-API) satisfies the primary criteria for a protocol and interface that connects an orchestrator to many domain controllers. A TAPI-based interface may provide a variety of services.
5. Current SDON Application Challenges
Since SDON is a novel technology, it faces many obstacles [82] throughout the advancement and evolving phase. The optical layer differs from the electrical layer in terms of order, contrast, and other features. Although disaggregation solves lots of problems with flexibility and vendor-neutral ability, model-driven development has not been achieved to its full potential until the framework, languages, and other tools can employ a set of agreed-upon models [110]. Moreover, regarding the controller component of SDN, the controller is still not fully secured and reliable, and it is vulnerable to denial-of-service (DoS) attacks [111]. Table 8 provides a summary of state of the art in SDON solutions and implementations.
5.1. Flexibility
A flexible network adds up to the solution provided by the conventional network by giving access to network dynamism and fine-grained operations. A flexible network has features that accommodate network elasticity and “elastic orchestration” of “network slices.” This characteristic of network flexibility improves network efficiency and the utilisation of network resources. In 2020, [89] proposed a network slicing strategy to solve SDON flexibility issues. The use of the network slicing techniques requires network providers to open their physical network connectivity platform to the parallel introduction of multiple logical self-contained networks. This technique of network slicing is orchestrated in various ways based on their individual service requirements. These network slices are then (temporarily) controlled by tenants, since these tenants have control over several layers such as the physical layer, virtualisation layer, and service layer. Any of these instances consist of a collection of virtual network functions that are orchestrated and operated on the same infrastructure. Different network slice instances may be orchestrated and designed independently according to their specifications, such as network QoS; in this sense, very heterogeneous requirements may be met on the same infrastructure. Reference [91] also proposed and leveraged on ROADMs of an optical network by suggesting CDC ROADM implementation. According to research from [93, 94, 96], much attention should be given to the southbound interface with the data plane devices. This would mean instead of incorporating the intelligence into the SDN controller, the various data plane devices will have intelligence on their own. When MPLS is used, the label switch path (LSP) allows different routing packets to transition to routers based on a fashion that is connection-based. Table 9 summarises the various flexibility approaches provided in the literature.
5.2. Quality of Service
One of the essentials for measuring network performance is the quality of services it provides. Quality of service could be based on several parameters such as bit error rate, signal-to-noise ratio, and quality factor. This section will analyse the various SDON solutions from different literature studies and their accompanying gaps. Table 10 shows the different implementations to solve SDON problems. Most solutions suggest that we propose an algorithm for solving the issues at hand in SDON. In solving these problems, a factor this section looks out for is the effect of the problem-solving on the quality of service delivered. Although SDON is a successful candidate with a great potential to have access to numerous information resources via the energy Internet, one of the SDON’s main challenges is to help the SDON’s diverse existence of services. As a result, the SDON must have the potential to “service awareness” to be a future proof. Nevertheless, the SDON currently struggles to properly consider and balance these services with high performance, which is a crucial concern with the features and specification of different large information systems. Table 10 also summarises the different reviews for solving quality-of-service problems in SDON and the limitations in these implementations.
5.3. Security and Reliability
Even though SDNS provides optical networks with lots of vitality, there have been lots of debates surrounding the area of security. A number of researchers and stakeholders in optical network paradigm propose that SDN in optical network already provides an achievable security, and it has security benefits also. Others suggest that SDN-enabled optical networks are very cumbersome and complex to be rightly secured. There are a few security and reliability papers that point out the security areas of interest. SDON attackers mostly gain from the inadequate expertise and novelty of the SDON technology. Most attackers concentrate on the controllers and introduce a potential threat for applications in the SDN, which could affect the configuration of the optical network. Security and reliability go hand in hand, and a few solutions from various publications are summarised in Table 11.
5.3.1. Current SDON Challenges
SDN technology vastly benefits companies and network providers by improving network controllability with SDN orchestration. There have been a number of algorithms and strategies implemented to inculcate orchestration to solve SDN problems. The current problem of SDN is not just the capacity to implement automatic behaviour in a network or the coordination of networking hardware and software pieces to enable applications and services. There are specific challenges that sprout with the implementation of orchestration for SDNs. From the reviews under [111], in terms of optical network flexibility, most researchers adapted to using a reconfigurable optical add/drop multiplexer (ROADM) [115] as an essential component where SDN functionality can be deployed into the optical network environment [116]. It could also be inferred that the ROADM component [117] being vendor-neutral allows for a wide variety and accommodates a wide range of proposed algorithms [118], which can be used. The remaining proposal under flexibility is very specific to a particular problem, such as elasticity in optical networks and embedded control planes; notwithstanding these areas are also vital for future research work. From the reviews on the current state of the art in quality of service, it can be inferred that much light was thrown on algorithms and implementations that can render positive feedback on the performance of SDON. Again, [125] presented a ROADM-based approach using a tailored algorithm to render the services needed by the service providers and the client. Looking at the limitations under quality of service, most of the proposed approaches had a problem with quality of service, which was measured based on signal-to-noise ratio, bit error rate, jitter, time delays, and topology limitations [120]. In tackling security and reliability issues in SDON, the proposed algorithms in [121] all indicate that much attention should be given to the SDN controller in optical networks. In just a few instances did people suggest using machine learning approaches for SDON, and the limitation [66] to this is the complexity associated with the programs for various machine learning [18]. Upon the ROADM as an SDN controller suggestion [54], [126] suggested an advanced reconfigurability approach. The rest settled on the conventional approach. Even with Rakesh et al., after suggesting CDC as an approach, a two-client approach was set up for testing and later the proposed solution used another approach. This study considers a colourless, directionless, contentionless, and gridless (CDCG)-based approach using ROADM as a controller. Table 12 highlights the current strategies used to solve SDN problems and their accompanying limitations.
Table 12 presents different implementations for solving problems related to network and service orchestration. The majority of the strategies suggested and implemented above sought to solve the bandwidth and scalability problems, because one of the main motives for implementing SDN orchestration is to make the network scalable as much as possible and utilise the use of bandwidth. The use of docker containers solves the majority of scalability problems, and upcoming implementations will capitalise on dockerised OpenFlow containers for the control plane. Another factor that most strategies and implementations focused on was bandwidth utilisation, which was a missing ingredient from some of the above solutions. High latency and network reliability were also a limitation in current implementations. This calls for an implementation where bandwidth can be monitored and well utilised so the network can be scaled as it grows. These factors are useful for service providers and all network stakeholders. Last but not least network reliability should be well catered for since customers pay for services and require reliability on the part of stakeholders and service providers. The proposed implementation and architecture consider all these limitations and provide the necessary implementation.
6. Recommendations and Future Research Directions
This study proposed an SDON solution based on a flexible orchestrator. Given the progress made in the advancement and deployment of SDON solutions in recent years, aspects such as flexibility, security and reliability, quality of service, and a few other taxonomies expatiated need further reconditioning and enhancement. Despite the recent work in these segments under SDON, major issues in testing will continue to be dealt with in the immediate future as more complex algorithms are being implemented in these areas. To get a balance and optimum SDON performance, which considers flexibility, security, reliability, QoS, cost, and expenditure [131], as well as throughput efficiency, future studies, and research work, should focus and take into further consideration these fields of research under SDON.(i)Programmability, Dynamism, and Flexibility of SDON Controller Components: the first recommendation for future studies is to consider adding more intelligence to the SDON controller. The major reason why SDN functionality is inculcated into the optical network paradigm is due to its flexibility and control programmability. Regarding the review and dissection of the various components in this study, its expedient is that much light is thrown on the components that act and operate as an SDN controller in optical networks. The entire flexibility of an SDON depends on these controller components [132]. This gives room to software developers to also capitalise on the programmability of SDN [133] to generate a more robust application program for optical networks and even for orchestration systems in 5G [109]. Furthermore, in the area of security, in tackling security and reliability issues in SDON [130], the proposed algorithm in [59–61, 134] indicates that when much attention is given to the SDN controller in optical networks [94], there would be a more secure SDON because of the robustness [111] of the customized controller algorithms. It could also be inferred from the limitations that a network is reliable or secure based on its configuration or the robustness of its algorithms.(ii)Adapting to Advance Learning Techniques: since the optical network is associated with the physical layer, on some occasions, some network specifications such as the “baud rate” and “modulation formats” affect the transmission line quality. This means that it is crucial that SDON adapts to some network modelling algorithms to be able to predict the transmission quality [113]. A few of the researchers in the review suggested the Dijkstra algorithm and some machine learning techniques. It is also essential for researchers to consider some machine learning algorithms in the future. This will enable the algorithms to study the behaviour of the network and come out with a more precise solution. Some literature studies have gone to the extent of using supervised learning [131] and neural networks to be able to manage link failures and detect transmission quality for testing purposes. In the future, such learning algorithm can be examined to see how well it fits to solve SDON problem deployment based on the optical fiber length, bandwidth, modulation, and multiplexing techniques before they are deployed on an SDON controller. This solves a lot of problems during the testing stages and helps researchers to avoid issues with vendor incompatibility and logical error-prone programs for SDN controllers.
7. Contribution
In order for this century to make the world a global village, it relied heavily on optical networks. The inception of optical fiber networks and their corresponding division multiplexing techniques increased the throughput and speed of the Internet, allowing data to be sent across continents, under the sea, and across cities. These advancements also call for more research and solutions for an optimal and robust performing network [118]. There have been numerous solutions and improvements from researchers even within a few years. With this much insight from recent studies, the green and potholes in research have been clearly exposed for further research and studies, and one of such areas is the inflexibility and problems posed in optical networks. Undoubtedly, from the current state of the art, most researchers approach solving issues of optical networks from the SDN perspective where they can have full charge and control of the entire network [131]. There are more to be done in SDN optical-based networks. This study administered a systematic review of current research solutions, implementations, and advancements in SDON from divers’ researchers and research groups. The paper clearly elaborated on the fundamentals of SDON, the benefits, and the recent challenges in SDON based on a few metrics rendered by these researchers along with the strategies they adapted to solve these problems. This architecture proposed provides an introduction to model-driven development, which is a widely used framework for SDN in transportation networks, based on the increased programmability of devices. The basic principles underpinning SDN for disaggregated optical networks include reference design and industry best practices, the YANG data modelling language, and the NETCONF/RESTCONF protocols, as well as a subset of partial and complete disaggregation deployment models. This study focuses on a specific use case for model-driven development, which has been disaggregated optical networks in recent years, with a concentration on the usage of TAPI interfaces and YANG models with open device model capabilities. Below is a summary of various solution implementations based on different taxonomies as shown in Table 13.
8. Conclusion
This article after in-depth review provides an overview of current SDN approaches in optical networks. The survey began with an introduction and relevant review studies on SDN and optical networks, respectively. After discussing some challenges in both research areas, an outline of relevant solutions and approaches by other researchers was considered and expounded. Then, from the implementation perspective of flexibility, reliability, and security, the quality of service and cost of SDON were intensively examined. Then, the study again tackled the various difficulties and challenges in research and what can be done in the future. In conclusion, a lot of research has been done on SDN in optical networks, and there are still a lot of challenges and loopholes ahead to be addressed. Nevertheless, the optical network community has a responsibility to assist in fixing these challenges. This study aims to not only provide some fundamental insights into how SDN works in optical networks but also introduce some approaches and implementations and when they should be utilised to address certain issues in SDON. Since this research area is still in its young phase and maturing, we foresee that this review and discussion will pave the way for SDON development and a more intelligent optical network deployment.
Conflicts of Interest
The authors declare no conflicts of interest.