Multi-Protocol Label Switching

Transcription

1 Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik IV Prof. Dr. rer. nat. Otto Spaniol Multi-Protocol Label Switching Seminar: Datenkommunikation und Verteilte Systeme SS 2003 Dirk Sabath Matrikelnummer: Betreuung: Rajendra Persaud Lehrstuhl für Informatik IV, RWTH Aachen

2 Contents 1 Introduction 3 2 Overview Internet Protocol Integrated Services Differentiated Services Multi-Protocol Label Switching Motivation Forwarding Equivalence Class Label Switched Path Label Edge Router Label Switching Router Forwarding packets at the Ingress LER Forwarding packets at the Egress LER Label Distribution Hierarchical Label Switched Paths Label Stack Processing the TTL Remote Label Distribution Resource ReSerVation Protocol Establishing a LSP with RSVP-TE Creating a PATH-Message Forwarding a PATH-Message Creating a RESV-Message Forwarding a RESV-Message Summary 24 2

3 A Flowcharts for RSVP-TE 26 A.1 Flowchart: RSVP-TE A.2 Flowchart: Create PATH message A.3 Flowchart: Forward PATH message A.4 Flowchart: Create RESV message A.5 Flowchart: Forward RESV message

4 1 Introduction The increasing demand and growth of the Internet require a more effective handling of ressources. Thus, Quality of Service (QoS) and Traffic Engineering (TE) become more important. In order to provide QoS in a domain it is possible to use existing QoS architectures like Integrated Services (IntServ) or Differentiated Services (DiffServ). The Integrated Services QoS architecture provides microflow based QoS. The Differentiated Services QoS architecture provides aggregate based QoS. Both architectures have in common that they do not affect routing decisions. Routing decisions are based on conventional IP routing which is typically based on the destination IP address of a packet. So it is not possible to avoid over-utilized links in a network. For this reason Traffic Engineering is needed. Multi Protocol Label Switching (MPLS) is a solution to Traffic Engineering. MPLS is a path based architecture. It uses a certain signaling protocol to set up paths. These paths can be established independently from conventional IP routing since the forwarding decision for a packet at a router of a path is based on a label which is added to the packet. A further advantage of MPLS is that it provides faster forwarding. An IP router makes a forwarding decision by looking for a longest prefix match on the destination IP in the routing table. With MPLS, a router gets all the information needed to forward a packet by a simple table lookup for the label in a packet. This lookup can be performed in constant time. MPLS uses a signaling protocol to set up paths and to distribute label bindings between routers. The Label Distribution Protocol (LDP) or the Resource ReSerVation Protocol for Traffic Engineering (RSVP-TE) cope with this task. This document describes the Resource ReSerVation Protocol for Traffic Engineering (RSVP-TE). In order to provide QoS it is either possible to use RSVP-TE and to reserve resources along a path or to use MPLS together with DiffServ. 2 Overview 2.1 Internet Protocol The Internet Protocol (IP) [1] is the most common network layer protocol. It uses 32-bit addresses divided into four octets to identify nodes in a network. Every router keeps a routing table, which contains all the information needed to forward IP packets. The routing table is usually calculated by a routing algorithm such as Open Shortest Path First (OSPF) [2]. On the basis of the routing table, a router decides locally and independently where to forward a packet. When an IP packet arrives at a router, the router searches the routing table for the longest prefix match 1 for the destination IP address. The packet is forwarded to the next hop identified by the corresponding routing table entry. 1 If there is more than one match, only one match is chosen. 4

5 Consequently, packets to the same destination cannot be distinguished. So they will always follow the same path through the network. Thus, performing Traffic Engineering (TE) with IP is not possible. IP provides a Type of Service (ToS) field which could be used for Quality of Service (QoS). However, this field has never been really implemented so that IP alone cannot be used for providing Quality of Service. 2.2 Integrated Services The Integrated Services (IntServ) QoS architecture [3] is an extension to IP. The idea of IntServ is to classify packets into microflows. The classification is done by the source address, the source port, the destination address, the destination port and the protocol ID. For the microflows Quality of Service is provided by setting up paths which guarantee requested resources. Setting up a path can be done with the Resource Reservation Protocol (RSVP) [4][5]. Since a path is set up for each microflow, this results in a bad scalability. The IntServ architecture contains the following four components: Reservation Setup Protocol This is usually RSVP. RSVP sets up a path for a microflow in two steps: 1. The path setup starts with creating a path message. This path message is forwarded to the egress router of the path. 2. The egress router of the path creates a reservation message which specifies the Quality of Service the egress router can provide after it has received the path message. The reservation message is forwarded back to the ingress router of the path. Admission Control algorithm The Admission Control algorithm decides if a reservation can be accepted. It also initiates a reservation when needed. Packet classifier The packet classifier maps an incoming packet to a microflow so that the packet will be placed into the correct transmit queue. Since this mapping is performed at every router, the classification expenses are very high. Packet scheduler The packet scheduler handles a separate queue for the packets of each microflow. IntServ offers end-to-end Quality of Service, but setting up a single path for each microflow results in a bad scalability. Also, the classification expenses are very high because the classification of packets is performed at every router in a path. 5

