Simulator for Performance Evaluation of ASON/GMPLS Network

The hierarchical control plane network architecture of Automatically Switched Optical Network with utilization of Generalized Multi-Protocol Label Switching protocols is compliant to next generation networks requirements and can supply connections with required quality of service, even with incomplete domain information. Considering connection control, connection management and network management, the controllers of this architecture could perform the same operations on the transport plane resources and could support control functions for Software Defined Networking controllers, which are considered as the future networking solutions. Therefore, it is very important to determine factors that have an influence on service control and resource management. One of the tools for achieving this goal is computer simulation. The paper proposes a simulator for the hierarchical control plane networks in an open source OMNeT++ environment, in order to evaluate network architecture performance for different network structures and traffic parameters. To demonstrate simulator capabilities, examples of typical simulations performance results for Polish and European network structures are presented and discussed. Performance metrics which have been used to evaluate the performance of this architecture are: mean values of Call Set-up Time, Connection Set-up Time, Call Release Time, Connection Release Time, loss probability for inter-domain connection requests and loss probability for low and high priority requests. General remarks concerned with presented simulator are also provided.


I. INTRODUCTION
The Automatically Switched Optical Network (ASON) is a standardized network architecture proposed by International Telecommunication Union -Telecommunication Standardization Sector (ITU-T) in [1]. The main purpose of ASON control plane is to facilitate fast and efficient configuration of connections within a transport layer network to support both switched and soft permanent connections in a high capacity core optical network. The hierarchical control plane approach, which is presented in [1], gives the opportunity to control multidomain network under the condition of incomplete domain information and can satisfy current and future needs of network operator for supplying services with strictly defined Quality of Service (QoS). The ASON control plane is composed of different components, which provide specific functions with the use of routing and signaling protocols. The protocol suite that can potentially The associate editor coordinating the review of this manuscript and approving it for publication was Guangjie Han . be used to implement the general control plane function is Generalized Multi-Protocol Label Switching (GMPLS) [2], [3]. The ASON approach utilizing GMPLS protocols by control plane is named as ASON/GMPLS. Actually, ASON recommendations are in many areas compliant with Software Defined Networking (SDN) concept. Common control aspects for ASON and SDN controllers are presented in [4], [5]. The first laboratory trial tests for ASON/GMPLS and SDN were conducted and are presented in [6].
For the commercial success, both SDN and ASON/GMPLS architectures with hierarchical control plane structure should be properly designed. Therefore, we should examine and determine which parameters have significant impact on ASON/GMPLS control plane performance. Because of the complexity of analytical models for optical network architectures, which map all ASON/GMPLS functions, the simulation method is an effective technique for evaluating control plane architecture's performance. Many factors can affect network performance. Because of that, utilization of simulators for performance evaluation and examination VOLUME 9, 2021 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ of dependencies are highly desirable for research purpose.
Conducting evaluations in the simulated environment allow examination of ASON/GMPLS performance, without the need to carry out experiments on the actual or future installed network. Significant work has been completed for simulators of IP/MPLS over ASON/GMPLS networks. The exemplary results for a flat control plane architecture are presented in [7]. Apart from [7], we propose the simulator with the hierarchical ASON/GMPLS approach with a control plane implementation including Resource Reservation Protocol with Traffic Engineering Extensions (RSVP-TE) [8], Diameter protocol [9], Link Management Protocol (LMP) [10] and Open Shortest Path First (OSPF) mechanisms protocols [11]. The functionality and certain general description of the presented simulator without implementation details could be also found in [12], [13]. In [12], we compared the efficiency of flat to hierarchical control plane of ASON/GMPLS structures. In [13], we have examined in a simulation, two resource reservation algorithms to indicate, whether they have significant impact on required quality of service in ASON/GMPLS network with hierarchical control plane structure.
Currently, simulation is the basic tool for researching telecommunications networks due to the complexity of the systems and solved problems for both mobile and stationary users. The examples for the first are Viena Long Term Evolution-Advanced (LTE-A) simulator [14] and MANET Agent-based Simulator for Evaluating communications with MULtimedia (MASEMUL) [15]. Our considerations are focused on the ASON/GMPLS with hierarchical control plane structure networks for stationary users.
Tab. 1 compares the most relevant features of telecommunications network simulators, in the context of this work. The comparison includes ASON/GMPLS simulator presented in the paper, Asons simulator [16], IP/MPLS over ASON/GMPLS simulator [7], Viena LTE-A simulator [14], and MASEMUL [15]. The main advantage of our ASON/GMPLS simulator is its ability to demonstrate and simulate optical hierarchical control plane functionalities with differentiated service quality classes. The presented simulator has a modular design based on compound modules. Due to this, it can be easily expanded in order to examine different resource reservation algorithms, protection and restoration mechanisms, and budget QoS parameters. Just like Asons and IP/MPLS over ASON/GMPLS simulator, it is suitable for simulating core optical control plane network. Apart from Viena Long Term Evolution-Advanced (LTE-A) simulator, which is MATLAB based, ASON/GMPLS does not require a license for certain toolboxes.
In the paper our contributions to development of ASON/GMPLS network architecture are: • design and implementation of ASON/GMPLS network simulator with hierarchical control plane structure in an open-source OMNeT++ environment, • mapping control elements functions and protocols mechanisms in the simulator, • proposition and implementation of communication between hierarchical control plane structures with Diameter protocol and LMP procedures which are not included in general ITU-T recommendations, • presentation simulator capabilities by its simulation results. The paper is organized as follows. The standardization of ASON/GMPLS architecture is presented in section II. Section III is devoted to the structure of the simulator, a recommended call service ASON/GMPLS scenario and a validation process. In section IV, exemplary results for simulation model for Polish structure and simulation model for European structure are presented and discussed. The paper is summarized in section V.

