Rheinisch-Westfalische Technische Hochschule AachenLehrstuhl fur Informatik IVProf. Dr. rer. nat. Otto Spaniol

Multi-Protocol Label Switching

Seminar: Datenkommunikation und VerteilteSystemeSS 2003

Dirk SabathMatrikelnummer: 228752

Betreuung: Rajendra PersaudLehrstuhl fur Informatik IV, RWTH Aachen

Contents

1 Introduction 3

2 Overview 3

2.1 Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Integrated Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Differentiated Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Multi-Protocol Label Switching 5

3.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2 Forwarding Equivalence Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.3 Label Switched Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.3.1 Label Edge Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.3.2 Label Switching Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3.3 Forwarding packets at the Ingress LER . . . . . . . . . . . . . . . . . . . . 10

3.3.4 Forwarding packets at the Egress LER . . . . . . . . . . . . . . . . . . . . . 10

3.3.5 Label Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.4 Hierarchical Label Switched Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.4.1 Label Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.4.2 Processing the TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4.3 Remote Label Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Resource ReSerVation Protocol 18

4.1 Establishing a LSP with RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1.1 Creating a PATH-Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1.2 Forwarding a PATH-Message . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.3 Creating a RESV-Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1.4 Forwarding a RESV-Message . . . . . . . . . . . . . . . . . . . . . . . . . 24

5 Summary 24

2

A Flowcharts for RSVP-TE 26

A.1 Flowchart: RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

A.2 Flowchart: Create PATH message . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

A.3 Flowchart: Forward PATH message . . . . . . . . . . . . . . . . . . . . . . . . . . 28

A.4 Flowchart: Create RESV message . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

A.5 Flowchart: Forward RESV message . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3

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 toprovide 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 providesmicroflow 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 arebased 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 isneeded.

Multi Protocol Label Switching (MPLS) is a solution to Traffic Engineering. MPLS is a path basedarchitecture. It uses a certain signaling protocol to set up paths. These paths can be establishedindependently from conventional IP routing since the forwarding decision for a packet at a router ofa 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 forwardingdecision 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 ina 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 forTraffic Engineering (RSVP-TE).

In order to provide QoS it is either possible to use RSVP-TE and to reserve resources along a path orto 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 addressesdivided into four octets to identify nodes in a network. Every router keeps a routing table, whichcontains all the information needed to forward IP packets. The routing table is usually calculated bya 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 arrivesat a router, the router searches the routing table for the longest prefix match1 for the destination IPaddress. The packet is forwarded to the next hop identified by the corresponding routing table entry.

1If there is more than one match, only one match is chosen.

4

Consequently, packets to the same destination cannot be distinguished. So they will always follow thesame 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 ofService.

2.2 Integrated Services

The Integrated Services (IntServ) QoS architecture [3] is an extension to IP. The idea of IntServ is toclassify packets into microflows. The classification is done by the source address, the source port, thedestination address, the destination port and the protocol ID. For the microflows Quality of Serviceis provided by setting up paths which guarantee requested resources. Setting up a path can be donewith the Resource Reservation Protocol (RSVP) [4][5]. Since a path is set up for each microflow, thisresults in a bad scalability.The IntServ architecture contains the following four components:

� Reservation Setup ProtocolThis 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 theegress router of the path.2. The egress router of the path creates a reservation message which specifies the Quality ofService the egress router can provide after it has received the path message. The reservationmessage is forwarded back to the ingress router of the path.

� Admission Control algorithmThe Admission Control algorithm decides if a reservation can be accepted. It also initiates areservation when needed.

� Packet classifierThe packet classifier maps an incoming packet to a microflow so that the packet will be placedinto the correct transmit queue. Since this mapping is performed at every router, the classifica-tion expenses are very high.

� Packet schedulerThe 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 ina bad scalability. Also, the classification expenses are very high because the classification of packetsis performed at every router in a path.

5

2.3 Differentiated Services

The Differentiated Services (DiffServ) QoS architecture [6] tries to eliminate the bad scalability ofIntServ by partitioning packets into traffic classes. The assignment of packets to traffic classes isdone at the ingress nodes of a network. Each traffic class is mapped to a certain Codepoint. ACodepoint is encoded by 6 bits in the DS field, which replaces the ToS field of the IP header [7]. Foreach 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 thepackets 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 ofdelay that the packets experience. Each of these classes is further subdivided by different dropprecedences. Packets with a higher drop precedence will be discarded more probably in case ofcongestion.

