MPLS TE Technology White Paper

MPLS TE Technology White Paper

Keywords: MPLS, MPLS TE, RSVP TE, CR LDP, CSPF, OSPF TE, IS-IS TE
Abstract: This document discusses the MPLS TE technology and the H3C implementation of
MPLS TE, and presents some typical applications.
Acronyms:
Acronym
Full spelling
BFD
Bidirectional Forwarding Direction
CR LDP
Constraint-Based Routing LDP
CSPF
Constraint Shortest Path First
FEC
Forwarding Equivalence Class
FRR
Fast ReRoute
IGP
Interior Gateway Protocol
IS-IS
Intermediate System to Intermediate System Protocol
LDP
Label Distribution Protocol
LSP
Label Switched Path
L3VPN
Layer 3 VPN
L2VPN
Layer 2 VPN
MPLS
Multiprotocol Label Switching
MPLS TE
MPLS Traffic Engineering
OSPF
Open Shortest Path First
RSVP
Resource reSerVation Protocol
RSVP-TE
RSVP Traffic Engineering extension protocol
TED (TEDB)
Traffic Engineering Database
TE
Traffic Engineering
VPN
Virtual Private Network
Hangzhou H3C Technologies Co., Ltd.
1/30
Table of Contents
1 Overview......................................................................................................................................... 4
1.1 Problems with Traditional Routing ....................................................................................... 4
1.2 TE Solution .......................................................................................................................... 4
1.3 Benefits of MPLS TE ........................................................................................................... 5
2 Technical Characteristics ............................................................................................................... 6
2.1 Static LSP Tunneling............................................................................................................ 7
2.2 Explicit Routing .................................................................................................................... 7
2.2.1 Strict Explicit Paths ................................................................................................... 7
2.2.2 Loose Explicit Paths.................................................................................................. 8
2.2.3 Hybrid Explicit Paths ................................................................................................. 9
2.3 Link Coloring ........................................................................................................................ 9
2.4 Priorities and Preemption .................................................................................................. 10
2.4.1 Priorities .................................................................................................................. 10
2.4.2 Preemption .............................................................................................................. 11
2.5 Tunnel Reoptimization ....................................................................................................... 12
2.6 LSP Tunnel Backup ........................................................................................................... 12
2.7 FRR.................................................................................................................................... 14
2.7.1 Problems Solved by FRR........................................................................................ 14
2.7.2 Switchover Time with FRR...................................................................................... 15
2.7.3 Limits of FRR........................................................................................................... 15
2.8 Automatic Bandwidth Adjustment ...................................................................................... 15
2.9 Automatic Route Advertisement......................................................................................... 16
2.9.1 IGP Shortcut............................................................................................................ 16
2.9.2 Forwarding Adjacency............................................................................................. 16
2.10 MPLS L3/L2 VPN over TE ............................................................................................... 17
3 MPLS TE Implementation ............................................................................................................ 17
3.1 Information Advertisement ................................................................................................. 18
3.2 Path Selection.................................................................................................................... 19
3.3 Signaling Protocol .............................................................................................................. 20
3.3.1 RSVP-TE................................................................................................................. 20
3.3.2 CR-LDP ................................................................................................................... 25
3.4 Data Forwarding ................................................................................................................ 26
2/30
4 Application Scenarios ................................................................................................................... 27

4.1 Bandwidth Guarantee ........................................................................................................ 27
4.2 Protection Function............................................................................................................ 27
4.3 Integration of TE Tunneling and MPLS VPN ..................................................................... 28
5 References ................................................................................................................................... 29
3/30
1 Overview
1.1 Problems with Traditional Routing
With traditional routing technologies, a router selects the shortest path for traffic
without considering other factors such as bandwidth. Even when congestion occurs, it
does not switch traffic to any other available path. The problem gets highlighted when
large traffic is present.
Figure 1 Problems with traditional routing
As shown in the above figure, two paths are available for traffic to travel from Router
A to Router H: Router A->Router C->Router G->Router F->Router H (Path 1) and
Router A->Router C->Router D->Router E->Router F->Router H (Path 2). Suppose
that all links have the same metric. Then, all traffic will be forwarded on Path 1, the
shortest path. This tends to overload Path 1 while Path 2 is idle. You can address the
problem by modifying their link metrics so that the two paths have the same cost to
share load. However, this solution tends to cause traffic jam on other links and is
difficult to implement on a network with complex topology as the change of a link may
involve multiple routes.
1.2 TE Solution
Traffic engineering addresses the problems with traditional routing by taking elements
4/30
such as bandwidth into consideration.