6 2.3 Differentiated Services The Differentiated Services (DiffServ) QoS architecture [6] tries to eliminate the bad scalability of IntServ by partitioning packets into traffic classes. The assignment of packets to traffic classes is done at the ingress nodes of a network. Each traffic class is mapped to a certain Codepoint. A Codepoint is encoded by 6 bits in the DS field, which replaces the ToS field of the IP header [7]. For each Codepoint a certain Per-Hop Behavior (PHB) is defined. There are three standardized PHBs: Expedited Forwarding (EF) The Expedited Forwarding PHB tries to offer low delay, low jitter and a low loss ratio for the packets of the associated traffic class. Assured Forwarding (AF) The Assured Forwarding PHB offers assured but not guaranteed bandwidth and delay bounds. The AF PHB is divided into four AF classes which differ from one another in the level of delay that the packets experience. Each of these classes is further subdivided by different drop precedences. Packets with a higher drop precedence will be discarded more probably in case of congestion. Default The Default PHB does not give any guarantees for bandwidth or delay. This behavior equals the Best Effort service commonly applied in the internet. DiffServ uses several queues for the PHBs. The scheduler handles these queues in such a way that it can meet the guarantees of the PHBs. DiffServ does not offer end-to-end QoS guarantees because it provides QoS for aggregates and not for single microflows. Since routing decisions are not made by DiffServ, it is not possible to perform traffic engineering. 3 Multi-Protocol Label Switching 3.1 Motivation Neither with IntServ nor with DiffServ Traffic Engineering is possible. However, networks do not have infinite bandwidth so that Traffic Engineering is desirable. Especially for providing Quality of Service Traffic Engineering can be very helpful. Thus, MPLS should offer: Quality of Service Traffic Engineering 6

7 Low complexity for packet classification and forwarding The idea of the Multi-Protocol Label Switching (MPLS) architecture is to separate classification of packets and forwarding decisions. To do so, packets are classified only at the ingress nodes of an MPLS domain. The inner nodes forward packets by switching labels. The labels are carried in a new header. So inner nodes just have to take this label, exchange it with another, and then forward the packet. We will contemplate this in detail in the next sections. MPLS itself does not introduce new QoS mechanisms, but it can be used in combination with existing architectures (e.g. DiffServ) to provide QoS. Traffic Engineering can be realized by setting up explicit paths with the Resource ReSerVation Protocol for Traffic Engineering (RSVP-TE). RSVP-TE is also capable of providing QoS. RSVP-TE is described in detail in section Forwarding Equivalence Class The classification of packets takes place at the ingress router of an MPLS domain. The ingress router maps packets to Forwarding Equivalence Classes (FECs) [8]. If packets are mapped to the same FEC, these packets cannot be distinguished after they have been labeled and consequently they will follow the same path to the egress node. Thus, a particular path in the MPLS domain can be identified with a particular FEC. Classification can be done by various parameters, e.g destination address, destination port, source address, source port, etc. Host A traffic classified to FEC 1 R2 Host C Host B R1 traffic classified to FEC 2 R3 Host D Figure 3.1: Mapping by destination and source address In figure 3.1 the mapping is based on destination and source address. Thus, packets from Host A and Host B can be distinguished and will perhaps follow different paths. If the mapping in this figure was only based on the destination address, packets from Host A and Host B to the same destination Host would be classified to the same FEC. 3.3 Label Switched Path In an MPLS domain paths are set up on which the packets will be forwarded. Such a path is called Label Switched Path (LSP). A LSP is a sequence of routers. is called the LSP 7

8 ingress and the LSP egress. The inner routers are MPLS capable routers which receive labeled packets. Forwarding decisions at the inner routers are only based on this label carried in the packets by a simple table lookup using the incoming label as an index. In a LSP, labeled packets are forwarded from to for. In this case, is called upstream LSR and analogously is called downstream LSR. Thus, a LSP is unidirectional. For the reverse direction as it is always needed by TCP, another path must be set up. Host A R1 (Ingress) R2 R4 R5 (Egress) Host B R3 Figure 3.2: Label Switched Path Host C In Figure 3.2 builds a LSP, where is the LSP ingress and is the egress router. Packets arrive unlabeled at. adds a particular label belonging to the corresponding FEC to the packets destined for Host B. When these packets arrive at, this router removes the label and forwards the packet Label Edge Router The Label Edge Routers (LERs) are the end points of an MPLS domain. They handle the traffic when it enters or leaves the MPLS domain. A Label Edge Router can also act as a Label Switching Router (LSR) as described in the next section. In Figure 3.2 and are Label Edge Routers, but in the LSP acts as a LSR for that path. LERs must be distinguished between ingress and egress routers. The ingress router is responsible for mapping packets to a FEC. The ingress LER keeps an Next Hop Label Forwarding Entry (NHLFE) for each FEC. When a path is not set up for a particular FEC, the NHLFE should indicate that, i.e. by setting the NHLFE to zero. If a path is set up for a FEC, the NHLFE contains the outgoing label for a packet, a stack operation which describes the handling of the label in the packet and the next hop address. The following table shows the fields of an NHLFE at the ingress LER and egress LER: Ingress LER Egress LER Label Outgoing label for the packet Explicit null label Stack operation Push label Pop label Next hop address Address of next hop in the path The pair of FEC and corresponding NHLFE is hold in the FEC-to-NHLFE map (FTN). If a LER 8

