3.2.7 Feature Description - MPLS

HUAWEI CX600 Metro Services Platform
V600R003C00
Feature Description - MPLS

Issue
02
Date
2011-09-10
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2011. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute the warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address:
Huawei Industrial Base

Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website:
http://www.huawei.com
Email:
support@huawei.com
Issue 02 (2011-09-10)
Huawei Proprietary and Confidential

Copyright Huawei Technologies Co., Ltd.

About This Document
About This Document

Purpose
This document describes the MPLS feature in terms of its overview, principle, and applications.
This document together with other types of document helps intended readers get a deep
understanding of the MPLS feature.
Related Versions
The following table lists the product versions related to this document.
Product Name
Version
HUAWEI CX600 Metro

Services Platform
V600R003C00SPC300
Intended Audience
This document is intended for:
l
Network planning engineers
Commissioning engineers
Data configuration engineers
System maintenance engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol
Description
DANGER
Issue 02 (2011-09-10)
Indicates a hazard with a high level of risk, which if not

avoided, will result in death or serious injury.

ii

Symbol
About This Document
Description
WARNING
CAUTION
Indicates a hazard with a medium or low level of risk, which

if not avoided, could result in minor or moderate injury.
Indicates a potentially hazardous situation, which if not
avoided, could result in equipment damage, data loss,
performance degradation, or unexpected results.
TIP
Indicates a tip that may help you solve a problem or save

time.
NOTE
Provides additional information to emphasize or supplement

important points of the main text.
Change History
Updates between document issues are cumulative. Therefore, the latest document issue contains
all updates made in previous issues.
Changes in Issue 02 (2011-09-10)

Second commercial release.
Changes in Issue 01 (2011-06-30)

Initial field trial release.
Issue 02 (2011-09-10)

iii

Contents
Contents
About This Document.....................................................................................................................ii
1 MPLS Overview.............................................................................................................................1
1.1 Introduction to MPLS.........................................................................................................................................2
1.2 References..........................................................................................................................................................2
1.3 Principles............................................................................................................................................................3
1.3.1 Concepts....................................................................................................................................................3
1.3.2 Establishing LSPs....................................................................................................................................10
1.3.3 MPLS Forwarding...................................................................................................................................12
1.3.4 MPLS Ping/Traceroute............................................................................................................................17
1.4 Applications......................................................................................................................................................19
1.4.1 MPLS-based VPN...................................................................................................................................19
1.4.2 PBR to an LSP.........................................................................................................................................20
1.5 Terms and Abbreviations..................................................................................................................................21
2 MPLS LDP.....................................................................................................................................24
2.1 Introduction to LDP..........................................................................................................................................25
2.2 References........................................................................................................................................................25
2.3 Principles..........................................................................................................................................................25
2.3.1 Concepts..................................................................................................................................................26
2.3.2 LDP Sessions...........................................................................................................................................27
2.3.3 Advertising and Managing Labels...........................................................................................................28
2.3.4 Establishment of LDP LSP......................................................................................................................31
2.3.5 LDP Extension for Inter-Area LSP.........................................................................................................31
2.3.6 Outbound and Inbound LDP Policies......................................................................................................33
2.3.7 LDP-IGP Synchronization.......................................................................................................................34
2.3.8 Synchronization Between LDP and Static Routes..................................................................................36
2.3.9 LDP GR...................................................................................................................................................37
2.3.10 LDP NSR...............................................................................................................................................38
2.3.11 LDP FRR...............................................................................................................................................38
2.3.12 LDP MTU..............................................................................................................................................40
2.3.13 LDP MD5..............................................................................................................................................41
2.3.14 LDP Authentication...............................................................................................................................41
2.3.15 Distributing Labels for BGP by LDP....................................................................................................42
Issue 02 (2011-09-10)

iv

Contents
2.3.16 LDP over TE..........................................................................................................................................45

2.3.17 LDP GTSM............................................................................................................................................46
2.3.18 Coexistence of the Local and Remote LDP Sessions............................................................................47
2.3.19 Distributing Labels for All Peers by LDP.............................................................................................48
2.4 Terms and Abbreviations..................................................................................................................................49
3 MPLS TE........................................................................................................................................51
3.1 Introduction to MPLS TE.................................................................................................................................52
3.2 References........................................................................................................................................................56
3.3 Principles..........................................................................................................................................................57
3.3.1 RSVP-TE.................................................................................................................................................58
3.3.2 Make-Before-Break.................................................................................................................................59
3.3.3 P2MP RSVP-TE......................................................................................................................................60
3.3.4 Automatic Bandwidth Adjustment..........................................................................................................63
3.3.5 Re-optimization.......................................................................................................................................64
3.3.6 TE FRR....................................................................................................................................................65
3.3.7 SRLG.......................................................................................................................................................69
3.3.8 CR-LSP Backup......................................................................................................................................70
3.3.9 DS-TE......................................................................................................................................................75
3.3.10 Static Bidirectional Co-routed LSP.......................................................................................................87
3.3.11 TE Tunnel Protection Group.................................................................................................................88
3.3.12 BFD for TE CR-LSP.............................................................................................................................90
3.3.13 BFD for TE Tunnel................................................................................................................................92
3.3.14 RSVP Authentication............................................................................................................................93
3.3.15 RSVP GR...............................................................................................................................................94
3.3.16 RSVP Summary Refresh.......................................................................................................................95
3.3.17 RSVP Hello...........................................................................................................................................96
3.3.18 BFD for RSVP.......................................................................................................................................97
3.3.19 TE LSP Configuration Template...........................................................................................................97
3.3.20 Multi-Area Advertisement of an MPLS LSR-ID..................................................................................99
3.4 Terms and Abbreviations................................................................................................................................100
4 MPLS OAM................................................................................................................................102
4.1 Introduction to MPLS OAM...........................................................................................................................103
4.2 References......................................................................................................................................................103
4.3 Principles........................................................................................................................................................104
4.3.1 MPLS OAM Detection..........................................................................................................................104
4.3.2 Reverse Tunnel......................................................................................................................................106
4.3.3 MPLS OAM Auto Protocol...................................................................................................................106
4.3.4 Protection Switching..............................................................................................................................107
4.4 Terms and Abbreviations................................................................................................................................108
Issue 02 (2011-09-10)


1 MPLS Overview
MPLS Overview
About This Chapter

1.1 Introduction to MPLS
1.2 References
1.3 Principles
1.4 Applications
1.5 Terms and Abbreviations
Issue 02 (2011-09-10)


1 MPLS Overview
1.1 Introduction to MPLS

Background of MPLS
The Internet based on the IP technology prevailed in the middle 1990s. The IP technology,
however, performs poorly in forwarding packets because of inevitable software dependence on
searching routes through the longest match algorithm. As a result, the forwarding capability of
IP technology becomes a bottleneck to the network development.
With the evolvement of network technologies, the Asynchronous Transfer Mode (ATM)
technology comes out. It uses labels (namely, cells) of fixed length and maintains a label table
that is much smaller than a routing table. Therefore, compared with the IP technology, the ATM
technology performs much better in forwarding packets. The ATM technology, however, is
difficult to popularize because of its complex protocol and high cost in deployment.
The traditional IP technology is simple and costs little in deployment. People then are eager to
making a technical breakthrough to combine advantages of IP and ATM technologies. Thus, the
MPLS technology comes forth.
Initially, MPLS emerges to increase the forwarding rate of devices. Different from IP routing
in forwarding packets, MPLS analyzes a packet header only on the network edge but not at each
hop. In this manner, the time to process packets is shortened.
The application specific integrated circuit (ASIC) technology is developed and the routing rate
is no longer a bottleneck of the network development. As a result, MPLS does not have
advantages in high-speed forwarding any more. MPLS supports multi-layer labels, and its
forwarding plane is connection-oriented. Thus, MPLS is widely used in Virtual Private Network
(VPN), traffic engineering (TE), and Quality of Service (QoS).
Introduction to MPLS
MPLS works between the data link layer and the network layer in the TCP/IP protocol stack. It
provides the IP layer with connection services and obtains services from the data link layer.
MPLS replaces IP forwarding with label switching. A label is a short connection identifier of
fixed length that is meaningful for the local end. The label is similar to the ATM virtual path
identifier (VPI)/virtual channel identifier (VCI) and the Frame Relay data link connection
identifier (DLCI). The label is encapsulated between the data link layer and the network layer.
MPLS is not limited by any specific protocol of the data link layer and is enabled to use any
Layer 2 media to transfer packets.
The origin of MPLS is the Internet Protocol version 4 (IPv4). The core MPLS technology can
be extended to multiple network protocols, such as the Internet Protocol version 6 (IPv6), Internet
Packet Exchange (IPX), Appletalk, DECnet, and Connectionless Network Protocol (CLNP).
Multiprotocol in MPLS means that the protocol supports multiple network protocols.
In fact, the MPLS technology is a tunneling technology rather than a service or an application.
It supports multiple protocols and services. Moreover, it can ensure the security for data
transmission.
1.2 References
Issue 02 (2011-09-10)


1 MPLS Overview
The following table lists the references of this document:

Document No.
Description
RFC 3031
Multiprotocol Label Switching Architecture
RFC 3036
LDP Specification
RFC 3032
MPLS Label Stack Encoding
RFC 3443
Time To Live (TTL) Processing in Multi-Protocol Label

Switching (MPLS) Networks
RFC 3034
Use of Label Switching on Frame Relay Networks

Specification
RFC 2702
Requirements for Traffic Engineering Over MPLS
RFC 3209
RSVP-TE: Extensions to RSVP for LSP Tunnels
RFC 2547
BGP/MPLS VPNs
1.3 Principles
1.3.1 Concepts
MPLS Network Structure
Figure 1-1 shows the typical structure of an MPLS network. The fundamental element of an
MPLS network is Label Switching Router (LSR). Many LSRs on a network form an MPLS
domain. LSRs that reside at the edge of an MPLS domain and connect to other networks are
Label Edge Routers (LERs). LSRs within an MPLS domain are core LSRs. If an LSR connects
to one or more adjacent nodes that do not run MPLS, the LSR is the LER. If all the adjacent
nodes of an LSR run MPLS, the LSR is the core LSR.
Issue 02 (2011-09-10)


1 MPLS Overview
Figure 1-1 MPLS network structure
LER
MPLS network
Non- MPLS
network
Non- MPLS
network
Core LSR Core LSR

LER
LER
Core LSR
Core LSR
Non- MPLS
network
Non- MPLS
network
LER
LER
The transfer of packets in the MPLS domain is based on labels. When IP packets enter an MPLS
network, the LER at the entrance analyzes IP packets and then adds proper labels to them. All
nodes on the MPLS network forward data according to labels. When IP packets leave the MPLS
network, the labels are deleted on the LER that is the exit.
The path that IP packets pass through on an MPLS network is called the LSP. An LSP is a
unidirectional path in the same direction with the data flow.
Figure 1-2 MPLS LSP
MPLS network
Ingress
Non-MPLS
network
Transit
Transit
Egress
Non-MPLS
network
LER
Core LSR
Core LSR
LER
LSP
The beginning node of an LSP is called the ingress. The end node of the LSP is called the egress.
The nodes between both ends along the LSP are transits. An LSP may have none, one, or several
transit(s), but only one ingress and one egress.
Issue 02 (2011-09-10)


1 MPLS Overview
Forwarding Equivalence Class

The forwarding equivalence class (FEC) is a set of data flows with the same attributes. These
data flows are processed in the same way by LSRs during transmission.
FECs can be identified by the address, service type, and QoS. For example, during IP forwarding
according to the longest match algorithm, packets with the same destination belong to an FEC.
Label
A label is a short identifier of a fixed length that is only meaningful for the local end. It is used
to uniquely identify an FEC to which a packet belongs. In some cases such as load balancing,
an FEC can be mapped to multiple incoming labels, but one label only represents one FEC on
a device. The label is a connection identifier, similar to the ATM VPI/VCI and the Frame Relay
DLCI.
A label is 4 bytes long. Figure 1-3 shows the encapsulation structure of the label.
Figure 1-3 Structure of the MPLS packet header
A label contains the following fields:

l
Label: indicates the value field of a label. The length is 20 bits.
Exp: indicates the bits used for extension. The length is 3 bits. Generally, this field is used
for the Class of Service (CoS) that serves similarly to Ethernet 802.1p.
S: identifies the bottom of a label stack. The length is 1 bit. MPLS supports multiple labels,
namely, the label nesting. When the S field is 1, it means that the label is at the bottom of
the label stack.
TTL: indicates the time to live. The length is 8 bits. This field is the same as the TTL in IP
packets.
Labels are encapsulated between the data link layer and the network layer. Thus, labels can be
supported by all protocols of the data link layer.
Figure 1-4 shows the position of the label in a packet.
Figure 1-4 Position of the label in a packet
Label Space
Label space means the range of label values. In the CX600 implementation, the label space is
classified as follows:
l
Issue 02 (2011-09-10)
0 to 15: indicates special labels. For details about special labels, see Table 1-1.

1 MPLS Overview
16 to 1023: indicates the label space shared by static LSPs and static CR-LSPs.
1024 or above: indicates the label space for dynamic signaling protocols, such as LDP,
RSVP-TE, and MP-BGP.
The label space for dynamic signaling protocols is independent and successive but cannot
be shared or affect each other. Label space for dynamic signaling protocols is defined by
the license file on the device. To change the label space, you need to modify the license
file.
Table 1-1 Special labels
Issue 02 (2011-09-10)
Label Value
Label
Description
IPv4 Explicit
NULL Label
Indicates that the label must be popped out, and the packets
must be forwarded on the basis of IPv4. If the egress
allocates a label whose value is 0 to the penultimate hop,
the penultimate hop LSR needs to push label 0 to the top
of a label stack and forward the packet to the egress. When
the egress finds that the value of the label carried in the
packet is 0, the egress pops out the label. The label 0 is
valid only at the bottom of the label stack.
Router Alert
Label
Indicates a label that is only valid when it is not at the

bottom of a label stack. The label is similar to the Router
Alert Option field in IP packets. When the node receives
such a label, the label is sent to a local software module
for further processing. The packet forwarding is
determined by the next layer label. If the packet needs to
be forwarded continuously, the node needs to push the
Router Alert Label to the top of the label stack again.
IPv6 Explicit
NULL Label
Indicates that the label must be popped out, and the packets
must be forwarded on the basis of IPv6. If the egress
allocates a label whose value is 2 to the penultimate hop,
the penultimate hop LSR needs to push label 2 to the top
of a label stack and forward the packet to the egress. When
the egress finds that the value of the label carried in the
packet is 2, the egress pops out the label directly. The label
2 is valid only at the bottom of the label stack.
Implicit
NULL Label
When the label whose value is 3 is swapped on the

penultimate hop LSR, the penultimate hop LSR pops out
the label and forwards the packet to the egress. After the
egress receives the packet, the egress forwards the IP
packet or the VPN packet.
4 to 13
Reserved
None.
14
OAM Router
Alert Label
Indicates a label for the packets of Operation

Administration and Maintenance (OAM) over an MPLS
network. MPLS OAM sends OAM packets to detect LSPs
and notify faults. OAM packets are transparent on transits
and the penultimate LSR.
15
Reserved
None.


1 MPLS Overview
Label Stack
A label stack is a set of arranged labels. An MPLS packet can carry multiple labels at the same
time. The label next to the Layer 2 header is called the top label or the outer label. The label next
to the Layer 3 header is called the bottom label or inner label. Theoretically, MPLS labels can
be nested limitlessly.
Figure 1-5 Label stack
The label stack organizes labels according to the rule of Last-in, First-Out. The labels are
processed from the top of the stack.
Label Operations
Information about the basic label operations is a part of the label forwarding table. The operations
are described as follows:
l
Push: When an IP packet enters an MPLS domain, the ingress adds a new label to the packet
between the Layer 2 header and the IP header; or, an LSR adds a new label to the top of
the label stack, namely, the label nesting.
Swap: When a packet is transferred within an MPLS domain, the local node swaps the label
at the top of the label stack in the MPLS packet for the label allocated by the next hop
according to the label forwarding table.
Pop: When a packet leaves an MPLS domain, the label is popped out from the MPLS packet;
or, the top label of the label stack is popped out at the penultimate hop on an MPLS network
to decrease the number of labels in the stack.
Penultimate Hop Popping

In fact, the label is useless at the last hop of an MPLS domain. In this case, the feature of
penultimate hop popping (PHP) is applied. On the penultimate node, the label is popped out of
the packet to reduce the size of the packet that is forwarded to the last hop. Then, the last hop
directly forwards the IP packet or forwards the packet by using the second label.
PHP is configured on the egress. In addition, the egress only allocates the following label to the
PHP:
Label 3: indicates the implicit-null label. This label is not listed in the label stack. When an LSR
receives an implicit-null label, the LSR pops out the label in the packet rather than uses this
implicit-null label to replace the label at the top of the label stack. The egress directly forwards
the packet through an IP link or according to the next layer label.
Issue 02 (2011-09-10)


1 MPLS Overview
Label Switching Router

A Label Switching Router (LSR) refers to devices that can swap labels and forward MPLS
packets. It is also called the MPLS node. The LSR is a fundamental element on an MPLS
network. All LSRs support the MPLS protocol.
LER
An LER is the LSR that resides on the edge of an MPLS domain. When an LSR connects to one
node that does not run MPLS, the LSR acts as the LER.
The LER classifies the packets entering an MPLS domain by FECs and pushes labels into FECs.
Then, the LER forwards MPLS packets based on labels. When packets leave the MPLS domain,
the labels are popped out. The packets become IP packets again and are forwarded continuously.
Label Switched Path

The path that an FEC passes through in the MPLS network is called the LSP.
An LSP functions similarly to virtual circuits of ATM and Frame Relay. The LSP is a
unidirectional path from the ingress to the egress.
Ingress, Transit, and Egress LSRs

The LSP is a unidirectional path. LSRs along an LSP can be classified as follows:
l
Ingress LSR: indicates the beginning of an LSP. Only one ingress exists on an LSP.
The ingress pushes a new label to the packet and encapsulates the IP packet as an MPLS
packet to forward.
Transit LSR: indicates the middle node of an LSP. Multiple transit LSRs may exist on an
LSP.
The transit LSR mainly searches routes in the label forwarding table. Then, it swaps labels
to complete the forwarding of MPLS packets.
Egress LSR: indicates the end node of an LSP. Only one egress exists on an LSP.
The egress mainly pops labels out of MPLS packets and forwards the packets that restore
the IP packet.
Upstream and Downstream

According to the direction of data transmission, LSRs are classified as follows:
l
Upstream: Based on the specified LSR, in the direction of data flows, the LSRs that send
MPLS packets to the local LSR are upstream LSRs.
Downstream: Based on the specified LSR, in the direction of data flows, the next-hop LSRs
that receive MPLS packets sent from the local LSR are downstream LSRs.
As shown in Figure 1-6, the data flows to 192.168.1.0/24. LSR A is the upstream LSR of LSR
B and the LSR B is the downstream of LSR A. Likely, LSR B is the upstream LSR of LSR C.
LSR C is the downstream LSR of LSR B.
Issue 02 (2011-09-10)


1 MPLS Overview
Figure 1-6 Upstream and downstream
192.168.1.0/24
LSR-A
Downstream
data flow
LSR-B
Downstream
data flow
LSR-C
Label Distribution
Packets with the same destination address belong to an FEC. A label out of an MPLS label
resource pool is allocated to the FEC. LSRs record the relationship of the label and the FEC.
Then, LSRs send a message and advertises to upstream LSRs about the label and FEC
relationship in message. The process is called label distribution.
Figure 1-7 Schematic diagram of the label distribution
Labels are
distributed upstream
LSR-A
Data flow
downstream
Labels are
distributed upstream
LSR-B
Data flow
downstream
192.168.1.0/24
LSR-C
As shown in Figure 1-7, LSR B and LSR C use an FEC respectively to identify packets with
the destination address as 192.168.1.0/24. Then, labels are allocated to FECs and their
relationship is advertised to upstream LSRs. Thus, labels are allocated by the downstream LSRs.
Label Distribution Protocols

Label distribution protocols are MPLS control protocols, namely, signaling protocols. They are
used to classify FECs, distribute labels, and create and maintain LSPs.
MPLS utilizes multiple label distribution protocols, such as Label Distribution Protocol (LDP),
Resource Reservation Protocol Traffic Engineering (RSVP-TE), and Multiprotocol Border
Gateway Protocol (MP-BGP).
MPLS Architecture
The MPLS architecture consists of a control plane and a forwarding plane.
Figure 1-8 shows the MPLS architecture.
Issue 02 (2011-09-10)


1 MPLS Overview
Figure 1-8 Schematic diagram of the MPLS architecture
Control Plane
IP Routing Protocol
Routing Information
Base (RIB)
Label Information Base
(LIB)
MPLS IP Routing
Protocol
Forwarding Plane
Label Forwarding
Information Base(LFIB)
The control plane is connectionless and responsible for distributing labels, creating the label
forwarding table, and creating or deleting LSPs.
The forwarding plane, also known as the data plane, is connection-oriented. It can apply
services and protocols of ATM, Frame Relay, and Ethernet networks. The forwarding plane
is mainly responsible for adding labels to and deleting labels from IP packets.
Simultaneously, it forwards the received packets according to the label forwarding table.
1.3.2 Establishing LSPs

Procedure of Establishing LSPs
Usually, MPLS allocates labels for packets and establish an LSP. Then, MPLS can forward
packets.
Labels are allocated and distributed by a downstream LSR to an upstream LSR. As shown in
Figure 1-9, the downstream LSR classifies FECs according to an IP routing table and then
allocates labels to specific FECs. Then, the downstream LSR notifies the upstream LSR through
label advertisement protocols to set up a label forwarding table and an LSP.
Figure 1-9 Establishment of an LSP
To 3.3.3.3/32
Label=Z
Ingress
To 3.3.3.3/32
Label=Y
Transit
To 3.3.3.3/32
Label=3
Transit
Egress
3.3.3.3/32
Issue 02 (2011-09-10)

10

1 MPLS Overview
The classification of LSPs is as follows:

l
Static LSP: It is set up by the administrator.
Dynamic LSP: It is set up by the routing protocol and label distribution protocol.
Establishing Static LSPs

You can allocate labels manually to set up static LSPs. The principle is that the value of the
outgoing label of the upstream node is equal to the value of the incoming label of the downstream
node.
The availability of a static LSP makes sense only for the local node that cannot sense the entire
LSP.
l
On the ingress: A static LSP is configured, and the outgoing interface of the ingress is
enabled with MPLS. If the route is reachable, the state of the static LSP is Up regardless
of the existence of the transit or egress. A reachable route means that a route entry exists
whose destination address and the next hop address match those in the local routing table.
On the transit: A static LSP is configured, and the incoming and outgoing interfaces of the
transit are enabled with MPLS. If the incoming and outgoing interfaces are Up on the
physical layer and protocol layer, the static LSP is Up, regardless the existence of the
ingress, egress, or other transits.
On the egress: A static LSP is configured, the incoming interface of the egress is enabled
with MPLS. If the incoming interface is Up on the physical layer and protocol layer, the
static LSP is Up, regardless the existence of the ingress or the transit.
NOTE
A reachable route is required on the ingress only for setting up a static LSP, but not on the transit or egress.
A static LSP is set up without label distribution protocols or exchanging control packets. Thus,
the static LSP costs little and it is applicable to small-scale networks with simple and stable
topology. The static LSP cannot vary with the network topology dynamically. The administrator
needs to configure the static LSP.
Establishing Dynamic LSPs

Dynamic LSPs are set up automatically by the label distribution protocol. The following label
distribution protocols are applicable to an MPLS network.
l
LDP
The Label Distribution Protocol (LDP) is specially defined for distributing labels. When
LDP sets up an LSP in hop-by-hop mode, LDP identifies the next hop along the LSP
according to the routing forwarding table on each LSR. Information contained in the routing
forwarding table is collected by IGP and BGP. LDP is not directly assotiated with routing
protocols, but indirectly uses routing information.
LDP is not the only label distribution protocol. BGP and RSVP can also be extended to
distribute MPLS labels.
RSVP-TE
The Resource Reservation Protocol (RSVP) is designed for the integrated service module
and is used to reserve resources on nodes along a path. RSVP works on the transport layer
and does not transmit application data. RSVP is a network control protocol, similar to the
Internet Control Message Protocol (ICMP).
Issue 02 (2011-09-10)

11

1 MPLS Overview
RSVP is extended to support the setting up of a Constraint-based Routed LSP (CR-LSP).

The extended RSVP is called the RSVP-TE signaling protocol. It is used to set up TE
tunnels.
Different from LDP LSPs, RSVP-TE tunnels are characteristic as follows:
Bandwidth reservation requests
Bandwidth constraint
Link colors
Explicit paths
l
MP-BGP
The Multiprotocol Extensions for BGP (MP-BGP) is an extended protocol of BGP. MPBGP imports the community attribute. MP-BGP supports label distribution for MPLS VPN
routes and labeled inter-AS VPN routes.
1.3.3 MPLS Forwarding

Basic Concepts of MPLS Forwarding
l
Tunnel ID
To provide the same interface of a tunnel used by upper layer applications such like the
VPN and route management, the system automatically allocates an ID to each tunnel,
namely, tunnel ID. The tunnel ID is valid locally.
The tunnel ID is in a length of 32 bits. The length of the fields varies according to tunnel
types.
Figure 1-10 shows the structure of a tunnel ID.
Figure 1-10 Structure of a tunnel ID
The description of each field is as follows.

Table 1-2 Description of each field of a tunnel ID
Issue 02 (2011-09-10)
Field
Description
Token
Indicates the field that is used to search an MPLS forwarding

table for specified MPLS forwarding entries. The token is an
index number for searching forwarding information.
Sequence Number
Indicates the sequence number of a tunnel ID.
Slot Number
Indicates the slot number of an outgoing interface sending

packets.

12

1 MPLS Overview
Field
Description
Tunnel Type
Indicates the type of a tunnel. The tunnel types of MPLS are as

follows:
l LSP: indicates the LSP tunnel that is set up dynamically
through LDP without any constraints.
l CRLSP: indicates the LSP tunnel that is set up dynamically
through CR-LDP or RSVP-TE with constraints.
l MPLS Local IFNET: indicates the tunnel that is set up by the
External BGP (EBGP) on MPLS interfaces of AS Boundary
Routers (ASBRs).
On inter-AS VPN Option B and Option C, besides information
on L2VPN label blocks, VPN routing information sent from an
ASBR to the BGP peer must contain tunnel information. No
tunnel, however, is set up between ASBRs. Thus, the MPLS local
IFNET tunnel is required between ASBRs to send AS-external
routing information to the peer within the AS.
Allocation Method
Indicates the method to allocate tokens. The methods are as

follows:
l Global: All tunnels share the same public global token space.
Two tokens cannot have the same value.
l Global with reserved tokens: This method is similar to the
global method. Differently, this method can reserve tokens
that tunnels cannot use. That is, the token of the tunnel begins
at a specified value.
l Per slot: Each slot has independent tokens. Tokens in the
same slot are different and tokens of different slots may be
the same.
l Per slot with reserved tokens: This method is similar to the
per slot method. Differently, this method can reserve tokens
that tunnels cannot use. That is, the token of a tunnel begins
at a specified value.
l Per slot with different avail value: This method is similar to
the per slot method. Differently, the token values of different
slots range differently.
l Mixed: Space can be created in either Global method or Per
slot method. The method to be selected depends on the
interface type. For the VLANIF or the interface of a backbone
network, the global method is adopted. Otherwise, the per slot
method is adopted.
l Mixed with 2 global space: Space can be created in global
space 1 method, global space 2 method, and per slot method.
l 2 global space: Space can be created in global space 1 method
and global space 2 method.
NOTE
The allocation method adopted by devices depends on license files.
Issue 02 (2011-09-10)

