MPLS/IP Analysis and Simulation for the Implementation of Path Restoration Schemes

Transcription

1 MPLS/IP Analysis and Simulation for the Implementation of Path Restoration Schemes V. ALARCÓN-AQUINO, Y. L. TAKAHASHI-ITURRIAGA, J. C. MARTÍNEZ-SUÁREZ, L. G. GUERRERO-OJEDA Departamento de Ingeniería Electrónica y Mecatrónica Universidad de las Américas, Puebla Ex -Hacienda Santa Catarina Mártir San Andrés, Cholula Puebla MEXICO Abstract: Traditionally, IP (Internet Protocol) has been routed over ATM (Asynchronous Transfer Mode) via Virtual Circuits (VCs) or Multi-Protocol over ATM (MPOA). These methods proved to have a complicated operation mode, reason why the necessity for a simpler method was felt. All these necessities can be supported by the Multi-Protocol Label Switching (MPLS) since it integrates the most important characteristics of layers 2 and 3 of the OSI model. This paper explains and analyzes the concepts of MPLS, as well as performing a simulation and comparison of path restoration schemes using Network Simulator (NS). The results show the advantages of working over a connection-oriented technology (MPLS) by supporting a more efficient rerouting scheme for link failures. Key-Words: IP, MPLS, ATM, network simulator, path restoration schemes, path protection schemes. 1 Introduction During the last years, the Internet growth has taken an exponential and unstoppable course; at the same time there has been an increasing demand of new and more sophisticated services, reason why the technology has had to undergo fundamental changes with respect to the usual practices developed in the mid 90s. In this super-growth environment, the Internet Service Providers (ISPs) must find a way to adjust the dramatic growth of network traffic and number of users. There are several factors that have contributed to the demand for larger bandwidth capabilities. More and more businesses are being done on the Internet, most of the firms in every industry are looking at the Internet as a way to improve business processes and reduce the cost of doing business with partners and customers. The number of Internet users around the world is growing rapidly as well: the Computer Industry Almanac reports that in 2002, 490 million people around the world had Internet access or 80 per 1000 people worldwide. This ratio will grow to 118 people per 1000 by year 2005 [10]. Furthermore, an aspect that feeds this accelerated growth in the demand is the best effort nature of the Internet, in which access and distribution of contents services are emphasized instead of data transport services. But there is a growing demand for services that require a higher level of capability, especially higher predictability from the Internet (a more deterministic and less random answer). Service Level Agreements (SLAs) written to meet Layer 2, Layer 3, and even Layer 4 parameters are being request by customers to fulfill this bandwidth demand [10]. As Internet is already supporting these requirements, the demand for these applications is also increasing. To avoid having equipment specifically designed for the new Internet applications, ISPs had to adapt any commercially available equipment. The best option seemed to be to increase the performance of the traditional routers. As infrastructure, the ATM switching equipment was the only technology that provided the required bandwidth, the packet forwarding capacities, and traffic engineering. The idea was to combine, in many ways, the effectiveness and yield of the ATM switches with the control capabilities of IP routers. The answer was the deployment of the IP over ATM Model (IP/ATM). The IP/ATM operation supposes the overlapping of a logical topology of IP routers over a physical topology of ATM switches. The main advantage of IP/ATM is that executes the translation from a connectionless based IP data transfer to a connection-oriented based ATM data transfer. The solution of implementing IP over ATM allows taking advance of the ATM infrastructure, its bandwidth, available with competitive prices, and the data transport rapidity provided by ATM switches. On an IP network the network engineers must configure, support and manage an IP topology at least. On IP/ATM networks in addition they have to manage the ATM plane. Although

