Novel Software-Defined Network Approach of Flexible Network Adaptive for VPN MPLS Traffic Engineering

Multi-Protocol Label Switching VPN (MPLS-VPN) is a technology for connecting multiple remote sites across the operator’s private infrastructure. MPLS VPN offers advantages that traditional solutions cannot guarantee, in terms of security and quality of service. However, this technology is becoming more prevalent among businesses, banks or even public institutions. With this strong trend, the management of the paths on which these tunnels can be deployed has become a necessity is a priority need for Internet access providers (ISPs). Through the principle of controller orchestration, ISPs can overcome this difficulty. Software-defined network is a paradigm allowing through the principle of orchestration to manage the entire network infrastructure. In this paper, we propose a new approach called FNA-TE "Flexible Network Adaptive Traffic Engineering", this approach allows to manage MPLS VPN tunnels to meet the QoS requirements of those with the highest priority. Keywords—SDN; QoS; VPN; MPLS; Adaptive network

Among the strengths of the MPLS technology, traffic engineering (TE) is used to optimize the use of network resources to avoid congestion.It is the consideration of the bandwidth avail-able on a link during routing decisions that makes this optimization possible.MPLS-TE allows the establishment of MPLS tunnels routed explicitly according to the constraints of the trans-ported traffic (bandwidth, delay ...) and the resources available in the network.MPLS-TE creates a connected mode in IP net-works, optimizing the use of resources and maximizing the traffic load that can flow over the network while preserving the quality of service.
In order to overcome the complexities of implementing traffic engineering policies across multiple routers, softwaredefined network (SDN) [9][10] [11] technology can be used.SDN de-couples the data plane from the control plane by centralizing it on a device called a controller.SDN can be used to solve a variety of problems related to the complexity and the high number of equipment.SDN is mainly based on three logical layers: the given layer, the control layer, and the application layer.The application layer provides the set of services and applications used by the end user.The given layer contains the physical equipment responsible for conveying the information.The control layer contains all the operations and instructions that man-age the entire network.
The rest of the paper is organized as follows: in Section 2 we will discuss the strengths of our contributions.In Section 3 we will detail the architecture of our solution.Section 4 will focus on performance evaluation.And we will conclude in Section 5.

II. FLEXIBLE NETWORK ADAPTIVE -TRAFFIC ENGINEERING
To understand the motivation behind our approach, we will briefly describe the existing issues in MPLS VPN technology:  A customer may have one or more VPNs with the same or different destinations.
 These VPN tunnels can have different priorities.
 Multiple MPLS VPNs can follow the same path.
 Paths can have asymmetric performance, in terms of effective bandwidth and unused bandwidth.
A. Strengths 1) Detect VPN tunnels in the establishment phase or already established.
2) Draw the architecture of the intermediate network.
3) Detect for each tunnel the associated LSP. 4) Classify tunnels by priority.5) Decide on the shortest LSP to assign to the VPN. 6) Check that the remaining bandwidth meets the QoS requirements of the tunnel.
7) Treat tunnels fairly; that is to say, not necessarily to route the tunnel with the highest priority by the short path having sufficient bandwidth, to the detriment of the lowest priority tunnels.A higher priority tunnel can be routed through the second or nth best path if this degrades the performance of the lower priority tunnels already deployed.

B. Proof
 Let G be a graph (V, E) with V are the vertex routers and E are links.E (u, v) are the ends of a link.
 Let w be a neighbor vertex.www.ijacsa.thesai.org Let Ba be the available bandwidth.
 The bandwidth of the first link to the source:

| ̅ ̅ |
The bandwidth beyond the neighbor: U + 1 and v + 1 to avoid a closed path.
The most optimal segment S is therefore defined by the following function: Since the segments are determined; they must be sorted by available bandwidth from the highest (h) to the lowest (l).
The path with the highest available bandwidth is defined by the following equation: Suppose that the available bandwidth of the shortest path is not sufficient, our algorithm can move to the next path: , where n is the variance.
The variance is relative to the priority.A non-priority VPN can traverse the longest path with restricted bandwidth.

(∑ )
Until this phase we were able to determine the shortest path having the available bandwidth meeting the QoS requirements of the source.But, is it necessary to move the other tunnels to another path in favor of the tunnel with the highest priority?In some cases we can find the nth best way for the tunnel with the highest priority: Case 1: It is possible that several lower priority tunnels coexist in .
Case 2: Moving several non-priority tunnels to another  can jeopardize their quality of service.
Case 3: Sometimes routing the highest priority VPN by the nth best path does not degrade the quality of its exchanges as this path meets the customer's QoS requirements.
The following formula is used to define the closest path to the best , meeting the Breq requirements.