13

1 MPLS Overview
NHLFE
The next hop label forwarding entry (NHLFE) can guide the MPLS packet forwarding.
An NHLFE contains the following information.
Tunnel ID
Outgoing interface
Next hop
Outgoing label
Label operation
ILM
The incoming label map (ILM) indicates the mapping between an incoming label and a set
of NHLFEs.
The ILM contains the following information.
Tunnel ID
incoming label
incoming interface
Label operation
The ILM on a transit can bind the labels to NHLFEs. The function of an ILM table is similar
to the FIB that is searched according to destination IP addresses. Thus, you can obtain all
label forwarding information from searching an ILM table.
FTN
FTN is a short form of FEC-to-NHLFE. The FTN indicates the mapping between an FEC
and a set of NHLFEs.
Details about the FTN can be obtained by searching the token values that are not 0x0 in a
FIB. The FTN is available on the ingress only.
Process of MPLS Forwarding

Take the LSP that supports the PHP as an example to describe how MPLS packets are forwarded.
Figure 1-11 MPLS label distribution and packet forwarding
To 3.3.3.3/32
Label=Z
Ingress
Label distributing
Packet transmitting
To 3.3.3.3/32
Label=Y
Transit
To 3.3.3.3/32
Label=3
Transit
Egress
3.3.3.3/32
PHP
Label=Z
Label=Y
IP Packet
IP Packet
IP Packet
IP Packet
To 3.3.3.3 PUSH To 3.3.3.3 SWAP To 3.3.3.3 POP To 3.3.3.3
Ingress
Issue 02 (2011-09-10)
Transit
Transit

IP Packet
To 3.3.3.3
Egress
3.3.3.3/32
14

1 MPLS Overview
As shown in Figure 1-11, an LSP whose FEC is identified by the destination address 3.3.3.3/32
is set up on an MPLS network. MPLS packets are forwarded as follows:
1.
The ingress receives an IP packet destined for 3.3.3.3/32. Then, the ingress adds Label Z
to the packet and then forwards the packet.
2.
The transit receives the labeled packet and swaps labels by popping Label Z out and pushing
Label Y into the packet.
3.
The transit at the penultimate hop receives the packet with Label Y. The value of Label 3
is allocated by the egress. The transit performs the PHP to pop out Label Y and forwards
the packet. From the penultimate hop to the egress, the packet is transmitted as an IP packet.
4.
Then, the egress receives the IP packet and forwards it to 3.3.3.3/32.
MPLS Forwarding Flow

When an IP packet enters an MPLS domain, the ingress searches the FIB to check whether the
tunnel ID corresponding to the destination IP address is 0x0.
l
If the tunnel ID is 0x0, the packet is forwarded along the IP link.
If the tunnel ID is not 0x0, the packet is forwarded along an LSP.
Figure 1-12 shows the MPLS forwarding flow.

Figure 1-12 MPLS forwarding flow
Ingress
NHLFE
FIB
FEC
Transit
Tunnel ID
ILM
Tunnel ID
Next Hop
OutLabel
Operation
Out Interface
Next Hop
OutLabel Operation
NHLFE
InLabel Tunnel ID
Egress
Out Interface
Tunnel ID
ILM
InLabel
MPLS packets are forwarded as follows on nodes along an LSP.

1.
The ingress searches the FIB and NHLFE tables to forward MPLS packets.
2.
The transit searches the ILM and NHLFE tables to forward MPLS packets.
3.
The egress searches the ILM table to forward MPLS packets.
During the MPLS forwarding, FIB entries, ILM entries, and NHLFEs are associated with each
other through the token field in the tunnel ID.
l
Forwarding on the Ingress

The ingress processes as follows to forward MPLS packets:
Issue 02 (2011-09-10)

15

1 MPLS Overview
1.
Searches the FIB and finds the tunnel ID corresponding to the destination IP address.
2.
Finds the NHLFE corresponding to the tunnel ID in the FIB and associates the FIB
entry with the NHLFE entry.
3.
Checks the NHLFE for information about the outgoing interface, next hop, outgoing
label, and label operation type. The label operation type is Push.
4.
Pushes the obtained label into IP packets, processes the EXP field according to QoS
policy and the TTL field, and then sends the encapsulated MPLS packets to the next
hop.
Forwarding on the Transit

The transit processes as follows to forward the received MPLS packets:
1.
Checks the ILM table corresponding to an MPLS label and finds the token.
2.
Finds the NHLFE corresponding to the token in the ILM table.
3.
Checks the NHLFE for information about the outgoing interface, next hop, outgoing
label, and label operation type.
4.
MPLS packets are processed distinctively according to the specific label value.
If the label value is equal to or greater than 16, a new label replaces the label in
the MPLS packet. At the same time, the EXP field and TTL field are processed.
Then, the MPLS packet with the new label is forwarded to the next hop.
If the label value is 3, the label is popped out from the MPLS packet. At the same
time, the EXP field and TTL field are processed. Then, the packet is forwarded
through IP routes or according to its next layer label.
Forwarding on the Egress

When the egress receives MPLS packets, the egress checks the ILM table for the label
operation type. At the same time, the egress processes the EXP field and TTL field.
When the S field in the label is equal to 1, the label is the stack bottom label and the
packet is directly forwarded through IP routes.
When the S field is equal to 0 in the label, a next layer label exists and the packet is
forwarded according to the next layer label.
Processing MPLS TTL

An MPLS label has a TTL field in the length of 8 bits. The TTL field is the same as that in an
IP packet header. MPLS processes the TTL to prevent loops and implement traceroute.
RFC 3443 defines two modes in which MPLS processes the TTL, that is, uniform mode and
pipe mode. By default, MPLS processes the TTL in Uniform mode.
l
Uniform Mode
When IP packets enter an MPLS network, on the ingress, the IP TTL decreases by one and
is mapped to an MPLS TTL field. Then, the TTL field in MPLS packets is processed in
the standard mode. As shown in Figure 1-13, on the egress, the MPLS TTL decreases by
one and is mapped to the IP TTL field.
Issue 02 (2011-09-10)

16

1 MPLS Overview
Figure 1-13 TTL process in Uniform mode
MPLS
MPLS
TTL 254
IP TTL
254
IP TTL
255
PE
CE
PE
MPLS
TTL 253
IP TTL
254
CE
IP TTL
252
Pipe Mode
As shown in Figure 1-14, on the ingress, the IP TTL decreases by one and the MPLS TTL
is constant. Then, MPLS TTL is processed in the standard mode. On the egress, IP TTL
decreases by one. That is, when IP packets enter an MPLS network, the IP TTL only
decreases by one respectively on the ingress and egress.
Figure 1-14 TTL process in Pipe mode
MPLS
CE
PE
IP TTL
255
MPLS
TTL 100
MPLS
TTL 100
IP TTL
254
PE
MPLS
TTL 99
MPLS
TTL 100
IP TTL
254
CE
IP TTL
253
1.3.4 MPLS Ping/Traceroute

Issue 02 (2011-09-10)

17

1 MPLS Overview
Overview
On an MPLS network, when data fails to be transmitted across an LSP, the MPLS control plane
cannot detect the transmission failure. Thus, the network maintenance is difficult to carry out.
MPLS ping and MPLS traceroute functions provide a mechanism to detect LSP faults and locate
the failed node timely.
MPLS ping is used to test the network connectivity and the host accessibility. MPLS traceroute
is used to check the network connectivity and locate network faults.
Similar to the IP ping and IP traceroute, the MPLS ping and the MPLS traceroute detect the LSP
availability through MPLS Echo Request and MPLS Echo Reply messages. These two messages
are sent through UDP. The port number is 3503. Thus, the receiver can recognize theses two
messages according to the received UDP port number.
The MPLS Echo Request message contains information about the FEC of the LSP to be detected.
The message is sent like other packets that belong to the FEC along the LSP. In this manner, the
LSP is detected. The MPLS Echo Request message is forwarded to the destination by MPLS;
the MPLS Echo Reply message is forwarded to the source through an IP link.
The destination address in the IP header of the Echo Request message is set to 127.0.0.1/8 and
the IP TTL is set to 1. This can prevent the egress from forwarding the message to other nodes.
MPLS Ping
Figure 1-15 MPLS network
5.5.5.5/32
4.4.4.4/32
LSP
1.1.1.1/30
CX-A
1.1.1.2/30
2.2.2.1/30
CX-B
2.2.2.2/30
3.3.3.1/30
CX-C
3.3.3.2/30
CX-D
As shown in Figure 1-15, an LSP whose FEC is identified with the destination being CX-D is
set up on CX-A. CX-A uses the MPLS ping feature to detect the LSP as follows:
1.
CX-A checks whether the LSP exists. For a TE tunnel, CX-A checks whether the tunnel
interface exists and whether a CR-LSP is set up successfully. If the LSP does not exist, an
error message is returned and CX-A stops pinging. If the LSP exists, CX-A performs the
following actions continuously.
2.
CX-A constructs an MPLS Echo Request packet. The destination address is 127.0.0.1/8 in
the IP packet header and the IP TTL is set to 1. CX-A searches the corresponding LSP and
pushes a label (its TTL is 255) of the LSP into the packet. Then, CX-A sends the packet to
CX-B.
3.
CX-B and CX-C that serve as transits forward the MPLS Echo Request packet as a common
MPLS packet.
If a transit fails to forward the packet, the transit returns a reply message carrying the error
code.
Issue 02 (2011-09-10)

18

4.
1 MPLS Overview
When the MPLS forwarding path works normally, transits forward the packet successfully
to CX-D, namely, the egress of the LSP. CX-D processes the packet and replies with an
MPLS Echo Reply packet.
MPLS Traceroute
As shown in Figure 1-15, CX-A uses the MPLS traceroute feature to detect an LSP with the
destination address 4.4.4.4/32 as follows:
1.
CX-A checks whether an LSP exists.

l If the LSP exists, CX-A performs the following actions continuously.
l If the LSP does not exist, an error message is returned and CX-A stops tracing the route.
2.
CX-A constructs an MPLS Echo Request packet. The destination address is 127.0.0.1/8 in
the IP packet header and the IP TTL is 1. CX-A searches for a corresponding LSP and
pushes a label (its TTL is 1) of the LSP into the packet. Then, CX-A sends the packet to
CX-B. CX-B receives this packet and the TTL of the label times out. Then, an MPLS Echo
Reply message is returned. The destination UDP port and the destination IP address of the
MPLS Echo Reply message is the source UDP port and the source IP address of the MPLS
Echo Request packet. In additional, the IP TTL is 255.
3.
After receiving the MPLS Echo Reply message, CX-A sends an MPLS Echo Request
packet. The TTL of the label is 2. CX-B forwards this packet as a common MPLS packet.
CX-C receives this packet and the TTL of the label times out. Then, an MPLS Echo Reply
message is returned.
If a transit fails to forward the packet, no MPLS Echo Reply message is returned.
4.
After receiving the MPLS Echo Reply message, CX-A sends an MPLS Echo Request
packet. The TTL of the label is 3. CX-B and CX-C forward this packet as a common MPLS
packet. CX-D receives the packet and finds that the destination address of the packet is a
local loop IP address. Then, CX-D returns an MPLS Echo Reply message.
1.4 Applications
1.4.1 MPLS-based VPN
The traditional VPN can transmit data of private networks over the public network through
tunneling protocols, such as the Generic Routing Encapsulation (GRE), Layer 2 Tunneling
Protocol (L2TP), and Point to Point Tunneling Protocol (PPTP).
The MPLS-based VPN can be a private network whose security is similar to that of the FR
network. Because packets are not encapsulated or encrypted, the IPSec technology and GRE or
L2TP tunnels are not required on the device. In addition, the network delay is minimized.
As shown in Figure 1-16, the MPLS-based VPN integrates private network branches through
an LSP to form a unified network. The MPLS-based VPN controls the interconnection between
VPNs. Figure 1-16 shows the devices applied in the MPLS-based VPN.
l
Customer Edge (CE) is an edge device in a customer network. The CE can be a router, a
switch, or a host.
Provider Edge (PE) is an edge device on a service provider network.
Issue 02 (2011-09-10)

19

1 MPLS Overview
Provider (P) is a backbone device on an SP network. A P is not directly connected to CEs.

Ps only need to possess basic MPLS forwarding capabilities and do not maintain
information about a VPN.
Figure 1-16 MPLS-based VPN
CE3
VPN
branch 3
PE3
CE1
VPN
branch 1
PE1
Backbone network
PE2
CE2
VPN
branch 2
The characteristics of MPLS-based VPN are as follows:

l
PEs are responsible for managing VPN users, setting up LSPs between PEs, and allocating
routes to sites of a VPN.
The route allocation between PEs are implemented by LDP or MBGP.
The MPLS-based VPN supports the IP address multiplexing between sites and the
interconnection of different VPNs.
1.4.2 PBR to an LSP

The policy-based routing (PBR) means to select a route according to a user-defined policy for
security and load balancing. The CX600 supports the PBR to an LSP. In an MPLS network, IP
packets that meet the filtering policy can be forwarded through a specified LSP.
In Figure 1-17, CX-A, CX-B, CX-C, CX-D, and CX-E are in the original network. CX-F and
CX-G are added to provide new services. The traffic is forwarded as follows:
l
The traffic for original services is forwarded through the original network.
The traffic for new services is forwarded by CX-F and CX-G.
Issue 02 (2011-09-10)

20

1 MPLS Overview
Figure 1-17 Application of the PBR to an LSP
CX-B
CX-A
CX-D
CX-C
CX-F
CX-E
CX-G
To forward part of the traffic of new services through the original network, you can configure
the PBR to an LSP on CX-A. In this manner, the traffic meeting the specific policy can be
forwarded through the original network.
You can also use the PBR to the LSP together with LDP FRR to divert some traffic to the backup
LSP for load balancing when the backup LSP may be idle relatively.

Terms
Issue 02 (2011-09-10)
Terms
Explanation
Label space
A value range of labels.
ILM
The incoming label map (ILM) indicates the

mapping between an incoming label and a set
of NHLFEs. The ILM contains the following
information: Tunnel ID, incoming label and
incoming interface.
LDP peer
Two LSRs with an LDP session that use LDP

to exchange label or FEC mapping
information.
LDP identifier
A value that is used to identify a specified

LSR label space.

21

1 MPLS Overview
Terms
Explanation
NHLFE
The next hop label forwarding entry

(NHLFE) can guide the MPLS packet
forwarding. An NHLFE contains the
following information: Tunnel ID, outgoing
interface, next hop, outgoing label and label
operation.
PHB
PHB describes how the packets with the same

DSCP value are forwarded to the next hop.
The PHB records certain traffic attributes,
such as latency and packet loss ratio. At
present, the IETF defines three standardized
PHBs, that is, expedited forwarding (EF),
assured forwarding (AF), and best-effort
(BE). The BE is the default PHB.
Control plane
The control plane is connectionless and

responsible for distributing labels, creating
the label forwarding table, and creating or
deleting LSPs.
Forwarding plane
The forwarding plane, also known as the data

plane, is connection-oriented. It can apply
services and protocols of ATM, Frame Relay,
and Ethernet networks. The forwarding plane
is mainly responsible for adding labels to and
deleting labels from IP packets.
Simultaneously, it forwards the received
packets according to the label forwarding
table.
Abbreviation
Issue 02 (2011-09-10)
Abbreviation
Full Spelling
DoD
Downstream-on-Demand
DU
Downstream Unsolicited
LSP
Label switched path
FEC
ILM
Incoming Label Map
LAM
Label Advertisement Mode
LDP
Label Distribution Protocol
LER
Label Edge Router
LFIB
Label Forward Information Base

22

Issue 02 (2011-09-10)
1 MPLS Overview
Abbreviation
Full Spelling
LSP
Label Switched Path
LSR
Label Switching Router
MPLS
Multiprotocol Label Switching
NHLFE
Next Hop Label Forwarding Entry
PHP
Penultimate Hop Popping

23

2 MPLS LDP
MPLS LDP
About This Chapter

2.1 Introduction to LDP
2.2 References
2.3 Principles
Issue 02 (2011-09-10)

24

2 MPLS LDP
2.1 Introduction to LDP

Definition
Label Distribution Protocol (LDP) is a control protocol of Multiprotocol Label Switching
(MPLS). It is like a signaling protocol of a traditional network. It classifies Forwarding
Equivalence Classes (FECs), distributes labels, and establishes and maintains the Label
Switched Path (LSP). In addition, LDP defines the messages in and procedures for distributing
labels.
Purpose
MPLS supports multiple labels and its forwarding plane is connection-oriented, and thus this
excellent scalability enables the MPLS/IP-based network to provide various services. Through
LDP, Label Switching Routers (LSRs) directly map routing information at the network layer to
the switched paths at the data link layer, and thus establish LSPs at the network layer. LDP
features simple networking and configurations, supports route topology-driven establishment of
LSPs, and supports large-capacity LSPs, and thus is widely used to provide VPN services.
2.2 References
The following table lists the references of this document:
Document
Description
Remarks
RFC5036
LDP Specification
Does not support loop detection.
RFC3215
LDP State Machine
RFC5443
LDP IGP Synchronization
Supports all messages except the

end-of-lib message.
RFC3478
Graceful Restart Mechanism

for Label Distribution Protocol
RFC1321
The MD5 Message-Digest

Algorithm
RFC3037
LDP Applicability
RFC3988
Maximum Transmission Unit

Signalling Extensions for the
2.3 Principles
Issue 02 (2011-09-10)

25

2 MPLS LDP
2.3.1 Concepts
The MPLS architecture involves multiple label distribution protocols, of which LDP (Label
Distribution Protocol) is widely used.
LDP defines the messages of label distribution and procedures for processing the messages.
LSRs associated by the incoming labels, next hop nodes, and outgoing labels for a specified
forwarding equivalence class (FEC) according to local forwarding table; thus LSPs are formed.
For details about LDP, refer to LDP Specification in RFC 5036.
LDP Adjacency
When an LSR receives a Hello message from the peer, it indicates that an LDP peer may exist.
Under this situation, the LSR will create an LDP adjacency for maintaining the existence of the
peer. There are two types of LDP adjacencies: the local adjacency and remote adjacency.
LDP Peers
LDP peers refer to two LSRs that use LDP to set up an LDP session and then exchange Label
messages.
LDP peers learn the labels of each other through LDP session between them.
LDP Sessions
In an LDP session, LSRs exchange messages such as Label Mapping and releasing. LDP sessions
are classified into the following types:
l
Local LDP session: an LDP session between the two LSRs that are directly connected.
Remote LDP session: an LDP session between the two LSRs that are directly or indirectly
connected.
Local and remote LDP sessions can exist together.
LDP Dynamic Capability Announcement Function

The LDP dynamic capability announcement function allows an LDP extension to be dynamically
enabled or disabled on a device during an LDP session is working, ensuring the stability of an
LSP.
Relationships Between LDP Adjacencies, Peers, and Sessions

LDP maintains the existence of peers by using adjacencies. The type of peers depends on the
type of corresponding adjacencies. A peer can be maintained by multiple adjacencies. If a peer
is maintained by both local and remote adjacencies, the type of the peer supports coexistence of
the local and remote adjacencies. An LDP session can be established only when peers are present.
Type of LDP Messages

LDP messages have the following types:
l
Discovery message: used to notify or maintain the existence of an LSR on a network.
Session message: used to establish, maintain, and terminate sessions between LDP peers.
Issue 02 (2011-09-10)

26

2 MPLS LDP
Advertisement message: used to create, modify, and delete label mappings for FECs.
Notification message: used to provide advisory information and error information.
To ensure the reliability of message transmission, LDP uses the TCP transport for Session,
Advertisement, and Notification messages and uses the UDP transport for transmitting the
Discovery message only.
Label Spaces and LDP Identifiers

l
Label space
Label space refers to the value range of labels that are distributed for LDP peers. The types
are as follows:
Per-Platform Label Space: indicates that the entire LSR uses one label space.
Per-Interface Label Space: indicates that each interface of the LSR is assigned with a
label space.
LDP ID
The LDP identifier identifies the range of the label space of a specified LSR. The format
is <LSR ID>:<Label space ID>. The length is 6 bytes. Where,
LSR ID: indicates the LSR identifier and is of 4 bytes.
Label space ID: indicates the identifier of the label space, with a length of 2 bytes.
2.3.2 LDP Sessions

LDP Discovery Mechanism
The LDP discovery mechanism is used by an LSR to discover potential LDP peers. LDP
discovery mechanisms are classified into the following types:
l
Basic discovery mechanism: used to discover directly-connected LSR peers on a link.

An LSR periodically sends LDP Hello messages to implement the basic discovery
mechanism and establish a local LDP session.
The Hello message contains the LDP identifier and other information (such as the hold time
and transport address). If the LSR receives an LDP Hello message on an interface, it
indicates that LDP peers are connected to the interface.
Extended discovery mechanism: used to discover indirectly-connected LSR peers on a link.

The LSR periodically sends Targeted Hello messages to a specified address to implement
the extended discovery mechanism and establish a remote LDP session.
The Targeted Hello message, a UDP message, is sent to the specified address to LDP
interface 646. The Targeted message contains the LDP identifier and other information
(such as the transport address and hold time). If the LSR receives a Targeted Hello message
on an interface, it indicates that LDP peers are connected to the interface.
Procedures for Establishing an LDP Session

Two LSRs send Hello messages to each other to trigger the establishment of an LDP session.
Figure 2-1 shows the procedures for establishing an LDP session.
Issue 02 (2011-09-10)

27

2 MPLS LDP
Figure 2-1 Procedures for establishing an LDP session
LSR-B (passive role)

192.168.1.1/32
LSR-A (active role)

192.168.1.2/32
Step1
Step2
Step3
Step4
Step5
Hello message
TCP Connection
The actor sends an Initialization
message to negotiate about parameters
When the parameters are received,
an Initialization message and a
Keepalive message are sent
When the parameters are received,
a Keepalive message is sent
1.
Two LSRs send a Hello message to each other. The Hello message contains the transport
address that the two parties use to establish an LDP session. The role with the larger
transport address starts to establish a TCP connection as the active role. As shown in Figure
2-1, LSRA starts to establish the TCP connection as the active role and LSRB waits for the
TCP connection as the passive role.
2.
After the TCP connection is successfully established, the active role LSRA sends an
Initialization message to negotiate parameters used for establishing the LDP session with
the passive role. These parameters include the LDP version, label distribution mode, value
of the Keepalive timer, maximum length of the PDU, and label space.
3.
After receiving the Initialization message, if the passive role LSRB rejects certain
parameters, it sends a Notification message to terminate the establishment of the LDP
session. If the passive role LSRB accept all parameters, it sends an Initialization message
and a Keepalive message to the active role LSRA.
4.
After receiving the Initialization message, if the active role LSRA cannot accept certain
parameters, it sends a Notification message to the passive role LSRB to terminate the
establishment of the LDP session. If the active role LSRB can accept all parameters, it
sends a Keepalive message to the passive role LSRB.
After both the two parties receives the Keepalive message from each other, the LDP session is
successfully established.
2.3.3 Advertising and Managing Labels

After the LDP session is established, an LDP exchanges messages, such as the label mapping
message, to establish LSP. RFC 5036 defines the label advertisement mode, label distribution
control mode, and label retention mode to determine how the LSR advertises and manages labels.
The CX600 supports the combination of the following modes:
Issue 02 (2011-09-10)

28

2 MPLS LDP
Combination of the DU label advertisement mode, ordered label control mode, and liberal
label retention mode
Combination of the DoD label advertisement mode, ordered label control mode, and
conservative label retention mode
Label Advertisement Mode

On an MPLS network, an LSR distributes labels for FECs and notifies its upstream LSRs of the
distributed labels. That is, labels are distributed from downstream to upstream on the MPLS
network.
Label advertisement modes are as follows:
l
DU label advertisement mode

Downstream Unsolicited (DU): An LSR distributes a label for an FEC without having to
receive the Label Request message from its upstream LSR.
As shown in Figure 2-2, for the FEC destined for 192.168.1.1/32, the establishment of the
LSP is triggered in host mode. The egress sends an unsolicited Label Mapping message to
the upstream transit node to advertise the label of the host route to 192.168.1.1/32.
Figure 2-2 DU mode
Distribute labels
upstream voluntarily
Ingress
Distribute labels
upstream voluntarily 192.168.1.1/32
Transit
Egress
Downstream on Demand
Downstream on Demand (DoD): An LSR distributes labels for FECs after receiving an
Label Request messages from its upstream LSRs.
As shown in Figure 2-3, the downstram egress triggers the establishment of an LSP
destined for the FEC 192.168.1.1/32 in host mode. The upstream ingress sends the Label
Request message, the downstream egress receives this message, and then sends the Label
Mapping message to the downstream.
Figure 2-3 DoD mode
The upstream requests The upstream requests the

the downstream for labels
downstream for labels
Ingress
Issue 02 (2011-09-10)
Transit
192.168.1.1/32
Egress
The label is
distributed after the
request is received

29

2 MPLS LDP
The label advertisement mode on an upstream LSR and that on an downstream LSR must be
consistent.
Label Distribution Control Mode

The label distribution control mode refers to the processing mode used by an LSR when the LSR
distributes labels during the setup of an LSP.
The label distribution control modes are classified into the following modes:
l
Independent label distribution control

Independent label distribution control refers to that a local LSR can distribute a label bound
to a FEC and then inform the upstream LSR, without waiting for the label distributed by
the downstream LSR.
As shown in Figure 2-2, if the label distribution mode is DU and the label distribution
control mode is Independent, the transit LSR distributes labels for the ingress without
waiting for labels of the egress.
As shown in Figure 2-3, if the label distribution mode is DoD and the label distribution
control mode is Independent, the directly-connected transit of the ingress that sends the
Label Request message directly replies with labels without waiting for labels of the
egress.
Ordered label distribution control

Ordered label distribution control: An LSR advertises the mapping between a label and a
FEC to its upstream LSRs only when it is the outgoing node of the FEC or when it receives
the Label Mapping message of the next hop for the FEC.
As shown in Figure 2-2, the label distribution mode is DU and the label distribution
control mode is ordered. Consequently, the LSR (transit in the diagram) must receive
a label mapping message from the downstream (egress in the diagram). Then, it can
distribute a label to the upstream (ingress in the diagram).
As shown in Figure 2-3, if the label distribution mode is DoD and the label distribution
control mode is Ordered, the directly-connected transit of the ingress that sends the
Label Request message must receive a label mapping message from the downstream
(egress in the diagram). Then, it can distribute a label to the upstream (ingress in the
diagram).
Label Retention Mode

The label retention mode refers to the way an LSR handles processes the label mapping that it
receives but does not use in a short time.
The label mapping that an LSR receives maybe from the next hop, maybe not.
The label retention modes are classified into the following modes:
l
Liberal label retention mode

An LSR preserves the Label Mapping message received from a neighbor LSR regardless
of whether the neighbor LSR is its next hop or not.
Conservative label retention mode

An LSR retains the label mapping received from a neighbor LSR only when the neighbor
LSR is its next hop.
When the next hop of an LSR changes due to change of the network topology:
Issue 02 (2011-09-10)

30