� DefaultThe Default PHB does not give any guarantees for bandwidth or delay. This behavior equalsthe 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 itcan meet the guarantees of the PHBs. DiffServ does not offer end-to-end QoS guarantees because itprovides 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 nothave infinite bandwidth so that Traffic Engineering is desirable. Especially for providing Quality ofService Traffic Engineering can be very helpful.Thus, MPLS should offer:

� Quality of Service

� Traffic Engineering

6

� Low complexity for packet classification and forwarding

The idea of the Multi-Protocol Label Switching (MPLS) architecture is to separate classification ofpackets and forwarding decisions. To do so, packets are classified only at the ingress nodes of anMPLS domain. The inner nodes forward packets by switching labels. The labels are carried in anew header. So inner nodes just have to take this label, exchange it with another, and then forwardthe packet. We will contemplate this in detail in the next sections. MPLS itself does not introducenew QoS mechanisms, but it can be used in combination with existing architectures (e.g. DiffServ) toprovide QoS.Traffic Engineering can be realized by setting up explicit paths with the Resource ReSerVation Pro-tocol for Traffic Engineering (RSVP-TE). RSVP-TE is also capable of providing QoS. RSVP-TE isdescribed in detail in section 4.

3.2 Forwarding Equivalence Class

The classification of packets takes place at the ingress router of an MPLS domain. The ingress routermaps 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 followthe same path to the egress node. Thus, a particular path in the MPLS domain can be identified with aparticular FEC. Classification can be done by various parameters, e.g destination address, destinationport, source address, source port, etc.

classified totraffic

FEC 2

FEC 1classified to

traffic

Host A

Host B

Host D

Host C

R3

R2

R1

130.134.14.32

192.168.3.14

137.226.12.8

192.168.3.32

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 andHost B can be distinguished and will perhaps follow different paths. If the mapping in this figure wasonly based on the destination address, packets from Host A and Host B to the same destination Hostwould 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 calledLabel Switched Path (LSP). A LSP is a sequence of routers ������������� ��� . ��� is called the LSP

7

ingress and � � the LSP egress. The inner routers � � � ����� ��� � are MPLS capable routers which re-ceive labeled packets. Forwarding decisions at the inner routers are only based on this label carried inthe packets by a simple table lookup using the incoming label as an index. In a LSP, labeled packetsare 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 alwaysneeded by TCP, another path must be set up.

Host A

R3

R2

R4

Host C

Host B

R1 (Ingress)

R5 (Egress)

Figure 3.2: Label Switched Path

In Figure 3.2 � ��� ��� � ����� ����� � builds a LSP, where � � is the LSP ingress and ��� is the egressrouter. Packets arrive unlabeled at � � . ��� adds a particular label belonging to the corresponding FECto the packets destined for Host B. When these packets arrive at ��� , this router removes the label andforwards the packet.

3.3.1 Label Edge Router

The Label Edge Routers (LERs) are the end points of an MPLS domain. They handle the traffic whenit 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 inthe LSP ��� acts as a LSR for that path.LERs must be distinguished between ingress and egress routers. The ingress router is responsible formapping 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. bysetting the NHLFE to zero. If a path is set up for a FEC, the NHLFE contains the outgoing label fora packet, a stack operation which describes the handling of the label in the packet and the next hopaddress. The following table shows the fields of an NHLFE at the ingress LER and egress LER:

Ingress LER Egress LERLabel Outgoing label for the packet Explicit null label

Stack operation Push label Pop labelNext 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

classifies a packet to a FEC, the LER does a lookup in the FTN for the corresponding NHLFE. If thepath for the FEC is not set up yet, the LER has to setup the path first. Otherwise it adds the labelfrom the NHLFE to the packet and forwards the packet to the next hop in the path. In order to label apacket, the ingress creates a shim header which contains the following four fields:

� LabelThe label is encoded in 20 bits. The LER gets the label from the NHLFE which was attachedto the packet’s FEC.

� Experimental bitsThe experimental bits can be used for example to encode DiffServ codepoints when usingDiffServ combined with MPLS.

� Stack bitThe Stack bit indicates that this label is the last label in the packet. This bit is useful forhierarchical 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 theIP header is copied into the TTL field of the shim header.

0 31

SExpLabel

20 23

TTL

24

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 anIncoming Label Map (ILM) which contains NHLFEs. When a packet arrives for which the router isthe egress LER, the router looks up the ILM by using the label carried by the packet as an index tothe 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, toremove the shim header and to make a forwarding decision based on the remaining packet, e.g. itdoes 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 canbe avoided if the penultimate router on the path already removes the label. This method is calledPenultimate Hop Popping. If Penultimate Hop Popping was used in Figure 3.2, ��� would copy theTTL to the IP header, remove the shim header from the packet and forward it to � � . The packet willarrive at ��� as a plain IP packet, so ��� only has to do a lookup in the routing table.