As shown in the following figure, two paths are available between Router A and
Router H: Router A -> Router C -> Router G -> Router F -> Router H (Path 1) and
Router A -> Router C -> Router D -> Router E -> Router F -> Router H (Path 2). The
path bandwidth of Path 1 is 40 Mbps and that of Path 2 is 100 Mbps. If a service that
requires 40 Mbps path bandwidth and a service that requires 70 Mbps path
bandwidth are present between Router A and Router H, traffic engineering can
assign the 40 Mbps service to Path 1 and the 70 Mbps service to Path 2. Thus, link
congestion can be avoided.
Router G
40 M bandwidth
100 M bandwidth
40 M traffic
70 M traffic
1
1
Router C
Router A
Router F
Router H
1
Router D
Router E
Figure 2 Network with MPLS TE
Traffic engineering (TE) focuses on the optimization of overall network performance.

It is intended to conveniently provide highly efficient and reliable network services.
The performance objectives associated with TE are either traffic oriented to enhance
quality of service (QoS) or resources oriented to optimize resources (especially
bandwidth) utilization. TE helps optimize network resources use to reduce network
administrative cost, and dynamically tune traffic when congestion or flapping occurs.
In addition, it allows ISPs to provide added value services.
1.3 Benefits of MPLS TE

The interior gateway protocols (IGPs) cannot present some dynamic factors such as
bandwidth and traffic characteristics, because they are topology-driven and consider
5/30
only network connectivity. This IGP disadvantage can be repaired by using an overlay
model, such as IP over ATM or IP over FR.
An overlay model provides a virtual topology above the physical network topology for
a more scalable network design. It also provides better traffic and resources control
support for implementing a variety of traffic engineering policies. Despite all the
benefits, overlay models are not suitable for implementing traffic engineering in largesized backbones because of their inadequacy in extensibility.
In this sense, MPLS TE is a better traffic engineering solution for its extensibility and
ease of implementation.
MPLS is better than IGPs in implementing traffic engineering for the following:
z
MPLS supports explicit LSP routing.
LSP routing is easy to manage and maintain compared with traditional packetby-packet IP forwarding.
The Constraint-Based Routed Label Distribution Protocol (CR-LDP) is suitable

for implementing a variety of traffic engineering policies.
MPLS TE uses less system resources compared with other traffic engineering
implementations.
MPLS TE brings together the benefits of MPLS and traffic engineering. It delivers
these benefits:
z
Resource reservation by establishing LSP tunnels to specific destinations.
Convenient LSP tunneling behavior control by introducing attributes such as

priority and preemption.
Providing protection with route backup or fast reroute (FRR) technology when a
link or node fails.
Small LSP setup overheads, which hardly affect normal network services.
All these benefits make MPLS TE an attractive traffic engineering solution. It allows
service providers to optimize and manage network resources efficiently to provide
diversified services.
2 Technical Characteristics
MPLS TE delivers these features:
z
Static LSP Tunneling
Explicit Routing
6/30

z
Link Coloring
Priorities and Preemption
Tunnel Reoptimization
LSP Tunnel Backup
FRR
Automatic Bandwidth Adjustment
Automatic Route Advertisement
MPLS L3/L2 VPN over TE
2.1 Static LSP Tunneling

Similar to static routing, static LSP tunneling does not require signaling and requires
you to make configuration on each hop regarding resource requirements, labels, and
so on. An LSP thus established is not affected by the signaling protocol and will exist
until being removed.
2.2 Explicit Routing

Explicit routing draws the path that an LSP must travel to reach the destination. With
explicit routing, you can specify which nodes the LSP must travel and which nodes it
must bypass. Explicit routes can be used as constraints to calculate the path that an
LSP is intended to travel.
2.2.1 Strict Explicit Paths
Figure 3 Strict explicit path

