An Optimal Path Computation Architecture for the Cloud-Network on Software-Defined Networking

Abstract

Legacy networks do not open the precise information of the network domain because of scalability, management and commercial reasons, and it is very hard to compute an optimal path to the destination. According to today’s ICT environment change, in order to meet the new network requirements, the concept of software-defined networking (SDN) has been developed as a technological alternative to overcome the limitations of the legacy network structure and to introduce innovative concepts. The purpose of this paper is to propose the application that calculates the optimal paths for general data transmission and real-time audio/video transmission, which consist of the major services of the National Research & Education Network (NREN) in the SDN environment. The proposed SDN routing computation (SRC) application is designed and applied in a multi-domain network for the efficient use of resources, selection of the optimal path between the multi-domains and optimal establishment of end-to-end connections.

1. Introduction

1.1. Background

By expanding demands for mobile communication devices, such as smart phones, tablet PCs and notebook PCs, and increasing use of Internet services, wireless data traffic has grown explosively. Additionally, the situation in the ICT industries, like the convergences of broadcasting and telecommunication industries in cloud computing, machine to machine (M2M) and smart TV, and the convergence of the information and the communication technologies industries is being developed. Demand for technological innovation in the ICT industry has gone through interactions and evolutions and now requires a new ecosystem in the ICT industry [1].

The recent trend introduced to accommodate the new requirements in the ICT environment and to overcome the structural limitations of the existing network is software-defined networking (SDN). The SDNs that emerge as alternatives to the network structure is divided into a few groups—the group that runs large-volume data centers and provides cloud services, such as Google, Yahoo, Facebook, Microsoft and HP, the major network vendor group that supplies network equipment, such as Cisco, Juniper and Alcatel, and the communication service providers that run the communication networks and provide communication services, such as Deutsche Telekom, Verizon and NTT (Nippon Telegraph and Telephone Corporation). These groups are the main players in the SDN field interacting with each other [1,2,3]. These players cooperate to establish technological standards while competing with each other.

The companies and public organizations that have interest in SDN are cooperating to present a substantial and detailed SDN through practice and legal policies. The most representative example is the Open Networking Foundation (ONF) [4], which has been established to set the SDN and the Openflow standards and to promote the adoption of the standards. The fact that the board members of the ONF mostly consist of the users, such as Deutsche Telekom, Facebook, Google, Microsoft, Verizon and Yahoo, and not the network equipment vendors, increases the possibility of the wide adoption of the SDN. Moreover, there are around 100 member companies, including global companies, such as Cisco, Juniper, Brocade, IBM, Dell, HP, VMware and Huawei, and they are exerting their influence to build their own ecosystems.

1.2. Research Objective

At present, there are around 100 National Research and Education Networks (NRENs) currently running, including Internet2 of the USA, GEANT in Europe, SURFnet in the Netherland, NORDUnet in Scandinavia, JGN+ in Japan and AARNET in Australia. IPv6, multicasting-based optical packet hybrid networking, international lambda exchange node and automated inter-domain networking are the technologies that have been greatly developed thanks to the leadership of these NRENs. However, this has been changed by activities that are focused on construction and advancement of interconnected network infrastructure and international cooperation about 3–4 years ago. Internet2 of the USA develops the “innovation platform” that allows for the convergence of network, cloud computing and storage based on NET+ services, the Global Environment for Network Innovation (GENI) and SDN technologies. SURFnet develops SURFconext, and GEANT develops various future Internet testbeds. NORDUnet, JGN+ and AARNET are also shifting their focus from network hardware infrastructure to software-based structure through their own research network platforms in order to develop a hyper convergence service environment for the future.

The legacy network consists of management domains for scalability, management and commercial purposes. The management domain consists of the Interior Gateway Protocol (IGP) and the Border Gateway Protocol (BGP) that connect autonomous systems (AS). Information within the domain is not opened for security purposes. Autonomous systems share path information based on the trust established by the policies, but it is difficult for a certain user to get full end-to-end path information. Due to this reason, it is extremely difficult to calculate the optimal path to the target destination. Moreover, when an error occurs on the path, the path must be searched again, and the optimal path must be found. However, path information sharing is rare. Allocating optimal paths among the networks and providing connectivity to the users at the end of the network are crucial missions of not only commercial network service providers, but also the NREN.

This paper is focused on the NREN and presents an application that calculates optimal paths for data transmission and real-time audio/video transmission, which is one of major issues for the network service providers. The proposed SDN routing computation (SRC) application efficiency is designed in the SDN and applied in the multi-domain network for efficient use of the resources, selection of the optimal path in a multi-domain network and optimal establishment of end-to-end connections.