II. ASON/GMPLS HIERARCHICAL ARCHITECTURE
ASON hierarchical control plane standardization, initiated by ITU-T primarily defines the components of the control plane and interactions between these components. The control plane is represented by call control components and connection control components.
The node consists of the Connection Controller (CC), the Routing Controller (RC) and the Link Resource Manager (LRM) for a single level in a routing area hierarchy. View of the status and utilization of resources of the transport plane is provided to the LRM by the Termination and Adaptation Performer (TAP). The Protocol Controller (PC) supports the function of mapping the parameters of the abstract interfaces of the control components into protocol messages. In the case of hierarchical approach, connection controllers are related to one another in a hierarchical manner and could play the role of Network Representant, Domain Representant or Node. General remarks and guidelines for architecture and control plane components are presented in [1], [2], [11], [8]. Additionally, the Internet Engineering Task Force (IETF) has defined the extensions for signaling and routing protocols. The requirements for Generalized MPLS (GMPLS) protocols usage and extensions for ASON can also be found in [17], [18], [19].
Despite the standardization, the recommendations for hierarchical ASON/GMPLS routing are not very detailed. Method of hierarchical QoS routing based on a network resource reservation and algorithms for hierarchical routing could be found in [20], [21]. Multi-domain ASON/GMPLS network operations for hierarchical routing are presented in [22]. Simulators for hierarchical ASON/GMPLS with detailed architecture control plane implementation are not available. Most of the research in this area is focused on hierarchical routing algorithms without implementation details for ASON/GMPLS network. Advancement of the works which have been carried out for control aspects for ASON indicates that ASON/GMPLS hierarchical control plane structure is sufficient for supporting SDN controller [23], [24]. Due to this, the authors propose a simulator for hierarchical control plane performance.
In order to examine functionality of the ASON/GMPLS architecture, the simulator implementation was preceded by the implementation of the functionality of the ASON/GMPLS architecture in the laboratory at Gdansk University of Technology. The results of work within the ASON/GMPLS testbed network are presented in [25]. The solutions implemented in the laboratory testbed were transferred to the simulator to examine their effectiveness for more complex network topologies.