9 classifies a packet to a FEC, the LER does a lookup in the FTN for the corresponding NHLFE. If the path for the FEC is not set up yet, the LER has to setup the path first. Otherwise it adds the label from the NHLFE to the packet and forwards the packet to the next hop in the path. In order to label a packet, the ingress creates a shim header which contains the following four fields: Label The label is encoded in 20 bits. The LER gets the label from the NHLFE which was attached to the packet s FEC. Experimental bits The experimental bits can be used for example to encode DiffServ codepoints when using DiffServ combined with MPLS. Stack bit The Stack bit indicates that this label is the last label in the packet. This bit is useful for hierarchical LSPs, so it becomes important in section 3.4. Time-To-Live (TTL) The TTL in the header of an IP packet is left untouched along the path. Thus, the TTL of the IP header is copied into the TTL field of the shim header Label Exp S TTL Figure 3.3 MPLS shim header The egress LER can act in two ways. The simple way is that it receives labelled packets. It keeps an Incoming Label Map (ILM) which contains NHLFEs. When a packet arrives for which the router is the egress LER, the router looks up the ILM by using the label carried by the packet as an index to the ILM. The NHLFE contains a special label, the EXPLICIT NULL label and the Stack operation [pop label]. So the NHLFE indicates that the LER has to copy the TTL back in the IP header, to remove the shim header and to make a forwarding decision based on the remaining packet, e.g. it does a lookup in the routing table. This results in two lookups: first, a lookup of the ILM to discover that this router is the LSP egress, second a lookup of the routing table to make a forwarding decision. The lookup of the ILM can be avoided if the penultimate router on the path already removes the label. This method is called Penultimate Hop Popping. If Penultimate Hop Popping was used in Figure 3.2, would copy the TTL to the IP header, remove the shim header from the packet and forward it to. The packet will arrive at as a plain IP packet, so only has to do a lookup in the routing table. 9

10 3.3.2 Label Switching Router The core routers between the LSP ingress and the LSP egress are Label Switching Routers (LSR). In order to achieve separation of classification and packet forwarding, the LSR does not classify packets, its forwarding decisions are only based on the incoming label of a packet. The LSR receives labelled packets from the upstream node of the path. The LSR does not classify a packet to a FEC, it just looks up the Incoming Label Map for a corresponding Next Hop Label Forwarding Entry for that label. By using the incoming label as an index to the ILM, this lookup is performed in constant time. The NHLFE from the ILM contains the new label called outgoing label, an operation for the label which is [swap label] in this case and the next hop address. After the ILM lookup, the LSR replaces the label with the outgoing label, decrements the TTL from the shim header and forwards the packet to the next hop specified by the next hop address in the NHLFE. FTN at R1 FEC FEC 1 Out Label 23 NHLFE Op. push Next Hop R2 ILM at R2 In Label Out Label NHLFE Op swap R4 R2 NextHop ILM at R5 NHLFE In Out Label Label Op. NextHop 42 Expl. pop N/A NULL Host A FEC 1 R1 (Ingress) R5 (Egress) Host B R3 ILM at R4 In Label Out Label R4 NHLFE Op. NextHop Host C When Penultimate Hop Popping is used swap R5 66 Impl. pop R5 NULL Figure 3.4 FEC-to-NHFLE map and Incoming Label map at routers along the path Figure 3.4 shows the LSP from Figure 3.2 with FTN and ILM maps at the routers of the LSP. When Penultimate Hop Popping is used, the router receives packets unlabeled from R4. As has figured out with its ILM, it removes the label from the packets and forwards them. When Penultimate Hop Popping is not used, receives packets labeled with 42, so removes the shim header from these packets. In both cases the router searches the routing table for a longest prefix match of the destination IP address of the packets. 10

11 3.3.3 Forwarding packets at the Ingress LER If a packet arrives at the ingress LER, it passes through the following four steps: Classify the packet to its FEC A packet is classified to a FEC if the packet matches a particular set of rules, which are associated with the FEC, e.g. the packets destination IP address matches a particular prefix, Lookup of the NHLFE in the FTN When the matching FEC is found, the ingress router does a lookup in the FEC-to-NHLFE map. If the corresponding NHLFE indicates that a path is set up for the FEC, the operation given in the NHLFE is [push label]. If the path for the FEC does not exist yet, the ingress router must initiate a path setup. This assumes the use of Downstream-on-Demand label distribution as described in section Add the MPLS shim header to the packet The label in the MPLS shim header is taken from the NHLFE of the FEC which the packet belongs to. The TTL field is filled with the TTL from the received IP packet. The shim header is inserted between the link layer header and the IP header. Forward the packet The packet is forwarded to the router which is specified by the next hop address in the NHLFE for the FEC Forwarding packets at the Egress LER If Penultimate Hop Popping is not used, the egress LER receives labeled packets from its upstream LSR. The LER only looks at the shim header which does not hold information about the LSP end points. The router does a lookup in the ILM to find the corresponding NHLFE for the incoming label of the packet. The NHLFE contains a special label, the EXPLICIT NULL label. A router realizes with the EXPLICIT NULL label that it is the egress LER. The operation given by the NHLFE is [pop label], so the router removes the label from the packet. In an NHLFE which contains an EXPLICIT NULL label, there is no specified next hop. If Penultimate Hop Popping is used, the label of a packet is removed by the penultimate hop. In the same manner as above, the penultimate hop has to figure out that it is responsible for removing the label. Thus, the penultimate hop does the lookup in the ILM for the incoming label. If it is the penultimate hop for the path which the packet belongs to then the NHLFE contains an IMPLICIT NULL label. This label indicates that the label must be removed. In opposition to an NHLFE with an EXPLICIT NULL label, this NHLFE contains the egress LER as the next hop. After the label has been removed, either at the penultimate hop or at the LER, the LER forwards the unlabeled packet. For this reason, the LER has to make a forwarding decision based on the remaining packet. 11

