- Email: [email protected]
An extended software defined optical networks slicing architecture
An Extended Software Defined Optical Networks Slicing Architecture
Journal Pre-proof
An Extended Software Defined Optical Networks Slicing Architecture Tiago Portela, Maxwell E. Monteiro, Jefferson Rodrigo A. Cavalcante, Joaquim Celestino Jr, Ahmed Patel PII: DOI: Reference:
S0920-5489(19)30465-9 https://doi.org/10.1016/j.csi.2020.103428 CSI 103428
To appear in:
Computer Standards & Interfaces
Received date: Revised date: Accepted date:
7 December 2019 22 January 2020 22 January 2020
Please cite this article as: Tiago Portela, Maxwell E. Monteiro, Jefferson Rodrigo A. Cavalcante, Joaquim Celestino Jr, Ahmed Patel, An Extended Software Defined Optical Networks Slicing Architecture, Computer Standards & Interfaces (2020), doi: https://doi.org/10.1016/j.csi.2020.103428
This is a PDF file of an article that has undergone enhancements after acceptance, such as the addition of a cover page and metadata, and formatting for readability, but it is not yet the definitive version of record. This version will undergo additional copyediting, typesetting and review before it is published in its final form, but we are providing this version to give early visibility of the article. Please note that, during the production process, errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain. © 2020 Published by Elsevier B.V.
An Extended Software Defined Optical Networks Slicing Architecture
Tiago Portelaa,∗,1 (Researcher), Maxwell E. Monteirob,∗∗,2 (Researcher), Jefferson Rodrigo A. Cavalcantec,∗,1 (Researcher), Joaquim Celestino Jrd,∗,3 (Supervisor) and Ahmed Patele,∗ (Supervisor) a [email protected] b [email protected] c [email protected] d [email protected] e [email protected]
ARTICLE INFO
ABSTRACT
Keywords: OTN, SDN, EON, Optical Network Slicing, Software Defined Optical Networks, Data Centers, NETCONF
Optical Networks are composed of multiple devices, from multiple vendors. Normally these networks have a huge transmission capacity. The Slicing of Optical Networks is not a new concept, but continues to be very important, since the capacity of Optical Networks keeps evolving. Most of the time the slicing is manually configured by system operators. Besides being laborious and error-prone, such configuration limits the clients’ ability to customize and configure the network according to their own needs. One way out of this problem is to separate from these devices the control of and the data from the planes. The Software Defined Networks (SDNs) propose the separation of planes while also offering network operators the flexibility to create and manage applications, enabling them to reduce the network costs by globally optimizing the network’s resources, reducing the staff needed to configure it, and contributing for less violation of the service level agreement (SLA). SDN can also help operators to maximize their profit by generating more revenue through mechanisms that increase availability and failure resiliency, maximize throughput, allow for fast dynamic reprovisioning and enable network virtualization. The goal of this paper is to propose a Software Defined Optical Networks Slicing Architecture (SONA) extension (eSONA). that permits defining components such as topology manager, inventory manager, slice manager and path provisioner, and thus enable Optical Networks slicing. It has proved to be capable of managing different slices and provisioning a path on a given slice over the same physical optical network. It has showed an excellent performance, taking little time to provision paths, even with a large number of nodes, which are crucial for optical environments.
∗ UECE
- State University of Ceará, Brazil - Federal Institute of Technology of Espírito Santo State, Brazil ORCID (s): 0000-0003-0972-098X (M.E. Monteiro) 1 Associated researcher at the State University of Ceará - UECE 2 Associated professor at the Federal Institute of Technology of Espírito Santo State - IFES 3 Titular professor at the State University of Ceará - UECE
∗∗ IFES
Portela et al.: Preprint submitted to Elsevier
Page 1 of 12
eSONA
1. Introduction
Modern long distance networks are multi-technology, and are traditionally organized as interdependent technology layers from low-capacity access layer to high-capacity optical layer, coming to a number of distribution technologies with average capacity. Such complex infrastructure was designed to be operated solely by the owner’s service provider. However, three technology changes have recently transformed this scenario. The first was the evolution of Optical Transport Networks (OTN), which allowed for the fusion of low-capacity data communication with high-capacity optical transmission. More recently, we also saw the emergence of Software Defined WAN (SD-WAN) [20]. But the most recent and most disruptive change was the advent of 5G [10], a technology that has been presenting itself as a game changer in terms of network resources slicing and sharing. Drawing inspiration from the evolution of OTN, we proposed Software-Define Optical Networks Slicing Architecture (SONA), an architecture for a hypothetical scenario where OTN equipment could support a shared operation [25]. Unfortunately, our first proposal did not capture the SD-WAN phenomena, and we were not able to address the consolidation of the new optical network evolution, the elastic Optical Networks (EON) [18]. With the evolution from static to configurable and elastic optical networks, their control planes gained the responsibility for: network topology discovery, status updates, optical equalization, Routing, Spectrum Allocation (RSA).Although control plane technologies such as the Generalized MultiProtocol Label Switching (GMPLS) support such tasks [22], they are not programmable and not shareable among multiservice providers, motivating the development and adoption of programmable control planes for optical networks, either through Software Defined Optical Networks (SDON) [16] or Network Function Virtualization (NFV) [7], which has transformed the way operators manage their networks. Nevertheless, management interfaces previously used to setup and manage physical equipment, such as command line interfaces, XML/NETCONF or Simple Network Management Protocol (SNMP), are making way for network orchestrators and controller’s applications. In this paper, we propose an extension for the Softwaredefined Optical Network Slicing Architecture (SONA) which we call eSONA, defining its components and operation capabilities. Like SONA, eSONA enables Optical Networks slicing by virtualization, but introduces some architectural and functional enhancements.
1.1. Paper’s organization
This paper is organized as follows. In section 2 we provide a list of related works; in section 3 we discuss the proposed architecture; Section 4 presents the optical slicing use cases; In Section 5, we present a Proof of Concept; in Section 6 the evaluation and results of eSONA are presented; and finally, in Section 7 we conclude this investigation and discuss directions for future work. Portela et al.: Preprint submitted to Elsevier
2. Related Works
In the last decades, several researches on Software-Defined Optical Networks have been developed. Gringer et al. [13] revealed the benefits and challenges of extending SDN concepts to optical networks, explaining how complex a control plan for the OTN networks is when compared with data networks, as it is necessary to take into account physical constraints such as optical signal range, bandwidth control and routing light paths. Besides the complexity, Gringer also mentioned the advantages of the optical network virtualization in slices. Lightpaths could thus be configured based on bandwidth and delay constraints, and could be shared among clients. The assignment of Lightpaths on the same physical substrate to different clients is better known as Virtual Optical Network Embedding (VONE) [12]. VONEs are enhanced by EON technology, which maximize the physical substrate usage and asymmetric bandwidth of the client virtual networks. Alvizu et al. [2] have depicted the whole scenario of SDN in transport networks, the so called T-SDN. Once again, the challenges of optical physical layer and the virtualization functions benefits were emphasized. According to Alvizu, SDON is the first step towards transport Software defined Networks. Regarding SDON, [24] and [3] have dealt with an extension of OpenFlow (OF) protocol to support optical switching restrictions, and [5] has added extensions for optical impairments. [17] has proposed a conversion module to translate Open Flow into extended openflow for EON equipment. Fokuda [11] and others have proposed an extension of GMPLS to include EON spectrum fragmentation solution. Therefore, when using a flexible optical layer through reconfigurable Optical ADD and DROP Multiplexer (ROADM) and transceivers that can be tuned, SDN transport networks may need a control protocol extension to deal with optical multiplexing and switching, as well as with variable link bandwidth [18] applications. However, de Almeida and others [1] have brought into our attention the challenges of SDEON, namely: the poor GMPLS support to EON, and the traditional SDN centralized Controller model. Both [5] and [24] propose architectures aimed at the use of SDN concepts to create Virtual Optical Networks (VONs). However, they present a hybrid solution, using algorithms which are well known in the optical world, such as GMPLS RSVP-TE and OSPF-TE. On the other hand, [3] and SONA [25] architecture calculate the route, using proprietary algorithms, a PCE instantiation [8]. [3] and [24] use a network slicing strategy, based upon optical cross-connect tables to establish the virtual paths. SONA uses Virtual Machines with NETCONF database implementing cross-connect function, based on ITU-T recommendations and modeled with YANG language. This features make it easier to deploy SONA in the real world. While SONA generates the VON based solely on link availability, [3] supposedly generates a VON considering the imPage 2 of 12
eSONA
pact of physical layer impairments, using a quality of transmission (QoT) estimator, although it is not clear how these physical impairments are evaluated. The related work summary can be seen in the table below.
Technology EON OTN VON OpenFlow GMPLS Netconf SliceManAPI PCE QoT
[5] ✓ ✓ ✓ ✓ ✓
[24] ✓ ✓ ✓ ✓ ✓
[3]
✓ ✓
works [17] [11] ✓ ✓ ✓ ✓
✓
✓
[25] ✓ ✓
eSONA ✓ ✓ ✓
✓ ✓ ✓ ✓
✓ ✓ ✓ ✓
controllers, which are responsible for network intelligence. The last one is the application layer, composed by client applications that requests and uses network slices. The eSONA extensions are highlighted in Figure 6, section 6. Note that from now on, whenever we refer to SONA’s components, the reader should know that they include eSONA’s. Only eSONA’s enhancements will be highlighted.
Table 1 Comparison of Related works
On Table 1, EON refers to Elastic Optical Networks Technology, while OTN refers to Optical Transport Networks (based on ITU-T recommendations). GMPLS represents not only the control protocol, but also the routing algorithms (like OSPF-TE). NETCONF represents the use of YANG data model and NETCONF transport protocol for internal (solution modules) or external (network devices) configuration. Slice Man API represents a set of programming primitives dedicated to slicing procedures. PCE means the use of an open mechanism for computing routes that is independent of algorithms. And at last, QoT represents the capacity to calculate routes taking physical impairments into account.
2.1. Our Contribution - The eSONA
As it can be noticed by reading Table 1, slicing architectures and solutions use to have gaps, specially related with Elastic Optical Networks, Slicing Man API and QoT. SONA has addressed some of these gaps, with the exception of EON and QoT. Our contribution in this paper is to extend SONA to tackle its weaknesses, namely EON and QoT. This sort of enhanced SONA was baptized (eSONA). eSONA generates the VON based on link availability and quality of transmission. The Link concept was extended to cover the EON sub-carriers and modulation variety.
3. Architecture
Being an extension of SONA, eSONA inherits the architecture of its predecessor, as presented in Figure 1. This proposed architecture intents to enable optical networks slicing through software-defined networks (SDN) layering concept. Both SONA and eSONA’s architectures are divided in 3 layers which communicate with each other through APIs. The first layer contains optical elements of the network. The second, known as the control layer, is made up of one or more Portela et al.: Preprint submitted to Elsevier
Figure 1: SONA’s architecture for optical network slicing
Inside the controller logic, SONA provides a process called Optical Network Slicer (ONS), which is composed of a set of stateful modules. These modules are: the Slices Manager, the Provisioner, the Path Computation Element, the Topology Manager and the Inventory. The input interface of these modules can be created using files in the Extensible Markup Language (XML), JavaScript Object Notation (JSON) or even through objects built in the same implementation language. In addition to the ONS modules, a module called Devices Manager is used to manage the interaction with network devices. It is the adapter-connector between the Optical Network Element and the Provisioner. This module can translate provisioning commands to devices’ specific configuration protocols.
3.1. Inventory
In order to be able to manage a network, it is necessary to know its network devices. The inventory module is responsible for managing and storing information of the devices that compose an optical network. This module must be constantly fed with information about the capabilities of all the devices that connect to the network. Thus, it is necessary to model these devices in a given storage language, defining the granularity needed for their management. Page 3 of 12
eSONA
The basic inventory information can be represented by 3 classes: the Node, the Slot, and the Interface, as it can be seen in Figure 2. These classes have a unique identifier, and in addition to this information, the Node class has a list of slots represented by the Slot class, which in its turn has a list of interfaces. The Interface class contains a field to identify which layer is implemented in it and is being sliced. Interfaces also have an interface Type attribute in order to identify connection capacity over a link.
Figure 3: Class diagram showing the basic structure to represent a network topology
the slice’s topology), besides any other specific parameters of the implemented algorithm.
3.4. Provisioner Figure 2: The eSONA’s extended Class diagram with the basic optical Network Element components
3.2. Topology Manager
The Topology Manager module manages the network topology, which is necessary to provide routing capability. This topology is obtained by neighboring discovery protocols such as LLDP. This module must manage both the topology of the physical network and the topologies of the slices created later. It is also responsible for validating whether the devices and Links used in slices are in the physical topology. Both the physical and the slice’s topologies can be represented using a Topology class instance. Topology has as attributes a unique identifier, the level (physical, or Slice), a list of nodes, and a list of links (Figure 3). The class Link has an identifier, a source node and source Interface, as well as a destination node and a destination interface. The nodes are represented by the Node class, which are dealt with in section 3.1. As an extension of SONA, eSONA introduced the attributes of Availability (to store whether or not a link is busy), BitRate (to summarize the connection transmission capacity), and also of the QoT (to summarize the quality of transmission over that link), as the reader can see in Figure 4. The QoT can be calculated using the FEC, and the BER post-FEC counters [26].
This module is responsible for the provision of network paths. For this task, it uses the path calculated by the PCE, and applies the necessary configurations based on the SONA’s YANG model shown in Figure 11. The YANG configuration is set to the device Manager, which redirects the configuration to the Network Element according to each device’s configuration protocols. Here we have the most notorious change between SONA and eSONA: the introduction of the Device Adapter, as explained in section 3.6. This enhancement was proposed within the eSONA extensions, and it aims at providing the final solution with flexibility and protocol neutrality. Another eSONA’s enhancement was to make the Device Manager mark the provisioned links as Busy (Availability), just after the confirmation of the device’s configuration. It is necessary to avoid wrong calculation by the PCE for new paths over the same physical topology. The following information is needed to identify links in use: link identifier, slice tenant, in which area such slice is contained, and the topology identifier to which the link belongs.
3.5. Slices Manager
The Slices Manager is a module responsible for Slices management, as its name suggests, and is responsible for the creation, removal and updating of slices. Slices Operation must be performed by the main network operator through its application. Before performing any operation, though, this module must interact with the Inventory and Topology Manager modules, so that it is possible to validate the slice information. An example is the verification of the existence and 3.3. Path Computation Element availability of nodes and interfaces. In addition to the operaThe main function of the Path Computation Element (PCE) tions mentioned above, this module also receives the tenant is to calculate a path between the source and destination nodes, controllers’ path, provisioning requests over their slices. if a path exists. This calculation can be done using a route Each slice in the network must be identified by two fields: calculation algorithm, prioritizing requirements such as qualthe slice tenant (slice owner) and which area it belongs to ity of transmission (QoT), price or other policies. This mod(health, safety, etc). The area field can be used to prioritize, ule will only be activated per request and the Provisioner for example, bandwidth for a particular area at a particular module is responsible for requesting route calculation. In time of the day. The representation of a basic slice can be order to actually perform the route calculation, this module seen in Figure 5, where a slice has the identifying informamust receive the source node, destination node, a list of valid tion and a list of possible topologies. nodes, and a list of available links (these two lists come from Portela et al.: Preprint submitted to Elsevier
Page 4 of 12
eSONA
ration protocol. Device Adapters are created automatically by the Device Manager according to the neighbor discovery protocol, but are manually configured to reflect the real aspects of the respective ONE. Those not configured are assumed to be the standard SONA’s OTNSwitch, which requires no mapping translation, because it accepts NETCONF, using SONA’s crossconnection YANG model.
Figure 4: The eSONA’s extended Class diagram with Fixed and Flex Grid Links representation
Figure 5: Class diagram with the basic structure of a network slice
3.6. eSONA’s architecture extension
Figure 6: Extended eSONA architecture for optical network slicing
As mentioned before, the most important eSONA’s architecture extension was the introduction of the so called Device Adapter, a proxy for the real optical network devices (ONE). The device Adapter is responsible for translating SONA’s cross-connection YANG configuration model Figue 11 to the respective network optical device’s configuration protocol, whatever it happens to be. Figure 6 shows the case in which there are three Device Adapters instances: (i) The DeFigure 7: The Device Adapter Class vice Adapter 1, which interacts with a ROADM via Open Config protocol, (ii) The Device Adapter 2, which interacts with an OTN Switch via Netconf Protocol, and (iii) The De4. Use Cases vice Adapter 3, which interacts with an EON ADM via an OpenFlow protocol extension. There are two main use cases for SONA: the creation of a The mapping between SONA’s cross-connection YANG conslice and the establishment of a path in a given slice. Again, figuration model to each of the real devices’ configuration all the use cases shown here are equally valid to eSONA. protocol is beyond the scope of this paper. When driven by Cases or artifacts which are valid only for eSONA will be the Device Manager, the Device Adapter creates and sends to highlighted. the real devices the respective configuration messages. Figure 7 shows the class diagram for this new concept. The 4.1. Slice Creation Device Adapter has the following attributes: the Node Id, In this use case, the actions after the new slice creation making a association with the real optical element; the Type, request from the Network Operator are specified. The objecreferring to the node function/capabilities; the configuration tive is to enable the management of such slice through the protocol; and finally the mapping file, the driver for the transtenant application. Only the main network operator has aclation between SONA’s YANG model and the real configucess to this function. This use case starts after the network Portela et al.: Preprint submitted to Elsevier
Page 5 of 12
eSONA
operator sends a request to create a new slice to the Slices Manager module. The basic flow of this use case begins when the operator decides to create a new slice of the network. At this point, the creation of this slice should be requested to the Slices Manager module - it should be provided with the basic information for slice creation. The main information are the slice owner (the tenant, to which area this slice belongs), nodes, slots, interfaces and links. When the Slices Manager module receives the request, it will first validate the incoming data, and then communicate with the Inventory module in order to validate the data against the device’s inventory. After that, it will request the Topology Manager module to check if there are valid connections between devices reported in the slice. The final validation verifies if the links suggested by the network operator are available for a new tenant (that is, if they were not yet assigned to any customers). The process ends when the slice information is saved in the database. With that, the slice has finally been created. This flow can be seen in the diagram below (Figure 8).
between the source and destination devices. Then, with the calculated route, the cross-connection messages will be built and sent to the Devices Manager module. The process ends when the cross-connection messages are sent to the optical elements. A path provision is thus made. This flow can be seen in the diagram below (Figure 9).
Figure 9: Sequence diagram with the basic flow for path provisioning
For eSONA there’s an extension on this use case, which can be seen in Figure 10. The Diagram shows how the Devices Manager drives the Devices Adapter instance to reach out a real ONE. The other interactions are the same as in SONA.
Figure 8: Sequence diagram with the basic flow for slice creation
4.2. Path Provisioning
This use case specifies the action to request the Optical Network Slicer (ONS) to provision a path for a given slice. The goal here is to enable the provisioning of paths per slice. This function is accessed from the client application, which is viewed as the client controller. This use case starts after the tenant’s Operating System (OS) sends a request to the Slices Manager module to provision a path in a certain slice. The basic flow of this use case begins when the tenant’s OS decides to provision a path over its slice. At this point it should request the path provisioning in the slice it owns, passing its basic credentials and source/destination devices to the Slices Manager. After receiving the request, the Slices Manager module validates the data received through the same validation process described in the use case of creating a slice. After the validation process, the Slices Manager module sends a request to the Provisioner module for it provision a path. The Provisioner will then take the following steps. First, it will ask the Path Computation Element module for a valid route Portela et al.: Preprint submitted to Elsevier
Figure 10: Sequence diagram with the eSONA provisioning extension
5. Proof of Concept
With a view to testing our new technology, we devised a simple strategy to compare SONA and eSONA, having their proofs of concept developed and analysed on the same platforms and in the same scenarios. In what follows, all implementation descriptions related to SONA are to be taken as equally valid to eSONA, except where we explicitly indicate otherwise. Page 6 of 12
eSONA
5.1. Controller
The bases of software-defined networks suggest the use of an external machine to host the network controller functions. SONA’s proof of concept was developed in JAVA and using the OpenDaylight (ODL) [19] as a platform for network programmability. This facilitated the modularization of the architecture. Every module in SONA uses the ODL database, which stores information using [4]. The standard configuration ODL protocol is the Network Configuration Protocol (NETCONF) [6], which over time has become the standard SONA’s South Bound Interface (SBI). Both the tenant and the Network Operator’s API were made using the Representational State Transfer Protocol (REST) [9], which have become the standard North Bound Interface (NBI).
5.2. Bandwidth
As an evolution of SONET/SDH networks, the Optical Transport Network (OTN) [14] introduced the DWDM technology to create more flexible and powerful transmission systems. With a view to preserving compatibility with the prevailing standards of data network, ONT established a transmission hierarchy based on multiples of the 1.25 Gbps basic signal (ODU0): 2.5 Gbps (ODU1), 10 Gbps (ODU2), 40 Gbps (ODU3) and 100 Gbps (ODU4) [21]. In this study, we have taken all the possible OTN rates into account, although the sub ODU0, the ODU4 super compositions (200, 400, 800 Gbps, 1.2 Tbps), as well as the myriad of rates in between them have been excluded from our analysis. These typical EON issues, together with the spectrum fragmentation are beyond the scope of this work.
5.3. Cross-Connection
The cross-connection is the main function performed by an ONE with (CX or OCX) capability, and consists of the switching between input and output signals. This is the very essence of network routing. The connection matrix is an abstraction to represent the cross-connection state. Circuit or path protection and network efficiency are both affected by cross-connection decisions.
5.4. Emulation of Network Elements
Due to material limitations, we have used virtual machines to represent the optical network elements (ONE). Each of those was equipped with a NETCONF agent and database to implement the SONA’s standard cross-connection YANG model, which is based on the ITU-T G.874.1 [15] recommendation. This was altered using the abstractions slots and interfaces instead of atomic functions, as it can be seen in Figure 11 The ONEs virtual machines were created using the OpenStack framework [23]. The VMs’ image was a CentOs 7.2, running on KVM. The Netconf agent and Database were provided by the tail-f confD framework.
6. Evaluation and Results
This section presents the scenario used in the performance evaluation of SONA and eSONA, in terms of slicing perforPortela et al.: Preprint submitted to Elsevier
Figure 11: YANG cross-connection module
mance. Since Data Center interconnection became an important issue, we have decided to evaluate both SONA and eSONA in a typical DCI scenario. Taking into account the different needs of applications for bandwidth and latency, it is important to assess the performance of slices creation and paths provisioning.
6.1. Evaluation scenario
We give here a brief description of the evaluated scenario. It is composed of two data centers which attempt to communicate with each other through an optical network. This network is divided into cores, and each core contains 5 nodes, as shown in Figure 12. It is important to note that the only goal of the core abstraction shown here is to simplify the topology representation, and does not impose any restriction to SONA’s or eSONA’s operation, which could work upon any kind of topology. Communication between cores is carried out through a bridge connection: a couple of border nodes. The Datacenter K is bound to an input node within a core. Data Center K+1 does the same. In order to automate the generation of the topologies, we decided to always bind the Data center Page 7 of 12
eSONA
1 (A) to core 1 and the Data Center 2 (B) to core 2. The remaining network cores are interconnected via bridge connections. Seven topologies were generated so that we could proceed to the evaluation, as shown in Table 2. Aiming to establish a common network base line, all nodes are instances of the standard ONE VM. For eSONA, that means that only instances of the Standard Device Adapter are created and no configuration mapping is needed. Netconf is the standard NBI protocol.
Figure 12: Network topology used for DCs communication with N nodes and N/5 cores
Table 2 Evaluated topologies with the respective number of nodes Topology Topology 1 Topology 2 Topology 3 Topology 4 Topology 5 Topology 6 Topology 7
Number of cores 1 2 3 4 5 6 7
6.4. Slices Creation Results
During the analysis of the ONS performance in creating slices, we took into account the time in milliseconds required for the Slices Manager to be informed of a slice configuration, to communicate with all other needed modules, to execute all validation processes and to save the new slice information in its database. While the test was carried out, we observed that the first slice creation request used a much longer time than the subsequent ones. This extra time is used by the OpenDaylight (ODL) controller to create the instances necessary to call the main method of communication between the client application and the Slices Manager, as well as the time to create database access objects. Thus, in order to analyze only the time spent in the creation of slices algorithm, the tests were performed without restarting ODL. The time required for creating the slices gradually increases as we increase the number of network nodes, as the reader can see in the graph represented in Figure 13. Notice that eSONA’s performance is slightly worse than that of SONA. The time increasing can be explained by the interaction between the Device Manager and the Device Adapter. Besides, the extensions on Link Class (availability) made the retrieving SQL slower.
Number of Nodes 5 10 15 20 25 30 35
6.2. Methodology
The Slice Manager simultaneously received requests for the creation of three distinct slices for each topology in Table 2. These requests were sent by the client applications, representing three different tenants (or Data centers, in our context). All slices had the same number of nodes, so that the results could be compared. Thus, all physical nodes of the network were sliced into three virtual nodes. For each of the seven topologies, the time required for the creation of the three slices was recorded. This process was repeated 30 times, so that variations of the processing time of SONA’s and eSONA’s operations could be taken into account. By the end of the 30 repetitions, the average time for setting all three slices in each topology was calculated.
6.3. Test infrastructure
The ODL and SONA/eSONA components were deployed on a computer with the following specification: • CPU: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz • Storage: Hd Ssd Samsung 840 Evo Sata 6gb/s 500gb • Memory: Corsair Vengeance 8GB DDR3 1600MHz Portela et al.: Preprint submitted to Elsevier
Figure 13: Average time for the creation of three slices in different topologies
Upon analysis of the time taken by each SONA/eSONA component (sub-process), as observed in Section 4.1, to create slices, we found that:
• Around 3.4% of the total time of slices creation is spent on the controller intrinsic processes; • Around 5% is spent with the inventory validation;
• Around 8% is spent checking the availability of interfaces; • Around 9% is spent checking and validating the slices; and • Around 74% is taken up to operate the database;
Page 8 of 12
eSONA
Surprisingly, the database operations consume more time than those of SONA. Nevertheless, we can note that both than the slice validation processes, which run through all their performances are very similar. nodes and interfaces slots, becoming more complex as the network nodes and slices increase: Figure 6.4. As the reader can notice, some of eSONA’s tasks are slightly slower than their SONA’s counterparts, namely, the Controller interactions, the Interface Availability validation and the Topology validation. As expected, the extensions over the Link model and the introduction of the Device Adapter took a toll on processing time.
Figure 15: Average time to provision a valid path in 3 slices on different topologies
Analyzing the time taken by each sub-process, as defined in Section 4.2, for performing the path provisioning, we observed that, on average: • 1% of the total path provisioning time is spent on the validation of the slice;
Figure 14: Average percentage of time needed to execute slice creation per Tasks
• 2% is spent on the preparation of messages of cross connection; • 38% is spent with the controller’s intrinsic processes;
6.5. Path Provisioning Results
When analysing the ONS performance in path provision, as well as in creating slices, we took into account the time, in milliseconds, that it took for the Slices Manager to receive a provisioning request, request the PCE a valid route and finally send the cross-connection messages to the virtual machines. The time spent by the virtual machines on processing the messages was not taken into account. The data collection process was similar to the one presented in the previous section. Slices Manager received provision requests from three client applications, each of them responsible for a different slice. The performance was calculated using the slices created in the slices creation test (thus using the same topology networks). All provisions were made having the source node as node 1 and the node N as the destination node. For each topology, the time required for the routes provisioning in all the slices was recorded. Like in the case of the slices creation tests, we observed that in the first path provisioning request the controller takes much longer than in the subsequent requests. All tests were performed without restarting the Open Day Light (OD) framework, so that we analyze only the time spent by the paths provision algorithm. The time required to provision paths in slices grows in a linear way when we increase the number of network nodes: (Figure 15). eSONA’s performance results are slightly worse Portela et al.: Preprint submitted to Elsevier
• and 59% is spent with route calculation.
Route calculation takes up the largest amount of time, because it concentrates the main operations of the slices’ validation process. In short, the time spent is used up in eliminating busy nodes that cannot be used in route calculation, through the Dijkstra algorithm (Figure 16).
Figure 16: Average percentage of time needed to execute path provisioning subprocesses
Figure 17 shows that eSONA’s components are almost as fast as their SONA’s counterparts, with the exception of the Page 9 of 12
eSONA
Configuration imposition, which is included into SONA’s intrinsic controller process. The route calculation task took pretty much the same amount of time to be executed in both architectures.
optical slices administration. This approach allows the replication of eSONA for a variety of control frameworks, optical equipment and vendors. eSONA’s performance has proven to be slightly worse than that of SONA, but eSONA is far more flexible and comprehensive than its predecessor. Experiments involving eSONA’s EON capability will be further evaluated in a future work.
7.1. Future Work
In an attempt to improve eSONA’s capabilities, the development of the following features are suggested:
Figure 17: Average percentage of time needed to execute path provisioning tasks into eSONA’s subprocesses
7. Conclusion
The study of new forms of optical networks management is a complex task. Although the GMPLS meets some basic management needs of optical networks, several innovations are being made through more research in order to apply Software-Defined Networking concepts to make it more flexible. Advances in Optical Network slicing could make Data Center Interconnection as flexible as the intra-Data Center networks. SD-WAN could also have benefit from the use of shared optical infrastructure. It seems clear for us that optical transport networks must share resources and control in order to meet modern management challenges and that these challenges demand not only control protocol extensions, but a robust slicing solution. The aim of this paper was to extend the Slicing optical network management architecture already available by using the SDN concepts. The focus was on slicing a shared optical transport network, which was successfully achieved as demonstrated in section 6. Although SONA and eSONA were not tested in a real optical network, a proof of concept was implemented using tools widely known in the computer and telecommunication networking community, meeting the needs for the creation of a certain number of sliced virtual networks, as well as of provisioning paths on these slices. We used virtual machines to represent optical devices and Netconf as a control protocol. The proposed architecture and components presented were modeled and created for modifying the traditional SDN controller, so that it could manage slices in an optical network. Among the main components, there are modules for shared and sliced inventory, sliced topology and Portela et al.: Preprint submitted to Elsevier
1. Allowing the routing paths computation to take into account different elastic transfer rates, from 1,25 Gbps to 1,2 Tbps); 2. Implementing the QoT as a routing parameter; 3. Expanding virtualization to other network layers, creating a multilayer slicing; 4. Implementing an EON virtual ONE in order to test the EON issues; 5. Testing eSONA in a real multi Data center interconnection. 6. Porting eSONA to ONOS, a new Telecom controller framework.
Acknowledgements
This research has been partially supported by CNPq National Council for Scientific and Technological Development (CNPq), and Ceará’s Foundation for Scientific and Technological Development Support (FUNCAP).
8. Bibliography References
[1] de Almeida Amazonas, J.R., Santos-Boada, G., Ricciardi, S., SoléPareta, J., 2016. Technical challenges and deployment perspectives of sdn based elastic optical networks, in: 2016 18th International Conference on Transparent Optical Networks (ICTON), IEEE. pp. 1–5. [2] Alvizu, R., Maier, G., Kukreja, N., Pattavina, A., Morro, R., Capello, A., Cavazzoni, C., 2017. Comprehensive survey on t-sdn: Softwaredefined networking for transport networks. IEEE Communications Surveys & Tutorials 19, 2232–2283. [3] Azodolmolky, S., Nejabati, R., Peng, S., Hammad, A., Channegowda, M.P., Efstathiou, N., Autenrieth, A., Kaczmarek, P., Simeonidou, D., 2012. Optical flowvisor: An openflow-based optical network virtualization approach, in: Optical Fiber Communication Conference, Optical Society of America. pp. JTh2A–41. [4] Bjorklund, M., 2010. Yang-a data modeling language for the network configuration protocol (netconf)(ietf rfc 6020). [5] Channegowda, M., Nejabati, R., Simeonidou, D., 2013. Softwaredefined optical networks technology and infrastructure: Enabling software-defined optical network operations [invited]. Journal of Optical Communications and Networking 5, A274–A282. [6] Enns, R., Bjorklund, M., Schoenwaelder, J., 2011. Netconf configuration protocol. Network . [7] Fang, W., Zeng, M., Liu, X., Lu, W., Zhu, Z., 2016. Joint spectrum and it resource allocation for efficient vnf service chaining in interdatacenter elastic optical networks. IEEE Communications Letters 20, 1539–1542.
Page 10 of 12
eSONA [8] Farrel, A., Vasseur, J.P., Ash, J., 2006. A path computation element (PCE)-based architecture. RFC 4655. Internet Engineering Task Force. [9] Fielding, R.T., 2000. Architectural styles and the design of networkbased software architectures. Ph.D. thesis. University of California, Irvine. [10] Foukas, X., Patounas, G., Elmokashfi, A., Marina, M.K., 2017. Network slicing in 5g: Survey and challenges. IEEE Communications Magazine 55, 94–100. [11] Fukuda, T., Liu, L., Baba, K.i., Shimojo, S., Yoo, S., 2015. Fragmentation-aware spectrum assignment for elastic optical networks with fully-distributed gmpls, in: 2015 Optical Fiber Communications Conference and Exhibition (OFC), IEEE. pp. 1–3. [12] Gong, L., Zhu, Z., 2013. Virtual optical network embedding (vone) over elastic optical networks. Journal of Lightwave Technology 32, 450–460. [13] Gringeri, S., Bitar, N., Xia, T.J., 2013. Extending software defined network principles to include optical transport. Communications Magazine, IEEE 51, 32–40. [14] ITU-T, 2010. Optical Transport Networks from TDM to Packet. [15] ITU-T, 2012. G.874.1: Optical Transport Network (OTN): Protocolneutral management information model for the network element view. [16] Ji, P.N., 2012. Software defined optical network. International Conference on Optical Communications and Networks (ICOCN) . [17] Liu, L., Muñoz, R., Casellas, R., Tsuritani, T., Martínez, R., Morita, I., 2013. Openslice: An openflow-based control plane for spectrum sliced elastic optical path networks. Optics express 21, 4194–4204. [18] Masahiko Jinno, Hidehiko Takara, B.K.Y.T.Y.S., Matsuoka, S., 2009. Spectrum-efficient and scalable elastic optical path network: Architecture,benefits, and enabling technologies. IEEE Communications Magazine . [19] Medved, J., Varga, R., Tkacik, A., Gray, K., 2014. Opendaylight: Towards a model-driven sdn controller architecture, in: Proceeding of IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks 2014, IEEE. pp. 1–6. [20] Michel, O., Keller, E., 2017. Sdn in wide-area networks: A survey. IEEE Internet of Things Journal , 37–42. [21] Ramaswami, R., Sivarajan, K., Sasaki, G., 2009. Optical networks: a practical perspective. Morgan Kaufmann. [22] dos Santos, G.C., 2010. Proposta e implementação de plano de controle GMPLS para redes WDM reconfiguráveis. Master’s thesis. UNIVERSIDADE ESTADUAL DE CAMPINAS. Brazil. [23] Sefraoui, O., Aissaoui, M., Eleuldj, M., 2012. Openstack: toward an open-source solution for cloud computing. International Journal of Computer Applications 55, 38–42. [24] Siqueira, M., Oliveira, J., Curiel, G., Hirata, A., van’t Hooft, F., Nascimento, M., Esteve Rothenberg, C., 2013. An optical sdn controller for transport network virtualization and autonomic operation, in: Globecom Workshops (GC Wkshps), 2013 IEEE, IEEE. pp. 1198–1203. [25] de Souza, T.P., Cavalcante, J.R.A., Patel, A., Monteiro, M.E., Celestino, J., 2017. Sona: software defined optical networks slicing architecture, in: 2017 IEEE 31st International Conference on Advanced Information Networking and Applications (AINA), IEEE. pp. 654– 661. [26] Sugihara, K., Miyata, Y., Sugihara, T., Kubo, K., Yoshida, H., Matsumoto, W., Mizuochi, T., 2013. A spatially-coupled type ldpc code with an ncg of 12 db for optical transmission beyond 100 gb/s, in: Optical Fiber Communication Conference, Optical Society of America. pp. OM2B–4.
Portela et al.: Preprint submitted to Elsevier
Page 11 of 12
eSONA Tiago Portela de Souza received his BSc degree in Information Systems at 7 de Setembro University Center (UNI7), and his MSc degree in Computer Science from the State University of Ceará (UECE), Brazil. His research interests cover Internet of Things, Cloud Computing and Software Defined Networks.
Maxwell Eduardo Monteiro received his MSc in Computer Science from the Federal University of Espírito Santo, Brazil, with emphasis on Telecommunication Management. He received his PhD degree from the Federal University of Espírito Santo, Brazil, specializing in Photonic and optical communication. His main research interest lies in the area of Software Defined Optical Networks.
co-authored another book entitled: “Securing Information & Communication Systems: Principles, Technologies & Applications” which was published by Artech House during 2008. On 1st October 2009 he delivered an inauguration public talk at UKM entitled: “THE PACKET THAT NEVER ARRIVED – The Evolution of Fast Secure Heterogeneous Computer Networking”, which traces his key research topics & contributions, as well as some topics of a futuristic nature.
Jefferson Cavalcante received his MSc degree in Computer Science with an emphasis on Computer Networks from the State University of Ceará. He has worked with time series forecasting on network performance monitoring, IPv6 networks and OTN. His current areas of interest are Deep Neural Networks and memristor-based accelerators.
Joaquim Celestino Junior received his MSc degree from the Federal University of Paraíba, in Campina Grande, Brazil, and his PhD from the Université Paris VI, in Paris, France, specializing in Computer Networks and Distributed Systems. He is currently an Emeritus Professor at the State University of Ceará (UECE) and member of the Science Academy in Ceará, Brazil. His research covers networking, security, software defined networks, cloud computing and distributed systems. He has authored more than 100 publications and co-authored several books. He is a member of the Editorial Advisory Board of several International Journals and has participated in many international conferences and workshops. Ahmed Patel received his MSc & PhD degrees in Computer Science from Trinity College Dublin (TCD), University of Dublin in 1978 & 1984 respectively, specializing in the design, implementation & performance analysis of packet switched networks. He is Research Professor at Universidade Estadual do Ceará (UECE), Fortaleza, Brazil and is currently on sabbatical leave with key research interest in Advanced Computer Networking, IoT, Cloud Computing, Big Data, Predictive Analysis, Use of Advanced Computing Techniques, Impact of e-social Networking, Closing the digital divide ICT gap and ICT Project Management. He has published well-over 270 technical & scientific papers & co-authored three books, two on computer network security & the third on group communications. He co-edited one book on distributed search systems for the Internet and also co-edited &
Portela et al.: Preprint submitted to Elsevier
Page 12 of 12
Journal Pre-proof
An Extended Software Defined Optical Networks Slicing Architecture Tiago Portela, Maxwell E. Monteiro, Jefferson Rodrigo A. Cavalcante, Joaquim Celestino Jr, Ahmed Patel PII: DOI: Reference:
S0920-5489(19)30465-9 https://doi.org/10.1016/j.csi.2020.103428 CSI 103428
To appear in:
Computer Standards & Interfaces
Received date: Revised date: Accepted date:
7 December 2019 22 January 2020 22 January 2020
Please cite this article as: Tiago Portela, Maxwell E. Monteiro, Jefferson Rodrigo A. Cavalcante, Joaquim Celestino Jr, Ahmed Patel, An Extended Software Defined Optical Networks Slicing Architecture, Computer Standards & Interfaces (2020), doi: https://doi.org/10.1016/j.csi.2020.103428
This is a PDF file of an article that has undergone enhancements after acceptance, such as the addition of a cover page and metadata, and formatting for readability, but it is not yet the definitive version of record. This version will undergo additional copyediting, typesetting and review before it is published in its final form, but we are providing this version to give early visibility of the article. Please note that, during the production process, errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain. © 2020 Published by Elsevier B.V.
An Extended Software Defined Optical Networks Slicing Architecture
Tiago Portelaa,∗,1 (Researcher), Maxwell E. Monteirob,∗∗,2 (Researcher), Jefferson Rodrigo A. Cavalcantec,∗,1 (Researcher), Joaquim Celestino Jrd,∗,3 (Supervisor) and Ahmed Patele,∗ (Supervisor) a [email protected] b [email protected] c [email protected] d [email protected] e [email protected]
ARTICLE INFO
ABSTRACT
Keywords: OTN, SDN, EON, Optical Network Slicing, Software Defined Optical Networks, Data Centers, NETCONF
Optical Networks are composed of multiple devices, from multiple vendors. Normally these networks have a huge transmission capacity. The Slicing of Optical Networks is not a new concept, but continues to be very important, since the capacity of Optical Networks keeps evolving. Most of the time the slicing is manually configured by system operators. Besides being laborious and error-prone, such configuration limits the clients’ ability to customize and configure the network according to their own needs. One way out of this problem is to separate from these devices the control of and the data from the planes. The Software Defined Networks (SDNs) propose the separation of planes while also offering network operators the flexibility to create and manage applications, enabling them to reduce the network costs by globally optimizing the network’s resources, reducing the staff needed to configure it, and contributing for less violation of the service level agreement (SLA). SDN can also help operators to maximize their profit by generating more revenue through mechanisms that increase availability and failure resiliency, maximize throughput, allow for fast dynamic reprovisioning and enable network virtualization. The goal of this paper is to propose a Software Defined Optical Networks Slicing Architecture (SONA) extension (eSONA). that permits defining components such as topology manager, inventory manager, slice manager and path provisioner, and thus enable Optical Networks slicing. It has proved to be capable of managing different slices and provisioning a path on a given slice over the same physical optical network. It has showed an excellent performance, taking little time to provision paths, even with a large number of nodes, which are crucial for optical environments.
∗ UECE
- State University of Ceará, Brazil - Federal Institute of Technology of Espírito Santo State, Brazil ORCID (s): 0000-0003-0972-098X (M.E. Monteiro) 1 Associated researcher at the State University of Ceará - UECE 2 Associated professor at the Federal Institute of Technology of Espírito Santo State - IFES 3 Titular professor at the State University of Ceará - UECE
∗∗ IFES
Portela et al.: Preprint submitted to Elsevier
Page 1 of 12
eSONA
1. Introduction
Modern long distance networks are multi-technology, and are traditionally organized as interdependent technology layers from low-capacity access layer to high-capacity optical layer, coming to a number of distribution technologies with average capacity. Such complex infrastructure was designed to be operated solely by the owner’s service provider. However, three technology changes have recently transformed this scenario. The first was the evolution of Optical Transport Networks (OTN), which allowed for the fusion of low-capacity data communication with high-capacity optical transmission. More recently, we also saw the emergence of Software Defined WAN (SD-WAN) [20]. But the most recent and most disruptive change was the advent of 5G [10], a technology that has been presenting itself as a game changer in terms of network resources slicing and sharing. Drawing inspiration from the evolution of OTN, we proposed Software-Define Optical Networks Slicing Architecture (SONA), an architecture for a hypothetical scenario where OTN equipment could support a shared operation [25]. Unfortunately, our first proposal did not capture the SD-WAN phenomena, and we were not able to address the consolidation of the new optical network evolution, the elastic Optical Networks (EON) [18]. With the evolution from static to configurable and elastic optical networks, their control planes gained the responsibility for: network topology discovery, status updates, optical equalization, Routing, Spectrum Allocation (RSA).Although control plane technologies such as the Generalized MultiProtocol Label Switching (GMPLS) support such tasks [22], they are not programmable and not shareable among multiservice providers, motivating the development and adoption of programmable control planes for optical networks, either through Software Defined Optical Networks (SDON) [16] or Network Function Virtualization (NFV) [7], which has transformed the way operators manage their networks. Nevertheless, management interfaces previously used to setup and manage physical equipment, such as command line interfaces, XML/NETCONF or Simple Network Management Protocol (SNMP), are making way for network orchestrators and controller’s applications. In this paper, we propose an extension for the Softwaredefined Optical Network Slicing Architecture (SONA) which we call eSONA, defining its components and operation capabilities. Like SONA, eSONA enables Optical Networks slicing by virtualization, but introduces some architectural and functional enhancements.
1.1. Paper’s organization
This paper is organized as follows. In section 2 we provide a list of related works; in section 3 we discuss the proposed architecture; Section 4 presents the optical slicing use cases; In Section 5, we present a Proof of Concept; in Section 6 the evaluation and results of eSONA are presented; and finally, in Section 7 we conclude this investigation and discuss directions for future work. Portela et al.: Preprint submitted to Elsevier
2. Related Works
In the last decades, several researches on Software-Defined Optical Networks have been developed. Gringer et al. [13] revealed the benefits and challenges of extending SDN concepts to optical networks, explaining how complex a control plan for the OTN networks is when compared with data networks, as it is necessary to take into account physical constraints such as optical signal range, bandwidth control and routing light paths. Besides the complexity, Gringer also mentioned the advantages of the optical network virtualization in slices. Lightpaths could thus be configured based on bandwidth and delay constraints, and could be shared among clients. The assignment of Lightpaths on the same physical substrate to different clients is better known as Virtual Optical Network Embedding (VONE) [12]. VONEs are enhanced by EON technology, which maximize the physical substrate usage and asymmetric bandwidth of the client virtual networks. Alvizu et al. [2] have depicted the whole scenario of SDN in transport networks, the so called T-SDN. Once again, the challenges of optical physical layer and the virtualization functions benefits were emphasized. According to Alvizu, SDON is the first step towards transport Software defined Networks. Regarding SDON, [24] and [3] have dealt with an extension of OpenFlow (OF) protocol to support optical switching restrictions, and [5] has added extensions for optical impairments. [17] has proposed a conversion module to translate Open Flow into extended openflow for EON equipment. Fokuda [11] and others have proposed an extension of GMPLS to include EON spectrum fragmentation solution. Therefore, when using a flexible optical layer through reconfigurable Optical ADD and DROP Multiplexer (ROADM) and transceivers that can be tuned, SDN transport networks may need a control protocol extension to deal with optical multiplexing and switching, as well as with variable link bandwidth [18] applications. However, de Almeida and others [1] have brought into our attention the challenges of SDEON, namely: the poor GMPLS support to EON, and the traditional SDN centralized Controller model. Both [5] and [24] propose architectures aimed at the use of SDN concepts to create Virtual Optical Networks (VONs). However, they present a hybrid solution, using algorithms which are well known in the optical world, such as GMPLS RSVP-TE and OSPF-TE. On the other hand, [3] and SONA [25] architecture calculate the route, using proprietary algorithms, a PCE instantiation [8]. [3] and [24] use a network slicing strategy, based upon optical cross-connect tables to establish the virtual paths. SONA uses Virtual Machines with NETCONF database implementing cross-connect function, based on ITU-T recommendations and modeled with YANG language. This features make it easier to deploy SONA in the real world. While SONA generates the VON based solely on link availability, [3] supposedly generates a VON considering the imPage 2 of 12
eSONA
pact of physical layer impairments, using a quality of transmission (QoT) estimator, although it is not clear how these physical impairments are evaluated. The related work summary can be seen in the table below.
Technology EON OTN VON OpenFlow GMPLS Netconf SliceManAPI PCE QoT
[5] ✓ ✓ ✓ ✓ ✓
[24] ✓ ✓ ✓ ✓ ✓
[3]
✓ ✓
works [17] [11] ✓ ✓ ✓ ✓
✓
✓
[25] ✓ ✓
eSONA ✓ ✓ ✓
✓ ✓ ✓ ✓
✓ ✓ ✓ ✓
controllers, which are responsible for network intelligence. The last one is the application layer, composed by client applications that requests and uses network slices. The eSONA extensions are highlighted in Figure 6, section 6. Note that from now on, whenever we refer to SONA’s components, the reader should know that they include eSONA’s. Only eSONA’s enhancements will be highlighted.
Table 1 Comparison of Related works
On Table 1, EON refers to Elastic Optical Networks Technology, while OTN refers to Optical Transport Networks (based on ITU-T recommendations). GMPLS represents not only the control protocol, but also the routing algorithms (like OSPF-TE). NETCONF represents the use of YANG data model and NETCONF transport protocol for internal (solution modules) or external (network devices) configuration. Slice Man API represents a set of programming primitives dedicated to slicing procedures. PCE means the use of an open mechanism for computing routes that is independent of algorithms. And at last, QoT represents the capacity to calculate routes taking physical impairments into account.
2.1. Our Contribution - The eSONA
As it can be noticed by reading Table 1, slicing architectures and solutions use to have gaps, specially related with Elastic Optical Networks, Slicing Man API and QoT. SONA has addressed some of these gaps, with the exception of EON and QoT. Our contribution in this paper is to extend SONA to tackle its weaknesses, namely EON and QoT. This sort of enhanced SONA was baptized (eSONA). eSONA generates the VON based on link availability and quality of transmission. The Link concept was extended to cover the EON sub-carriers and modulation variety.
3. Architecture
Being an extension of SONA, eSONA inherits the architecture of its predecessor, as presented in Figure 1. This proposed architecture intents to enable optical networks slicing through software-defined networks (SDN) layering concept. Both SONA and eSONA’s architectures are divided in 3 layers which communicate with each other through APIs. The first layer contains optical elements of the network. The second, known as the control layer, is made up of one or more Portela et al.: Preprint submitted to Elsevier
Figure 1: SONA’s architecture for optical network slicing
Inside the controller logic, SONA provides a process called Optical Network Slicer (ONS), which is composed of a set of stateful modules. These modules are: the Slices Manager, the Provisioner, the Path Computation Element, the Topology Manager and the Inventory. The input interface of these modules can be created using files in the Extensible Markup Language (XML), JavaScript Object Notation (JSON) or even through objects built in the same implementation language. In addition to the ONS modules, a module called Devices Manager is used to manage the interaction with network devices. It is the adapter-connector between the Optical Network Element and the Provisioner. This module can translate provisioning commands to devices’ specific configuration protocols.
3.1. Inventory
In order to be able to manage a network, it is necessary to know its network devices. The inventory module is responsible for managing and storing information of the devices that compose an optical network. This module must be constantly fed with information about the capabilities of all the devices that connect to the network. Thus, it is necessary to model these devices in a given storage language, defining the granularity needed for their management. Page 3 of 12
eSONA
The basic inventory information can be represented by 3 classes: the Node, the Slot, and the Interface, as it can be seen in Figure 2. These classes have a unique identifier, and in addition to this information, the Node class has a list of slots represented by the Slot class, which in its turn has a list of interfaces. The Interface class contains a field to identify which layer is implemented in it and is being sliced. Interfaces also have an interface Type attribute in order to identify connection capacity over a link.
Figure 3: Class diagram showing the basic structure to represent a network topology
the slice’s topology), besides any other specific parameters of the implemented algorithm.
3.4. Provisioner Figure 2: The eSONA’s extended Class diagram with the basic optical Network Element components
3.2. Topology Manager
The Topology Manager module manages the network topology, which is necessary to provide routing capability. This topology is obtained by neighboring discovery protocols such as LLDP. This module must manage both the topology of the physical network and the topologies of the slices created later. It is also responsible for validating whether the devices and Links used in slices are in the physical topology. Both the physical and the slice’s topologies can be represented using a Topology class instance. Topology has as attributes a unique identifier, the level (physical, or Slice), a list of nodes, and a list of links (Figure 3). The class Link has an identifier, a source node and source Interface, as well as a destination node and a destination interface. The nodes are represented by the Node class, which are dealt with in section 3.1. As an extension of SONA, eSONA introduced the attributes of Availability (to store whether or not a link is busy), BitRate (to summarize the connection transmission capacity), and also of the QoT (to summarize the quality of transmission over that link), as the reader can see in Figure 4. The QoT can be calculated using the FEC, and the BER post-FEC counters [26].
This module is responsible for the provision of network paths. For this task, it uses the path calculated by the PCE, and applies the necessary configurations based on the SONA’s YANG model shown in Figure 11. The YANG configuration is set to the device Manager, which redirects the configuration to the Network Element according to each device’s configuration protocols. Here we have the most notorious change between SONA and eSONA: the introduction of the Device Adapter, as explained in section 3.6. This enhancement was proposed within the eSONA extensions, and it aims at providing the final solution with flexibility and protocol neutrality. Another eSONA’s enhancement was to make the Device Manager mark the provisioned links as Busy (Availability), just after the confirmation of the device’s configuration. It is necessary to avoid wrong calculation by the PCE for new paths over the same physical topology. The following information is needed to identify links in use: link identifier, slice tenant, in which area such slice is contained, and the topology identifier to which the link belongs.
3.5. Slices Manager
The Slices Manager is a module responsible for Slices management, as its name suggests, and is responsible for the creation, removal and updating of slices. Slices Operation must be performed by the main network operator through its application. Before performing any operation, though, this module must interact with the Inventory and Topology Manager modules, so that it is possible to validate the slice information. An example is the verification of the existence and 3.3. Path Computation Element availability of nodes and interfaces. In addition to the operaThe main function of the Path Computation Element (PCE) tions mentioned above, this module also receives the tenant is to calculate a path between the source and destination nodes, controllers’ path, provisioning requests over their slices. if a path exists. This calculation can be done using a route Each slice in the network must be identified by two fields: calculation algorithm, prioritizing requirements such as qualthe slice tenant (slice owner) and which area it belongs to ity of transmission (QoT), price or other policies. This mod(health, safety, etc). The area field can be used to prioritize, ule will only be activated per request and the Provisioner for example, bandwidth for a particular area at a particular module is responsible for requesting route calculation. In time of the day. The representation of a basic slice can be order to actually perform the route calculation, this module seen in Figure 5, where a slice has the identifying informamust receive the source node, destination node, a list of valid tion and a list of possible topologies. nodes, and a list of available links (these two lists come from Portela et al.: Preprint submitted to Elsevier
Page 4 of 12
eSONA
ration protocol. Device Adapters are created automatically by the Device Manager according to the neighbor discovery protocol, but are manually configured to reflect the real aspects of the respective ONE. Those not configured are assumed to be the standard SONA’s OTNSwitch, which requires no mapping translation, because it accepts NETCONF, using SONA’s crossconnection YANG model.
Figure 4: The eSONA’s extended Class diagram with Fixed and Flex Grid Links representation
Figure 5: Class diagram with the basic structure of a network slice
3.6. eSONA’s architecture extension
Figure 6: Extended eSONA architecture for optical network slicing
As mentioned before, the most important eSONA’s architecture extension was the introduction of the so called Device Adapter, a proxy for the real optical network devices (ONE). The device Adapter is responsible for translating SONA’s cross-connection YANG configuration model Figue 11 to the respective network optical device’s configuration protocol, whatever it happens to be. Figure 6 shows the case in which there are three Device Adapters instances: (i) The DeFigure 7: The Device Adapter Class vice Adapter 1, which interacts with a ROADM via Open Config protocol, (ii) The Device Adapter 2, which interacts with an OTN Switch via Netconf Protocol, and (iii) The De4. Use Cases vice Adapter 3, which interacts with an EON ADM via an OpenFlow protocol extension. There are two main use cases for SONA: the creation of a The mapping between SONA’s cross-connection YANG conslice and the establishment of a path in a given slice. Again, figuration model to each of the real devices’ configuration all the use cases shown here are equally valid to eSONA. protocol is beyond the scope of this paper. When driven by Cases or artifacts which are valid only for eSONA will be the Device Manager, the Device Adapter creates and sends to highlighted. the real devices the respective configuration messages. Figure 7 shows the class diagram for this new concept. The 4.1. Slice Creation Device Adapter has the following attributes: the Node Id, In this use case, the actions after the new slice creation making a association with the real optical element; the Type, request from the Network Operator are specified. The objecreferring to the node function/capabilities; the configuration tive is to enable the management of such slice through the protocol; and finally the mapping file, the driver for the transtenant application. Only the main network operator has aclation between SONA’s YANG model and the real configucess to this function. This use case starts after the network Portela et al.: Preprint submitted to Elsevier
Page 5 of 12
eSONA
operator sends a request to create a new slice to the Slices Manager module. The basic flow of this use case begins when the operator decides to create a new slice of the network. At this point, the creation of this slice should be requested to the Slices Manager module - it should be provided with the basic information for slice creation. The main information are the slice owner (the tenant, to which area this slice belongs), nodes, slots, interfaces and links. When the Slices Manager module receives the request, it will first validate the incoming data, and then communicate with the Inventory module in order to validate the data against the device’s inventory. After that, it will request the Topology Manager module to check if there are valid connections between devices reported in the slice. The final validation verifies if the links suggested by the network operator are available for a new tenant (that is, if they were not yet assigned to any customers). The process ends when the slice information is saved in the database. With that, the slice has finally been created. This flow can be seen in the diagram below (Figure 8).
between the source and destination devices. Then, with the calculated route, the cross-connection messages will be built and sent to the Devices Manager module. The process ends when the cross-connection messages are sent to the optical elements. A path provision is thus made. This flow can be seen in the diagram below (Figure 9).
Figure 9: Sequence diagram with the basic flow for path provisioning
For eSONA there’s an extension on this use case, which can be seen in Figure 10. The Diagram shows how the Devices Manager drives the Devices Adapter instance to reach out a real ONE. The other interactions are the same as in SONA.
Figure 8: Sequence diagram with the basic flow for slice creation
4.2. Path Provisioning
This use case specifies the action to request the Optical Network Slicer (ONS) to provision a path for a given slice. The goal here is to enable the provisioning of paths per slice. This function is accessed from the client application, which is viewed as the client controller. This use case starts after the tenant’s Operating System (OS) sends a request to the Slices Manager module to provision a path in a certain slice. The basic flow of this use case begins when the tenant’s OS decides to provision a path over its slice. At this point it should request the path provisioning in the slice it owns, passing its basic credentials and source/destination devices to the Slices Manager. After receiving the request, the Slices Manager module validates the data received through the same validation process described in the use case of creating a slice. After the validation process, the Slices Manager module sends a request to the Provisioner module for it provision a path. The Provisioner will then take the following steps. First, it will ask the Path Computation Element module for a valid route Portela et al.: Preprint submitted to Elsevier
Figure 10: Sequence diagram with the eSONA provisioning extension
5. Proof of Concept
With a view to testing our new technology, we devised a simple strategy to compare SONA and eSONA, having their proofs of concept developed and analysed on the same platforms and in the same scenarios. In what follows, all implementation descriptions related to SONA are to be taken as equally valid to eSONA, except where we explicitly indicate otherwise. Page 6 of 12
eSONA
5.1. Controller
The bases of software-defined networks suggest the use of an external machine to host the network controller functions. SONA’s proof of concept was developed in JAVA and using the OpenDaylight (ODL) [19] as a platform for network programmability. This facilitated the modularization of the architecture. Every module in SONA uses the ODL database, which stores information using [4]. The standard configuration ODL protocol is the Network Configuration Protocol (NETCONF) [6], which over time has become the standard SONA’s South Bound Interface (SBI). Both the tenant and the Network Operator’s API were made using the Representational State Transfer Protocol (REST) [9], which have become the standard North Bound Interface (NBI).
5.2. Bandwidth
As an evolution of SONET/SDH networks, the Optical Transport Network (OTN) [14] introduced the DWDM technology to create more flexible and powerful transmission systems. With a view to preserving compatibility with the prevailing standards of data network, ONT established a transmission hierarchy based on multiples of the 1.25 Gbps basic signal (ODU0): 2.5 Gbps (ODU1), 10 Gbps (ODU2), 40 Gbps (ODU3) and 100 Gbps (ODU4) [21]. In this study, we have taken all the possible OTN rates into account, although the sub ODU0, the ODU4 super compositions (200, 400, 800 Gbps, 1.2 Tbps), as well as the myriad of rates in between them have been excluded from our analysis. These typical EON issues, together with the spectrum fragmentation are beyond the scope of this work.
5.3. Cross-Connection
The cross-connection is the main function performed by an ONE with (CX or OCX) capability, and consists of the switching between input and output signals. This is the very essence of network routing. The connection matrix is an abstraction to represent the cross-connection state. Circuit or path protection and network efficiency are both affected by cross-connection decisions.
5.4. Emulation of Network Elements
Due to material limitations, we have used virtual machines to represent the optical network elements (ONE). Each of those was equipped with a NETCONF agent and database to implement the SONA’s standard cross-connection YANG model, which is based on the ITU-T G.874.1 [15] recommendation. This was altered using the abstractions slots and interfaces instead of atomic functions, as it can be seen in Figure 11 The ONEs virtual machines were created using the OpenStack framework [23]. The VMs’ image was a CentOs 7.2, running on KVM. The Netconf agent and Database were provided by the tail-f confD framework.
6. Evaluation and Results
This section presents the scenario used in the performance evaluation of SONA and eSONA, in terms of slicing perforPortela et al.: Preprint submitted to Elsevier
Figure 11: YANG cross-connection module
mance. Since Data Center interconnection became an important issue, we have decided to evaluate both SONA and eSONA in a typical DCI scenario. Taking into account the different needs of applications for bandwidth and latency, it is important to assess the performance of slices creation and paths provisioning.
6.1. Evaluation scenario
We give here a brief description of the evaluated scenario. It is composed of two data centers which attempt to communicate with each other through an optical network. This network is divided into cores, and each core contains 5 nodes, as shown in Figure 12. It is important to note that the only goal of the core abstraction shown here is to simplify the topology representation, and does not impose any restriction to SONA’s or eSONA’s operation, which could work upon any kind of topology. Communication between cores is carried out through a bridge connection: a couple of border nodes. The Datacenter K is bound to an input node within a core. Data Center K+1 does the same. In order to automate the generation of the topologies, we decided to always bind the Data center Page 7 of 12
eSONA
1 (A) to core 1 and the Data Center 2 (B) to core 2. The remaining network cores are interconnected via bridge connections. Seven topologies were generated so that we could proceed to the evaluation, as shown in Table 2. Aiming to establish a common network base line, all nodes are instances of the standard ONE VM. For eSONA, that means that only instances of the Standard Device Adapter are created and no configuration mapping is needed. Netconf is the standard NBI protocol.
Figure 12: Network topology used for DCs communication with N nodes and N/5 cores
Table 2 Evaluated topologies with the respective number of nodes Topology Topology 1 Topology 2 Topology 3 Topology 4 Topology 5 Topology 6 Topology 7
Number of cores 1 2 3 4 5 6 7
6.4. Slices Creation Results
During the analysis of the ONS performance in creating slices, we took into account the time in milliseconds required for the Slices Manager to be informed of a slice configuration, to communicate with all other needed modules, to execute all validation processes and to save the new slice information in its database. While the test was carried out, we observed that the first slice creation request used a much longer time than the subsequent ones. This extra time is used by the OpenDaylight (ODL) controller to create the instances necessary to call the main method of communication between the client application and the Slices Manager, as well as the time to create database access objects. Thus, in order to analyze only the time spent in the creation of slices algorithm, the tests were performed without restarting ODL. The time required for creating the slices gradually increases as we increase the number of network nodes, as the reader can see in the graph represented in Figure 13. Notice that eSONA’s performance is slightly worse than that of SONA. The time increasing can be explained by the interaction between the Device Manager and the Device Adapter. Besides, the extensions on Link Class (availability) made the retrieving SQL slower.
Number of Nodes 5 10 15 20 25 30 35
6.2. Methodology
The Slice Manager simultaneously received requests for the creation of three distinct slices for each topology in Table 2. These requests were sent by the client applications, representing three different tenants (or Data centers, in our context). All slices had the same number of nodes, so that the results could be compared. Thus, all physical nodes of the network were sliced into three virtual nodes. For each of the seven topologies, the time required for the creation of the three slices was recorded. This process was repeated 30 times, so that variations of the processing time of SONA’s and eSONA’s operations could be taken into account. By the end of the 30 repetitions, the average time for setting all three slices in each topology was calculated.
6.3. Test infrastructure
The ODL and SONA/eSONA components were deployed on a computer with the following specification: • CPU: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz • Storage: Hd Ssd Samsung 840 Evo Sata 6gb/s 500gb • Memory: Corsair Vengeance 8GB DDR3 1600MHz Portela et al.: Preprint submitted to Elsevier
Figure 13: Average time for the creation of three slices in different topologies
Upon analysis of the time taken by each SONA/eSONA component (sub-process), as observed in Section 4.1, to create slices, we found that:
• Around 3.4% of the total time of slices creation is spent on the controller intrinsic processes; • Around 5% is spent with the inventory validation;
• Around 8% is spent checking the availability of interfaces; • Around 9% is spent checking and validating the slices; and • Around 74% is taken up to operate the database;
Page 8 of 12
eSONA
Surprisingly, the database operations consume more time than those of SONA. Nevertheless, we can note that both than the slice validation processes, which run through all their performances are very similar. nodes and interfaces slots, becoming more complex as the network nodes and slices increase: Figure 6.4. As the reader can notice, some of eSONA’s tasks are slightly slower than their SONA’s counterparts, namely, the Controller interactions, the Interface Availability validation and the Topology validation. As expected, the extensions over the Link model and the introduction of the Device Adapter took a toll on processing time.
Figure 15: Average time to provision a valid path in 3 slices on different topologies
Analyzing the time taken by each sub-process, as defined in Section 4.2, for performing the path provisioning, we observed that, on average: • 1% of the total path provisioning time is spent on the validation of the slice;
Figure 14: Average percentage of time needed to execute slice creation per Tasks
• 2% is spent on the preparation of messages of cross connection; • 38% is spent with the controller’s intrinsic processes;
6.5. Path Provisioning Results
When analysing the ONS performance in path provision, as well as in creating slices, we took into account the time, in milliseconds, that it took for the Slices Manager to receive a provisioning request, request the PCE a valid route and finally send the cross-connection messages to the virtual machines. The time spent by the virtual machines on processing the messages was not taken into account. The data collection process was similar to the one presented in the previous section. Slices Manager received provision requests from three client applications, each of them responsible for a different slice. The performance was calculated using the slices created in the slices creation test (thus using the same topology networks). All provisions were made having the source node as node 1 and the node N as the destination node. For each topology, the time required for the routes provisioning in all the slices was recorded. Like in the case of the slices creation tests, we observed that in the first path provisioning request the controller takes much longer than in the subsequent requests. All tests were performed without restarting the Open Day Light (OD) framework, so that we analyze only the time spent by the paths provision algorithm. The time required to provision paths in slices grows in a linear way when we increase the number of network nodes: (Figure 15). eSONA’s performance results are slightly worse Portela et al.: Preprint submitted to Elsevier
• and 59% is spent with route calculation.
Route calculation takes up the largest amount of time, because it concentrates the main operations of the slices’ validation process. In short, the time spent is used up in eliminating busy nodes that cannot be used in route calculation, through the Dijkstra algorithm (Figure 16).
Figure 16: Average percentage of time needed to execute path provisioning subprocesses
Figure 17 shows that eSONA’s components are almost as fast as their SONA’s counterparts, with the exception of the Page 9 of 12
eSONA
Configuration imposition, which is included into SONA’s intrinsic controller process. The route calculation task took pretty much the same amount of time to be executed in both architectures.
optical slices administration. This approach allows the replication of eSONA for a variety of control frameworks, optical equipment and vendors. eSONA’s performance has proven to be slightly worse than that of SONA, but eSONA is far more flexible and comprehensive than its predecessor. Experiments involving eSONA’s EON capability will be further evaluated in a future work.
7.1. Future Work
In an attempt to improve eSONA’s capabilities, the development of the following features are suggested:
Figure 17: Average percentage of time needed to execute path provisioning tasks into eSONA’s subprocesses
7. Conclusion
The study of new forms of optical networks management is a complex task. Although the GMPLS meets some basic management needs of optical networks, several innovations are being made through more research in order to apply Software-Defined Networking concepts to make it more flexible. Advances in Optical Network slicing could make Data Center Interconnection as flexible as the intra-Data Center networks. SD-WAN could also have benefit from the use of shared optical infrastructure. It seems clear for us that optical transport networks must share resources and control in order to meet modern management challenges and that these challenges demand not only control protocol extensions, but a robust slicing solution. The aim of this paper was to extend the Slicing optical network management architecture already available by using the SDN concepts. The focus was on slicing a shared optical transport network, which was successfully achieved as demonstrated in section 6. Although SONA and eSONA were not tested in a real optical network, a proof of concept was implemented using tools widely known in the computer and telecommunication networking community, meeting the needs for the creation of a certain number of sliced virtual networks, as well as of provisioning paths on these slices. We used virtual machines to represent optical devices and Netconf as a control protocol. The proposed architecture and components presented were modeled and created for modifying the traditional SDN controller, so that it could manage slices in an optical network. Among the main components, there are modules for shared and sliced inventory, sliced topology and Portela et al.: Preprint submitted to Elsevier
1. Allowing the routing paths computation to take into account different elastic transfer rates, from 1,25 Gbps to 1,2 Tbps); 2. Implementing the QoT as a routing parameter; 3. Expanding virtualization to other network layers, creating a multilayer slicing; 4. Implementing an EON virtual ONE in order to test the EON issues; 5. Testing eSONA in a real multi Data center interconnection. 6. Porting eSONA to ONOS, a new Telecom controller framework.
Acknowledgements
This research has been partially supported by CNPq National Council for Scientific and Technological Development (CNPq), and Ceará’s Foundation for Scientific and Technological Development Support (FUNCAP).
8. Bibliography References
[1] de Almeida Amazonas, J.R., Santos-Boada, G., Ricciardi, S., SoléPareta, J., 2016. Technical challenges and deployment perspectives of sdn based elastic optical networks, in: 2016 18th International Conference on Transparent Optical Networks (ICTON), IEEE. pp. 1–5. [2] Alvizu, R., Maier, G., Kukreja, N., Pattavina, A., Morro, R., Capello, A., Cavazzoni, C., 2017. Comprehensive survey on t-sdn: Softwaredefined networking for transport networks. IEEE Communications Surveys & Tutorials 19, 2232–2283. [3] Azodolmolky, S., Nejabati, R., Peng, S., Hammad, A., Channegowda, M.P., Efstathiou, N., Autenrieth, A., Kaczmarek, P., Simeonidou, D., 2012. Optical flowvisor: An openflow-based optical network virtualization approach, in: Optical Fiber Communication Conference, Optical Society of America. pp. JTh2A–41. [4] Bjorklund, M., 2010. Yang-a data modeling language for the network configuration protocol (netconf)(ietf rfc 6020). [5] Channegowda, M., Nejabati, R., Simeonidou, D., 2013. Softwaredefined optical networks technology and infrastructure: Enabling software-defined optical network operations [invited]. Journal of Optical Communications and Networking 5, A274–A282. [6] Enns, R., Bjorklund, M., Schoenwaelder, J., 2011. Netconf configuration protocol. Network . [7] Fang, W., Zeng, M., Liu, X., Lu, W., Zhu, Z., 2016. Joint spectrum and it resource allocation for efficient vnf service chaining in interdatacenter elastic optical networks. IEEE Communications Letters 20, 1539–1542.
Page 10 of 12
eSONA [8] Farrel, A., Vasseur, J.P., Ash, J., 2006. A path computation element (PCE)-based architecture. RFC 4655. Internet Engineering Task Force. [9] Fielding, R.T., 2000. Architectural styles and the design of networkbased software architectures. Ph.D. thesis. University of California, Irvine. [10] Foukas, X., Patounas, G., Elmokashfi, A., Marina, M.K., 2017. Network slicing in 5g: Survey and challenges. IEEE Communications Magazine 55, 94–100. [11] Fukuda, T., Liu, L., Baba, K.i., Shimojo, S., Yoo, S., 2015. Fragmentation-aware spectrum assignment for elastic optical networks with fully-distributed gmpls, in: 2015 Optical Fiber Communications Conference and Exhibition (OFC), IEEE. pp. 1–3. [12] Gong, L., Zhu, Z., 2013. Virtual optical network embedding (vone) over elastic optical networks. Journal of Lightwave Technology 32, 450–460. [13] Gringeri, S., Bitar, N., Xia, T.J., 2013. Extending software defined network principles to include optical transport. Communications Magazine, IEEE 51, 32–40. [14] ITU-T, 2010. Optical Transport Networks from TDM to Packet. [15] ITU-T, 2012. G.874.1: Optical Transport Network (OTN): Protocolneutral management information model for the network element view. [16] Ji, P.N., 2012. Software defined optical network. International Conference on Optical Communications and Networks (ICOCN) . [17] Liu, L., Muñoz, R., Casellas, R., Tsuritani, T., Martínez, R., Morita, I., 2013. Openslice: An openflow-based control plane for spectrum sliced elastic optical path networks. Optics express 21, 4194–4204. [18] Masahiko Jinno, Hidehiko Takara, B.K.Y.T.Y.S., Matsuoka, S., 2009. Spectrum-efficient and scalable elastic optical path network: Architecture,benefits, and enabling technologies. IEEE Communications Magazine . [19] Medved, J., Varga, R., Tkacik, A., Gray, K., 2014. Opendaylight: Towards a model-driven sdn controller architecture, in: Proceeding of IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks 2014, IEEE. pp. 1–6. [20] Michel, O., Keller, E., 2017. Sdn in wide-area networks: A survey. IEEE Internet of Things Journal , 37–42. [21] Ramaswami, R., Sivarajan, K., Sasaki, G., 2009. Optical networks: a practical perspective. Morgan Kaufmann. [22] dos Santos, G.C., 2010. Proposta e implementação de plano de controle GMPLS para redes WDM reconfiguráveis. Master’s thesis. UNIVERSIDADE ESTADUAL DE CAMPINAS. Brazil. [23] Sefraoui, O., Aissaoui, M., Eleuldj, M., 2012. Openstack: toward an open-source solution for cloud computing. International Journal of Computer Applications 55, 38–42. [24] Siqueira, M., Oliveira, J., Curiel, G., Hirata, A., van’t Hooft, F., Nascimento, M., Esteve Rothenberg, C., 2013. An optical sdn controller for transport network virtualization and autonomic operation, in: Globecom Workshops (GC Wkshps), 2013 IEEE, IEEE. pp. 1198–1203. [25] de Souza, T.P., Cavalcante, J.R.A., Patel, A., Monteiro, M.E., Celestino, J., 2017. Sona: software defined optical networks slicing architecture, in: 2017 IEEE 31st International Conference on Advanced Information Networking and Applications (AINA), IEEE. pp. 654– 661. [26] Sugihara, K., Miyata, Y., Sugihara, T., Kubo, K., Yoshida, H., Matsumoto, W., Mizuochi, T., 2013. A spatially-coupled type ldpc code with an ncg of 12 db for optical transmission beyond 100 gb/s, in: Optical Fiber Communication Conference, Optical Society of America. pp. OM2B–4.
Portela et al.: Preprint submitted to Elsevier
Page 11 of 12
eSONA Tiago Portela de Souza received his BSc degree in Information Systems at 7 de Setembro University Center (UNI7), and his MSc degree in Computer Science from the State University of Ceará (UECE), Brazil. His research interests cover Internet of Things, Cloud Computing and Software Defined Networks.
Maxwell Eduardo Monteiro received his MSc in Computer Science from the Federal University of Espírito Santo, Brazil, with emphasis on Telecommunication Management. He received his PhD degree from the Federal University of Espírito Santo, Brazil, specializing in Photonic and optical communication. His main research interest lies in the area of Software Defined Optical Networks.
co-authored another book entitled: “Securing Information & Communication Systems: Principles, Technologies & Applications” which was published by Artech House during 2008. On 1st October 2009 he delivered an inauguration public talk at UKM entitled: “THE PACKET THAT NEVER ARRIVED – The Evolution of Fast Secure Heterogeneous Computer Networking”, which traces his key research topics & contributions, as well as some topics of a futuristic nature.
Jefferson Cavalcante received his MSc degree in Computer Science with an emphasis on Computer Networks from the State University of Ceará. He has worked with time series forecasting on network performance monitoring, IPv6 networks and OTN. His current areas of interest are Deep Neural Networks and memristor-based accelerators.
Joaquim Celestino Junior received his MSc degree from the Federal University of Paraíba, in Campina Grande, Brazil, and his PhD from the Université Paris VI, in Paris, France, specializing in Computer Networks and Distributed Systems. He is currently an Emeritus Professor at the State University of Ceará (UECE) and member of the Science Academy in Ceará, Brazil. His research covers networking, security, software defined networks, cloud computing and distributed systems. He has authored more than 100 publications and co-authored several books. He is a member of the Editorial Advisory Board of several International Journals and has participated in many international conferences and workshops. Ahmed Patel received his MSc & PhD degrees in Computer Science from Trinity College Dublin (TCD), University of Dublin in 1978 & 1984 respectively, specializing in the design, implementation & performance analysis of packet switched networks. He is Research Professor at Universidade Estadual do Ceará (UECE), Fortaleza, Brazil and is currently on sabbatical leave with key research interest in Advanced Computer Networking, IoT, Cloud Computing, Big Data, Predictive Analysis, Use of Advanced Computing Techniques, Impact of e-social Networking, Closing the digital divide ICT gap and ICT Project Management. He has published well-over 270 technical & scientific papers & co-authored three books, two on computer network security & the third on group communications. He co-edited one book on distributed search systems for the Internet and also co-edited &
Portela et al.: Preprint submitted to Elsevier
Page 12 of 12