2 for some ISPs the separation of control planes satisfies their necessities of a separated ATM backbone management and IP NAS (network access services), for providing stability and predictability to the network, it is also true that the topology overlapping produces greater costs for network deploying. So it is important to notice that, although IP/ATM has important advantages produced by the integration of Layer 2 and Layer 3, this is made in a discontinuous way, with the inconvenient of the maintenance of two separated networks. Another limitation of deploying the IP over ATM model is the cell tax problem, created when breaking down IP packets into 53-bytes cells comprised of 48 byte payloads and 5 bytes of overhead [10]. This tax produces a reduction of 20% on the available bandwidth. The solution that IP/ATM introduces for meeting the cell tax problem is the increasing of interconnection IP nodes. This solution creates as well the problem of exponential growth n ( n 1) of the number of nodes that form the network; this slows down the process of packet forwarding made by the corresponding protocols, and so the necessity for a new technology that meets these demands. The remainder of this paper is organized as follows. Section 2 presents a description and operation of the MPLS protocol. In Section 3, a description of different path protection and restoration schemes are introduced. Simulation results for different path restoration schemes under different scenarios are reported in Section 4. In Section 5, conclusions of this paper are presented. 2 Multi-Protocol Label Switching (MPLS) In this section, we present a description and operation of the MPLS protocol. MPLS [12] is an Internet Engineering Task Force (IETF) framework [5] that provides specifications for the routing, forwarding and switching of traffic flows through a network. MPLS combines the performance and capabilities of Layer 2 (data link layer) switching with the scalability and IP capabilities of Layer 3 (network layer). As a connection-oriented technology, MPLS enables IP-centric networks to be more predictable and efficient through load-sharing of traffic across multiple links in a network, enables ISPs to avoid bottlenecks (link congestion) by providing a level of traffic engineering, enables higher levels of service to customers by allowing flow prioritization and resource preemption, enables fast rerouting schemes to offer high network availability, and eliminates the problem of managing different control planes formed in IP/ATM networks [10]. 2.1 MPLS Components MPLS is based on the label switching technology that can be characterized by its use of label swapping packet forwarding, combined with IP control protocols and a label distribution protocol. A label is a short fixed-length underlying protocol-specific identifier for a path that a packet should traverse. High speed switching of data is possible by the insertion of these labels at the beginning of the packet and this can be used by hardware to switch packets quickly between links [12]. To deploy MPLS in an IP network, the shim header is inserted between the layer 2 and the layer 3 headers. Fig.1 shows the insertion of the shim header. The label field includes the physical label that identifies the packet. The EXP field is used for QoS (Quality of Service) implementations. The S field is used to indicate if label stack is present. The TTL field prevents packets from looping forever in the network [12]. Fig. 1 MPLS shim header. In MPLS, data transmission through the network occurs on Label Switched Paths (LSPs). LSPs are a sequence of labels at every node along the path, from the traffic source to its destination [6]. LSPs are established either prior to data transmission (control-driven) or upon detection of a certain flow of data (data-driven). Label Switching Routers (LSRs) are the devices that participate in the MPLS protocol mechanisms. LSRs are highperformance routers that provide fast packet forwarding by performing the label swapping process, and are located at the core of the network [14]. Label Edge Routers (LERs) are devices that operate at the edge of the MPLS network. LERs have a very important function in the label distribution process when a packet ingresses the MPLS network, and in the removal of labels when a packet leaves the network to the corresponding access network. The Forwarding Equivalence Class (FEC) is an identifier for a group of packets that share the same requirements for their transport and are forwarded in the same way through a MPLS network [12]. FECs are built with information generated by an Interior Gateway Protocol (IGP), such as Open Shortest Path First (OSPF). Fig. 2 shows the standard components that form an MPLS

3 network. In order to support hierarchal routing, MPLS uses the label stack. The label stack is a set of labels attached to a packet organized in a LIFO (Last In First Out) structure. This stack allows MPLS to operate in tunneling 1 mode. Fig. 2 MPLS components. 2.2 MPLS Operation As a packet enters the MPLS domain it has to be submitted to several processes in order to reach its final destination. The first process consists in the creation of label bindings for the label distribution. Once the label has been created by the LER, the label must be bound to a certain FEC in order to create the label binding. Since the assignment of a particular packet to a particular FEC is done just once, it is thus important to use a connectionoriented protocol. The second process is the label distribution. A LDP (Label Distribution Protocol) is a set of procedures by which one LSR informs another of the label/fec bindings it has made. Two LSRs which use a label distribution protocol to exchange label/fec binding information are known as label distribution peers with respect to the binding information they exchange [2]. There are several protocols that can be used for label LDP [9], Border Gateway Protocol (BGP), constraint-based LDP (CR-LDP), and Resource ReSerVation Protocol (RSVP), the last two for traffic engineering. The decision to bind a label to a particular FEC is made by the LSR which is downstream with respect to that binding. Thus the labels are downstream assigned, and label bindings are distributed in the upstream direction [2]. Once the bindings have been created, every LSR creates a Label Information Base (LIB) which is a table that contains information about the labels (incoming, outgoing) and interface mappings. Table 1 illustrates an example of a LIB. The next step is the creation of the LSPs with help of the Next Hop Label Forwarding Entry (NHLFE) table. The NHLFE table is used for the process of forwarding 1 This is a unique feature of MPLS for controlling the entire path of a packet without specifying the intermediate routers. labeled packets because its information can be processed by hardware as layer 2 data. An example of label assignation and distribution with the utilization of NHLFEs is shown in Fig. 3. It can be seen that the label distribution is preformed by the label manager, and the NHLFE is used at every LSR of the LSP created. The last process is the packet forwarding through the LSP in upstream direction. The inbound LER forward the labeled packets to their next hop and then the subsequent LSRs execute the label swapping operation in order to forward the packet to the egress LER. The outbound LER will execute a label pop (removal) and delivers the packets to its final destination. Fig. 4 shows the forwarding of packets towards the egress LER (label manager). Table 1. A Label Information Base. Incoming Incoming Outgoing Outgoing Interface Label Interface Label Fig. 3 Setup of LSP with label distribution Fig. 4 Packet forwarding.