12 3.3.5 Label Distribution In order to forward labeled packets only by switching labels, a LSR has to know which labels to use as outgoing labels. So labels must be distributed between routers. Labels are distributed at path setup. Two routers which distribute labels to each other are called label distribution peers. In general, the downstream peer binds a label to a particular FEC and distributes this label binding to its upstream peer. The upstream peer uses the label from that label binding as the outgoing label for packets of the FEC. The advantage of distributing label bindings from downstream to upstream routers is that the downstream router controls the binding of incoming labels so that it can avoid ambiguities between incoming labels. When a router receives a label binding for a particular FEC from a downstream node and the router is not the ingress LER for that FEC, it creates an NHLFE which contains the provided label as the outgoing label, the stack operation [swap label] and the downstream router as the next hop. The router binds a free label to the NHLFE and stores the NHLFE in the ILM by using the new label as an index to the ILM. The router distributes the label binding to its upstream label distribution peer on the path. When the ingress LER for a particular FEC receives a label binding for this FEC, it creates an NHLFE which includes the provided label as the outgoing label, the stack operation [push label] and the downstream router as the next hop. The ingress LER assigns the NHLFE to the FEC and stores it in the FTN map. In an MPLS domain, there are two Label Distribution Control Modes: Ordered Control With Ordered Control, only the egress router of a LSP is allowed to start binding a label to a FEC. It distributes the label binding to its upstream label distribution peer on the path. One after another binds a new label for the FEC after it has received a label binding for the FEC from the downstream router and distributes the label binding to the upstream router until the ingress router receives the label binding. The ingress router binds the label to the corresponding FEC in its FTN. Independent Control With Independent Control, every router in the MPLS domain is allowed to start binding a label to a FEC. Thus, a LSR which binds an incoming label to a particular FEC and distributes it to its label distribution peers creates an NHLFE with the EXPLICIT NULL label as the outgoing label and the stack operation [pop label]. This is needed since a LSR must be able to forward labeled packets of that FEC for which it has distributed a label binding. When the LSR has received the corresponding label binding for the FEC from the downstream label distribution peer, the LSR replaces the NHLFE with the EXPLICIT NULL by an NHLFE which contains the provided label as the outgoing label, the stack operation [swap label] and the downstream peer as the next hop. 12

13 a) Ordered Control request 1. for label 2. request for label R1 R2 R3 bind e.g. bind e.g. 4. label label 40 b) Independent Control request for label request for label R1 R2 R3 bind e.g. bind e.g. 2. label label 40 Figure 3.5 Label Distribution Control modes: a) Independent; b) Ordered The MPLS architecture supports two Label Distribution Advertisement Modes. With the Downstreamon-Demand label distribution, the ingress router of a LSP explicitly requests a label binding. When Downstream-on-Demand label distribution is used together with Ordered Control, the ingress router will generate a label request for a FEC. The request will be forwarded downstream until the egress router of the LSP receives the request. The egress router binds a label and distributes it upstream. Every router in the path binds a label and distributes it upstream after it has received a label binding from the downstream router. When the ingress router receives the label binding, it uses the provided label as the outgoing label for the FEC for which the path is set up. When Independent Control is used with Downstream-on-Demand, an inner router of the path could bind a label and distribute it to the upstream router first and then request a label from the downstream router. Unsolicited Downstream label distribution means that the routers of an MPLS domain can independently decide to bind labels and distribute them to their upstream routers without that the upstream routers have explicitly requested a label binding. When the ingress router of a path receives a label binding from the downstream router for that path, it binds the provided label to the FEC. The Label Retention Mode determines the handling of label bindings if a link or a router fails. With the Liberal Label Retention Mode, a router decides to hold a label binding although the downstream router is not reachable. When the downstream router for that label binding becomes available again, the label binding can be reused immediately. With the Conservative Label Retention Mode a router discards a label binding if the downstream router for that binding becomes unavailable. Thus, if the downstream router becomes available again and should be used for a path, the upstream router has to request a new label binding. The Liberal Label Retention Mode uses more label space. If a router has enough space for an entire 13

14 ILM with at least NHLFEs 2, there should be enough space to hold the label bindings. If a router has not enough space to support all incoming labels the conservative label retention mode could be reasonable. The conservative label retention mode will cause more label distribution traffic because of the re-binding of labels. 3.4 Hierarchical Label Switched Paths In almost the same manner as IP packets are tunneled over a LSP, it is also possible to tunnel labeled packets over a LSP. That is, a LSP which is established between a LER of a particular MPLS domain and a LER of another MPLS domain is routed through a further MPLS domain. The packets of this LSP are tunneled over a LSP in the middle MPLS domain which the original LSP is routed through. When a packet which traverses the LSP between the ingress LER of the first domain and the egress LER of the last domain arrives at the ingress LER of the middle domain, it will be tunneled over the LSP in the middle domain. The ingress LER of the middle domain adds a further label to the packet. When the packet leaves the middle domain, the egress LER of the middle domain removes the second label, and forwards the packet to the ingress LER of the third domain. The egress LER of the last domain removes the last label and forwards the packet towards the destination host. The path from the ingress LER of the first domain to the LER of the third domain is a hierarchical label switched path. The labeled packets from the ingress LER to the egress LER of the third domain are tunneled over a LSP in the second MPLS domain. 2 For each incoming label the ILM includes at least one NHLFE. 14