7/30
A strict explicit path is the path that an LSP must take as intended. On such a path,
any two neighboring nodes are directly connected.
In the above figure, Router B strict in the legend indicates that the LSP must pass
by the Router B node and the previous hop of Router B must be Router A, the ingress
LSR; Router C strict indicates that the LSP must pass by Router C, and the
previous hop of Router C must be Router B, and so on.
2.2.2 Loose Explicit Paths
Figure 4 Loose explicit path
On a loose explicit path, the nodes that an LSP must pass by are explicitly specified
but a node and its previous hop may have devices in between.
In the above figure, Router E loose in the legend indicates that the LSP must pass
by Router E, but Router E is not necessarily directly connected to Router A, the
ingress LSR.
8/30
2.2.3 Hybrid Explicit Paths
Figure 5 Hybrid explicit path
Strict and loose routing could be used together. In the above figure, "Router B strict
in the legend indicates that the LSP must pass by Router B and Router B must
directly connect to Router A, the ingress LSR; Router E loose indicates that the LSP
must pass by Router E, but multiple routers are allowed between Router E and
Router B.
2.3 Link Coloring

Links are colored to help determine links that a path can travel. A total of 32 link
colors are available. You may specify a path to travel links in certain color and bypass
links in any other colors.
9/30
Figure 6 Link coloring
In this example, the LSP must not travel bronze links. Therefore, the bronze links will
be cut during path calculation.
2.4 Priorities and Preemption

2.4.1 Priorities
Every LSP tunnel has a setup priority and a holding priority. Both priorities range from
0 to 7, with a lower numerical number indicating a higher priority. When multiple LSP
tunnels are to be established, the LSP tunnel with higher setup priority is set up prior
to the others. When resources such as bandwidth are insufficient, the LSP tunnel with
lower holding priority could be preempted by an LSP tunnel with higher setup priority.
10/30
2.4.2 Preemption
Figure 7 LSP preemption
As shown in the figure, there exist two TE tunnels, T1 (Router A->Router B->Router E)
with 155 Mbps of bandwidth and T2 (Router C->Router B->Router F) with 155 Mbps
of bandwidth. The setup and holding priorities of T1 are 0 and those of T2 are 7.
Suppose that each link has the same bandwidth in both directions and all links are
assigned the same metric. When link Router BRouter E goes down, Router B
signals the event to Router A. Router A then recalculates a new path Router A>Router B->Router F->Router E for T1. As the bandwidth of link Router BRouter F is
inadequate to carry both T1 and T2 and T2's holding priority (7) is lower than that of
T1, T2 will be preempted. A new path is set up for T1 as follows:
1)
A PATH message is sent along Router A -> Router B ->Router F -> Router E,
and a RESV message is sent along Router E-> Router F -> Router B -> Router
A.
2)
When Router B receives the RESV message from Router F, it clears T2 and
sends a PathTear message to Router F and a ResvTear message to Router C.
If there is traffic on T2, clearing T2 will result in packet loss. To address the issue, you
can use the make-before-break mechanism to introduce a delay before clear actions.
11/30
This allows you to set up a path for T2 before it is cleared.
2.5 Tunnel Reoptimization

One of the major objectives of TE is to optimize traffic distribution on a network. It
allows network administrators to reoptimize the LSPs that have been established
based on changes in bandwidth, traffic, management policy, or other factors.
For a tunnel, reoptimization occurs when a better path, which means the smallest
metric/hop and less likelihood of being preempted, is found.
It is important not to interrupt service traffic during reoptimization. To this end, before
clearing an LSP tunnel, you must set up a new LSP tunnel so that the traffic can be
switched over to the new tunnel. The resources used by the old LSP tunnel therefore
cannot be released for the new tunnel on shared links. As the new tunnel cannot
share the resources of the old tunnel, failure may occur when setting up the new LSP
due to inadequate resources.
The shared-explicit (SE) reservation style of RSVP-TE well addresses the problem. In
SE style, the old and new LSP tunnels can share resources, so that you can set up
the new LSP tunnel without having to wait for the old LSP tunnel to be cleared when
resources are inadequate.
2.6 LSP Tunnel Backup

You may create a CR-LSP tunnel to backup another important CR-LSP tunnel so that
the backup one can take over when the primary one fails.
12/30
Figure 8 LSP and its backup
1. Primary LSP
The primary LSP is the desired optimal path. It is the object of tunnel backup. When it
fails, traffic is switched over to the backup LSP and the primary LSP reestablishment
is initiated.
2. Hot-standby LSP
A hot-standby LSP is established upon the establishment of a primary LSP. When the
ingress router receives a primary LSP failure message, it switches traffic to the hotstandby LSP. When the primary LSP recovers, the router switches traffic back.
The hot standby mechanism ensures fast switchover upon failure by establishing
extra LSPs. It is suitable for delay-sensitive services.
3. Ordinary backup LSP