2. Software-Defined Networking

SDN is a new network architecture in which network control and the data transmission features are separate and programmable. In existing network equipment, both control and data transmission functions exist within a single hardware unit. SDN, however, allows for separation of softwarized control functions in physical or logical computing units. In other words, in SDN, the network control functions can be separately implemented as applications or services.

Figure 1 shows an SDN architecture in which core functions of the network are centered in the SDN controller layer. The service providers and the communication service providers can gain network control independence from network equipment vendors by simplifying the network design, implementation and operation [4,5,6,7,8]. The network operator can easily set the network node through the use of a simple programming method, rather than manually setting each of the numerous distributed units over the cord line.

Moreover, the companies can utilize the centralized functions of the SDN controller to promptly handle network issues and greatly reduce time needed to provide a new network service or application. By centralizing the network control layers, the companies can flexibly and efficiently manage the network, and also, through dynamic and automated programming, companies can optimize network resources and directly develop the application to manage network resources. The SDN architecture provides APIs for the users to implement customized services for certain purposes: switching, routing, network resource allocation, bandwidth management, traffic engineering, system optimization, quality of service (QoS), security, access control lists (ACLs) and policy management [4,6,9,10,11,12].

Figure 1. Software-defined networking (SDN) architecture (source: Open Networking Foundation (ONF)) [4].

Figure 1. Software-defined networking (SDN) architecture (source: Open Networking Foundation (ONF)) [4].

3. SDN-Based Path Management

This section describes the computation of path in multi-domain networks. The path computation element (PCE) is an element that supports calculation of the topology-based network path or route and accommodates the limitations required for the calculation [13,14,15,16].

Most IP-based network traffic engineering solutions operate on a single routing domain. When the path goes out of the routing area from the ingress node to the egress node or out of the AS of the ingress node, these solutions stop operation [17,18]. In these case, the path computation problem entails great complexity, because it is impossible to acquire complete routing information through the network. This is because service providers tend to keep routing information closed for reasons such as the scalability constraints and confidentiality concerns.

By appearance of the multimedia applications through VoIP, video conference, e-commerce and VPN, real-time QoS requirements are highlighted strongly, and the core of these requirements is the capability to set the traffic path based on the explicit path computation through constraint-based routing. The shortest path routing paradigm applied to the legacy network does not support carrying network traffic through explicit paths. The Openflow protocol in SDN, however, can directly handle the data transmission function in network equipment to set the path between two end points. The SDN control layer can leverage topology-aware path computation to cost-effectively enable bandwidth on demand. SDN provides a real-time topological view of the network, enables network virtualization and allows network bandwidth reservation to provide guaranteed performance on a per-connection or flow basis to meet Service Level Agreement (SLA) requirements [19,20,21]. Also SDN provides bandwidth allocation and QoS change on demand in enterprise or cloud provider network by interacting with the network control layer to query network performance and resource availability, as shown in Figure 2 [19].

Figure 2. Bandwidth allocation & QoS change on Demand with northbound API from SDN [19].

Figure 2. Bandwidth allocation & QoS change on Demand with northbound API from SDN [19].

The most important mission, and the purpose in path computation, is to handle the issues related to multi-domain connection settings. In other words, in the PCE, calculating the path in multiple domains is the most important. For multi-domain path computation, three methods are presented.

3.1. Per-Domain Path Computation

The per-domain path computation method starts at the entry point of the domain, as shown in Figure 3. This method progresses within the domain, and a good-enough path is selected for the destination [22].

Figure 3. Per-domain path computation.

Figure 3. Per-domain path computation.

In general, this method progresses on the assumption that connection configurations between the domains are known and uses information, such as IP routing, for selecting the domain exit point. However, this method does not always guarantee the optimized path to the destination.

3.2. Simple Cooperating PCEs

The simple cooperating PCEs method is to find an optimal path between adjacent domains through communication between the PCEs [23].

Figure 4 shows an example of simple cooperating PCEs. When a path computation request arrives from the ingress node of the source, PCE1 does not select the network path using its own domain information alone and sends queries concerning optimal path selection to PCE2 in the neighbor domain. The PCE2 selects the best path in its own domain and responds with the neighboring egress information to PCE1.

Figure 4. Simple cooperating PCEs.

Figure 4. Simple cooperating PCEs.

3.3. Backward Recursive Path Computation

As shown in Figure 5, the backward recursive path computation (BRPC) method is based on the cooperation between the PCEs and provides the optimized network path through cranking back the signaling during computation, even when full visibility is not provided [24].