15 Domain C Domain A C 1 IP Host A A 2 A 1 72 A 3 IP C 2 C 4 C 3 IP Host B A 4 32 IP C 5 54 IP ILM at C 5 In Out Op Next Hop swap C 4 ILM at A 4 In Out Op Next Hop 67 IP 61 IP swap B 1 B 1 Domain B B 3 ILM at B 1 In Out Op Next Hop swap B push B IP B IP ILM at B 3 In Out Op Next Hop 27 expl. NULL pop swap C 5 Figure 3.6: A hierarchical path There are two LSPs in Figure 3.6. One LSP is between the ingress LER (B 1) and the egress LER (B 3) of the second MPLS domain (domain B), this LSP is referred to as an LSP tunnel. Another LSP, the hierarchical LSP, is between the ingress LER (A 1) of the MPLS domain A and the egress LER (C 4) of the MPLS domain C. The ingress LER B 1 of domain B receives a packet labeled with 67. B 1 swaps the label 67 with 69 and forwards the packet to itself. Then it does a lookup in the ILM for the label 69 which returns a NHLFE which contains the outgoing label 18, the stack operation [push label] and B 2 as the next hop. Thus, B 1 adds the outgoing label 18 in front of existing labels in the packet. When the packet leaves domain B at the egress LER B 3, te router B 3 removes the foremost label of the packet. It does a lookup in the ILM for the next label on the packet which is 69. B 3 swaps the label 69 with the outgoing label 61 and forwards it to C Label Stack A packet contains more than one label if it is forwarded through an LSP tunnel. If a packet enters a LSP a new label is added in front of existing labels, and when the packet leaves the LSP the foremost 15

16 label will be removed. The packet includes the Label Stack [9] which is organized in First In First Out order. Thus, the foremost label in a packet is the top of the label stack, the last label is the bottom of the label stack. The labels are encoded in MPLS shim headers as described in section 3.2 (Figure 3.3), so a label on the label stack can be associated with the corresponding shim header in the packet. The stack bit of the shim header indicates the bottom of the label stack. It is set if the shim header is the last shim header in the packet, otherwise it is not set. The depth of the label stack can be associated with the depth of the hierarchy of a LSP. The LSP using the label at the stack depth of is referred to as a LSP at level of the hierarchy. The LSP which uses the labels at the bottom of the stack is referred as the LSP at level one. In Figure 3.6, the LSP between B 1 and B 3 is an LSP tunnel at level 2. The LSP between A 1 and C 4 is a LSP at level 1. ILM NHLFE In Out Op Next hop push BR 2 lookup Label = 18 Operation = push label Next hop = BR 2 BR 1 Label = 18 Exp S=0 TTL Label = 15 Exp S=1 TTL Label = 15 Exp S=1 TTL Figure 3.7: LSP tunnel ingress router When a packet with a label stack of depth m arrives at LER A 4 of domain A, A 4 swaps the label at the top of the stack and forwards it to the ingress LER B 1 of domain B. The router B 1 swaps the label which A 4 has put on the packet. Then it does a lookup in its ILM for the new label. The corresponding NHLFE contains the outgoing label 18 and the next hop which is B 2, but the stack operation is [push label]. Thus, B 1 creates an additional shim header with the outgoing label. The stack bit is set to zero and the TTL is copied from the shim header at the top of the stack of the incoming packet. The shim header is inserted in front of the existing shim headers, so it becomes the new top of the label stack. The stack has now the depth. After adding the new shim header the packet is forwarded to the next hop B 2. 16

17 ILM In 27 Out Impl. NULL NHLFE Op pop Next hop lookup Operation = pop label BR 3 Label = 27 Exp S=0 TTL Label = 15 Exp S=1 TTL Label = 15 Exp S= Figure 3.8: LSP tunnel egress router TTL When the packet with the label stack of depth arrives at the egress LER B 3 of domain B, B 3 does a lookup in its ILM with the incoming label of the packet. The corresponding NHLFE contains the operation [pop label], so B 3 removes the shim header at the top of the label stack. The label stack depth decreases to. B 3 does a further lookup in its ILM for the label at stack level. The label stack can grow to any depth, but the size of a packet increases linearly with the label stack depth, so it can reach the size of the path MTU. When a packet with the size of the path MTU arrives at a LSP ingress router, the ingress router has to fragment the packet if this is permitted by the network layer protocol. The router splits the packet without the MPLS shim headers into fragments which have at most the size of the path MTU minus the size of the shim headers which encode the label stack. Thus, each fragment has enough space for the label stack, which will be added to each fragment Processing the TTL Every router in an MPLS domain checks the TTL of the shim header at the top of the label stack whether it becomes less than zero. In that case, the router discards the packet and sends an ICMP message towards the sender. The processing of the TTL in a LSP is specified in two models [10]: 17