2 MPLS LDP
If the LSR uses the liberal label retention mode, it can use the previous labels sent from the
non-next hop to fast re-establish an LSP (For the information about establishment of LDP
LSP , refer to Establishment of LDP LSP). This requires more memory and label spaces
than the conservative mode.
If the LSR uses the conservative label retention mode, it retains only labels received from
the next hop. This saves memory and the label space but the LSP is re-set up slowly.
Conservative label retention mode is usually used together with DoD on the LSRs that have
limited label spaces.
The LSP is distributed with a label but not established successfully called Liberal LSP.
2.3.4 Establishment of LDP LSP

The LSP establishment is the process of binding an FEC with the label and advertising the
binding relationship to LSRs on the LSP. The procedures for establishing an LSP in DU label
distribution mode and ordered label control mode are described as follows:
1.
When the route of the network changes, if a label edge router (LER) finds a new destination
address in its routing table and the address does not belong to any existing FEC, the LER
creates an FEC for the address.
2.
If the egress of an MPLS network has available labels for distribution, it distributes labels
for FECs and actively sends the Label Mapping message to the ingress. The Label Mapping
message contains distributed labels and bound FECs.
3.
After receiving the Label Mapping message, the LSR adds mapping to its label forwarding
table and then actively sends the Label Mapping message of the specified FEC to the ingress
LSR.
4.
After receiving the Label Mapping message, the ingress LSR also adds the mapping to its
label forwarding table. An LSP is thus established, and the packets classified as the FEC
can be forwarded on the basis of the label.
2.3.5 LDP Extension for Inter-Area LSP

This feature enables LDP to establish inter-area LDP LSPs to provide tunnels that traverse the
public network.
Issue 02 (2011-09-10)

31

2 MPLS LDP
Figure 2-4 Networking topology of LDP Extension for Inter-Area LSP
Loopback0
1.3.0.1/32
Loopback0
1.1.0.1/32
GE1/0/0
10.1.1.1/24
LSRA
IS-IS
Area20
/1
Loopback0 E1/0 /24 /0 LSRB
1
1.2.0.1/32 G .1.1. E1/0 /24
G .1 .2
20
.1
IS-IS
20
GE
Area10
20 1/
.1. 0/2
GE1/0/0
2.1
10.1.1.2/24 LSRD
/24
Loopback0
1.3.0.2/32
GE
20 1/
.1. 0/0
2.2
/24
LSRC
As shown in Figure 2-4, there are two IGP areas, Area 10 and Area 20.
In the routing table of LSRD at the edge of Area 10, there are two host routes to LSRB and
LSRC. Generally, to prevent a large number of routes from occupying too many resources, on
LSRD, you can use IS-IS to aggregate the two routes to one route 1.3.0.0/24 and send this route
to Area 20. Consequently, there is only one aggregated route (1.3.0.0/24) but not 32-bit host
routes in the routing table of LSRA. By default, when establishing LSPs, LDP searches the
routing table for the route that exactly matches the forwarding equivalence class (FEC) in the
received Label Mapping message. Table 2-1 shows routing entry information of LSRA and
routing information carried in FEC in the situation as shown in Figure 2-4.
Table 2-1 Routing entry information of LSRA and routing information carried in FEC
Routing entry information
of LSRA
FEC
1.3.0.0/24
1.3.0.1/32
1.3.0.2/32
LDP establishes liberal LSPs rather than inter-area LDP LSPs for aggregated routes. In this
situation, LDP cannot provide required backbone network tunnels for VPN services.
Therefore, in the situation as shown in Figure 2-4, you need to configure LDP to search for
routes according to the longest match rule to establish LSPs. There is already an aggregated
route 1.3.0.0/24 in the routing table of LSRA. When LSRA receives a Label Mapping message
Issue 02 (2011-09-10)

32

2 MPLS LDP
(such as the carried FEC is 1.3.0.1/32) from Area 10, LSRA searches for a route according to
the longest match rule defined in RFC 5283. Then, LSRA finds information about the aggregated
route 1.3.0.0/24, and uses the outbound interface and next hop of this route as those of the route
1.3.0.1/32. In this manner, LDP can establish inter-area LDP LSPs.
2.3.6 Outbound and Inbound LDP Policies

By default, an LSR receives and sends label mapping messages for all FECs, resulting in the
establishment of a large number of LDP LSPs. The establishment of a large number of LDP
LSPs consumes a great amount of system resources of an LSR, and as a result, the LSR may be
overburdened. In this case, an outbound or inbound LDP policy needs to be configured to reduce
the number of label mapping messages to be sent or received, reducing the number of LSPs to
be established and saving memory.
Outbound LDP Policy

The outbound LDP policy filters label mapping messages to be sent. The outbound LDP policy
does not take effect with L2VPN label mapping messages, which means that all the L2VPN
label mapping messages can be sent. In addition, the ranges of FECs to which the labeled BGP
routes and non-BGP routes are mapped can be configured separately.
If FECs in the label mapping messages to be sent to an LDP peer group or all LDP peers are in
the same range, the same outbound policy is applicable to the LDP peer group or all LDP peers.
In addition, the outbound LDP policy supports split horizon. After split horizon is configured,
an LSR distributes labels only to its upstream LDP peers.
An LSR checks whether an outbound policy mapped to the labeled BGP route or non-BGP route
is configured before sending a label mapping message for a FEC.
l
If no outbound policy is configured, the LSR sends the label mapping message.
If an outbound policy is configured, the LSR checks whether the FEC in the label mapping
message is within the range defined in the outbound policy. If the FEC is within the FEC
range, the LSR sends a label mapping message for the FEC; if the FEC is not in the FEC
range, the LSR does not send a label mapping message.
If the FEC to which the route mapped fails to pass any outbound policy, no transit LSP or egress
LSP can be established.
Inbound LDP Policy

The inbound LDP policy filters label mapping messages to be received. The inbound LDP policy
does not take effect with L2VPN label mapping messages, which means that all the L2VPN
label mapping messages can be received. In addition, the range of FECs to which the non-BGP
routes are mapped is configurable.
If FECs in the label mapping messages to be received by an LDP peer group or all LDP peers
are in the same range, the same inbound policy is applicable to the LDP peer group or all LDP
peers.
An LSR checks whether an inbound policy mapped to a FEC is configured before receiving a
label mapping message for the FEC.
l
If no inbound policy is configured, the LSR receives the label mapping message.
If an inbound policy is configured, the LSR checks whether the FEC in the label mapping
message, is within the range defined in the inbound policy. If the FEC is within the FEC
Issue 02 (2011-09-10)

33

2 MPLS LDP
range, the LSR receives the label mapping message for the FEC; if the FEC is not in the
FEC range, the LSR does not receive the label mapping message.
If the FEC fails to pass any outbound policy on an LSR, the LSR receives no label mapping
message for the FEC.
In this case, one of the following results may occur:
l
If a DU LDP session is established between an LSR and its peer, a liberal LSP is established.
In addition, this liberal LSP cannot function as a backup LSP after LDP FRR is enabled.
If a DoD LDP session is established between an LSR and its peer, the LSR sends a Release
message to tear down label-based bindings.
2.3.7 LDP-IGP Synchronization

LDP-IGP synchronization is a technique that synchronizes IGP convergence and LDP
convergence by suppressing the advertisement of IGP routes, ensuring that traffic is not
interrupted.
On a network comprising primary and backup links, the following situations may occur:
l
If a primary link fails, traffic following IGP routes and along an LSP switches to a backup
link. After the primary link recovers, an IGP converges faster than LDP. IGP traffic
switches back to the primary link before LDP converges. This causes traffic on the LSP to
be discarded.On a network deployed with LDP over TE, traffic on the LSP first switches
to a physical link and then immediately to a backup link, leading to LSP flapping.
When a primary LSP transmits traffic properly and an LDP session between nodes along
the primary LSP fails, IGP traffic is still transmitted along the primary link, but traffic on
the LSP over the primary link is deleted. An LSP cannot be established on the backup link,
on which there is no IGP route. As a result, traffic on the LSP is discarded.On a network
deployed with LDP over TE, a route may switch first to an associated tunnel. After the cost
value of the tunnel is set to the maximum value, traffic switches to the backup link, leading
to LSP flapping.
When a master/slave switchover is performed, an IGP may complete the GR process and
then advertise the maximum cost value of link before an LDP session is established, leading
to route flapping.
Principles of LDP-IGP synchronization are as follows:

LDP convergence is complete the same time IGP convergence is complete by suppressing the
advertisement of IGP routes. If an LSP fails, an IGP changes the route advertisement mode to
synchronize LDP convergence with IGP convergence.
LDP-IGP synchronization involves the following timers:
l
Hold-down timer
Hold-max-cost timer
Delay timer
GR delay timer
LDP-IGP synchronization is applicable to the following scenarios.
Issue 02 (2011-09-10)

34

2 MPLS LDP
Figure 2-5 Traffic switchback by using LDP-IGP synchronization
On a network shown in Figure 2-5 with the primary link and backup link, if the primary
link recovers from a fault, traffic switches from the backup link to the primary link. After
IGP route convergence is complete, there is a period of time during which the previous
LSP cannot be used and a new LSP is not set up, causing traffic to be dropped. To prevent
traffic loss, LDP-IGP synchronization can be configured to delay the IGP route switchback
till LDP converges. Before the new LSP converges, the previous LSP continues forwarding
traffic till the new LSP is successfully established. Then, the original LSP is deleted. The
process of LDP-IGP synchronization is as follows:
1.
A link fault is rectified.
2.
An LDP session is set up between LSR2 and LSR3, and an IGP holds down the
establishment of an IGP neighbor relationship.
3.
Traffic travels through the previous LSP.
4.
After the LDP session is set up, Label Mapping messages are exchanged and then
synchronization between IGP and LDP starts.
5.
The IGP establishes a neighbor relationship and switches traffic back to the primary
link, and the LSP is re-established and its route converges on the primary link (in
milliseconds).
If an LDP session between nodes on a primary link fails, the LSP of the primary link will
be deleted, but IGP traffic is stilled forwarded along the primary link. Traffic on the LSP
cannot switch to a backup link, leading to continuous traffic loss. To prevent this problem,
you can configure LDP-IGP synchronization. LDP-IGP synchronization ensures that if an
LDP session fails, LDP advertises the fault to IGP. Then, an IGP advertises the maximum
cost value of an associated link so that the route switches to a backup link, and traffic on
the LSP also switches to the backup link. The detailed process of LDP-IGP synchronization
is as follows.
1.
Issue 02 (2011-09-10)
An LDP session between nodes along the primary link becomes defective.
35

2 MPLS LDP
2.
LDP informs an IGP of the failure on the primary link, and the IGP advertises the
maximum cost value of the primary link.
3.
The IGP route switches to the backup link.
4.
An LSP is set up along the backup link, and entries are delivered.
To ensure that the LDP session is set up successfully, you can configure a Hold-max-cost
timer to always advertise the maximum cost value. This ensures that traffic is always
transmitted along the backup link before the LDP session of the primary link is set up.
l
The detailed process of LDP-IGP synchronization is as follows after a master-slave

switchover occurs:
1.
An IGP on the Restarter advertises a normal cost value and starts a GR Delay timer,
waiting for an LDP session to be set up. Then, the IGP ends the GR process.
2.
If the GR Delay timer expires before the LDP session is set up, the IGP starts a Holdmax-cost timer, and advertises the maximum cost value of the link.
3.
After the LDP session is set up, or the Hold-max-cost timer expires, the IGP restores
the normal cost value of the local link and refreshes the route.
4.
The IGP route and LSP information are retained on the Helper. Therefore, after the
LDP session goes Down, LDP does not inform the IGP of the event, and the IGP still
advertises routes according to the normal cost value, which ensures that traffic and
the LSP are not switched.
2.3.8 Synchronization Between LDP and Static Routes

With the help of synchronization between LDP and static routes, you can switch traffic from the
faulty primary link to the backup link by suppressing the activation of static routes and delay
traffic switchback to the primary link, thus ensuring that LDP is synchronized with static routes.
Synchronization between LDP and static routes is used to minimize packet loss during traffic
switchover and switchback on the network with primary and backup links. As shown in Figure
2-6, on a network with primary and backup links, a static route is configured between LSRA
and LSRD, and an LSP is established between the two devices based on the static route.
Normally, Link A is preferred.
Figure 2-6 Networking diagram of LSP switching with synchronization between LDP and static
routes
LSRB
Link A
LSRA
LSRD
Link B
LSRC
Issue 02 (2011-09-10)

36

2 MPLS LDP
LSP switchover
If an LDP session is established, MPLS traffic is transmitted over Link A. If LDP is disabled
or becomes faulty on LSRB, the LDP session between LSRA and LSRB is interrupted.
Because the link between LSRA and LSRB works properly, the static route between LSRA
and LSRB is active. However, the LSP is switched to Link B. As a result, MPLS traffic
between LSRA and LSRD is interrupted.
If synchronization between LDP and static routes is enabled on LSRA, when the LDP
session goes Down, traffic transmitted through the static route is automatically switched
to Link B. Then the LSP is switched to Link B, ensuring continuous MPLS traffic
forwarding. During synchronization, adjusting the preference of the static route of Link A
makes traffic be switched to the Link B.
LSP switchback
If the link between LSRA and LSRB fails, the LSP is switched to Link B. If the link between
LSRA and LSRB recovers, the static route becomes active and the LSP is switched back
to Link A. However, the previous LSP becomes unavailable, and a new LSP has not been
established. As a result, MPLS traffic between LSRA and LSRD is interrupted.
After synchronization between LDP and static routes is enabled on LSRA, the static route
becomes active only after the LDP session goes Up. This ensures continuous traffic
forwarding.
2.3.9 LDP GR
LDP Graceful Restart (GR) enables a Restarter to perform master/slave switchover without
interrupting forwarding through a Helper.
When master/slave switchover occurs on a node that is not capable of GR, the neighbor deletes
the LSP because the session becomes Down. As a result, traffic cannot be forwarded and services
are interrupted for a short period. To avoid interruption, LDP GR is configured because it can
keep labels consistent before and after master/slave switchover, that is, it can sustain MPLS
forwarding. Figure 2-7 shows the detailed process.
1.
Before master/slave switchover, LDP neighbors negotiate the GR capability when

establishing an LDP session.
2.
When aware that the GR Restarter performs the master/slave switchover, the Helper starts
the Reconnect timer, and preserves the forwarding entry related to the Restarter before the
timer times out. The forwarding is not interrupted on condition that the Restarter preserves
the MPLS forwarding entry.
3.
If a session is re-established between the Restarter and the Helper before the Reconnect
timer times out, the Helper deletes the Reconnect timer and starts the Recovery timer.
4.
Before the Recovery timer times out, the Helper helps the Restarter to restore forwarding
entries and the Restarter also helps the Helper restore forwarding entries. After the timer
times out, the Helper deletes all the Restarter-related forwarding entries that are not
restored.
5.
After performing master/slave switchover, the Restarter starts the Forwarding State
Holding timer. Before the timer times out, the Restarter preserves forwarding entries before
GR and restores forwarding entries under the help of the Helper. After the timer times out,
the Restarter deletes all unrestored forwarding entries.
Issue 02 (2011-09-10)

37

2 MPLS LDP
Figure 2-7 Principle of LDP GR
GR Restarter
GR Helper
Negotiate GR capability and

send the Initialization (FT
Session TLV) message
Master/Slave
switchover
Start the Forwarding
State Holding Timer
Mark all MPLS
forwarding
entries Stale
Send the Initialization (FT Session

TLV, Recovery Time=Forwarding
State Holding Timer) message
Restore label
binding
Re-establish the LDP session

Exchange the Label Mapping
message
End GR
Succeed in detecting
faults on GR
Restarter. Mark GRRestarter-related
forwarding entries
Stale
Keep the MPLS

forwarding entries
marked Stale
Restore label
binding
End GR
2.3.10 LDP NSR

Principle of LDP NSR
The non-stop routing (NSR) technology is an innovation based on the non-stop forwarding (NSF)
technology whereas is naturally different from NSF. When a software or hardware fault occurs
on the control plane, NSR ensures the uninterrupted forwarding and the uninterrupted connection
of the control plane. In addition, the control plane of a neighbor does not sense the fault.
LDP NSR is implemented through synchronization between the master control board and slave
control board. When being started, the slave control board backs up data of the master board in
batches to ensure data consistency on both boards at this stage. LDP NSR simultaneously notifies
the master and slave control boards of receiving packets in real time. In this manner, the slave
control board synchronizes data with the master board. NSR then ensures that after the
switchover, the slave board fast takes over services on the original master board, whereas the
neighbor does not detect the fault on the local router.
LDP NSR synchronizes the following key data between the master control board and slave
control board:
l
LSP forwarding entries
Key resources including labels and XC
LDP protocol control blocks
2.3.11 LDP FRR

LDP Fast Reroute (FRR) provides the fast reroute function for MPLS networks by backing up
local interfaces.
Issue 02 (2011-09-10)

38

2 MPLS LDP
LDP FRR, in liberal label retention mode of LDP, obtains a liberal label, applies a forwarding
entry for the label, and then forwards the forwarding entry to the forwarding plane as the backup
forwarding entry for the primary LSP. When the interface is faulty (detected by the interface
itself or according to BFD detection) or the primary LSP fails (according to BFD detection),
LDP FRR fast switches traffic to the backup LSP to protect the primary LSP. A primary LSP
rather than a backup LSP is concerned with the backup forwarding entries generated by LDP
FRR; therefore, the implementation of LDP FRR does not involve traffic switchover.
l
Manually configured LDP FRR needs to be specified with the outbound interface and next
hop of the backup LSP by running a command. When the source of the liberal label matches
the outgoing interface and next hop, a backup LSP can be established and its forwarding
entries can be delivered.
LDP auto FRR depends on the implementation of IP FRR. When the source of the preserved
liberal label matches the outgoing interface and next hop of the backup route, the
requirement for triggering the policy of the backup LSP is met, and no backup LSP manually
configured according to the backup route exists, a backup LSP can be established and its
forwarding entries can be delivered. The default policy of LDP auto FRR is that the 32-bit
backup routes triggers LDP to establish backup LSPs. When both the manually configured
LDP FRR and LDP auto FRR meet the establishment conditions, the manually configured
LDP FRR is established preferentially.
Applicable Environment
Figure 2-8 A typical applicable environment of LDP FRR (triangle topology)
LSRC
LSRA
LSRB
Figure 2-8 shows a typical applicable environment of LDP FRR. The preferred route from LSR
A to LSR B is LSRA-LSRB and the second optimal route is LSRA-LSRC-LSRB. Thus, a
primary LSP of LSRA-LSRB is established on LSR A and a backup LSP of LSRA-LSRC-LSRB
is established to protect the primary LSP. After receiving the label from LSR C, LSR A compares
the label with the route from LSRA to LSRB. Because the next hop of the route from LSR A to
LSR B is not LSR C, LSR A preserves the label as a liberal label. If either of the following
conditions is met,
l
The source of a liberal label for manually configured LDP FRR corresponds to a specified
outgoing interface and next hop.
The backup route corresponding to the source of the liberal label for LDP auto FRR
exists and its destination meets the policy for LDP to create a backup LSP, and no backup
LSP manually configured according to the backup route exists.
Issue 02 (2011-09-10)

39

2 MPLS LDP
LSRA can apply a forwarding entry for the liberal label, establish a backup LSP as the backup
forwarding entry of the primary LSP, and send the backup LSP and primary LSP together to the
forwarding plane. In this way, the primary LSP is associated with the backup LSP.
When the interface detects fault by itself, BFD detects faults on the interface, or BFD detects
that the primary LSP fails, LDP FRR is triggered. After LSP FRR is complete, traffic is switched
to the backup LSP according to the backup forwarding entry. In this manner, LSP FRR takes
effect. Then, the route is converged from LSRA-LSRB to LSRA-LSRC-LSRB. An LSP is
established on the new LSP (the original backup LSP), and the original primary LSP is deleted,
and then the traffic is forwarded along the new LSP of LSRA-LSRC-LSRB.
Figure 2-9 A typical applicable environment of LDP FRR (rectangle topology)
As shown in Figure 2-8, all nodes in the triangle topology supports LDP FRR, but only parts
of nodes in the rectangle topology supports LDP FRR. As shown in Figure 2-9, if the optimal
route form N1 to D is N1-N2-D (load balancing is unavailable), then S receives a liberal label
from N1 and is bound to LDP FRR. When the link between S and D is faulty, traffic is switched
to the route of S-N1-N2-D without forming a loop.
However, if the optimal route from N1 to D is load balanced between N1-N2-D and N1-S-D, S
as the downstream neighbor of N1 does not necessarily receive the liberal label from N1. In
addition, though S receives the liberal label (LDP distributes labels for each peer) and is
configured with LDP FRR, traffic may still go to S after traffic switch to N1, which leads to a
loop, till the route from N1 to D is converged to N1-N2-D.
2.3.12 LDP MTU

MTU is short for Maximum Transmission Unit. When two devices on the same network
interconnect with each other, the MTU plays an important role. The size of the MTU determines
the maximum number of bytes that can be transmitted by the sender at a time. If the MTU exceeds
the maximum number of bytes supported by the receiver or a transit devices, packets are then
fragmented or even discarded, thus aggravating the network transmission load. In this manner,
devices have to calculate the MTU before communications so that sent packets can reach the
receiver successfully.
Principles
LDP LSP forwarding and common IP forwarding differ greatly in terms of implementation
mechanism but share a large number of similar aspects about the MTU. Both of them are required
to send packets smoothly to the receiver through each hop devices without reassembly.
Issue 02 (2011-09-10)

40

2 MPLS LDP
The MPLS MTU, like the interface MTU, has a default value and is configurable. To inform the
upstream device of the LDP MTU, an LSR needs to calculate the LDP MTU by taking the smaller
of the MTU values used by all downstream devices and the MTU of the egress of the host. The
LSR puts the value of the smaller MTU in the MTU TLV of the Label Mapping message and
then sends the Label Mapping message to the upstream device. If any of the two MTUs
mentioned previously changes due to change of configurations or the outgoing interface of the
local end, the LSR recalculates the MTU and then sends the Label Mapping message that
contains the calculated MTU to all upstream devices.
2.3.13 LDP MD5

MD5, short for Message-Digest Algorithm 5, is an international standard digest password
algorithm defined by RFC 1321. A typical application of MD5 is to calculate the digest of a
message to avoid modification of the message. The MD5 message digest is uniquely generated
by an irreversible character string algorithm. Thus, a different message digest is generated when
the message changes in any form during transmission, based on which the receiver considers
the arriving packet incorrect.
Principles
LDP MD5 implements anti-modification check of LDP packets by generating a unique digest
from a message, which is more strict than common TCP checksum.
Before sending packets through TCP, the device performs LDP MD5 authentication by adding
the unique message digest after the TCP header. The message digest is calculated through the
MD5 algorithm based on the sum of the TCP header, LDP message, and password set by the
user.
After receiving the TCP packet, the device extracts the TCP header, message digest, and LDP
message and then calculates the message digest from the combination of the TCP header, LDP
message, and password set by the user. The device compares this calculated message digest with
the message digest carried by the TCP packet to check whether the TCP packet is modified.
To implement the LDP MD5, LDP enables users to set password in plain text or cipher text. The
plain text or cipher text is used to encrypt the password in a configuration file. The plain text
directly records the character string set by the user. The cipher text records the character string
encrypted by a special algorithm.
No matter the password is encrypted in plain text or cipher text, the character string input by the
user is directly used in calculating the message digest; that is, the password encrypted in a private
encryption algorithm is not involved in calculating the MD5 message digest. The algorithm used
to convert the plain text and the cipher text is private for each vendor; therefore, the algorithm
of one vendor is transparent for another vendor.
2.3.14 LDP Authentication

LDP MD5
Message-Digest Algorithm 5 (MD5) is a standard digest algorithm defined in RFC 1321. A
typical application of MD5 is to calculate a message digest to prevent message spoofing. The
MD5 message digest is a unique result calculated through an irreversible character string
conversion. If a message is modified during transmission, a different digest is generated. After
the message arrives at the receiving end, the receiving end can determine that the packet is
modified by comparing the received digest with the pre-computed digest.
Issue 02 (2011-09-10)

41

2 MPLS LDP
LDP MD5 authentication prevents LDP packets from being modified by generating a unique
digest for an information segment. This authentication is stricter than the common checksum
verification of TCP connections.
Before an LDP message is sent over a TCP connection, LDP MD5 authentication is performed
by padding the TCP header with a unique digest. This digest is a result calculated by MD5 based
on the TCP header, LDP message, and a password set by a user.
When receiving this TCP packet, the receiver obtains the TCP header, digest, LDP message,
and then uses MD5 to calculate a digest based on the received TCP header, received LDP
message, and locally-stored password. The receiver compares the calculated digest with the
received one to check whether the packet is modified.
A password can be set either in cipher text or plain text. The plain text password is directly
recorded in the configuration file. The cipher text password is recorded in the configuration file
after being encrypted by using a special algorithm.
During the calculation of a digest, the character string entered manually is used irrespective of
whether the password is in plain text or cipher text. This means that a password calculated using
a private encryption algorithm does not participate in MD5 calculation and therefore ensures
that LDP MD5 authentication implemented on Huawei devices is transparent to non-Huawei
devices.
LDP Keychain
Keychain, an enhanced encryption algorithm to MD5, calculates a message digest for the same
LDP message to prevent the message from being modified.
During keychain authentication, a group of passwords are defined to form a password string,
and each password is specified with the encryption and decryption algorithms such as MD5
algorithm and SHA-1 and configured with the validity period. When sending or receiving a
packet, the system selects a valid password based on the user's configuration. Within the valid
period of the password, the system uses the encryption algorithm matching the password to
encrypt the packet before sending it out, or uses the decryption algorithm matching the password
to decrypt the packet before accepting it. In addition, the system automatically adopts a new
password after the previous password expires, preventing the password from being decrypted.
The keychain authentication password, the encryption and decryption algorithms, and the
password validity period that construct a keychain configuration node are configured by using
different commands. A keychain configuration node requires at least one password and
encryption and decryption algorithms.
To reference a keychain configuration node, specify the required peer and the name of the node
in the MPLS LDP view. In this manner, an LDP session is encrypted. Different peers can
reference the same keychain configuration node.
2.3.15 Distributing Labels for BGP by LDP

Distributing labels for BGP by LDP refers to that LDP establishes an LDP egress LSP for 32bit-mask BGP routes with labels on the public network and LDP establishes a transit LSP for
BGP routes on the public network.
LDP distributes labels for BGP routes in the inter-AS L3VPN Option C L3VPN scenario or the
carrier's carrier scenario. After LDP distributes labels for BGP routes, in the inter-AS Option C
scenario, the IBGP full meshed neighbor relationship need not be established between the PE
and ASBR; in the carrier's carrier scenario, the full meshed IBGP neighbor relationship need
not be established between the PEs of the level 2 carrier.
Issue 02 (2011-09-10)

42

2 MPLS LDP
L3VPN inter-AS Option C

Figure 2-10 Networking topology of the L3VPN inter-AS Option C scenario
BGP/MPLS Backbone
AS 100
Loopback1:
3.3.3.9/32
BGP/MPLS Backbone
AS 600
Loopback1:
4.4.4.9/32
Serial2/0/0: Serial2/0/0:
11.0.0.2/8 11.0.0.1/8
Serial1/0/0:
Serial1/0/0:
Loopback1: 1.1.1.1/8
9.1.1.1/8 Loopback1:
2.2.2.9/32
5.5.5.9/32
ASBR-1(PE)
ASBR-2(PE)
PE1
Loopback6:
30.0.0.1/8
Serial1/0/0:
9.1.1.2/8
Serial1/0/0:
1.1.1.2/8
MP-EBGP
PE2
Loopback6:
20.0.0.1/8
Configurations and deployment:

Different from the common L3VPN inter-AS Option C mode, Huawei L3VPN inter-AS
Option C mode does not establish the IBGP neighbor relationship between PE1 and ASBR1
and between PE2 and ASBR2. Instead, the L3VPN inter-AS Option C scenario mode
enables LDP to distribute labels for BGP routes on the two ASBRs and imports BGP routes
to IGP for advertisement. In this way, an LDP ingress LSP with the destination being the
peer PE can be established as the public network tunnel of L3VPN.
Route advertisement procedures:

Take the loopback address of PE1 for example. PE1 advertises 2.2.2.9/32 to ASBR1
through IGP. After learning the route 2.2.2.9/32, ASBR1 distributes a BGP label and then
advertises 2.2.2.9/32 to EBGP neighbor ASBR2 through BGP. After ASBR2 learns the
public network BGP route 2.2.2.9/32 with a label, LDP establishes an LDP egress LSP for
2.2.2.9/32 and advertises it (already imported to IGP) to PE2 through IGP. After learning
the IGP route 2.2.2.9/32, PE2 establishes an LDP ingress LSP for it.
Operations on labels:
Take the packet sent along the private network route 30.0.0.1/8 for example. PE1 pushes
a BGP label and then pushes an LDP label to the packet. ASBR1 pops outs the LDP label,
sends the packet along the BGP LSP, and then pushes a BGP label to the packet. ASBR2
pops outs the external BGP label, sends the packet along the LDP LSP, and then pushes an
LDP label. PE2 pops out the external LDP label and the internal BGP label in sequence
and then forwards the packet along 20.0.0.1/8 through IP.
Issue 02 (2011-09-10)

43

2 MPLS LDP
Carrier's Carrier
Figure 2-11 Networking topology of the carrier's carrier scenario
AS:100
Provider carrier
Loopback1
Loopback1
3.3.3.9/32
4.4.4.9/32
GE/0/0
30.1.1.1/24
PE1
PE2
GE1/0/0
GE1/0/0
GE2/0/0
30.1.1.1/24
11.1.1.2/24
21.1.1.2/24
AS:200
Loopback1
Customer
carrier
1.1.1.9/32
PE3
GE2/0/0
11.1.1.1/24
GE2/0/0
10.1.1.1/24
CE1
GE1/0/0
10.1.1.2/24
GE1/0/0
Loopback1
100.1.1.2/24
2.2.2.9/32
AS:300
Loopback1
GE1/0/0 Customer carrier 6.6.6.9/32
21.1.1.2/24
GE2/0/0
20.1.1.2/24
CE2
GE2/0/0
20.1.1.1/24
PE4
GE1/0/0
Loopback1
120.1.1.2/24
5.5.5.9/32
MP-EBGP
GE1/0/0
100.1.1.1/24
AS:65410
CE3
GE1/0/0
120.1.1.1/24
AS:65420
CE4
Configurations and deployment:

As shown in Figure 2-11, PE3, CE1, CE2, and PE4 are PEs of the level 2 carrier; PE1 and
PE2 are PEs of the level 1 carrier; CE3 and CE4 are CEs of a private network. Different
from the common carrier's carrier mode, Huawei carrier's carrier mode does not establish
the IBGP neighbor relationship between PE3 and CE1 and between PE4 and CE2. Instead,
Huawei carrier's carrier mode enables LDP to distribute labels for BGP routes on the CE1
and CE2 and imports BGP routes to IGP for advertisement. In this way, an LDP ingress
LSP with the destination being the peer PE can be established on PE3 and PE4 as the public
network tunnel of the level 2 carrier.
Route advertisement procedures:

Take the loopback address of PE4 for example. PE4 advertises 6.6.6.9/32 to CE2 through
IGP. After learning the route 6.6.6.9/32, CE2 distributes a BGP label and then advertises
6.6.6.9/32 with the distributed BGP label to the EBGP neighbor PE2 through BGP. After
learning private network route of 6.6.6.9/32, PE2 advertises the private network route. After
learning the private network BGP route of 6.6.6.9/32, PE1 advertises the private network
BGP route of 6.6.6.9/32 to the EBGP neighbor CE1 through BGP. After CE1 learns
6.6.6.9/32, 6.6.6.9/32 is already a public network BGP route with labels. LDP establishes
an LDP egress LSP for 6.6.6.9/32 and then advertises 6.6.6.9/32 (it is already imported to
IGP) to PE3 through IGP. After learning the IGP route 6.6.6.9/32, PE3 establishes an LDP
ingress LSP for 6.6.6.9/32.
Issue 02 (2011-09-10)

44

2 MPLS LDP
Operations on labels:
Take the packet sent along the private network route 100.1.1.1/24 for example. PE3 pushes
a BGP label and then pushes an LDP label to the packet. CE1 pops outs the LDP label,
sends the packet along the BGP LSP. CE2 pops outs the external BGP label, sends the
packet along the LDP LSP, and then pushes an LDP LSP. PE4 pops outs the external LDP
label and internal BGP label in sequence, and then forwards the packet to 120.1.1.1/24
through IP.
2.3.16 LDP over TE

RSVP TE is an MPLS tunnel technology and can generate LSPs for other protocols as tunnels
to transparently transmit packets. LDP is another MPLS tunnel technology and can generate
LDP LSPs. LDP over TE, a technology used by VPN servers, enables LDP LSPs to cross RSVP
TE areas. According to VPN applications, to carry out the MPLS traffic engineering, carriers
have difficulty in deploying TE on the entire network. Thus, carriers can plan a core TE area
where TE is deployed, and implement LDP outside the TE area.
After the RSVP TE tunnel is established, an IGP (such as OSPF and IS-IS) enables the outgoing
interface of routes to select a TE tunnel through local calculation or by advertising link state
advertisement (LSA). The source device is directly connected to the destination device of the
TE tunnel by the interface (logical interface) of the TE tunnel. Actually, packets are transparently
transmitted in the TE tunnel.
Figure 2-12 Networking topology of LDP over TE
LDP LSP
LSR1
LDP LSP
RSVP LSP
LSR2
LSR3
BP1
LSR4
LSR5
BP2
RSVP LSP
As shown in Figure 2-12, the entire network is an MPLS VPN, runs LDP as the signaling
protocol, and provides common VPN services. LSR1 and LSR5 are PEs. After a large number
of users are connected to the network, traffic between LSR1 and LSR5 passes the link between
LSR2 and LSR3. Thus, the link is congested. The link between LSR2 and BP1 is idle. The LSP,
however, cannot use the link between LSR2 and BP1 because the IGP cost of this link is high.
To solve this problem, LDP over TE can be deployed. A TE tunnel can be established between
LSR2 and LSR4 and the tunnel passes BP1 and BP2. Adjust the value of IGP cost so that routes
can be load balanced on LSR2 on the following two interfaces:
l
Physical interfaces of LSR2 and LSR3
Interfaces of the TE tunnel between LSR2 and LSR4
Issue 02 (2011-09-10)

45

2 MPLS LDP
In this manner, LDP establishes LSPs for load balancing to allow traffic to pass through the idle
link.
Advantages: A configurable number of TE tunnels can be established on idle links. This has
more advantages than adjusting the value of IGP cost and is widely applied in MPLS TE.
2.3.17 LDP GTSM

GTSM, short for Generalized TTL Security Mechanism (GTSM), is a mechanism that protects
the service over IP layer by checking whether the TTL value in the IP header is within a predefined range. The preconditions for using GTSM are as follows:
l
The TTL of normal packets between devices is determined.
The TTL of packets cannot be modified.
GTSM can be applied to BGP (including IPv6), OSPF, LDP, RSVP, and OSPFv3.
Principles
LDP GTSM is the application of GTSM to LDP.
To protect a device from attacks, GTSM checks the TTL of a packet to check whether the packet
is valid. GTSM for LDP is applied to LDP packets between neighbor or adjacent (based on fixed
number of hops) devices. The TTL range is preset for packets from other devices and GTSM is
enabled. In this manner, when LDP is used between devices, if the TLL of an LDP packet is out
of the TTL range, the LDP packet is considered an invalid attack packet and thus discarded. In
this way, the upper layer protocols are protected.
GTSM is mainly used to protect the TCP/IP-based control plane from the CPU-utilization or
CPU overload attack. To apply GTSM to LDP, GTSM is used on all LDP packets to prevent
LDP from suffering attacks such as CPU-utilization when LDP receives and processes a large
number of pseudo packets.
Figure 2-13 Networking topology of LDP GTSM
LSR1
LSR2
LSR3
LSRA (attack packets)

Core routers
LSR4
Issue 02 (2011-09-10)

LSR5
46

2 MPLS LDP
As shown in Figure 2-13, LSR1 to LSR5 are core devices on a backbone network. When
indirectly connected to a core device, LSRA may forge LDP packets between LSR1 and LSR5
to launch attacks.
When LSRA is indirectly connected, the TTL carried by pseudo packets is considered unforced,
which is the precondition of GTSM.
Configure the GTSM policy of reaching possible neighbors on LSR1 to LSR5 separately. For
example, set the number of valid hops of packets sent by LSR2 to 1 or 2 on LSR5 and the TTL
to 254 or 255. When the pseudo packet sent by LSRA reaches LSR5 through multiple
intermediate devices, the TTL of the pseudo packet is out of the preset TTL range. Thus, LSR5
discards the pseudo packet and avoids attacks.
2.3.18 Coexistence of the Local and Remote LDP Sessions

Principles
This feature is mainly applied to L2VPN services.
The principle is that both the local LDP adjacency and remote LDP adjacency can be connected
to the same peer, that is, the peer is maintained by both the local LDP adjacency and remote
LDP adjacency.
As shown in Figure 2-14, when the local LDP adjacency is deleted due to the faulty link to
which the adjacency is connected, the type of the peer may change without affecting the existence
and status of the peer. The type is determined by the type of adjacencies. The type of adjacencies
include the local, the remote, and coexistence of the local and remote.
When the link becomes faulty or is recovering, the type of the peer may change and the session
type corresponding to the peer changes accordingly. However, the session is not deleted and
does not become Down; instead, the session is still Up.
Figure 2-14 Networking topology of coexistence of the Local and remote LDP sessions
Remote Adjacency
CE1
PE1
Local
PE2
Adjacency
CE2
A typical application scenario is L2VPN. As shown in Figure 2-14, L2VPN services are applied
on PE1 and PE2. When the directly-connected link between PE1 and PE2 is disconnected and
then recovers, the procedures are as follows:
Issue 02 (2011-09-10)

47

2 MPLS LDP
1.
A session for the coexistence of the local LDP adjacency and remote LDP adjacency is
created on the two directly-connected devices. L2VPN messages are sent through this
session.
2.
The physical link between PE1 and PE2 becomes Down, and thus the local LDP adjacency
of the peer becomes Down. The route between PE1 and PE2 is reachable through P, that
is, the remote LDP adjacency is still Up. When the session type changes, the session
becomes a remote session and is still Up. The L2VPN can not sense the change of the
session type and thus it does not delete the session. This prevents the L2VPN from
disconnecting neighbors and recovering and reduces the service interruption time.
3.
When the fault is rectified, the link between PE1 and PE2 becomes Up and then the local
LDP adjacency becomes Up. When the session type changes, the session is restored to a
session through which the local LDP adjacency and remote LDP adjacency can coexist,
and the session is still Up. The L2VPN can not sense the change of the session type and
thus it does not delete the session. This reduces the service interruption time.
2.3.19 Distributing Labels for All Peers by LDP

This sub-feature solves the problem that the convergence is slow when the link is faulty.
When labels are distributed for only upstream peers and Label Mapping messages are sent, check
the upstream/downstream relationship of the session in routing information. An upstream node
cannot send the Label Mapping message to its downstream node along a route. If the route
changes and the upstream/downstream relationship is switched, the new downstream node
resends the Label Mapping message. In this process, the convergence is slow.
After LDP distributes labels for all peers, LDP sends Label Mapping messages to all matching
peers without distinguishing the upstream/downstream relationship. That is, each node can send
Label Mapping messages to all peers.
As shown in Figure 2-15, the original routes from P2 to P3 are P2->P1->P3->PE3 and P2->P4>PE4-PE3. For the loopback interface route on PE3, P1 is the next hop of P2. When P2 receives
the Label Mapping message from P1 and can distribute labels to upstream nodes only, P2 does
not send the Label Mapping message about the route to P1. In this manner, when the link between
P1 and P3 is faulty, the route from PE1 to PE3 is switched from PE1->P1->P3->PE3 to PE1>P1->P2->P4->P3->PE3 and P2 becomes the downstream of P1. However, P2 does not send
the Label Mapping message to P1 and thus must wait to resend the Label Mapping message. In
the process, LSP reconvergence is slow.
When LDP distributes labels for all peers, after P2 receives the Label Mapping message from
P1, P2 directly sends the Label Mapping message about the route to P1 and LDP generates a
liberal LSP on P1. In this manner, when the link between P1 and P3 is faulty, the route from
PE1 to PE3 is switched from PE1->P1->P3->PE3 to PE1->P1->P2->P4->P3->PE3, P2 becomes
the downstream of P1, and the liberal LSP directly changes to a normal LSP. Then, LSP
convergence is accelerated.
In addition, you can configure split horizon to determine the upstream peers to which Label
Mapping messages are sent and the upstream peers to which Label Mapping messages are not
sent.
Issue 02 (2011-09-10)

48

2 MPLS LDP
Figure 2-15 Networking topology of distributing labels for all peers by LDP
PE1
P1
P3
PE3
PE2
P2
P4
PE4
Primary LSP
Backup LSP
LSP from P2 to PE3

Terms
Terms
Explanation
GR Restarter
A node that is restarted by the administrator

or in case of failures. The GR restarter must
support GR.
GR Helper
A neighbor of a GR restarter. The GR helper

must support GR.
Abbreviation
Issue 02 (2011-09-10)
Abbreviation
Full Spelling
LDP
LSP
Label Switched Path
FEC
GTSM
Generalized TTL Security Mechanism
TTL
Time To Live
GR
Graceful Restart
FRR
Fast Reroute
49

Issue 02 (2011-09-10)
2 MPLS LDP
Abbreviation
Full Spelling
MTU
Maximum Transmission Unit

50

3 MPLS TE
MPLS TE
About This Chapter

3.1 Introduction to MPLS TE
3.2 References
3.3 Principles
Issue 02 (2011-09-10)

51

3 MPLS TE
3.1 Introduction to MPLS TE

Purpose
In a traditional IP network, a node select the shortest path as the route regardless of other factors
such as bandwidth. The shortest path, however, may be congested with traffic, whereas other
available paths are idle.
Figure 3-1 Problems in Traditional Routing
R8
R3
R4
R2
R5
R1
R6
R7
As shown in Figure 3-1, assume that links have the same metric. The shortest path from R1
(R8) to R5 is R1 (R8) -> R2 -> R3 -> R4 -> R5. Data is forwarded along this shortest path though
other paths to R5 are available. The situation may occur that the path R1 (R8) -> R2 -> R3 ->
R4 -> R5 is congested due to overload, and the path R1 (R8) -> R2 -> R6 -> R7 -> R4 -> R5 is
idle.
Network congestion is the major cause of poor performance of a backbone network. The
congestion is caused by insufficient resources or unbalanced load of network resources. Traffic
engineering (TE) solves the problem of congestion caused by unbalanced loading. Traditional
TE solutions to congestion are as follows:
l
TE controls the network traffic by adjusting the metric of a path. This can eliminate
congestion of only part of links, and cause the congestion on other links. In addition, in a
network with complicated topology, the metric is difficult to adjust because the change of
a link may affect multiple routes.
TE directs partial traffic by setting up virtual connections (VCs) based on an overlay model.
The current Interior Gateway Protocols (IGPs) are topology driven and applicable to only
static network connections regardless of the dynamic factors such as bandwidth and traffic
characteristics.
The overlay model such as IP over Asynchronous Transfer Mode (ATM) and IP over Frame
Relay (FR) can complement IGP disadvantages. The overlay model provides the virtual
topology over the physical topology for a network. This helps to reasonably adjust traffic
and implement Quality of Service (QoS) features. The overlay model, however, is of high
cost and low scalability.
To implement TE in a large-scale backbone network, a scalable and simple solution is required.

As an overlay model, the Multiprotocol Label Switching (MPLS) protocol can set up a virtual
Issue 02 (2011-09-10)

52

3 MPLS TE
topology over a physical topology, and then map traffic to this virtual topology. Thus, MPLS
TE that integrates MPLS with TE emerges.
Definition
MPLS TE is an abbreviation for MPLS Traffic Engineering. In MPLS TE, a constraint-based
label switched path (CR-LSP) can be set up according to the Resource Reservation Protocol-TE
(RSVP-TE). The constraints include the bandwidth, priority, affinity attribute, explicit path,
CSPF tie-breaking rule, metric type, hop limit, and Shared Risk Link Group (SRLG). In addition,
a CR-LSP can be set up statically, that is, a static CR-LSP.
By integrating MPLS with traffic engineering, MPLS TE can reserve resources by setting up
LSPs along a specified path to detour congested nodes and balance network traffic.
MPLS offers the following features required by TE implementation:
l
MPLS supports explicit paths to control the paths of LSPs.
MPLS uses the signaling to set up LSPs, which are easy to configure and convenient to
maintain.
Setting up LSPs consume a few resources; therefore, the establishment of LSPs does not
affect other network services.
Network traffic is easily mapped to an LSP.
The behaviors of an LSP can be easily controlled by the attributes of the LSP such as priority
and preemption.
The administrative group attribute and affinity attribute can control the path of an LSP.
MPLS allows traffic aggregation and disaggregation, which is more flexible than IP
forwarding.
MPLS can easily generate constraint-based routes.
MPLS TE can solve the problem that some links are overloaded while others are idle; thus, the
current bandwidth resources can be efficiently utilized. In addition, MPLS TE can reserve
resources to ensure the service quality during the establishment of LSPs.
To ensure continuity of services, MPLS TE introduces the CR-LSP backup mechanism and fast
reroute (FRR) mechanism. When faults occur on a link, traffic can be switched in time.
The attributes related to MPLS TE are as follows:
l
CR-LSP
A CR-LSP is the LSP that is set up on basis of certain constraints. A common LSP is set
up on the basis of routing information. In addition to routing information, a CR-LSP can
be set up when other requirements, such as the specified bandwidth, color, setup priority,
hold priority, explicit path, and QoS parameters are met.
CR-LSPs are classified into the following types:
Static CR-LSP: Forwarding information and resource information are manually
configured for a CR-LSP regardless of signaling protocols or path calculation. Setting
up a static CR-LSP costs few resources because two ends of the CR-LSP do not need
to exchange MPLS control packets. The static CR-LSP, however, cannot be adjusted
dynamically according to the changeable network topology and hence is not widely
used.
Dynamic CR-LSP: It is set up and maintained through the signaling mechanism. Path
calculation is required during the setup of a dynamic CR-LSP.
Issue 02 (2011-09-10)

53

3 MPLS TE
RSVP-TE
RSVP (Resource Reservation Protocol) is extended to RSVP-TE for the setup of a CRLSP.
Bandwidth
Bandwidth is one of basic attributes of MPLS TE. Before a CR-LSP is set up, the path of
a CR-LSP is selected according to the specified bandwidth. The RSVP-TE signaling carries
the bandwidth information and reserves bandwidth on each node along the path. After a
CR-LSP is set up, the CR-LSP can provide sufficient bandwidth for the specific service.
Explicit path
A CR-LSP can be set up over a specified path. This path is called an explicit path. Explicit
paths are classified into the following types:
Strict explicit path
A strict explicit path means that at least one interface address of every node along the
path is specified. By strictly specifying an explicit path, you can most exactly control
the path of a CR-LSP.
Figure 3-2 Strict explicit path
LSRA
LSRB
LSRD
LSRF
Strict
LSRC
LSRE
B Strict
C Strict
E Strict
D Strict
F Strict
As shown in Figure 3-2, LSRA is the ingress, and LSRF is the egress. An LSP from
LSRA to LSRF is set up along a strict explicit path. "InterfaceB strict" indicates that
this LSP must pass through the InterfaceB of LSRB, and the previous hop of LSRB is
LSRA. "InterfaceC strict" indicates that this LSP must pass through the interfaceC of
LSRC, and the previous hop of LSRC is LSRB. The rest may be deduced by analogy,
and then you can precisely control the path through which the LSP passes.
Loose explicit path
A loose explicit path contains the specified nodes through which an LSP must pass;
however, the path is not specified strictly.
Issue 02 (2011-09-10)

54

3 MPLS TE
Figure 3-3 Loose explicit path
LSRA
LSRB
LSRD
LSRF
Loose
LSRC
LSRE
D Loose
As shown in Figure 3-3, an LSP is set up over a loose explicit path from the ingress
LSRA to the egress LSRF. "D loose" indicates that this LSP must pass through LSRD;
however, other devices can exist between LSRD and LSRA. That is, LSRA and LSRD
do not need to be directly connected.
The MPLS TE signaling carries information about information about explicit path including
strict versus loose attribute and sets up CR-LSPs over the specified paths.
Explicit Route Object (ERO) describes information about the path through which the LSP passes.
The explicit paths can be strict or loose. Path messages are then forwarded along the specified
ERO, without being restricted by IGP shortest path.
l
CSPF tie-breaking
CSPF calculates only the shortest path to the tunnel destination. During the path
computation, if there are several paths with the same metric, CSPF selects one of them.
This process is called tie-breaking. Tie-breaking methods for selecting the path are as
follows:
Most-fill: selects the link with the highest proportion of the used bandwidth to the
maximum reservable bandwidth. This method highly utilizes bandwidth resources.
Least-fill: selects the link with the lowest proportion of the used bandwidth to the
maximum reservable bandwidth. This method realizes even use of bandwidth resources.
Random: distributes LSPs evenly to links and hence the bandwidth need not be taken
into consideration.
When several links have the same proportion of the used bandwidth to the maximum
reservable bandwidth, for example, the links do not use the reserved bandwidths or the
bandwidths occupied on each link are equal, the link discovered first is selected no matter
whether most-fill or least-fill is configured.
Priority and preemption

When you set up a CR-LSP, if no path has sufficient bandwidth, an established CR-LSP
with a lower priority is torn down and the bandwidth resources assigned to that CR-LSP
are used. This is called preemption.
CR-LSPs use two priority attributes, namely, setup priority and holding priority, to
determine whether to preempt resources. The value of the priority is an integer ranging
from 0 to 7. The smaller the value, the higher the priority. The value 7 indicates the lowest
priority.
Administrative group and affinity attributes

An administrative group is a 32-bit vector representing a set of link attributes.
Issue 02 (2011-09-10)

55

3 MPLS TE
The affinity attribute is a 32-bit vector representing the color of a tunnel link. After the CRLSP is configured with the affinity attribute, the device compares the affinity attribute with
the administrative group attribute during link selection to determine whether to select or
detour the path with the specified attributes.
After the affinity attribute is configured on the ingress, the affinity attribute is sent to each
node along a CR-LSP through RSVP-TE.
l
Hop limit
Hop limit is used to select a path for the CR-LSP to be set up. Similar to the administrative
group attribute and affinity attribute that can limit a CR-LSP, it limits the number of hops
that a CR-LSP allows.
SRLG
The SRLG is a group of links sharing the same public physical resource (or an optical fiber).
The links in the same SRLG take the same risk. That is, if one link becomes invalid, the
remaining links also become invalid.
The SRLG technology is mainly used to enhance the reliability of TE tunnels in the
scenarios of CR-LSP hot standby and TE FRR networking. The links sharing the same
physical resource take the same risk. For example, when the main interface goes Down, its
sub-interfaces also go Down. If the links of the primary tunnel and backup tunnel take the
same risk, when the link where the primary tunnel resides goes Down, the backup tunnel
probably goes Down. Therefore, the SRLG is a restriction on the backup tunnel calculation.
3.2 References
The following table lists the references of this document.
Issue 02 (2011-09-10)
Document
Description
Rem
arks
RFC 2205
Resource Reservation Protocol
RFC 2209
Resource Reservation Protocol (RSVP) - Version 1 Message

Processing Rules
RFC 2370
The OSPF Opaque LSA Option
RFC 2547
BGP/MPLS VPNs
RFC 2702
Requirements for Traffic Engineering Over MPLS
RFC 2747
RSVP Cryptographic Authentication
RFC 2961
RSVP Refresh Overhead Reduction Extensions
RFC 3031
Multiprotocol Label Switching Architecture
RFC 3032
MPLS Label Stack Encoding
RFC 3034
Use of Label Switching on Frame Relay Networks Specification
RFC 3209
RSVP-TE: Extensions to RSVP for LSP Tunnels
RFC 3210
Applicability Statement for Extensions to RSVP for LSP-Tunnels

56

3 MPLS TE
Document
Description
Rem
arks
RFC 3473
Generalized Multi-Protocol Label Switching (GMPLS) Signaling

Resource Reservation Protocol-Traffic Engineering (RSVP-TE)
Extensions
RFC 3630
Traffic Engineering (TE) Extensions to OSPF Version 2
RFC 3784
Intermediate System to Intermediate System (IS-IS) Extensions for

Traffic Engineering (TE)
RFC 4124
Protocol Extensions for Support of Diffserv-aware MPLS Traffic

Engineering
RFC 4127
Russian Dolls Bandwidth Constraints Model for Diffserv-aware

MPLS Traffic Engineering
RFC 4128
Bandwidth Constraints Models for Differentiated Services

(Diffserv)-aware MPLS Traffic Engineering: Performance
Evaluation
RFC 4139
Requirements for Generalized MPLS (GMPLS) Signaling Usage

and Extensions for Automatically Switched Optical Network
(ASON)
draft-ietfmpls-rsvplspfastreroute-02
Fast Reroute Extensions to RSVP-TE for LSP Tunnels
draft-ietfmpls-nodeidsubobject-01
Definition of an RRO node-id subobject
draft-ietftewg-diff-teproto-02
Protocol extensions for support of Diff-Serv-aware MPLS Traffic

Engineering
draft-ietfmpls-diff-tereqts-00
Requirements for support of Diff-Serv-aware MPLS Traffic

Engineering
draft-ietfmpls-diffext-07
MPLS Support of Differentiated Services
3.3 Principles
MPLS TE can guarantee normal traffic transmission by setting up a TE tunnel with sufficient
bandwidth.
Issue 02 (2011-09-10)

57

3 MPLS TE
3.3.1 RSVP-TE
The Resource Reservation Protocol (RSVP) is designed on the basis of the Integrated Services
model. RSVP can reserve resources on each node of a CR-LSP. RSVP, an Internet control
protocol, operates on the transport layer; however, RSVP does not transport application data.
RSVP-TE is an extension to RSVP. RSVP-TE can set up or delete CR-LSPs by supporting TE
attributes through extended objects.
RSVP-TE has the following characteristics:
l
A CR-LSP is unidirectional.
RSVP-TE is receiver-oriented. A receiver initiates a request for resource reservation and

maintains the resource reservation information.
RSVP-TE uses a soft state mechanism to maintain the resource reservation information.
RSVP is extended to the RSVP-TE in the following aspects:

l
RSVP-TE appends Label Request objects to RSVP Path messages to request labels. In
addition, Resv messages carry Label objects that are used to allocate labels. In this manner,
TE tunnels can be set up.
The extended RSVP messages can carry not only label binding information but also
information about path constraint parameters.
RSVP-TE supports MPLS TE attributes, such as resource reservation, through the extended
objects.
RSVP-TE Messages
RSVP-TE messages include the Path message, Resv message, PathErr message, ResvErr
message, PathTear message, ResvTear message, ResvConfirm message, Hello message, ACK
message, Srefresh message, GRPath message and RecoveryPath message.
RSVP-TE messages are as follows:
l
Path message: is sent by the sender to request the downstream node to allocate labels for
this CR-LSP. The path information is recorded in the Path message when it passes through
each node, and the Path State Block (PSB) is created on each node.
Resv message: is used to reserve resources on each node. A Resv message carries the
resource reservation information for which the sender applies. It is sent in the direction
opposite to the direction of data traffic. On each node of the CR-LSP, a Reserved State
Block (RSB) is created, and the Resv message records information about the allocated
labels.
PathErr message: is sent upstream by an RSVP node if an error occurs during the processing
of a Path message. After transit nodes receive the PathErr message, transit nodes forward
the message upstream to the ingress.
ResvErr message: is sent downstream by an RSVP node when an error occurs during the
processing of a Resv message. After transit nodes receive the ResvErr message, transit
nodes forward the message downstream to the egress.
PathTear message: is sent downstream by the ingress to delete the local state block created
on each node.
ResvTear message: is sent upstream by the egress node to delete local resources on each
node. After the ingress receives a ResvTear message, the ingress sends a PathTear message
downstream.
Issue 02 (2011-09-10)

58

3 MPLS TE
Process of Setting up a CR-LSP

Figure 3-4 Schematic diagram of setting up a CR-LSP
Ingress
PE1
Path
Resv
Transit
P1
Path
Resv
Transit
P2
Path
Resv
Egress
PE2
Figure 3-4 shows the process of setting up a CR-LSP.

1.
The ingress receives a message that notifies the ingress to set up a CR-LSP, and then creates
the PSB and sends a Path message downstream.
2.
Transit nodes process and forward the Path message and create PSBs respectively.
3.
The egress receives the Path message and then creates a PSB. In addition, the egress
generates a Resv message according to the Path message, creates an RSB, and then sends
a Resv message upstream.
4.
Transit nodes process and forward the Resv message and create RSBs respectively.
5.
The ingress receives the Resv message and then creates an RSB to confirm that resources
are successfully reserved.
After the preceding process, a CR-LSP is successfully set up.
Soft State
RSVP nodes periodically send RSVP Refresh messages to synchronize statuses (including PSB
and RSB) with RSVP neighboring nodes or restore the lost RSVP messages. This is the soft
state mechanism of RSVP. If no Refresh message about a certain state is received within a
specified interval, the state is deleted.
When a node needs to refresh its state, it creates a Refresh message and sends it downstream. If
a route changes and MPLS TE FRR is enabled, the next Path message initializes the path state
based on the new route and the Resv message creates the reservation state on each node of the
new CR-LSP. The unused path state is deleted after timeout.
Reservation Style
Reservation requests from upstream nodes are collectively called reservation styles. Currently,
Huawei supports the following reservation styles:
l
Fixed Filter (FF): creates a distinct reservation for data packets from a particular sender.
This sender does not share its resource reservation with other senders and allocates a unique
label.
Shared Explicit (SE): creates a single reservation for the explicitly-specified senders. The
senders share the resource reservation and allocate different labels.
3.3.2 Make-Before-Break
Make-before-break is a technology for ensuring high reliability of CR-LSP switchover. When
a CR-LSP is created, the original CR-LSP is not deleted. After the CR-LSP is successfully set
Issue 02 (2011-09-10)

59

3 MPLS TE
up, traffic is switched to the CR-LSP. Then, the original CR-LSP is deleted. In this manner,
traffic is not interrupted.
Figure 3-5 Principles of the make-before-break mechanism
60Mbit/s
R1
60Mbit/s
60Mbit/s
60Mbit/s
R2
R3
R4
60Mbit/s
R5
The make-before-break mechanism works as follows:

l
Modifies the CR-LSP.

As shown in Figure 3-5, assume that the maximum reservable bandwidth for all links is
60 Mbit/s. A CR-LSP along the path LSRA -> LSRB -> LSRC -> LSRD is set up, and the
bandwidth is 40 Mbit/s. The path is expected to change to LSRA -> LSRE -> LSRC ->
LSRD to forward data because LSRE has a low load. The remaining reservable bandwidth
of the path between LSRC and LSRD is only 20 Mbit/s. The total bandwidth cannot meet
the requirement for 40 Mbit/s. In this case, you can use the make-before-break mechanism
to solve the problem.
Through the make-before-break mechanism, the newly established path LSRA -> LSRE > LSRC -> LSRD uses the original bandwidth of the path between LSRC and LSRD during
resource reservation. After the new CR-LSP is set up, traffic is switched to the new path,
and then the original path is deleted.
Releases bandwidth of the original CR-LSP for the new CR-LSP.

If the reservable bandwidth of the shared link meets the increment requirement, a new CRLSP can be set up. As shown in Figure 3-5, assume that the maximum reservable bandwidth
of all links is 60 Mbit/s. A CR-LSP along the path LSRA -> LSRB -> LSRC -> LSRD is
set up with the bandwidth being 30 Mbit/s. The path is expected to change to LSRA ->
LSRE -> LSRC -> LSRD to forward data because LSRE has a low load, and the released
bandwidth is 40 Mbit/s. The reservable bandwidth of the path between LSRC and LSRD
is only 30 Mbit/s. The total bandwidth cannot meet the requirement for 40 Mbit/s. In this
case, you can use the make-before-break mechanism to solve the problem.
Through the make-before-break mechanism, the newly established CR-LSP along the path
LSRA -> LSRE -> LSRC -> LSRD uses the original bandwidth of the path between LSRC
and LSRD during resource reservation. That is, the bandwidth of the new CR-LSP is 40
Mbit/s, among which 30 Mbit/s is released by the original path. After the new CR-LSP is
set up, traffic is switched to the new CR-LSP, and then the original CR-LSP is deleted.
3.3.3 P2MP RSVP-TE

The following problems exist during the transmission of multicast packets:
l
Issue 02 (2011-09-10)
Bandwidth waste: On traditional core networks and backbone networks, IP and MPLS are
usually deployed to forward data packets. IP and MPLS networks flexibly forward unicast
packets with high reliability and TE capabilities. Nevertheless, these IP and MPLS
60

3 MPLS TE
networks waste bandwidths because they forward multicast packets by replicating them for
each receiver.
l
Transmission interruption: During the transmission of multicast packets, PIM advertises

leaf IDs and sets up MDTs based on routes hop by hop. Therefore, if a node is congested,
the transmission of multicast packets is affected. In addition, when a link fails on a network,
traffic convergence is slow, and as a result, the transmission of multicast packets is
interrupted.
To help prevent the preceding problems, P2MP RSVP-TE is developed on the basis of MPLS
to satisfy requirements for establishing a P2MP RSVP-TE tunnel. In addition, P2MP RSVP-TE
improves reliability and QoS and provides effective TE capabilities. An existing IP and MPLS
network can obtain the multicast capability after simple configuration, reducing expenditures of
the configuration and maintenance and adapting to the trend of network integration.
Establishing a P2MP RSVP-TE Tunnel

The process of establishing a P2MP RSVP-TE tunnel is as follows:
l
Specify all the leaves on the ingress. The paths from the ingress to the leaves can be explicit
paths or dynamically calculated.
The ingress sends an RSVP-TE Path message to every leaf along the paths. After receiving
the RSVP-TE Path message, each leaf sends an RSVP-TE Resv message to the ingress.
During message exchange, RSVP-TE signaling reserves bandwidth on LSRs along the
paths.
After receiving the RSVP-TE Resv messages replied by the leaves, the ingress successfully
sets up LSPs.
The P2MP RSVP-TE tunnel is then successfully set up.
Figure 3-6 Schematic diagram of establishing a P2MP RSVP-TE tunnel
Figure 3-6 shows the network of a P2MP RSVP-TE tunnel. The procedure for setting up the
P2MP RSVP-TE tunnel is as follows:
Issue 02 (2011-09-10)

61

3 MPLS TE
1.
A P2MP RSVP-TE tunnel is set up from LSR A to the leaves LSR D, LSR G, and LSR H,
including the path LSR A -> LSR B -> LSR C-> LSR D, the path LSR A -> LSR B -> LSR
C -> LSR H, and the path LSR A -> LSR E -> LSR F -> LSR G. These paths can be set up
over explicit paths or be dynamically calculated on LSR A.
2.
LSR A constructs RSVP-TE Path messages separately destined for LSR D, LSR G, and
LSR H and sends these messages downstream along the specified paths. After receiving
the RSVP-TE Path message, every leaf replies with an RSVP-TE Resv message carrying
a label along the specified path.
3.
LSR A receives RSVP-TE Resv messages from LSR D, LSR G, and LSR H.
The P2MP RSVP-TE tunnel is then successfully set up.
FRR over a P2MP RSVP-TE Tunnel

A P2MP RSVP-TE tunnel, like a P2P RSVP-TE tunnel, provides FRR. FRR ensures that traffic
switches to a bypass LSP within 50 ms after a link or a node fails.
Figure 3-7 Schematic diagram of FRR over a P2MP RSVP-TE tunnel
LSRJ
LSRB
LSRC
LSRD
LSRE
LSRF
LSRG
LSRA
LSRI
LSRH
Primary LSP
Bypass LSP
Figure 3-7 shows the networking of FRR over a P2MP RSVP-TE tunnel. FRR provides link
protection and node protection for the P2MP RSVP-TE tunnel.
Issue 02 (2011-09-10)

62

3 MPLS TE
Link protection: On LSR B, a P2P bypass LSP along the path LSR B -> LSR J -> LSR C
is set up to back up the link from LSR B to LSR C. If the link from LSR B to LSR C fails,
traffic switches to the bypass LSP along the path LSR B -> LSR J -> LSR C.
Node protection: On LSR E, either of the following methods can be adopted to protect
traffic on LSR F and on the link from LSR E to LSR F:
Setting up two P2P LSPs along the path LSR E -> LSR I -> LSR G and the path LSR
E -> LSR I -> LSR H
Setting up one P2MP tunnel along the path LSR E -> LSR I -> LSR G and the path LSR
E -> LSR I -> LSR H
No matter which method is adopted, if LSR F fails, traffic switches to two bypass LSPs
along the path LSR E -> LSR I -> LSR G and the path LSR E -> LSR I -> LSR H.
The CX600 supports FRR link protection.
3.3.4 Automatic Bandwidth Adjustment

With the automatic bandwidth adjustment, a system can dynamically detect traffic, and then recreate an LSP with required bandwidth according to detection results.
The bandwidth of a tunnel can be set manually, whereas the traffic of the tunnel is changeable.
To ensure continuity of traffic, you can set the bandwidth required by the maximum quantity of
traffic as reservable bandwidth. This can meet the requirement of traffic, whereas waste
bandwidth resources. In communications networks, bandwidth resources are valuable. To save
bandwidth, TE automatic bandwidth adjustment is developed.
The average bandwidth of a tunnel within a sampling period can be obtained through regular
sampling. After sampling for multiple times in a period, the bandwidth is recalculated according
to the average value of sampled values. Then, an LSP is set up according to the bandwidth. After
the LSP is successfully set up, traffic is switched to the LSP, and then the original LSP is deleted.
If the LSP fails to be set up, traffic is still transmitted along the original LSP. Then, the bandwidth
is adjusted after the next sampling period.
You can also set the maximum bandwidth and minimum bandwidth, and ensure that the
bandwidth is adjusted within the range.
NOTE
l By default, the automatic bandwidth adjustment is disabled on a tunnel.

l On a tunnel of multi-class type (multi-CT), the automatic bandwidth adjustment is not supported.
l The automatic bandwidth adjustment and the CR-LSP re-optimization cannot be configured together.
The automatic bandwidth adjustment is to trigger the bandwidth adjustment of a tunnel in a

specified interval.
The sampling period takes effect on various types of MPLS TE tunnels except for static TE
tunnels and multi-CT tunnels. The outbound interface rate of an MPLS TE tunnel is recorded
after a sampling period. In this manner, the average bandwidth of the MPLS TE tunnel in a
sampling period can be obtained.
After the automatic bandwidth adjustment is enabled on an MPLS TE tunnel, when the
adjustment frequency timer expires, the system adopts the maximum value among the sampled
values within the period specified by the timer as the bandwidth constraint, and then initiates a
request for setting up an LSP. After the LSP is successfully set up, traffic is switched to the LSP,
and then the original LSP is torn down; if the LSP fails to be set up, traffic is still transmitted
through the original LSP.
Issue 02 (2011-09-10)

63

3 MPLS TE
The automatic bandwidth adjustment works in the following configurable modes:

l
Adjustment mode: The system automatically collects traffic information and automatically
adjusts bandwidth of a tunnel.
Collect-BW mode: The system only automatically collects traffic information, but does not
automatically adjust the bandwidth of a tunnel.
3.3.5 Re-optimization
In automatic re-optimization, the path of a CR-LSP is recalculated at certain intervals. In this
manner, the path of the CR-LSP is optimized.
TE aims at optimizing the distribution of traffic in a network. After a CR-LSP is established,
the path of the CR-LSP can be recalculated according to the change of the bandwidth, traffic,
or management policy in a network. A CR-LSP is optimized if a better path is found. That is,
the CR-LSP is re-set up only when a better path with a smaller metric exists.
The CR-LSP re-optimization is performed in the following modes:
l
Automatic re-optimization: You can specify an interval for optimizing a CR-LSP. After
the interval expires, the CR-LSP automatically finds for a better path to perform reoptimization.
Manual re-optimization: You can run a command line to trigger CR-LSP re-optimization
and request the system to recalculate a better path to set up a CR-LSP.
When CR-LSP re-optimization is in process, traffic must be uninterrupted. That is, the traffic
must be switched to a new CR-LSP before the original CR-LSP is torn down. On the link shared
by the new and original CR-LSPs, the bandwidth of the shared link must be calculated twice
because the bandwidth of the original CR-LSP is not released before the new CR-LSP is set up.
Otherwise, the new CR-LSP cannot be set up because of a lack of bandwidth.
The SE (Shared-Explicit) reservation style of RSVP-TE can solve this problem. The SE style
allows the original and new CR-LSPs to share resources; therefore, the new CR-LSP can be set
up before the original CR-LSP is torn down.
NOTE
l By default, re-optimization is not performed. If re-optimization is enabled, the default interval for reoptimizing a CR-LSP is 3600 seconds.
l The automatic re-optimization and the automatic bandwidth adjustment cannot be configured together.
l If the FF reservation style is adopted, the CR-LSP re-optimization cannot be configured.
The implementation of CR-LSP re-optimization is as follows:

l
In automatic re-optimization, when the specified interval for optimizing a CR-LSP expires,
Constraint Shortest Path First (CSPF) is triggered to calculate the path of the CR-LSP. If
the path calculated by CSPF has a metric smaller than that of the existing CR-LSP, a new
CR-LSP is set up along the new path. If the CR-LSP is successfully set up, the system
notifies the forwarding plane to switch traffic and delete the original CR-LSP. After the
process, re-optimization is complete. If the CR-LSP is not successfully set up, the traffic
is still forwarded along the existing CR-LSP.
In manual re-optimization, a re-optimization command is run in the user view to trigger reoptimization.
Issue 02 (2011-09-10)

64

3 MPLS TE
3.3.6 TE FRR
TE Fast Reroute (FRR) is a local protection mechanism to protect CR-LSPs against link failures
or node failures. In addition, FRR can perform bandwidth protection or non-bandwidth
protection for the primary CR-LSP.
In TE FRR, bypass CR-LSPs that detour the failed link or failed node are pre-established to
protect the primary CR-LSP. When the link or node is faulty on a CR-LSP, traffic is transmitted
through the bypass CR-LSP and the ingress can simultaneously initiate the setup of the primary
CR-LSP without interrupting data transmission.
The concepts related to FRR are as follows:
l
Primary CR-LSP: It is the CR-LSP that is protected.
Bypass CR-LSP: It is the CR-LSP that protects the primary CR-LSP. On the bypass CRLSP, the Point of Local Repair (PLR) is the ingress and the Merge Point (MP) is the egress.
The bypass CR-LSP is usually in the idle state and hardly transmits data. If you need the
bypass CR-LSP to forward service data when it protects the primary CR-LSP, you must
allocate sufficient bandwidth to the bypass CR-LSP.
PLR: The PLR is the ingress of the bypass CR-LSP and must be on the path of the primary
CR-LSP. The PLR can be the ingress rather than the egress of the primary CR-LSP.
MP: The MP is the egress of the bypass CR-LSP and must be on the path of the primary
CR-LSP. The MP cannot be the ingress of the primary CR-LSP.
Link protection: The PLR (LSRB) and the MP (LSRC) are directly connected, and the
primary CR-LSP passes through the link, as shown in Figure 3-8. When the link fails,
traffic can be switched to the bypass CR-LSP along the path LSRB -> LSRF -> LSRC.
Figure 3-8 Schematic diagram of FRR link protection
PLR
LSRA
LSRB
MP
LSRC
LSRD
Primary LSP
Bypass LSP
LSRF
Issue 02 (2011-09-10)
Node protection: A node (LSRC) exists between the PLR (LSRB) and the MP (LSRD) and
the primary CR-LSP passes through the node (LSRC), as shown in Figure 3-9. When LSRC
fails, traffic can be switched to the bypass CR-LSP along the path LSRB -> LSRF -> LSRD.

65

3 MPLS TE
Figure 3-9 Networking diagram of FRR node protection
PLR
R1
R2
MP
R3
R4
R5
Primary LSP
Bypass LSP
R6
Setup of the primary CR-LSP

The setup of the primary CR-LSP is the same as the setup of a common CR-LSP.
Differently, during the setup of the primary CR-LSP, the ingress adds the local protection
desired flag, label recording desired flag, and the SE style desired flag to the Path message.
If bandwidth protection is required, the bandwidth protection desired flag is also added to
the Path message.
Bypass CR-LSP binding

The process of searching for a suitable bypass CR-LSP is also called bypass CR-LSP
binding. The primary CR-LSP only with the local protection desired flag can trigger the
binding policy. The binding must be complete before CR-LSP switchover is performed.
During the binding, the node must obtain information about the outbound interface of the
bypass CR-LSP, Next Hop Label Forwarding Entry (NHLFE), Label Switching Router
(LSR) ID of the MP, label allocated by the MP, and protection type.
For the ingress and the transit node, the next hop (NHOP) and next NHOP (NNHOP) of
the primary CR-LSP are known. If the egress LSR ID of the bypass CR-LSP is equal to the
LSR ID of the NHOP, the link of the primary CR-LSP is under protection; if the egress
LSR ID of the bypass CR-LSP is equal to the LSR ID of the NNHOP, the NHOP is under
protection.
When multiple bypass CR-LSPs are available to protect the same CR-LSP, you can choose
the bypass CR-LSP that meets the bandwidth requirement. When the bandwidth
requirement is met, node protection takes precedence over link protection, and manual
protection takes precedence over auto protection.
If a bypass CR-LSP is successfully bound to the primary CR-LSP, the NHLFE of the primary
CR-LSP records the NHLFE index of the bypass CR-LSP and the label allocated by the MP to
the upstream node, namely, the inner label. An inner label is used to forward traffic during FRR
switching.
l
Fault detection
Link protection directly uses a link layer protocol to detect and advertise faults. The speed
of fault discovery on the link layer depends on the link type. Node protection uses the link
layer protocol to detect link faults. If no fault occurs on a link, the bidirectional forwarding
detection (BFD) mechanism can be configured to detect faults of the protected node.
In node protection, only the protected node and the link between the protected node and
the PLR is protected. The PLR, however, cannot detect the faults on the link between the
protected node and the MP.
After a link fault or a node fault is detected, the outbound interface on the PLR is set as the
stale state, which triggers FRR switching.
Issue 02 (2011-09-10)

66

3 MPLS TE
Switchover
When the primary CR-LSP fails, both traffic and RSVP messages must be switched to the
bypass CR-LSP, and the switchover event needs to be advertised upstream. During
switchover, the NHLFE of the primary CR-LSP is set with a switchover flag.
Switchback
After primary/bypass CR-LSP switchover, the PLR sends upstream a PathError message
carrying the switchover flag. The ingress tries to re-create the primary CR-LSP instead of
tearing it down after receiving the PathError message. The ingress forwards data through
the bypass CR-LSP until the primary CR-LSP is re-created successfully. The primary CRLSP that the ingress tries to re-created is called the modified CR-LSP.
If the primary CR-LSP is successfully re-created, the traffic and RSVP messages are
switched back to the primary CR-LSP. During switchback, TE FRR (including Auto FRR)
adopts the make-before-break mechanism. That is, the original primary CR-LSP is torn
down only after the modified CR-LSP is set up successfully.
Figure 3-10 Schematic diagram of TE FRR
R1
R2
R3
R4
R5
As shown in Figure 3-10, the primary CR-LSP is along the path LSRA -> LSRB -> LSRC ->
LSRD and the bypass CR-LSP is along the path LSRA -> LSRE -> LSRC. LSRB is the node
to be protected.
When the primary CR-LSP fails, the system uses the bypass CR-LSP to forward data and
attempts to set up a modified CR-LSP. After the modified CR-LSP is successfully set up along
the original path, traffic is switched to the modified CR-LSP along the path LSRA -> LSRB ->
LSRC -> LSRD and the original primary CR-LSP is torn down.
Auto TE FRR
In TE FRR, to set up a CR-LSP to be protected, you must set up a bypass CR-LSP and bind it
and the CR-LSP to be protected. When the link or node is faulty, data can be automatically
switched to the bypass CR-LSP.
Therefore, the FRR protection can take effect only when the bypass CR-LSP is manually set up.
If the bypass CR-LSP is not set up or the configuration of the bypass CR-LSP does not meet the
requirement, the protection of the CR-LSP does not take effect. To simplify the configuration
and remain the FRR feature, Auto TE FRR is developed.
After a primary CR-LSP to be protected by FRR is set up on a device enabled with Auto TE
FRR, and enabled with bandwidth protection or non-bandwidth protection, the device
automatically tries to set up an auto bypass CR-LSP that is eligible and optimal. After the
establishment succeeds, the auto bypass CR-LSP can protect the primary CR-LSP.
Issue 02 (2011-09-10)

67

3 MPLS TE
The implementation of Auto TE FRR is the same as that of the manually-configured TE FRR.
The bypass CR-LSP in manual TE FRR needs to be set up manually; however, the bypass CRLSP in Auto TE FRR is generated through calculation based on a policy.
Precedence of Protection Modes in TE FRR

TE FRR protection modes are as follows:
l
Bandwidth protection and non-bandwidth protection
Node protection and link protection
Manual protection and auto protection
Bandwidth protection and non-bandwidth protection are both defined manually.When required,
you can choose the bypass CR-LSP that meets the bandwidth requirement. When the bandwidth
requirement is met, node protection takes precedence over link protection, and manual protection
takes precedence over auto protection.
Board Hot Pulling-out Protection

Board hot pulling-out protection indicates that when the interface board where an outbound
interface of a primary CR-LSP on a PLR resides is pulled out, the MPLS TE traffic is swiftly
switched to the bypass CR-LSP. After the interface board is re-inserted, if the outbound interface
of the primary CR-LSP is still available, the MPLS TE traffic is switched back to the primary
CR-LSP. Board Hot Pulling-out Protection is used to protect the outbound interface of the
primary CR-LSP on a PLR.
Usually, if an interface board configured with a TE tunnel interface is pulled out, tunnel
information is lost. When Board Hot Pulling-out Protection is adopted, the tunnel interface of
the primary CR-LSP on a PLR, the tunnel interface of the bypass CR-LSP, and the outbound
interface of the bypass CR-LSP must not reside on the interface board to be pulled out. It is
recommended that you configure TE tunnel interfaces of the ingress on the main control board.
After configuring TE tunnel interfaces of the ingress on the main control board, if the interface
board where the physical outbound interface of the primary CR-LSP resides is pulled out or
fails, the interface becomes Stale and the FRR-enabled primary CR-LSP is not deleted. When
the interface board is re-inserted, the interface restores available and a primary CR-LSP is reestablished.
Deploying of TE FRR
TE FRR is a local protection mechanism in MPLS TE. When deploying a bypass CR-LSP, you
must plan the link or node protected by the bypass CR-LSP, and ensure that this bypass CR-LSP
does not pass through the link or node that it protects. Otherwise, the protection does not take
effect.
FRR does not take effect when the primary CR-LSP and the bypass CR-LSP fail at the same
time. That is, if FRR is performed, data is switched from the primary CR-LSP to the bypass CRLSP. When the bypass CR-LSP forwards data, the bypass CR-LSP must be Up all the time. If
the bypass CR-LSP is faulty, the protected data, however, cannot be forwarded through MPLS.
As a result, data transmission is interrupted and the FRR function is invalidated. Though the
bypass CR-LSP is re-created, it cannot forward data. Data can be forwarded only after the
primary CR-LSP restores or is re-created.
TE FRR supports the N:1 protection mode. That is, a bypass CR-LSP can protect multiple
primary CR-LSPs.
Issue 02 (2011-09-10)

68

3 MPLS TE
In addition, FRR needs to occupy additional bandwidth for establishing the bypass CR-LSP in
advance. If the remaining network bandwidth is insufficient, FRR can protect only the key link
or node.
3.3.7 SRLG
Shared Risk Link Group (SRLG) is a set of links at the same risk of faults. If a link in an SRLG
fails, other links also fail. In this case, if the other link in the SRLG functions as the hot-standby
CR-LSP or FRR bypass CR-LSP to protect the failed link, protection does not take effect.
SRLG is a link attribute, in numerical notation. The links with the same SRLG value are in one
SRLG. Configuring the SRLG attribute can limit the selection of paths for the hot-standby CRLSP and FRR bypass CR-LSP, which prevents the primary and bypass (or hot-standby) CRLSPs from being set up along the links at the same risks.
Figure 3-11 Networking diagram of the SRLG
LSRF
SRLG 30
LSRA
LSRB
LSRC
LSRD
LSRE
SRLG 20
LSRG
SRLG 20
As shown in Figure 3-11, take TE FRR as an example. The primary CR-LSP is along the path
R1 -> R2 -> R3 -> R4 -> R5, and the link R2 -> R3 -> R4 needs to be protected by an FRR
bypass CR-LSP. On R2, two bypass CR-LSPs are set up along the path R2 -> R6 -> R4 and the
path R2 -> R8 -> R4, respectively.
During the deployment, the path between R2 and R3 and the path between R8 and R4 share the
same risk. That is, if the bypass CR-LSP is set up along the path R2 -> R8 -> R4, when the link
between R2 and R3 fails, the link between R8 and R4 also fails. The protection, therefore, cannot
take effect.
Therefore, before the configuration of CR-LSPs, it is recommended that you collect and
configure the SRLG information for links. The links between R2 and R3 and between R8 and
R4 can be configured with the same SRLG value. That is, both links are in the same SRLG. This
ensures that the primary CR-LSP selects a bypass CR-LSP that is not in the same SRLG.
Principles
The SRLG attribute is distributed in the TE extension based on an Interior Gateway Protocol
(IGP). When the SRLG attribute is used, the SRLG value is also a constraint like the bandwidth
that is used by CSPF to calculates paths.
Issue 02 (2011-09-10)

69

3 MPLS TE
MPLS TE SRLG works in either of the following modes:

l
Strict mode: The SRLG attribute is a required constraint when the CSPF calculates the
paths for the hot-standby CR-LSP or FRR bypass CR-LSP.
Preferred mode: The SRLG attribute is an optional constraint when the CSPF calculates
the paths for the hot-standby CR-LSP or FRR bypass CR-LSP. For example, when a hotstandby CR-LSP is set up, if the CSPF fails to calculate the path according to the SRLG
attribute, the CSPF recalculates the path regardless of the SRLG attribute.
The SRLG mode and the SRLG information on an interface are configured locally. SRLG
information about the link can be advertised to the entire autonomous system (AS) through IGP
routes. That is, nodes in the same AS can obtain SRLG information about all links. The CSPF
calculates paths according to the configured SRLG mode and SRLG information on the current
node.
3.3.8 CR-LSP Backup

On one tunnel, a CR-LSP that protects traffic on a primary CR-LSP is called a backup CR-LSP.
A backup CR-LSP protects traffic on key CR-LSPs, playing an important role in traffic
protection. If the primary CR-LSP fails, traffic can switch to the backup CR-LSP.
When the ingress detects that the primary CR-LSP is unavailable, it switches traffic to the backup
CR-LSP. After the primary CR-LSP recovers from the fault, the traffic switches back. In this
manner, traffic on the primary CR-LSP is protected.
CR-LSP backup is performed in the one of the following modes:
l
Hot standby: A backup CR-LSP is set up at the same time a primary CR-LSP is set up. If
the primary CR-LSP fails, traffic immediately switches to the backup CR-LSP. When the
primary CR-LSP recovers, traffic switches back to the primary CR-LSP. The hot-standby
CR-LSP and the best-effort path can be set up together.
Ordinary backup: A backup CR-LSP is set up after a primary CR-LSP fails. When the
primary CR-LSP fails, traffic switches to the backup CR-LSP; when the primary CR-LSP
recvoers, the traffic switches back to the primary CR-LSP.
Table 3-1 shows the differences between hot standby and ordinary backup.
Table 3-1 Differences between a hot standby CR-LSP and an ordinary backup CR-LSP
Issue 02 (2011-09-10)
Item
Hot-Standby CR-LSP
Ordinary Backup CR-LSP
When a backup
CR-LSP is set
up
The backup CR-LSP is set up

at the same time the primary
CR-LSP is Up.
The backup CR-LSP is set up only if

the primary CR-LSP fails.
Explicit path
Whether or not a primary CRLSP overlaps a backup CRLSP can be determined

manually. If an explicit path is
allowed for a backup CR-LSP,
the backup CR-LSP can be set
up over an explicit path.
No matter whether the backup CRLSP is set up along an explicit path,

the backup CR-LSP path will fully or
partially overlap the path of the
primary CR-LSP.

70

3 MPLS TE
Item
Hot-Standby CR-LSP
Ordinary Backup CR-LSP
Is a best-effort
path
established
Yes
A best-effort path can be established

together with an ordinary backup
CR-LSP that is set up by using
attribute templates.
NOTE
A backup CR-LSP can be configured with neither automatic bandwidth adjustment nor reoptimization.
Best-effort path
A hot-standby CR-LSP can be set up together with a best-effort path, whereas an ordinary
backup CR-LSP cannot. Failures of both primary and backup CR-LSPs can trigger the setup
of a temporary CR-LSP, which is called a best-effort path. In such cases, traffic switches
to the best-effort path.
As shown in Figure 3-12, the primary CR-LSP adopts the path PE1 -> P1 -> PE2 and the
backup CR-LSP adopts the path PE1 -> P2 -> PE2. If both the primary and backup CRLSPs are faulty, PE1 triggers the setup of a best-effort path PE1 -> P2 -> P1 -> PE2.
Figure 3-12 Schematic diagram of the best-effort path
P1
PE1
P2
PE2
Primary path
Secondary path
Best-effort path
NOTE
The bandwidth of a best-effort path is not guaranteed; the affinity attribute and hop limit can be set
for the best-effort path as required.
Make-Before-Break, deletion delay, and switching delay

A backup CR-LSP supports the make-before-break mechanism, deletion delay, and switching
delay. When the user changes a backup CR-LSP's Modify attribute, the system makes use of the
make-before-break mechanism to recreate the backup CR-LSP. After the backup CR-LSP with
a new Modify attribute has been successfully established, traffic on the original backup CR-LSP
(if it is transmitting traffic) switches to this new backup CR-LSP and the original backup CRLSP is deleted.
Issue 02 (2011-09-10)

71

3 MPLS TE
Traffic switches backup in one of the following situations:

l
Traffic switching from the best-effort path to the primary CR-LSP or backup CR-LSP is
prioritized. In descending order of priority, traffic will switch first to the primary CR-LSP,
which has the highest priority; if the primary CR-LSP is unavailable, traffic will switch to
the hot-standby CR-LSP; the ordinary CR-LSP has the lowest priority for traffic switching.
When traffic is being transmitted over an ordinary CR-LSP, traffic will switch from the
ordinary CR-LSP to a hot-standby CR-LSP with a higher priority than the ordinary CRLSP if the hot-standby CR-LSP is established earlier than the primary CR-LSP.
If the primary CR-LSP recovers while the backup CR-LSP is transmitting traffic, traffic
switches from the backup CR-LSP back to the primary CR-LSP.
The deletion delay and switching delay ensure that traffic is not dropped during a switchover.
For example, the process of switching traffic from an ordinary CR-LSP back to the primary CRLSP is as follows:
1.
After the primary CR-LSP goes Up, the system sets the buffer time for a switchback. During
the buffer time, traffic does not switch from the ordinary CR-LSP back to the primary CRLSP.
2.
Within the buffer time, the new entries are created along nodes of the primary CR-LSP.
3.
After the buffer time expires, traffic starts to switch back to the primary CR-LSP.
4.
After traffic successfully switches back, the ingress sets the buffer time for preparing for
deleting the ordinary CR-LSP. After the buffer time expires, the ordinary CR-LSP is deleted
from the TE tunnel.
Setting Up CR-LSPs in Sequence

In one tunnel, multiple options for setting up CR-LSPs exist. To ensure that a CR-LSP takes
over services as soon as possible, the system will try all options in sequence, first a primary CRLSP, then a hot-standby CR-LSP, and then an ordinary backup CR-LSP until a CR-LSP has
been successfully established.
The sequence for creating CR-LSPs is as follows:
1.
When a new tunnel is configured or a tunnel goes Down, the system first attempts to set
up a primary CR-LSP, then a hot-standby CR-LSP, then an ordinary backup CR-LSP, and
then a best-effort path in sequence until a CR-LSP is successfully established.
2.
You may configure a maximum of three CR-LSP attribute templates for hot-standby CRLSPs and three for ordinary backup CR-LSPs. These templates are prioritized. The system
uses them one by one in descending order of priority until a CR-LSP is successfully set up.
3.
If a CR-LSP has been set up using a lower-priority attribute template, in the event CR-LSP
status changes, the system will try to set up a CR-LSP using a higher-priority template.
During the upgrade, the system uses the make-before-break mechanism to create a new
CR-LSP, preventing traffic interruption.
Locking a Backup CR-LSP Attribute Template

As noted above, the system allows you to configure three prioritized attribute templates for hotstandby CR-LSPs and three for ordinary backup CR-LSPs. After an existing backup CR-LSP
has been set up using a lower priority attribute template, the system will continue to attempt to
set up a new backup CR-LSP using a higher priority attribute template.
If a stable CR-LSP has been set up using any of the attribute templates, users can lock this backup
CR-LSP attribute template in place. This will prevent the system from changing the attribute
Issue 02 (2011-09-10)

72

3 MPLS TE
template being used to a higher priority attribute template. When the attribute template is locked,
the system will not attempt to use a higher priority attribute template to set up a CR-LSP even
though the attribute template in use is of a lower priority. This avoids unnecessary traffic
switchover and saves system resources.
After a locked attribute template has been unlocked, the system will again be able to change
attribute templates automatically.
Dynamic Bandwidth Protection for Hot-standby CR-LSPs

Hot-standby CR-LSPs can be configured with dynamic bandwidth protection. The dynamic
bandwidth protection function allows a hot-standby CR-LSP to make use of bandwidth resources
only after it takes over traffic from a faulty primary CR-LSP. This saves network resources and
reduces network costs.
After dynamic bandwidth protection is enabled, the hot-standby CR-LSP does not occupy any
bandwidth as long as the primary CR-LSP is transmitting traffic. The dynamic bandwidth
protection process works as follows:
1.
When the primary CR-LSP fails, traffic immediately switches to the hot-standby CR-LSP
with bandwidth at 0 kbits/s. In addition, the ingress uses the make-before-break mechanism
to trigger the reestablishment of a hot-standby CR-LSP.
2.
When the new hot-standby CR-LSP has been successfully set up, the system switches traffic
to this CR-LSP and deletes the hot-standby CR-LSP with bandwidth at 0 kbits/s.
3.
When the primary CR-LSP recovers, traffic switches back to the primary CR-LSP. At this
time, the hot-standby CR-LSP releases the bandwidth it occupies and this bandwidth is
then used by the system to set up another hot-standby CR-LSP.
Path Overlapping Function for Hot-standby CR-LSPs

The path overlapping function can be configured for hot-standby CR-LSPs. This function allows
a hot-standby CR-LSP to use links of a primary CR-LSP. After the hot-standby CR-LSP is
established, it can protect traffic on the primary CR-LSP.
Comparison with Other Features

1.
CR-LSP backup and TE FRR are different:

l CR-LSP backup is a type of end-to-end path protection, providing protection for an
entire CR-LSP.
l FRR provides local protection. It protects only a certain link or a certain node along a
CR-LSP. In addition, FRR is a temporary protection mechanism for swift responses. It
demands short switchover time.
2.
CR-LSP backup is often deployed together with FRR.

Common network combinations include:
l CR-LSP hot standby together with TE FRR: FRR rapidly senses a link fault and switches
traffic to the bypass tunnel. After information about the link fault is sent to the ingress
through signaling, traffic switches to the hot-standby CR-LSP.
l CR-LSP ordinary backup together with TE FRR: FRR rapidly senses a link fault and
switches traffic to the bypass tunnel. If both the primary TE FRR tunnel and bypass TE
FRR tunnel fail, traffic switches to the ordinary backup CR-LSP.
Issue 02 (2011-09-10)

73

3 MPLS TE
NOTE
If the primary tunnel is enabled with synchronization between the bypass tunnel and backup CRLSP. If the primary CR-LSP fails, traffic switches to the TE FRR bypass tunnel. In addition, the
primary CR-LSP is being restored while the backup CR-LSP is also being created. When the
backup CR-LSP is successfully created and the primary CR-LSP does not recovers, traffic
switches to the backup CR-LSP.
3.
CR-LSP backup is associated with FRR.

You can configure a TE FRR bypass tunnel and end-to-end backup CR-LSP together. The
backup CR-LSP is more reliable than a TE FRR bypass tunnel. Therefore, to increase
security of the tunnel, it is recommended that you configure both the TE FRR bypass tunnel
and the backup CR-LSP. After association between CR-LSP backup and FRR is enabled:
l If ordinary backup is configured, the following conditions apply:
When protected link or node fails, the system switches traffic to the TE FRR bypass
tunnel and attempts to restore the primary CR-LSP. At the same time, the system also
attempts to set up a backup CR-LSP.
If the backup CR-LSP has been set up successfully and the primary CR-LSP has not
been restored, traffic switches to the backup CR-LSP.
Once the primary CR-LSP has been restored successfully, traffic switches back to the
primary CR-LSP, whether the traffic is on the TE FRR bypass tunnel or the backup CRLSP.
When set up of the backup CR-LSP has failed and the primary CR-LSP has not been
restored, traffic continues to pass through the TE FRR bypass tunnel.
l If hot standby is configured, the following conditions apply:
If the backup CR-LSP is in the Up state and protected link or node faults occur, traffic
switches to the TE FRR bypass tunnel and then immediately to the backup CR-LSP. At
the same time, the system attempts to restore the primary CR-LSP.
If the backup CR-LSP is in the Down state, the conditions for traffic switches are the
same as ordinary backup mode.
When the primary CR-LSP is Up, a hot-standby CR-LSP is also set up. After this backup
CR-LSP has been successfully created, more bandwidth resources are needed. The ordinary
backup CR-LSP is set up only when the primary CR-LSP is in the FRR-in-use state. This
means that as long as the primary CR-LSP works normally, no more bandwidth is needed.
Therefore, it is recommended that ordinary backup to be used together with TE FRR.
4.
The difference between CR-LSP backup and the tunnel protection groups is as follows:
CR-LSP backup and tunnel protection groups are two types of end-to-end protection
mechanisms in MPLS TE. Table 3-2 shows the differences between these two mechanisms.
Table 3-2 Differences between CR-LSP backup and the tunnel protection group
Issue 02 (2011-09-10)
Item
CR-LSP Backup
Tunnel Protection Group
Object to be
protected
Primary and backup CR-LSPs

are set up on the same tunnel. The
backup CR-LSP protects the
primary CR-LSP.
In a tunnel protection group, one

tunnel protects another tunnel.

74

3 MPLS TE
Item
CR-LSP Backup
Tunnel Protection Group
TE FRR
Only the primary CR-LSP

supports TE FRR. The backup
CR-LSP does not support TE
FRR.
The primary tunnel supports TE FRR.

The protection tunnel does not support
TE FRR.
LSP attributes
With the exception of the TE

FRR attribute, the primary CRLSP and the backup CR-LSP
have the same attributes. In
addition, bandwidth for the
backup CR-LSP can be set
separately.
The attributes of one tunnel in the

tunnel protection group are
independent of the attributes of the
other tunnel. For example, a protection
tunnel with no bandwidth can protect
the primary CR-LSP that has a
bandwidth.
Protection mode A 1:1 protection mode is

supported. That is, each primary
CR-LSP has a backup CR-LSP.
An N:1 protection mode is supported.

That is, multiple CR-LSPs share one
protection tunnel. When any primary
CR-LSP fails, data switches to the
same shared protection tunnel.
3.3.9 DS-TE
Definition
MPLS DS-TE combines Multi-Protocol Label Switching Traffic Engineering (MPLS TE) and
the Differentiated Service (Diff-Serv) to provide Quality of Service (QoS) guarantee.
In MPLS DS-TE, MPLS TE is responsible for establishing Label Switched Paths (LSPs) to
control traffic paths precisely and ensure bandwidth, and providing the multi-protection
mechanism to improve service reliability; Diff-Serv is responsible for performing Class of
Service (CoS) to reserve resources according to the CoS granularity, set control policies and
guarantee mechanisms, thus providing QoS guarantee.
Purpose
With the development of network technologies, IP networks based on packet exchanges take
the place of ATM and FR networks based on circuit switching gradually. In addition, the types
of services provided by the Internet Service Provider (ISP) develop from data services or voice
services into an integration of video, voice, and data services. With the merge of business
behaviors and networks, the ISP carries increasing traffic volumes and provides more types of
services. In this situation, users pay more attention to whether the ISP can guarantee QoS.
The Diff-Serv model classifies user services into different types and then performs differentiated
traffic forwarding according to the CoS, thus meeting different QoS requirements. The DiffServ model is excellent in scalability. It is because data streams of multiple services are mapped
with only several CoSs and thus the amount of information to be maintained is in direct
proportion to the type of data streams rather than the number of data streams.
The Diff-Serv model, however, can reserve resources only on a single node rather than ensure
QoS along the entire path.
MPLS TE establishes the LSP by using available resources along the link. In this manner, it
provides guaranteed bandwidth for specific traffic whenever the network is stable or failed. An
Issue 02 (2011-09-10)

75

3 MPLS TE
LSP can be established only when there are available resources. This improves the bandwidth
utilization of the current device. MPLS TE can also precisely control traffic paths so that current
bandwidth can be made full use of.
MPLS TE, however, cannot provide differentiated QoS guarantees for traffic of different types.
Suppose that there are two types of traffic: voice traffic and video data. Video frames may be
repeated for a long time, so it may be required that video traffic be of higher discard priority
than voice traffic. MPLS TE does not classify traffic but assigns voice traffic and video traffic
the same discard priority.
MPLS DS-TE integrates the advantages of Diff-Serv and TE technologies. TE can guarantee
bandwidth resources and improve reliability by realizing fault fast recovery through mechanisms
such as link protection. DS-TE classifies services based on the CoS and reserves resources based
on CoS granularity. In addition, DS-TE provides the MPLS fault tolerance mechanism for every
CoS and configures rate limit and access permission control. Thus, traffic can be confined to the
range that is set during resource reservation. In this manner, QoS is guaranteed.
Benefits
DS-TE establishes the LSP along the link by using available resources. In this manner, it provides
guaranteed bandwidth for specific traffic to avoid congestion whenever the network is stable or
failed. An LSP is established only when there are available resources. This improves the
bandwidth availability of the current device.
DS-TE can enable fast failure recovery through link protection and Fast ReRoute (FRR). Thus,
services' reliability is improved.
DS-TE classifies services based on the CoS and reserves resources based on CoS granularity.
In addition, DS-TE provides different MPLS fault tolerance mechanisms for each CoS level and
configures rate limit and access permission control. Thus, traffic can be confined to the range
that is set during resource reservation and QoS is provided so that strict Service Level Agreement
(SLA) is met, such as voice, ATM, and FR.
Basic Concepts of MPLS DS-TE

l
DS field
To implement Diff-Serv, the ToS field in an IPv4 header is redefined in RFC 2474 and then
called the Differentiated Services (DS) field. In the DS field, higher two bits are reserved
and lower six bits are the DS CodePoint (DSCP).
PHB
Per-Hop Behavior (PHB) is used to describe the next action on packets with the same DSCP.
Generally, PHBs include traffic features such as delay and packet loss ratio.
At present, the IETF defines three standard PHBs: Expedited Forwarding (EF), Assured
Forwarding (AF), and Best-Effort (BE). BE is the default PHB.
CT
To provide differentiated services, DS-TE divides the LSP bandwidth into one to eight
parts, each part corresponding to a CoS. Such a collection of bandwidths of an LSP or a
group of LSPs with the same CoS is called a CT. A CT can transmit only the traffic of a
CoS.
IETF defines that DS-TE can support up to eight CTs, marked as CTi, in which i ranges
from 0 to 7.
l
Issue 02 (2011-09-10)
Single-CT and multi-CT

76

3 MPLS TE
Single-CT indicates that an LSP can transmit only the traffic of a single CT.
Multi-CT indicates that an LSP can concurrently transmit the traffic of multiple CTs. In
multi-CTs, resource reservation, LSP establishment, or bandwidth preemption can be
implemented only when bandwidths of all CTs are sufficient.
Huawei DS-TE supports both the single-CT and the multi-CT.
l
TE-Class
TE-Class refers to the combination of a CT and a priority, in the format of <CT, priority>.
The priority is the preemption priority of the CR-LSP rather than the EXP value in the
MPLS header. The value of the priority is an integer ranging from 0 to 7. The smaller the
value, the higher the priority. A CR-LSP can be set up only when both <CT, setup-priority>
and <CT, holding-priority> exist in the TE-class mapping table. Assume that the TE-class
mapping table of a node contains only TE-Class [0] = <CT0, 6> and TE-Class [1] = <CT0,
7>, only can the following three types of CR-LSPs be successfully set up:
Class-Type=CT0, setup-priority=6, hold-priority=6
CTs and priorities can be in any combination. Therefore, there are 64 TE-Classes
theoretically. The CX600 supports a maximum of eight TE-Classes. which are specified
through user configurations.
DS-TE
DS-TE has two modes:
IETF mode: The IETF mode is defined by IETF and supports 64 TE-Classes by
combining 8 CTs and 8 priorities. The CX600 supports up to 8 TE-Classes.
Non-IETF mode: The non-IETF mode is not defined by IETF and supports 16 TEClasses by combining 2 CTs and 8 priorities.
TE-Class mapping table

The TE-Class mapping table consists of a group of TE-Classes. In the CX600, the TE-Class
mapping table consists of a maximum of 8 TE-Classes. As for an LSP allocated with
bandwidth, when configuring the ingress or reserving resources along the nodes of the LSP,
you need to take the TE-Class mapping table into account. Otherwise, the LSP cannot be
set up successfully. It is recommended that all Label Switching Routers (LSRs) in the MPLS
network be configured with the same TE-Class mapping table.
BCM
The Bandwidth Constraints Model (BCM) defines the maximum number of Bandwidth
Constraints (BCs), such as CTs that use the bandwidth of each BC, and how to use BC bandwidth.
Principle for Combining MPLS TE and Diff-Serv

The Label Edge Router (LER) of the MPLS Diff-Serv domain sorts traffic into a small number
of classes and marks the class information in the DSCP field of packets. When scheduling and
forwarding packets, LSRs select the PHBs according to the DSCP values.
The EXP field in the MPLS header can carry Diff-Serv information. The key to implementing
DS-TE is to map the DSCP value (with a maximum number of 64 values) to the EXP field (with
a maximum number of eight values). RFC 3270 provides the following solutions:
Issue 02 (2011-09-10)

77

3 MPLS TE
Label-Only-Inferred-PSC LSP (L-LSP): The discard priority is set in the EXP field and the
PHB type is determined by the label. During forwarding, MPLS labels determine the LSP
of datagrams and allocate scheduling behaviors to packets.
EXP-Inferred-PSC LSP (E-LSP): The scheduling type and the discard priority are set in
the EXP field in the MPLS label. During forwarding, the label determines the LSP of
datagrams, and the EXP field determines PHB. E-LSPs are applicable to a network with
up to eight PHBs.
In the CX600, E-LSPs are implemented. The mapping from the DSCP value to the EXP field
complies with RFC 3270. The mapping from the EXP field to the PHB is manually configured.
The Class Type (CT) is used in DS-TE to allocate resources based on the class of traffic. DSTE maps traffic with the same PHB to one CT and allocates resources for each CT. Therefore,
a DS-TE LSP is set up based on the CT. That is, when DS-TE calculates an LSP, it needs to take
CTs and obtainable bandwidth of each CT as constraints; when DS-TE reserves resources for
the LSRs along an LSP, it needs to consider CTs and their bandwidth requirements.
IGP and RSVP Extensions

To support DS-TE, RFC 4124 extends IGP by introducing the optional bandwidth constraints
sub-TLV and redefining the original unreserved bandwidth sub-TLV. This helps inform and
collect information about reservable bandwidths of CTs with different priorities on the link.
In addition, the IETF extends RSVP by defining a CLASSTYPE object for the Path message in
RFC 4124 and defining an EXTENDED_CLASSTYPE object in draft-minei-diffserv-te-multiclass. For details about CLASSTYPE and EXTENDED_CLASSTYPE objects, see RFC 4124
and draft-minei-diffserv-te-multi-class.
After an LSR along an LSP receives the RSVP Path messages carrying CT information, an LSP
is set up if resources are sufficient. After the LSP is successfully set up, the LSR recalculates
the reservable bandwidth of each CT corresponding to each priority. The reserved information
is sent to the IGP module to advertise to other LSRs on the network.
Currently, the IETF defines the following BCMs:
l
Maximum Allocation Model (MAM): maps a BC to a CT and CTs do not share bandwidth
resources. The BC mode ID of the MAM is 1.
Figure 3-13 Schematic diagram of the MAM
BC0
BC1
...
BC7
Max Researvable Bandwidth >= BC0+BC1+...+BC7
In the MAM, the sum of CTi LSP bandwidths does not exceed BCi (i ranges from 0 to 7);
the sum of bandwidths of all LSPs of all CTs does not exceed the maximum reservable
bandwidth of the link.
For example, assume that a link with the bandwidth of 100 Mbit/s adopts the MAM and
supports three CTs: CT0, CT1, and CT2. For example, assume that on a link, the bandwidth
is 100 Mbit/s and the MAM is adopted. BC0, which is 20 Mbit/s, carries CT0 (BE flows);
BC1, which is 50 Mbit/s, carries CT1 (AF flows); BC2, which is 30 Mbit/s, carries CT2
(EF flows). In this case, the total LSP bandwidths that are used to transmit BE flows cannot
Issue 02 (2011-09-10)

78

3 MPLS TE
exceed 20 Mbit/s; the total LSP bandwidths that are used to transmit AF flows cannot
exceed 50 Mbit/s; the total LSP bandwidths that are used to transmit EF flows cannot exceed
30 Mbit/s.
In the MAM, bandwidth preemption between CTs does not occur but certain bandwidth
resources may be wasted.
l
Russian Dolls Model (RDM): permits bandwidth sharing between CTs. The BC mode ID
of the RDM is 0.
The bandwidth of BC0 is smaller than the maximum reservable bandwidth on a link.
Nesting relationships exist among BCs. As shown in Figure 3-14, the bandwidth of BC7
is fixed; the bandwidth of BC6 nests the bandwidth of BC7...The bandwidth of BC0 nests
the bandwidth of all BCs. This model is similar to a Russian doll. A large doll nests a smaller
doll and then this smaller doll nests a much smaller doll, and so on.
Figure 3-14 Networking diagram of the RDM
BC7
CT7
....
BC0
BC1
CT1+...+CT7 CT0+CT1+...
+CT7
Max Reservable Bandwidth >= BC0>=BC1>=....>=BC7
For example, assume that a link with the bandwidth of 100 Mbit/s adopts the RDM and
supports 3 CTs (CT0, CT1, and CT2). CT0, CT1, and CT2 are used to transmit BE flows,
AF flows, and EF flows respectively. BC0 is 100 Mbit/s; BC1 is 50 Mbit/s; BC2 is 20 Mbit/
s. In this case, the total LSP bandwidths that are used to transmit expedited forwarding (EF)
flows do not exceed 20 Mbit/s; the total LSP bandwidths that are used to transmit EF flows
and AF flows do not exceed 50 Mbit/s; the total LSP bandwidths that are used to transmit
BE, AF, and EF flows do not exceed 100 Mbit/s.
The RDM allows bandwidth preemption among CTs. The preemption relationship among
CTs is: In the case of 0 <= m < n <= 7 and 0 <= i < j <= 7, CTi with the priority being m
can preempt the bandwidth of CTi with the priority being n and the bandwidth of CTj with
the priority being n. The total LSP bandwidths of CTi, however, does not exceed the
bandwidth of BCi.
In the RDM, bandwidth resources are used effectively.
l
Extended-MAM: indicates a bandwidth allocation mode that supports E-LSP. In the

extended-MAM, the BC model ID is 254.
The extended-MAM supports eight implicit TE-classes of the combinations of CT0 and
the priority being 0 to 7. Eight implicit CTs are flooded through the Unreserved BW TLV
of the IGP module.
Differences Between the IETF Mode and Non-IETF Mode

Huawei implements non-IETF DS-TE earlier than IETF DS-TE. In the network deployment or
device version upgrade, the non-DS-TE device may coexist with the DS-TE device. Therefore,
Issue 02 (2011-09-10)

79

3 MPLS TE
both the IETF mode and the non-IETF mode are designed for DS-TE so that the DS-TE devices
of different modes can interwork. The following lists the differences between the IETF mode
and the non-IETF mode.
Table 3-3 Differences between the IETF mode and non-IETF mode
DS-TE Mode
Non-IETF Mode
IETF Mode
Bandwidth model
Supports the MAM and RDM.
Supports the RDM, MAM,

and extended MAM.
CT type
Supports CT0 and CT1 in

single CT mode. CT0 and CT1
cannot be configured together.
Supports CT0 to CT7 in multiCT mode. Eight CTs can be

configured together.
BC type
Supports BC0 and BC1.
Supports BC0 to BC7.
TE-class mapping table
The TE-Class mapping table

can be configured but cannot
take effect.
The TE-Class mapping table

