Interoperability and Reliability of Multiplatform MPLS VPN: Comparison of Traffic Engineering with RSVP-TE Protocol and LDP Protocol

One of the alternatives to overcome network scalability problem and maintaining reliability is using MPLS VPN network. In reallity, the current network is already using a multiplatform of several different hardware vendors, i.e., Cisco and Juniper platforms. This paper discusses the comparison of the simulation results to see interoperability of multiplatform MPLS VPN andreliability through traffic engineering using RSVP-TE and LDP protocols. Both the RSVP and LDP protocols are tested on a stable network and in a recovery mode,as well as non-load conditions and with additional traffic load. The recovery mode is the condition after the failover due to termination of one of the links in the network. The no-load condition means that the network is not filled with additional traffic. There is only traffic from the measurement activity itself. While network conditions with an additional load are conditions where there is an additional UDP packet traffic load of 4.5 Mbps in addition to the measurement load itself. On a stable network and without additional traffic load, the average delay on LDP protocol is 59.41 ms, 2.06 ms jitter, 0.08% packetloss, and 8.99 Mbps throughput. Meanwhile, on RSVP protocol, the average delay is 52.40 ms, 2.39 ms jitter, 12.18% packet loss, and 7.80 Mbps throughput. When failover occurs and on recovery mode, LDP protocol is48% of packet loss per 100 sent packets while on RSVP packet loss percentage is 35.5% per 100 sent packets. Both protocols have interoperability on the third layer of multiplatform MPLS VPN, but on heavy loaded traffic condition, RSVP protocol has better reliability than the LDP protocol.


I. INTRODUCTION
S ERVICE provider is the main player in the pro- cation allows the use of provider's network resource optimally. For instance, Virtual Private Network (VPN) allows a private data link on public network with high scalability and security [1]. By VPN, providers can utilize their network on the Internet to be used as private data communication for users as long as the users are connected to provider's Point of Presence (PoP) [1,2].
The Internet Engineering Task Force (IETF) standardizes a solution such as Multiprotocol Label Switch (MPLS) as an expansion of VPN to increase the performance of forwarding and traffic engineering intelligence on packet based network [2][3][4]. MPLS combines the advantage of the second OSI layer of forwarding and routing efficiency on the third OSI layer to increase the performance by label switching. This mechanism is consecutively used as a method to control traffic flow on the network to ensure the rigidity of traffic that is known as traffic engineering. Traffic engineering can overcome standard routing protocols such as RIP, OSPF, IGRP, and others on MPLS network because they seek the nearest and shortest route [2,[4][5][6].
There are two protocols supporting the traffic engineering, namely Resource Reservation Protocol (RSVP) and Constraint-Based Routed Label Distribution Protocol (CR-LDP). These protocols offer the same functions but different mechanisms. However, RSVP shows an advantage on data transport because it uses UDP so it is connectionless. On the other hand, several platforms deny UDP access so in the level of data transport, availability, and accessibility determine which protocols to be used [7][8][9][10].
Researchers have tested traffic engineering methods on MPLS network using several approaches [3,4,[11][12][13][14][15][16]. Reference [14] applied tunneling and explicit route traffic engineering and analyzed the QoS for multicast I n P r e s s  [14]. Reference [8] compared the RSVP and CR-LDP protocol parameters as traffic engineering protocol on MPLS network. Meanwhile, Ref. [9] compared frame error rate, throughput, and normalized data rate between RSVP and non-RSVP network. The analyzed data were voiced on the same physical network. The result revealed that the RSVP network had a lower frame error rate with a high throughput and normalized data rate compared to non-RSVP [9]. Reference [13] compared the memory usability of LDP and RSVP together with the advance of MPLS. The tested data packet on the network was Point to Multi-Point (P2MP) multicast data. The result showed RSVP-TE was better in utilizing network resource while LDP offered constant scalability within an expanding network. In reality, the Internet is not always a single platform but multiplatform from different hardware vendors such as Cisco and Juniper. Every vendor has its scalability rule for each of their hardware. Therefore, hardware vendors and network providers must share the same information to determine which protocols to be implemented on MPLS network considering protocol determination becomes a crucial factor to rank the manufacturers devices and network providers [11].
This paper is the further development of the previous work of Ref. [17] that discusses the performance of the RSVP-TE protocol in Multiplatform MPLS VPN. This paper compares the results of traffic engineering by adjusting traffic flows (override traffic routes) by setting and controlling RSVE-TE and LDP protocols on multiplatform MPLS network. The goal is to compare the interoperability and reliability of RSVP and LDP protocols on multiplatform MPLS networks. The reliability will be seen by testing the performance of services (QoS).

II. RESEARCH METHOD
The research procedure is of the following: 1) System modeling 2) System configuration 3) Testing a) Connectivity testing b) Performance parameter testing 4) Analysis