18 a) Uniform model Label Stack level m level m 1 TTL = n TTL = n 2 TTL = n 3 R 2 R 3 R 4 TTL = n 1 TTL = n 4 (TTL = n 1) R 1 R 5 push label pop label TTL = n 5 b) Pipe model without Penultimate Hop Popping Label Stack level m level m 1 TTL = N 1 R 2 R 3 TTL = N TTL = N 2 R 4 TTL = N 3 TTL = n R 1 (TTL = n 1) R 5 TTL = n 2 push label Figure 3.9: TTL processing models pop label Uniform model With the uniform TTL processing model, a LSP at level of the hierarchy gets informed about how many hops are traversed in a LSP at level of the hierarchy. The processing of the TTL does not depend on whether Penultimate Hop Popping is used or not. When a packet arrives at the ingress router of an LSP tunnel, a new shim header is added to the packet. The additional shim header contains the TTL from the packet. The ingress router decrements this TTL by one and forwards the packet to the next hop in the LSP tunnel. Every router in the LSP tunnel which receives the packet decrements the TTL of the shim header at the top of the label stack by one. The TTLs of the shim headers at lower levels in the label stack are left untouched. The egress router or the penultimate hop of the LSP tunnel removes the foremost shim header and copies the TTL of the removed shim header to the underlying shim header, which has become the top of the label stack. Thus, the TTL of the packet always contains the information about how many hops the packet has traversed. Pipe model With the pipe model, a LSP at level of the hierarchy appears as two hops for a LSP at level. The processing of the TTL depends on whether Penultimate Hop Popping is used or not. When a packet enters an LSP Tunnel, the ingress LER of the LSP tunnel decrements the TTL in the shim header of the top of the label stack. After that it creates a new TTL for the additional shim header which becomes the new top of the label stack. The LSRs of the LSP tunnel decrement the new TTL in the shim header at the top of the label stack. When Penultimate Hop Popping is not used, the egress LER of the LSP tunnel removes the shim header at the top of the label stack. It does not care for the TTL of the removed shim header, but decrements the TTL in the foremost shim header in the packet at the new top of the label stack. Thus, the TTL of the shim header at the top of the label stack has been decremented by two when the packet leaves the LSP tunnel. 18

19 If Penultimate Hop Popping is used, the penultimate hop will remove the shim header at the top of the label stack, but does not decrement the TTL of any shim header in the label stack. The egress LER just decrements the TTL in the shim header at the top of the label stack. Thus, regardless of using Penultimate Hop Popping or not, with the pipe model the TTL of the shim header at the top of the label stack is decremented by two when it leaves the LSP tunnel Remote Label Distribution LSRs which exchange label bindings are label distribution peers. If they are directly connected, they are called local label distribution peers. Label distribution peers which are not directly connected are called remote label distribution peers. There are two ways for remote label distribution peers to exchange label bindings: Explicit Peering With Explicit Peering, a remote downstream label distribution peer provides a label binding by addressing the receiver of the particular label distribution protocol message directly. Thus, each router which forwards the label distribution protocol message does not care about the provided binding in the message. For example, the packet which contains the message is tunneled through an existing LSP tunnel between the remote label distribution peers. Implicit Peering With Implicit Peering, a remote downstream label distribution peer would bind labels for its local and remote distribution peers. Then it creates a label distribution protocol message for its local distribution peers and adds label bindings for its remote label distribution peers as an attribute to the message. When a local distribution peer receives that message, it accepts the local label binding. It adds the remote label binding information to a label distribution protocol message for a local label binding and forwards this message to its local distribution peers. This process repeats until the destination of the remote label binding is reached. Thus, each router which receives a label distribution protocol message with a remote label binding piggybacked on it has to check if it is the remote label distribution peer for that remote label binding. 4 Resource ReSerVation Protocol The Resource ReSerVation Protocol (RSVP) [4] is a protocol for setting up paths between routers. The path setup is initiated by the ingress router of a path. The ingress router sends a request for a path setup in terms of a PATH message towards the egress router. Every RSVP capable router which processes and forwards this path message will belong to the path. The egress router which is included as destination in the PATH message replies to it by sending a RESV message towards the ingress node. The egress router can specify QoS for a path in the RESV message, but this is out of the scope of this 19

20 document. This document describes the null service [11], which is used when resources should not be reserved at path setup. For example, if MPLS is used in combination with DiffServ, QoS is provided by the mechanisms of DiffServ as described in section 1.3 and so RSVP uses the null service. RSVP is not a routing protocol, that is RSVP has no control about which routers belong to a path 3 because forwarding decisions are made by a routing protocol and RSVP capable routers belong to a path if they have processed and forwarded the PATH message. RSVP is a soft state protocol. So a path setup must be refreshed within a certain time. The paths are unidirectional. In order to use RSVP as a label distribution protocol for MPLS, RSVP-TE [12] specifies extensions to RSVP. With these extensions, RSVP is able to provide label distribution for MPLS by distributing label bindings between label distribution peers at path setup. Another extension is that the ingress router of a path is able to use an predetermined route for a path. Thus, traffic engineering becomes possible with RSVP-TE. 4.1 Establishing a LSP with RSVP-TE In order to establish a LSP with RSVP-TE, the ingress router creates a path message and forwards it towards the egress router for that LSP. The egress router binds a label, creates a RESV message which contains the label binding and forwards it towards the ingress router. A router which receives the RESV message takes the label from the RESV message and uses it as the outgoing label for the LSP. Then it binds a new label for the LSP and adds it to the RESV message. After the ingress has received the RESV message, it stores the label as the outgoing label in the NHLFE which is assigned to the LSP s FEC. The following sections explain this in detail. RSVP-TE uses Downstream-on-Demand label distribution because the PATH message contains a request for a label binding. Also RSVP uses Ordered Control mode since the egress router starts with label binding when sending a RESV message. The PATH and RESV messages are encapsulated in IP packets. They consist of a common RSVP header and several objects, which are introduced in the next sections. The RSVP header essentially contains the following fields: Message Type This field is needed to distinguish between a PATH and a RESV message Checksum The 16-bit checksum is computed by taking the one s complement of the sum of the one s complement of 16-bit parts of the message. Send TTL The Send TTL is needed to detect if there is a non-rsvp router which has forwarded the RSVP 3 except ingress and egress routers 20