can be configured and take
effect.
IGP message
The priority-based reservable

bandwidth is carried in the
Unreserved bandwidth subTLV.
The CT information is carried

in the Unreserved bandwidth
sub-TLV and Bandwidth
Constraints sub-TLV.
RSVP message
The CT information is carried

in the CLASSTYPE object.
Single CT:
CT information is carried in
the CLASSTYPE object.
Multi-CT:
CT information is carried in
the EXTENDED_CLASSTYPE object.
Switching Between DS-TE Modes

The IETF mode and non-IETF mode can be switched between each other. The following table
shows the switching between the IETF mode and non-IETF mode.
Table 3-4 Switching between DS-TE modes
Issue 02 (2011-09-10)
Item
Non-IETF Mode to IETF

Mode
IETF Mode to Non-IETF

Mode
Changes of
bandwidth constraint
models
The bandwidth constraints model

is unchanged.
The extended-MAM is switched

to the MAM.

80

3 MPLS TE
Item
Non-IETF Mode to IETF

Mode
IETF Mode to Non-IETF

Mode
Changes of the TEclass mapping table
If the TE-Class mapping table is

not configured, adopt the default
TE-Class mapping table.
Otherwise, adopt the configured
one. For the default TE-Class
mapping table, see Table 3-5.
No TE-Class mapping table is

used.
LSPs with the combinations of

<CT, setup-priority> and <CT,
holding-priority> that are not in
the TE-class mapping table are
deleted from the ingress and
transit nodes.
The following types of LSPs are

deleted from the ingress and
transit nodes:
Deletion of LSPs
If a TE-Class mapping table is

configured, the TE-Class
mapping table is not deleted.
If no TE-Class mapping table is
configured, the default TE-Class
mapping table is deleted.
Multi-CT LSPs
Single-CT LSPs with a CT
ranging from CT2 to CT7
Table 3-5 Default TE-class mapping table

TE-Class
CT
Priority
TE-Class[0]
TE-Class[1]
TE-Class[2]
TE-Class[3]
TE-Class[4]
TE-Class[5]
TE-Class[6]
TE-Class[7]
Typical Networking
l
Application scenario 1: different services of a VPN transmitted over an MPLS TE tunnel

On VPNs using the MPLS TE tunnel, EF, AF, and BE services can be transmitted over the
same VPN. This means that different services may be transmitted over the same tunnel at
the same time.
To prevent mutual interference between different services in a TE tunnel, you can create
multiple VPNs and TE tunnels so that different tunnels transmit different services. If
multiple VPNs transmit different services concurrently on the network, a large number of
VPNs and TE tunnels need to be created, which is a waste of resources.
Issue 02 (2011-09-10)

81

3 MPLS TE
Another solution is to deploy DS-TE. A multi-CT LSP is used to transmit different services
of a VPN. A multi-CT LSP can be reserved for 8 CTs, each corresponding to a service of
a VPN. These services are mutually independent.
As shown in Figure 3-15, BE, AF, and EF services access VPN1 at the same time. You
need to set up only one TE tunnel, configure CT0 (100 Mbit/s), CT1 (50 Mbit/s), and CT2
(10 Mbit/s) for the tunnel, and bind VPN1 to the tunnel on the ingress. After the
configurations, all the traffic of VPN1 is classified and then enters the corresponding queue.
Figure 3-15 Networking diagram of different services of a VPN over an LSP
CT0 for BE: 100M bps

CT2 for AF: 50M bps
CT7 for EF: 10M bps
PE
MPLS TE tunnel
PE
VPN1
Site1
CE
CE
VPN1
Site2
Application scenario 2: traffic of different VPNs transmitted over an MPLS TE tunnel

On VPNs using the MPLS TE tunnel, multiple VPNs may use the same TE tunnel. These
VPNs have different requirements for QoS, which may cause VPNs to compete for
resources and thus QoS for each kind of service is not guaranteed. This scenario can be
divided into the following situations, for each of which a solution is provided:
Multiple VPNs with totally different services:
Multiple VPNs with totally different services: If the number of CoSs is less than or
equal to 8, a TE tunnel can be used to transmit these services.
For example, services of VPN1 and VPN2 are transmitted over the TE tunnel at the
same time. The CoS of VPN1 is EF and BE while the CoS of VPN2 is AF. In this case,
only one TE tunnel needs to be set up to configure different CTs for different services
of each VPN. The number of CTs is equal to 3, that is, the sum of the number of CoSs
of VPN1 plus the number of CoSs of VPN2.
Multiple VPNs with identical services
In this case, the required number of TE tunnels equals the number of VPNs. The required
number of CTs of each TE tunnel equals the number of services of the VPN.
For example, services of VPN1 and VPN2 are transmitted over the MPLS TE tunnel at
the same time. The CoSs of both VPN1 and VPN2 are EF and BE. In this case, two TE
tunnels need to be set up so that the services of different VPNs use different TE tunnels.
On each TE tunnel, CoSs are configured with corresponding CTs.
Multiple VPNs with partially same services:
Issue 02 (2011-09-10)

82

3 MPLS TE
In this case, a TE tunnel needs to be set up for each VPN. The required number of CTs
of each TE tunnel equals the number of services of the VPN.
l
Application scenario 3: VPN traffic and non-VPN traffic concurrently transmitted over an
MPLS TE tunnel
Both VPN traffic and non-VPN traffic coexist in the VPN and have different requirements
for QoS. If they are transmitted over a TE tunnel, it may cause VPN traffic and non-VPN
traffic to compete for resources and thus QoS for each kind of service is not guaranteed.
This scenario can be divided into the following situations, for each of which a solution is
provided:
CoSs of VPN traffic are totally different from CoSs of non-VPN traffic.
In this case, one TE tunnel needs to be set up to transmit traffic. Different CTs are
configured for the CoSs of VPN traffic and non-VPN traffic. The number of CTs equals
the service number of VPN traffic plus the service number of non-VPN traffic, as shown
in Figure 3-16.
CoSs of VPN traffic are identical with CoSs of non-VPN traffic.
Two TE tunnels need to be set up respectively for VPN traffic and non-VPN traffic. On
each TE tunnel, CoSs are configured with corresponding CTs, as shown in Figure
3-17.
CoSs of VPN traffic are partially same as CoSs of non-VPN traffic.
In this case, two TE tunnels need to be set up respectively for VPN traffic and non-VPN
traffic. On each TE tunnel, CoSs are configured with corresponding CTs, as shown in
Figure 3-17.
Figure 3-16 Networking diagram of VPN traffic and non-VPN traffic over a TE tunnel
Non-VPN
service
CT2 for AF: 50M bps
MPLS TE tunnel
PE
VPN
site 1
PE
CE
CE
CT0 for BE: 100M bps
CT7 for EF: 10M bps
VPN
site 2
VPN service
Issue 02 (2011-09-10)

83

3 MPLS TE
Figure 3-17 Networking diagram of VPN traffic and non-VPN traffic over two TE
tunnels respectively
Non-VPN
service
Tunnel1: CT2 for

AF: 50M bps
MPLS TE tunnel1
PE
PE
MPLS TE tunnel2
VPN
site 1
CE
CE
Tunnel2: CT0 for BE:
100M bps
VPN
site 2
VPN
service
Application scenario 4: DS-TE in TE tunnel protection

Both VPN traffic and non-VPN traffic coexist in the VPN and have different requirements
for QoS. If they are transmitted over a TE tunnel, it may cause VPN traffic and non-VPN
traffic to compete for resources and thus QoS for each kind of service is not guaranteed.
This scenario can be divided into the following situations, for each of which a solution is
provided:
Table 3-6 DS-TE in tunnel protection
Protection Mode
DS-TE Mode
TE FRR
It has two situations:

l Bandwidth protection is required: Manual FRR supports 1:1
protection and N:1 protection and guarantees QoS by manually
configuring CTs and bandwidths for bypass tunnels; auto FRR
supports only 1:1 protection and guarantees QoS through the
bypass tunnel inheriting the CTs and bandwidths of the
primary tunnel.
l Bandwidth protection is not required. CTs and bandwidths of
the bypass tunnel are not taken into consideration. Both
manual FRR and auto FRR support 1:1 protection and N:1
protection.
Issue 02 (2011-09-10)

84

3 MPLS TE
Protection Mode
DS-TE Mode
CR-LSP backup
The bypass tunnel inherits the CTs and bandwidths of the primary
tunnel. The best-effort path does not need to guarantee QoS.
Therefore, the best-effort path does not inherit the CT types and
bandwidth of the primary tunnel and only guarantees that traffic
can be forwarded.
Tunnel protection
group
A tunnel protection group is formed by binding two independent

configured tunnels that are in master/slave relationship.
Therefore, the DS-TE of the backup tunnel is determined by the
configuration. To guarantee QoS, the backup tunnel has the same
CT and bandwidth as the primary tunnel.
In addition, MPLS OAM detection packets are sent through the
queue with the highest priority on a TE tunnel.
These protection modes can be used in any combination to protect the primary TE tunnel.
For example, as shown in the following figure, CR-LSP backup is used together with FRR.
Figure 3-18 Application of the combination of CR-LSP and FRR
P1
Backup path of the primary
tunnel
PE1
P2
P3
P4
PE2
eth3
Primary path of the
primary tunnel
TE FRR backup tunnel
P5
Application scenario 5: interworking of devices in different DS-TE modes

In the network deployment or device version upgrade, the non-DS-TE device may coexist
with the DS-TE or the device in non-IETF mode may coexist with the device in IETF mode.
For non-MPLS DS-TE tunnels, the CX600 maps CT0 to AF. The CX600 supports device
interworking in the following cases:
Interworking between the DS-TE device and the non-DS-TE device
Supports the setup of a TE tunnel from the non-DS-TE device to the DS-TE device.
Supports the setup of a TE tunnel from the DS-TE device to the non-DS-TE device.
Supports the interworking with the DS-TE devices of other vendors that do not support
CT objects.
Issue 02 (2011-09-10)

85

3 MPLS TE
The CX600 can resolve the RSVP Path message carrying the following CT information:
The CT information about the L-LSP is carried in the EXTENDED_CLASSTYPE
object.
CT0 information is carried in the EXTENDED_CLASSTYPE object.
DS-TE Scheduling
The single-CT mode (CT1 or CT0) and non-standard DS-TE are supported. On the current
product, the TE protection mechanism is supported, and TE bandwidth assurance is also
supported in LDP over TE and RRVPN. In addition, on the hardware in support of HQoS, the
DS-TE capability with a maximum of eight CTs is supported.
Therefore, it is designed to implement standard DS-TE with eight CTs, priority scheduling for
eight CTs, bandwidth assurance of eight-CT DS TE (improved from the previous bandwidth
assurance of single-CT DS-TE), and flexible mappings between CTs and CoSs.
Traffic classification is performed on the traffic received by the ingress PE to prioritize packets.
Differentiated scheduling is performed for the packets sent by the ingress PE. Through fivehierarchical QoS scheduling, traffic is classified based on the priority in the Flow Queue (FQ);
total bandwidth is restricted in the Subscriber Queue (SQ), as shown in Figure 3-19.
Figure 3-19 HQoS Scheduling
Packets are not processed in the group queue (GQ). Interface-level HQoS is implemented by
each interface module and DS-TE does not change the interface-level HQoS function.
Users do not need to master the internal processing of HQoS but only need to configure the
mapping between CTs and FQs globally. Note that a CT and a flow queue correspond with each
other and the scheduling behavior of the flow queue determines the scheduling behavior of the
CT.
Eight templates of mappings between CTs and FQs can be configured, including a default one.
Issue 02 (2011-09-10)

86

3 MPLS TE
The default mappings between CTs and FQ queues are as follows:

CT
FQ
Scheduling Mode
CT7
CS7
PQ
CT6
CS6
PQ
CT5
EF
PQ
CT4
AF4
WFQ
CT3
AF3
WFQ
CT2
AF2
WFQ
CT1
AF1
WFQ
CT0
BE
LPQ
The product can calculate an FQ template according to the template applied to the TE outgoing
interface and the bandwidth of each CT. Users can configure eight such mapping templates
globally. Through flexible mappings, requirements of different BCMs can be met.
3.3.10 Static Bidirectional Co-routed LSP

A static bidirectional co-routed label switched path (LSP) consists of two static constraint-based
routed (CR) LSPs in opposite directions. MPLS TE supports MPLS forwarding in both directions
along such an LSP.
Static bidirectional co-routed LSP is an important MPLS Transport Profile (TP) feature. It
provides a reverse path for LSP ping messages, LSP tracert messages, and OAM messages.
Differences Between a Static Bidirectional Co-Routed LSP and a Common Static

LSP
A static bidirectional co-routed LSP is established by allocating labels manually to a specific
forwarding equivalence class (FEC). Although this LSP is established in the same way as a
common static CR-LSP, a static bidirectional co-routed LSP requires two forwarding tables, one
for sent packets and the other for received packets.
NOTE
In manual label allocation mode, the outgoing label value of a node is equal to the incoming label value of its
next hop.
Unlike two independent CR-LSPs in opposite directions, a static bidirectional co-routed LSP is
a single tunnel that consists of two CR-LSPs and works based on two forwarding tables. A static
bidirectional co-routed LSP can go Up only when both LSPs can transmit packets. If one of the
two CR-LSPs goes Down, the static bidirectional co-routed LSP goes Down. These two
forwarding tables work together. This allows any transit node on a bidirectional LSP to send a
response message along the same path in the opposite direction though IP support is unavailable.
Establishing a Static Bidirectional Co-Routed LSP

A node on a static bidirectional co-routed LSP only has information about the local LSP and
cannot obtain information about nodes on the other LSP. A static bidirectional co-routed LSP
Issue 02 (2011-09-10)

87

3 MPLS TE
shown in Figure 3-20 consists of a CR-LSP and a reverse CR-LSP. The CR-LSP originates from
the ingress and terminates on the egress. Its reverse CR-LSP originates from the egress and
terminates on the ingress.
Figure 3-20 Networking diagram for a static bidirectional LSP
Ingress
Transit
Transit
Egress
The configuration procedure for a static bidirectional co-routed LSP is as follows:

l
Configure the ingress. Configure a tunnel interface and enable MPLS TE on the outbound
interface of the ingress. If the outbound interface is Up and has sufficient bandwidth, the
static bidirectional co-routed LSP can go Up, irrespective of whether a transit node or an
egress is available.
Configure a transit node. Enable MPLS TE on two outbound interfaces. If they are both
Up and have sufficient bandwidth, the static bidirectional co-routed LSP can go Up,
irrespective of whether an ingress, another transit node, or an egress is available.
Configure the egress. Enable MPLS TE on the inbound interface. If the inbound interface
goes Up and has sufficient bandwidth, the static bidirectional co-routed LSP can go Up,
irrespective of whether an ingress or a transit node is available.
3.3.11 TE Tunnel Protection Group

A TE protection group is applicable to high-performance networks. As a protection tunnel is
reserved, transmission of data traffic can be quickly restored on the bypass tunnel after the
primary tunnel is faulty.
In a TE tunnel protection group, a primary tunnel and a bypass tunnel are pre-created and the
bypass tunnel is bound to the primary tunnel. In this manner, the primary tunnel and the bypass
tunnel form a tunnel protection group.
The attributes of a bypass tunnel can be configured independently, which facilitates the network
planning.
Concepts related to the tunnel protection group are as follows:
l
Primary tunnel: It is the tunnel to be protected.
Protection tunnel: It is the tunnel that protects the primary tunnel.
Protection switchover: In a tunnel protection group, when the primary tunnel is faulty, data
traffic is swiftly switched to the bypass tunnel, which enhances reliability of a network.
In 1:1 mode, a primary tunnel and a bypass tunnel are set up between the ingress and the
egress. Normally, data is transmitted through the primary tunnel. When the ingress detects
a fault on the primary tunnel through a detection mechanism, protection switchover is
performed and the ingress switches traffic to the bypass tunnel for transmission.
In N:1 mode, a tunnel functions as the bypass tunnel for multiple primary tunnels. When
any primary tunnel fails, data is switched to the shared bypass tunnel. This can save
bandwidth in a network of the full mesh topology, as shown in Figure 3-21.
Issue 02 (2011-09-10)

88

3 MPLS TE
Figure 3-21 Networking diagram of 1:1 protection mode
LSRA
LSRB
Working tunnel-1
Working tunnel-2
Protection tunnel-3
Data flow when primary
tunnel is normal
tunnel is failed
The implementation of a protection group of TE tunnels is simple and most operations are
performed at the ingress. You can configure a protection tunnel for the primary tunnel at the
ingress. When a fault is detected on the primary tunnel through OAM or BFD, the ingress detects
whether the protection tunnel is configured and whether the protection tunnel is available. If the
protection tunnel is available, the ingress switches traffic to the protection tunnel.
As shown in Figure 3-22, primary tunnels tunnel-1 and tunnel-2, and the bypass tunnel tunnel-3
are set up on the ingress LSR A.
On LSR A, tunnel-3 is specified as the protection tunnel for the primary tunnels tunnel-1 and
tunnel-2. After the configured fault detection mechanism at the ingress detects a fault on
tunnel-1, traffic is switched to tunnel-3. In addition, the system attempts to re-create tunnel-1.
If tunnel-1 is successfully set up, the traffic is switched back to the primary tunnel.
Figure 3-22 Schematic diagram of the tunnel protection group
Working tunnel-1
Working tunnel-2
Protection tunnel-3
LSRA
LSRB
tunnel is normal
tunnel is failed
Working tunnel-1is faild
Configuration of the Tunnel Protection Group

A TE tunnel protection group enhances reliability of the primary tunnel through the planning.
Therefore, before configuring a TE tunnel protection group, you need to plan the network. To
ensure the better performance of the protection tunnel, the protection tunnel must detour the
links and nodes through which the primary tunnel passes.
Issue 02 (2011-09-10)

89

3 MPLS TE
After the tunnel protection group is configured, the control plane can switch traffic in manual
mode or automatic mode. In addition, you can set the time to perform switchover.
NOTE
During the configuration, the protection tunnel cannot be protected by any other protection tunnel or
enabled with TE FRR.
3.3.12 BFD for TE CR-LSP

The traditional detection mechanisms, including the RSVP Hello mechanism and RSVP Srefresh
(summary refresh) mechanism, detect faults at slow speeds. BFD, however, adopts the fast
packet transmission mode and quickly detects faults on a CR-LSP of an MPLS TE tunnel, which
triggers fast traffic switchover for protection.
Figure 3-23 Networking diagram of BFD
LSRB
LSRD
LSRF
LSRA
LSRC
LSRE
As shown in Figure 3-23, without BFD, when LSR E is faulty, if a Layer 2 device exists, LSR
A and LSR F cannot detect the fault in time. The Hello mechanism then performs detection,
whereas the detection lasts for a long time.
If BFD is enabled on LSR A, LSR B, LSR C, LSR D, LSR E, and LSR F, when LSR E is faulty,
LSR A and LSR F can detect the fault within a short period, and then switch data traffic to the
path LSR A -> LSR B -> LSR D -> LSR F.
BFD for TE CR-LSP can rapidly detect a fault on the CR-LSP and notifies the forwarding plane,
which ensures fast traffic switchover. Usually, BFD for TE CR-LSP works together with the
hot-standby CR-LSP or the tunnel protection group.
Concepts related to BFD are as follows:
l
Static BFD session: Both local discriminator and remote discriminator are specified
manually. In addition, they must be consistent. Otherwise, no BFD session can be set up.
After a BFD session is set up, the intervals for sending and receiving packets can be
changed.
Dynamic BFD session: The local discriminator and remote discriminator do not need to be
manually specified. After the neighbor relationship is set up through a routing protocol, the
routing management (RM) module distributes parameters to notify the BFD module to set
up a BFD session. The local discriminator, remote discriminator, and intervals for sending
and receiving packets are obtained through negotiation.
Issue 02 (2011-09-10)

90

3 MPLS TE
Detection period: indicates the interval for detecting whether a BFD session is Up. If no
packet is received from the remote end within a detection period, the BFD session is
considered Down.
A BFD session is bound to a CR-LSP. That is, a BFD session is set up between the ingress and
the egress. A BFD packet is sent by the ingress and forwarded to the egress through a CR-LSP.
Then, the egress responds to the BFD packet. In this manner, a BFD session at the ingress can
fast detect the status of the path through which the CR-LSP passes.
When the BFD session detects a link fault, BFD notifies the forwarding plane of the fault. The
forwarding plane searches for a bypass CR-LSP and then switches traffic to the bypass CR-LSP.
The forwarding plane notifies the control plane of the fault. Then, if dynamic BFD for TE CRLSP is enabled, the control plane actively creates a BFD session to detect the bypass CR-LSP;
if static BFD for TE CR-LSP is enabled and the bypass CR-LSP needs to be detected, the BFD
session can be set up manually.
Figure 3-24 Networking diagram of a BFD session before and after switchover
LSRD
LSRB
LSRC
LSRA
LSRD
LSRA
LSRC
LSRB
Primary Lsp
Backup Lsp
Bfd Session
As show in Figure 3-24, a BFD session is set up to detect the link through which the primary
CR-LSP passes. When a fault occurs on the link, the BFD session at the ingress immediately
notifies the fault to the forwarding plane. Then, the ingress switches traffic to the backup CRLSP, and sets up a new BFD session to detect the link of the backup CR-LSP.
Issue 02 (2011-09-10)

91

3 MPLS TE
Configuration of BFD for TE

Figure 3-25 Networking diagram of BFD for TE
LSRA
LSRB
LSRD
Primary tunnel
LSRC
1.
Switchover between the primary CR-LSP and the hot-standby CR-LSP

As shown in Figure 3-25, a primary CR-LSP is set up between LSR A and LSR B, and a
hot-standby CR-LSP is set up. On LSR A, a BFD session is set up to detect faults on the
primary CR-LSP from LSR A to LSR B. When a fault occurs on the primary CR-LSP, the
BFD session fast notifies LSR A of the fault. After receiving the fault information, LSR A
fast switches traffic to the hot-standby CR-LSP to ensure normal traffic transmission.
2.
Switchover between the primary tunnel and the bypass tunnel

As shown in Figure 3-25, a primary tunnel is set up along the path LSR A -> LSR D ->
LSR B, and a bypass tunnel is set up along the path LSR A -> LSR C -> LSR B. A BFD
session is set up to detect the CR-LSP of the primary tunnel along the path LSR A -> LSR
D -> LSR B. When a fault occurs on the primary tunnel, the BFD session fast notifies LSR
A of the fault. After receiving the fault notification, LSR A fast switches traffic to the bypass
tunnel to ensure normal traffic transmission.
3.3.13 BFD for TE Tunnel

BFD for TE has two modes, that is, BFD for TE tunnel and BFD for TE CR-LSP. This section
only describes BFD for TE Tunnel. The BFD mechanism detects communication faults between
forwarding engines. To be specific, the BFD mechanism detects bidirectionally connectivity of
a data protocol on the same path between systems. The path can be a physical link or a logical
link such as a TE tunnel.
When the BFD session detects the entire TE tunnel, Virtual Private Network (VPN) FRR is
triggered to quickly switch traffic when the primary TE tunnel is faulty, which minimizes impacts
on services.
In the VPN FRR scenario, a TE tunnel is set up between provider edge (PE) devices and the
BFD mechanism is used to detect the tunnel. If the BFD mechanism detects a fault on the TE
tunnel, VPN FRR switching is performed in milliseconds.
The BFD for tunnel service and the MPLS Operation Administration and Maintenance (OAM)
service cannot be configured together on TE tunnels.
At present, Huawei implements only Layer 3 VPN (L3VPN) FRR. That is, BFD for tunnel can
be enabled only in the L3VPN to provide the fast switching service.
Issue 02 (2011-09-10)

92

3 MPLS TE
3.3.14 RSVP Authentication

RSVP messages are sent over Raw IP with no security mechanism and thus expose themselves
to being modified and expose devices to attacks. RSVP authentication uses digest information
in RSVP messages to authenticate the RSVP messages, preventing malicious attacks initiated
by the modified or forged RSVP messages and thus improving the network reliability and
security.
Principles
Two nodes exchanging RSVP messages are configured with the same key. One node uses the
key to calculate a digest for a message to be sent by using the Hash Message Authentication
Code Message Digest 5 (MAC-MD5) algorithm. The node adds the digest to the message as an
integrity object and then sends the message to the peer node. After receiving the message, the
peer node uses the same key and the HMAC-MD5 algorithm to calculate a digest and compares
the calculated digest with the received one. If the two digests are the same, the node accepts the
message; if the two digests are different, the node discards the message.
RSVP authentication, however, cannot prevent the anti-replay attack or solve the problem of
neighbor relationship termination resulted from disordered RSVP messages. To solve these
problems, RSVP authentication extensions are introduced. The RSVP authentication extensions
include the authentication lifetime, authentication handshake mechanism, and sliding window
mechanism based on the original authentication mechanism. They can improve the RSVP
security and enhance the user authentication in an adverse network environment such as network
congestion.
RSVP Key Management

RSVP key management is performed in either of the following modes:
l
MD5 key management

An MD5 key is entered in either cipher text or plaintext on an RSVP interface or on an
RSVP neighbor. MD5 is used to decrypt or and encrypt messages. MD5 key management
has the following characteristics:
Each protocol feature is configured with a unique key, which cannot be shared.
Each interface or neighbor can be configured with only one key. To change a key,
reconfigure one.
Keychain key management

Keychain is an enhanced encryption algorithm. During the configuration of keychain
authentication, a group of passwords are defined to form a password string, and each
password is specified with the encryption and decryption algorithms and configured with
the expiration. When sending or receiving a message, the system selects a valid password
based on the configuration. Before the expiration of the password, the system uses the
encryption algorithm matching the password to encrypt the message before sending it out,
or uses the decryption algorithm matching the password to decrypt the message before
accepting it. In addition, the system automatically adopts a new password after the previous
password expires, preventing the password from being decrypted.
Keychain key management has the following characteristics:
The keychain authentication password, the encryption and decryption algorithms, and
the password expiration that form a keychain configuration node are configured by using
Issue 02 (2011-09-10)

93

3 MPLS TE
different commands. A keychain configuration node requires at least one password and
encryption and decryption algorithms.
Keychain can be used by a majority of protocol features so that the keys can be uniformly
managed and shared by multiple features.
An RSVP interface or an RSVP neighbor can use a keychain with the HMAC-MD5
algorithm.
RSVP Authentication Levels

RSVP authentication provides the following modes:
l
Neighbor-oriented authentication
In this mode, you can configure authentication information such as authentication keys
based on different neighbor addresses. RSVP then authenticates each neighbor separately.
There are two configuration methods:
Configure one interface IP address of the neighbor as the neighbor address.
Configure the LSR ID of the neighbor as the neighbor address.
Interface-oriented authentication
After interface-oriented authentication is configured, RSVP authenticates messages based
on the inbound interfaces of the messages.
The two authentication modes have different priorities in the descending order of neighbororiented authentication, and interface-oriented authentication. The low-priority authentication
mode is used only when the high-priority authentication is not enabled. Once the messages fail
to pass the high-priority authentication, they are discarded.
3.3.15 RSVP GR
RSVP graceful restart (GR) is a status recovery mechanism applicable to RSVP-TE.
The RSVP GR function is designed on the basis of the non-stop forwarding (NSF) concept.
When a fault occurs on the control plane of a device, the upstream and downstream neighbors
send messages to restore the RSVP soft state, whereas the forwarding plane does not sense the
fault and cannot be affected by the fault. In this manner, stability and reliability of traffic is
guaranteed.
RSVP GR detects the GR status of neighbors through the Hello extension feature, for details
about the Hello feature, see the section RSVP Hello.
The principle of RSVP GR is as follows:
As shown in Figure 3-26, when the restarter performs GR, it stops sending Hello messages to
its neighbors. If the GR-enabled neighbors fail to receive Hello messages for three consecutive
times, the neighbors considers that the restarter is performing GR and all forwarding information
is retained. In addition, the interface board continues transmitting services and waits for the
restarter to restore the GR status.
After the restarter is restarted, if it receives Hello messages from neighbors, it sends Hello
messages to the neighbors. The processing modes of Hello messages are different on the
upstream and downstream nodes.
l
Issue 02 (2011-09-10)
If the upstream helper receives a Hello message, it sends a GR Path message downstream
to the restarter.
94