An ordinary backup LSP is established only when the ingress router receives a
primary LSP failure message. After the backup LSP is successfully established, the
router switches traffic from the primary one to it.
With the ordinary backup mechanism, the backup tunnel travels a different path from
the primary link, bypassing all links that have failed. However, because in this
approach the backup tunnel is set up after the primary one has failed, the switch
13/30
speed is slower than that with the hot standby mechanism. For this reason, the
ordinary backup mechanism is suitable for delay-insensitive services.
2.7 FRR
2.7.1 Problems Solved by FRR
Fast reroute (FRR), also known as fast restoration, is a link and node protection
mechanism in MPLS TE.
In this approach, once a link or node fails on a path, FRR comes up to reroute the
path to a new link or node to bypass the failed link or node. This can happen as fast
as less than 50 milliseconds, a value tolerable by most delay-sensitive services like
VoIP, thus minimizing data loss. Once a link or node on an LSP configured with FRR
fails, traffic is switched to the protection link and the headend of the LSP starts
attempting to set up a new LSP.
Router A
Router C
Router E
Router G
Ingress
Egress
1
Router B
Router D
1
Router F
Router H
Figure 9 FRR
As shown in the above figure, the primary LSP travels the path Router A -> Router B > Router D -> Router F -> Router G. Tunnel Router A->Router C->Router D protects
node Router B and link Router ARouter B; tunnel Router B->Router C->Router F
protects node Router D and link Router BRouter D; and tunnel Router D->Router C>Router E->Router G protects node Router F and link Router DRouter F.
When link Router BRouter D fails, traffic travels path Router A->Router B->Router
C->Router F->Router G.
14/30

Router A
Router C
Router E
Router G
Ingress
Egress
1
Router B
Router D
1
Router F
Router H
Figure 10 Traffic switchover upon failure of link Router BRouter D
2.7.2 Switchover Time with FRR

How fast traffic switchover can happen with FRR depends on the following two
factors:
z
The time spent detecting a link/node failure. Link/node failure detection can be
performed in hardware or by sending RSVP hello messages, with the former
approach taking less time. In addition, detection on an SDH/SONET link is
faster than on a GE link and link failure detection is faster than node failure
detection.
The time actually spent switching traffic. How fast this could happen depends
on the CPU and system load.
2.7.3 Limits of FRR

FRR provides only temporary protection and no longer functions after the protected
link recovers. This is because FRR protection may cause congestion on other links
and be unable to provide adequate resources such as bandwidth.
Bypass tunnels do not provide protection for the headends and tailends of protected
LSPs. To do that, you can use LSP tunnel backup.
In addition, FRR may fail to remedy the situation where multiple links/nodes fail.
2.8 Automatic Bandwidth Adjustment

A certain amount of bandwidth is allocated to each LSP during its setup. The idea of
15/30
automatic bandwidth adjustment is to tune the bandwidth of the LSP tunnel based on
its history traffic statistics without affecting the ongoing service. The following
presents how the device tunes the bandwidth of an LSP.
The device makes sampling periodically, every 5 minutes for example, to obtain the
average bandwidth in a sampling interval. Based on the samplings in a certain period
(24 hours for example), the device calculates the maximum value and uses this value
as the bandwidth to initiate a new LSP tunnel. After this tunnel is set up, the device
switches traffic over to the tunnel and clears the old one. If the setup fails, traffic will
travel the old LSP and another adjustment attempt will be made at the end of the next
sampling interval.
To reduce the impact caused by adjustments, adjustment thresholds are introduced.
The idea is that an adjustment can be initiated only when the percentage of maximum
average bandwidth increase or decrease relative to the last maximum average
bandwidth crosses the up or down thresholds. In addition, you may set the maximum
and minimum bandwidth values to confine adjustments within the range.
2.9 Automatic Route Advertisement

Two approaches are available to automatic route advertisement: IGP shortcut and
forwarding adjacency. Both of them enable TE tunnel interfaces to participate in IGP
SPF calculation. For the headend of a TE tunnel, the TE tunnel is a directly
connected interface. You may assign this interface such a metric that it is regarded
the outgoing interface to the tailend of the TE tunnel. The CR-LSP in this case is
considered as a point-to-point link.
2.9.1 IGP Shortcut