21 message. The Send TTL is copied from the IP header. If the Send TTL of an incoming RSVP message differs from the TTL of the IP header, then a non-rsvp router has forwarded the message. Length The Length of the complete message, that is, RSVP header and the objects in the message RSVP identifies a LSP by the SESSION object and the SENDER TEMPLATE object. The SESSION object contains the tunnel end point address which is the IP address of the egress LER of the LSP, and a Tunnel ID. The SENDER TEMPLATE object contains the tunnel sender address which is the IP address of the ingress LER of the LSP, and a LSP ID. However, in RESV messages the SENDER TEMPLATE object is included as a FILTER SPEC object. These objects are present in PATH and RESV messages. They are used to assign a RESV message to a prior PATH message Creating a PATH-Message When an ingress router starts to setup a LSP, it first creates a PATH message. The PATH message consists of a RSVP header and at least the following objects: SESSION object The SESSION object contains the IP address of the egress router of the LSP, which will create the RESV message when it receives the PATH message, and the Tunnel ID. The Tunnel ID is generated by the ingress of the LSP. RSVP HOP object The ingress router stores its own IP address in the RSVP HOP object. The RSVP HOP object is needed to route RESV message on the same path as the PATH message. TIME VALUES object This object contains the refresh period. Since RSVP is a soft state protocol the path setup has to be refreshed within this period. LABEL REQUEST object The LABEL REQUEST object indicates that labels have to be bound and distributed for the LSP in the RESV message. SENDER TEMPLATE object The SENDER TEMPLATE contains the IP address of the ingress router and a LSP ID. The LSP ID is generated by the ingress router. SENDER TSPEC object The SENDER TSPEC object describes the characteristics of the traffic which will be sent over the path. If the null service is used, the SENDER TSPEC only includes the maximum packet size for a packet. 21

22 The ingress router stores the SESSION, SENDER TEMPLATE, SENDER TSPEC and LABEL RE- QUEST objects in the Path State Block. The SESSION and SENDER TEMPLATE objects are needed to assign an incoming RESV message to a previously sent PATH message. The Path State Block is hold for the path refresh. It is possible to add an EXPLICIT ROUTE object (ERO) to the path message. The ERO describes a predetermined route for the LSP. The ERO contains a list of subobjects. A subobject consists of an abstract node and a loose flag. An abstract node is referred to as a group of routers. The PATH message has to be routed according to the list of subobjects in the ERO. If the loose flag is set in a subobject, a router in the abstract node of this subobject should belong to the path but it is not required. The abstract node of a subobject with the loose flag set is referred to as a loose node. Otherwise if the loose flag is not set in a subobject, the abstract node of this subobject must belong to the path. The abstract node of a subobject with the loose flag not set is referred to as a strict node. After the ingress router has created the objects of the PATH message, it creates an RSVP header. The ingress computes the checksum and the length of the PATH message. The Send TTL has to be the same value as the TTL in the IP packet with which the PATH message will be send. At the ingress router, this will be the initial value, e.g. 255, for a TTL. The ingress router encapsulates the PATH message in an IP packet which is destined for the egress router of the LSP Forwarding a PATH-Message When a PATH message arrives at a LSR, the LSR first verifies the checksum and the length of the PATH message. The LSR checks if it is the tunnel end point specified in the SESSION object. If this is true, the router will continue with creating a RESV message. If the LSR is not the tunnel end point, it continues processing the PATH message as follows: Create Path State Block to store the SESSION, SENDER TEMPLATE, LABEL REQUEST, SENDER TSPEC and the RSVP HOP object. The SESSION object and SENDER TEMPLATE object identify the LSP which will be established. With this information, the RESV message which arrives later can be assigned to the LSP. Since the RESV message must be routed on the same path as the PATH message, the RSVP HOP object, which contains the address of the previous hop of the PATH message, must be stored in the Path State Block. Replace the previous hop address in the RSVP HOP object by the address of the LSR. So the next router which processes the PATH message will know where to forward the corresponding RESV message. Get the next hop for the PATH message: 22

23 ERO is not present The LSR does a lookup in the routing table to determine the next hop for the PATH message. ERO is present The LSR looks at the first subobject. If it is not within the abstract node of the subobject the LSR sends a Bad initial subobject error message towards the ingress router of the LSP. Otherwise it walks through the subobject list and removes the first subobject at every step until the LSR is not in the abstract node of a subobject or the end of the list is reached. If the end of the list is reached, the LSR removes the ERO from the PATH message and does a lookup in the routing table to determine the next hop for the PATH message. If there is a subobject with an abstract node which does not include the LSR, the LSR does a lookup in the routing table if it is directly connected to a router in the abstract node. If this is the case, the router chooses the router of the abstract node which it is directly connected to as the next hop for the PATH message. If the LSR is not directly connected to a router in the abstract node of the subobject the LSR checks if the routing table contains an entry with a next hop in its own abstract node for the abstract node of the subobject. If it does not find a next hop from its own abstract node and the abstract node is a strict node, the LSR sends a Bad strict node error towards the ingress LER and the path setup fails. If the abstract node is a loose subobject, the LSR does a lookup in the routing table in order to get a next hop address. After a next hop is found, the LSR replaces the first subobject with a new subobject. The abstract node of the new subobject includes the next hop, so that the next hop will accept the EXPLICIT ROUTE object. If the PATH message includes an ERO, the PATH message has to be encapsulated in a new IP packet which is destined for the chosen next hop and the Send TTL in the RSVP header is copied from the new IP header. If the LSR removed the ERO the IP packet must be destined for the egress LER specified by the tunnel endpoint address in the SESSION object. Finally the LSR forwards the packet Creating a RESV-Message When the egress router of the LSP receives the PATH message and the PATH message includes a LABEL REQUEST object it assigns a free label or if Penultimate Hop Popping is used it binds the IMPLICIT NULL label for the LSP. If Penultimate Hop Popping is not used, it creates an NHLFE with the EXPLICIT NULL label as the outgoing label and the stack operation [pop label]. Then it creates a RESV message. The RESV message consists of a RSVP header and at least the following objects: SESSION object The SESSION object must be the same as in the PATH message, so that the routers which forward the RESV message can assign the RESV message to the LSP. 23