III. ASON/GMPLS SIMULATOR
The simulator models ASON/GMPLS architecture with hierarchical control plane (for signaling messages) and the transport (data) plane. The signaling messages from the control plane are handled by the transport plane consisting of Optical Cross-Connects (OXCs) with Dense Wavelength Division Multiplexing (DWDM) optical links characterized by the physical length and capacity (bandwidth) at each wavelength. The two lowest layers of the Open Systems Interconnection model (OSI model) with no signal parameters -except for bit rate, message transmission time, including the Ethernet frame header and propagation delay -are simulated in the transport layer.
In the control plane, all higher layers of the OSI model resulting from the handling of ASON/GMPLS architecture protocols together with their header lengths, are simulated taking into account their impact on transmission time. At the top of the stack, are the applications responsible for control of the call service and scenarios.
The ASON/GMPLS simulator is realized in OMNeT++ environment, which is an object-oriented modular discrete event network simulation framework developed by András Varga [26].
The architecture of OMNeT++ simulations with ASON/GMPLS functional blocks is presented in Fig. 1. The blocks in grey represent the OMNeT++ environment components as follows [27]: • simulation kernel and class library (SIM), • Model Component Library with simple module definitions, their C++ implementations, compound modules types, channels, queues and messages types, • library with code common to all user interfaces (ENVIR), • envir-based libraries that contain specific user interface implementations (Cmdenv, Tkenv, Qtenv). The ASON/GMPLS simulator consists of six main functional blocks: control plane, transport plane, call generation, topology and resource configuration, initial configuration, measurements which are integrated in OMNeT++ executable architecture. An implementation case for European network divided into three domains (represented as blue, green and pink nodes) based on ASON/GMPLS simulator is presented in Fig. 2.
The control plane consists of functional elements for call and connection functions. Call control functions are represented by Calling/Called Party Controllers (CCC1, CCC2), a Network Call Controller (NCC) and additional element an ids, which is responsible for call identifier assignment and call release generation.
In the simulator the connection control functions are performed by nodes named as Control Elements (CEs).
Each Control Element consists of the Connection Controller (CC), the Routing Controller (RC) and the Link Resource Manager (LRM). The Termination and Adaptation Performer (TAP) function and interaction with the LRM is provided in lrm module. The RC functions and its interaction with CC are provided in cc module. Each CE provides an interface to OXC configuration and PC functions. The number of the CE is equal to the number of nodes. The example of CE structure for European network is presented in Fig. 3.
In hierarchical control plane, the hierarchy Connection Controller could play the role of CE Network Representant, CE Domain Representant or CE Node.   The CE Network Representant and CE Domain Representant are related to one another in a hierarchical manner. Due to this each domain routing area has its own Connection Controller (CC) that has knowledge of the topology of its routing area but has no knowledge of the topology of routing areas above or below itself in the hierarchy, or other routing areas at the same level in the hierarchy. On each level of hierarchy configurations for LRM and RC are different according to ITU-T recommendations.
The transport plane block simulates Optical Cross-Connects (OXCs) operations. A value of blocking probability is assumed for each OXC block. Signaling is performed on a separate wavelength. The resource allocation takes into consideration Routing and Wavelength Assignment problem (RWA) and connection control functions are performed in order to supply a wavelength continuity constraint condition.
Call generation is performed by generators module with default Mersenne Twister RNG (MT) presented in Fig. 2 as Generator_high_1, Generator_high_2, Generator_low_1, Generator_low_2. The call requests are generated according to request distribution defined in configuration file named as omnetpp.ini and request matrix in module CCC1 and CCC2 for low and high priority requests.
Topology and resource configuration is performed based on dedicated additional scripts in Python language for SNDlib [28] native format which generate network structure description (as .ned file) and Link Resource Manager configuration. It gives the model a great flexibility in regards to different network structures examination.
An initial configuration is additionally implemented in omnetpp.ini file (detailed and presented in further part of the section), where CE Network Representant, CE Domain Representants or CE Nodes for each domain are established. The ASON/GMPLS simulator enables different inter-domain configurations.
Functional block measurement is performed in the ids module and NCC controller. Call and connection times are calculated based on results recorded by ids. Loss probabilities are calculated based on results recorded by the NCC. Call control functions concerned with call processing and connection control functions are responsible for set-up and release connections in the transport plane. The call control plane is not aware of transport plane topology and separation for call control addresses and connection control addresses is introduced.
Optical resource reservation in the connection control plane is performed with the Resource Reservation Protocol -Traffic Engineering (RSVP-TE) and standardized RSVP-TE messages [8]. The communication between Network Representant and Domain Representants, and Domain Representants and CE Nodes is realized with the use of Diameter protocol [9]. Routing functions are implemented with Open Shortest Path First -Traffic Engineering (OSPF-TE) based on routing protocol mechanisms [11].
Each functional element on each output port has a separate service queue system in the simulator, with the infinite First In First Out queue (FIFO). Messages' sending time depends on the size of the message and signaling link capacity.
In the simulation system we can distinguish groups of components: files with functional elements implementation in C++ code, message definitions, an initial configuration file and a file with a network structure.
The implementation of functional elements of control plane and transport plane is performed in C++ files with.h/.cc suffixes. Call control elements and connection control elements are defined as cSimpleModules and combined in hierarchical manner. Each C++ file containing the implementation of the functionality of the model element has an identical structure in which we can distinguish: class definition, initialization function, handleMessage() function and finish() function (optional). The handleMessage() function is called for every message that arrives at the module. The finish() function is called, when simulation results are put into file via output vector and output scalars. Output vectors are time series data, recorded from simple modules, while output scalars are summary results, computed during the simulation and written out when the simulation completes.
In the presented simulator functionality of the RC and the TAP are implemented in cc.cc file and lrm.cc file. Messages are introduced in the simulator as.msg files with defined message type and data fields. The omnetpp.ini configuration file contains settings that control how the simulation is executed and values for model parameters.
When simulation program is built, the messages files are translated into C++ code using the opp_msgc program. Then all C++ sources are compiled and linked with the simulation kernel and a user interface library to form a simulation executable library. The .ned files are loaded dynamically in their original text forms when the simulation program starts. After simulation, the results are recorded in separate.sca and.vci files and analyzed by using dedicated scripts written in Python language.

