An Effective Hierarchical Control Plane for Software-Defined Networks Leveraging TOPSIS for End-to-End QoS Class-Mapping

If an end-to-end (E2E) path includes multiple domains, we need inter-domain collaboration to ensure the E2E quality-of-service (QoS) for the applications. In heterogeneous networks, an E2E path may go through domains with several QoS classes in each domain. However, the prevalent legacy network architecture and the standard software-deﬁned networking (SDN) model lack effective mechanisms for inter-domain collaboration and QoS class mapping. In this study, we propose a hierarchical SDN control plane approach to guarantee the E2E QoS among multiple domains with various QoS classes on the E2E path. We propose a controller module for selecting the most suitable QoS class for each domain in the E2E path based on multi-criteria decision-making by using the technique for order of preference by similarity to ideal solution (TOPSIS). We map the suitable service classes in the global controller (GC) for provisioning the E2E QoS according to the application service requests. First, we propose an SDN-based inter-domain communication scheme and the message processing algorithm for E2E service delivery when multiple QoS classes exist in each domain. Next, we formulate the problem of service class selection with TOPSIS, provide an E2E mapping scheme, and demonstrate it with an example. Finally, we compare the proposed approach with the existing schemes for E2E QoS class mapping in terms of E2E delay, jitter, packet loss rate (PLR), and cost (per bandwidth unit). According to our simulation results, the proposed approach ensures the E2E QoS and guarantees the E2E delay, jitter, PLR, and cost according to the application service requests


I. INTRODUCTION
The rapid developments in Internet technology have resulted in the ubiquitous proliferation of network terminals. However, the traditional network architecture was not adapted to advancements in future communication and Internet technologies, which has resulted in heterogeneous networks. Therefore, the legacy network infrastructure could not maintain a constant pace with radical changes in the Internet. The main feature of the traditional network architecture is that the data and control planes are tightly coupled, which leads to several limitations: for example, if we want to change the configuration of the network, we should configure each device The associate editor coordinating the review of this manuscript and approving it for publication was Yulei Wu .
independently throughout the entire network. Similarly, vendors are hesitant in providing the internal details of their devices to the developers and users, because changes in the configuration of traditional networking devices can lead to a malfunction in the networks. Besides, the protocols are strongly embedded in the firmware of the network devices. These restrictions hamper innovation in the networks due to proprietary hardware and lack of testing for innovative networking solutions. This increases the administrative workload and the overall cost of network management.
On the contrary, the software-defined networking (SDN) paradigm [1]- [3] has revolutionized the management of networks by decoupling data and control planes. The separation of data and control planes has moved the network complexity from networking devices to the intelligent SDN controllers. of the E2E domains, multiple domains must be administered by several controllers, which must collaborate for sharing the underlying network status. Thus, the SDN architecture with a global view of the inter-domain scenario needs to be further explored for ensuring E2E QoS in the presence of multiple service classes. 1 In this study, our motivation is to propose the SDN-based approach for E2E service class mapping with a global control of the QoS metrics, provisioning the E2E services delivery when multiple providers exist on the E2E path. As compared with previous work, the contributions of this study are as follows: • We propose a packet processing algorithm with a hierarchical control plane solution leveraging SDN for inter-domain collaboration and E2E service provisioning for heterogeneous network providers. • We propose a network model for service class selection in the SDN-based heterogeneous network environment by proposing a technique for order of preference by similarity to ideal solution (TOPSIS) module for the SDN controller and a mapping mechanism for QoS classes.
• We perform a demonstration and simulations for the SDN-based approach and compare the results with the previous schemes. Our method improves E2E performance for various performance metrics.
• To check the effectiveness of the proposed approach based on a TOPSIS module, the simulations are also performed for the SDN-based approach by removing the TOPSIS module from it.
• The simulations demonstrate effect of the cost per bandwidth unit on the E2E performance. The remainder of this paper is organized as follows. In Section II, we discuss related work and challenges in the traditional and SDN-based approaches for E2E QoS class-mapping and service provisioning. The proposed SDN-based approach, a packet processing algorithm in the hierarchical control plane, the network model for E2E service class selection, and a step-by-step procedure for class selection and mapping based on the TOPSIS module is discussed in Section III (A)-(E). In Subsection III (F), we demonstrate the proposed approach with an example. Section IV evaluates the results and compares them with previous schemes. In Subsection IV (F), we show the effect of the cost weight on the E2E performance. Moreover, we evaluate the E2E cost (per bandwidth unit) in subsection IV (G) and compare it with previous schemes. Finally, Section V concludes the paper and discusses future work.

