UNIVERSITY OF NAIROBI DEPARTMENT OF ELECTRICAL AND INFORMATION ENGINEERING SIMULATION OF MULTI-PROTOCOL LABEL SWITCHING. Project Index: 124

Transcription

1 UNIVERSITY OF NAIROBI DEPARTMENT OF ELECTRICAL AND INFORMATION ENGINEERING SIMULATION OF MULTI-PROTOCOL LABEL SWITCHING Project Index: 124 By Geoffrey Omeke Mosongo F17/2367/2009 Supervisor: Dr. G.S.O Odhiambo Examiner: Prof. V.K Oduol Project report of the final year project towards partial fulfillment of the requirements for the degree of Bachelor of Science in Electrical and Electronic Engineering of the University of Nairobi Submitted on: April 28, 2014

2 DECLARATION OF ORIGINALITY NAME: MOSONGO GEOFFREY OMEKE REGISTRATION NUMBER: F17/2367/2009 COLLEGE: Architecture and Engineering FACULTY/SCHOOL/INSTITUTE: Engineering DEPARTMENT: Electrical and Information Engineering COURSE NAME: Bachelor of Science in Electrical and Electronic Engineering TITLE OF WORK: Computer Simulation of Multiprotocol Label switching 1) I understand what plagiarism is and I am aware of the University Policy in this regard. 2) I declare that this final year project report is my original work and has not been submitted elsewhere for examination, award of degree or publication. Where other people s work or my work has been used, this has properly been acknowledged and referenced in accordance with the University of Nairobi s requirements 3) I have not sought or used the services of any professional agencies to produce this work 4) I have not allowed, and shall not allow anyone to copy my work with the intention of passing it off as his/her own work 5) I understand that any false claim in respect of this work shall result in disciplinary action, in accordance with the University anti-plagiarism policy Signature:... Date:... [i]

3 ABSTRACT Multiprotocol Label Switching (MPLS) is a ubiquitous technology used by Internet Service Providers and enterprise networks to forward packets. This project shall present a description of Multiprotocol Label Switching architecture and its functionality through a computer simulation model. An MPLS network will be simulated and its performance measured. Analysis of results related to latency, link utilization, amount of traffic in the Label Switched Paths (LSPs) and throughput within nodes in the network shall be done to show the key performance metrics of MPLS. The simulation tool used in this project is OPNET Modeler version 14.5 from Riverbed Technologies. [ii]

4 ACKNOWLEGEMENT I would like to thank my parents for their encouragement and prayers during the time I was undertaking this project. Their enormous support gave me the energy and ability to complete this task. I would also like to thank my project supervisor Dr. GSO Odhiambo for all the guidance that he accorded me during this period. I would also like to recognize Mr. Paul Msava and Mr. Eric Gaitho from Safaricom Limited for their guidance and support that enabled me complete this work successfully, may God Almighty bless them in their endeavors. This project work is dedicated to the final year Electrical Engineering class of 2014 at the University of Nairobi for all the best moments we had together. [iii]

5 Table of Contents DECLARATION OF ORIGINALITY...i ABSTRACT... ii ACKNOWLEGEMENT... iii Table of Contents...iv LIST OF FIGURES...vi ABBREVIATIONS... viii 1. INTRODUCTION SHORTEST PATH ROUTING PRINCIPLE Shortest path routing principle and its drawbacks MPLS TECHNOLOGY OVERVIEW MPLS Label MPLS Network Architecture Label Switched path (LSP) Forwarding Equivalence Class (FEC) Label Distribution Protocol (LDP) MPLS Control Plane and Forwarding plane Path Determination Offline Path calculation Constraint-Based Routing (CBR) MPLS Signaling Protocols LDP CR-LDP Label Merging Traffic Engineering in MPLS Networks Distribution of Topology information Path selection Directing traffic along the computed paths Traffic Management...14 NETWOTK MODEL AND SIMULATION Simulation Tool OPNET Model Configuration Objects OPNET Simulated Application Traffic Network Topology Description of the Topology OSPF Simulation Scenario RESULTS Analysis and Discussion OSPF Throughput...23 [iv]

6 4.8.2 Queuing delay MPLS Simulation Scenario MPLS SCENARIO RESULTS Analysis and Discussion Throughput Queuing delay CONCLUSION REFERENCES APPENDIX APPENDIX A: PROCEDURE FOR MODELLING OSPF EXPERIMENT APPENDIX B: PROCEDURE FOR MODELLING MPLS EXPERIMENT...37 [v]