A. System Modeling
We consider a model of a small company, which has one head office and two branch offices. They are connected through a VPN network by a provider. Each The model is assumed that a company XYZ has one head office and two branch offices; they are connected through VPN network by the provider. Every branch office consists of two networks and the head office consists of one network. The network provider applies the MPLS on their own core network [10]. The system modeling is depicted in Fig.1 below. Fig. 1. VPN Model [10] This network simulates 3 Customer Edges (CE), 3 Provider Edges (PE) and 5 routers as a core network from the provider. In multiplatform test, CE router is from Cisco and on core network routers and PE are from both Cisco and Juniper.
adjusting traffic IGP to prevent t protocol control In this resear engineering on M avoided on certa With the LD network follows to give the pack this simulation, configuration is   ation and Information Technology) Journal, Vol. XI No. 1, pp. 101-102 a way it utilizes network resource while scalability within an expanding network rnet is not always a single platform but ifferent hardware vendors such as Cisco endor has its scalability rule for each of refore, hardware vendors and network e the same information to determine be implemented on MPLS network determination becomes a crucial factor e manufacturer's devices and network development of a previous paper [10] rformance of the RSVP-TE protocol in VPN. This paper compares the results g by adjusting traffic flows (override ing and controlling RSVE-TE and LDP atform MPLS network. The goal is to rability and reliability RSVP and LDP tform MPLS networks. The reliability g the performance of services (QoS).

II. METHODS
in this study refers to the following ling guration nectivity testing ormance parameter testing med that a company XYZ has one head ch offices; they are connected through provider. Every branch office consists of e head office consists of one network. r applies the MPLS on their own core system modeling is depicted in Fig.1 On every network in each business location owned by XYZ there is a router acting as gateway to connect with PoP owned by network provider. In overall, the system topology is depicted in Fig.2 below.  [10] From the figures above in general there are three main components of the system; CE, PR, and Label Switch Router (LSR). The three components will be configured to simulate traffic engineering on 3 rd OSI layer VPN MPLS network.
The variation of platforms refers to Table I below [10]. The traffic engineering in our simulation is basically by adjusting traffic flow (override traffic routes) determined by IGP to prevent traffic congestions on certain routes by routing protocol controlling on multiplatform MPLS network.
In this research, the RSVP protocol will be used for traffic engineering on MPLS network so that network congestion is avoided on certain links.
With the LDP protocol, the selection of a path in the network follows the selection of a path by IGP. LDP duty is

Provider Core Network
Customer XYZ Network branch office has two networks and the head office has only one network. The network provider applies the MPLS on their own core network [17]. The model of the system is depicted in Fig. 1. This network simulates three customer edges (CE), three provider edges (PE), and five routers as a core network from the provider. In the multiplatform test, CE router is from Cisco, and on core network routers and PE are from both Cisco and Juniper.
On every network in each business location, a router acts as a gateway to connect to the provider network with PoP. Graphically, the system topology is depicted in Fig. 2.
The topology has three main components of the system, CE, PR, and Label Switch Router (LSR). The three components will be configured to simulate traffic engineering on the third OSI layer VPN MPLS network. The variation of platforms is presented in Table I.