II. LITERATURE REVIEW
The E2E QoS provisioning in SDN is significant for seamless communication between the source and destination nodes. Because of a lack of a common northbound application programming interface (NB API), multiple heterogeneous network domains require collaboration, and service classes that exist on the E2E path need mapping to guarantee QoS. Neither of the two mentioned topics is regarded as a trivial issue in the literature. Therefore, in this study, we focus on the inter-domain coordination and QoS class mapping on the E2E path leveraging SDN. In this section, we describe the existing studies that provide different schemes for collaboration among domains and QoS class mapping when multiple providers exist on the E2E path. First, we discuss such schemes and their issues in traditional networks. Then, we describe SDN-based studies.
The inter-domain collaboration on the E2E path is critical because of different QoS architectures in each domain and heterogeneity of the service providers. Previously, the bilateral model [13] was widely followed for QoS negotiation between inter-providers. However, in this model, the service performance negotiation happens only between the neighboring providers with no global view of the E2E domains for service delivery. Consequently, the model is not capable of providing the E2E service provisioning and is not scalable. Furthermore, the mapping of the service classes is a challenging task with respect to meeting the E2E service needs due to the local view of the network state information in the domains.
The QoS in the inter-provider faces many challenges [14]. A comprehensive in-depth analysis of inter-provider issues is given in [13]. Herein, we further investigate various approaches to address these issues. In the heterogeneous networks, the QoS architecture for each domain is different; therefore, the E2E path establishment would be suboptimal. Besides, the E2E path consists of various QoS classes. Therefore, provisioning the QoS on the E2E level is cumbersome for E2E application service requests. Several approaches have been presented owing to the limitations of the bilateral scheme. A solution based on the cooperation model was prevalent for content distributors [15], [16]. However, it does not apply to heterogeneous networks, because the service classes are not globally unique, whereas the applications need an E2E service guarantee. Hence, the QoS class mapping has been explored by several researchers due to its significance for the QoS guarantee on the E2E path passing through multiple domains with several service providers. A generic framework for service specification in [17] provides a description of service classes in network domains. Then, a mapping technique is applied for the selection of the unique E2E service class.
Several approaches exist for inter-domain class mapping on the E2E level in the traditional networking architecture [18]- [20]. In [18], the authors proposed a policy-dependent conformance matching scheme (P-CMS) as an extension of CMS using a third-party (3P) approach. A 3P agent in [21] is partially responsible for monitoring service-level agreements (SLAs) among different domains. The CMS maps the service classes from the source to the destination in heterogeneous domains. However, this approach does not ensure the E2E QoS of the applications and cannot adapt to the changing parameters. Moreover, the P-CMS has no global view of the service metrics and needs a tight collaboration among the domains. Additionally, this solution is not cost-aware because it only considers the technical performance metrics 2 such as delay, jitter, and packet loss rate (PLR).
The problem of service class selection was also formulated using a 3P integer programming (3PIP) approach [19]. A multi-constraint technique for mapping of service classes is introduced. However, it fails when the constraint limitation is not met. The tight collaboration among multiple domains of different providers is critical for QoS provisioning on the E2E path. To achieve this objective, authors in [20] proposed a goal programming (GP) approach deployed on a 3P agent for class mapping. As discussed in [21], the 3P scheme is a significant solution for QoS delivery among different providers. It meets various conflicting goals and constraints. However, the interaction between the domains and the third-party server, as well as the details of the message flows, are not given. Furthermore, it is based on traditional networking architecture and cannot meet certain objectives. Inspired by the 3P agent, its analogy with the central SDN controller, and the wide adoption of SDN in future technologies, we further explore the SDN for E2E service provisioning and QoS class mapping.
A comprehensive survey for inter-domain SDN is presented in [22] which discusses the applications, challenges, and evolution in the inter-domain SDN. First, the study discusses a typical approach to inter-domain communication mechanisms such as a West-East Bridge (WE-Bridge) i.e. a proposal made by Tsinghua University for inter-domain communication in SDN. Then, a mechanism is described for the establishment of connections, exchange of information, message format, the process of negotiation and the virtual network view in SDN domains. Finally, the applications and challenges are discussed.
A representative study in [23] proposed a framework based on the network as a service (NaaS) for E2E QoS provisioning in SDN. The SDN controllers have no common standard interface for interoperability among controllers of heterogeneous domains. Therefore, a service delivery platform (SDP) is proposed. Further, the scheme illustrates an analytical model for network abstraction and resource assignment. This study emphasizes the bandwidth utilization enhancement for the E2E QoS guarantee. Additionally, the numerical and analytical results show that the scheme simplifies resource management and improves bandwidth utilization considering the E2E QoS provisioning. Similarly, the study in [24] has also proposed the SDN-based approach for enhancing the utilization of network resources. Apart from enhancing the bandwidth utilization, the paper also describes network failure recovery in a multi-domain scenario. However, these studies failed to consider different QoS classes offered in each domain from the source to the destination on the E2E path.
In literature [25] the E2E QoS in SDN has been investigated while focusing on domain privacy. A privacy-aware framework is proposed in the inter-domain environment where the network statistics are processed in a distributed manner and then a single point collects the QoS request for making a binary decision. Further, to quantify achieved privacy a privacy index metric is proposed in the inter-domain SDN. The results show that the proposed adaptive learning technique provides 1.4x more privacy. However, the study only focus on the privacy for inter-domain SDN frameworks.
The study in [26] provided a resource reservation framework for E2E QoS fulfillment for delay bound applications. Moreover, the significance of E2E QoS in various applications (such as smart grids, healthcare, education, mobility, gaming, and manufacturing) is discussed. Further, the study discusses the mechanism for inter-domain interaction, resource reservation concept, and admission control in SDN. The simulation shows the performance results for controlplane scalability. However, it does not provide any details on QoS service classes and the communication design among the domains. Moreover, the proposed architecture follows the flat structure for inter-domain communication; therefore, it lacks global control over the performance metrics.
The authors in [27] introduced a hierarchical SDN method with the aim to reduce the flow request messages to a controller and improve the control plane scalability. The architecture is scalable irrespective of the number of connections of the network. The hierarchical architecture consists of a broker controller that acts as a coordinator between the lower-level controllers and the QoS-based routing procedure among the autonomous systems. However, the architecture needs further investigation in the case of heterogeneous network providers with multiple service classes on the E2E path from source to destination.
These previous studies were based on the traditional distributed Internet architecture. However, the distributed algorithms use border gateway protocol (BGP) [28], resource reservation protocol (RSVP) [29], and BGP link-state (LS) [30] signaling protocols. However the following political and technical aspects do not recommend the use of BGP and traditional distributing routing protocols.
• The BGP does not consider the resistances existing between the vendors and inter-providers.
• Limited length of BGP policy compliant paths among countries [31].
• The BGP has a slow convergence [32] time because its execution model is local.
• The BGP performs cross-domain routing in a decentralized way without knowledge of E2E paths, fails to provide a globally optimal path intended for E2E QoS provisioning.
• The BGP oscillation is persistent. Therefore, it does not guarantee a shortest path [33].
• The literature in [23] argues that BGP is not suitable for inter-domain SDN routing and suggests the decoupling of policy and routing control for interoperability among domains in SDN.
• Additionally, the traditional network vendors do not provide the granularity of device configurations, and the protocols are firmly embedded in the firmware. Therefore, deploying a new service on the E2E level is cumbersome, inflexible, and complex. Moreover, the SDNbased schemes have not described the QoS class-mapping for the E2E QoS guarantee. Further, the architectures are based on the flat structure, which does not describe the global view of the inter-domains for E2E service class mapping.
SDN is considered as the technology for future Internet because of its potential benefits of (1) decoupling the control plane from the data plane (i.e., centralized management) and (2) E2E QoS guarantee according to the diverse demands of different applications. Several studies have explored the first aspect. However, leveraging the SDN paradigm in the multi-domain context with several service providers and the E2E QoS guarantee has not been investigated well, specifically, with the existence of QoS classes on the E2E path. To the best of our knowledge, our proposed SDN-based approach can provide a global view for multiple source-todestination inter-provider domains and perform class mapping on the E2E level.