7 LIST OF FIGURES Fig 2.1 Illustrated architecture of a backbone of an ISP... 3 Fig 2.2 Illustrated model of an Autonomous system... 3 Figure 2.3 Forwarding based on shortest path (minimum cost)....5 Figure 2.4 Illustration of under-utilized paths in the backbone 6 Figure 2.4 Illustration of optimized backbone link utilization... 6 Fig. 3.1 MPLS Header...7 Fig. 3.2 MPLS Network Architecture and node types...8 Fig. 3.3 MPLS Network Illustration. 10 Fig 4.1: Overview of the experiential network model...19 Fig 4.2 TCP and UDP Throughput (Bits/second..21 Fig 4.3 TCP and UDP Throughput (Packets/second)..21 Fig 4.4 Throughput Shortest Path (bits/sec)..21 Fig 4.5 Average Link Utilization Shortest path 21 Fig 4.6 Queuing delay shortest path.22 Fig 4.7 Queuing delay longest path 22 Fig 4.8 Utilization Longest Path...22 Fig 4.9 Longest path Throughput (bits/sec)...22 Fig 4.10 Network for MPLS simulation scenario..25 Fig 4.11 TCP and UDP Throughput (Bits/second)...27 Fig 4.12 TCP and UDP Throughput (Packets/second).27 Fig 4.13 Traffic In and Out of PE_1 -PE_2 (Bits/second)...27 Fig 4.14 Average LSP PE_1 - PE_2 Delay (sec)..27 Fig4.16 LSP PE_1 PE1_2 1 Delay (sec) 28 [vi]

8 Fig 4.15 Traffic In and Out of PE_1 -PE_2 1 (Bits/sec)...28 Fig 4.17 Traffic In and Out of PE_2 -PE_1 (Bits/second)...28 Fig4.18 LSP PE_2 PE_1 Delay (Seconds) 28 Fig 4.19 Traffic In and Out of PE_2 -PE_1 1 (Bits/second) 29 Fig 4.20 LSP PE_2 PE1_1 1 Delay (sec)..29 [vii]

9 ABBREVIATIONS CSPF Constraint Shortest Path First CR-LDP Constraint based Label Routing Protocol FEC Forward Equivalence Class IP Internet Protocol IPv4 -- Internet Protocol version 4 ISIS Intermediate System to Intermediate System IGP Interior Gateway Protocol LDP Label Distribution Protocol LER Label Edge Router LFIB Label Forwarding Information Base LSP Label Switch Path LSR Label Switch Router MPLS Multi Protocol Label Switching OPNET Optimized Network Engineering Tool OSPF Open Shortest Path First RSVP Resource Reservation Protocol SPF Shortest Path First TCP Transmission Control Protocol TE Traffic Engineering TED Traffic Engineering Database UDP User Datagram Protocol VPN Virtual Private Network [viii]

10 1. INTRODUCTION In the recent past there has been an enormous growth in the use of Internet. This rapid growth has made a huge impact on the type of services requested from consumers and the kind of performance they demand from the services they wish to use. Consequently as service providers encourage businesses on the Internet, there has been a requirement for them to develop, manage and improve IP- network infrastructure in terms of performance. Therefore, the interest of traffic control through traffic engineering has become important for ISP s. Multi-Protocol Label Switching (MPLS) is an emerging technology which plays an important role in the next generation networks by providing Traffic Engineering (TE). It overcomes the limitations like excessive delays and high packet loss of IP networks by providing scalability and congestion control. Due to the low latency and low packet loss during routing of packets MPLS is considered ideal for mission critical applications. Today s networks often function with well-known shortest path routing protocols. Shortest path routing protocols as their name implies, are based on the shortest path forwarding principle. In short, this principle is about forwarding IP- traffic only through the shortest path towards their destination. At one point, when several packets destined from different networks start using the same shortest path, it may become heavily loaded. This will result in congestion within the network. Various techniques have been developed to cope with the shortest path routing protocols shortcomings. However, recent research has come up with another way to deal with the problem. With traffic engineering, one can engineer traffic through other paths than the shortest path. The network carries IP-traffic, which flows through interconnected network elements, including response systems such as protocols and processes. Traffic engineering establishes the parameters and operating points for these mentioned elements. Internet traffic leads to control problem. Therefore a desire and need for better control over the traffic may be accomplished with help of Traffic Engineering (TE). The main objective of this project is to study and understand Multiprotocol Label Switching architecture and functionality. The specific objectives are: Page 1

11 Designing a topology to simulate an MPLS network Choosing the performance parameters such as latency, link utilization, amount of traffic in the Label Switched Paths (LSPs) and throughput within nodes Analysis of the results and showing them graphically In order to outline the performance achieved by traffic engineering, it was necessary to start by giving a description of the shortest path routing principle and its drawbacks. Then, the architecture of Multiprotocol Label Switching shall be presented together with its functionality. After giving a description of the technology, the simulation network is presented to measure its performance. Initially, the network is configured to run shortest path routing protocol OSPF. To measure performance outbreaks, TCP and UDP traffic is generated to measure their treatment under a heavily loaded network. Then, the same network with its traffic once again is used, this time implementing Multiprotocol Label Switching to engineer the flows to separate paths. Results collected from both scenarios are then analyzed and shown graphically. Page 2

12 2. SHORTEST PATH ROUTING PRINCIPLE The internet today consists of multiple service providers network connected to each other, forming a global network communication infrastructure. This infrastructure enables people around the world to communicate with each other through interconnected network devices. These devices are set up to process any data that traverse through them. The devices or nodes are often formed in logical and hierarchical way. With customers networks connected to a node or a router often called customer edge router (CE) at one end, and to an Internet service provider s (ISP) network edge router, which is referred to as provider edge router (PE) at the other end. The core routers within the provider s network form the inner routers forwarding packets a step closer to its destination. These often smaller autonomous systems (AS) are then connected to more powerful networking area referred to as the backbone. The backbone often carries the extensive amount of traffic that is to be transmitted or/and received between AS s. An example over such architecture is given in the figure below. Fig 2.1 Illustrated architecture over backbone of an ISP Fig 2.2 Illustrated model of an Autonomous system Page 3

13 An AS may look like the one illustrated in figure 2. In order to make right delivery of packets received from the customer s networks, routers must exchange information with each other. In short, the routing and forwarding mechanism is primarily divided into three processes. The first process is mainly responsible for exchanging topology information. This is needed for the second part of the process, which is the calculation of routes. Calculation happens independently within each router to build up a forwarding table. The forwarding table enables processing incoming packets to be forwarded towards its destination. The forwarding table is used when a packet is being forwarded and therefore must contain enough information to accomplish the forwarding function. Within an AS, routing is based on Interior Gateway Protocols (IGPs) such as Routing Information Protocol (RIP) [5], Open Shortest Path First (OSPF) [3] and Intermediate SystemIntermediate System (IS-IS) [6]. RIP is based on the distance vector algorithm and always tries to find the minimum hop route. Routing protocols such as OSPF and IS-IS are more advanced in the sense that routers exchange link state information and forward packets along shortest path based on Dijkstra s algorithm [2]. In short, Dijkstra s algorithm computes the shortest path from every node to every other node in the network that it can reach. This is of course a highly simplified description. With help of Dijkstra s algorithm, every node can compute the shortest path tree to every destination [2]. 2.1 Shortest path routing principle and its drawbacks The shortest path routing principle imposes some drawbacks within the routing area. The scenario in Figure 2.3 illustrates the forwarding of packets based on the shortest path algorithms. Looking at the figure 2.3, it can be assumed that routers 1, 2, 3, and 4 form a smaller piece of a larger AS or backbone. Traffic is coming in from both R_1 and R_2 and destined for the same terminating router R_7 through router R_7. In this case, congestion may appear after a while between router R_3 and router R_4 since all the packets are sent over the minimum cost (high bandwidth) path to its destination. It uses only one path per source destination pair, thereby potentially limiting the throughput of the network [2]. To give an example of the impacts this may pose in the network, the following is considered: It is known that TCP connections tend to lower their transfer rate when signs of congestion appears, consequently making more room for UDP traffic to fill up the link and suppress the Page 4

14 TCP flows [4]. This causes the UDP traffic sent by one of the sources suppress the TCP flows sent by the other sources. Clearly, the situation can be avoided if the TCP and UDP traffic choose different non-shortest paths to achieve a better performance. Congestion in the network is caused by lack of network resources or uneven load balancing of traffic. The latter one is the one that can be remedied by traffic engineering, which is the major advantage of MPLS. If all packets sent from customers use the same shortest path to their destination, it may be difficult to assure some degree of QoS and traffic control. There are of course ways to support every single traffic flow with different technologies to assure QoS. For instance, a signaling protocol may be used to reserve resources for a certain flow travelling through the network, but this will only be per-flow basis and when many of these are configured it makes it impractical for an ISP to manage and administer, since it isn t a scalable solution [7]. This can be proven by a simple formula, which states that if there exist N routers in the topology and C classes of services, it would be needed (N* (N-1) * C) trunks containing traffic flows [7]. Figure 2.3 Forwarding based on shortest path (minimum cost) The other problem with the shortest path routing protocols is the lack of ability to utilize the network resources efficiently [1]. This is not achieved by the shortest path routing protocols since they all just depend on the shortest path [1]. This is illustrated in the below figure, where packet from both networks connected to R2 and R8 traverse through the path with minimum cost, leaving other paths underutilized. Its capability to adapt to changing traffic conditions is limited by oscillation effects. If the routers flood the network with new link state advertisement messages based on the traffic weight on the links, this could result in changing the shortest path Page 5

15 route. At one point, packets are forwarded along the shortest path, and suddenly right after exchange of link states advertisement choosing another shortest path through the network. The result may again be poor resource utilization [2]. This unstable characteristic has more or less been dealt with in the current version of OSPF, but with the side effect of been less sensitive to congestion and speed of response to it [2]. Figure 2.4 Illustration of under-utilized paths in the backbone Looking at figure 2.5, it can be seen that a more balanced network has been achieved when traffic from networks connected to R2 and R8 start using the underutilized paths of figure 2.4 Figure 2.5 Illustration of optimized backbone link utilization Page 6

16 3. MPLS TECHNOLOGY OVERVIEW Multiprotocol Label Switching (MPLS) is a high performance technology that enables a much faster switching of packets making up a data stream. [15]. Main MPLS processing and sorting of packets takes place only once at the beginning of a connection. MPLS has turned out to be the most efficient technology for efficiently managing and operating IP networks. Common areas of application of the protocol could include: Switching of connections for real time data streams (such as video, multimedia or Voice over IP [VoIP]) Creation of virtual private networks (VPNs) MPLS is however not a replacement of the IP network but a reinforcement of its functionality. A label is added to the packet header once it enters the MPLS domain. A label is a short fixed entity with no internal structure. The label alone will control the switching process along the entire length of the connection directing it along the previously determined path without requiring further unpackaging or processing of the normal IP header. 3.1 MPLS Label The flow label consists of 20 bits (Corresponding to approximately one million labels). Its length is shorter compared to IPv4 (32 bits wide) and IPv6 (128 bits wide). This in effect adds to the speed with which packets can be processed and switched by intermediate routers. The labels are either interface-significant labels or domain-significant labels. An interface-significant label is recognized only at a single interface by the two routers at the end of that interface. In domain significant labeling, the same label will be used for the same FEC by all routers within the MPLS domain. An MPLS label will be defined inside the MPLS-SHIM header which is 32 bit wide and organized as shown in the figure below. 20-Bit Label EXP (3 Bits) (S) TTL (8 Bits) Fig. 3.1 MPLS Header Page 7

17 The labels on the packets are established by using Forwarding equivalence class (FEC). Following the Label field there are 3 bits EXP field which is known as Traffic class field (TC field) this is used for Quality of Service (QoS) related functions. Next field is called stack field which is 1 bit field and this is used to indicate bottom of label stack. The tail consist 8-bit TTL (Time to Live) field which has a similar functionality as that of the TTL field in the IP header 3.2 MPLS Network Architecture MPLS domains form a part of a given administration s network comprising of MPLS-capable routers at the backbone. These routers are referred to as Label Switched Routers (LSRs) The MPLS domain is thus typically surrounded by an IP-routing domain used at its periphery to connect more remote devices. There are different types of nodes (LSRs) which together form an MPLS domain as shown in the figure 3.2 below: MPLS nodes Routers capable of supporting MPLS services MPLS edge nodes nodes at the edge of an MPLS domain. They convert other network layer protocols into the MPLS format or provide for gateway functions between different MPLS domains. MPLS ingress nodes these are edge nodes at the point where MPLS traffic is originated usually by entering from a non-mpls routing domain. MPLS egress nodes these are MPLS edge nodes at the point where the data flow leaves the MPLS domain for delivery via a non-mpls domain. Intermediate LSR They receive an incoming labeled packet, perform an operation on it, switch the packet and send it to the correct data link [16]. Fig. 3.2 MPLS Network Architecture and node types Page 8

18 Other terms used in MPLS technology are explained as follows; Label Switched path (LSP) A Label Switched Path (LSP) is a series of LSRs that switch a labeled packet through an MPLS network or part of an MPLS network. In MPLS domain, there exists a number of LSPs that originate at the Ingress node, traverses one or more intermediate nodes and terminate at the Egress node Forwarding Equivalence Class (FEC) This can be visualized as describing a group of IP packets that are forwarded in the same manner, over the same path, with the same forwarding treatment [10]. All packets belonging to the same FEC have the same label. However, not all packets containing the same label belong to the same FEC, because their FEC values might differ, their forwarding treatment could differ and they could belong to a different FEC. Each packet in MPLS network is assigned with FEC only once at the Ingress node Label Distribution Protocol (LDP) It is a protocol in which the label mapping information is exchanged between LSRs. It is responsible in establishing and maintaining labels 3.3 MPLS Control Plane and Forwarding plane Nodes in an MPLS domain have two architectural planes: control plane and forwarding plane [11]. A LSR is able to process both conventionally routed IP packets and MPLS routed packets, so both the control plane and the forwarding plane has functionalities for both IP and MPLS. The control plane is the IP routing protocols and the label distribution protocol used. The forwarding plane is the conventional IP forwarding and the MPLS Forwarding. The control plane maintains and controls the forwarding table by learning the network topology from the routing protocols such as OSPF, IS-IS and BGP. It is responsible for building the MPLS IP routing control by updating the label bindings which are exchanged between the routers. The forwarding plane is the conventional IP forwarding and the MPLS Forwarding. The forwarding plane is the conventional IP forwarding and the MPLS Forwarding. The MPLS forwarding plane forwards packets according to the labels attached to packets. The MPLS forwarding can perform different label actions according to the instructions in the NHLFE (next Page 9

19 hop label forwarding entry) and in the Incoming Label Map (ILM) table at each node. In MPLS routers control plane and data plane are separated entities. This separation allows the deployment of a single algorithm that is used for multiple services and traffic types. The label-swapping forwarding algorithm explains how the packets are routed in the MPLS domain which is described in the following steps. When a packet enters the MPLS domain a label of short fixed-length is inserted in the packet header by the Ingress router. FEC is identified from the label. The packets belonging to one particular FEC are forwarded through the same path through the MPLS network even though all the packets do not have the same destination address. The path on which the packets are forwarded to the next hop in the network is LSP. Every hop in MPLS network forwards the packets based on the label but not on IP address. This is done until the packets reach the final hop in MPLS network and then the label is removed by Egress router and normal IP forwarding resumes. Here the Ingress and Egress routers are the LERs and the hops within the MPLS domain are LSRs which is shown in Fig.3.3 Fig. 3.3 MPLS network illustration The following is the brief description of MPLS routing: MPLS uses signaling protocols to establish the paths. Label Distribution Protocol is the signaling protocol and the paths established are called Label Switched path. Routers that support MPLS are Label Switched Routers (LSRs). The LSRs which are located at the edges of MPLS are Page 10

20 called Label Edge Routers (LERs). All the packets enter or exit the MPLS domain through LERs. In Fig.3 LER_1, LER_2, LER_3 and LER_4 are the Labe Edge Routers. LER_2 is the Ingress router which maps the incoming traffic into the MPLS domain. LER_3 is the Egress router through which the packets exit from the MPLS domain. An LSP originates at Ingress router and travels through one or more LSRs and terminates at Egress router. When packet enters the MPLS domain, labels are inserted in their headers by Ingress router and the packets are mapped on to the LSP using Forwarding Equivalence Class (FEC).All the packets which match a Particular FEC, are forwarded on the same LSP. The FEC is described by the set of attributes e.g. destination IP, type of service etc. The core LSRs (which are LSR_1, LSR_2 and LSR_3 in the Fig.3) forwards the packets based on label information but not on the IP address. When a router receives the packet it checks label information base (LIB) instead of routing table and determines the next hop in MPLS domain. Finally the Egress router LER_3 removes the label from the packet header and forwards the packet to the next hop based on IP address and from here the conventional IP forwarding of packets continues. 3.4 Path Determination There are two main approaches used to determine the desired path for FECs; offline path calculation and constraint based routing Offline Path calculation The LSPs and FECs can be determined with an off line tool without the LSRs directly participating in the process. The basic input to the tool is ingress and egress points, physical topology and traffic estimates. Based on the inputs the tool can be used to calculate a set of physical paths for LSPs that optimize the usage of the network resources. Then those routes can be explicitly setup in the MPLS domain. This way of doing path calculations can lead to optimal resource usage, predictable routing and stable network configurations. 3.5 Constraint-Based Routing (CBR) With constraint based routing, network parameters (constraints) are used to determine the best route a set of packets should take. Each LSR determines an explicit route for each traffic trunk (aggregation of traffic flows) originating from that LSR based on bandwidth and cost of the links Page 11

21 and other topology state information. The LSP created is the route that satisfies the requirements of the traffic and the constraints that are set. Calculating a path that satisfies these constraints requires that the information about whether the constraints can be met is available for each link, and this information must be distributed to all the nodes that perform path calculation. This means that the relevant link properties have to be advertised throughout the network. This is achieved by adding TE-specific extensions to the linkstate protocols ISIS and OSPF that allow them to advertise not just the state (up/down) of the links, but also the link s administrative attributes and the bandwidth that is available. In this way, each node has knowledge of the current properties of all the links in the network. Once this information is available, a modified version of the shortest-path-first (SPF) algorithm, called constrained SPF (CSPF), can be used by the ingress node to calculate a path with the given constraints. CSPF operates in the same way as SPF, except it first prunes from the topology all links that do not satisfy the constraints. 3.6 MPLS Signaling Protocols Signaling is a way in which routers exchange important information. In an MPLS network, the type of information exchanged between routers depends on the signaling protocol being used. At a base level, labels must be distributed to all MPLS enabled routers that are expected to forward data for a specific FEC and LSPs created. The MPLS architecture does not assume any single signaling protocol [12]. Therefore, for the purposes of this project report I will discuss only two methods for label distribution Label Distribution Protocol (LDP) Constrained Routing with LDP (CR-LDP) LDP It is designed for the explicit purpose of distributing MPLS labels, thus setting up LSPs in the MPLS domain. It always selects the same physical path that conventional IP routing would select. Thus LDP does not support TE. Because of the recent development in routing technology, LDP is not much for label distribution today. There is however an extension to the original LDP protocol that brings new functionality for the LDP protocol called CR-LDP. Page 12

22 3.6.2 CR-LDP This is an extension of LDP that supports constraint-based routed LSPs. The term constraint implies that in a network and for each set of nodes there exists a set of constraint that must be satisfied for the link or links between two nodes to be chosen for an LSP. An example of a constraint is to find a path that needs a specific amount of bandwidth. LSRs that use CR-LDP to exchange label and FEC mapping information are called LDP peers; they exchange this information by forming a LDP session. There are four categories of LDP messages: Discovery messages announce and maintain the presence of an LSR in an MPLS domain. This message is periodically sent as a Hello message through a UDP port with the multicast address of all routers on this subnet. Session message is sent to establish, maintain and delete sessions between LDP peers. Advertisement messages create, change and delete label mappings for FECs. Notification Messages provides status, diagnostic and error information. 3.7 Label Merging If multiple LSPs arriving at a LSR have different incoming labels but are to be forwarded the same path towards the egress router, then these LSPs may not need to be treated as separate LSPs for the rest of the path [13]. If the FECs carried by these LSPs can be aggregated, this can be seen as an aggregation of traffic. Then those LSPs can be merged together and switched using a common label. This is known as label merging or aggregation of flows. Aggregation can reduce the number of labels needed to handle a particular set of packets and can also reduce the amount of label distribution traffic needed. An LSR is capable of label merging if it can receive two packets from different incoming interfaces, with different labels, and send both packets out the same outgoing interface with the same label without the use of the label stack. Once the packets are sent, the information that they arrived from different interfaces with different labels is lost and they are treated as one flow. Page 13

23 3.8 Traffic Engineering in MPLS Networks Traffic Engineering (TE) is a mechanism that controls the traffic flows in the networks and provides performance optimization by optimally utilizing the network resources [14]. Some of the key features of TE are resource reservation, fault-tolerance and optimum Resource utilization. Important factors needed for TE include: Distribution of Topology information Path selection Directing traffic along the computed paths Traffic Management Distribution of Topology information There needs to be a mechanism to advertise the current information about the links for the nodes, so that the nodes can build a map about the network topology. It is crucial that the information about the link or node failures have to be rapidly propagated through the networks, this makes the problem to be fixed quickly [15] Path selection This process involves computing the path information between nodes in the network. The shortest path with minimum links is selected. The other constraints like bandwidth and delay is also considered during the path selection Directing traffic along the computed paths Traffic is forwarded along the particular calculated path between source and destination node. Typically this is achieved by forwarding table Traffic Management Traffic management deals with the process of forwarding the traffic with the predictable quality. The parameters such as bandwidth, delay, jitter and packet loss are the main concern for the traffic management. The main objective of considering TE is to efficiently use the available network resources and increase service quality of applications on the Internet. The motivation behind MPLS TE is Page 14

24 Constraint Based Routing (CBR) which takes bandwidth, policies and network into consideration for establishing a path (LSPs) in MPLS domain to forward the packets. Constraint Based Routing (CBR) takes bandwidth, policies and network into consideration for establishing a path (LSPs) in MPLS domain to forward the packets. In this case: All links in the domain should be characterized with traffic engineered attributes The configured attributes must be advertised to all routers in the IGP area A constraint path calculation mechanism to be implemented at each node There is obviously a need of routing protocol and possibly the link state algorithm to convey link attributes among nodes. Rather than developing a new routing protocol specific for this purpose, existing link state protocols are extended to support CBR, hence results in ISIS TE and OSPF-TE. The set of newly added attributes include: Traffic Engineered (TE) metric, other than IGP metric to be configured upon the links Maximum Bandwidth, the TE link capacity Maximum Reserve Bandwidth, how much bandwidth on a link can be reserved (TE pool) Unreserved Bandwidth, still available bandwidth on a link from TE pool Administrative Group TE metric: is a value assigned at a specific link for TE calculation, if TE metric is not configured across the links then by default IGP-TE takes into account IGP metric at that link. It is also considered to be TE administrative weight over the TE capable links Maximum bandwidth: A static value configured by operator at each link. A configurable value across a link can be greater than the actual link capacity resulted in over provisioning the links, while keeping in mind the constraint that not all the circuits passing through an over provisioned link should be active at the same time. Unreserved bandwidth: This value changes on every TE-LSP setup/tear down and the updated information is sent across the domain. Flooding the value upon every change, results in number of Traffic Engineered Link State Advertisements (TE-LSA) to be sent per Page 15

25 unit time, and TE network is susceptible to being unstable. Link state protocol calculation is distributed mostly; each node requires full information regarding network statistics. Administrative group: A 32-bit value used as a flexibility mechanism across TE links. Each administrative group bit can be used to specify different parameters of a TE link. Link can be marked optionally with different values (or colors) which can be understood generally in terms of a tag on the link. Each color/value corresponds to a specific property as latency, delay, packet loss. Thus, it provides interfaces statistics using attribute names expressed in strings [16]. Page 16

26 4. NETWOTK MODEL AND SIMULATION 4.1 Simulation Tool In this project, OPNET Modeler was used. Optimized Network Performance (OPNET) is a discrete event simulation tool. It provides a comprehensive development environment supporting the modeling and simulation of communication networks. This contains data collection and data analysis utilities. OPNET allows large numbers of closely spaced events in a sizeable network to be represented accurately. This tool provides a modeling approach where networks are built of nodes interconnected by links. Each node s behavior is characterized by the constituent components. The components are modeled as a final state machine. Details of OPNET Modeler 14.5 can be found in [17, 18] 4.2 OPNET Model Configuration Objects The network components as used in this project work from OPNET library include: ethernet_wkstn: Ethernet workstation OPNET element is used to simulate the network users. It consists of single Ethernet connection at a selected rate, directed by the underlying medium used to connect to an Ethernet switch. ethernet_server: Ethernet server provided in OPNET is used to simulate the service server in the network. It contains one Ethernet connection to the switch, facilitating that subnet. Cisco 7200 router: Router model capable of supporting MPLS 100BaseT: This is a full duplex link operating at 100 Mbps used to connect the ethernet_server and Ethernet_wkstn to the Cisco 7200 series routers PPP_E3: This is a duplex link connecting two nodes running IP at a rate of Mbps. It was used to connect the Cisco 7200 routers MPLS_E-LSP_STATIC: Static LSP are not signaled during the startup. They allow more routing control Application Config: This element is used to tell OPNET which application is going to be modeled upon the underlying network. A single Application Config. is used to instruct OPNET for multiple network applications. Application parameters for different application types being observed are configured in this element. Page 17

27 Profile Config: Profiles describe the activity patterns of a user or group of users in terms of the applications used over a period of (simulation) time [25]. There can be several different profiles running on a given network under observation. User profiles have diverse properties, so configuring a certain profile with a specific application was done here. The configured profiles are then assigned to the network users. mpls_config_object: Configuring MPLS FEC and Traffic Trunk is done under this element configuration. The configured specification is used at the Ingress Edge router to direct the traffic flows and assign different LSP to different application traffic. 4.3 OPNET Simulated Application Traffic FTP Traffic: FTP stands for File Transfer Protocol. It is used to generate traffic flow from the FTP server towards the FTP client (CE_1), thus simulating file downloading based upon the request from the client. The FTP traffic characteristics are provided in the figure 1 below. Table 4.1: FTP traffic Configuration in OPNET Video Conferencing Traffic: The video conferencing inherits the mentioned characteristics. It is given a TOS value which equals to DSCP AF41. The traffic generated by Video application per second includes: (128x240 byes) (15 frames per second) = 3,686,400 bits/second Page 18

28 Table 4.2: Video Conferencing traffic Configuration in OPNET 4.4 Network Topology Figure 4.1 illustrates the networking topology that was used. The network topology cannot be said to be a realistic operational network. The intention was to create a networking environment, which could represent a part of an overall network topology of an ISP network. The model suite supported workstations, servers, routers, and link models. Cisco 7200 access routers were used at the edge of the network where the traffic was transmitted to or received from the workstations and the servers. Fig 4.1: Overview of the experiential network model. Page 19

29 4.5 Description of the Topology Two applications were configured which used TCP and UDP as their transport protocol. With these applications generating traffic, the intention was to measure the treatment of these traffic types when shortest path routing and MPLS is implied. Since most of the traffics getting transmitted in today s Internet use TCP or UDP as transport protocols, these protocols were the right choice for experiments within the simulations. We gave the network approximately two minutes before traffic generation was triggered. This was done to make sure the routers had enough time to exchange topology information and building up their routing tables. From the second minute, file transfer application was triggered to start, making TCP to transport its packets through the network. TCP traffic intensity was set to 50,000,000 bytes of files downloaded from the server. The other application was set to start one minute later transporting its packets with UDP transport protocol. The traffic intensity for UDP was set to 3,686,400 bits/second. The maximum transmission unit (MTU) was set to the Ethernet value of 1500 bytes. The MTU specify the IP datagram packet that can be carried in a frame. When a host sends an IP datagram, therefore, it can choose any size that it wants. With reference to figure3, CE_1 was to communicate with the FTP_SERVER using the file transfer application, meaning it would start generating the TCP traffic intensity described above at the second minute. CE_2 on other hand, were to use the video conferencing application, thus making it to generate UDP traffic one minute later. The UDP traffic was transmitted to CE_3, which accepted video conferencing related UDP traffic. 4.6 OSPF Simulation Scenario The first scenario was created to highlight some of the shortest path routing principle characteristics as mentioned in chapter 2. Specifically, the parameters of interest are, throughput, link utilization and queuing delay issues when traffic flows compete for same scarce resources under overloaded situations. All paths were set to an equal cost of 100. All the routers were configured using only Open Shortest Path First (OSPF) as their routing protocol. Details over configurations of network nodes and traffic implementations within OPNET can be reviewed in appendix A. Page 20

30 4.7 RESULTS Fig 4.2 TCP and UDP Throughput (Bits/second) Fig 4.3 TCP and UDP Throughput (Packets/second) Fig 4.4 Throughput Shortest Path (bits/sec) Fig 4.5 Average Link Utilization Shortest path Page 21

31 Fig 4.6 Queuing delay shortest path Fig 4.8 Utilization Longest Fig 4.7 Queuing delay longest path Fig 4.9 Longest path Throughput (bits/sec) Page 22

32 4.8 Analysis and Discussion OSPF Throughput From the configuration, CE_1 was set to send and receive two 50,000,000 byte files over the simulation time starting the second minute. Observing from the collected statistics the maximum transfer rate achieved was 3,484, bits/second during the 234th second. A minute later, CE_2 started generating UDP traffic. From the configuration, CE_2 is sending and receiving video conferencing traffic at the Ethernet NIC card. The maximum transmission rate recorded was 6,010, bits/second during the 600th second of the simulation. Keeping in mind that both traffic utilized their links towards the ingress router, it was registered that the UDP traffic intensity had a tremendous effect on the TCP traffic intensity. These effects were registered between clients and the ingress router PE_1 every time UDP- traffic intensity was being transmitted. Figure 4.2 and 4.3 shows that the TCP throughput starts falling, when the video client starts generating traffic. This causes TCP throughput to fall to 1,935, bits/second during the 210 th minute. The UDP traffic does not care about congestion within the network, continuing transmitting its traffic regardless of packets managing to arrive at the intended destination. Figure 4.3 shows the amount of packets sent from the clients towards the server. Observing the registered result, it was witnessed that each times UDP- traffic increased its traffic intensity; the TCP traffic intensity lowered y equally. However, some increase was registered right after such incidents. It can be said that these increases of intensity made by TCP after each decreases are related to the fast retransmit option of TCP RENO implementation. The other statistical result gathered from the simulation were the throughput measured from paths between routers that handled the traffic flows. Figures 4.4 and 4.9 shows the results gathered from the simulation. It was observed that the throughput between routers combining one path (PE_1, P_3, P_4, P_5, PE_2), were unutilized, while the other path (PE_1, P_1, P_2 and PE_2) were fully utilized. This indicated weakness of OSPF when it came to load balancing the traffic. Page 23

33 From the figures, it was observed that the longest path had a stable amount of zero throughput. The shortest path however, had a non-zero throughput which reached a maximum of 8,693, bits/second. It was also observed that the link was utilized all the time. The overall picture that was aimed at here was the fact that OSPF routing protocol did not utilize the network resources efficiently at times were traffic load conditions are heavy, utilizing only the shortest path between any pair of ingress and egress routers. With this functionality implied, bottlenecks arise and congestion takes place within the network. If the network topology was more complex and other traffic was forwarded from other routers and utilized this path towards some destination, the results may have been even worst from the ones registered. In the real world of ISP networks, different traffic types may end up utilizing the same shortest path, making it possible to achieve the same negative results at any point between any routers that gets to become part of a shortest path. This force out congestion points and bottlenecks within a network configured with a shortest path routing protocol Queuing delay Some statistics concerning queuing delay and throughput from the edge and core routers were also collected. From figure 4.8 and 4.9, it was registered that no activities were taking place between routers combining the longest path. A delay of seconds was recorded, which is negligible. This was due to the fact that the links remained unutilized within the simulation time. On the other hand, the queuing delay from PE_1 to P_1 grows every time the UDP traffic starts generating its traffic intensity Figure 4.6 shows that the queuing is much heavier between the ingress router and the first router along the path. From the second router and after, the queuing delay has a stable value. This indicates that heavy queuing only occurs between the first routers along the shortest path. This is quite reasonable since the ingress router forwards enough packets that the link connected to the first core router can carry. 4.9 MPLS Simulation Scenario Figure 4.10 illustrates the MPLS simulation scenario. The preceding network model was copied and the only changes made were the red, green and blue colored stretched arrows combining Page 24

34 label-switching paths through the experiential network. Below, details of the MPLS related configurations shall be presented. For complete and more detailed specifications over this experiential network, refer to appendix B In order to be able to control flows of traffic, label-switching paths (LSPs) had to be installed. Static LSPs were established; in order to have a more precise control over the path a flow was to use. Flow specifications governed by the ingress router (PE_1) for traffics injected into the network were also specified. Fig 4.10 Network for MPLS simulation scenario Four LSPs were created between the ingress router (PE_1) and the egress router (PE_2). Two traffic trunks were specified for the traffic flowing through the LSPs. Trunk FTP was created to engineer the traffic from the FTP client (CE_1) to the FTP server. Its specifications were as shown in table 1 below Table 4.3 FTP trunk profile specification Page 25

35 Trunk video was created to engineer video conferencing traffic from the video caller (CE_2) to the video receiving client (CE_3). The specifications are indicated in table 2 below. Table 4.4 Video trunk profile specification Two Forwarding Equivalent Classes (FECs) were created, one for Video traffic (FEC Video) based on the type of service DSCP AF41 and another for FTP traffic (FEC FTP) with the type of service being DSCP AF11. Four Static LSPs were configured from PE_1 to PE_2 and from PE_2 to PE_1 to map the traffic as outlined below PE_1 - P_1 - P_2 - PE_2 TCP traffic from the TCP client to the TCP server PE_1 P_3 P_4 P_5 PE_2 Video conferencing traffic from CE_2 to CE_3 PE_2 - P_2 - P_1 - PE_1 -- TCP traffic from the TCP server to the TCP client PE_2 P_5 P_4 P_3 PE_1 -- Video conferencing traffic from CE_3 to CE_2 Traffic binding was configured on PE_1: FEC FTP was bound to flow through LSP PE_1 - P_1 - P_2 - PE_2 from CE_1 while FEC Video was bound to flow through LSP PE_1 P_3 P_4 P_5 PE_2 from CE_2. The same was done with PE_2 with FEC FTP transporting traffic from the FTP server through LSP PE_2 - P_2 - P_1 - PE_1. Video traffic from CE_3 was mapped to FEC Video and bound to LSP PE_2 P_5 P_4 P_3 PE_1. The following parameters were set on all routers: LDP was enabled, link discovery Hellos were enabled, Loop Back interfaces were enabled and configured, LDP neighbors were set and finally all the interfaces in the routers were enabled. Page 26

36 4.10 MPLS SCENARIO RESULTS Fig 4.11 TCP and UDP Throughput (Bits/second) Fig 4.12 TCP and UDP Throughput (Packets/second) Fig 4.14 Average LSP PE_1 - PE_2 Delay (sec) Fig 4.13 Traffic In and Out of PE_1 -PE_2 (Bits/second) Page 27

37 Fig4.15 LSP PE_1 PE1_2 1 Delay (sec) Fig 4.16 Traffic In and Out of PE_1 -PE_2 1 (Bits/sec) Fig 4.17 Traffic In and Out of PE_2 -PE_1 (Bits/second) Fig4.18 LSP PE_2 PE_1 Delay (Seconds) Page 28

38 Fig 4.19 Traffic In and Out of PE_2 -PE_1 1 (Bits/second) Fig 4.20 LSP PE_2 PE1_1 1 Delay (sec) 4.11 Analysis and Discussion Throughput From the configuration, CE_1 was set to send and receive two 50,000,000 byte files over the simulation time starting the second minute. Observing from the collected statistics indicated in figure 4.11, the maximum transfer rate achieved was 1,923, bits/second during the 594th second. UDP traffic was generated a minute later from CE_2 reaching a maximum transmission rate of 3,017, bits/second during the 594 th second. Keeping in mind that both traffic utilized their links towards the ingress router, it was registered that the UDP traffic intensity had some effect on the TCP traffic intensity. These effects took place over the simulation time. The minimum value recorded by TCP traffic was 388, bits/second 168 second after the simulation while a maximum of 1,923, bits/second was registered during the 594th second. The transients can be attributed TCP acknowledgements travelling from the server back towards the client along the shortest path. Page 29

39 Another factor that is related to the ingress router which is responsible for the forwarding of traffic transmitted to it could also cause the transients. Packets intended to be traffic engineered must follow the policy of and reservation of the label- switching path that they are going to use. When utilizing a LSP, the router must keep track of which flow spec established for the LSP the packets get to use. PE_1 which is the ingress router must then govern the amount of average bit rate allowed by the flow spec defined for each LSP. The flow spec which was defined and used by UDP traffic, allowed only an average bit rate of 4,214,400 bits/sec. With UDPP traffic exceeding at some points the average bit rate traffic intensity, some queuing at the ingress router had to take place to govern the amount of average bit rate limit configured. Figure 4.14 shows the amount of queuing delay between the ingress router PE_1 and the routers along the path. The queuing delay has some direct impact on the TCP protocol. Other results gathered from the MPLS experimentation were the throughput measured from paths between routers that handled traffic flows. Figures 4.13, 4.16, 4.17 and 4.19 shows the results gathered from the simulation. It was recorded that the throughput between routers combining the shortest path and longest path were more balanced compared with the shortest path configured network simulated earlier. It was witnessed that TCP traffic travelling along LSP PE_1-PE_2 reaches a maximum of 28, bits/second. Here, the throughput starts climbing 120 seconds after the start of the simulation. From the results registered, it was confirmed that the longest path was more efficiently utilized with the traffic engineering capabilities of MPLS. With no traffic engineering, it was noted that probably no throughput was witnessed at the non-shortest path as simulated in the preceding experiment. TCP traffic would have then suffered a lot more when competing with its rival UDP traffic along the shortest path From figure 4.19, the throughput intensity from path combining routers PE_1 P_3 P_4 P_5 PE_2 through PE_1-PE_21 LSP was shown. Since UDP traffic gets to utilize this path alone, i t w a s p o s s i b l e to avoid congestion within the network. If shortest path routing were configured, the path would have been over utilized making both traffic streams to suffer from congestion within the network. Page 30

40 Queuing delay Some statistics concerning queuing delay from the edge and core routers were also collected. From figures 4.14, 4.15, 4.18 and 4.20, it can be observed that the queuing delay is more balanced between both paths comparing it with the shortest path routing scenario. UDP traffic, which utilizes the path PE_1 P_3 P_4 - P_5 seems to have a lower queuing delay values than the TCP traffic. It keeps a steady value approximately at seconds. Another interesting detail of it is the slightly queuing delay drop offs at each second along the simulation time The other result registered, was the fact that almost all- significant queuing appeared between the first few seconds along both paths. Thereafter, the values kept stable queuing delay values along the forwarding path. This happens because the entire major queuing takes place between the ingress and first router along the path and since the queuing values aren t very high, a very stable queuing value between other routers along the path was recorded. The amount of traffic between these routers are more predictable since the second router along the path get the right amount of traffic that it can forward further closer towards some destination. It s the first router that gets to queue the heavy amount of traffic that the links can t cope to carry immediately. Comparing these results with the earlier result from the shortest path routing scenario network, the queuing delay keep a much less queuing delay value (Maximum seconds and Minimum seconds) between the ingress router and the egress router along the shortest path, than the OSPF routing scenario. Page 31

41 5. CONCLUSION Page 32

42 6. REFERENCES [1] Daniel O. Aweduche, MPLS and Traffic Engineering in IP Networks, IEEE Communication Magazine December 1999, UUNET (MCI Worldcom) [2] D Bertsekas & R Gallager, Data Networks, Second Edition, Prentice Hall [3] J. Moy, OSPF version 2, RFC 2328, Ascend Communications Inc. April [4] Wei Sun, Praveen Bhaniramka, Raj Jain, Quality of Service usingtraffic Engineering over MPLS: An analysis, IEEE 2000, /00. [5] C. Hedrick, Routing Information Protocol, RFC 1058, Rutgers University, June [6] D. Oran, OSI IS-IS Intra-domain Routing Protocol, RFC 1142, Digital Equipment Corp., February [7] T. Li, Y. Rekhter, A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE) RFC 2430, October [8] Martin P. Clark, Telecommunications Consultant, Germany Data Networks, IP and the Internet; Protocols, Design and Operation [9] Luc De Ghein, CCIE No.1897, MPLS Fundamentals; A Comprehensive introduction to MPLS Theory and Practice [10] Ivan Pepelnjak, Jim Guichard, MPLS and VPN Architectures; A Practical guide to understanding, designing and deploying MPLS and MPLS enabled VPNs [11] Vivek Alwayn, Advanced MPLS design and Implementation [12] E. Rosen, A. Viswanathan, R.Callon Multiprotocol Label Switching Architecture (RFC 3031) January 2001 Page 33