9

3.3.2 Label Switching Router

The core routers between the LSP ingress and the LSP egress are Label Switching Routers (LSR). Inorder 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 labelledpackets from the upstream node of the path. The LSR does not classify a packet to a FEC, it justlooks up the Incoming Label Map for a corresponding Next Hop Label Forwarding Entry for thatlabel. 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 labelwhich is [swap label] in this case and the next hop address. After the ILM lookup, the LSR replacesthe label with the outgoing label, decrements the TTL from the shim header and forwards the packetto the next hop specified by the next hop address in the NHLFE.

23 66 swap R4

66 42 R5swap

Host A R1 (Ingress)

Host BR5 (Egress)

Host C

R4

Op. NextHop

ILM at R2

FEC Next Hop

23

Op.

R2FEC 1 push

Op. NextHop

ILM at R4

FEC 1

NHLFE

NHLFE

FTN at R1

NHLFE

Out

Out

OutLabel

Op. NextHop

ILM at R5NHLFE

Label

Label

OutLabel

LabelIn

Label

LabelIn

In

42 pop N/A

66 pop R5When Penultimate Hop Popping

is usedNULL

NULLExpl.

Impl.

R3

R2

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. WhenPenultimate Hop Popping is used, the router � � receives packets unlabeled from R4. As ��� hasfigured out with its ILM, it removes the label from the packets and forwards them. When PenultimateHop Popping is not used, ��� receives packets labeled with 42, so � � removes the shim header fromthese packets. In both cases the router � � searches the routing table for a longest prefix match of thedestination IP address of the packets.

10

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 FECA packet is classified to a FEC if the packet matches a particular set of rules, which are associ-ated with the FEC, e.g. the packets destination IP address matches a particular prefix,

� Lookup of the NHLFE in the FTNWhen 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 givenin the NHLFE is [push label]. If the path for the FEC does not exist yet, the ingress routermust initiate a path setup. This assumes the use of Downstream-on-Demand label distributionas described in section 3.3.5.

� Add the MPLS shim header to the packetThe label in the MPLS shim header is taken from the NHLFE of the FEC which the packetbelongs to. The TTL field is filled with the TTL from the received IP packet. The shim headeris inserted between the link layer header and the IP header.

� Forward the packetThe packet is forwarded to the router which is specified by the next hop address in the NHLFEfor the FEC.

3.3.4 Forwarding packets at the Egress LER

If Penultimate Hop Popping is not used, the egress LER receives labeled packets from its upstreamLSR. The LER only looks at the shim header which does not hold information about the LSP endpoints. The router does a lookup in the ILM to find the corresponding NHLFE for the incoming labelof the packet. The NHLFE contains a special label, the EXPLICIT NULL label. A router realizeswith the EXPLICIT NULL label that it is the egress LER. The operation given by the NHLFE is [poplabel], so the router removes the label from the packet. In an NHLFE which contains an EXPLICITNULL label, there is no specified next hop.

If Penultimate Hop Popping is used, the label of a packet is removed by the penultimate hop. Inthe same manner as above, the penultimate hop has to figure out that it is responsible for removingthe label. Thus, the penultimate hop does the lookup in the ILM for the incoming label. If it is thepenultimate hop for the path which the packet belongs to then the NHLFE contains an IMPLICITNULL label. This label indicates that the label must be removed. In opposition to an NHLFE with anEXPLICIT 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 theunlabeled packet. For this reason, the LER has to make a forwarding decision based on the remainingpacket.

11

3.3.5 Label Distribution

In order to forward labeled packets only by switching labels, a LSR has to know which labels to useas 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, thedownstream peer binds a label to a particular FEC and distributes this label binding to its upstreampeer. The upstream peer uses the label from that label binding as the outgoing label for packets of theFEC. The advantage of distributing label bindings from downstream to upstream routers is that thedownstream router controls the binding of incoming labels so that it can avoid ambiguities betweenincoming labels.When a router receives a label binding for a particular FEC from a downstream node and the routeris not the ingress LER for that FEC, it creates an NHLFE which contains the provided label as theoutgoing label, the stack operation [swap label] and the downstream router as the next hop. The routerbinds a free label to the NHLFE and stores the NHLFE in the ILM by using the new label as an indexto 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 NHLFEwhich includes the provided label as the outgoing label, the stack operation [push label] and thedownstream router as the next hop. The ingress LER assigns the NHLFE to the FEC and stores it inthe FTN map.