III. PROPOSED APPROACH
Our first objective is to provide an architecture for collaboration among domains that provides a global view of the E2E network. Therefore, in the first part, we are discussing our proposed architecture, the packet processing algorithm, and modules of the controller for achieving this objective. Second, we aim to select the most suitable 3 service class among a set of service classes on the E2E path and to perform a mapping of these service classes for defining a globally defined class for an E2E service provisioning. The following subsections illustrate this in detail.

A. ARCHITECTURE FOR E2E SERVICE DELIVERY
The inter-domain environment is a complex network with various components. Therefore, a suitable network model having provision for state-of-the-art technology and well-defined functional units is needed for its management, control, and design. The proposed architecture for E2E SLAs between different service providers is based on SDN. Our proposed architecture leverages the deployment of the centralized modules, deployment of new applications, and flexible interaction between forwarding devices and the SDN controller through southbound (SB) API.
Herein, we recall two types of multi-controller architectures to apply our TOPSIS module for computing the unique E2E QoS class in the presence of inter-domain heterogeneous providers. We call them the flat controller architecture (FCA) and the hierarchical controller architecture,  as shown in Figures 1 and 2, respectively. We investigated these two controller architectures for E2E service class mapping. In the FCA, the local domain controllers (LDCs) interact in a peer-to-peer (P2P) manner. However, FCA has three main problems. First, the scalability is limited as the network size grows; it worsens the processing latency of the controller [34]. Second, the lack of a common NB API restricts the interoperability among multiple vendors of controllers [23]. Third, there is no architecture to find global E2E unique service class calculation due to P2P collaboration among the domains. Further in HCA the traffic to the controller reduces 50% than the FCA [27].
Our proposed approach is based on SDN. Hence, it overcomes the issues in the BGP and the traditional distributing protocols such as the proprietry hardware, inter-operability, centralized managment which ensures the shortest path, cross-domain routing in a centralized manner and mainly the innovation in testing new technologies. Further, our proposed method leverages hierarchical architecture [35]- [37]. The hierarchical architecture of SDN controllers integrates autonomous domains with a hierarchical association. Multiple domains are integrated with a hierarchical controller architecture, where LDCs coordinate through a GC. By applying the hierarchical architecture, new services can be easily managed and deployed in the domains coexisting on the E2E path between the source and the destination [38] nodes.
The tasks handled by a controller are propagated from lower layer LDCs to the upper layer GC which decreases the computational complexity. The hierarchy control plane with a global view decreases the E2E delay as the network scales [39]. The GC in the proposed architecture acts proactively for the establishment of the E2E path, therefore, the flow setup delay (the delay for path establishment and pushing the flow entries into the switches) [40] is reduced. The hierarchical architecture enables communication among multiple LDCs with assorted equipment. The effectiveness of the hierarchical control plane for effective collaboration among heterogeneous tactical networks with a guaranteed QoS has been proved in [41].
The proposed architecture is shown in Figure 2. There are LDCs and a GC. The switches in the domains are connected with LDCs on the E2E path. The GC obtains the underlying network status dynamically from the LDCs administering the domains; consequently, it has access to the global topology. Thus, the GC provisions resources from the LDCs upon the arrival of a service request. The LDCs collaborate through GC, and SLAs are exchanged through it. Each LDC is equipped with a traffic flow template (TFT) module [42], which gathers the source and destination port numbers, Internet Protocol (IP) addresses, and QoS parameters. The collected data will be used by the E2E path computation (PCM) [43] and TOPSIS modules to find the E2E path and the ideal service class among a set of service classes on the E2E path. Finally, a GC will find the globally unique service class for an E2E service provisioning. Figure 3 shows different modules for gathering network status, inter-domain collaboration, E2E path computation, and QoS class mapping. Each LDC runs a TFT module to obtain the service requests from the domains through its SB API protocol, i.e., OpenFlow [6], a PCM to compute a path, and a TOPSIS module to select a QoS class in the E2E path. The GC proactively gathers the path and service class information and configure the rest of LDCs. Thus, GC finds the E2E path and unique E2E service class. On the arrival of a new packet, the GC maps the global service class from the source to the destination on the E2E path from the service classes computed by the TOPSIS modules of each LDC. The E2E SLAs across multiple domains is provided by the GC. which forwards it to (GC). 6: The (GC) proactively calculates the E2E path (P i ) and