43 [13] Fernando Solano, Student Member, IEEE, Ramon Fabregat, and Jose Luis Marzo, Member, IEEE, On Optimal Computation of MPLS Label Binding for Multipoint-toPoint Connections IEEE Transactions on Communications, Vol. 56, No. 7, July [14] Xipeng Xiao, Alan Hannan, and Brook Bailey, Global Center Inc. Lionel M, NI, Michigan State University. Traffic Engineering with MPLS in the Internet [15] Haris Hodzic, Sladjana Traffic Engineering with Constraint Based Routing Zoric 50th International Symposium ELMAR-2008, September 2008, Zadar, Croatia. [16] Ina Minei, Julian Lucek, MPLS enabled applications: emerging developments and new technologies, 3rd edition, Wiley, 2010 [17] OPNET Technologies Inc., "OPNET Modeler Modeling Manual", Bethesda, MD, release 14.5, June 2008 [18] OPNET Technologies Inc., "OPNET Protocol Model Documentation", Bethesda, MD, release 14.5, June 2008 Page 34

44 7. APPENDIX 7.1 APPENDIX A: PROCEDURE FOR MODELLING OSPF EXPERIMENT Creating the Network 1. Add the following objects from the object palette to the project workspace: Application Config, Profile Config, QoS Attribute, MPLS Config, 3 Ethernet wkstn, 1 Ethernet server, 7 Cisco 7200 routers 2. Connect the Cisco 7200 routers together with DS2 links (from the Link model palette) as per the diagram. 3. Connect the workstations and the server to the routers with 100Base_T links. 4. Select the following menu was: Protocols/IP/Routing/Select routing Protocols, OSPF was selected and applied to all subinterfaces and all interfaces (including loopback, VLAN). 5. Select all routers then Protocols/OSPF/Configure Area, insert area 0 in the box then click OK. 6. Select all WAN links from LER1, LSR1, and LSR4 to LER2. Select OSPF/Configure Interface Costs and set the interface cost explicitly for all selected links to 100. Configuring the Application Here the applications and file sizes to be used on the model are defined. 1. Select Edit Attributes from the Applications node; s e t Application Definitions to 2 (because there are 2 applications). Name t he rows: FTP Application and Video Application. 2. From the FTP Application Description row, set the value of FTP to High Load. Change the value in the (Ftp) Table for a size of 50,000,000 and an Inter-Request Time of constant (100) to continue to request files of 50,000,000 bytes. Set the TOS field to AF11 for DSCP. 3. From the Video Application row, set the Video Conferencing value to Low Resolution Video. Click on Low Resolution Video and choose Edit from the drop down menu. Select the value in the (Video Conferencing) Table to high resolution video and the TOS set to DSCP AF41). Page 35