This method progresses on the assumption that the PCEs can calculate all paths between the domains, and the PCEs in the neighboring domain and the domain including the destination are known. In the following, this method is compared with the per-domain path computation for the network illustrated in Figure 5.

Figure 5. Example of a network environment for the backward recursive path computation (BRPC).

Figure 5. Example of a network environment for the backward recursive path computation (BRPC).

In the per-domain path computation method, PCE1 in domain 1 selects “A-B-C-D-E” as the optimal path from Source A to Domain 1 and notifies PCE2 of the optimal path, as shown in Figure 6. Then, PCE2 in domain 2 computes the optimal path between the egress node of Domain 1 and the ingress node of Domain 2. In this way, the optimal path to the destination is selected “A-B-C-D-E-G-I-J-…-O” in the per-domain path computation method. In other words, the path computation is calculated in the forward direction. However, in the entire optimal path in Domains 1 to 3, the metric of the path “A-F-H-I-K-M-O” is 13 (the smaller the metric, the more optimal the path). In other words, the path returned by the per-domain path computation is not an optimal path. While the per-domain path computation method may present the optimal path within individual domains, it tends to fail to present the most optimal path from the perspective of the entire path.

Figure 6. Example of the per-domain path computation (forward path computation).

Figure 6. Example of the per-domain path computation (forward path computation).

In the BRPC method, the path computation progresses from the domain including the destination, as shown in Figure 7, and the neighboring PCEs are notified of the group of available paths. Based on the received information, each of the PCEs computes the optimal paths from the ingress node to the egress node and forms a tree starting from the destination.

Figure 7. Example of the backward recursive path computation (backward path computation).

Figure 7. Example of the backward recursive path computation (backward path computation).

4. SDN Routing Computation Application

The SDN routing computation (SRC) application proposed in this research collects node information for network path computation in a multi-domain environment and has a network path computation structure for sharing node information mutually. This section presents the SRC architecture as the path calculation node of each domain.

4.1. SRC Model

The SRC is included in the SDN controller or formed as an external node type by separating it from the controller. One of the major SRC roles is to process the path computation requests received from the SDN controller. The following describes the SRC configuration models for this role.

4.1.1. Internal SRC Model

As shown in Figure 8, the internal SRC node can be implemented in the SDN controller. In the SDN controller, traffic engineering (TE) information is exchanged, and based on exchanged TE information, the traffic engineering database (TED) is built.

Figure 8. Internal SRC model.

Figure 8. Internal SRC model.

When the controller receives a service request, the route computation element (RCE) can calculate the requested path by referring to the local policy.

4.1.2. External SRC Model

Figure 9 shows that the SRC is separated from the controller requesting path setup and located in an external node. The external SRC can be implemented on a certain network server that does not transfer the traffic to the outside. In this model, the computing resources of the controller that centrally manages the entire network are not allocated to the path calculation, so that the load on the controller required for path calculation can be reduced. When the controller receives the service request, the path calculation requests are sent to the external SRC. Path calculation is implemented based on the TED with reference to the local policy, and the calculated result is returned to the controller.

Figure 9. External SRC model.

Figure 9. External SRC model.

4.2. Architecture of SRC

Figure 10 shows the architecture of the SRC application, and the components of the architecture are as follows.

Figure 10. Architecture of SDN optimal path computation application.

Figure 10. Architecture of SDN optimal path computation application.

-

Routing computation element (RCE): As the SDN controller requests the network path calculation to RCE, the RCE calculates all paths based on the source/database node information and the network performance elements (such as bandwidth, delay, etc.) received from TED.

-

Traffic engineering database (TED): TED is generated on the network domain resources and network topology information. It includes bandwidth, delay and jitters, and the RCE calculates the optimal path meeting the requirements using this information.

-

Node/device information database (NID): NID saves basic network connection status within the corresponding domain for prompt path calculation and regularly updates the data.

4.3. Application of SRC in Multi-Domain Environment

While each government independently manages its network resources, NRENs are cooperating to set the paths in the multi-domain network as if setting network paths on the intra-domain network. Therefore, networks in a region or a country are viewed as a single domain, and the SRC application is applied to the multi-domain SDN network to propose models that can compute optimal paths by the characteristics of each research field, such as large-volume data transmission, HD or higher-resolution video transmission, etc.

This section describes the characteristics of each of the research fields and how to apply the SRC in the multi-domain environment in order to analyze the optimal path for multi-domain path selection in the data transmission.