A. MESSAGE FLOW FOR CALL SET-UP REQUEST
The ASON/GMPLS simulator provides call set-up, connection set-up, call-release, connection-release scenarios VOLUME 9, 2021 in accordance with standardization recommendation for ASON/GMPLS network.
Due to the sheer size of conducted research, we have decided to focus in the paper only a successful call set-up scenario performed in accordance with standardization recommendation for ASON/GMPLS network. The message flow and Label Switching Path (LSP) establishment are presented in Fig. 4 and Fig. 5  Representant. Corresponding RSVP-TE and Diameter messages are sent in Domain 2.

8) After receiving confirmation messages from Domains'
Representants, the Network Representant sends connection_confirmed message to NCC. 9) NCC informs the initiating CCC1 about the termination of the request by sending call_confirmed with the given CallId. Successfully establishment of LSP connection path is finalized with an appropriate call_confirmed message, which is sent to the ids module.
The process of call release is invoked when the ids module send busycallid message and is not presented in the paper.
The Link Management Protocol (LMP) mechanisms are also provided in the simulator. Remote and local identifiers are mapped according to the Link Property Correlation procedure [10]. The examples of simulation results performed in the presented simulator are provided in the next section.
The simulator was examined in accordance with the recommendations. Verification and validation were conducted during the development of the simulator. Performed verification process confirmed that control plane scenarios are correctly implemented and are compliant with ASON/GMPLS specifications.