45 Configuring the Profiles 1. From the Profiles node, select Edit Attributes; s e t Profile Definitions to 2 (because there are 2 profiles). T he rows are named: TCP Profile and UDP Profile. 2. Name and set the attributes of row 0 as shown below with the FTP traffic starting 120 seconds after the start of the simulation 3. Set streaming video traffic to start 180 seconds after the start of the simulation Configuring the Workstations and Servers 1. Right-click the FTP Client, from Edit Attributes: Application: Supported Profiles, s et t h e rows to 1. Set the Profile Name to TCP Profile: OK. 2. Right-click the Video Clients, from Edit Attributes: Application: Supported Profiles s et t h e rows to 1. Application was edited: Supported Services and rows set to 1. Set service name to Video Application: OK twice 3. Right-click the FTP Server: Edit Attributes: Application: Supported Services and set rows to 1. Set service name to FTP Application: OK twice. Traffic and Flows 1. Set OSPF to run on all routers with an area of Run DES for 600 seconds and quantify the different traffic flows after choosing the appropriate statistics. Page 36

46 7.2 APPENDIX B: PROCEDURE FOR MODELLING MPLS EXPERIMENT Copy the current scenario and name it MPLS_TE. Here Trunk profiles are created. For each traffic flow FECs are assigned and then bound to the static LSPs at LER PE_1 and LER PE_2. TCP traffic will be made to flow along the route PE_1 - P_1 - P_2 - PE_2. Two unidirectional paths are made one originating at each LER. Video traffic will flow between LER PE_1 and LER PE_2 via PE_1 P_3 P_4 P_5 PE_2. Again, two unidirectional paths will be made. Creation of traffic Trunk profiles. Two traffic flows need to be defined for the two different DSCP classes of flows. Right click on the MPLS configuration object and select Edit Attributes. Select Traffic Trunk Profiles and edit the fields and enter two rows. For each row add a trunk name and enter the traffic profile as shown below for each flow. Trunk_Video is added as shown below (it is a CBR profile): Finally Trunk_FTP is added with the following configurations Creation of FEC classes Here two Forward Equivalent Classes (FEC) are created; one for Video and one for FTP. These flows can be managed in the network Page 37