B. PACKET PROCESSING ALGORITHM
QoS class (C i ) using PCM and TOPSIS modules from the rest of LDCs. 7: The (GC) performs the mapping according to the (NPH ) service requests. 8: Once, the (GC) mapping is completed, the (GC) returns the (P i ) and E2E unique service class and pushes the (FR) to the (S 1 ) of the outermost domain as a Packet − Out (POUT ) message via the (LDCs). 9: The (FR) gets updated in the ingress switch (S 1 − CBMQs). 10: Else 11: The (NPH ) matches the (FR) on (S 1 − CBMQs) of the outermost domain, then 12: The (EFR) in the (S 1 − CBMQs) are followed for forwarding the (NP).
Algorithm 1 demonstrates the packet processing in the hierarchical architecture upon the arrival of the new packet (NP). When the (NP) arrives on the ingress switch (S 1 ) of the outermost domain, the new packet header (NPH ) is compared with the flow rules (FR) in the switch (S 1 ) class-based mapping queues (CBMQs) i.e. (S 1 − CBMQs). The (FR) for the service classes and the mapping information is implemented as the (CBMQs) in the SDN switches [44]. If the (FR) on the (S 1 − CBMQs) does not match with the (NPH ), then, a Packet − In (PIN ) message is sent to the (LDC). The LDC forwards the request to the (GC). In the meanwhile, the (GC) proactively configures the E2E path (P i ) using PCM module and QoS classes (C i ) leveraging TOPSIS modules from the LDCs. In each LDC (k), the TFT module gathers the source and destination IP addresses, port numbers, and QoS requests via the SB API protocol which is utilized by the TOPSIS module. As the (GC) has a global view of the whole network and QoS classes from the TOPSIS modules, it maps it per application service requests for the E2E path (P i ). The mapping is performed with the (CBMQs) on the switches, where the (FR) for the service classes are defined. Further, Equation (11) and Equation (12) shows how the service classes are mapped and computed for the (P i ). On completion of the mapping, the (GC) returns the (P i ) and E2E unique service class to the ingress switch (S 1 ) of the outermost domain as a Packet − Out (POUT ) message via the (LDCs). The (FR) are updated on the (S 1 − CBMQs). On the contrary, if the (NPH ) matches the (FR) on the (S 1 − CBMQs) of the outermost domain, then, the (NP) is forwarded according to the existing flow rules (EFR) of the (S 1 − CBMQs).

C. NETWORK MODEL FOR E2E SERVICE CLASS SELECTION
In this section, we describe how to select the ideal QoS class in each LDC on the E2E path with the proposed SDN architecture. A QoS class is defined as a collection of performance parameters such as delay, jitter, PLR, and cost on the E2E path in a domain with multiple inter-providers. Herein, the cost refers to cumulative costs for traffic management in terms of generation, sending, and termination. Several classes consider different QoS metrics such as delay, jitter, PLR, and cost from several providers. Therefore, QoS class selection on the E2E path can be modeled as a multi-criteria decision making (MCDM) problem. The following key problems need to be solved. First, we need to compute the most desirable QoS classes on the E2E path passing through each LDC. Second, we need to find a globally defined service class for the whole E2E path.
An SDN is represented as  Table 1.

D. TOPSIS MODULE
TOPSIS is a multi-criteria decision-making (MCDM) scheme [46], [47] widely used in diverse fields [48]- [50] for MCDM problems. The effectiveness of the TOPSIS over other approaches is due to; • Its programmable and logical behavior; • Suitability in handling wide range of criteria and alternative metrics; • Comparative consistency in ranking alternatives; • Its ability in dealing with constrained subjective inputs [51], [52] and • We can prioritize the preferences of the network users through assigning weights to the performance metrics. VOLUME 8, 2020 The effective use of TOPSIS in heterogeneous networks has been described in [53]. Herein, we will introduce TOPSIS as an SDN controller module in the LDC for service class selection in a domain. There are two ideal solutions proposed by this technique: positive and negative. The most and least desirable service classes for a given domain in the E2E path are selected by the positive and negative ideal solutions, respectively. Using a TOPSIS module, the LDC selects the most desirable service class that has a minimum distance from the positive and maximum distance from the negative ideal solutions, respectively. The selected service classes through the TOPSIS module employed on the LDC will be used by the GC for the unique E2E service class computation on the E2E path. Let us describe a step-by-step approach for applying TOPSIS in an LDC. A decision matrix Q k representing the alternatives (QoS classes) and criteria (QoS performance metrics) is formed for a domain administered by LDC k in the E2E path. The general form of the decision matrix is given in (1). The service classes are represented by i = 1 to i = m and the QoS metrics are denoted by j = 1 to j = n. Herein, j = 1, j = 2, j = 3, and j = 4 denote the delay, jitter, PLR, and cost. We are using the words ''QoS metric'' and ''QoS performance metric'' interchangeably. The row values show the service metric values for a QoS class of LDC k. Next, q (i,j) is the value of the service metric in the LDC k corresponding to the i th service class and j th QoS parameter. 11 q 12 q 13 · · · q 1n q 21 q 22 q 23 · · · q 2n q 31 q 32 q 33 · · · q 3n . . . . . . . . . . . . . . .
The decision matrix is normalized by (2) using the Euclidean normalization [54]. A normalized matrix R k is obtained for LDC k, where r ij is the normalized value of the service metric corresponding to the i th row and j th column. These normalized values are computed for i = 1, 2, 3, . . . , m service classes and j = 1, 2, 3, . . . , n service metrics.
r 12 r 13 · · · r 1n r 21 r 22 r 23 · · · r 2n r 31 r 32 Next, the normalized matrix is converted into a weighted decision matrix F k by (4). Each value f ij in this matrix is calculated by (5). Here, W i denotes a weight factor for the service metric in a QoS class.
Then, we compute the positive and negative ideal solutions for the QoS classes of LDC k. Equations (6) and (7) show the positive (A * j,k ) and negative (A − j,k ) ideal solutions for the QoS classes in domain k on the E2E path. Here, J 1 and J 2 are the benefit and cost metrics in the E2E QoS classes. These equations show our objective functions: to maximize the benefit QoS metrics and minimize the cost performance metrics in a service class on the E2E path. In our case, we aim to minimize the following performance metrics on the E2E path passing from the source domain to the destination domain: delay, jitter, cost, and PLR. Hence, a smaller value for these performance metrics will be selected in the service classes.
The similarity index is calculated by (8) and (9) toward the positive and negative ideal solutions. These equations quantify the Euclidean distance (ED) from the positive ideal and negative ideal service classes (i.e., the most and least desirable QoS classes). Variables (D * i,k ) and (D − i,k ) show the best and worse values, respectively, of the E2E service computed by the TOPSIS module deployed in LDC k.
Finally, we obtain weights of the candidate alternatives (QoS classes) using (10) by the TOPSIS module in LDC k. Furthermore, these alternatives are ranked according to their final weights obtained using (10). The alternative with the highest weight is selected by LDC k as the ideal service class for the domain in the E2E path.
Thus, the service classes with the highest weight would be selected from each domain d by the TOPSIS modules of each LDC in the E2E path. These values are shared with the GC. The GC has a global view of the service classes from all LDCs. Thus, GC computes the unique service class for the whole E2E path. Further, it performs a mapping of these service classes per application service requests.