B. System Configuration
Basically, the traffic engineering in our simulation is materialized by adjusting the traffic flow (overriding traffic routes) determined by IGP to prevent traffic congestions on certain routes by routing protocol controlling on multiplatform MPLS network. In this research, the RSVP protocol is used for traffic engineering on MPLS network so that network congestion can be avoided on certain links.
With the LDP protocol, the selection of a path in the network following that of IGP. LDP duty is to give the packet label entering the MPLS network. In this simulation, the format of the LDP on a Cisco router configuration is shown in Listing 1.

Router(config)#mpls label protocol LDP Router(config)#mpls ldp router-id [loopback]
Listing 2 shows an example configuration of LDP in LSR4.   In the LSR5 router, all interfaces used by IGP incorporated into LDP protocols and MPLS, because all interfaces used in MPLS networks.
The path determination used in this research is Explicit Path and Dynamic Path. Explicit path is used as a main path in transporting data from each PE and Dynamic Path acts as redundancy in case one node fails to work. The Explicit Path is depicted in Fig.7 below. The configuration format in Cisco router appointed to activate traffic engineering feature on MPLS network is depicted in Fig.8 below.  The path determination used in this research is Explicit Path and Dynamic Path. Explicit path is used as a main path in transporting data from each PE and Dynamic Path acts as redundancy in case one node fails to work. The Explicit Path is depicted in Fig. 3.
The configuration format in Cisco router appointed to activate traffic engineering feature on MPLS network is depicted in Listing 5. LSR1(config)#mpls traffic-eng tunnels LSR1(config)#interface Ethernet1/1 LSR1(config)#mpls traffic-eng tunnels LSR1(config)#interface Ethernet1/2 LSR1(config)#mpls traffic-eng tunnels LSR1(config)#router ospf 10 LSR1(config)#mpls traffic-eng router-id lo0 LSR1(config)#mpls traffic-eng area 0 In MPLS network, the path connecting LSR is called Label Switched Path (LSP) [7]. The configuration on Listing 6 is a configuration to form LSP traffic engineering on Cisco router. The address to be passed by LSP is determined by separate tunnel interface. Listing 7 shows the configuration for traffic engineering at LSR1 (Cisco).
With a similar method, configuration on Juniper router is done so the network can be set based on the plan.  Fig.10 below shows the configuration for traffic engineering at LSR1 (Cisco). The connectivity test is intended to check the interoperability of multiplatform MPLS VPN. Testing is done by connecting the host to each CE router on the network as shown in Fig.11 below. The hosts which are used to test the connectivity use Ubuntu 12.04 operating system. Tools which are used in the testing are Ping and Traceroute. The testing process will be carried out from Host-B and Host C to Host-A with two scenarios for each protocol; that is when the network was stable (called as end-to-end connectivity testing) and when the network has failover (called as network recovery testing).

I n P r e s s
End-to-end connectivity test and network recovery are done on LDP and RSVP protocols. Testing is done by sending a ping request from Host-B and Host C to Host-A with a total of 100 packages and it can be seen how many packages are acceptable.

C. Interoperability: Connectivity Test
The connectivity test is intended to check the interoperability of multiplatform of MPLS VPN. Testing is done by connecting the host to each CE router on the network as shown in Fig. 4.
The hosts which are used to test the connectivity use Ubuntu 12.04 operating system. Tools used in the testing are Ping and Traceroute. The testing process will be carried out from Host B and Host C to Host A with two scenarios for each protocol. That is when the network is stable (called as end-to-end connectivity testing) and when the network has failover (called as network recovery testing).
End-to-end connectivity test and network recovery are done on LDP and RSVP protocols. Testing is done by sending a ping request from Host B and Host C to Host A with a total of 100 packages and it can be seen how many packages are acceptable. The number of 100 packets is sufficient to see network connectivity.