In the IGP shortcut approach, routes with a CR-LSP TE tunnel interface as the
outgoing interface are not advertised to neighboring devices. Therefore, TE tunnels
are not visible or available to other devices.
2.9.2 Forwarding Adjacency

IGP shortcut is performed on a perrouter basis. Only the ingress router can use the
TE tunnel in IGP route calculation. In the scenario presented in the following figure,
16/30
LSP Router BRouter G can participate in IGP route calculation only on Router B,
because the LSP is unknown to the other routers. For this reason, Router A will use
the path Router A->Router C->Router E->Router G with the metric 30 to reach Router
G instead of the path Router A->LSP Router BRouter G with the metric 20.
Router A
Router C
Router E
10
10
Router G
10
Ingress
Egress
10
10
10
10
10
1
Router B
Router D
10
1
Router F
Router H
Figure 11 Automatic route advertisement
Unlike IGP shortcut, forwarding adjacency allows a router to advertise a CR-LSP as a

common LSA (or an IS-IS LSP) to its neighboring routers while using the CR-LSP as
the outgoing interface to the tailend router. As this link is unidirectional, a link in the
reverse direction from Router G to Router B must be created. On Router A, the IGP
route selected to reach Router G will then be Router A->LSP Router BRouter G.
2.10 MPLS L3/L2 VPN over TE

TE supports current mainstream MPLS L3VPN and L2VPN applications. TE tunnels
can serve as tunnels on the public network to provide bandwidth guarantee for VPN
users.
3 MPLS TE Implementation
The following four functions work together to implement MPLS TE:
z
Information advertisement, implemented via IS-IS/OSPF TE
Path selection, implemented via CSPF
LSP setup signaling, implemented via the RSVP TE/CR-LDP protocol
Data forwarding
17/30
Figure 12 Implementation framework of MPLS TE
3.1 Information Advertisement

In addition to network topology information, TE must learn the network links, TErelevant parameters, and network load information. For this purpose, the information
advertisement function was designed. The idea is to extend the existing IGP
protocols to advertise link state information, including the maximum link bandwidth,
maximum reservable bandwidth, reserved bandwidth, and link color. Such information
is flooded on the network through IGP and constitutes the traffic engineering
database (TEDB) on devices that need to perform CSPF calculation. A TEDB is
similar to the LSDB in OSPF. However, it contains not only network topology
information, but also link attribute information that TE concerns about. A device can
use its TEDB to monitor the status of TE-enabled links throughout the network and,
taking itself as the root node, CSPF calculate the constraint-based paths to
destination networks.
In the TE extension to OSPF, three types of Opaque LSAs (Type 9, Type 10, and
Type 11) are used to carry TE-relevant link attributes and to flood changes of the
attributes on an interface to all OSPF neighbors. Every LSR running TE will have a
TEDB as a result. Usually, LSA Type 10 is used for carrying and flooding extended
link attributes inside an area.
Like OSPF, IS-IS is extended to advertise TE information. An intermediate system (or
a router) advertises routes in link state protocol data units (LSPs) and uses some new
TLVs (type, length, value) to carry link information that are required for TE tunnel
establishment. Among these TLVs, Type 22 is an extension to the IS reachable TLV,
18/30
Type 134 is the TE Router ID TLV, and Type 135 is the extended IP reachable TLV.
IGP extensions maintain link and topology attributes on each router to form the TEDB
for constraint-based path calculation.
3.2 Path Selection

MPLS TE uses the CSPF algorithm to calculate paths that satisfy the bandwidth,
color, preemption, priority and explicit routing constraints.
CSPF is an enhanced shortest path first algorithm that takes specific constraints into
consideration. Based on resource availability and whether selected parts are against
the constraints of the user policy, CSPF first prunes nodes and links that do not
satisfy the constraints from the current topology. Then, it uses the SPF algorithm to
calculate the shortest path that satisfies the constraints, which is expressed by a
group of LSR addresses.
The following details the path calculation process:
z
Compare the links in the TEDB and prunes those that do not satisfy the
constraints, for example, bandwidth and color constraints.
Based on the new topology, use the SPF algorithm to calculate the shortest
path that satisfies the constraints of the LSP.
In case of a tie, select the path with the least hops.
If there is still more than one path, select one based on the load balancing
policy.
What the IS-IS SPF algorithm or OSPF SPF algorithm calculates are the shortest
paths to the next hops, and every router must run the SPF algorithm. As a contrast,
what the CSPF algorithm calculates are explicit paths that satisfy the constraints, and
usually only the ingresses of the LSPs to be established (the headends of the TE
tunnels) need to run the CSPF algorithm. On a TE headend, a route calculated by
CSPF is considered as a logical interface that leads to the destination (the tailend of
the TE tunnel).
The MPLS signaling protocol then signals the explicit path calculated by CSPF to the
downstream LSRs along the path to create a TE tunnel. After the TE tunnel is
19/30
established, IP packets taking this tunnel will be encapsulated with MPLS labels at
the ingress of the tunnel and then forwarded along the tunnel till they arrive the
egress of the tunnel.
3.3 Signaling Protocol