E. GLOBAL E2E SERVICE CLASS MAPPING
The GC checks for the degree of correspondence (DC) [55] ratio of the offered and required service classes for an application service request (i.e., whether the service classes offered in the domains on the E2E path meet the service requirements of an application). Therefore, a global view of the E2E QoS service classes is shared with the LDCs. Each LDC updates the information for the forwarding devices of the corresponding domain. To verify whether the E2E QoS classes satisfy the service requirements of an application, we calculate the E2E DC E2E ratio. The formula for calculating DC E2E is shown in (11). In this equation, AS j,req and AS j,off represent the required and the offered service class values on the E2E path passing from the source domain to the destination domain for a service metric j.
The DC E2E j ratio denotes whether the offered service classes on the E2E path computed by the TOPSIS module guarantee the service class requests of an application for a service metric j. For example, DC E2E j=1 = 1 means that the ratio of the QoS class requested by an application has a perfect match with the QoS classes offered in each domain on the E2E path for the performance metric delay. Herein, j = 1, 2, 3, 4 are the performance metrics of delay, jitter, PLR, and cost, respectively. If DC E2E j >1, it indicates that the offered service classes (AS j,off ) provide better service class values than the service class values required for an application (AS j,req ). In contrast, if DC E2E j < 1, the offered service classes in the E2E path returned by the TOPSIS modules from E2E LDCs do not satisfy the required service class requests for an application.
Assume that the E2E domains are managed by n LDCs such that K = {k 1 , k 2 , k 3 , . . . , k n }. The offered service classes on the E2E path are summed by (12). We introduce two binary variables: u k n = {1, 0} for a domain n under LDC k on the path and y k i = {1, 0} for class selection in a domain i.e., u k n = {1} if a domain n in the E2E path is selected under LDC k and y k i = {1} if a service class i is selected by LDC k in a domain; otherwise, y k i = {0}. Let S k j,i be the value of performance metric j in LDC k for a service class i computed by the TOPSIS module. Then, AS j,off will be determined by the application according to its service requirements.