D. Reliability Test
Reliability refers to the performance of the system. Network performance measurement is performed by connecting the host to each CE router. The compared performance parameters are the delay, jitter, packet loss, and throughput. Network performance measurement with LDP and RSVP protocols is done in two conditions, no load (except the measurement traffic itself) and loaded (with the additional UDP traffics). Figure 5 shows no load traffic measurement model.
To simulate loaded network, the network will be flooded by UDP traffics by 50% from maximum traffic Reliability refers to the performance of the system. Network performance measurement is performed by connecting the host to each CE router. The performance parameters to be compared are the delay, jitter, packet loss and throughput. Network performance measurement with LDP and RSVP protocols is done in 2 conditions; no load (except the measurement traffic itself) and loaded (with the additional UDP traffics). Fig.12 shows no load traffic measurement model. To simulate loaded network, the network will be flooded by UDP traffics by 50% from maximum traffic load of 4.5 Mbps sent from Host-A to Host-B and Host-C. The loaded network measurement is depicted in Fig.13. The measurement is done using 2 tools; Ping and Iperf. Ping is used to determine delay while Iperf is used to send traffic and measuring jitter, packet loss, and throughput. The measurement is done by sampling data every second during 60 seconds.

III. RESULTS AND DISCUSSION
The results of the end-to-end connectivity test are shown in Table II   Reliability refers to the performance of the system. Network performance measurement is performed by connecting the host to each CE router. The performance parameters to be compared are the delay, jitter, packet loss and throughput. Network performance measurement with LDP and RSVP protocols is done in 2 conditions; no load (except the measurement traffic itself) and loaded (with the additional UDP traffics). Fig.12 shows no load traffic measurement model. To simulate loaded network, the network will be flooded by UDP traffics by 50% from maximum traffic load of 4.5 Mbps sent from Host-A to Host-B and Host-C. The loaded network measurement is depicted in Fig.13. The measurement is done using 2 tools; Ping and Iperf. Ping is used to determine delay while Iperf is used to send traffic and measuring jitter, packet loss, and throughput. The measurement is done by sampling data every second during 60 seconds.

III. RESULTS AND DISCUSSION
The results of the end-to-end connectivity test are shown in Table II  During the process the network will be r link failover in a netw testing are shown in T TABEL III.

LDP
B C

RSVP B C
In general, it appe RSVP protocol is les LDP protocol. The ab has a convergence tim number of losses to t number of losses by t because, in the RSVP before-break, where th Delay is a time r recipient. From 60s of loaded traffic from Ho in Fig.14.  Fig. 6.
The measurement is done using two tools, Ping and Iperf. Ping is used to determine delay while Iperf is used to send traffic and measure jitter, packet loss, and throughput. The measurement is done by sampling data every second during 60 s.

A. End-to-End Connectivity
The end-to-end connectivity is tested using the ping command on Linux OS. The purpose of this test is to ensure that the network is well connected. The results of the end-to-end connectivity test are shown in Table II.  In Table II, it can be seen that all submitted packets are completely received. This indicates the network connection is stable and has no issue. On the stable condition, with the LDP protocol, the traceroute result from Host B to Host A shows the path through LSR2 (PE-B) → LSR5 → LSR4 → LSR1 (PE-A). The traceroute results from Host C to Host A shows the path through LSR3 (PE-C) → LSR5 → LSR4 → LSR1 (PE-A). The paths according to the configuration that has been done previously. Traceroute testing on Host B and Host C with LDP protocol shows the path similarities through LSR5 and LSR4. It shows that the LDP protocol susceptible to congestion of traffic because traffic from LSR2 and LSR3 pass through the same path.
With the RSVP protocol, traceroute results from Host B to Host A shows the path through LSR2 (PE-B) → LSR5 → LSR1 (PE-A). The path is according to the configuration that has been done before. The traceroute results from Host C to Host A shows the path through LSR3 (PE-C) → LSR4 → LSR1 (PE-A). Traceroute testing with RSVP protocol indicates that the traffic sent from Host B and Host C, has passed through different pathways to prevent congestion of traffic in the network.