In an MPLS domain, there are two Label Distribution Control Modes:

� Ordered ControlWith Ordered Control, only the egress router of a LSP is allowed to start binding a label to aFEC. It distributes the label binding to its upstream label distribution peer on the path. One afteranother binds a new label for the FEC after it has received a label binding for the FEC fromthe downstream router and distributes the label binding to the upstream router until the ingressrouter receives the label binding. The ingress router binds the label to the corresponding FECin its FTN.

� Independent ControlWith Independent Control, every router in the MPLS domain is allowed to start binding a labelto a FEC. Thus, a LSR which binds an incoming label to a particular FEC and distributes it toits label distribution peers creates an NHLFE with the EXPLICIT NULL label as the outgoinglabel and the stack operation [pop label]. This is needed since a LSR must be able to forwardlabeled packets of that FEC for which it has distributed a label binding. When the LSR hasreceived the corresponding label binding for the FEC from the downstream label distributionpeer, the LSR replaces the NHLFE with the EXPLICIT NULL by an NHLFE which containsthe provided label as the outgoing label, the stack operation [swap label] and the downstreampeer as the next hop.

12

for labelrequest

for labelrequest

1. 2.

for labelrequest

1. 3. for labelrequest

4.2.

R1 R3

label 12 label 40

4. 3.

R2

R1 R2 R3

label 12 label 40

bind e.g. bind e.g.

bind e.g. bind e.g.

a) Ordered Control

b) Independent Control

Figure 3.5 Label Distribution Control modes: a) Independent; b) Ordered

The MPLS architecture supports two Label Distribution Advertisement Modes. With the Downstream-on-Demand label distribution, the ingress router of a LSP explicitly requests a label binding. WhenDownstream-on-Demand label distribution is used together with Ordered Control, the ingress routerwill generate a label request for a FEC. The request will be forwarded downstream until the egressrouter 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 bindingfrom the downstream router. When the ingress router receives the label binding, it uses the providedlabel 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 couldbind a label and distribute it to the upstream router first and then request a label from the downstreamrouter.

Unsolicited Downstream label distribution means that the routers of an MPLS domain can indepen-dently decide to bind labels and distribute them to their upstream routers without that the upstreamrouters have explicitly requested a label binding. When the ingress router of a path receives a labelbinding 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. Withthe Liberal Label Retention Mode, a router decides to hold a label binding although the downstreamrouter 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 downstreamrouter for that binding becomes unavailable. Thus, if the downstream router becomes available againand 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

ILM with at least ���

NHLFEs2, there should be enough space to hold the label bindings. If a routerhas 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 becauseof 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 labeledpackets over a LSP. That is, a LSP which is established between a LER of a particular MPLS domainand a LER of another MPLS domain is routed through a further MPLS domain. The packets of thisLSP 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 egressLER of the last domain arrives at the ingress LER of the middle domain, it will be tunneled over theLSP 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 secondlabel, and forwards the packet to the ingress LER of the third domain. The egress LER of the lastdomain 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 hierarchicallabel switched path. The labeled packets from the ingress LER to the egress LER of the third domainare tunneled over a LSP in the second MPLS domain.

2For each incoming label the ILM includes at least one NHLFE.

14

IP

IP

IP

IP

IP IP

IP

IP

IP

Host A

Host B

Domain A

Domain B

Domain C

54

18 27

32

72

67

A 1

A 2

A 4

A 3

B 1

B 2

B 3

C 5

C 4

C 2

C 1

C 3

54 C 4swap

27 pop

ILM at B 3

ILM at C 5

swap6732

ILM at A 4

B 169

69 69

swap

69 18

67

push B 2

NULLexpl.

61

69 61 swap C 5

−−

In Out Next HopOp

B 1

ILM at B 1

Out Op Next HopIn

In Out Next Hop

In Out Op

Op

Next Hop

61

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 69and forwards the packet to itself. Then it does a lookup in the ILM for the label 69 which returns aNHLFE which contains the outgoing label 18, the stack operation [push label] and B 2 as the nexthop. Thus, B 1 adds the outgoing label 18 in front of existing labels in the packet. When the packetleaves domain B at the egress LER B 3, te router B 3 removes the foremost label of the packet. Itdoes a lookup in the ILM for the next label on the packet which is 69. B 3 swaps the label 69 with theoutgoing label 61 and forwards it to C 5.

3.4.1 Label Stack

A packet contains more than one label if it is forwarded through an LSP tunnel. If a packet enters aLSP a new label is added in front of existing labels, and when the packet leaves the LSP the foremost