Figure 11 shows the network construction to which the SRC that calculates the optimal path based on the transmission characteristics of the network is applied in the multi-domain environment. The purpose is to set a path from Switch “a” connected to Host A to Switch “i” connected to Host B. The RCE1 and 2 in SRC Apps 1 and 2 calculate all available paths between the ingress/egress nodes of each domain. Since the source “a” and the destination “i” are already known, SRC1 and 2 calculate the path of each domain in the backward recursive path computation method.

Figure 11. Example of multi-domain path computation.

Figure 11. Example of multi-domain path computation.

Figure 12 shows that link metrics are applied within each domain in multi-domain networks. The first value in the parentheses represents the link-bandwidth and the second value is the link-delay.

Figure 12. Multi-domain network with metrics (Bandwidth, Delay).

Figure 12. Multi-domain network with metrics (Bandwidth, Delay).

The paths calculated by SRC1 and 2 are the candidates for the optimal path and can be presented in a tree form, as shown in Figure 13.

Figure 13. Path-tree computed by SRC 1, 2.

Figure 13. Path-tree computed by SRC 1, 2.

The path optimized for data transmission among the paths calculated by SRC1 is “a-c-b-d”, of which the bandwidth metric is the smallest, and the path for real-time multimedia data transmission is “a-c-d”, of which the delay metric is the smallest. SRC2 performs the same as SRC1.

The optimal path is selected on the multi-domain based on the optimal paths calculated by SRC1 and 2. At this time, the paths to the destination are combined and the parameters suitable for the characteristics of the transmission are selected to decide the optimal path with the smallest bandwidth metric or delay metric among the optimal path candidates presented in a tree form. Figure 14 shows the optimal paths computed by SRC1 and SRC2 on the multi-domain network.

In Figure 14a, the selected path among all available paths on the SDN multi-domain has the smallest bandwidth metric. In Figure 14b, the selected path has the smallest delay metric.

Figure 14. Path selection by metric of bandwidth (a) and delay (b).

Figure 14. Path selection by metric of bandwidth (a) and delay (b).

5. Performance Evaluation

5.1. Organize Testbed

This section aims to verify the proposed SRC based on the multi-domain network. As mentioned above, NRENs have supported various fields of research activities—large-volume data transmission, HD and higher-resolution video transmission, measurement and process data transmission and sharing of research equipment and resources. In order to verify the SRC application that calculates optimal paths based on the transmission characteristics, a virtual testbed, shown in Figure 15, has been configured. The experiment is based on the assumption that the domains supervised by Controllers 1 and 2 (Opendaylight [25,26]) are different network environments with different administrators and tools used, which can implement a virtual network called the “mininet”.

Figure 15. Testbed for verifying SRC.

Figure 15. Testbed for verifying SRC.

5.2. Configuration and Evaluation

Two of the network services—“large-volume data transmission”, which are dependent on bandwidth, and “HD or higher-resolution video transmission”, which are sensitive to delays—were selected for a test on the testbed shown in Figure 16.

Figure 16. Testbed for path computation by the transmission characteristics.

Figure 16. Testbed for path computation by the transmission characteristics.

In order to create a multi-domain environment, two domains were formed, as shown in Figure 16. With the source Host A and the destination Host B, the path with the minimum hops will be calculated and will be compared with the path to be calculated by SRC in terms of bandwidth and delay. The experiment assumes that there is no sudden change in the network status, such as a traffic increase, which is hard to predict. As mentioned before, the SRC manages metrics, such as bandwidth and delay, using each domain shown in Figure 16. For actual domain management, metrics are given that are suitable for the network infrastructure and the service types of the corresponding domain. Because each of the domains may use different metric standards, metrics must be set through the use of the link, bandwidth or delay in the node/device information database of the SRC before computation of the optimal path.

Figure 17 shows the path with the minimum hops. In most cases, the optimal path is selected based on different metric values for each routing protocol. The Routing Information Protocol (RIP) uses hop count, the Open Shortest Path First (OSPF) uses bandwidth and the Interior Gateway Routing Protocol (IGRP) or the Enhanced IGRP (EIGRP) uses bandwidth, delay, load, etc., and the Border Gateway Protocol (BGP) applied to the network reachability when calculating the optimal path. This experiment is to compare the path determined by the minimum hop and the path determined through the SRC.

Figure 18 shows path selection for “large-volume data transmission” through the SRC. The path is selected by backward recursive path computation (BRPC) method in which optimal path candidates are presented in a tree form and the path with the proper transmission characteristic (bandwidth) is selected. Figure 19 shows the optimal path determined based on the bandwidth.

