Beruflich Dokumente
Kultur Dokumente
V600R003C00
02
Date
2011-09-10
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.
Website:
http://www.huawei.com
Email:
support@huawei.com
Issue 02 (2011-09-10)
Related Versions
The following table lists the product versions related to this document.
Product Name
Version
V600R003C00SPC300
Intended Audience
This document is intended for:
l
Commissioning engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol
Description
DANGER
Issue 02 (2011-09-10)
ii
Symbol
Description
WARNING
CAUTION
TIP
NOTE
Change History
Updates between document issues are cumulative. Therefore, the latest document issue contains
all updates made in previous issues.
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
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
Issue 02 (2011-09-10)
1 MPLS Overview
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
Description
RFC 3031
RFC 3036
LDP Specification
RFC 3032
RFC 3443
RFC 3034
RFC 2702
RFC 3209
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
LER
MPLS network
Non- MPLS
network
Non- MPLS
network
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
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
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.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
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.
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
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
4 to 13
Reserved
None.
14
OAM Router
Alert Label
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.
1 MPLS Overview
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.
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: 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
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.
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
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.
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
Dynamic LSP: It is set up by the routing protocol and label distribution protocol.
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.
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
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.
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
Issue 02 (2011-09-10)
Field
Description
Token
Sequence Number
Slot Number
12
1 MPLS Overview
Field
Description
Tunnel Type
Allocation Method
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.
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.
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
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.
During the MPLS forwarding, FIB entries, ILM entries, and NHLFEs are associated with each
other through the token field in the tunnel ID.
l
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.
Checks the ILM table corresponding to an MPLS label and finds the token.
2.
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.
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
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
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.
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.
Issue 02 (2011-09-10)
19
1 MPLS Overview
CE3
VPN
branch 3
PE3
CE1
VPN
branch 1
PE1
Backbone network
PE2
CE2
VPN
branch 2
PEs are responsible for managing VPN users, setting up LSPs between PEs, and allocating
routes to sites of a VPN.
The MPLS-based VPN supports the IP address multiplexing between sites and the
interconnection of different VPNs.
The traffic for original services is forwarded through the original network.
Issue 02 (2011-09-10)
20
1 MPLS Overview
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.
Issue 02 (2011-09-10)
Terms
Explanation
Label space
ILM
LDP peer
LDP identifier
21
1 MPLS Overview
Terms
Explanation
NHLFE
PHB
Control plane
Forwarding plane
Abbreviation
Issue 02 (2011-09-10)
Abbreviation
Full Spelling
DoD
Downstream-on-Demand
DU
Downstream Unsolicited
LSP
FEC
ILM
LAM
LDP
LER
LFIB
22
Issue 02 (2011-09-10)
1 MPLS Overview
Abbreviation
Full Spelling
LSP
LSR
MPLS
NHLFE
PHP
23
2 MPLS LDP
MPLS LDP
Issue 02 (2011-09-10)
24
2 MPLS LDP
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
RFC3215
RFC5443
RFC3478
RFC1321
RFC3037
LDP Applicability
RFC3988
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.
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.
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 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.
27
2 MPLS LDP
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.
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
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
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.
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.
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.
Issue 02 (2011-09-10)
31
2 MPLS LDP
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.
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.
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.
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.
Hold-down timer
Hold-max-cost timer
Delay timer
GR delay timer
Issue 02 (2011-09-10)
34
2 MPLS LDP
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.
2.
An LDP session is set up between LSR2 and LSR3, and an IGP holds down the
establishment of an IGP neighbor relationship.
3.
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.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
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.
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
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.
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.
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
GR Restarter
GR Helper
Restore label
binding
End GR
Succeed in detecting
faults on GR
Restarter. Mark GRRestarter-related
forwarding entries
Stale
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.
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.
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.
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.
42
2 MPLS LDP
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
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
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.
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
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.
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.
Applicable Environment
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
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.
Applicable Environment
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.
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
Explanation
GR Restarter
GR Helper
Abbreviation
Issue 02 (2011-09-10)
Abbreviation
Full Spelling
LDP
LSP
FEC
GTSM
TTL
Time To Live
GR
Graceful Restart
FRR
Fast Reroute
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
49
Issue 02 (2011-09-10)
2 MPLS LDP
Abbreviation
Full Spelling
MTU
50
3 MPLS TE
MPLS TE
Issue 02 (2011-09-10)
51
3 MPLS TE
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.
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 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.
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 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
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.
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
RFC 2209
RFC 2370
RFC 2547
BGP/MPLS VPNs
RFC 2702
RFC 2747
RFC 2961
RFC 3031
RFC 3032
RFC 3034
RFC 3209
RFC 3210
56
3 MPLS TE
Document
Description
Rem
arks
RFC 3473
RFC 3630
RFC 3784
RFC 4124
RFC 4127
RFC 4128
RFC 4139
draft-ietfmpls-rsvplspfastreroute-02
draft-ietfmpls-nodeidsubobject-01
draft-ietftewg-diff-teproto-02
draft-ietfmpls-diff-tereqts-00
draft-ietfmpls-diffext-07
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 uses a soft state mechanism to maintain the resource reservation information.
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
Ingress
PE1
Path
Resv
Transit
P1
Path
Resv
Transit
P2
Path
Resv
Egress
PE2
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.
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
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
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
60
3 MPLS TE
networks waste bandwidths because they forward multicast packets by replicating them for
each receiver.
l
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.
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 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.
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.
63
3 MPLS TE
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.
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
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.
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
PLR
R1
R2
MP
R3
R4
R5
Primary LSP
Bypass LSP
R6
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.
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.
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.
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
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.
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
When a backup
CR-LSP is set
up
Explicit path
70
3 MPLS TE
Item
Hot-Standby CR-LSP
Is a best-effort
path
established
Yes
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.
71
3 MPLS TE
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.
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.
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.
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.
2.
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.
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
Object to be
protected
74
3 MPLS TE
Item
CR-LSP Backup
TE FRR
LSP attributes
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.
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)
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
Class-Type=CT0, setup-priority=7, hold-priority=6
Class-Type=CT0, setup-priority=7, hold-priority=7
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.
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.
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.
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
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
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
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
CT type
BC type
IGP message
RSVP message
Single CT:
CT information is carried in
the CLASSTYPE object.
Multi-CT:
CT information is carried in
the EXTENDED_CLASSTYPE object.
Issue 02 (2011-09-10)
Item
Changes of
bandwidth constraint
models
80
3 MPLS TE
Item
Deletion of LSPs
Multi-CT LSPs
Single-CT LSPs with a CT
ranging from CT2 to CT7
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
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
PE
MPLS TE tunnel
PE
VPN1
Site1
CE
CE
VPN1
Site2
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
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
PE
PE
MPLS TE tunnel2
VPN
site 1
CE
CE
Tunnel2: CT0 for BE:
100M bps
VPN
site 2
VPN
service
DS-TE Mode
TE FRR
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
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
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
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.
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.
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
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.
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
LSRA
LSRB
Working tunnel-1
Working tunnel-2
Protection tunnel-3
Data flow when primary
tunnel is normal
Data flow when primary
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
Data flow when primary
tunnel is normal
Data flow when primary
tunnel is failed
Working tunnel-1is faild
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.
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
LSRA
LSRB
LSRD
Primary tunnel
LSRC
1.
2.
92
3 MPLS TE
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.
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.
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.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
94
3 MPLS TE
Figure 3-26 Networking diagram of restoring the GR status through Path and RecoveryPath
messages
Upstream
Support
Downstream
Hello
Hello
Path
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.
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 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.
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.
Hello Repuest
Hello ACK
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.
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.
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.
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
Issue 02 (2011-09-10)
98
3 MPLS TE
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.
Issue 02 (2011-09-10)
Item
Full Spelling
RSVP
FRR
Fast Reroute
CSPF
TE
Traffic Engineering
MP
Merge Point
PLR
100
Issue 02 (2011-09-10)
3 MPLS TE
Item
Full Spelling
CT
Class Type
PSB
RSB
101
4 MPLS OAM
MPLS OAM
Issue 02 (2011-09-10)
102
4 MPLS OAM
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
ITU-T
Recommendation
Y.1711
103
4 MPLS OAM
Document
Description
Remarks
ITU-T
Recommendation
Y.1720
RFC 3429
RFC 4377
RFC 4378
4.3 Principles
4.3.1 MPLS OAM Detection
MPLS OAM packets can be classified into the following types:
l
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
Ingress
lSR
BDI
CV
/FF
Engress
lSR
BDI
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
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.
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.
CX-A
CX-B
Primary tunnel
Primary tunnel
Protection tunnel
Backward tunnel
Data flow when primary
tunnel is normal
Data flow when primary
tunnel is falled
Issue 02 (2011-09-10)
107
4 MPLS OAM
Description
Reverse
It is the direction opposite to the direction that traffic flows along the
detected LSP.
Forward
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.
User 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
CV
Connectivity Verification
FFD
FDI
BDI
TTSI
108