15

label will be removed. The packet includes the Label Stack [9] which is organized in First In FirstOut order. Thus, the foremost label in a packet is the top of the label stack, the last label is the bottomof the label stack. The labels are encoded in MPLS shim headers as described in section 3.2 (Figure3.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 isthe 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 LSPusing the label at the stack depth of � is referred to as a LSP at level � of the hierarchy. The LSPwhich uses the labels at the bottom of the stack is referred as the LSP at level one. In Figure 3.6, theLSP 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.

BR 1

lookup Operation = push labelLabel = 18

Next hop = BR 2

Label = 15 Exp S=1 TTL Label = 15 Exp S=1 TTL

Exp TTLLabel = 18 S=0

... ...

Out Op Next hop

NHLFE

18 BR 2push

ILM

In

15

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 atthe 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 ILMfor the new label. The corresponding NHLFE contains the outgoing label 18 and the next hop whichis B 2, but the stack operation is [push label]. Thus, B 1 creates an additional shim header with theoutgoing label. The stack bit is set to zero and the TTL is copied from the shim header at the top ofthe stack of the incoming packet. The shim header is inserted in front of the existing shim headers, soit 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

Label = 15 Exp S=1 TTL...

lookup

BR 3

Out Next hop

ILMNHLFE

27

Label = 15 Exp S=1 TTL

Exp TTLS=0

...

Label = 27

In Op

popNULLImpl.

−−−

Operation = pop label

Figure 3.8: LSP tunnel egress router

When the packet with the label stack of depth �� �

arrives at the egress LER B 3 of domain B, B 3does a lookup in its ILM with the incoming label of the packet. The corresponding NHLFE containsthe operation [pop label], so B 3 removes the shim header at the top of the label stack. The label stackdepth 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 stackdepth, so it can reach the size of the path MTU. When a packet with the size of the path MTU arrivesat a LSP ingress router, the ingress router has to fragment the packet if this is permitted by the networklayer protocol. The router splits the packet without the MPLS shim headers into fragments which haveat 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.

3.4.2 Processing the TTL

Every router in an MPLS domain checks the TTL of the shim header at the top of the label stackwhether it becomes less than zero. In that case, the router discards the packet and sends an ICMPmessage towards the sender. The processing of the TTL in a LSP is specified in two models [10]:

17

Label Stacklevel m

level m − 1

Label Stacklevel m

level m − 1

TTL = n

TTL = N − 2TTL = N −1

TTL = n

TTL = n − 3

TTL = n − 5

TTL = n − 2

TTL = N −3

TTL = n − 1 TTL = n − 4

(TTL = n −1)

TTL = n −2

TTL = N

(TTL = n − 1)R 1

R 2 R 3

R 5

R 4

push label pop label

R 1

R 2

R 5

R 4R 3

push label pop label

a) Uniform model

b) Pipe model without Penultimate Hop Popping

Figure 3.9: TTL processing models

� Uniform modelWith 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 theTTL 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 tothe packet. The additional shim header contains the TTL from the packet. The ingress routerdecrements this TTL by one and forwards the packet to the next hop in the LSP tunnel. Everyrouter in the LSP tunnel which receives the packet decrements the TTL of the shim header atthe top of the label stack by one. The TTLs of the shim headers at lower levels in the labelstack are left untouched. The egress router or the penultimate hop of the LSP tunnel removesthe foremost shim header and copies the TTL of the removed shim header to the underlyingshim header, which has become the top of the label stack. Thus, the TTL of the packet alwayscontains the information about how many hops the packet has traversed.

� Pipe modelWith 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 theTTL in the shim header of the top of the label stack. After that it creates a new TTL for theadditional shim header which becomes the new top of the label stack. The LSRs of the LSPtunnel 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 theshim header at the top of the label stack. It does not care for the TTL of the removed shimheader, but decrements the TTL in the foremost shim header in the packet at the new top of thelabel stack.

Thus, the TTL of the shim header at the top of the label stack has been decremented by twowhen the packet leaves the LSP tunnel.

18

If Penultimate Hop Popping is used, the penultimate hop will remove the shim header at thetop 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 shimheader at the top of the label stack is decremented by two when it leaves the LSP tunnel.

3.4.3 Remote Label Distribution

LSRs which exchange label bindings are label distribution peers. If they are directly connected, theyare called local label distribution peers. Label distribution peers which are not directly connected arecalled remote label distribution peers.

There are two ways for remote label distribution peers to exchange label bindings:

� Explicit PeeringWith Explicit Peering, a remote downstream label distribution peer provides a label bindingby 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 pro-vided binding in the message. For example, the packet which contains the message is tunneledthrough an existing LSP tunnel between the remote label distribution peers.

� Implicit PeeringWith Implicit Peering, a remote downstream label distribution peer would bind labels for itslocal and remote distribution peers. Then it creates a label distribution protocol message forits local distribution peers and adds label bindings for its remote label distribution peers as anattribute to the message. When a local distribution peer receives that message, it accepts thelocal label binding. It adds the remote label binding information to a label distribution protocolmessage for a local label binding and forwards this message to its local distribution peers. Thisprocess repeats until the destination of the remote label binding is reached. Thus, each routerwhich receives a label distribution protocol message with a remote label binding piggybackedon 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 apath setup in terms of a PATH message towards the egress router. Every RSVP capable router whichprocesses and forwards this path message will belong to the path. The egress router which is includedas 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

document. This document describes the null service [11], which is used when resources should not bereserved at path setup. For example, if MPLS is used in combination with DiffServ, QoS is providedby 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 path3

because forwarding decisions are made by a routing protocol and RSVP capable routers belong to apath if they have processed and forwarded the PATH message. RSVP is a soft state protocol. So apath 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 extensionsto RSVP. With these extensions, RSVP is able to provide label distribution for MPLS by distributinglabel bindings between label distribution peers at path setup. Another extension is that the ingressrouter of a path is able to use an predetermined route for a path. Thus, traffic engineering becomespossible 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 forwardsit towards the egress router for that LSP. The egress router binds a label, creates a RESV messagewhich contains the label binding and forwards it towards the ingress router. A router which receivesthe RESV message takes the label from the RESV message and uses it as the outgoing label for theLSP. Then it binds a new label for the LSP and adds it to the RESV message. After the ingress hasreceived the RESV message, it stores the label as the outgoing label in the NHLFE which is assignedto the LSP’s FEC. The following sections explain this in detail.RSVP-TE uses Downstream-on-Demand label distribution because the PATH message contains arequest for a label binding. Also RSVP uses Ordered Control mode since the egress router starts withlabel binding when sending a RESV message.

The PATH and RESV messages are encapsulated in IP packets. They consist of a common RSVPheader and several objects, which are introduced in the next sections. The RSVP header essentiallycontains the following fields:

� Message TypeThis field is needed to distinguish between a PATH and a RESV message

� ChecksumThe 16-bit checksum is computed by taking the one’s complement of the sum of the one’scomplement of 16-bit parts of the message.

� Send TTLThe Send TTL is needed to detect if there is a non-RSVP router which has forwarded the RSVP

3except ingress and egress routers

20

message. The Send TTL is copied from the IP header. If the Send TTL of an incoming RSVPmessage differs from the TTL of the IP header, then a non-RSVP router has forwarded themessage.

� LengthThe 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 SESSIONobject 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 theIP address of the ingress LER of the LSP, and a LSP ID. However, in RESV messages the SENDERTEMPLATE object is included as a FILTER SPEC object. These objects are present in PATH andRESV messages. They are used to assign a RESV message to a prior PATH message.

4.1.1 Creating a PATH-Message

When an ingress router starts to setup a LSP, it first creates a PATH message. The PATH messageconsists of a RSVP header and at least the following objects:

� SESSION objectThe SESSION object contains the IP address of the egress router of the LSP, which will createthe RESV message when it receives the PATH message, and the Tunnel ID. The Tunnel ID isgenerated by the ingress of the LSP.

� RSVP HOP objectThe ingress router stores its own IP address in the RSVP HOP object. The RSVP HOP objectis needed to route RESV message on the same path as the PATH message.

� TIME VALUES objectThis object contains the refresh period. Since RSVP is a soft state protocol the path setup hasto be refreshed within this period.

� LABEL REQUEST objectThe LABEL REQUEST object indicates that labels have to be bound and distributed for theLSP in the RESV message.

� SENDER TEMPLATE objectThe SENDER TEMPLATE contains the IP address of the ingress router and a LSP ID. TheLSP ID is generated by the ingress router.

� SENDER TSPEC objectThe SENDER TSPEC object describes the characteristics of the traffic which will be sent overthe path. If the null service is used, the SENDER TSPEC only includes the maximum packetsize for a packet.

21

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 neededto assign an incoming RESV message to a previously sent PATH message. The Path State Block ishold for the path refresh.