47 Right click on the MPLS configuration object and select Edit Attributes. Select FEC Specifications and edit the fields and enter two rows. For each row add a FEC name (Video and another for FTP traffic) Details for FEC_FTP are as shown below: For the FEC_Video enter the FEC details as shown below. Assign DSCP code point AF41 for video Configuration of static LSP between PE_1, P_1, P_2, PE_2 Using the MPLS_E-LSP_STATIC object, configure a unidirectional static route from PE_1 to PE 2 Click on the MPLS_E-LSP_STATIC object in the MPLS object palette. From the project workspace, click on the LSP s ingress LER PE_1, Click on the next link or router in the LSPs route The tooltips indicate which links and routers can be added to the route. Hold the cursor over a link or router for details about adding it to the LSP. Continue clicking on each link or router in the route until all have been added. Right-click in the project workspace and select Finish Path Definition to finish drawing the LSP Configure a static LSP between PE_2, P_2, P_1, and PE_1 Same as above but from PE_2 towards PE_1 on the top path Page 38

48 Configure static routes along the bottom path. Configure a static LSP between PE_1 P_3 P_4 P_5 PE_2 as above and one between PE_2P_5-P_4-P_3-PE_1 as above. When creation of LSPs is finished, right-click in the project workspace and select Abort Path Definition, otherwise, draw the next static LSP Update the LSP details. From the Protocols > MPLS menu, choose Update LSP Details to configure label switching information on the LSP(s). Choose Protocols/MPLS/Show all LSPs to show the paths on the topology diagram. Right-click on the link between PE_1 and P_1 to reveal the path names. Click on the PE_1 to P_2 path and select Edit Attributes. Click on Path Details and examine the path details to see the labels being used to determine the path between the routers. Configure Traffic Mapping configuration on PE_1 Here we are going to bind the FEC_ Video profile to the Video trunk and map this onto one or more Label Switched Paths (LSPs). Then the FEC_ FTP profile is bound to the FTP trunk and mapped onto a different LSP. On PE_1, choose the Edit Attributes/MPLS/MPLS parameters/traffic Mapping Configuration attribute and enter 2 rows. Choose the Interface In as shown below: Configure the FEC/Destination Prefix as FEC_Video with the Traffic Trunk to Trunk_Video, the Primary LSP from PE_1 to PE_2 (weight 100), and the Backup LSP to PE_1 to PE_21. Configure the next row as above for the same FEC and LSPs except set the Traffic Trunk to Trunk_FTP as shown below: Page 39

49 Configure Traffic Mapping configuration on LER_2 Now it is necessary to bind the FEC_Video profile to the Video trunk and map this onto one or more Label Switched Paths (LSPs) at PE_2 Then the FEC_ FTP profile is bound to FTP trunk and mapped onto a different LSP. On PE_2, choose the Edit Attributes/MPLS/MPLS parameters/traffic Mapping Choose the Interface In as shown below: Configure Link Discovery Protocols on the routers. Select the PE_1 router and right click. Select Edit Attributes/MPLS/LDP parameters. Set the Status to Enabled; the Discovery configuration/link Hellos to enabled; the Loopback Interfaces to Enabled and select the router loopback address (LB0). Set the Neighbor Configuration, number of rows to 2 and name the neighbors as P_1 and P_3. Click OK to save the parameters. (Ensure that the appropriate interfaces between the MPLS routers have been enabled). A similar exercise should be done on all the other routers. Page 40