24 RSVP HOP object The RSVP HOP object includes the IP address of the egress router. TIME VALUES object The TIME VALUES object includes the same refresh period as in the PATH message. STYLE object The STYLE object includes a filter style. The filter style defines how the reservation in the FLOWSPEC is shared between the senders of a session. There are three filter styles: Fixed Filter Style: With the Fixed Filter Style, the receiver creates a reservation for each sender of a session. Shared Explicit Style: With the Shared Explicit Style, the receiver can specify the senders of a session which share a reservation. Wildcard Filter Style: With the Wildcard Filter Style, all senders of a session share the reservation. Note that these filter styles only apply to the senders of a session, that is, the reservations can be shared between senders of multipoint-to-point paths or the sender in a point-to-point path can share reservation with itself. The latter case is used to reroute a path or to change the reservation for a path. For that reason, the sender creates a new path using the shared explicit filter style so that the new reservation will not be added to the old reservation. After the new path is setup, the old path will be removed. FLOWSPEC object The FLOWSPEC object determines the reservation which the receiver has made for the path. If the null service is used, the FLOWSPEC object only includes the maximum packet size. FILTER SPEC object The FILTER SPEC object must be the same as the SENDER TEMPLATE object in the PATH message, so that the routers which forward the RESV message can assign the RESV message to the LSP. LABEL object The LABEL object includes the assigned label for the LSP. The RSVP header is created in the same manner as the RSVP header in the PATH message. The egress router sends the RESV message encapsulated in an IP packet to the previous hop of the PATH message. Since the RESV message must be forwarded on exactly the same route as the PATH message, the RESV message is not destined for the ingress router of the LSP, which could result in a different route. 24

25 4.1.4 Forwarding a RESV-Message When a RESV message arrives at a LSR, the LSR verifies the checksum and the length of the RESV message. It looks for a Path State Block with the same SESSION and where the SENDER TEM- PLATE object equals the FILTER SPEC object of the RESV message. If the LSR is not the ingress LSR of the LSP, it binds an incoming label for the LSP and creates a NHLFE with the outgoing label from the LABEL object of the RESV message. If the label in the LABEL object is the IMPLICIT NULL label, the NHLFE includes the stack operation [pop label] since this label indicates that the LSR is the penultimate hop for that LSP. If the label is not the IMPLICIT NULL label, the NHLFE includes the stack operation [swap label]. The next hop address is the address of the hop from which the RESV message was received. This address is given by the RSVP HOP object in the RESV message. The LSR stores the NHLFE in the ILM by using the incoming label as an index to the map. After that the LSR creates a new RSVP HOP object with its IP address and a new LABEL object with the incoming label binding. Furthermore, it creates a STYLE and FLOWSPEC object indicating the desired QoS. A new RESV message is created which contains a new RSVP header. The new RSVP HOP object, the new LABEL object, the new STYLE object, the new FLOWSPEC object and the SESSION, TIME VALUES and the FILTER SPEC object from the received RESV message are added to the new RESV message. The LSR encapsulates the RESV message in an IP packet. The IP packet is destined for the router specified in the RSVP HOP object in the Path State Block. This is the router from which the PATH message was previously received. finish path setup: If the ingress LSR receives the RESV message, it creates an NHLFE which includes the label from the LABEL object of the RESV message as the outgoing label, the stack operation [push label] and the address from the RSVP HOP object as the next hop address. The ingress LER assigns the NHLFE to the corresponding FEC for the LSP in the FTN. The path setup has finished. 5 Summary The idea of MPLS is to reduce the expenses of forwarding decisions at a router by adding a label to a packet which carries all the information needed to forward the packet. The ingress router of an MPLS domain classifies a packet into a Forwarding Equivalence Class. A Forwarding Equivalence Class is associated with a Label Switched Path. The Label Switching Routers in a LSP forward a packet by exchanging the label with another and forward it to the next hop in the path. For this reason they do a lookup in the Incoming Label Map with the incoming label. The ILM includes Next Hop Label Forwarding Entries for incoming labels. An NHLFE includes the outgoing label, a stack operation, and the next hop address for a packet. If a LSP spans more than one MPLS domain it can be tunneled over another LSP. Such a LSP is called a hierarchical path. The labels in a packet are organized in the label stack. The label stack is added to a packet before the IP header. A router must inform its upstream router for a LSP about a label binding. MPLS uses a label distribution protocol to distribute label bindings between label distribution peers. RSVP-TE is a label 25