The signaling protocol reserves resources and establishes LSPs. Comware supports
static CR-LSP and two dynamic signaling protocols: RSVP-TE and CR-LDP. The two
dynamic signaling protocols use the downstream-on-demand (DoD) label distribution
mode and deliver functions such as setting up LSPs, explicit routing, and conveying
resources information.
3.3.1 RSVP-TE
1. Overview
The Resource Reservation Protocol (RSVP) is designed for the integrated service
model. It reserves resources on each node along a path. RSVP is an Internet control
protocol similar to ICMP. It operates at the transport layer but does not participate in
data transmission.
The RSVP extension, RSVP-TE, supports MPLS label distribution and allows
resource reservation information to be transmitted with label bindings. In MPLS TE,
RSVP-TE operates as a signaling protocol for LSP tunnel setup. It can implement the
following functions:
z
Establishing and maintaining TE LSPs.
Tearing down TE LSPs.
Notifying errors.
2. Basic Concepts
1)
Soft state
Soft state is a mechanism used by RSVP-TE to periodically refresh the resource

reservation state on a node.
The resource reservation state can be path state or reservation state. These two
states are regularly refreshed by Path messages and Resv messages respectively. A
20/30
state will be removed if no refresh message is received for it in certain interval, and
the TE LSP will be removed accordingly.
2)
Resource reservation style
Resource reservation style refers to the style in which the RSVP-TE protocol works
when establishing LSPs and reserving bandwidth.. The resource reservation style
that a TE LSP uses is decided by the initiator of the tunnel and implemented by every
node along the path through RSVP.
Currently, two reservation styles are available with the Comware Platform Software:
z
Fixed-filter style (FF) where resources are reserved for individual senders and
cannot be shared among the senders on the same session.
Shared-explicit style (SE) where resources are reserved for the senders on the
same session and shared among them.
At present, SE is only used for make-before-break.
3. Make-before-break
Make-before-break is a mechanism to change MPLS TE tunnel attributes with
minimum data loss and without extra bandwidth.
Figure 13 Make-before-break
The above figure presents a scenario where a path Router A->Router B->Router C>Router D is established with 30 Mbps of reserved bandwidth between Router A and
Router D. The remaining bandwidth is then 30 Mbps.
If 40 Mbps path bandwidth is requested, the remaining bandwidth of the Router A>Router B->Router C->Router D path will be inadequate. The problem cannot be
21/30
addressed by selecting another path, Router A->Router E->Router C->Router D,

because the bandwidth of the Router CRouter D link is inadequate.
To address the problem, you can use the make-before-break mechanism. It allows
the new path to share the bandwidth of the original path at the Router CRouter D
link. Upon creation of the new path, traffic is switched to the new path and the
previous path is torn down.
4. RSVP-TE messages
RSVP-TE uses RSVP messages with extensions. The following are RSVP messages:
z
Path messages: transmitted along the path of data transmission downstream by

each RSVP sender to save path state information on each node along the path.
Resv messages: sent by each receiver upstream towards senders to request

resource reservation and to create and maintain reservation state on each node
along the reverse of data transmission path.
PathTear messages: sent downstream immediately after being created to

remove the path state and related reservation state on each node along the
path.
ResvTear messages: sent upstream immediately after being created to remove

the reservation state on each node along the path.
PathErr messages: sent upstream to report Path message processing errors to

senders. They do not affect the state of the nodes along the path.
ResvErr messages: sent downstream to notify the downstream nodes that error
occurred during Resv message processing or reservation error occurred as the
result of preemption.
ResvConf messages: sent to receivers to confirm Resv messages.
The TE extension to RSVP adds new objects to the Path message and the Resv
message. These objects carry not only label bindings but also routing constraints to
support CR-LSP and FRR.
5. LSP tunnel establishment