Figure 17. The results of path computation by the minimum hops.

Figure 17. The results of path computation by the minimum hops.

Figure 18. Path computation using the SRC application (metric: bandwidth).

Figure 18. Path computation using the SRC application (metric: bandwidth).

Figure 19. The results of path computation by the bandwidth.

Figure 19. The results of path computation by the bandwidth.

As shown in the Table 1, Path 2 (bandwidth) has more hops than Path 1 (min hop), but has a higher bandwidth metric than that of Path 1. Path 2 with a higher bandwidth metric is better for data transmission. The average throughput of Path 2 is about 100 Mbps faster than that of Path 1.

Table 1. Comparison between Path 1 (Min hops) and Path 2 (Bandwidth).

	Path	No. of hops	Metric (Bandwidth)	Average Throughput (Mbps)
Path 1 (Min hops)	a-c-d-f-g-j	6	22	285
Path 2 (Bandwidth)	a-c-b-d-f-g-j	7	25	400

Table 1. Comparison between Path 1 (Min hops) and Path 2 (Bandwidth).

	Path	No. of hops	Metric (Bandwidth)	Average Throughput (Mbps)
Path 1 (Min hops)	a-c-d-f-g-j	6	22	285
Path 2 (Bandwidth)	a-c-b-d-f-g-j	7	25	400

Figure 20 shows that an optimal path is selected for real-time collaborative research, such as real-time HD media transmission. In simple data transmission, network delays or packet losses can be handled through data retransmission. However, in high-resolution video transmission for video conferences or real-time video education, data losses result in voice and image disconnection. Even though they are restorable, the user’s satisfaction level is low. Therefore, in real-time media transmission, delays and packet losses are more crucial than bandwidth, so that it is rational that the delay or jitter metric should be used instead of minimum hops or bandwidth for real-time video and audio transmission. Figure 21 shows that an optimal path is determined based on minimum delays. The path is determined for each transmission characteristic as described before.

Figure 20. Path computation using the SCR application (metric: delay).

Figure 20. Path computation using the SCR application (metric: delay).

Figure 21. The results of path computation by the delay.

Figure 21. The results of path computation by the delay.

As shown in the Table 2, Path 1 with the minimum hops has a metric of 34, while path 3 with the minimum delay has a metric of 21. Path 3 with minimum delay has a smaller metric, although it has more hops and is, therefore, more suitable for real-time media transmission. The actually measured delay of Path 3 is about 40 ms less than that of Path 1.

Table 2. Comparison between Path 1 (Min hops) and Path 3 (Delay).

	Path	No. of hops	Metric (Delay)	Average Delay (ms)
Path 1 (Min hops)	a-c-d-f-g-j	6	34	88.6
Path 3 (Delay)	a-b-c-d-f-h-i-j	8	21	42.4

Table 2. Comparison between Path 1 (Min hops) and Path 3 (Delay).

	Path	No. of hops	Metric (Delay)	Average Delay (ms)
Path 1 (Min hops)	a-c-d-f-g-j	6	34	88.6
Path 3 (Delay)	a-b-c-d-f-h-i-j	8	21	42.4

6. Conclusions

This research describes the SDN environment that can change the network ecosystem from the hardware-based one to the software-based one while global NRENs are moving their focuses toward software-based future service environments. At present, it is difficult for a certain user to get full network information about end-to-end path. Due to this reason, it is extremely difficult to compute the optimal path to the target destination. Moreover, when an error occurs on the path, the path must be searched again, and the optimal path must be found. However, path information sharing is rare. Allocating optimal paths among the networks and providing connectivity to the users at the end of the network are crucial missions of not only commercial network service providers, but also the NREN.

SDN is a new network architecture in which network control and data transmission features are separate and programmable. The service providers and the communication service providers can gain network control independence from network equipment vendors by simplifying the network design, implementation and operation. There is no need to understand thousands of protocol standards and details. Instead, the infrastructure layer can be easily controlled simply through the controller.

This paper proposes an application that calculates optimal paths for data transmission and real-time audio and video transmission, which is a major issue of the network service providers. The SRC application is efficiently designed and applied in the multi-domain network for efficient use of the resources, selection of the optimal path between the domains and optimal establishment of end-to-end connections. The application focuses on the architectural structure design for the selection of the network paths.

The research presents an optimal path determination model in the SDN network, a new paradigm in the changing network environment, and is expected to help NRENs research activities in the SDN and the newly emerging field and promotes itself as NRENs by being applied to user-friendly services and platforms.