B. Network Recovery
During the process of package transmission, one of the links in the network will be removed from the topology to simulate link failover in the network. The goal is to see the speed of each protocol that can perform recovery. The results of network recovery testing using command Ping in OS Linux are shown in Table III. In general, it appears that the number of packets lost with RSVP protocol is less than the number of packets lost with LDP protocol. The data shows that the RSVP protocol has a convergence time faster than LDP protocol, because of a number of losses to the protocol RSVP by 35.5%. Meanwhile, the number of losses by the LDP protocol are 48%. This happens because in the RSVP protocol, manufacture LSP is a make-before-break, where the LSP is made before the failover.

C. Delay
Delay is a time required by data packet from sender to recipient. The delay measurement is done using the command Ping and iPerf on the Linux OS. Command Ping functions to record delay, while iPerf works to add network traffic load at the time of measurements with additional traffic load. From 60 s of measurement, we obtain a delay for no loaded traffic from Host B and Host C to Host A as depicted in Fig. 7. Figure 7 shows that the average of delay for 60 s between LDP and RSVP protocol. It shows no significant difference. The delay rate for LDP protocol is around 50-70 ms delay and around 40-60 ms for RSVP protocol. Figure 8 shows the average of delay after the network is flooded with UDP traffic. This additional load is generated by iPerf of 4.5 Mbps as reverse traffic to the original sender.
On Fig. 8, a significant difference of delay can be seen on the network between using LDP protocol and RSVP protocol. With the LDP protocol, the average of delay about 80 ms and there are two packages that   timeout marked with two points of the graph is above 500 ms. While with the RSVP protocol, the average delay is relatively stable around 50 ms. Figure 8 also shows that the RSVP protocol can manage the traffic better than the LDP protocol when the network is flooded with traffic. Table IV shows the average of delay for 60 s with LDP and RSVP protocols obtained by using command Ping on Linux OS. The differences of network performance came after the network is flooded with traffic. With the LDP protocol, all traffics from Host B and Host C to the Host A have passed through the same path, resulting in accumulation of packages on the used link. The cumulation of packets causes queues packets to be longer, so the delay increases. Meanwhile, with the RSVP protocol, traffic from Host B and Host C has passed through different pathways to prevent the congestion on the used link.

D. Jitter
Jitter is a variation of delay as a result of time difference or interval of data packet arrival at the recipient. The measurement of jitter is done using Iperf tools. Jitter measurements in no-additional traffic load conditions are performed by sending a maximum pf 9 Mbps UDP packeta generated by iPerf. From the measurement for 60 s, we obtain the packet loss percentage for no loaded traffic from Host B and Host C to Host A as seen in Fig. 9. Figure 9 shows that the average jitter for 60 s between LDP and RSVP protocol has the same relative value which is around 2 ms. This value indicates that in  no loaded traffic which both with the LDP and RSVP protocols, network quality is still maintained. The measurement of jitter with additional traffic loads is done by adding 4.5 Mbps of reverse traffic load. Figure 10 shows the average jitter after the network is flooded with UDP traffic.
After the network is flooded with UDP traffic, the average of jitter with LDP and RSVP protocols is different. With the LDP protocol, the average jitter is around 4 ms, while the average jitter with RSVP protocol is around 2 ms. This shows a decreasing in the quality of the network in terms of jitter with LDP protocol when loaded traffic condition, while with the RSVP protocol, the decrease tends to be smaller. Table V shows the average of jitter for 60 s with LDP and RSVP protocols obtained by using iPerf tools.

E. Packet Loss
Packet loss is a rate to determine how much data packets are lost at the destination. The measurement of packet loss is done using Iperf tools. Packet loss measurements in no-additional traffic load conditions are performed by sending a maximum 9 Mbps UDP packets generated by iPerf. From a 60-second measurement, we obtain a packet loss for no loaded traffic from Host B and Host C to Host A as seen in Fig. 11. Figure 11 shows the average packet loss with the LDP and RSVP protocol during the 60 s that have the same relative value of 0%. The impulse value of the initial in graph with both the LDP and RSVP protocol is possible as results of external influences, coming   from the system simulator. During the measurements, the computer loads as a system simulator increases. This happens because in addition to hardware simulation, the computer must simulate the traffic. Thus, the measurement process allows changes impulsively. Overall with the LDP and RSVP protocols in no loaded traffic condition, the packet loss value at both LDP and RSVP protocols is around 0%. The measurement of packet loss with additional traffic loads is done by adding 4.5 Mbps reverse traffic load. Figure 12 shows the average of packet loss in the network after loaded with UDP traffic.
After the network flooded with UDP traffic, the average of packet loss with the LDP and RSVP protocols shows a significant difference. With LDP protocol, the average of packet loss is around 60%, while the average of packet loss with RSVP protocol is around 15%. This shows that the losses in the network with LDP protocol is larger than the RSVP protocol.

