Proceedings of the International Conference on Computer and Communication Engineering 2008 May 13-15, 2008 Kuala Lumpur, Malaysia Performance Analysis and the Study of the behavior of MPLS Protocols Md. Arifur Rahman1, Ahmedul Haque Kabir1, K. A. M. Lutfullah1, M. Zahedul Hassan2, M. R. Amin1 1 Department of Electronics and Communication Engineering, East West University, Mohakhali, Dhaka-1212, Bangladesh; [email protected] com, [email protected] edu 2 Information and Communication Technology Cell, Bangladesh Atomic Energy Commission, Ramna, Dhaka-1000, Bangladesh; [email protected] om Abstract MultiProtocol label switching (MPLS) is the new means to take care of the fastest growing communication network to enhance the speed, scalability and service provisioning capabilities. In order to optimize the use of transmission resources, MPLS carries differentiated services across the Internet through a virtual path capability between packet (label) switches. MPLS also has the capabilities to engineer traffic tunnels by avoiding congestion and utilizing all available bandwidth with an efficient manner.
The core value of MPLS is followed by the comparison of MPLS network with the existing network and MPLS signaling protocols: Constrained based Label Distribution Protocol (CR-LDP), Resource Reservation Protocol (RSVP) and Traffic Extension RSVP (RSVP-TE) maintaining the Quality of Service (QoS) parameters and their performance analysis as well. In such context, a full comprehensive simulation environment is created for a conventional network and MPLS applied over that traditional network to evaluate the comparative performance of network traffic behavior and the functionalities of MPLS signaling protocols as well.
Finally, the results are evaluated and analyzed, and their behaviors are shown by means of graphical manner. Keywords: Label Switching, MPLS, LDP, CR-LDP, RSVP, RSVP-TE, QoS, Network Simulator (NS2). I. 1. INTRODUCTION The key functionalities of Traffic Engineering (TE) are resource reservation, fault-tolerance and optimum Resources utilization. MultiProtocol Label Switching (MPLS) technology allows traffic engineering and enhances the performance of the existing protocols over the traditional IPv4 network [1, 2]. The central II. 2.
TRAFFIC MANAGEMENT In this simulation, the default specifications for G. 711 (64) codec has been considered , where bidirectional Constant Bit Rate (CBR), User Datagram Protocol (UDP) are used as Voice over IP services and idea of MPLS is to attach a short fixed-length label to packets at the ingress router of the MPLS domain. Packet forwarding then depends on the tagged label, not on longest address match, as in traditional IP forwarding. A router placed on the edge of the MPLS domain, named Label Edge Router (LER) that is associated to a label on the basis of a Forwarding Equivalence Class (FEC).
In the MPLS network, internal routers that perform swapping and label-based packet forwarding are called Label Switching Routers (LSRs) . Since MPLS by itself cannot provide service differentiation, combination of DiffServ with MPLS architectures seems to be a useful solution to provide QoS to multimedia traffic while effectively using network resources. The result of this integration is the DiffServ-aware Traffic Engineering (DS-TE). In order to enable DS-TE functionalities, DiffServ, MPLS and TE-related information have to be exchanged among routers through the control plane by means of a dynamic signaling protocol.
Three signaling protocols are used in MPLS networks: (i).? Label Distribution Protocol (LDP) , (ii).? Constraint based Routing LDP (CR-LDP)  and (iii).? Resource Reservation Protocol – Traffic Engineering (RSVP-TE) [1, 6]. The focus of the paper is on the comparative performance analysis between conventional and MPLS network. This paper is organized as follows. Section 2 describes the Traffic management. The simulation arrangements based on topology, traffic pattern and demonstration of numerical results are given in Sec. 3. Finally the conclusion is presented in Sec. 4. 78-1-4244-1692-9/08/$25. 00 ©2008 IEEE 226 streaming media . It should be noted that for any given codec, as the voice payload per packet is increased while the net bandwidth use is reduced. Fewer packets are needed to transmit the same amount of data that reduce the net overhead . The calculations are computed as follows: Voice packet size = layer 2 header + (IP + UDP + RTP) Header + voice payload. Voice packets per second = codec bit rate / voice payload size Bandwidth = voice packet size x voice packets per second. In this experiment, compression of IP, UDP and RTP headers for G. 11 (64) codec are not taken into consideration. Thus the UDP packet size in bytes = UDP header + RTP header + voice payload = 8 + 12 + 160 = 180bytes. For the Largest Packet Size, Ethernet MTU size packets are considered. Ethernet MTU = 1500bytes. Of these 1500 bytes, the IP headers use 20bytes, leaving 1480 bytes for the UDP packet (including header and payload). Thus UDP packets of 1480bytes are considered. And for creating worst scenario, another UDP packet of 830 bytes and Drop Tail queue type have also been considered. III. 3.
SIMULATION AND PERFORMANCE ANALYSIS We have used NS2 to create the topology as shown in figure 1 for both traditional and MPLS networks. The simulation has been developed to emphasize the impact of Traffic Engineering over the traditional network. Nodes 0 and 1 are used as source and nodes 6 and 7 are used as destination. The information table 1 of node LSR2 act as Label Edge Router (LER) shown below, where egress router characterize FEC, label and LSPID. Labels of this table are distributed based on the control mode that is chosen to be executed at node LSR2.
During packet transmission, label swapping is done by each intermediate node. Routing information is stored in LIB, PFT and ERB tables using mapping message from egress router to ingress router(LSR2 to LSR7) and vice versa. Figure 2: Symmetric Network without MPLS In MPLS network, node 2 to node 5 is defined as LSR nodes. We have considered LSR2 as ingress and LSR5 as egress where the path through node 2_3_5 considered as shortest path. Due to the congestion at node 2, traffic engineering is applied for MPLS network. Traffic follows the alternative path (via node 2_3_5).
Figure 3: Symmetric Network with MPLS Figure 1: Simulation Topology In traditional network path (via node 2_4_5) is not utilized, while path (via node 2_3_5)is over utilized. Packets are lost due to congestion at node 2 and we have observed same situation when no traffic engineering is applied for MPLS network. A. ANALYTICAL REPORT The figure 4 below shows the throughput of received packets (MB) for each flow of traffic from source nodes before applying traffic engineering where received level is approximately 0. 9 MB for node 6 and 0. 6 MB for node 7. 227
TABLE I. VARIOUS TYPES OF TABLE FOR MPLS NETWORK PFT dump___ [node: 2] ——————————————–FEC PHB LIBptr AltanativePath 7 -1 0 -1 ERB dump___ [node: 2] ——————————————–FEC LSPid LIBptr 5 3600 0 5 3700 1 LIB dump___ [node: 2] ——————————————–# iIface iLabel oIface oLabel LIBptr 0: -1 -1 4 1 -1 1: -1 -1 4 2 -1 After applying the Traffic Engineering in MPLS, network congestion as well as packet received level is improved. Traffic follows the path (via nodes 2_4_6) as an explicit route.
Throughput of MPLS network shown in figure 5 where received level is approximately 1. 4 MB up to 3 sec then the curve slowly goes down at 4. 5 sec it is almost 1 MB for node 6 and almost 1 MB for node 7. TABLE II. COMPARISONS OF PACKETS (IN BIT) BEHAVIOR BETWEEN TRADITIONAL AND MPLS NETWORK Packet type Total CBR Packet send Total CBR Packet receive Total CBR Packet drop Traditional (bit) 4567280 3876930 642670 MPLS (bit) 5389310 5105790 221410 Figures (6 and 7) below show (graphically) the number of packet drop behavior for both Traditional and MPLS network with respect to time.
Figures (6 and 7) indicate the rapid fluctuation of packets. The average number of packets drop are approximately 6 and 2 for traditional and MPLS network respectively. Figure 4: Throughput of a traditional network. Figure 6:Packet drop Behaviors of Traditional Network Figure 7:Packet drop Behaviors of MPLS Network Figure 5: Throughput of a MPLS network. Table given below shows the total number of packets transmitted from sources, received by 228 destination nodes and dropped due to congestion for both traditional and MPLS network. Packet loss is much less in MPLS network than that of traditional network. IV.
CONCLUSION This paper has been prepared based on the traffic flow over both conventional and MPLS network, where network topology and other simulation parameters are chosen as common to establish the better performance of MPLS network over traditional network. Based on the comparison of signaling protocols, it can be found that RSVP has drawback in its scalability that is one reason for choosing CR-LDP for MPLS protocol. The results are obtained after some experimentation and calculation with network scale (number of nodes, link capacity and delay) and traffic arrangements (sources and packet sizes, and CBR packet arrival rates).
As expected, packet transmissions (in terms of both delay and loss) are improved in MPLS network. Although the chosen parameters can be disputed to be artificially extreme, the traffic engineering mechanism improves the performance of general delay and loss. REFERENCES        Analysis of MPLS traffic engineering – Circuits and Systems, 2000, www. ieeexplore. ieee. org/iel5/7554/20602/00952816. pdf Independent study report Study of Traffic Engineering Algorithms, www. ieee. unlv. edu/~venkim/opnet/IndependentStudy. df Signaling Protocols in DiffServ-aware MPLS Networks: Design and Implementation of RSVP-TE Network Simulator, www. ieeexplore. ieee. org/iel5/10511/33286/01577748. pdf L. Andersson et al. LDP Specification, IETF RFC, 3036, January 2001 B. Jamoussi et al. Constraint-Based LSP Setup using LDP, IETF RFC,3212, January 2002 D. Awduche et al. RSVP-TE: Extensions to RSVP for LSP Tunnels, IETF RFC 3209, December 2001 “Voice over IP – Per Call Bandwidth Consumption”. http://www. cisco. com/warp/public/788/pkt-voicegeneral/bwidth_consume. html 229