It is possible to add an EXPLICIT ROUTE object (ERO) to the path message. The ERO describes apredetermined route for the LSP. The ERO contains a list of subobjects. A subobject consists of anabstract node and a loose flag.

An abstract node is referred to as a group of routers. The PATH message has to be routed accordingto 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 tothe path but it is not required. The abstract node of a subobject with the loose flag set is referred to asa loose node. Otherwise if the loose flag is not set in a subobject, the abstract node of this subobjectmust belong to the path. The abstract node of a subobject with the loose flag not set is referred to asa strict node.

After the ingress router has created the objects of the PATH message, it creates an RSVP header. Theingress computes the checksum and the length of the PATH message. The Send TTL has to be thesame value as the TTL in the IP packet with which the PATH message will be send. At the ingressrouter, this will be the initial value, e.g. 255, for a TTL. The ingress router encapsulates the PATHmessage in an IP packet which is destined for the egress router of the LSP.

4.1.2 Forwarding a PATH-Message

When a PATH message arrives at a LSR, the LSR first verifies the checksum and the length of thePATH message. The LSR checks if it is the tunnel end point specified in the SESSION object. If thisis 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 TEMPLATEobject identify the LSP which will be established. With this information, the RESV messagewhich arrives later can be assigned to the LSP. Since the RESV message must be routed onthe same path as the PATH message, the RSVP HOP object, which contains the address of theprevious 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 thenext router which processes the PATH message will know where to forward the correspondingRESV message.

� Get the next hop for the PATH message:

22

– ERO is not presentThe LSR does a lookup in the routing table to determine the next hop for the PATH mes-sage.

– ERO is presentThe LSR looks at the first subobject. If it is not within the abstract node of the subobjectthe LSR sends a ”Bad initial subobject” error message towards the ingress router of theLSP. Otherwise it walks through the subobject list and removes the first subobject at everystep 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 anddoes a lookup in the routing table to determine the next hop for the PATH message. Ifthere is a subobject with an abstract node which does not include the LSR, the LSR does alookup in the routing table if it is directly connected to a router in the abstract node. If thisis the case, the router chooses the router of the abstract node which it is directly connectedto as the next hop for the PATH message. If the LSR is not directly connected to a routerin the abstract node of the subobject the LSR checks if the routing table contains an entrywith a next hop in its own abstract node for the abstract node of the subobject. If it doesnot find a next hop from its own abstract node and the abstract node is a strict node, theLSR sends a ”Bad strict node” error towards the ingress LER and the path setup fails. Ifthe abstract node is a loose subobject, the LSR does a lookup in the routing table in orderto get a next hop address.After a next hop is found, the LSR replaces the first subobject with a new subobject. Theabstract node of the new subobject includes the next hop, so that the next hop will acceptthe EXPLICIT ROUTE object.

� If the PATH message includes an ERO, the PATH message has to be encapsulated in a newIP packet which is destined for the chosen next hop and the Send TTL in the RSVP header iscopied from the new IP header. If the LSR removed the ERO the IP packet must be destinedfor the egress LER specified by the tunnel endpoint address in the SESSION object. Finally theLSR forwards the packet.

4.1.3 Creating a RESV-Message

When the egress router of the LSP receives the PATH message and the PATH message includes aLABEL REQUEST object it assigns a free label or if Penultimate Hop Popping is used it binds theIMPLICIT NULL label for the LSP. If Penultimate Hop Popping is not used, it creates an NHLFEwith the EXPLICIT NULL label as the outgoing label and the stack operation [pop label]. Then itcreates a RESV message. The RESV message consists of a RSVP header and at least the followingobjects:

� SESSION objectThe SESSION object must be the same as in the PATH message, so that the routers whichforward the RESV message can assign the RESV message to the LSP.

23

� RSVP HOP objectThe RSVP HOP object includes the IP address of the egress router.

� TIME VALUES objectThe TIME VALUES object includes the same refresh period as in the PATH message.

� STYLE objectThe STYLE object includes a filter style. The filter style defines how the reservation in theFLOWSPEC 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 eachsender of a session.

– Shared Explicit Style: With the Shared Explicit Style, the receiver can specify the sendersof a session which share a reservation.

– Wildcard Filter Style: With the Wildcard Filter Style, all senders of a session share thereservation.

Note that these filter styles only apply to the senders of a session, that is, the reservations can beshared between senders of multipoint-to-point paths or the sender in a point-to-point path canshare reservation with itself. The latter case is used to reroute a path or to change the reservationfor a path. For that reason, the sender creates a new path using the shared explicit filter style sothat the new reservation will not be added to the old reservation. After the new path is setup,the old path will be removed.