Figure 14shows how to set up an LSP tunnel with RSVP-TE:
22/30
Figure 14 Set up an LSP with RSVP-TE signaling
The following is a simplified procedure for setting up an LSP tunnel with RSVP-TE:
1)
CSPF on the ingress LSR calculates a path for the CR-LSP based on the
constraints such as specified path segments, bandwidth, and link color.
2)
The ingress LSR sends a Path message towards the egress LSR. This
message contains the bandwidth reservation information and the path
calculated for the CR-LSP.
3)
The LSRs that the Path message traverses along the path create the PSB as
required.
4)
After receiving the Path message, the egress LSR sends back a Resv message
carrying the resource reservation and label binding information towards the
ingress LSR. The LSRs that the Resv message traverses along the path
reserve resources and create the RSB as required.
5)
When the ingress LSR receives the Resv message, the CR-LSP is established.
As resources are reserved on the LSRs along the path for the LSP established using
RSVP-TE, services transmitted on the LSP are guaranteed.
6. LSP tunnel maintenance

As RSVP is a soft state protocol, it needs to send messages called Refresh
messages periodically to maintain paths and reservation states, that is, to implement
LSP tunnel maintenance.
The Refresh messages are not new messages, but messages that have been
advertised before. The main information in a Refresh message and the path that the
Refresh message travels must be match those of the original message exactly.
23/30
Refresh messages can only be used to refresh Path messages and Resv messages.
Message refreshing between nodes along a CR-LSP path is independent, that is, it
does not need the ingress LSR or egress LSR to send messages periodically to
trigger.
As Refresh messages are periodically sent, when many RSVP sessions are present,
there may be many Refresh messages, increasing the burden of the network. In
addition, for some delay-sensitive applications, the refreshing delay they must wait for
recovering lost RSVP messages may be intolerable. As tuning refresh intervals is not
adequate to address the two problems, the refreshing mechanism was extended as
follows to address the problems:
1)
Message_ID extension
RSVP itself uses Raw IP to send messages. The Message_ID extension mechanism
adds objects that can be carried in RSVP messages. Of them, the Message_ID
object and the Message_ID_ACK object are used to acknowledge RSVP messages,
thus improving transmission reliability.
On an interface enabled with the Message_ID mechanism, you may configure RSVP
message retransmission. After the interface sends an RSVP message, it waits for
acknowledgement. If no ACK has been received before the initial retransmission
interval (Rf seconds for example) expires, the interface resends the message. After
that, the interface resends the message at an exponentially increased retransmission
interval equivalent to (1 + Delta) Rf seconds until an ACK is received or the rapid
retry limit RI is reached.
2)
Summary refresh extension
Send summary refreshes (Srefreshes) rather than retransmit standard Path or Resv
messages to refresh related RSVP state. This reduces refresh traffic and allows
nodes to make faster processing.
You may enable summary refresh extension on the interfaces that connect two
neighboring routers to improve their performance.
To use summary refresh, you must use the Message_ID extension. Only states
advertised using MESSAGE_ID-included Path and Resv messages can be refreshed
using summary refreshes.
24/30
3.3.2 CR-LDP
The Constraint-Based Routed Label Distribution Protocol (CR-LDP) is an extension to
LDP. It is used in conjunction with MPLS to perform constraint-based routing. Unlike
common LSPs, which are calculated simply based on the routing table or
administratively configured, CR-LSPs are calculated at the network edges based on
criteria in addition to routing information. This allows other TE attributes such as
bandwidth and color to be considered during LSP calculation.
The following figure shows how a CR-LSP is set up with CR-LDP.
Figure 15 Set up a CR-LSP with CR-LDP
LDP session setup and LDP session state machine maintenance are similar to those
in LDP.
As shown in the figure:
1)
The LDP protocol establishes LDP sessions between LSRs.
2)
The ingress LSR calculates a path for the CR-LSP tunnel through CSPF based
on the explicit route, bandwidth, link color and other constraints.
3)
The LSR then creates a label request message with the TLVs that convey the
bandwidth reservation and path information, and sends it to the downstream
LSR on the calculated path.
4)
After receiving the label request message, the downstream LSR forwards the
message to its downstream LSR based on the TLVs in the message. This
message travels along the path until it reaches the egress.
25/30
5)
When receiving the message, the egress confirms the resource reservation and
sends a mapping message to the upstream.
6)
The mapping message travels upstream to reserve resources on each node