F. DEMONSTRATION OF THE PROPOSED APPROACH
In this section, we demonstrate the proposed approach for QoS class mapping. Figure 4 shows an E2E view of five domains with five LDCs and a GC.  Tables 2 and 3 show the E2E the service requests and the service classes offered on the E2E path in five domains. Specifically, Table 3 shows the offered service class values in each domain on the E2E path, which are taken from the specifications in [19]. Herein, the cost is represented in monetary units (MU), which is the cost for the bandwidth transfer unit within the domain. Table 2 shows the service requests for the E2E path. These QoS values have been adopted from the standard requirements for the service requests [56].  Each LDC has a TOPSIS module that finds a service class among a set of service classes. The service classes for d 1 on the path are available to LDC (k 1 ) through the TFT module using SB API protocol. The service classes are shown in (13) as a matrix, where each row represents the QoS classes on the path in a domain for a performance metric. We form a decision matrix according to (1). The result is shown in (13) by adding the values for d 1 from Table 3. Next, we apply Euclidean normalization to (13) using (3), as discussed in the section about the TOPSIS module. The result is shown in (14). Further, we use (5) to assign weights to the QoS metrics of a service class. Initially, we assign the default weights (equal to 1) to these service metrics, as shown in (15) and (16). As we do not change the weights initially, the result of (5) will not alter the values of the service metrics of (14).
Next, we calculate positive and negative ideal solutions for the service classes by (6) and (7). Moreover, we find the deviation from the positive and negative ideal solutions of the service classes by (8) and (9). Table 4 shows the results. Finally, we obtain the deviation from the positive and negative ideal service classes by taking the square root of the summation, as shown in Table 5. Table 6 shows the priority of the service classes that are obtained by (10). The highest weight indicates the ideal service class for the domain. From the weights, we can see that the priority of the classes is C 1 > C 3 > C 2 . Therefore, C 1 will be the desirable service class, followed by C 3 and C 2 . Further, we calculate ideal classes (i.e., classes with a high priority) for other domains (i.e., d 2 , d 3 , d 4 , and d 5 ) by the LDCs k = 2, k = 3, k = 4, and k = 5 on the E2E path using similar steps.  The LDCs share the high-ideal service classes computed by the LDCs with the GC. Hence, the GC has the ideal QoS class for each domain on the E2E path. For example, the E2E values for the delay in these high-priority classes passing through k 1 , k = 2, k = 3, k = 4, and k = 5 are 40, 50, 15, 0, and 45. The GC obtains the ideal service class from each domain, which is mapped with the service requirement by (11) and (12). The E2E service classes are computed and compared using the DC E2E ratio. Equations (17), (18), and (19) calculate the DC E2E ratio for j = 1, j = 2, and j = 3. The ideal service class values for jitter and PLR are calculated using similar procedure as we did for the delay. Finally, the flow rules for the unique E2E service class are pushed to the underlying network devices. In (17)- (19), the numerator shows the service request value required for the application from Table 2 of application service request 1. The denominator depicts the offered service calculated on the E2E path by the GC from the TOPSIS module and mapping. Equation (17) shows the service conformance ratio for E2E delay, where the DC E2E j=1 = 1 shows the perfect match; therefore, the offered service class guarantees the E2E delay. Equation (18) shows that the DC E2E j=2 ratio for jitter is 1.33, which means that the offered service is better than the required service. The DC E2E j=3 for PLR is 1.11, as shown in (19). The PLR exponential values are first normalized according to the logarithmic scale and then the DC E2E j ratio is computed. Next, to check the influence of the weight on the DC E2E j ratio of each performance metric j, we have changed the weight of the delay metric to 5 (i.e., W = 5) from the default value of 1. The service classes and values of the performance metrics of (13) were used for observing the impact of weight. Equation (20) shows the change in weight. The resulting weighted values are shown in Table 7. Then, positive and negative ideal service classes are determined, and the ED is calculated (as shown in Table 8 and Table 9) according to the new weight. Further, Table 10 shows the deviation from the positive and negative service classes and the final weights of the service classes according to the new weight. Table 10 shows that the priority of alternative classes changes to C 1 > C 2 > C 3 from C 1 > C 3 > C 2 with changing the weight. The ranking of the service classes changes with increasing the weight value.   Next, to check whether the new weight influences the E2E performance, the DC E2E j=1 ratio is found by (21). The DC E2E j=1 ratio for the increased weight changes to DC E2E j=1 = 1.25 from 1, i.e., the offered delay service for the application further reduces with DC E2E j=1 > 1. Initially the DC E2E j=1 = 1 for the W = 1 shows the E2E delay is equal to the requested value of the application, i.e., 150 milliseconds (ms). However, when the weight is increased to W = 5, the offered service class values further improve, and the E2E delay becomes smaller, i.e., 120 ms as compared with 150 ms.

IV. SIMULATION RESULTS AND DISCUSSION
Results for the proposed approach are compared with existing ones, such as P-CMS [18], 3PIP [19], and GP [20]. The E2E path consists of five LDCs (k 1 , k 2 , k 3 , k 4 , and k 5 ). Delay, jitter, PLR, and cost (per bandwidth unit) are the main QoS service class parameters in each domain. The SDN network with 50 nodes created in Mininet [57] is divided into 5 domains and the controllers are placed according to the placement defined in [45]. Thus, the total number of domains is 5 and the number of nodes assigned to each controller are 5 to 20 [58]. Each domain is administered by one LDC. We use the Open-Daylight [11] controller for the implementation of the proposed architecture. The nodes in Mininet are connected with OpenDaylight controllers (LDCs and GC) by calling their IP addresses. Both Mininet and OpenDaylight run in virtual machines on a server. The configuration of the server consists of Intel Corei7, 3.4 GHz and 16 GB RAM. The operating system is Linux i.e. Ubuntu 16.04. The TFT, PCM, and TOPSIS modules are loaded as applications on the OpenDaylight controller. For an incoming service request, if the flow rules on the switches do not exist then the request is sent to LDC, which sends it to GC. In each LDC the TFF module obtains the source and destination information, which is used by the E2E path calculation (PCM) and TOPSIS modules. Further, the TOPSIS module finds the ideal QoS class among a set of service classes on the E2E path. A GC proactively configures the resources such as the E2E path, QoS classes and performs mapping. Each service class values for the delay, jitter, and PLR are calculated using the distributed Internet traffic generator (D-ITG) [59]. The cost (per bandwidth unit) is computed from the bandwidth computed with iperf [60]. The mapping is performed by defining flow rules (FR) for the service classes in the CBMQ on the SDN switches.
We compute the DC E2E j ratio for j = 1, j = 2, and j = 3 for five application service requests. The E2E delay, jitter, PLR, and cost are also analyzed by changing the weight of these metrics. Moreover, the DC E2E j ratio is also assessed with a change in the weight for each performance metric j. Moreover, the DC E2E j ratio of the proposed approach is compared with FCA and the proposed scheme without a TOPSIS module (WTM). More and more, we evaluate the E2E delay, VOLUME 8, 2020 jitter, PLR, and cost on the E2E path passing through five domains with the proposed scheme, FCA, and WTM. Finally, we demonstrate the effect of the cost (per bandwidth unit) on the E2E performance according to the customer priorities and compare the E2E cost with GP, 3PIP, and P-CMS.
A. ANALYSIS OF DC E 2E j RATIO Figure 5 compares the results of DC E2E j ratio for the QoS metrics such as delay (j = 1), jitter (j = 2), and PLR (j = 3) of our proposed SDN-based scheme leveraging TOPSIS with P-CMS, 3PIP, and GP. The DC E2E j ratios for the delay, jitter, and PLR are calculated on the E2E path. Because DC E2E j shows a ratio between the required and offered service classes, the values greater than 1 indicate that a scheme is offering a service metric value that is greater than the required value. For example, the delay ratio with the proposed approach is either equal to 1 or it is greater than 1 for all the application service requests. Figure 5 shows that the DC E2E j=1 ratios for the delay (j = 1) with P-CMS are lower than all other schemes. Consequently, E2E application service requests cannot be fulfilled, which is evident from the DC E2E j=1 ratio of P-CMS, which is less than 1 for application service requests 1 and 2. Similarly, the DC E2E j=1 ratio for other schemes are also lower than in the proposed scheme.
Moreover, Figure 5 shows that the DC E2E j ratio for the delay, jitter, and PLR (j = 1, 2, 3) for the SDN-based scheme is greater than other schemes. Figure 5 also shows that the 3P-based schemes such as GP and 3PIP DC E2E j=1 ratio and the proposed approach performs well as their values are either 1 or greater than 1; however, our proposed scheme surpasses the 3P schemes for most application service requests. The reason is that the proposed scheme computes a unique ideal service class for the E2E path in the GC according to the E2E application service requests. For P-CMS, the mapping is performed on the local domain level. Therefore, DC E2E j=1 < 1 for service requests 1 and 2.