IV. SIMULATION RESULTS
In this section we demonstrate expanded simulation results to illustrate the variety of simulations options and the simulator capabilities for different datasets and network structures. Using the simulator many sets of input variables can be changed. Amongst them are traffic source parameters, network structures and resource reservation algorithms.
We are capable of examining the impact of various factors on processing time and loss probabilities.
We performed simulations with the use of simulation models for Polish and European structures. Both are based on Survivable Network Design Library (SNDlib) [28]. The Polish and European structures consist of respectively 12 and 28 nodes. Each structure has been divided into three VOLUME 9, 2021 level hierarchies with pool resource reservation algorithm approach presented in [29].
The simulations were performed with the following parameters: • exponential distribution of call request, exponential distribution of connection release requests, • mean connection duration time (E(t)): 2 minutes, 5 minutes, 15 minutes, • the percentage of all generated requests (λ c ) for high priority (Ph):10%, 20%, • inter-domain traffic (MD):20%, 30%, • the percentage of resources on each link for protected pool for high priority requests (Pz):20%, 40%, • blocking probability of OXC: 0.001, • signaling link capacity:1Gb/s, • wavelength capacity:1Gb/s, • capacity of single connection requests in bandwidth units:1BU = 5Mb/s, 2BU = 10Mb/s, 3BU = 15Mb/s. In the simulation model, the resources are divided into two sets: a protected resources pool for high priority connection requests (Pz = 20% or Pz = 40%) and a common pool for low and high priority requests. The protected pool is used, if it is not possible to service high priority request using the common pool.
The total simulation time was 3600s with warm-up period 200s. The number of measurement intervals was 5. Obtained results (5 measurements intervals) were estimated using t-Student distribution with a confidence level equals 0.95.
We evaluate mean values of call and connections times: Call Set-up Time E(CallST) which is defined as the time from sending call_request (t1) up to call_confirmed (t4), mean Connection Set-up Time E(CST) which is defined as the time from sending connection_request (t2) up to connection_confirmed (t3) (Fig. 5), mean Call Release Time E(CallRT) which is defined as the time from sending call_release up to release_confirmed and mean Connection Release Time E(CRT) which is defined as connection_release up to connection_release_confirmed (here not presented in Fig. 5).
Additionally, we examine loss probability for low priority requests (B 0 ) defined as the ratio between the number of low lost priority requests and the total number of generated low priority requests and loss probability for high priority requests (B 1 ) defined as the ratio between the number of high lost priority requests and the total number of generated high priority requests. Moreover, we evaluate loss probability for inter-domain connections requests (B MD ) calculated for low and high priority connection requests as a ratio between lost low/high priority inter-domain connection requests and the total number of low/high priority inter-domain connection requests. The obtained results are presented in Fig. 6 -Fig. 12 for Polish structure and in Fig. 13 -Fig. 19 for European structure.
Other performance parameters that can be obtained by the simulator are E(CallST) for unsuccessful and successful call set-up request, E(CST) for unsuccessful and successful connection set-up request. Additionally, we can examine loss probability for low priority requests (B 0, ) and high priority request (B 1 ) with distinction between the possible reasons of loss (lack of resources, blockade of OXC). The same approach is done for (B SD ) and (B MD ). The list of the parameters could be expanded. Depending on the collected results, it is possible to measure not only the response times of individual functional modules, but e.g. the probability of service request loss, connection at the level of the entire network or domain (operator). Due to the fact that simulations results are collected and processed off-line, the user can prepare external scripts e. g. in Python language and analyze data according to needs.  The mean values of call/connections times for the same E(t) are smaller for low priority requests compared to high priority requests. For requests intensity greater than 33 requests per second E(CallST) and E(CST) are slightly smaller for low priority requests than for high priority requests. Detailed analysis of the length of connection paths indicated that for low priority requests connections paths are shorter than for high ones for values of requests intensities higher than 33 requests per second.
In Fig. 7  In our research we take into consideration the offered traffic to the transport plane (A 0 ) and the offered traffic per inter-domain link (a 0 ) which are calculated as follows: where: λ c -total intensity request per second, E(t) -mean connection duration time, Our research indicated that for higher intensities we obtained higher loss probabilities for low priority requests. Comparing E(CallST) and E(CST) for E(t) = 2 minutes versus loss probabilities for Ph = 10% and Pz = 20% (Fig. 8) we noticed that loss probabilities for low priority requests differ significantly from high priority requests. For offered traffic to the transport plane A 0 = 56679 Erl and Ph = 10% loss probability for high priority requests equals 0.0027 while for low priority requests equals 0.24. For E(t)= 5 minutes, Ph = 10% and Pz = 20% for offered traffic to the transport plane A 0 = 90348 Erl loss probability for high priority requests equals 0.0087 Erl while for low priority requests equals 0.45. As depicted in Fig. 8 and Fig. 9 for the same resource allocation (Pz = 20%) loss probability for Ph = 20% does not differ significantly from results obtained for Ph = 10% for low priority requests. Confidence intervals of loss probabilities for low priority requests overlap as well as for E(t) equals 2 minutes and E(t) equals 5 minutes. High priority requests probability differences are significant and B 1 equals 0.076 for A 0 = 90348 Erl, Pz = 20%, Ph = 20% while for A 0 = 90348 Erl, Pz = 20%, Ph = 10%, B 1 equals 0.0087. As expected, the change of resource allocation for high priority requests from Pz = 20% to Pz = 40% decreases loss probabilities for high priority requests and provides to increase probabilities for low priority requests.  Based on simulation results loss probabilities for interdomain connections (B MD ) with a distinction between high and low priority requests are determined and presented in Fig. 10 and Fig. 11 for inter-domain traffic 20% and Ph = 10% and Ph = 20%. In condition of Ph = 10% loss probabilities for high priority requests are smaller than for Ph = 20% for the same value of offered traffic per inter-domain link.  Performed research for Polish structure for MD = 20% and MD = 30% are presented in Fig. 12. In this case MD has impact on loss probability for low and high priority requests and leads to loss probability increase for low and high priority.
Taking under consideration the European structure we can notice that the mean Call Set-up Time E(CallST) does not exceed 35.5 milliseconds while the mean Connection Set-up Time E(CST) does not exceed 31 milliseconds (Fig. 13). The mean values of call/connections times for the same E(t) are smaller for low priority requests compared to high priority requests.
For requests intensity higher than 33 requests per second E(CallST) and E(CST) are slightly smaller for low priority requests than for high priority requests for the same reason as for Polish structure.
In Fig. 14  For offered traffic to the transport plane A 0 = 56679 Erl and Ph = 10% and Pz = 20% loss probability for high priority requests equals 0.0025 while for low priority requests equals 0.15. For E(t) = 5 minutes, Ph = 10% for offered traffic to the transport plane A 0 = 90348 Erl loss probability for high   priority requests equals 0.0047 while for low priority requests equals 0.3.
As depicted in Fig. 15 and Fig. 16. for the same resource allocation (Pz = 20%) loss probabilities for Ph = 20% do not differ significantly from results obtain for Ph = 10% for low priority requests. Confidence intervals of loss probabilities for low priority requests overlap as well as for E(t) equals 2 minutes and E(t) equals 5 minutes.
Loss probability presented in Fig. 15 and Fig. 16 for low priority requests differs significantly from high priority requests.   The change of resource allocation for low priority requests from Pz = 20% to Pz = 40% significantly affects loss probabilities for high priority requests while loss probabilities for low priority requests are higher, so the tendency is the same as in case of Polish structure. Loss probabilities for European structure for inter-domain connections (B MD ) with a distinction between high and low priority requests are determined and presented in Fig. 17 and Fig. 18 for inter-domain traffic 20%, Ph = 10% and Ph = 20%.
In condition of Ph = 10% for offered traffic smaller than 0.15 Erl loss probability for low priority requests does not exceed 0.1. In compare with Polish structure loss probability lower than 0.1 is obtained up to 0.25 Erl offered traffic per inter-domain link.
Performed research for European structure for MD = 20% and MD = 30% are presented in Fig. 19.
Loss probability for MD = 30% does not differ significantly for loss probabilities for MD = 20%. Confidence intervals of loss probabilities for MD = 20% and MD = 30% overlap for high priority requests as well as for low priority requests.
The presented results for Polish and European structures are in accordance with expectations and can be logically explained. E(CallST), E(CST) for intensities higher than 33 requests per second are longer for high priority requests than for low priority requests. Due to the fact that pool approach was implemented in resource reservation algorithm. Implemented resource algorithm gives more capabilities to supply wavelength continuity constraint condition and loss probability for high priority requests is smaller.

V. CONCLUSION
In the paper we proposed the simulator for performance evaluation of ASON/GMPLS network. The descriptions of functional blocks of ASON/GMPLS simulator and implementation details were presented. We described examples of scenarios and simulations results for Polish and European structures to indicate the complex interrelations in performance evaluation of ASON/GMPLS hierarchical control plane. The variety of results was provided to illustrate simulator capabilities and its usability in ASON/GMPLS network examination. The simulation results were presented to show the versatility and the possibility of easy adjustment to various simulations conditions.
The simulator is suitable for modeling and simulating different ASON/GMPLS network structures with the variety of functionalities which can be easily extended according to the needs. The network operator and researcher can use the simulator in order to evaluate ASON/GMPLS network performance and capabilities. Moreover, the modules of ASON/GMPLS simulator are implemented with the C++ programming language in an open source OMNeT++ environment. This increases the flexibility in extension of the simulator functionality for Next Generation Networks and SDN architecture.
The presented simulator is currently expanding in order to convergent SDN and ASON/GMPLS architectures. ASON/GMPLS and SDN functionality are aimed in the same direction. Many features provided by ASON/GMPLS could be run for cooperation with SDN controller.