4 2.3 MPLS Traffic Engineering Traffic engineering is a process that enhances network utilization by attempting to create a uniform or differentiated distribution of traffic throughout the network [6]. The result of this process is the avoidance of congestion in a certain path. It is important to understand that traffic engineering does not necessarily choose the shortest path between two hops [13]. In MPLS there are two approaches for implementing traffic engineering: Traffic Engineering RSVP (TE-RSVP) and CR-LDP. 3 Path Protection and Restoration When working with real networks, path congestion and link failure are very recurrent problems. It is thus important to the network manager to support path protection and restoration schemes. There are three schemes for path restoration: Haskin s scheme [15], Makan s scheme [1] and simple-dynamic scheme. The first two schemes have a pre-negotiated protection configuration -setup of backup paths prior to packet forwarding- whereas the dynamic scheme has a dynamic configuration [4]. The Haskin and Simple-Dynamic schemes are compared in this paper. When using simple-dynamic path restoration scheme and a link failure occurs, the node that detects the failure establishes a backup path by rerouting the traffic flow through the nearest usable link towards the destination node. In this scheme, the setup time of the backup path is long, so there is a considerable loss of packets during this time. In case of using Haskin s scheme [4,15] for path restoration, the backup path used when a failure occurs is predefined before data transmission starts. Two explicit LSPs are created, from the ingress LER to the egress LER and viceversa; this forms a protection loop that will function as a backup path in case of link failure. This scheme supports fast reroute, so there is not a big packet loss when a setup of backup path exists. 4 Simulations 4.1 Simulation Aims and Tool The aim of simulating MPLS on IP based networks is to use the features of MPLS for implementing a more efficient rerouting scheme and compare it with the commonly used by IP networks. The MPLS capability of creating explicit routes (traffic engineering) is the reason for using this technology as the backbone architecture. The simulation tool used consists of the Network Simulator version 2 (NS) [8]. NS is an event driven network simulator developed at the University of California at Berkeley that simulates variety of IP networks. The MPLS Network Simulator (MNS) was implemented by Gaeil Ahn [3], and is present in the current releases of NS-2. Further details and understanding of NS language can be found in [11]. 4.2 Simulation parameters In order to make a representative comparison between the path restoration schemes two scenarios were simulated, one topology with IP nodes, and another (same topology) with MPLS nodes. Fig. 5 shows the topology of the first scenario (A). Fig. 5 Scenario A topology. It can be seen that there are 13 IP nodes in the network, 11 nodes (n1-n11) that form the core network, the node n0 that operates as the traffic source, and the node n11 which is the traffic sink (destination). All the links between nodes are defined as duplex-links, a delay of 10ms, and with a drop-tail queue. Most of this links have a 1Mbps bandwidth (BW), but the links n5-n5 and n8-n9 have a 0.5Mbps BW. Two types of traffic are generated at n0, a User Datagram Protocol (UDP) traffic attached to a Constant Bit Rate (CBR) agent, and a Transfer Control Protocol (TCP) traffic attached to a File Transfer Protocol (FTP) agent. In this scenario a link failure is simulated, so a path restoration scheme must be established. As explicit routing is not supported by IP routing, there is only one option for path restoration: simple-dynamic scheme. This scheme is implemented with the dynamic Distance Vector (DV) routing protocol. The event scheduling for both scenarios is defined as follows: At 0.1 seconds, the CBR traffic starts. At 0.2 seconds, the FTP traffic starts. At 0.3 seconds, there is a failure at link n2-n3. At 0.5 seconds, link n2-n3 is restored, and link n7-n8 is down.