B. ANALYSIS OF E2E QoS METRICS WITH CHANGING WEIGHT
In this experiment, we have changed the weights of delay, jitter, PLR, and cost to see the impact on the E2E performance for our proposed scheme. Figure 6 compares E2E values for the QoS metrics (delay, jitter, PLR, and cost) with W = 1 and W = 5. According to Figure 6, if the weight of the delay is changed to 5, the E2E delay (ms) significantly decreases. Likewise, Figures 6(B)-(D) show a decrease in the E2E jitter (ms), PLR, and cost with a change in the weight (W = 5). Moreover, we have used (22) to check the percentage of decrease (PD) of every performance parameter when the weight is increased. Values of each parameter before the increasing weight (PVBIW ) and after increasing weight (PVAIW ) were recorded. The PD is substantial with a change in the weight from 1 to 5 for the E2E delay, jitter, PLR, and cost passing through five domains. The PD for the E2E delay is 33.76% according to this formula. Similarly, the change in weight significantly influences the jitter: the PD in jitter is 71.32%. Likewise, the PD for PLR is 11.76%. For the cost, the PD is 25.11%. The PD in delay, jitter, PLR and cost from (22) shows the effectiveness of the weight factor in the TOPSIS module.  the applications with newly assigned weights. Therefore, we changed the default weights of delay, jitter, and PLR from W = 1 to W = 5 in the proposed scheme and checked the DC E2E j ratio for (j = 1, 2, and 3). Figure 7 compares the DC E2E j ratio with W = 1 and W = 5 for the delay, jitter, and PLR for the application service requests 1, 2, 3, 4, and 5, respectively. According to Figures 7(A)-(C), if the weight of the performance metric is changed, the DC E2E j ratio changes. Figure 7 (A) shows an impact of the higher weight on the performance metric delay; a greater weight means that the resulting DC E2E j=1 ratio is greater than 1: DC E2E j=1 > 1. As a result, we can see a decrease in the E2E delay when passing through five domains. Therefore, the performance of the application will improve because of the lower E2E delay for application service requests, which is obvious from the higher DC E2E j=1 ratio. Consequently, the offered service class values in the domains will guarantee the service requests 1, 2, 3, 4, and 5 for the delay. Similarly, Figure 7(B) and Figure 7(C) show a higher DC E2E j ratio with an increase in weight for j = 2 and j = 3. Therefore, the jitter and PLR on the E2E path will further reduce with the higher weights of these performance metrics.

j RATIO WITH DIFFERENT SDN ARCHITECTURES
To check the effectiveness of the hierarchical SDN architecture equipped with a TOPSIS module (the proposed approach) on the E2E performance metrics, we have computed the DC E2E j for the delay, jitter, and PLR with the proposed method. Then, we repeated the experiment by removing the TOPSIS module from the LDCs, i.e., executing the simulations without a TOPSIS module (WTM) and, finally, in the FCA without the GC and TOPSIS module. Figure 8 compares the DC E2E j for delay (j = 1), jitter (j = 2), and PLR (j = 3) in the three scenarios. According to Figure 8, DC E2E j=1 < 1 for the architecture without the TOPSIS module for some application service requests, because the ideal service classes are not selected in the absence of a TOPSIS module. The FCA DC E2E j=1 < 1 for most service requests, because it lacks a global view and partial inter-domain collaboration, which influence the E2E performance metrics. Similarly, the same effect on the DC E2E j is evident for PLR (j = 2) and jitter (j = 3). Hence, the proposed approach guarantees the E2E QoS service for different application service requests whereas preserving the SDN programma-  bility, flexibility, and weight-adjusting capability for further reducing the E2E delay, jitter, PLR, and cost. Figure 9 compares E2E values for the QoS metrics (delay, jitter, PLR, and cost) with three architectures: the proposed scheme, WTM, and FCA. According to Figure 9, when the TOPSIS module is removed from the LDCs, there is a significant increase in the E2E delay (ms). Likewise, Figures 9 (B)-(D) show an increase in the E2E jitter (ms), PLR, and cost in the absence of a TOPSIS module and GC. Moreover, we have used (23) to check the percentage of increase (PI ) of each QoS metric when the architecture is changed. For each QoS metric, we have recorded its value before any change in the architecture (PVBC) and after the change in the architecture (PVAC). By (23), the PI for E2E delay is 35.78% with WTM compared with our proposed scheme. However, the PI for E2E delay with FCA is substantial (60.23%), because the FCA lacks a global view of the service classes and does not have a TOPSIS module for ideal service class selection on the E2E path. Similarly, the change in the architecture significantly influences the jitter as well, where the PI in jitter is 55.77% for WTM; for FCA, PI jumps to 75.28%. Likewise, the PI for PLR is 55.73% with WTM and, for FCA, the PI in PLR further increases to 92.23%. Finally, the PI reported cost is 7.87% and 14.66% for WTM and FCA architectures, respectively. Hence, according to the results in Figure 9, the hierarchical control plane with a GC and TOPSIS module effectively reduces the E2E delay, jitter, PLR, and cost. (2) if the customer wants a cheaper service, then we assign a high weight to the cost (HWC) i.e. 5, and (3) when the customer wants more cheaper service i.e. very high weight of the cost (VHWC) which is to 10 because after this value the DC E2E j for (j = 1, 2, 3) is negligible. To see the impact of these three priorities, we calculate the DC E2E j ratio for (j = 1, 2, 3) and also calculate the average E2E cost.