along the path. When it reaches the ingress, the CR-LSP is set up.
3.4 Data Forwarding

In MPLS, once an LSP is established, traffic arriving at the ingress will be forwarded
along the LSP. A packet could be mapped to a label binding based on certain criteria.
Those associated with the same label binding are regarded as belonging to the same
forwarding equivalence class (FEC). Normally, packets are mapped to FECs based
on network layer destination addresses. Packets in the same FEC are processed in
the same way in the MPLS network.
Similarly, in MPLS TE, the packets to be forwarded along the same tunnel are
regarded as belonging to the same FEC. Currently, three forwarding approaches are
available. They are static routing, policy-based routing (PBR), and automatic route
advertisement (IGP shortcut and forwarding adjacency).
1. Static Routing
Static routing is the easiest way to route traffic down an MPLS TE tunnel to its
destination. You only need to specify a static route pointing down the tunnel interface
at the headend of the tunnel.
2. PBR
You can also use policy-based routing to forward traffic down a TE tunnel. To this end,
you need to do these at the headend of the tunnel:
z
First, create an ACL to define the traffic that should travel along this tunnel.
Then, create a policy referencing the ACL to specify the TE tunnel interface as
the outgoing interface for the traffic matching the ACL.
Finally, apply the policy on the incoming interface.
3. IGP shortcut and forwarding adjacency

IGP shortcut and forwarding adjacency, two approaches to automatic route
26/30
advertisement, advertise TE tunnel interfaces to the IGP to participate in IGP route

calculation, allowing all traffic towards the tailend of a tunnel to be forwarded along
the tunnel. For details, refer to Automatic Route Advertisement.
4 Application Scenarios
4.1 Bandwidth Guarantee
You may provide per-service bandwidth guarantee between two nodes by
establishing multiple tunnels between the nodes.
As shown in the following figure, there are data and voice services between the
ingress and the egress. To guarantee the bandwidth required by voice service, you
can set up a TE tunnel dedicated to voice service and have data service travel other
paths to avoid congestion.
Figure 16 Bandwidth guarantee with MPLS TE
As shown in the figure, two links are available between the ingress and the egress.
Tunnel 2 is set up on a low-delay link to convey voice service while Tunnel 1 is set up
to convey data service.
4.2 Protection Function

z
You can use FRR to protect the crucial nodes or links on a network, as shown
in the following figure.
27/30

Router A
Router C
Router E
Router G
Ingress
Egress
1
Router B
Router D
1
Router F
Router H
Figure 17 Protection with FRR
Set up a backup tunnel to protect a path in conjunction with MPLS OAM. As

shown in the following figure, you may use Tunnel 1 as the backup of Tunnel 2
so that Tunnel 1 can take over when Tunnel 2 fails.
Ingress
Egress
Tunnel 1
Tunnel 2
Figure 18 Protection with setup tunnels
4.3 Integration of TE Tunneling and MPLS VPN

You can use TE tunnels in an MPLS L2VPN or MPLS L3VPN over the public network
to provide services with guaranteed bandwidth. In addition, you may use TE tunnels
to separate VPN services to provide differentiated bandwidth guarantee and QoS.
See the following two figures.
28/30
Figure 19 VPN over TE
Figure 20 VPN over TE (inter-domain)
5 References
z
RFC 2205: Resource ReSerVation Protocol (RSVP) Version 1 Functional

Specification
RFC 2209: Resource ReSerVation Protocol (RSVP) -- Version 1 Message

Processing Rules
RFC 3209: RSVP-TE: Extension to RSVP for LSP Tunnels
RFC 3210: Applicability Statement for Extension to RSVP for LSP Tunnels
RFC 3212: Constraint-Based LSP Setup Using LDP
RFC 3213: Applicability Statement for CR-LDP
RFC 3214: LSP Modification Using CR-LDP
RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels
RFC 2747: RSVP Cryptographic Authentication
29/30

z
RFC 2961: RSVP Refresh Overhead Reduction Extensions
Copyright 2008 Hangzhou H3C Technologies Co., Ltd. All rights reserved.
No part of this manual may be reproduced or transmitted in any form or by any means without prior written consent of
The information in this document is subject to change without notice.
30/30

MPLS TE Technology White Paper

Uploaded by

Copyright:

Available Formats

MPLS TE Technology White Paper

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MPLS TE Technology White Paper

Uploaded by

Copyright:

Available Formats

MPLS TE Technology White Paper