5 At 0.6 seconds, link n7-n8 is restored. At 0.7 traffic flows stop, end of simulation. Fig. 6 shows the topology of the second scenario (B). The same topology is used, but in this example, all core nodes are replaced with MPLS LSRs. Also, link capacities are the same. A are shown in Fig. 7(c). This data is the result of monitoring the CBR traffic sink agent attached to node 12. There is a considerable stable behavior of the bandwidth during the traffic flow, but there is also a delay in propagation time. When link failures occur there are packet loss problems because there is a log path setup time, this is reflected in the bandwidth at the destination node. The number of packets received at node 12 is 93. Fig. 6 Scenario B topology. In scenario B, events are equally defined, but there are three added events, these events represent the implementation of the Haskin scheme for path protection and restoration [4,7,15]. The added events are: At 0.1 seconds, the explicit route n4-n1-n2-n3- n10-n11 (ER1) is created. A1 0.2 seconds, the explicit route n11-n10-n9- n8-n7-n4-er1 (ER2) is created. At 0.3 seconds, a reroute binding is created between n9 and n12 with the explicit route (ER2). This is to simulate Haskin s model. 4.3 Simulation Results Once the simulation parameters have been completed, the simulated events can be visualized using the Network Animator (NAM) [11]. In scenario A, there is an IP network, so when link failure occurs there is a long LSP setup time and a considerable packet loss. Fig. 7 shows the events and results for scenario A. Fig. 7(a) shows the event when link n2-n3 fails, and also shows the loss of packets at link n1-n2. The DV routing protocol establishes a new path for the CBR traffic through the down-oriented nodes (n4-n7-n8-n9-n10-n11-n12). Fig. 7(b) illustrates the event when link n2-n3 is restored and link n7-n8 fails. It can be seen that there is also a packet loss and a path restoration through the central nodes (n4-n5-n6-n3-n10- n11-n12) in this case. The simulation results for both scenarios are in the form of bandwidth with bandwidth in Mbps in Y-axis and time in seconds in the X-axis. The results for the scenario Bandwidth Fig. 7(a) First link failure on scenario A. Fig. 7(b) Second link failure on scenario B. Time Fig. 7(c) Scenario A results. For scenario B, same events are visualized with NAM, these events and the results are shown in Fig. 8. All events occur exactly like scenario A until 0.5 seconds; after link n7-n8 fails one can observe the advantages of using Haskin s model for path restoration. Fig. 8(a) shows the event when path is being restored after the link failure. First, there is a short length flow of packets that follows

6 the same route used in scenario A, but then the predefined backup path (n4-n1-n2-n3-n10-n11-n12) is used as the working path and keeps that way until the end of simulation. Fig. 8(b) shows the simulation results of scenario B. There are visible changes in the bandwidth received at the destination node 12. A more stable curve is presented, where the reception of packets is lost for a few instants after the link failures, but since there is a short LSP restoration time, the network recovers quickly. In case of scenario B, the number of received packets at the traffic destination node is 102. Compared with the scenario A, there is a considerable improvement in the prevention of packet loss. So it is understandable to say that the implementation of Haskin s model using the explicit routing support of MPLS is the better choice for preventing packet loss and protecting working paths. Bandwidth Fig. 8(a) Link failure and path restoration in scenario B. Time Fig. 8(b) Scenario B results. 5 Conclusions In this paper a MPLS architecture analysis has been presented, which allows to determinate the characteristics, components, operation and applications that makes this technology the solution for meeting traffic engineering requirements. A presentation of a simulation environment, which allows a performance simulation in IP and MPLS based networks have also been presented. The simulation underlines the explicit routing capabilities of MPLS for the implementation of Haskin s scheme of path protection and restoration. This shows that using Haskin s model helps in the avoidance of packet loss. Future work will concentrate on simulation and comparison with ATM networks, and with larger and more realistic topologies and traffic sources. References: [1] C. Cheng Huang, V. Sharma, S. Hakam, K. Owens, A Path Protection/Restoration Mechanism for MPLS Networks, Internet Draft, July [2] E. Rosen, A. Viswanathan, and R. Callon. Multiprotocol Label Switching Architecture, RFC January 2001 [3] G. Ahn, W. Chun, Design and Implementation of MPLS Network Simulator. Chungnam National University of Korea, February 2001 [4] G. Ahn,W. Chun, Simulator for MPLS Path Restoration and Performance Evaluation, Chungnam National University, Korea, April 2001 [5] IETF, IETF MPLS Charter, [6] International Engineering Consortium, MPLS Tutorial, IEC, [7] J. Shrader, MPLS Simulation Template, Network Simulator NS, Netherlands, [8] K. Fall, The NS Manual, VINT Project. December [9] L. Anderson, P. Doolan, N. Feldman, A. Fredette. LDP Specification, RFC 3036, January [10] Marconi white paper, Building scalable Service Provider IP Networks, Connection-Oriented Networking Solutions, July [11] Network Simulator Homepage, [12] Nortel Networks, MPLS An introduction to Multi-protocol Label switching, Nortel Networks mkt. publications, April [13] P. Christensen, R. Pulley, A Comparison Of MPLS Traffic Engineering Initiatives, NetPlane Systems, Inc [14] R. Law, S. Raghavan, Diffserv and MPLS Concepts and Simulations, Virginia Polytechnic Institute and State University, April [15] D. Haskin, R. Krishnan, A Method for Setting an Alternative Label Switched Path to Handle Fast Reroute, Internet Draft, May 2000.