III. FNA-TE ARCHITECTURE
The proposed approach is based on three layers: application, control and data.Fig. 1 illustrates the proposed architecture.
The application layer is responsible for defining VPN tunnels and their priorities.Fig. 2 illustrates an example of the GUI interface for customizing tunnels.
The control layer can act on the path on which to deploy MPLS VPN tunnels based on the available bandwidth and the shortest route.This layer consists of five modules:

A. Network Discover
This module is responsible for detecting the network topology, V-vertex and E-links.In a hybrid network where routers do not support the OpenFlow protocol, additional protocols can be used as CDP for Cisco devices and LLDP for non-Cisco equipment.The controller verifies the network topology based on these protocols.For SDN devices, OFDP messages can be used for topology detection.In the case of the Moroccan university, specifically Chouaïb Doukkali University, the routers set up do not support SDN.The topology detected automatically by our controller is shown in Fig. 3.

B. Path Computation
As soon as the topology is discovered, this module makes it possible to calculate the most optimal path on which to deploy / route the MPLS VPN tunnel.The processing performed by this module is described in the previous section.However, the algorithm 1 illustrated in Fig. 4 describes the main operating phases of this module.

C. VPN Monitor
This module is used to check the MPLS VPN already deployed on a router.The controller can verify the VPN instances already open on a device by querying the SNMP MIB object: 1.3.6.1.4.1.9.9.711 or launch the "Show ip vrf" or "display ip vpn instance" commands for routers such as Cisco, Juniper, and HP.Recall that the priority of a tunnel can be detected at the base of the initial declaration by the administrator during the first phase (please refer to Fig. 2).

D. Admission Control
This module allows authorizing or not: 1) The establishment of a tunnel.
2) Routing a higher priority VPN.
3) Destruction of a lower priority VPN if all paths are overloaded.
4) The data plan contains all routers of the network architecture consisting of P, PE and CE equipment.
In the next section we will evaluate the performance of our approach.

A. Network Testbed
In order to evaluate the performances of our approach, we set up a network testbed consists of several routers and tens of clients (Fig. 5).Used applications for the evaluation are Voice over IP [12][13][14], Video streaming, and Database traffic.Evaluation criteria are: 1) VoIP latency: Delay it takes for one endpoint to send a packet to another.
2) VoIP jitter: Delay between submission of two packets.
3) VoIP MOS: Quality imperceptible of the call.4) VoIP loss rate: Quantity of VoIP non-received traffic.5) Video loss rate: Amount of non-received video traffic.6) Delay of database query.

B. Obtained Results
Fig. 6 illustrates the overall results obtained.Fig. 6(a) illustrates the VoIP loss rate obtained by our FNA approach compared to the RSVP-TE protocol.The results obtained showed the effectiveness of our approach compared to FNA-TE, we find that both models offered an acceptable rate up to the scenario of 80 clients, however, from the scenario of 90 clients we found that RSVP-TE exceeded the tolerable threshold of 3%, our model has shown its effectiveness even in the scenario of 200 customers.The VoIP latency results (Fig. 6(b)) thus showed the efficiency of our approach, a latency not exceeding 50 milliseconds was measured by FNA-TE against 150 RSVP-TE.Fig. 6(c) illustrates the VoIP jitter, the results obtained showed that the delay variation of our approach is the smallest not exceeding a value of 19 milliseconds against 50 of RSVP-TE.The same results are observed for Video Traffic Fig. 6(f) and Fig. 6(g).In this paper we dealt with a problem of traffic engineering in MPLS-VPN tunnels.Our FNA-TE contribution is to guarantee MPLS-VPN tunnels the least short path guaranteeing the bandwidth necessary for a good level of the quality of service of the transported traffic.Our contribution allows through fair treatment not to compromise the lowest priority tunnels.Our approach was tested in a network consistent with that of Chouaïb Doukkali University, in which we evaluated the performance of real-time, streaming and transactional traffic by increasing the load and the number of users.The results obtained showed the effectiveness of our approach compared to the protocol commonly used RSVP-TE.

∑
Consider MPLS VPN tunnels already established on an Ssegment: either Vc the number of VPN tunnels and Vp the priority of a tunnel.

Fig. 1 .
Fig. 1.The Architecture of the Proposed Approach.

Fig. 2 .
Fig. 2. The GUI Interface of the Application Layer.

Fig. 4 .
Fig. 4. The Operating Algorithm of the Path Computation Module.

Fig. 5 .
Fig. 5.The Operating Algorithm of the Path Computation Module.