F. Throughput
Throughput are how much packets of data received by a node within certain observation interval. The value is influenced by delay, jitter, and packet loss within the network. The measurement of throughput is done using Iperf tools. Packet loss measurements in no-additional traffic load conditions are performed by sending a maximum of 9 Mbps UDP packets generated by iPerf. From a 60-second measurement, we obtain a throughput for no loaded traffic from Host B and Host C to Host A as seen in Fig. 13. Figure 13 shows that the average of throughput with LDP and RSVP protocols has the same relative value around 9 Mbps. The impulse value of the initial in graph with both the LDP and RSVP protocol is a result of external influences. The throughput measured in the network will not reach the maximum value because the limited ability of the simulator is only 9 Mbps. With these limits, the maximum traffic that can be simulated is 9 Mbps.
The measurement of throughput with additional traffic loads is done by adding 4.5 Mbps reverse traffic load. This traffic generated by Ipref. Figure 14 shows the average of throughput in the network after loaded with UDP traffic.
After the network is flooded with UDP traffic, the average of throughput with the LDP and RSVP protocols show a significant difference. With the LDP protocol, average of throughput is around 4 Mbps, while with the RSVP protocol average throughput is around 8 Mbps. This shows the throughput on the  network with RSVP protocol is greater than the LDP protocol. Table VII illustrates the average of throughput within 60 s measurement with LDP and RSVP protocols obtained by using iPerf tools. From VII, it can be seen that the average of throughput in the network with the LDP and RSVP protocol during the 60 s for no loaded traffic shows the value that relatively equals. To analyze the throughput in the network, it will not be separated from the packet loss on the network. In a network with no loaded traffic with the LDP and RSVP protocol, losses in the network are under 1% and the result of throughput approaches the maximum value. This occurs because of collisions in the network tend to be limited so the whole packages sent can be received well. In the network with additional traffic with the protocol LDP, losses are around 59.48%, while with the RSVP protocol, losses are around 12.18%. The high losses on LDP protocol cause the number of packets that can be accepted decrease, so a lot of data are lost due to a collision in the network. Then, with the RSVP protocol, because the traffic is routed to a different path, the collision can be minimized so that the number of data packets that can be received are greater.

IV. CONCLUSIONS
Based on the network simulation of the third OSI layer multiplatform MPLS VPN with LDP protocol, we conclude that: • both the LDP and RSVP protocols can operate in the third multiplatform MPLS VPN (Cisco and Juniper), • in the recovery process from sending 100 packets, the rate of loss with the LDP protocol is 48% and the RSVP protocol is 35.5%, • on no traffic load with the LDP protocol, we obtain a delay of 59.41 ms, jitter of 2.06 ms, packet loss of 0.08%, and throughput of 8.996 Mbps, and with the RSVP protocol, we obtain a delay of 50.24 ms, jitter of 2.06 ms, packet loss of 0.29%, and throughput of 8.96 Mbps, • on the loaded traffic of 50% of maximum load with the LDP protocol, we obtain the delay rate of 98.82 ms, jitter of 3.96 ms, packet loss of 59.48%, and throughput of 3.58 Mbps, and with the RSVP protocol, we obtain the delay rate of 52.40 ms, jitter of 2.39 ms, packet loss of 12.18%, and throughput of 7.80 Mbps, and finally, • both protocols have interoperability at the third Layer Multiplatform of MPLS VPN, but on heavy loaded traffic condition, RSVP protocol is more reliable than the LDP protocol.