E. ANALYSIS OF E2E QoS METRICS WITH DIFFERENT SDN ARCHITECTURES
Figures 10 (A)-(C) shows when the weight of the cost changes then the results of DC E2E j ratio for the delay, jitter, and PLR from the TOPSIS mapping also change. We can see from Figure 10 (A) that when the customer priority for the cost increases. i.e. the customer wants a cheaper service (HWC and VHWC), then a decrease in the DC E2E j=1 ratio of delay is evident from the graph. However, the DC E2E j=1 ratio of the proposed method is still equal to or greater than 1 for all of the service requests. Hence, the QoS is provisioned for the service requests but the delay is a little high for the cheaper services. i.e. with the cost plans of HWC and VHWC. Figures 10 (B)-(C) shows similar trends in the graphs for the DC E2E j ratio of jitter and PLR (j = 2, 3).

G. EVALUATION OF E2E COST (PER BANDWIDTH UNIT)
In this subsection, we evaluate the E2E cost (per bandwidth unit) for DWC, HWC, and VHWC. Further, we compare it with the previous schemes i.e. P-CMS, 3PIP, and GP. Figure 11 shows the average E2E cost for these three scenarios (DWC, HWC, and VHWC) according to the cost priorities of the customer or the cost plans. We can see a decrease in the average E2E cost as the priority of the cost increases for the customer. The cost is more with the default cost plan. However, if the customer compromises on the E2E performance such as delay, jitter, and PLR, then there is a reduction in the E2E cost because we increase the weight of the cost in the TOPSIS module of the SDN controller. Figure 11 shows that  as the weight of the cost increase (VHWC) then the average E2E cost is minimum among the three cost plans. Figure 12 depicts the comparison of the E2E cost for the three cost scenarios (DWC, HWC, and VHWC) with P-CMS, 3PIP, and GP. We can see that the E2E cost is smaller for the proposed scheme. The GC computes the ideal service classes for the E2E path utilizing the TOPSIS module due to which the cost of the proposed solution is small as compared to P-CMS, 3PIP, and GP. We can see that P-CMS has a high cost due to its lack of a global view of the E2E service classes. Moreover, we can see that the E2E cost is small even with increasing the weight of the cost i.e. with HWC and VHWC as compared to other mapping schemes.

V. CONCLUSION
The distributed management and the tight coupling of data and control planes in the traditional networks restrict the global view and control of the network resources. With the emergence of centralized management through SDN technology, the underlying networks are managed globally from the central controller. However, a single controller can lead to a single point of failure and E2E service delivery issues in the presence of multiple providers with varying QoS classes. In this study, we have investigated the applicability of the hierarchical SDN architecture to the E2E service class mapping in a multi-domain environment using a multi-objective decision-making scheme TOPSIS. The concept of hierarchical architecture enables the management and collaboration of autonomous domains on the E2E path for service class mapping. Traditional Internet architecture and prevalent SDN schemes lack an effective QoS class mapping mechanism to guarantee the E2E QoS. In this paper, we first proposed an architecture for E2E collaboration among the autonomous domains with a packet processing algorithm. Next, we provided a TOPSIS-based ideal service class mapping scheme in SDN. Our proposed approach is flexible and adaptable to various technical and non-technical service parameters. A demonstration of the proposed approach was made with standard QoS classes offered in five domains.
The simulation results demonstrate the superiority of the proposed approach for the E2E QoS fulfillment in a multi-domain environment with different QoS classes in each domain. Additionally, the results verify that the degree of correspondence for the proposed approach is 1 or above 1 for most of the application service requests; hence, the offered service is far better than the required service. Furthermore, we analyzed the delay, jitter, PLR, and cost for E2E domains according to different weights allocated to these metrics. The percentage of reduction according to the changing weights and the DC E2E j was investigated for the QoS guarantee according to the service demands of the application. To check the effectiveness of the proposed approach, the PI in delay, jitter, PLR and cost was also compared with FCA and WTM SDN architectures. Finally, we evaluated the cost (per bandwidth unit) and compared it with the previous schemes. In future work, we will investigate the resources utilization in a multi-domain environment. Further, qualitative parameters will also be considered on the E2E path that influences the E2E QoS.