� FLOWSPEC objectThe FLOWSPEC object determines the reservation which the receiver has made for the path. Ifthe null service is used, the FLOWSPEC object only includes the maximum packet size.

� FILTER SPEC objectThe FILTER SPEC object must be the same as the SENDER TEMPLATE object in the PATHmessage, so that the routers which forward the RESV message can assign the RESV messageto the LSP.

� LABEL objectThe 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. Theegress router sends the RESV message encapsulated in an IP packet to the previous hop of the PATHmessage. Since the RESV message must be forwarded on exactly the same route as the PATH mes-sage, the RESV message is not destined for the ingress router of the LSP, which could result in adifferent route.

24

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 RESVmessage. 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 ingressLSR of the LSP, it binds an incoming label for the LSP and creates a NHLFE with the outgoing labelfrom the LABEL object of the RESV message. If the label in the LABEL object is the IMPLICITNULL label, the NHLFE includes the stack operation [pop label] since this label indicates that theLSR is the penultimate hop for that LSP. If the label is not the IMPLICIT NULL label, the NHLFEincludes the stack operation [swap label]. The next hop address is the address of the hop from whichthe RESV message was received. This address is given by the RSVP HOP object in the RESV mes-sage. 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 objectwith the incoming label binding. Furthermore, it creates a STYLE and FLOWSPEC object indicatingthe desired QoS. A new RESV message is created which contains a new RSVP header. The newRSVP HOP object, the new LABEL object, the new STYLE object, the new FLOWSPEC object andthe SESSION, TIME VALUES and the FILTER SPEC object from the received RESV message areadded to the new RESV message. The LSR encapsulates the RESV message in an IP packet. The IPpacket is destined for the router specified in the RSVP HOP object in the Path State Block. This isthe 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 fromthe LABEL object of the RESV message as the outgoing label, the stack operation [push label] andthe address from the RSVP HOP object as the next hop address. The ingress LER assigns the NHLFEto 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 apacket which carries all the information needed to forward the packet. The ingress router of an MPLSdomain classifies a packet into a Forwarding Equivalence Class. A Forwarding Equivalence Class isassociated with a Label Switched Path. The Label Switching Routers in a LSP forward a packet byexchanging the label with another and forward it to the next hop in the path. For this reason they doa lookup in the Incoming Label Map with the incoming label. The ILM includes Next Hop LabelForwarding 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 calleda hierarchical path. The labels in a packet are organized in the label stack. The label stack is added toa packet before the IP header.A router must inform its upstream router for a LSP about a label binding. MPLS uses a label dis-tribution protocol to distribute label bindings between label distribution peers. RSVP-TE is a label

25

distribution protocol which distributes labels at path setup. RSVP-TE is capable of using predeter-mined routes for a LSP. Thus, with MPLS and RSVP-TE it is possible to do Traffic Engineering.

MPLS provides better network performance than with conventional IP routing. An LSR which for-wards a packet only has to do one lookup in the ILM. In contrast to a longest prefix match for an IPaddress in the routing table this lookup is performed in constant time.

26

A Flowcharts for RSVP-TE

A.1 Flowchart: RSVP-TE

27

A.2 Flowchart: Create PATH message

28

A.3 Flowchart: Forward PATH message

29

A.4 Flowchart: Create RESV message

30

A.5 Flowchart: Forward RESV message

31

References

[1] J. Postel, Internet Protocol, RFC 791, September 1981

[2] J. Moy, OSPF Version 2, RFC 2328, April 1998

[3] R. Braden et al., Integrated Services in the Internet Architecture: an Overview, RFC 1633, June1994

[4] R. Braden et al., Resource ReSerVation Protocol (RSVP) – Version 1 Functional Specification,RFC 2205, September 1997

[5] R. Braden et al., Resource ReSerVation Protocol (RSVP) – Version 1 Message Processing Rules,RFC 2209, September 1997

[6] S. Blake et al., An Architecture for Differentiated Services, RFC 2474, December 1998

[7] K. Nichols et al., Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6Headers, RFC 2475, December 1998

[8] E. Rosen et al., Multiprotocol Label Switching Architecture, RFC 3031, January 2001

[9] E. Rosen et al., MPLS Stack Encoding, RFC 3032, January 2001

[10] P. Agarwal et al., Time To Live (TTL) Processing in Multi-protocol Label Switchind (MPLS)Networks, RFC 3443, January 2003

[11] Y. Bernet et al., Specification of the Null Service Type, RFC 2997, November 2000

[12] D. Awduche et al., RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC 3209, December 2001

32