|USFDC Home | USF Electronic Theses and Dissertations||| RSS|
This item is only available as the following downloads:
A DISTRIBUTED ROUTING ALGORITH M FOR ER-LSP SETUP IN MPLS NETWORKS by NAGA SIDDHARDHA GARIGE A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Electrical Engineering Department of Electrical Engineering College of Engineering University of South Florida Major Professor: Wilfrido A. Moreno, Ph.D. James T. Leffew, Ph.D. Kenneth A. Buckle, Ph.D. Date of Approval: April 1, 2003 Keywords: overlay model, traffic engi neering, explicit routing, RSVP, network optimization Copyright 2003, Naga Siddhardha Garige
TABLE OF CONTENTS LIST OF TABLES iii LIST OF FIGURES iv ABSTRACT vi CHAPTER 1 INTRODUCTION 1 1.1 Picture of the Internet 1 1.2 Why Conventional Networks Need More Than IP 3 1.3 Research Motivation 5 1.4 Thesis Outline 7 CHAPTER 2 BACKGROUND 8 2.1 Introduction to MPLS 8 2.1.1 Connection Oriented QoS Support 8 2.1.2 Traffic Engineering (TE) 9 2.1.3 Virtual Private Networks (VPNs) 10 2.1.4 Multi-protocol Support 11 2.2 MPLS at a Glance 11 2.3 MPLS Components 14 2.3.1 MPLS Header 14 2.3.2 Label Binding and Assignments 15 2.3.3 Label Distribution 17 2.3.4 Label Spaces 17 2.3.4 Label Merging 18 2.3.5 Label Stacking 18 2.4 Label Distribution Methods 19 2.4.1 Label Distribution Protocol (LDP) 19 220.127.116.11 LDP Header 20 18.104.22.168 LDP Message Format 20 22.214.171.124 LDP Messages 21 2.4.2 Resource Reservation Protocol 24 126.96.36.199 RSVP Overview 24 188.8.131.52 RSVP Messages 25 184.108.40.206 RSVP Soft State 26 220.127.116.11 RSVP Reservation Styles 27 18.104.22.168 RSVP Message Format 28 22.214.171.124 RSVP Object Fields 29 i
2.4.3 Extension to RSVP for Label Distribution 29 126.96.36.199 Establishing an LSP Tunnel 30 188.8.131.52 RSVP-Extended Path Message 31 184.108.40.206 RSVP-Extended Message 32 2.4.4 Carrying Label Information in BGP-4 32 220.127.116.11 Carrying Label Information 33 2.5 Constraint Based Routing 34 CHAPTER 3 PROBLEM DISCUSSION AND PROPOSED SOLUTION 36 3.1 Conventional Routing Techniques 36 3.1.1 Distance Vector Routing 36 18.104.22.168 Problems Associated with Distance Vector Routing 37 3.1.2 Link State Routing 37 22.214.171.124 Problems Associated with Link State Routing 37 3.2 Problems with Conventional Routing and Solution 38 3.3 Problems with Conventional Routing in Setting up LSPs 40 3.4 Proposed Algorithm 42 3.4.1 Basic Idea 42 3.4.2 Cluster Formation and I-Node Selection 43 3.4.3 The Routing Table 45 3.4.4 The Routing Process 46 126.96.36.199 The Route Discovery Process 47 3.4.5 Path Selection 49 CHAPTER 4 SIMULATION AND PERFORMANCE STUDY 51 4.1 Simulation Environment 51 4.2 Performance Parameters 52 4.2.1 Routing Overhead 52 4.2.2 Multiple Route Support 55 4.2.3 The Blocking Probability 56 4.2.4 Routing Loops 59 CHAPTER 5 CONCLUSION AND FUTURE WORK 60 5.1 Conclusion 60 5.2 Future Work 61 REFERENCES 62 ii
LIST OF TABLES Table 2.1: Body Field Values in RSVP Messages 29 Table 3.1: NSF-NET Network Topology-1 Overview 45 Table 3.2: NSF-NET Topology-1 Routing Table 46 iii
LIST OF FIGURES Figure 1.1: The Internet 1 Figure 1.2: A Sample ISP Network 2 Figure 2.1: MPLS General Architecture 12 Figure 2.2: Label Switching 13 Figure 2.3: MPLS Header 15 Figure 2.4: Label Binding 16 Figure 2.5: Label Stacking 19 Figure 2.6: LDP Message Exchange 19 Figure 2.7: LDP Message Header 20 Figure 2.8: LDP Message Format 21 Figure 2.9: RSVP in Host and Router 25 Figure 2.10: RSVP Header Format 28 Figure 2.11: RSVP Object Format 29 Figure 2.12: LSP Tunnel Setup Using RSVP Extension 31 Figure 2.13: Label Distribution Between Non-Adjacent BGP Peers 33 Figure 2.14: NLRI Information 34 Figure 2.15: MPLS Explicit Routing 35 Figure 3.1: Uneven Resource Utilization 38 Figure 3.2: MPLS Overlay Model 40 Figure 3.3: NSF-NET Topology with the Proposed Routing Algorithm 44 iv
Figure 3.4: Route Discovery Process for a LSP Request from Node 1 to Node 15 48 Figure 4.1: NSF-NET Backbone Topology 52 Figure 4.2: Routing Overhead Comparison with Node 1 as Source 53 Figure 4.3: Routing Overhead Comparison with Node 15 as Source 54 Figure 4.4: Routing Over Head in Flooding and the Proposed Algorithm 55 Figure 4.5: Maximally Disjoint Paths 56 Figure 4.6: NSF-NET Blocking Probability with 100 Mbps Links 58 Figure 4.7: NSF-NET Blocking Probability with 250 Mbps Links 58 v
A DISTRIBUTED ROUTING ALGORITHM FOR ER-LSP SETUP IN MPLS NETWORKS Naga Siddhardha Garige ABSTRACT The rapid growth of the Internet, in the last few years, has generated a need to enhance the existing IP networks in the areas of availability, dependability and scalability in order to provide a mission critical networking environment. In contemporary IP networks, data packets are routed as a function of the destination address and a single metric such as hop-count or delay. This approach tends to cause message traffic to converge onto the same link, which significantly increases congestion and leads to unbalanced network resource utilization. One solution to this problem is provided by Traffic Engineering (TE), which uses, bandwidth guaranteed, Explicitly Routed Label Switched Paths (ER-LSPs). Due to the dramatic increase in the backbone speeds, current research focuses more on traffic engineering with LSPs for clear control over the traffic distribution in the network. However, the growing popularity of the Internet is driving the Internet Service Providers to adapt new technologies in order to support multiple classes of applications with different characteristics and performance requirements. Multi-Protocol Label Switching (MPLS), which was proposed by the IETF provides essential facilities for traffic engineering and reliable QoS services for the Internet. MPLS networks provide the required flexibility for operators to manage their traffic with vi
ER-LSPs. Even though conventional routing algorithms support the ER-LSP setup in MPLS networks, they are not efficient in link residual capacity information updates and limit resource utilization, which eventually leads to LSP failures and unbalanced network resource utilization. This thesis proposes a new architecture with a cluster based distributed routing algorithm to setup bandwidth guaranteed ER-LSPs in MPLS backbone networks. The proposed routing algorithm confines the route discovery region in order to reduce the routing overhead and computes all possible routes from ingress node to egress node. Based on LSP requirements and network load conditions, the egress node selects the most suitable path from the available paths in order to setup the LSP. This routing scheme optimizes network resource utilization by evenly distributing traffic throughout the network. The Resource Reservation Protocol (RSVP) works in conjunction with the routing protocol for resource reservation and label distribution along the LSP. vii
CHAPTER 1 INTRODUCTION 1.1 Picture of the Internet With the commercial success of the Internet in the last two decades, the size of Internet and the traffic it generates has grown exponentially. Investigations show that the numbers of hosts on the Internet have tripled in the last two years and traffic is doubling every few months. Currently, more than 25 million computers, in over 180 countries, are interconnected through the Internet and the number is continuing to grow at a dramatic rate of 2 million new users per month. Figure 1.1: The Internet 1
The internet consists of many Local Area Networks (LANs) and Metropolitan Area Networks (MANs), which are interconnected through a backbone. The backbone is a super fast network that connects a number of national and global Internet Service Providers (ISPs). ISP networks are interconnected through Network Access Points (NAPs). Each ISP network consists of Point of Presence (POP) and interlinks between POPs. A sample ISP network  is presented in Figure 1.2. In general, POPs are interconnected in a ring fashion in order to improve reliability. An average ISP will have more than 50 POPs. POP is an integration of Accesses Routers (AS) connected to a remote customer, Border Routers (BR) that are connected to other ISPs, Hosting Routers (HR) connected to web servers and Core Routers (CR) connected to other POPs. Figure 1.2: A Sample ISP Network 2
Traffic is transmitted between the POPs through CRs. All other routes are connected to a CR using an OC3 link (155Mbps). However, high speeds CRs are interconnected using OC12 (622Mbps) or OC48 (2.5Gbps) links. 1.2 Why Conventional Networks Need More Than IP In the beginning, Internet applications were not considered mission critical and did not have specific performance requirements for throughput, delay, jitter and packet loss. As a result a single best-effort Class of Service (CoS) was adequate to support all Internet applications. In best-effort service, traffic is processed as quickly as possible and there is no guarantee for correctness or actual delivery. Due to its success, the Internet is now developing into a commercial infrastructure and the demand for service quality has escalated. In todays Internet, IP routing is based on the destination address and simple metrics such as hop count and delay. For example, in hop-by-hop a sender wants to send a data packet from A to B. In current IP routing, as the packet hops from router to router it continually looks for the next hop that is closest to B. It will go there and keep repeating the same process until it reaches the destination B. While looking for the next closest neighbor to the destination, factors like congestion are not taken into consideration. Sometimes this leads to selecting a path that is highly congested. Additionally, the route lookup process in each and every hop consumes precious time. Since all IP packets are not created equal (packets carrying voice and video are different from those carrying data) they may not be able to reach their destinations promptly enough to meet application needs. They can get stuck behind other packets whose Quality of Service (QoS) requirements are not sensitive. This makes traditional hop-by-hop IP packet forwarding ill suited for large-scale use with revenue generating 3
applications such as voice over IP and video conferencing. In a congestion state, even a small increase in the input traffic will greatly reduce the ability to carry useful traffic through the network. In general, destination based routing is succespable to the production of unbalanced traffic distribution and route oscillation, which will eventually lead to poor utilization of network resources in large backbones. The growing popularity of the Internet is forcing Internet service providers to adapt new technologies in order to support multiple classes of applications with different traffic characteristics and different performance requirements on the same network platform. The solution proposed for the problem is traffic management. Traffic management is defined as a set of mechanisms that are required to meet the performance demand of the applications in order to avoid congestion and improve the network resource utilization. However, the conventional routing approaches offer little support for traffic management. Distance vector routing protocols like the Routing Information Protocol (RIP) assigns a cost that is based on hop count and does not consider the loading conditions of various links in the network. Distance vector routing suffers from scalability and slow convergence to changes in the network. Even though the introduction of link state routing protocols addressed some of the problems with distance vector routing, they were not able to offer much support for traffic management. Open shortest path first (OSPF) routing offers load balancing with multi-path routing. However, OSPF routing decisions are based solely on destination the address, which helps very little in reducing congestion in the network. To address the problems in current IP networks, the Internet Engineering Task force (IETF) has proposed Multi Protocol label switching (MPLS)     as a 4
solution. The basic idea of MPLS is the assignment of short fixed labels to packets at the ingress router with the labels being used to make forwarding decisions instead of lookups for the destination address at each routing point. The labels effectively define a Label Switched Path (LSP), in the MPLS domain, to carry packets form source to destination. These LSPs can be manipulated and managed by the network administrator to direct the traffic. An LSP can be established in two ways. An LSP can be control driven, which is designated a hop-by-hop LSP or explicitly routed, which is called an ER-LSP. While setting up a hop-by-hop LSP, each Label switched Route (LSR) determines the next interface by looking at the layer-3 routing topology database and sends a label request to the next hop. Hop-by-hop LSPs follows the same route as layer 3 routed packets. In ER-LSP the complete route for the LSP is carried by the setup message. All the nodes that the ER-LSP will traverse and follow along the route are specified when the LSP is established. The most attractive feature of ER-LSP is that the route can be specified and controlled by the network management applications in order to direct the network traffic  . This makes it independent of layer-3 topology, which provides a good scope for traffic engineering (TE) . Router performance is also improved by avoiding routing table lookup for each and every IP packet. 1.3 Research Motivation With recent developments in Internet technology long awaited value added IP services are in production. Recent innovations in VLSI technology and processing speeds have opened new horizons for high-speed backbones. The growing demand for QoS services are forcing ISPs to adapt new technologies for more control over traffic and to improve the network resource utilization within high-speed backbones. The strength 5
of MPLS with traffic engineering for IP networks with bandwidth guaranteed label switched paths (LSPs) is attracting ISPs all over the world to design the next generation Internet, which will provide end-to-end Quality of Service (QoS) . LSPs are a more viable solution for improving network utilization than the current destination based routing. By carefully overlaying the bandwidth guaranteed LSPs over the physical network, ISPs can achieve a clear control over traffic distribution across their backbones. The basic problem is how to setup LSPs in or the network performance. Even though conventional routing protocols offer support for setting up an LSP, they generate substantial a amount of routing overhead and the route discovery process consumes a considerable amount of time. This thesis proposes a new way to set up LSPs with the help of a distributed routing algorithm. The objective of this algorithm is to fetch the most suitable path from source to destination based on QoS requirements and network load conditions. The algorithm exploits the knowledge of accurate link residual capacities in order to reduce the number of LSP request rejections and confines the route discovery region in order to optimize the route discovery process without overloading the network. Due to the distributive nature of the algorithm, the path is computed through the use of a distributed computation. During the computation control messages are exchanged among the nodes and the most up to date link state information at each node is collectively utilized in order to determine an optimal path. Once a path is selected the egress node initiates a Resource Reservation Protocol (RSVP) , which signals process and reserve resources upstream to the ingress node of the selected path to establish a bandwidth guaranteed ER-LSP. 6
1.4 Thesis Outline This thesis provides an overview of MPLS and ER-LSP setup in MPLS domains using a proposed distributed routing algorithm. Chapter 1 is an overview of the Internet, ISP setup and limitations of current IP networks. Chapter 2 presents an overall review of MPLS and its components. Topics like MPLS significance, MPLS components, label distribution methods, LSPs and RSVP are discussed in detail. Chapter 3 explains the routing algorithm proposed in this thesis and discusses the improvements provided over current algorithms. Performance comparison, simulation of the algorithm and results are discussed in Chapter 4. This chapter gives a detailed view of the simulation environment, test network layouts and the parameters considered in the evaluation of the proposed routing algorithm. Finally chapter 5 provides a summary and ideas concerning future work in this field. 7
CHAPTER 2 BACKGROUND This chapter explains the importance of Multi Protocol Label Switching (MPLS) in the emerging multi-service Internet. MPLS concepts such as label switching, Label Switched Paths (LSPs), Forward Equivalence Classes (FECs), label merging, label stacking, label distribution methods and Traffic engineering (TE) are discussed in detail. An overview of Resource Reservation Protocol (RSVP) along with proposed extensions for label distribution in setting up LSPs is also provided. 2.1 Introduction to MPLS Multi Protocol Label Switching,   , is a versatile solution to many problems currently faced by conventional IP networks. With enormous support required for traffic engineering and QoS, MPLS is emerging as the standard for the next generation Internet. The Internet Engineering Task Force (IETF) proposed MPLS as the standard. MPLS enhances speed, scalability and service provisioning capabilities in the Internet by reducing the amount of per-packet processing time required at each router and enhances router performance. MPLS provides significant capabilities in four popular areas.  2.1.1 Connection Oriented QoS Support Revenue generating applications like Virtual Private Networks (VPNs) and audio/video conferencing require increasingly sophisticated QoS support. The support is 8
required in order to assure the availability of bandwidth for specific applications and to provide guarantees for service level agreements. Contemporary IP networks cannot provide truly firm QoS enabled services to applications due to a lack of support for traffic engineering and QoS. Even though the Differentiated Service (DS) and Integrated Service (IS) frameworks provide support for QoS, their performance is limited with respect to scalability and flexibility features. In particular DS and IS approaches are inadequate for support of QoS enabled applications in highly loaded networks. MPLS enforces a connection-oriented framework on current IP-based networks and provides a foundation for reliable QoS enabled services. 2.1.2 Traffic Engineering (TE) The ability to dynamically define routes, plan resource commitments on the basis of known demand and optimize network utilization is referred to as traffic engineering. Current IP networks provide very poor support for traffic engineering. Specifically, routing protocols like OSPF enable routers to dynamically change the route to a given destination on a packet-by-packet basis while balancing the network load. In many cases such dynamic routing provides very little help in reducing network congestion and providing support for QoS. However, by enabling a connection-oriented framework in MPLS all the traffic between two end points follows the same route, which may be changed by simply using rerouting algorithms in the event of congestion. MPLS is not only aware of the individual packets, MPLS is also aware of packet flows, their QoS requirements and network traffic demands. With MPLS, for efficient load balancing, it is possible to setup routes on the basis of their individual flows or with two different flows between the same endpoints that follow different routes (maximally disjoint paths). 9
Practically, MPLS changes routes based on a flow-by-flow basis by taking advantage of the known traffic demands for each flow, instead of simply changing the route on a packet-to-packet basis,. With MPLS, it is easy to optimize the use of network resources in order to balance the load and to support various traffic requirement levels. 2.1.3 Virtual Private Networks (VPNs) A VPN typically uses the Internet as the transport backbone to establish secure links with business partners and to extend communications to regional and isolated offices. It significantly decreases the cost of communications for an increasingly mobile workforce since Internet access is generally local and much less expensive than dedicated remote access server connections. MPLS offers enormous support to VPN services. The use of MPLS for VPNs is an attractive alternative to building VPNs by using either ATM or Frame Relay Permanent Virtual Circuits (PVCs). Unlike a PVC model, the MPLS VPN model is highly scalable. It also supports the any-to-any model of communication among sites within a VPN without requiring the installation of a full mesh of PVCs across the service provider network. From the customer's perspective, a significant advantage of the MPLS VPN model is that in many cases routing can be dramatically simplified relative to the PVC model. Instead of managing routing over a topologically complex virtual backbone composed of many PVCs, an MPLS VPN customer can generally use the service providers backbone as the default route for all of the company's sites. Providers of VPN services often need to provide a range of QoS to their customers. MPLS VPNs support QoS through the use of emerging Differentiated Services (DS) techniques. With these techniques traffic is divided into different classes based on QoS requirements. The 10
different classes are identified by specific header bits or by different labels. Routes provide queuing treatments based on the header bits and labels in order to satisfy the QoS requirements. 2.1.4 Multi-protocol Support Multi-protocol support is one of the fascinating features of MPLS. The current Internet consists of different technologies such as IP routers, ATM switches and Frame Relay switches. MPLS can be used with many networking technologies and in pure IP networks, ATM networks, frame relay networks or any combination of two or even all three technologies. MPLS enabled routers can coexist with ordinary IP routers, ATM switches and Frame Relay switches. This universal nature of MPLS is attracting many users with mixed network technologies that are seeking a way to optimize resources and expand QoS support. 2.2 MPLS at a Glance  MPLS is a packet forwarding technology that uses labels to make packet-forwarding decisions. In this layer-3, analysis is performed only when the packet enters the MPLS domain and a label is assigned based on the layer destination address. An MPLS network consists of nodes called Label Switched Routes (LSRs). LSRs that connect non-LSRs (IP routers and ATM switches) are called Label Edge Routes (LERs). The LER through which a packet enters the MPLS network is called an ingress route and the LER by which a packet leaves the MPLS network is called an egress route. The general MPLS architecture is presented in Figure 2.1. These LSRs perform the switching and routing of data packets based on each packets assigned label. The route 11
traced by the packet between the ingress and egress nodes through intermediate LSRs is called a Label Switched Path (LSP). Figure 2.1: MPLS General Architecture When a packet enters an MPLS network a special database in the LER matches the destination address of the packet to a label. The label is inserted between the layer-3 (data link layer) and layer-4 (transport layer) headers. The object of labeling is to avoid any layer-3 lookups in forwarding the packet to the egress router. The label defines a flow of packets between two end points. Each flow is called a Forward Equivalence Class (FEC). A FEC contains all packets whose destination is a particular network prefix or all packets belonging to a particular application. All the packets in a FEC are provided the same treatment and route to a destination. The FEC for a packet can be determined by many parameters such as source or destination IP address, source or destination port number, IP protocol ID and differentiated service code point. Each LSR builds a table that specifies how packets must be forwarded. This table is called a Label Information Base (LIB), which is comprised of FEC to label binding information. Once the packet is assigned a FEC, an appropriate label is appended from the LIB. Then the packet passes through several LSRs in the MPLS domain on the way to its destination. Intermediate 12
LSRs examine the label, replaces the label with an appropriate outgoing label and forwards the packet to the next LSR along the LSP. The label switching process is illustrated in Figure 2.2. Figure 2.2: Label Switching Prior to assigning a packet to a FEC, the LSP must be set up and the required QoS parameters defined along the path. QoS parameters define the number of resources committed to the path and the queuing and discarding policies. In order to set up LSPs two protocols are used to exchange the necessary information among the LSRs. A routing protocol is required in order to determine the route from the ingress router to the egress router. A label distribution mechanism is also required to distribute labels along the path. A LSP can be established in two ways. The LSP can be control driven, which is a hop-by-hop LSP or it can be explicitly routed (ER-LSP). While setting up a hop-by-hop LSP, each LSR determines the next interface by looking at the layer-3 routing information provided by routing protocols such as OSPF and BGP and sends a label request to the next hop. A hop-by-hop LSP follows the same route that layer-3 routed packets follow in conventional routing. In ER-LSP the complete route for the LSP is 13
specified in the setup message. All the nodes that will be traversed along the ER-LSP are contained in the setup message and the order provides the route specification in establishing a LSP. This approach uses route discovery methods for setting up paths when defining a route from a source to a destination. The most attractive feature of the ER-LSP is that routes can be specified and controlled by network management applications in order to direct network traffic independent of the layer-3 topology, which provides a good scope for traffic engineering (TE). The label distribution method plays a significant role in setting up LSPs by distributing routing labels between neighboring LSRs. For efficient usage, labels are given only local significance. The use of signaling protocols such as the Label Distribution Protocol (LDP), Resource Reservation Protocol (RSVP) and Border Gateway Protocol (BGP) provides for label distribution to be carried out in MPLS networks. Section 2.4 presents a detailed review of LDP, RSVP and BGP label distribution operations. Eventually, the packet will arrive at the egress router where the label header is stripped and processed in order to determine the nature of the packet that is passed to the final destination. 2.3 MPLS Components 2.3.1 MPLS Header MPLS uses a 32-bit header that is created at the ingress router. It is embedded between the layer-2 (data link) header and layer-3 (network) headers. The format for an MPLS header is presented in Figure 2.3. The MPLS header consists of the following fields. 14
Label: 20-bit label value, which contains the MPLS label. Labels are assigned by the ingress LSR based on parameters such as destination address, traffic engineering, multicasting, virtual private network and QoS EXP: 3-bit field for experimental use S: Stacking bit used in label stacking TTL: 8-bit time to live field which places a limit on the number of hops Figure 2.3: MPLS Header 2.3.2 Label Binding and Assignment Binding refers to an operation at a LSR that associates a label with a FEC. Labels are bound to a FEC as a result of some event that indicates a need for such binding. Label binding can be control driven or data driven. In control driven bindings, control messages are used to exchange label and FEC information between peers. Data driven bindings take place dynamically and are based on the analysis of the received packets. Binding methods can be classified as downstream or upstream bindings. 15
In downstream binding, when an upstream router (Ru) sends a packet to downstream router (Rd), the Rd examines the packet and finds that the packet is associated with a FEC with label L. The Rd sends a request to the Ru to associate label L with all the packets intended for that particular FEC. The downstream binding method can be further divided into unsolicited downstream label binding and downstream on demand label binding. In the unsolicited downstream mode a downstream LSR locally associates a label for binding with a FEC and advertises its label binding information to its neighboring peers without being asked. In the downstream on demand mode the downstream LSR distributes a label only when explicitly requested by an upstream LSR for label binding for a FEC. In upstream binding, the Ru assigns a label locally to a FEC and advertises the assignment to its neighboring peers. Figure 2.4 presents a label-switching domain with three LSRs (LSR A, LSR B, and LSR C) and two host machines with IP addresses 192.168.1.2 and 192.168.1.1. Events 1 and 2 illustrate the down stream label assignment process between user 192.168.1.2 and LSR A. Events 3 and 4 illustrate the upstream label assignment. Figure 2.4: Label Binding 16
2.3.3 Label Distribution MPLS defines a label distribution process as a set of procedures that LSRs use to negotiate label information in forwarding traffic. There are many methods available to distribute labels in MPLS networks. Label Distribution Protocol (LDP), Resource Reservation Protocol (RSVP) and Border Gateway Protocol (BGP) are three popular methods of label distribution. Because of its popularity and support for traffic engineering, LDP is the most popular method of label distribution. The IETF has proposed LDP as a standard for label distribution in MPLS networks. Constraint-based Routing LDP (CR-LDP) is another protocol that allows network managers to set up explicitly routed LSPs, which are used for delay sensitive traffic. CR-LDP was derived from LDP. A brief review of all label distribution protocols is presented in section 2.4. 2.3.4 Label Spaces The label space refers to the manner that the label is associated with the LSR. The label space can be categorized into two ways. Per platform label space: Label values are unique across the complete LSR and labels are allocated from a common pool. No two labels distributed on the different interfaces have the same value. Per interface label space: The label ranges are associated with interfaces. Multiple label pools are defined from interfaces and the labels provided on those interfaces are allocated from the separate pools. Label values provided on different interfaces could be the same. Two octets in the LDP header carry the interface label spacing identifier. 17
2.3.5 Label Merging The incoming streams of traffic from different FECs can be merged together and switched using a common label if they are intended for the same final destination. This is known as stream merging or aggregation of flows. 2.3.6 Label Stacking One of the most powerful features of MPLS is label stacking, which is designed to scale to large networks. A labeled packet may carry many labels, which are organized as a last-in-first-out stack. Processing is always based on the top label. At any LSR a label can be added to the stack, which is referred to as a Push operation, or removed from the stack, which is referred to as a Pop operation. Label stacking allows the aggregation of LSPs into a single LSP for a portion of the route through different domains. This process is illustrated in Figure 2.5. Referring to Figure 2.5, assume LSR A, LSR B and LSR C belong to domain B (OSPF) while LSR X and LSR Y belong to domain A and C (BGP domains). This example also assumes that domain B is a transit domain. In order to set up an LSP from domain A to domain C, two levels of labels are used since there are two types of routing protocols. LSR X sends a packet to LSR A with label 21. Upon receiving the packet LSR A Pushes label 33 onto the label stack and forwards the packet to LSR B where label 33 is replaced with 14 and forwarded to LSR C. LSRs in domain B (OSPF) operate only on the top label, which is assigned by the exterior LSR of domain B. LSR C Pops the label from the label stack before sending it to domain C (OSPF) and LSR Y again operates on label 21, which is assigned by the BGP domain LSR. 18
Figure 2.5: Label Stacking 2.4 Label Distribution Methods 2.4.1 Label Distribution Protocol (LDP)  LDP is a set of procedures and messages by which LSRs establish LSPs through the network by mapping layer-3 routing information directly to layer-2 switched paths. The LDP operates between LSRs that are directly connected via a link or between non-adjacent LSRs. LSRs that use the LDP to exchange labels and FEC mapping information are called peer LSRs. They exchange information by establishing an LDP session. Figure 2.6 illustrates the concepts of LDP message exchange. The dotted line represents the logical exchange of LDP messages. In this exchange LDP messages from LSR A to LSR B pass through LSR B but LSR B will not take any action. Figure 2.6: LDP Message Exchange 19
The LDP uses a Type-Length-Value (TVL) encoding scheme to encode the information carried in the LDP messages. 188.8.131.52 LDP Header Each LDP message begins with a header followed by one or more LSP messages. The LDP header is presented in Figure 2.7. The header fields perform the following functions: Version: Version number of the protocol (currently 1) PDU length: Total length of the PDU in octets LDP ID: The sending LSRs label space identifier. The first four octets represent the IP address of the LSR and the last two octets represent the interface label space in the LSR. Figure 2.7: LDP Message Header 184.108.40.206 LDP Message Format The LDP message format is presented in Figure 2.8. The fields perform the following functions. U bit: Unknown bit. If the bit is set to 1 and is unknown to the receiver, it is discarded silently. 20
Message type: Indicates the message type. There are four categories of LDP messages. Message length: Specifies the length of the message ID. It contains both mandatory parameters and optional parameters. Message ID: This is a unique ID for the message, which can be used to associate notification messages with other messages. Mandatory parameters: A set of parameters such as keep alive time, label advertisement discipline (down stream or up stream), loop detection (enable or disable), path vector limit and PDU size. Figure 2.8: LDP Message Format 220.127.116.11 LDP Messages Hello message: This message is exchanged between peers during the LDP discovery operation. LSRs maintain a list of all hello messages received from potential LSR peers. By using this message peer, LSRs negotiate the holding time. Both of the LSRs will propose a holding time. The minimum holding time proposed is used as the actual holding time. Hello messages are also used to announce and maintain the presence of an LSR in the network. Periodically the 21
LSR sends a hello message through a UDP port with the multicast address of all routers on the subnet. Initialization message: This message is exchanged when LDP peers want to establish and maintain a session. In this process LSRs negotiate parameters such as keep alive time, label advertisement discipline, loop detection, path vector limit and PDU size. The session requesting LSR has to send a session message through the TCP port peer LSR in order to establish a session. Advertisement message: This message is used to create, exchange and delete label maps for FECs. This message is transported through a TCP port. An LSR can request a label mapping whenever it requires one or it can advertise a label to a peer LSR. Notification message: This message is used by an LSR to notify its peer about unusual or error conditions. Notification of conditions such as receiving unknown messages, expiration of keep alive time, shutdown by a node and failure of an LSP session is provided by use of this message. When an LSR receives a notification message with a status code it immediately terminates the LDP session by closing the TCP connection and discards all states of association with the peer LSR. Keep alive message: This message is used to monitor the TCP connection integrity between peer LSRs. Address message: This message is sent by an LSR to its LDP peer to advertise its interface address. Once the LSR receives an address message from its peer it 22
updates the label information base (LIB) for mapping between peer LDP identifiers and the next hops address. Address withdraw message: This message nullifies the address message and withdraws the previously advertised interface address. With this message the receiving LSR updates its LIB. Label mapping message: This message is used to advertise a FEC label binding between peer LSRs. This message contains IP addresses and their associated labels. A FEC Time Version and Length (TVL) specifies the FEC part of the FEC-label mapping. Label request message: This message is used by an LSR to request a label binding for a FEC from its LDP peer. Label request messages are sent whenever 1. An LSR recognizes a new FEC via a forwarding table and the next hop is an LDP peer. 2. A downstream LSR receives a label request from an upstream router. Label withdraw message: This message removes the mapping between a FEC and labels. This message is used to inform the peer LSRs to stop using specific FEC label bindings that were advertised in previous cases. This message is sent when an LSR no longer recognizes a previously known FEC for which it had advertised a label. Label abort request message: This message aborts an outstanding label request message. This message is issued when OSFP or BGP prefix advertisements change the label request operation. 23
2.4.2 Resource Reservation Protocol 18.104.22.168 RSVP Overview  Resource Reservation Protocol (RSVP) is a network control protocol that provides access to QoS for data flows in the Internet. RSVP works together with IP routing protocols and reserves resources along the routes that routing protocols calculate. RSVP is designed to manage flows of data rather than making a decision for each individual packet. A data flow is a sequence of datagrams that have the same source, destination and QoS requirements. QoS requirements are transmitted through the network with the help of a flow specification, which is a data structure used by the hosts to request special services from the network. These data flows consist of discrete sessions between specific source and destination machines. Sessions are identified by their destination address, protocol ID and destination port. RSVP supports both multi-cast and uni-cast sessions. To start an RSVP session, the host sends an RSVP Path message to a destination IP address. The message is forwarded to the destination based on the routing information available at the nodes. Once the receiver receives a path message, it sends the appropriate Reservation-Request messages upstream towards the sender. The RSVP protocol carries the request to all the nodes along the reverse data path towards the sender and reserves appropriate resources. After the sender application receives the Reservation Request message, the sender starts sending data packets. QoS is implemented for a particular data flow by a mechanism called traffic control. This mechanism includes a packet classifier, admission control and packet scheduler. 24
Figure 2.9: RSVP in Host and Router The packet classifier determines the QoS class for each packet and the packet scheduler allocates resources for transmission on that particular data link layer that is used by each interface. While RSVP passes the Reservation Request message upstream, at each node RSVP applies a local decision procedure called admission control to determine whether it can support the QoS request. If the request passes the admission control RSVP sets the parameters of the packet classifier and scheduler in order to obtain the desired QoS. If the admission control fails an error message is sent to the source. 22.214.171.124 RSVP Messages RSVP supports four message types. Path message: This message is sent along the uni-cast or multi-cast routes provided by the routing protocols. It is used to store the path from source to 25
destination that will be used to send route reservation-request messages from the upstream destination. Reservation-request message: The receiver sends this message upstream towards the sender in the process of reserving resources. Error and Confirm messages: o Path error message: Path error messages are delivered to the sender in case of path failure, which will result from a path message. These messages are routed by using the path state. o Reservation-request error messages: This message travels towards the receiver if admission control rejects a resource request. This includes admission failure, bandwidth unavailability, service not supported, bad flow specification and ambiguous path. Reservation request acknowledgement: This message is sent to the receiver as a result of a reservation request confirmation. This message contains a copy of the reservation confirmation. Teardown message: This message is used to remove the path and reservation without waiting for the timeout period. These messages are initiated by end systems in applications. RSVP supports path teardown and resource teardown messages. 126.96.36.199 RSVP Soft State Soft state refers to a state in which routes can be updated by RSVP messages. This permits an RSVP network to support dynamic group membership changes and routing changes. To maintain a reservation state, RSVP tracks a soft state in routers and 26
nodes, which will be periodically refreshed by path and reservation request messages. If no refresh messages arrive before the timeout process, the soft state will be deleted. The soft state can also be deleted with a teardown message. When the route changes the next path message will update the route state to the new route and reservation request messages will reserve resources on the new route. If a state change occurs RSVP propagates the changes end-to-end in the RSVP network. If the received state is different from the present state, the state is updated with the new state. 188.8.131.52 RSVP Reservation Styles Fixed Filter (FF) style: Creates a distinct reservation for traffic from each sender that is not shared by other senders. The total amount of bandwidth on a link for FF is the sum of all reservations for individual senders. It is used for applications in which the senders traffic is concurrent and independent. Wildcard Filter (WF) style: A single shared reservation is used for all senders to a session. The total reservation on a link remains the same regardless of the number of senders. It is used for applications where not all senders send traffic at the same time. Shared Explicit (SE) style: This method allows a receiver to explicitly specify the senders to be included in a reservation. There will be a single reservation on the link for all of the senders. 27
184.108.40.206 RSVP Message Format An RSVP message consists of a common header followed by a body. The RSVP message format is presented in Figures 2.10. Figure 2.10: RSVP Header Format RSVP message header fields contain the following information: Version: A 4-bit field that represents the protocol version number. Flags: A 4 bit-field that is currently undefined. Type: An 8-bit field with six possible values. Checksum: A 16-bit checksum representing the standard TCP/UCP checksum for RSVP messages. Length: A 16-bit length representing the RSVP packet in bytes. Send TTL: An 8-bit field representing the IP time-to-live value for the message. Message ID: A 32-bit field that provides a label that is shared by all fragments of one message from a given RSVP hop. More fragment (MF) bit: 1-bit message reserved. Fragment offset: A 24-bit field that represents the bytes of offset for the message. The RSVP body field values are presented in Table 2.1. 28
Table 2.1: Body Field Values in RSVP Messages Value Message Type 1 Path 2 Reservation request 3 Path error 4 Reservation request error 5 Path teardown 6 Reservation teardown 7 Reservation request acknowledgement 220.127.116.11 RSVP Object Fields The RSVP object format is presented in Figure 2.11. Figure 2.11: RSVP Object Format Length: A 16-bit field that specifies the total object length in bytes. Class-num: Identifier for the object class. C-type: Represents the object type, which is unique along with the class number. Object contents: Sessions, types, filters, and resource confirmations. 2.4.3 Extension to RSVP for Label Distribution  The extended RSVP supports the installation of explicitly routed LSPs with or without resource reservation. It also supports rerouting of LSPs, loop detection and 29
preemption. LSPs created by RSVP are also called LSP tunnels. These tunnels allow the implementation of various QoS policies along the tunnel. For example, these tunnels can be rerouted manually or automatically in case of network congestion or node failure in a LSP path. Hosts and routers that support RSVP and MPLS can associate labels with RSVP flows. This method employs downstream label assignment. Another important feature of the RSVP extension is its support for explicit routing capabilities. Explicit routing can be used in optimizing the utilization of network resources and to enhance traffic oriented performance characteristics. Using an explicitly routed LSPs ingress node can control the path from source to destination through the MPLS network. This can be accomplished by incorporating an EXPLICIT_ROUTE object in the RSVP path message. The EXPLICIT_ROUTE object carries the series of nodes that comprise the explicitly routed path. Based on the QoS requirements and network state, the administrator can specify these paths, which play a very important role in traffic engineering. 18.104.22.168 Establishing an LSP Tunnel  To create an LSP tunnel, the ingress router requests a label binding from a down stream router by initiating an RSVP path message. The RSVP path message will contain a LABEL_REQUEST object. Upon receipt of the LABLE_REQUEST object, the next hop LSR sends a label object with a RSVP Resv message. The RSVP Resv message travels upstream to the sender by following the path created by the Path message. The LABEL_REQUEST object requests all intermediate routers and receiver node to provide a label binding for the session. If a node fails to provide a label binding, it sends a Path 30
Err message with an unknown object class error. Figure 2.12 presents the LSP tunnel setup. Figure 2.12: LSP Tunnel Setup Using RSVP Extension 22.214.171.124 RSVP-Extended Path Message The path message with the SESSION type LSP_TUNNEL_IPV4, which is generated by the ingress router consists of the following objects: LABEL _REQUEST object: This object requests a label from the downstream router. EXPLICIT_ROUTE object (RRO): This object can be added to specify a pre determined path across the network. RECORD_ROUTE object (ERO): Allows the ingress router to receive a list of LSRs along the tunnel path. SESSION_ATTRIBUITE object: This object is used in session identification and monitoring. It also controls path setup priorities, holding priorities and local rerouting features. 31
126.96.36.199 RESV-Extended Message This message is transmitted by the egress LSR towards the ingress LSR in response to a PATH message and consists of the following objects: LABEL object: Performs the downstream label distribution process. RECORD_ROUTE object: Returns the LSPs path to the sender from the PATH message. SESSION object: Uniquely identifies the LSP being established. STYLE object: Specifies the reservation style (fixed-filter or shared-explicit). 2.4.4 Carrying Label Information in BGP-4  Border Gateway Protocol (BGP) is the current exterior routing protocol used by the Internet. BGP uses TCP as its transport protocol on port 179. When BGP peers are first established they exchange complete copies of their routing tables. When changes to routing tables are detected, BGP routers send only the changed routes to their neighbors. A BGP router does not send periodic routing updates and BGP updates advertise only the optimal path to a destination network. When BGP is used to distribute a particular route it can also be used to distribute an MPLS label that is mapped to the router. The label mapping information for a particular route is piggybacked on the BGP update message that is used to distribute the route itself. This method significantly improves scalability. Label distribution using BGP is helpful in following cases: If two LSRs are immediately adjacent and BGP peers, label distribution can be performed without any label distribution protocol. 32
If the exterior LSRs are BGP peers and distribute labels to each other, then all the interior LSRs that support MPLS need not receive any of the BGP routes from BGP peers. Label distribution is piggybacked on BGP updates using BGP-4 Multi-protocol Extension attributes. The label is encoded in the Network Layer Reachability Information (NLRI) field and the Subsequence Address Family Identifier (SAFI) is used to indicate the presence of the label. Figure 2.13: Label Distribution Between Non-Adjacent BGP Peers 188.8.131.52 Carrying Label Information Label information is carried as part of the Network Layer Reachability Information (NLRI) in the multi-protocol extensions attribute. NLRI is encoded as one or more triples of the form length, label and prefix, which is presented in Figure 2.14. Length: Indicates the length in bits of the address prefix plus the labels. Label: This field carries one or more labels that correspond to the label stack. Each label is encoded as 3 octets. The high-order 20bits contain the label value and lower order bit contains the bottom of stack. 33
Prefix: This field contains address prefixes followed by a sufficient number of trailing bits in order to make the end of the field fall on an octet boundary. The value of the trailing bits is irrelevant. Figure 2.14: NLRI Information 2.5 Constraint Based Routing One of the key issues in providing QoS guarantees is to determine paths that satisfy QoS constraints. A solution to this problem to QoS routing is also called Constraint Based Routing (CBR). CBR is a mechanism used to meet the traffic-engineering requirement for MPLS networks. In CBR, the route is computed from source to destination based on a set of metrics such as bandwidth, delay and hop count. Explicit routing is an integral part of CBR where a route from source to destination is computed before setting up the LSP based on metrics. Once the path is determined signaling protocols such as LDP or RSVP are used to setup Explicitly Routed Label Switched Paths (ER-LSPs) from the ingress to the egress node. ER-LSP is considered to be a capable solution in order to improve network utilization rather than the current destination based routing protocols. 34
Figure 2.15: MPLS Explicit Routing There are currently two protocols in MPLS to establish ER-LSP. The two protocols are Constraint-based Routing over LDP (CR-LDP) and RSVP modified to handle MPLS traffic engineering requirements (RSVP-TE). CR-LDP is an extension to LDP and RSVP-TE is an extension to RSVP to support explicit routing and traffic engineering in MPLS networks. ER-LSPs play a major role in traffic management by setting up bandwidth guaranteed LSP and load balancing to reduce network congestion. Figure 2.15 presents ER-LSPs through an ISP core between network 1 and network 2. 35
CHAPTER 3 PROBLEM DISCUSSION AND PROPOSED SOLUTION This chapter explains the proposed routing algorithm for setting up ER-LSP in MPLS networks. A brief introduction to conventional routing techniques and some problems associated with them are also discussed. The basic idea behind the proposed algorithm, its terminology, modes of operation and the problems addressed by the algorithm are discussed in detail. 3.1 Conventional Routing Techniques Conventional routing protocols are based on either distance vector routing or link state routing algorithms. 3.1.1 Distant Vector Routing This routing method requires each router to maintain a routing table that includes all possible destinations. Frequently the routing table will be broadcast to all the routers neighbors. Periodically, all routers in the network update their routing table using this information. The distant vector routing algorithm computes the shortest path from the source to the destination. In order to forward a packet, each router compares the distances received from each destination and determines the next hop. Route calculations are based on the Bellman-Ford algorithm. RIP and IGRP are widely known distance-vector routing protocols. 36
184.108.40.206 Problems Associated with Distance Vector Routing Distance vector routing does not take into account the network topology and takes a considerable amount of time to converge to changes in the network topology. Slow recovery causes problem such as counting to infinity and routing loops. Counting to infinity is a state where packets are looped continuously around the network despite the fact that the destination network is down. Route computations are based on hop count and not on metrics such as latency and bandwidth. 3.1.2 Link State Routing The link state routing protocol requires each router to maintain a partial map of the network. Periodically, all routers broadcast updates regarding the link status and topology changes. This event is called link state advertisement (LSA) and is flooded throughout the network. All routers note the changes and recompute their routes accordingly. This method is more reliable, easier to debug and less bandwidth-intensive than Distance-Vector-Routing. A well-known link state routing protocol is OSPF. OSPF routes are computed based on Dijkstras shortest path algorithm. 220.127.116.11 Problems Associated with Link State Routing To maintain a complete picture of the network routers require more memory. Periodic flooding consumes a considerable amount of bandwidth for the network. Link failures and new link establishments lead to unsynchronized updates and inconsistent path decisions. Routing is inefficient in large networks due to synchronization problems. 37
3.2 Problems with Conventional Routing and Solution  Conventional routing protocols are designed with a single point agenda to route packets from a source to a destination. Issues such as network performance optimization and resource utilization are given less importance in designing these routing protocols. This approach works well for Internets best-effort model. However, it doesn't provide adequate support for effective resource allocation and optimization. Widely used shortest path algorithms tend to cause traffic to converge onto the same link, which causes uneven traffic distribution across the network and creates bottlenecks Decisions are made in IP routing based on simple metrics such as hop count or delay. Even though the simplicity of IP routing is highly scalable, it typically doesn't enable optimization of resource utilization in the network backbone. These problems can be explained with an example, which is presented in Figure 3.1. Figure 3.1: Uneven Resource Utilization In this topology, there are two potential routes, C-D-G and C-E-F-G, from A to G and B to G. The C-D-G is considered the shortest path. Therefore, the routing protocol will direct all the traffic from A to G and B to G through the C-D-G path. This path 38
decision will cause an overload it for the C-D-G path while C-E-F-G path will remain idle. This problem happens because the routing protocol directs all packets, whose destination addresses shares the same prefix, to the same subsequent hop. Usually, in conventional IP routing, there will only be one path in the routing table for each destination even though there might be multiple suitable paths available. This situation leads to congestion and uneven traffic distribution. Poor route selection based on local optimization is another that contributes to the inefficient utilization of network resources. Each node selects the route from its own perspective, which might not be optimal for the entire network. For example, in the network presented in Figure 3.1, all the nodes in the network consider C-D-G as the shortest path and routes traffic through this path even when C-E-F-G is the better choice. This problem can be overcome by providing mechanisms for traffic management throughout the network. Using Traffic Engineering (TE), network operators can redistribute packet flows to attain a more uniform distribution across the network. Forcing traffic onto specific pathways allows resource optimization and at the same time makes it easier to deliver consistent service levels to customers. The common MPLS based approach for traffic engineering is the Overlay model. In this approach, service providers use MPLS to build a virtual network that includes a full mesh of logical connections between all network edge nodes. These logical connections can be MPLS explicit routes, which are enforced with bandwidth reservation. The traffic engineering objectives are accomplished by establishing these explicit routes over the physical network in such a manner as to evenly distribute traffic across all trunks within the network. Figure 3.2 presents the MPLS overlay approach to traffic engineering. Routers 39
A, B, C, D and E represent edge routers connecting external routing domains. In the MPLS overlay approach a virtual network is established via logical connections between all pairs of edge nodes. These logical connections can be established as MPLS LSPs with explicit control over the specific routes. Figure 3.2: MPLS Overlay Model 3.3 Problems with Conventional Routing in Setting up LSPs In order to calculate an explicit route, the ingress node needs to know the current topology and the available capacities. Currently, the available conventional routing protocols are designed with a single point agenda for routing packets from a source to a destination. Issues such as network performance optimization and resource utilization are given less importance during the design of routing protocols. This approach works well for Internets best-effort model. However, it doesn't provide adequate support for effective resource allocation and optimization. Widely used shortest path algorithms tend 40
to cause traffic to converge onto the same link, which causes uneven traffic distribution across the network and leads to bottlenecks. Although IP routing is highly scalable, it typically doesn't enable optimization of resource utilization, especially in backbone networks, where traffic volume and service requests change rapidly. A major problem exists for conventional routing protocols in ER-LSP since the LSPs are more sensitive to global state information and link residual capacities. This sensitivity is due to their QoS requirements and Service Level Agreements (SLA). Periodic routing updates do not guarantee up to date global state and residual capacity information since the state of node can change at any time. Inaccurate information regarding global state and link residual capacities may lead to LSP failures. Additionally, high routing overhead, which is generated by global state and residual capacity updates creates scalability problems. To a great extent, routing overhead messages volume increases in order to accommodate a variety of applications with a variety of QoS requirements such as bandwidth, loss rate, delay, delay jitter and cost in different measurements. It is also difficult to determine an ideal period to exchange all metrics among nodes due to different metrics changing at different times. For example, topology changes are less infrequent when compared to available bandwidth changes on communication links. A small routing update period leads to high overhead and a large period results in outdated information. Finally, in the case of setting up bandwidth guaranteed tunnels with RSVP, the reservation request process has to be initiated by the receiver. If the receiver receives all the possible routes from a source to a destination, based on QoS requirements and network load conditions, the receiver could select an optimal route to provide reliable service to users and at the same time distribute traffic evenly in network. 41
3.4 Proposed Algorithm 3.4.1 The Basic Idea A LSP request at an ingress node is defined by a quadruple (Ix, Ex, Qx, Rx). Where Ix specifies the ingress router, Ex specifies the egress router, Qx specifies QoS requirements and the nature of traffic and Rx represents a unique request identifier for LSPx. A new LSP can be routed along a given link only if the residual bandwidth of the link is more than the required bandwidth of the new LSP. The residual bandwidth for a link is defined as the difference between the total bandwidth for the link and the sum of the demands of the LSPs that are routed on the link. A network is considered as a set of N nodes that are interconnected by a set of k links. The basic idea behind the algorithm is to divide the network into a number of overlapping clusters where a cluster is defined as a subset of nodes. One node, for each cluster, is elected as a cluster head. The cluster is also called an Intelligent-node or I-node. All the I-nodes in the network maintain a global routing table, which provides information regarding all other I-Nodes and their associated cluster members. Other than I-nodes all other nodes in the network maintain a local routing table called a neighbors list, which represents information regarding all other nodes in their own cluster including the cluster head. Whenever an LSP request arrives at an ingress node, the ingress looks for a destination egress node in its neighbors list. If the egress is found in its own neighbors list then a route setup message will be passed to egress through the local I-node. The route discovery process will be initiated and route request packet will be forwarded to the local I-Node. A route request packet consists of a LSP request quadruple and a route 42
record. The route record is used to store information regarding the path traversed by the route request packet on its way to the egress node from the ingress node. Path information such as the sequence of nodes traversed, number of hops, available bottleneck bandwidth and total cost are stored. This information plays an important role in optimal path selection to the egress node. Link cost is based on residual bandwidth. Higher link costs correspond to low residual bandwidths while low route costs correspond to high residual bandwidths. The optimal path is determined based on the total cost information, QoS requirements and network load conditions at an egress node. The local I-Node looks for a destination in its routing table and forwards the route request packet to adjacent INodes, which are connected through border nodes, until the packet reaches its destination. At each hop, before forwarding the route request packet to the next node, QoS requirements are checked to make sure that the path supports the LSP requirements. In this manner the path from Ix to Ex is established. 3.4.2 Cluster Formation and I-Node Selection The establishment of cluster formation is the initial process carried out with respect to this algorithm. Every node in the network reserves one port to send and receive beacon messages regarding their existence in the network. During the setup stage, every node in the network sends beacon messages to their neighbors informing them of its existence in network. With the help of the beacon message, each node in the network updates its neighbors list. After completion of the beaconing process every node checks for the number of neighbors to which it is connected. If a node is connected to more than 3 neighbors it will attain I-node status and notify its neighbors of its status. Neighbors respond to the status message by sending associated acknowledgements to the 43
I-node, which establishes the cluster formation for the cluster that the I-node will act as cluster head. The status message carries an I-node number and its associated neighbors that form the cluster. Using the status message, all the nodes in a particular cluster update their neighbors list, which represents information about the local cluster. If a node is not directly connect with an I-node it will be treated as an alien node. Alien nodes send association requests to their neighbors that request association with their neighbors cluster and I-node. Neighbors forward this association request to the local I-node, which then includes the alien node in the cluster and informs all its neighbors about the alien node association. Figure 3.3 presents the NSF-NET topology for the proposed distributed routing algorithm with 16 nodes and 6 cluster heads. Table 3.1 presents an overview of the NSF-NET topology. Figure 3.3: NSF-NET Topology with the Proposed Routing Algorithm 44
Table 3.1: NSF-NET Network Topology-1 Overview Node Neighbors list No of Neighbors Node Status 1 2,5 2 Node 2 1,3,4,9 4 I-Node 3 2,4,5 3 Node 4 2,3,7 3 Node 5 1,3,6,11 4 I-Node 6 5,7,8 3 Node 7 4,6,10,16 4 I-Node 8 6,9 2 Alien Node 9 2,8,12 3 Node 10 7,12 2 Node 11 5,13,15 3 Node 12 9,10,13,15 4 INode 13 11,12,14,16 4 I-Node 14 13,15 2 Node 15 11,12,14,16 4 I-Node 16 7,13,15 3 Node 3.4.3 The Routing Table The routing table provides information regarding the total network topology for the I-Nodes. The routing table contains all the I-Nodes in the network and their associated cluster members. As explained earlier, routing requests are only forwarded to I-Nodes during the route discovery process. When an I-Node receives a route request it checks with its neighbors list. If the destination address is in the neighbors list the route request will be forwarded to the destination. In other cases the I-Node looks in the 45
routing table for a destination address and forwards the route discovery packet to the proper I-Node through neighboring I-Nodes. Table 3.2 presents the routing table for the network topology presented in Figure 3.3. Table 3.2: NSF-NET Topology-1 Routing Table Cluster Number I-Node Cluster Members 1 2 1,3,4,8,9 2 5 1,3,6,8,11 3 7 4,6,10,16 4 12 9,10,13,15 5 13 11,12,14,16 6 15 11,12,14,16 3.4.4 The Routing Process Two different types of routing scenarios, interior cluster routing and exterior routing, are examined in the algorithm. Interior cluster routing is a process whereby both ingress and egress nodes belong to the same cluster and are connected through a local I-node. Exterior routing is necessary when the ingress and egress nodes belong to different clusters and the ingress node has no information with respect to the egress node. When a source node requires a route to a destination it initiates a route discovery process that will discover a route from a source to a destination. Every route discovery process will be associated with a unique identifier (ID) in order to avoid duplicate requests for the same route in case the receiver is only interested in the fastest open route. Duplicate packets are not discarded since the receiver could be interested in all possible 46
routes from a source to a destination. Information about all possible routes is helpful in load balancing and path restoration in the event congestion occurs on the main path. The route maintenance process monitors the validity of the route discovered by the route discovery process. When a route maintenance process detects a problem with the existing route it initiates the route discovery process in order to determine a new route or a message is sent to the receiver requesting a shift to an alternate route. 18.104.22.168 The Route Discovery Process When a LSP request quadruple arrives at an ingress node the ingress node checks for an egress node in its neighbors list. If an egress node belongs to the same cluster the ingress node checks any QoS requirements on its link to the local I-node. If QoS requirements are satisfied the ingress node initiates a route setup message that carries the LSP request quadruple being forwarded to the local I-node. The I-node checks for QoS requirements on the link and forwards the route setup request to the egress node. The egress node initiates the RSVP process in order to reserve resources upstream of the ingress node. If any link on the way to the egress fails to support QoS requirements an error message with a unique code is generated and forwarded to the ingress node. In the case of an exterior routing process the ingress router will initiate a route discovery process and generate a route request packet, which will be forwarded to the local I-node. Once the local I-node receives a route request packet it looks at its routing table to obtain information regarding border nodes in order to establish link information about connecting to neighboring I-nodes. Border nodes directly connect I-nodes. Once border node information is acquired the local I-node forwards a route request packet to all of its neighboring I-nodes. Prior to forwarding the route request packet each node 47
ensures that QoS requirements are satisfied on the link to the next node. Upon receiving a route request packet the I-node looks for an egress node in its neighbors list. If an egress router is found in the neighbors list, a route request packets is forwarded to the egress router. Otherwise the I-node router request packet is again forwarded to neighboring I-nodes until it reaches the destination egress node. If any I-node receives a second route request packet with the same LSP request ID it will be discarded in order to avoid redundant routing overhead. Figure 3.4 exhibits a route request packet traversing from node 1 to node 15 with a LSP request (1, 15, QoS, Req_ID). As shown in Figure 3.4, three different paths are available from node 1 to node 15. Route request packets traverse through all these paths and store route information in a route record. Based on the information provided by route records and LSP QoS requirements, egress node 15 will select a suitable path for network optimization. Figure 3.4: Route Discovery Process for a LSP Request from Node 1 to Node 15 48
3.4.5 Path Selection Path selection is the process used by the egress node to select an optimal route in order to improve network resource utilization. As described previously, balancing the network load evenly and limiting resource consumption can achieve resource optimization. Route request packets traversing through different paths will reach the egress node. By looking at the route record the egress node obtains information regarding the sequence of hops, number of hops and total cost of a particular path. Based on the number of hops and the available bandwidth (cost) routing paths can be classified with respect to four different categories. Shortest path or Minimum-hop path: A path with the minimum hop count among all feasible paths. If there are several paths one is selected randomly. Widest-shortest path: A path with a minimum hop count among all feasible paths. If there are several paths the one with maximum residual bandwidth is selected. If there are several paths with the same bandwidth one is selected randomly. Shortest-widest path: A path with the maximum bandwidth among all feasible paths. If there are several paths the one with a minimum hop count is selected. If there are several paths with the same hop count one is selected randomly. Minimum-load path: A path with maximum residual bandwidth. If there are several paths one is selected randomly. Whenever a route request packet is received by an egress node it checks the LSP bandwidth requirements. If the bandwidth requirements are high a minimum-hop path or a widest-shortest path is selected in order to limit resource utilization. If the bandwidth requirements are moderate and the network load is light a minimum-load path or a 49
shortest-widest path is selected in order to balance the network load. Path selection also depends on the nature of the traffic that is specified in the QoS requirements. For example, if the traffic is real time audio or video data then preference is given to a shortest path or a widest-shortest path. 50
CHAPTER 4 SIMULATION AND PERFORMANCE STUDY The performance of the proposed routing algorithm was evaluated through a simulation based on the NSF-NET topology. The main goal of the simulation was to study the performance and scalability of the proposed routing algorithm with an NSF-NET network topology. The performance was judged by measuring the amount of routing overhead generated, the blocking probability, path restoration capability and load balancing. The results were compared with conventional methods such as the flooding and shortest path algorithms. Simulation results showed that the proposed routing algorithm considerably reduces routing overhead and the blocking probability while providing support for path restoration and load balancing. 4.1 Simulation Environment Simulations were conducted on the NSF-NET topology that is presented in Figure 4.1. The NSF-NET is a high speed hierarchical network funded by the National Science Foundation It is a backbone network comprised of 16 nodes connected to a 45Mb/s facility, which spans the continental United States. Mid-level networks from universities and local networks are attached to the NSF-NET. The network topology and the proposed algorithm simulations were written in the C programming language. 51
Figure 4.1: NSF-NET Backbone Topology 4.2 Performance Parameters Several parameters were considered in order to evaluate the performance of proposed routing protocol. The parameters considered were: Routing Overhead: The total number of routing packets generated during the route discovery process. Multiple Routes: For load balancing and path restoration. Blocking Probability: Number of LSP requests blocked out of N requests. Routing Loops: Routing packets traversing in a loop. 4.2.1 Routing Overhead Routing overhead was one of the most important parameter considered in judging the routing protocols efficiency. Route request packets that are generated in the route discovery process and periodic updates with respect to topology information wastes precious network bandwidth. This overhead includes topology information, periodic updates and route requests. With conventional protocols a considerable amount of bandwidth is wasted due to overhead generated due to periodic updates and routing processes. 52
Due to distributive nature and the cluster based I-node scheme, the proposed algorithm generated a considerably lower routing overhead when compared with the flooding protocol. The simulation results are presented in Figures 4.2 and 4.3. The proposed routing algorithm was used to calculate routes from node 1 to all other nodes in the NSF-NET. Figure 4.2 presents a comparison of the routing overhead generated by the proposed routing algorithm and the blind flooding protocol. Figure 4.2 shows that the routing overhead was directly proportional to the distance between the ingress and egress nodes. If the ingress node and the egress node belonged to the same cluster or neighboring clusters, the route discovery process generated less routing overhead. The proposed algorithm decreased the average routing overhead obtained from the flooding protocol by 30%. Figure 4.3 presents the same overhead comparison with node 15 as the ingress node. Figure 4.2: Routing Overhead Comparison with Node 1 as Source 53
Figure 4.3: Routing Overhead Comparison with Node 15 as Source A more in depth analysis was considered with the network topology presented in Figure 4.4. This network topology consisted of 6 nodes and 3 I-nodes. For example, ingress node 1 received a LSP request (I1, E6, Qx, Req_ID) where QoS requirements demanded maximally disjoint paths for load balancing. Figure 4.4 illustrates route request packets that were generated with flooding, which is a popular method for finding disjoint paths, and the packet produced by the proposed algorithm. Flooding generated 32 route request packets and required 3 events in order to provide disjoint paths to the destination. With the proposed routing algorithm, only 4 route request packets and 2 events were generated in order to provide same information. 54
Figure 4.4: Routing Over Head in Flooding and the Proposed Algorithm 4.2.2 Multiple Route Support Load balancing is a concept that allows a router to take advantage of multiple best paths to a given destination. The paths are derived with either static or dynamic protocols. 55
The proposed algorithm provides a convenient way of finding maximally disjoint paths by sending routing requests on all possible paths. After selecting a path for the destination based on QoS requirements, the local I-Node constantly looks for any route request packets arriving on different paths. As explained previously, the local I-Node makes a copy of the route record of the selected route and compares the route record with the other route requests that arrive for the same destination. If the path traversed by the new route request is different from the selected route the local I-Node sends a copy of the new route request packet to the destination. The destination egress node uses this route in case of a primary router LSP failure or for load balancing applications. Figure 4.5 shows route requests traversing from node 1 to node 6 for maximally disjoint paths. The simulation study showed that the proposed routing algorithm provides multiple paths and available maximally disjoint paths for load balancing and path restoration. Figure 4.5: Maximally Disjoint Paths 4.2.3 The Blocking Probability With the growing popularity of the MPLS overlay model and Traffic Engineering (TE) in backbone networks; Label Switched Paths (LSPs) are gaining more and more significance. Whenever a service request arrives at a node, a LSP will be established from the source to the destination for data transfer. As explained previously, based on 56
the applications LSPs have different QoS and bandwidth requirements. The blocking probability is defined as the number of service requests blocked out of the total requests received. Blocking Probability = Number of requests blocked / Total number of requests. A low blocking probability allows more service requests to be served and ISPs can generate more revenue. Currently, routing decisions are based on shortest path algorithms such as Dijkstrass algorithm and the Bellmen-Ford algorithm. These shortest path algorithms force traffic onto the same link, which leads to congestion and the congestion increases the blocking probability. In the proposed routing algorithm, path selection was given more importance in order to reduce the blocking probability. The egress router carefully examines all route request packets and route records. Then as a function of network load conditions and LSP QoS requirements an optimal path is chosen for a LSP setup. This process evenly distributes traffic through out the network and limits resource utilization, which eventually reduces the blocking probability allowing more service requests to be processed. Two sets of simulations were conducted in order to check the blocking probability calculation. In the first simulation setup, all links in the NSF-NET topology were considered as 100Mbps links and random LSP requests were routed through the NSF-NET. In the second simulation setup the NSF-NET links were upgraded to 250 Mbps from 100 Mbps. LSP requests were generated using a random number generation function with different bandwidth requirements. These requests were routed through the NSF-NET using the proposed routing algorithm and the blocking probability was calculated as a function of LSP bandwidth requirements. The blocking probability results 57
obtained with the proposed algorithm were compared with Dijkstras shortest path algorithm. Figures 4.6 and 4.7 present the NSF-NET topology blocking probability results for simulation setups one and two respectively. Figure 4.6: NSF-NET Blocking Probability with 100 Mbps links Figure 4.7: NSF-NET Blocking Probability with 250 Mbps links 58
Simulation results showed that the blocking probability was decreased considerably with the proposed algorithm when LSP bandwidth requirements were low and moderate. With high LSP bandwidth requirements the blocking probability results for the proposed algorithm were close to the shortest path algorithm results. With 100 Mbps links, the proposed algorithm decreased the blocking probability by 6%. After the link was upgraded to 250 Mbps the blocking probability was decreased further to 10%. 4.2.4 Routing Loops The other important issue studied was routing loops. In conventional routing methods, topology change updates and link residual capacities are broadcasted throughout the network at regular intervals. Routing loops result from out of date routing tables that direct route request packets to traverse a series of nodes without reaching a destination. As explained previously, with the proposed algorithm every route request generated is given a unique request identification number (REQ_ID). Whenever a route request passes through an I-node, the LSP request, (Ix, Ex, QoS, REQ_ID), is stored on a temporary stack. Duplicate route request packets, with the same LSP request identifier, are eliminated, which successfully avoids routing loops. 59
CHAPTER 5 CONCLUSION AND FUTURE WORK 5.1 Conclusion With an ever-growing demand for QoS enabled IP services, ISPs are forced to adapt new technologies for more control over traffic and to improve network resource utilization within high-speed backbones. Current research is focused more on traffic engineering with Explicitly Routed Label Switched Paths (ER-LSPs) for clear-cut control over traffic distribution in Internet backbone networks. This thesis proposed a new distributed routing algorithm for ER-LSP setups in MPLS backbone networks. The algorithm exploits the knowledge of accurate link residual capacities in order to reduce the number of LSP request rejections and confines the route discovery region in order to optimize the route discovery process without overloading the network. Simulation results showed that this cluster based I-node scheme produces a very improved LSP acceptance rate and improves network resource utilization. With the proposed cluster based I-node scheme, routing overhead was reduced more than 30% when compared with flooding and blocking probability was reduced nearly 10% when compared with shortest path algorithms. Through the computation of multiple paths the proposed algorithm provided greater support for path restoration and load balancing. 60
5.2 Future Work In this research a LSP setup was separated into a routing process and a resource reservation process. In the routing process, the proposed routing algorithm creates an optimal route for LSP establishment and the resource reservation process initiates an RSVP signaling process on the path created by reserving resources for LSP establishment. Combining these two processes into a single process can decrease LSP setup time much more. This could be accomplished by adding router request packets to RSVP path messages and equipping the RSVP daemon with path selection capabilities. Another important issue considered by the proposed algorithm is network optimization. In order to make routing decisions all the nodes in the network should be aware of network load and traffic conditions. This information can be generated from periodic traffic logs or by employing network snooping devices. Some functionality has to be added to the routing algorithm in order to obtain information regarding network load conditions and to broadcast such information to all the nodes in the network at regular intervals. Finally a Network Simulator (NS-2) patch could be used for in-depth investigation of the proposed algorithms merits and demerits. 61
REFERENCES  Xipeng Xiao Providing Quality of Service in the Internet, PhD Dissertation, Michigan State University  Rosen, E., Viswanathan, A. and R. Callon Multiprotocol Label Switching Architecture, RFC 3031, January 2001  William Stallings, Multiprotocol Label Switching (MPLS ), White paper, Cisco Systems  Uyless Black, Multi-Protocol Label Switching , Prentice Hall, December 2000  Tony Rybczynski and Bilel Jamoussi, Powering Core Networks through MPLS, White paper, Nortel Network  S. Hiroyuki, Y. Miyao and M. Yoshida, Traffic Engineering using Multiple Multipoint-to-point LSPs, IEEE INFOCOMM 2000  IP Traffic Engineering for Carrier Networks: Using Constraint-Based Routing to Deliver New Services White paper, Nortel Networks  R. Braden, Ed. L Zhang, S.Berson, S. Herzong and S. Jamin, Resource Reservation Protocol, RFC 2205.September 1997  Anderson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, LDP Specifications, RFC 3036, January 2001  Swallow et al., RSVP-TE: Extensions to RSVP for LSP Tunnels, Work in progress, http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-08.txt  D. Awduche, L.Berger, D. Gan, T. Li, V.Srinivasan and G. Swallow RSVP-TE: Extension to RSVP for LSP tunnels, Internet Draft, November 1998  Y. Rekhter and E. Rosen Carrying Label Information in BGP-4 RFC 3107, May 2000  Daniel O. Awduche, MPLS and Traffic Engineering in IP Networks, IEEE Communications, Dec 1999 62
xml version 1.0 encoding UTF-8 standalone no
record xmlns http:www.loc.govMARC21slim xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.loc.govstandardsmarcxmlschemaMARC21slim.xsd
leader nam Ka
controlfield tag 001 001430568
007 cr mnu|||uuuuu
008 031007s2003 flua sbm s000|0 eng d
datafield ind1 8 ind2 024
subfield code a E14-SFE0000086
Garige, Naga Siddhardha.
A distributed routing algorithm for ER-LSP setup in MLPS networks
h [electronic resource] /
by Naga Siddhardha Garige.
[Tampa, Fla.] :
University of South Florida,
Thesis (M.S.E.E.)--University of South Florida, 2003.
Includes bibliographical references.
Text (Electronic thesis) in PDF format.
System requirements: World Wide Web browser and PDF reader.
Mode of access: World Wide Web.
Title from PDF of title page.
Document formatted into pages; contains 62 pages.
ABSTRACT: The rapid growth of the Internet, in the last few years, has generated a need to enhance the existing IP networks in the areas of availability, dependability and scalability in order to provide a mission critical networking environment. In contemporary IP networks, data packets are routed as a function of the destination address and a single metric such as hop-count or delay. This approach tends to cause message traffic to converge onto the same link, which significantly increases congestion and leads to unbalanced network resource utilization. One solution to this problem is provided by Traffic Engineering (TE), which uses, bandwidth guaranteed, Explicitly Routed Label Switched Paths (ER-LSPs). Due to the dramatic increase in the backbone speeds, current research focuses more on traffic engineering with LSPs for clear control over the traffic distribution in the network. However, the growing popularity of the Internet is driving the Internet Service Providers to adapt new technologies in order to support multiple classes of applications with different characteristics and performance requirements. Multi-Protocol Label Switching (MPLS), which was proposed by the IETF provides essential facilities for traffic engineering and reliable QoS services for the Internet. MPLS networks provide the required flexibility for operators to manage their traffic with ER-LSPs. Even though conventional routing algorithms support the ER-LSP setup in MPLS networks, they are not efficient in link residual capacity information updates and limit resource utilization, which eventually leads to LSP failures and unbalanced network resource utilization. This thesis proposes a new architecture with a cluster based distributed routing algorithm to setup bandwidth guaranteed ER-LSPs in MPLS backbone networks. The proposed routing algorithm confines the route discovery region in order to reduce the routing overhead and computes all possible routes from ingress node to egress node. Based on LSP requirements and network load conditions, the egress node selects the most suitable path from the available paths in order to setup the LSP. This routing scheme optimizes network resource utilization by evenly distributing traffic throughout the network. The Resource Reservation Protocol (RSVP) works in conjunction with the routing protocol for resource reservation and label distribution along the LSP.
Adviser: Moreno, Wilfrido A.
Packet switching (Data transmission).
Routers (Computer networks)
x Electrical Engineering
t USF Electronic Theses and Dissertations.