3 MPLS TE
If the downstream helper receives a Hello message, it sends a RecoveryPath message

upstream to the restarter.
Figure 3-26 Networking diagram of restoring the GR status through Path and RecoveryPath
messages
Upstream
Support
Downstream
Hello
Hello
Path
Restart RecoveryPath Support
When the restarter receives the GRPath message and the RecoveryPath message, the PSB
restores the CR-LSP according to these two messages. In this manner, information about the
CR-LSP on the local control plane is restored.
If the downstream helper cannot send the RecoveryPath message, the local PSB restores the CRLSP through only the Path message.
3.3.16 RSVP Summary Refresh

In the case that the entire RSVP Refresh message does not need sending, the system only sends
the RSVP summary, a small part of Refresh message, to maintain the RSVP soft state and respond
to the RSVP soft state change and route change.
Each RSVP session needs to generate, send, receive, and process RSVP Path messages and Resv
message within the refresh period. With number of RSVP sessions increasing, a large number
of Refresh messages are generated to maintain the RSVP soft state. When an RSVP message
rather than an RSVP Refresh message is lost during transmission, reliability is degraded and
relay occurs. The summary refresh (Srefresh) extension can solve preceding problems. The
summary refresh mechanism reduces the number of Refresh messages and improves reliability
of RSVP messages and efficiency of resource usage.
The Srefresh extension enables the refreshing of RSVP soft state without the transmission of
standard Path or Resv messages. Applying the Srefresh extension reduces the amount of
information that must be transmitted. When Srefresh messages are sent to update the RSVP soft
state, common Refresh messages are suppressed.
Srefresh messages contain a series of Message_ID objects to identify the Path or Resv state to
be refreshed. The Srefresh extension builds on the previously defined Message_ID extension.
Only the state that was previously advertised in Path and Resv messages containing Message_ID
objects can be refreshed through the Srefresh extension.
When a node receives an Srefresh message, it matches the message with the local state block
(PSB or RSB).
l
If the Srefresh message matches the local state block, the node refreshes the local state
through the Srefresh message that is considered as a standard Refresh message.
If the Srefresh message does not match the local state block, the node sends a NACK
message to the sender of the Srefresh message. In addition, the node refreshes the PSB or
RSB according to the Path or Resv message and updates Message_ID objects.
Message_ID objects contain the sequence number of Message_IDs. When an LSP changes, the
sequence number of the corresponding Message_ID increases. When the node receives a Path
Issue 02 (2011-09-10)

95

3 MPLS TE
message, the node compares the sequence number of the Message_ID with that saved in the
local state block.
l
If they are equal, the RSVP soft state remains.
If the received the sequence number of the Message_ID is greater than the local one, it
indicates that the RSVP soft state is updated.
Currently, RSVP summary refresh can be enabled globally or on an interface. If global summary
refresh is enabled, the entire device has the RSVP summary refresh capability; if summary
refresh is enabled only on an interface, only the link where the interface resides has the RSVP
summary refresh capability.
3.3.17 RSVP Hello

An RSVP node sends Hello messages to neighbors to check whether the neighbors are reachable.
The Hello mechanism is a node-to-node fault detection method. When a fault is detected on the
link between nodes, the Hello mechanism handles the fault in a manner similarly to the link
layer. When the notification of the link layer defect is unavailable, or the fault detection
mechanism at the link layer cannot efficiently detect the fault on the link between nodes, you
can use the Hello mechanism.
l
When FRR is enabled, if the Hello mechanism detects that the neighbors are unreachable,
traffic switching is triggered and traffic is switched to the bypass CR-LSP, which prevents
traffic loss due to the unreachable next hop.
When RSVP GR is enabled, the Hello mechanism can detect whether the neighbor is
restarted. The neighbor node can restore the RSVP state only after being restarted.
The principle of the RSVP Hello mechanism is as follows:

1.
Hello handshake mechanism

Figure 3-27 Hello handshake mechanism
Hello Repuest
Hello ACK
As shown in Figure 3-27, LSRA and LSRB are directly connected.

l When the RSVP Hello mechanism is enabled on the interface of LSRA, LSRA sends a
Hello Request message to LSRB.
l If LSRB is enabled with the RSVP Hello mechanism, after LSRB receives the Hello
Request message, LSRB replies LSRA with a Hello ACK message.
l After LSRA receives the Hello ACK message from LSRB, LSRA confirms that the
neighbor LSRB is reachable.
2.
Detection of neighbor loss

After LSRA successfully sends a Hello Request message to LSRB, LSRA and LSRB
exchanges Hello messages. After LSRA sends three consecutively Hello Request messages
to LSRB, if LSRA receives no ACK messages from LSRB, LSRA considers the neighbor
LSRB as lost, and then re-initializes the RSVP Hello message.
Issue 02 (2011-09-10)

96

3 MPLS TE
When an LSP is set up between LSRA and LSRB, the following situation occurs:
l If GR is disabled and FRR is enabled, when the Hello mechanism detects neighbor loss,
FRR switching is triggered and traffic is switched to the bypass CR-LSP to ensure
normal traffic transmission.
l If GR is enabled, the GR process is performed.
3.
Detection of neighbor restart

When LSRA and LSRB are enabled with RSVP GR, when the Hello mechanism detects
that the neighbor LSRB is lost, LSRA waits for LSRB to send a Hello Request message
carrying a GR extension. Then, LSRA starts to support LSRB to restore the RSVP soft
state. After LSRB receives the Hello ACK message replied by LSRA, LSRB knows that
LSRA starts to support LSRB to perform the GR process. Then, LSRA and LSRB exchange
Hello messages to maintain the restored GR status.
3.3.18 BFD for RSVP

BFD for RSVP detects RSVP neighbor relationships. When a Layer 2 device such as a hub exists
between neighboring RSVP nodes, the two nodes can detect a link fault only through the Hello
mechanism. Thus, it takes several seconds to rectify the fault. This results in the loss of a great
amount of data. BFD for RSVP implements fault detection at the millisecond level. BFD for
RSVP fast detects faults on the link between neighboring RSVP nodes. BFD for RSVP is used
in the TE FRR networking where Layer 2 devices exist on the primary CR-LSP between the
PLR and its RSVP neighbor.
Figure 3-28 Networking diagram of BFD for RSVP
BFD Session
BFD Session
As shown in Figure 3-28, the BFD session for RSVP is set up to detect the link between RSVP
neighbors. In this manner, the RSVP module can fast detect a link failure.
The objects to be detected are different among BFD for RSVP, BFD for CR-LSPs, and BFD for
TE. BFD for RSVP mainly detects the IP layer, and only single-hop BFD sessions can be set up
between RSVP neighbors. In addition, the application scenario of BFD for RSVP is different
from that of BFD for tunnel or BFD for TE. BFD for tunnel and BFD for TE detects end-to-end
links, and BFD for RSVP detects status of links between neighboring nodes.
BFD for RSVP can share BFD sessions with BFD for Open Shortest Path Fist (OSPF), BFD for
Intermediate System to Intermediate System (IS-IS), or BFD for Border Gateway Protocol
(BGP). In this case, the local node selects the smallest values of all parameters of the shared
BFD session as the local BFD parameters. The parameters include the transmission interval, the
receiving interval, and the local detection multiplier.
3.3.19 TE LSP Configuration Template

To help simplify command configurations on a TE tunnel interface, a TE LSP attribute template
can be used to perform the configurations related to CR-LSPs. Such a template is also called a
TE LSP configuration template.
Issue 02 (2011-09-10)

97

3 MPLS TE
Attributes that are configured in a TE LSP configuration template for setting up CR-LSPs include
the bandwidth, explicit path, affinity property, priorities, hop limit, route record (label) flag,
FRR flag, and constraints of a bypass tunnel.
After TE LSP attribute templates are configured in the system view, a TE LSP attribute template
can be specified for a primary CR-LSP, a hot-standby CR-LSP, or a bypass CR-LSP in the tunnel
interface view. A CR-LSP is then set up by using the attributes specified in a relevant attribute
template.
TE LSP attribute templates on a tunnel interface provide the following advantages:
l
When multiple CR-LSPs with the same TE attributes are to be set up, using TE LSP attribute
templates greatly simplify configurations on the TE tunnel interface.
When a hot-standby or an ordinary CR-LSP is to be set up by multiple using attribute

templates, differentiated attributes can be specified in these attribute templates.
On a TE tunnel interface, multiple CR-LSP attribute templates are designated for a hotstandby CR-LSP or an ordinary CR-LSP. In this manner, a diversified protection paths are
available for CR-LSPs.
After TE attribute templates are configured, a tunnel interface provides a primary CR-LSP
with the hot-standby CR-LSP, ordinary CR-LSP, and best-effort path as protection paths
at the same time.
Modifying attributes in a TE LSP attribute template updates the configurations of the CRLSP that has been set up by using the TE LSP attribute template, providing more flexibility
for CR-LSP configuration.
Implementation
l
Configuring an attribute template

An attribute template is configured in the system view. The attributes that can be configured
in the attribute template include the bandwidth, explicit path, affinity property, priorities,
hop limit, route record (label) flag, FRR flag, and constraints of a bypass tunnel.
Configuring and using an attribute template on a tunnel interface

An attribute template for setting up a primary CR-LSP, a hot-standby CR-LSP, or an
ordinary CR-LSP is specified in the tunnel interface view. In addition, multiple attribute
templates is available for a hot-standby CR-LSP or an ordinary CR-LSP. These attribute
templates differ from each other by configuration, providing various path options for the
CR-LSP to be set up on the tunnel interface.
On the tunnel interface, the attributes in a primary attribute template are used to set up a
primary CR-LSP; the attributes in a hot-standby attribute template are used to set up a hotstandby CR-LSP; the attributes in an ordinary attribute template are used to set up an
ordinary CR-LSP. After attributes templates are configured, a best-effort path can be
configured on the tunnel interface.
After a primary CR-LSP is successfully set up by using an attribute template, hot-standby
attribute templates are used in sequence till a hot-standby CR-LSP is successfully set up.
If the primary CR-LSP cannot be set up, or if the primary CR-LSP fails after being set up
and no hot-standby CR-LSP is set up, an ordinary CR-LSP can be set up. Ordinary backup
attribute templates are used in sequence till an ordinary backup CR-LSP is successfully set
up.
If none of the primary CR-LSP, hot-standby CR-LSP, or ordinary CR-LSP is set up, a besteffort path is created.
Issue 02 (2011-09-10)

98

3 MPLS TE
Modifying configurations in an attribute template in use

When an attribute template has been used to set up CR-LSPs of a TE tunnel, you can modify
the attributes in the attribute template, thus modifying the attributes of all CR-LSPs that
are set up by using the attribute template.
Different parameters changed in the attribute template have different impacts on the setup
of CR-LSPs. If the priority or class type in the attribute template is modified, the breakbefore-make mechanism is triggered, during which the primary CR-LSP is torn down
before the new CR-LSP is set up. If the make-before-break attribute in the attribute template
is modified, the make-before-break mechanism is triggered, during which the new CR-LSP
is set up before the primary CR-LSP is torn down.
Coexistence of configurations in an attribute template and commands that are configured

on the tunnel interface
After an attribute template is configured on a tunnel interface, you can separately configure
the attributes that have been configured in the attribute template.
When attributes are configured both in the attribute template and by using command lines
on a tunnel interface, the attributes configured by using command lines are preferentially
used for setting up a CR-LSP.
3.3.20 Multi-Area Advertisement of an MPLS LSR-ID

Definition
OSPF advertises an intra-area route destined for an MPLS LSR-ID to all areas connected to the
local device.
Purpose
When an ABR serves as the egress of two tunnels in two OSPF areas, one tunnel is regarded as
valid.
Figure 3-29 Networking diagram of one ABR serving as the egress of the tunnel in two areas
Loopback 0
1.1.1.1/32
Area 1
Area 0
Tunnel1
LSRA
Tunnel2
ABR
LSRB
For OSPF, the prerequisite of a valid tunnel is that an intra-area route to the egress is reachable.
According to OSPF, one interface only belongs to one area. That is, routes to the loopback
address interface only belong to one area and can be inter-area routes in other areas.
To solve the problem that only one tunnel is valid, OSPF advertises an intra-area route destined
for an MPLS LSR-ID to all areas connected to the local device.
Issue 02 (2011-09-10)

99

3 MPLS TE
Principles
An OSPF process generates a device LSA for each area. After the stub link with the MPLS LSRID is present in a device LSA, the intra-area routes to the MPLS LSR-ID of different areas can
be calculated.
NOTE
The same two stub links are present in a device LSA of an OSPF area when the following conditions are
met:
l The loopback interface with the IP address as the MPLS LSR-ID in an OSPF area is enabled with
OSPF.
l The advertise mpls-lsr-id command is run in the OSPF view and the command takes effect.
Figure 3-30 Networking diagram of one ABR advertising an MPSL LSR-ID to two areas
simultaneously
Loopback 0
1.1.1.1/32
Area 1
Area 0
advertise 1.1.1.1/32
advertise 1.1.1.1/32
Tunnel2
Tunnel1
LSRA
ABR
LSRB
NOTE
To advertise an MPLS LSR-ID to multiple areas, the following conditions should be met:
l An interface is assigned the IP address that is an MPLS LSR-ID.
l The advertise mpls-lsr-id command is run in an OSPF process.
l MPLS and MPLS TE are enabled.

Abbreviations
Issue 02 (2011-09-10)
Item
Full Spelling
RSVP
Resource Reservation Protocol
FRR
Fast Reroute
CSPF
Constrained Shortest Path First
TE
Traffic Engineering
MP
Merge Point
PLR
Point of Local Repair

100

Issue 02 (2011-09-10)
3 MPLS TE
Item
Full Spelling
CT
Class Type
PSB
Path State Block
RSB
Reserved State Block

101

4 MPLS OAM
MPLS OAM
About This Chapter

4.1 Introduction to MPLS OAM
4.2 References
4.3 Principles
Issue 02 (2011-09-10)

102

4 MPLS OAM
4.1 Introduction to MPLS OAM

Definition
Operation, Administration and Maintenance (OAM) is an important means to cut costs in
network maintenance. The MPLS OAM mechanism manages operation and maintenance of
Multiprotocol Label Switching (MPLS) networks.
MPLS supports different Layer 2 and Layer 3 protocols such as IP, Frame Relay (FR), and
Asynchronous Transfer Mode (ATM). In an MPLS network, the OAM mechanism is provided
totally independent of any upper or lower layer, which implements the following features on the
MPLS user plane:
l
Detects connectivity of label switched paths (LSPs).
Assesses utilization and performance of an MPLS network.
Performs protection switching when a defect or fault occurs on a link to provide services
in compliance with the signed service level agreements (SLAs) signed.
Purpose
As an extensible key technology of the next generation network, MPLS provides multiple
services guaranteed by quality of service (QoS). MPLS introduces a unique network layer that
may cause faults. Therefore, MPLS networks need to support OAM.
The protocols (such as Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy
(SDH)) at the server layer below the MPLS network layer and the protocols (such as IP, FR, and
ATM) at the client layer above the MPLS network layer have their respective OAM mechanisms.
Failures of the MPLS network cannot be rectified thoroughly through the OAM mechanism of
other layers. In addition, the network technology hierarchy also requires MPLS to have its
independent OAM mechanism to decrease dependency between layers on each other.
The MPLS OAM mechanism can detect, identify, and locate a defect at the MPLS layer
effectively. Then, the MPLS OAM mechanism the reports and handles the defect. In addition,
when a failure occurs, the MPLS OAM mechanism can trigger protection switching.
4.2 References
The following table lists the references of this document.
Huawei implements MPLS OAM based on ITU-T recommendations; however, the Request for
Comments (RFCs) are only for reference.
Issue 02 (2011-09-10)
Document
Description
Remarks
ITU-T
Recommendation
Y.1710
Requirements for Operation &

Maintenance functionality for
MPLS networks
Huawei implement MPLS OAM in

compliance with this
recommendation.
ITU-T
Recommendation
Y.1711
Operation & Maintenance

mechanism for MPLS networks

recommendation.

103

4 MPLS OAM
Document
Description
Remarks
ITU-T
Recommendation
Y.1720
Protection switching for MPLS

networks

recommendation.
RFC 3429
Assignment of the 'OAM Alert

Label' for Multiprotocol Label
Switching Architecture (MPLS)
Operation and Maintenance
(OAM) Functions
This RFC is only reference for

Huawei to implement MPLS
OAM.
RFC 4377
Operations and Management

(OAM) Requirements for MultiProtocol Label Switched (MPLS)
Networks

OAM.
RFC 4378
A Framework for Multi-Protocol

Label Switching (MPLS)
Operations and Management
(OAM)

OAM.
4.3 Principles
4.3.1 MPLS OAM Detection
MPLS OAM packets can be classified into the following types:
l
Connectivity detection packets

Fast Failure Detection (FFD) packets
Connectivity Verification (CV) packets
Forward Defect Indication (FDI) packets
Backward Defect Indication (BDI) packets
MPLS OAM mainly detects connectivity of an TE LSP . MPLS OAM sends CV or FFD packets
periodically along the detected TE LSP .
Issue 02 (2011-09-10)

104

4 MPLS OAM
CV
/F
FD
Figure 4-1 Schematic diagram of MPLS OAM for connectivity detection
Ingress
lSR
BDI
CV
/FF
Engress
lSR
BDI
As shown in Figure 4-1, MPLS OAM works as follows:

1.
The ingress sends a CV packet or an FFD packet along an LSP to be detected. The packet
passes through the LSP and arrives at the egress.
2.
The egress compares the packet type, interval, and Trail Termination Source Identifier
(TTSI) in the received packet with the local values to check the correctness of the packet.
In addition, the egress counts the number of received correct and incorrect packets within
a detection cycle. In this manner, MPLS OAM detects connectivity of the LSP.
3.
The detection interval of CV packet is a fixed value, and the detection cycle of FFD packet
is three times the detection interval.
4.
When the egress detects an LSP defect, the egress analyzes the defect type and sends a BDI
packet carrying the defect information to the ingress through a reverse tunnel. In this
manner, the ingress is notified of the defect of a specific type in time. If the protection group
is configured correctly, protection switching is triggered.
The detected defect is of one of the following types:
l Non-MPLS layer defects
dServer: indicates a server-layer defect. A dServer defect is the server-layer defect
that occurs below an MPLS network. The defects of this type are reported by the
server layer to MPLS OAM for handling.
The lower layer network that bears MPLS services may have its own protection and
defect detection mechanism. When a lower-layer defect occurs on an LSP, a
downstream label switch router (LSR) that is closest to the defect can notify the
egress of the defect. The lower-layer defect should not trigger the switchover but be
only notified to the network management device. In addition, the lower-layer defect
can be notified to the ingress through a proper method (of sending BDI packets).
dPeerME: indicates a peer maintenance entity defect. A dPeerME defect is the
server-layer defect that occurs on a peer maintenance entity outside the MPLS
subnet. The defects of this type are reported by other network layers connected to
the MPLS subnet to MPLS OAM for handling.
l MPLS layer defects
dLOCV: indicates the defect of connectivity verification loss.
Issue 02 (2011-09-10)

105

4 MPLS OAM
A dLOCV defect occurs when no CV or FFD packet is received within three

consecutive intervals for sending CV or FFD packets.
dTTSI_Mismatch: indicates the defect of TTSI mismatching.
A dTTSI_Mismatch defect occurs when no CV or FFD packet with a correct TTSI
is received within three consecutive intervals for sending CV or FFD packets.
dTTSI_Mismerge: indicates the defect of TTSI mismerging.
A dTTSI_Mismerge defect occurs when CV or FFD packets with both correct and
incorrect TTSIs are received within three consecutive intervals for sending CV or
FFD packets.
dExcess: indicates the defect of the excessive rate of receiving connectivity detection
packets.
A dExcess defect occurs when five or more correct CV or FFD packets are received
within three consecutive intervals for sending CV or FFD packets.
l Other defects
dUnknown: indicates an unknown defect in an MPLS network.
A defect can be defined as dUnknown. For example, if the egress detects a defect that
both CV packets and FFD packets are sent along the same LSP, this special defect that
is not defined in the protocol can be identified as a dUnknown defect.
4.3.2 Reverse Tunnel

When the basic OAM function is configured, the LSP to be detected needs to be bound to a
reverse tunnel for transmitting BDI packets.
BDI packets are transmitted through the reverse tunnel. A reverse tunnel can be an LSP with the
ingress and egress being opposite to those on the detected LSP. The reverse tunnel can also be
a non-MPLS path that connects the ingress and the egress of the detected LSP.
The reverse tunnel transmitting BDI packets can be one of the following types:
l
Private reverse LSP
Shared reverse LSP
Non-MPLS reverse path

NOTE
Currently, Huawei only supports a TE tunnel as the reverse tunnel.
4.3.3 MPLS OAM Auto Protocol

MPLS OAM defined in ITU-T Recommendation Y.1710 and Y.1711 has the following
drawbacks:
l
On an LSP, if the ingress is enabled with the OAM function later than the egress, or OAM
is enabled on the egress and disabled on the ingress, a dLOCV defect occurs.
The dLOCV defect also occurs when OAM is disabled. You must disable OAM on the
ingress and egress before changing the type or updating the interval for sending detection
packets.
The OAM parameters need to be set on the ingress and egress respectively. This, however,
may cause the detection packet type and the interval for sending detection packets on the
ingress to be different from those on the egress.
Issue 02 (2011-09-10)

106

4 MPLS OAM
On the Huawei devices, the OAM auto protocol can address the preceding problems.
If the OAM auto protocol is enabled on the egress, the functions of first packet triggering OAM
and the dynamic enabling or disabling OAM are provided.
The MPLS OAM auto protocol is the patent of Huawei.
4.3.4 Protection Switching

Protection switching refers to that a protection tunnel (namely, the bypass tunnel) is pre-set for
the primary tunnel and assigned with bandwidth. The primary tunnel and the bypass tunnel form
a protection group. When the primary tunnel is faulty, data traffic can be quickly switched to
the bypass tunnel. This decreases the packet loss ratio or shortens the delay due to the LSP
failure, and enhances reliability of networks. Protection switching refers to the end-to-end
protection.
With MPLS OAM for fast fault detection, the protection switching can be performed in
milliseconds.
On the Huawei devices, protection switching can be performed in 1:1 mode or N:1 mode.
l
In 1:1 mode, a primary tunnel and a bypass tunnel are set up between the ingress and egress.
Normally, data is transmitted through the primary tunnel.
When the ingress detects a fault on the primary tunnel through MPLS OAM, protection
switching is performed and the ingress switches data to the bypass tunnel for
transmission.
In N:1 mode, a tunnel functions as the bypass tunnel for multiple primary tunnels. When
any primary tunnel fails, data is switched to the shared bypass tunnel. The N:1 mode is
used to save bandwidth in a network with the mesh topology.
Figure 4-2 Schematic diagram of the MPLS OAM tunnel protection
CX-A
CX-B
Primary tunnel
Primary tunnel
Protection tunnel
Backward tunnel
tunnel is normal
tunnel is falled
Issue 02 (2011-09-10)

107

4 MPLS OAM

Terms
Item
Description
Reverse
It is the direction opposite to the direction that traffic flows along the
detected LSP.
Forward
It is the direction that traffic flows along the detected LSP.
Path Merge LSR
It is the LSR that receives the traffic transmitted on the protection path
in MPLS OAM protection switching.
If the patch merge LSR is not the destination of traffic, it sends and
merges the traffic transmitted on the protection path onto the working
path.
If the path merge LSR is the destination of traffic, it sends the traffic
to the upper-layer protocol for handling.
Path Switch LSR
It is the LSR that switches or replicates traffic between the primary

LSP and the bypass LSP.
User Plane
It refers to the set of traffic forwarding components that the traffic

flow passes through. The OAM CV or FFD packet is periodically
inserted to this traffic flow to monitor the working status of the
forwarding components. In the IETF drafts, the user plane is called
data plane.
Ingress
It is the ingress LSR of the forward LSP, and is the egress LSR of the
reverse LSP.
Egress
It is the egress LSR of the forward LSP, and is the ingress LSR of the
reverse LSP.
Abbreviations
Issue 02 (2011-09-10)
Item
Full Spelling
MPLS
Multiprotocol Label Switching
CV
Connectivity Verification
FFD
Fast Failure Detection
FDI
Forward Defect Indication
BDI
Backward Defect Indication
TTSI
Trail Termination Source Identifier

108

3.2.7 Feature Description - MPLS

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

3.2.7 Feature Description - MPLS

Transféré par

Droits d'auteur :

Formats disponibles

HUAWEI CX600 Metro Services Platform

Feature Description - MPLS

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2011. All rights reserved.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Industrial Base

Huawei Proprietary and Confidential

HUAWEI CX600 Metro Services Platform

About This Document

About This Document

HUAWEI CX600 Metro

Network planning engineers

Data configuration engineers

System maintenance engineers

Indicates a hazard with a high level of risk, which if not

Huawei Proprietary and Confidential

HUAWEI CX600 Metro Services Platform

About This Document

Indicates a hazard with a medium or low level of risk, which

Indicates a tip that may help you solve a problem or save

Provides additional information to emphasize or supplement

Changes in Issue 02 (2011-09-10)

Changes in Issue 01 (2011-06-30)

Huawei Proprietary and Confidential

HUAWEI CX600 Metro Services Platform

Huawei Proprietary and Confidential

HUAWEI CX600 Metro Services Platform

2.3.16 LDP over TE..........................................................................................................................................45

Huawei Proprietary and Confidential

HUAWEI CX600 Metro Services Platform

About This Chapter

Huawei Proprietary and Confidential

HUAWEI CX600 Metro Services Platform

1.1 Introduction to MPLS

Huawei Proprietary and Confidential

HUAWEI CX600 Metro Services Platform

The following table lists the references of this document:

Multiprotocol Label Switching Architecture

MPLS Label Stack Encoding

Time To Live (TTL) Processing in Multi-Protocol Label

Use of Label Switching on Frame Relay Networks

Requirements for Traffic Engineering Over MPLS

RSVP-TE: Extensions to RSVP for LSP Tunnels

Huawei Proprietary and Confidential

HUAWEI CX600 Metro Services Platform

Figure 1-1 MPLS network structure

Core LSR Core LSR

Huawei Proprietary and Confidential

HUAWEI CX600 Metro Services Platform

Forwarding Equivalence Class

A label contains the following fields:

Label: indicates the value field of a label. The length is 20 bits.

HUAWEI CX600 Metro Services Platform

Table 1-1 Special labels

Indicates a label that is only valid when it is not at the

When the label whose value is 3 is swapped on the

Indicates a label for the packets of Operation

Huawei Proprietary and Confidential

HUAWEI CX600 Metro Services Platform

Penultimate Hop Popping

Huawei Proprietary and Confidential

HUAWEI CX600 Metro Services Platform

Label Switching Router