Multi Protocol Label Switching Guide

Passport 7400, 15000
Multiprotocol Label
Switching
Guide
241-5701-445
Multiprotocol Label Switching
Guide
Publication: 241-5701-445
Document status: Standard
Document version: 2.2S1
Document date: February 2001
Copyright © 2001 Nortel Networks.

All Rights Reserved.
Printed in Canada
NORTEL NETWORKS, the globemark design, the NORTEL NETWORKS corporate logo, DPN,
DPN-100, and PASSPORT are trademarks of Nortel Networks.
5
Publication history
February 2001
2.2S1 Standard
General availability. Contains information on Passport 7400 and
Passport 15000 for the PCR 2.2 GA release.
Passport 7400, 15000 Multiprotocol Label Switching Guide 2.2S1

6 Publication history
241-5701-445 2.2S1
7
Contents
About this document 13
Who should read this document and why 13
What you need to know 14
How this document is organized 14
What’s new in this document 14
Multiple LSPs per FEC 14
Alarms and Statistics 15
Configuring a hop-by-hop LSP 15
MPLS on ATM IP FP 15
Text conventions 15
Related documents 17
How to get more help 17
Chapter 1
Overview 19
What is MPLS technology? 19
How is MPLS implemented in Passport networks? 21
Why use MPLS? 22
How does MPLS work? 22
At the edge of the network 23
In the network core 24
In hop-by-hop routes 24
In explicit routes 26
MPLS in Passport nodes 28

8 Contents
Chapter 2
MPLS description 29
MPLS protocols 29
Label distribution protocol 29
Constraint-based routing using LDP 32
Creation of LSPs 34
Call setup for hop-by-hop LSPs 34
Call setup for ER-LSPs 35
LDP/CR-LDP interworking 37
Traffic engineering with MPLS 38
MPLS using ATM media 40
Label encapsulation 41
Ships-in-the-night operation 41
QoS mapping 41
LSP recovery 42
Chapter 3
Configuring MPLS 43
Implementation of MPLS 43
Prerequisites to configuring MPLS 45
Installing MPLS software 45
Configuring ports and interfaces 46
Configuring the virtual router and protocol port 46
Configuring the ATM media and links 47
Configuring the IP port 50
Configuring the MPLS component 51
Configuring the MPLS port 54
Configuring LSPs 57
Configuring an LSP group and IP forwarding policy 57
Configuring the explicit route path 60
Configuring an ER-LSP 61
Configuring a hop-by-hop LSP 64
Configuring LSP quality of service 64
LDP/CR-LDP interworking configuration 67
Considerations for configuring LDP/CR-LDP interworking 68
241-5701-445 2.2S1
Contents 9
Configuring LDP/CR-LDP interworking 68

Locking and unlocking an LSP 70
Chapter 4
Monitoring and troubleshooting 71
Tracing an LSP 71
Displaying the XcMap on the ingress node 72
Displaying the InSegment on the next node 73
Displaying the XcMap on the next node 73
Following the path 74
Operational information on LSP groups and LSPs 74
Displaying information on LSP groups 74
Displaying information on LSPs 75
Provisioning the alarm severity for a specific LSP 76
Tracing the peers of a node 77
Displaying the Ldp component 77
Listing the peers of a node 77
Listing the sessions of a peer 78
Listing the adjacencies of a session 78
Troubleshooting 79
Statistics 79
Solving problems 80

10 Contents
List of figures
Figure 1 MPLS technology 20
Figure 2 MPLS network 23
Figure 3 Hop-by-hop LSP 25
Figure 4 ER-LSP 26
Figure 5 Strict and loose ER LSPs 27
Figure 6 ER specification 28
Figure 7 Downstream-on-demand label advertisement 32
Figure 8 Call setup for hop-by-hop LSPs 35
Figure 9 Call setup for ER-LSPs 36
Figure 10 LDP/CR-LDP interworking 38
Figure 11 MPLS traffic engineering 40
Figure 12 MPLS and related components 44
Figure 13 Component tree for configuring the virtual router and
protocol port 46
Figure 14 Component tree for configuring the ATM media and
links 48
Figure 15 Component tree for configuring the IP port 50
Figure 16 Component tree for configuring the MPLS
component 52
Figure 17 Component tree for configuring the MPLS port 55
Figure 18 Component tree for configuring an LSP group and IP
forwarding policy 58
Figure 19 Component tree for configuring the explicit route
path 60
Figure 20 Component tree for configuring an ER-LSP 62
Figure 21 Component tree for configuring LSP quality of
service 65
Figure 22 Component tree for configuring LDP/CR-LDP
interworking 69
Figure 23 Tracing an LSP 72
241-5701-445 2.2S1
Contents 11
List of tables
Table 1 Mapping of MPLS traffic parameters to ATM service
categories 42
Table 2 MPLS interface statistics 79
Table 3 Troubleshooting the LSP 81

12 Contents
241-5701-445 2.2S1
13
About this document

This guide describes multiprotocol label switching (MPLS).
The following topics are discussed in this section:

• “Who should read this document and why” (page 13)
• “What you need to know” (page 14)
• “How this document is organized” (page 14)
• “What’s new in this document” (page 14)
• “Text conventions” (page 15)
• “Related documents” (page 17)
• “How to get more help” (page 17)
Who should read this document and why

This guide is for persons who perform the following tasks for MPLS:
• planning
• engineering
• installing and configuring
• provisioning
• operating and maintaining
• troubleshooting

14 About this document
What you need to know

This guide assumes that you understand the Passport network architecture.
You can learn more about the product by reading 241-5701-400 Passport
7400, 15000 Networking Overview.
How this document is organized

The 241-5701-445 Passport 7400, 15000 Multiprotocol Label Switching
Guide, contains the following information:
• “Overview” (page 19) presents an overview of MPLS and its
applications
• “MPLS description” (page 29) explains how MPLS works
• “Configuring MPLS” (page 43) explains how to install MPLS software
and configure Passport nodes with MPLS
• “Monitoring and troubleshooting” (page 71) provides information you
can use in maintaining and trouble-shooting MPLS
What’s new in this document

The following features were added to this document:
• “Multiple LSPs per FEC” (page 14)
• “Alarms and Statistics” (page 15)
• “Configuring a hop-by-hop LSP” (page 64)
• “MPLS on ATM IP FP” (page 15)
Multiple LSPs per FEC

This feature introduces the ability to configure multiple LSPs, of different
quality of service, to the same FEC destination. The CDL for MPLS is
significantly changed by this feature. The following sections were updated by
this feature:
• “How is MPLS implemented in Passport networks?” (page 21)
• “Why use MPLS?” (page 22)
• “In explicit routes” (page 26)
• “Traffic engineering with MPLS” (page 38)
241-5701-445 2.2S1
• “Configuring MPLS” (page 43)

• “Displaying the XcMap on the ingress node” (page 72)
• “Displaying the XcMap on the next node” (page 73)
• “Operational information on LSP groups and LSPs” (page 74)
Alarms and Statistics

This feature introduces the ability to provision the alarm severity for specific
LSPs. The following section was updated for this feature:
• “Provisioning the alarm severity for a specific LSP” (page 76)
Configuring a hop-by-hop LSP

The section “Configuring a hop-by-hop LSP” (page 64) was updated to
include information about a hop-by-hop LSP setup using the LdpQos
component.
MPLS on ATM IP FP
This feature provides support for MPLS on the ATM IP FP. The following
sections were updated:
• “MPLS in Passport nodes” (page 28)
Text conventions
This document uses the following text conventions:
• nonproportional spaced plain type
Nonproportional spaced plain type represents system generated text or

text that appears on your screen.
• nonproportional spaced bold type
Nonproportional spaced bold type represents words that you should type
or that you should select on the screen.

• italics
Statements that appear in italics in a procedure explain the results of a
particular step and appear immediately following the step.
Words that appear in italics in text are for naming.
• [optional_parameter]
Words in square brackets represent optional parameters. The command
can be entered with or without the words in the square brackets.
• <general_term>
Words in angle brackets represent variables which are to be replaced with
specific values.
• UPPERCASE,lowercase
Passport commands are not case-sensitive and do not have to match
commands and parameters exactly as shown in this document, with the
exception of string options values (for example, file and directory names)
and string attribute values.
• |
This symbol separates items from which you may select one; for
example, ON|OFF indicates that you may specify ON or OFF. If you do
not make a choice, a default ON is assumed.
• ...
Three dots in a command indicate that the parameter may be repeated
more than once in succession.
The term absolute pathname refers to the full specification of a path starting
from the root directory. Absolute pathnames always begin with the slash ( / )
symbol. A relative pathname takes the current directory as its starting point,
and starts with any alphanumeric character (other than /).
241-5701-445 2.2S1
Related documents
For the complete list of documents contained in the Passport documentation
library, see 241-5701-001 Passport 7400, 15000 Documentation Guide.
See the following Passport documents for information related to MPLS:

• 241-5701-600 Passport 7400, 15000 Configuration Guide
• 241-5701-805 Passport 7400, 15000 Understanding IP
• 241-5701-810 Passport 7400, 15000 Configuring IP
• 241-5701-060 Passport 7400, 15000 Components
• 241-5701-500 Passport 6400, 7400, 15000 Alarms
How to get more help

For information on training, problem reporting, and technical support, see the
“Nortel Networks support services” section in the product overview
document.

241-5701-445 2.2S1
19
Chapter 1
Overview
For an overview of multiprotocol label switching (MPLS), see the following
sections:
• “What is MPLS technology?” (page 19)
• “How is MPLS implemented in Passport networks?” (page 21)
• “Why use MPLS?” (page 22)
• “How does MPLS work?” (page 22)
• “MPLS in Passport nodes” (page 28)
What is MPLS technology?

MPLS is a label-swapping, networking technology that forwards packet
traffic over multiple, underlying layer-2 media. This technology integrates
layer-2 switching and layer-3 routing by linking the layer-2 infrastructure
with layer-3 routing characteristics. Layer-3 routing occurs at the edge of the
network, and layer-2 switching takes over in the MPLS network core. See
Figure “MPLS technology” (page 20).
Essentially, MPLS forwards a packet by swapping labels at each node in its

path. MPLS makes it possible to create new label formats without having to
change routing protocols. For example, MPLS traffic can include internet
protocol (IP), frame relay, ATM, and even optical waveforms.

20 Chapter 1 Overview
Figure 1
MPLS technology
MPLS network
MPLS MPLS
node node
router router
Packet Packet label Packet
Forwarding Forwarding Forwarding

on address on label on address
PPT 2888 001 AA
In its generic concept, MPLS can switch a frame from any kind of layer-2 link
to any other kind of layer-2 link. At this stage in the development of its
standards, MPLS supports ATM, frame relay, Ethernet, and point-to-point
protocol (PPP). Because traffic flow is independent of the MPLS control
protocols, MPLS will be able to support routing protocols that have not yet
been defined without any need for the underlying forwarding hardware to
change.
With MPLS, layer-3 traffic flows take advantage of the layer-2 traffic
engineering abilities and quality of service (QoS) performance, without
losing the benefit of existing best-effort, hop-by-hop routing.
MPLS is an emerging standard for network-layer packet forwarding, based on

a number of signaling protocols proposed by the Internet Engineering Task
Force (IETF). Among these protocols are the label distribution protocol
(LDP), border gateway protocol (BGP), resource reservation protocol
(RSVP), and constraint-based routing using LDP (CR-LDP). These signaling
241-5701-445 2.2S1
Chapter 1 Overview 21
protocols distribute labels and forward MPLS traffic. The choice of protocol
depends on factors such as the location and role of the switching node. In
some cases, a node uses more than one distribution protocol.
How is MPLS implemented in Passport networks?

In Passport networks, MPLS transports IP traffic over ATM infrastructure,
allowing carriers and large enterprises to send IP data easily across the ATM
backbone. MPLS functionality at the control plane allows carriers to use
existing ATM hardware to efficiently transport IP traffic. Passport nodes run
both an IP routing protocol and the MPLS signaling protocols LDP and CR-
LDP. These protocols allow the Passport nodes to establish label switched
paths, which are essentially VCCs, over the ATM infrastructure. Multiple
LSPs, with different quality of service and hot standby LSPs, can be
configured to the same destination.
Passport nodes in the MPLS network can also run an ATM control plane to
support ATM services. This hybrid method of running both control protocols
independently is called ships-in-the-night mode.
The Passport network’s ATM infrastructure allows MPLS traffic to use the
ATM queueing and traffic management capabilities. This practice provides
the ability to deliver end-to-end QoS for IP traffic.
The Passport implementation of MPLS takes advantage of the distributed

nature of the Passport software. The LDP functionality, which drives the
MPLS protocol, is not restricted to the control processor (CP) but is
distributed to the function processors (FP). In some cases, the only processing
executed on the CP is the generation and handling of some of the LDP
messages. The FP handles all other MPLS functions. This distributed
structure improves the overall scalability and resource usage for large
networks.

Why use MPLS?

Carrier organizations and large enterprises typically use MPLS in their
backbone networks to improve network resource usage. As the key to the
future of large-scale IP networks, MPLS provides the following benefits:
• independence of function—In MPLS, the forwarding plane is separated
from the routing protocol control plane, so that the MPLS core performs
a simple forwarding function completely independently of the packet
content. This practice allows policy and routing decisions to be applied
only once at the network edge.
• traffic engineering—MPLS channels the operation of IP routing so that
traffic can be steered to achieve efficient network resource usage and
optimal performance. The grouping of LSPs into LSP groups, allows for
multiple LSPs, of different quality of service, to the same FEC
destination.
• resource control—MPLS allows you to control valuable resources
precisely, for example, through the definition of different classes of
service.
• network evolution—MPLS is developing into a robust network in which
a single, unified protocol operates over multiple, underlying layer-2
technologies.
• traffic aggregation—MPLS VC merge capability allows you to aggregate
IP traffic towards a destination.
How does MPLS work?

MPLS is a forwarding mechanism that works by applying a label to IP traffic
entering the network. The label acts as a shorthand representation of the IP
packet header. As the traffic moves through the network, MPLS swaps the
label at each node on the route, according to a pre-defined label database at
that node. At the egress side of the MPLS network, the packet is decapsulated,
and continues under the IP routing protocol.
Figure “MPLS network” (page 23) shows an MPLS network with a number
of Passport nodes. The nodes at the edges of the network are label edge
routers (LER). The LER nodes provide ingress and egress functions for IP
traffic in the MPLS network. The core nodes are label switched routers
241-5701-445 2.2S1
(LSR). The LSR nodes provide the high-speed switching functions for the
network. The path of data between the MPLS nodes is a label switched path
(LSP). An LSP is a unidirectional tunnel through the network.
For more information on MPLS operation, see the following sections:

• Figure “MPLS network” (page 23)
• “In the network core” (page 24)
• “In hop-by-hop routes” (page 24)
• “In explicit routes” (page 26)
Figure 2
MPLS network
MPLS network
FEC1
LSP for FEC1
LSR LSR LER
FEC1
LER LSR LER
LSP for FEC2

FEC2
FEC2
PPT 2888 002 AA
At the edge of the network

When IP traffic arrives at an LER, MPLS applies the label for the first time.
To do this, the LER analyzes the information in the IP packet header, and
classifies traffic according to its destination and class of service
characteristics. The destination can be as broad as a router identifier or IP
address prefix, or it can be as specific as a full 32-bit IP host address.

At the LER, MPLS uses the concept of a forwarding equivalence class (FEC)
to map incoming traffic to an LSP. Essentially, a FEC defines a group of
packets that are forwarded over the same path with the same forwarding
treatment. This means that all the packets with the same FEC can be mapped
to the same label.
For each FEC, the LER sets up an LSP through the network to the destination
defined by the FEC. After the traffic is assigned a FEC, the LER applies a
label based on the label information base (LIB). The LIB maps each FEC to
an LSP label that defines the next-hop link. Because the underlying layer-2
media is ATM, MPLS uses the VCI of the ATM VCC as the label.
To forward the packet, the LER looks up the FEC in the LIB, and then
encapsulates the packet with the LSP label. The LER then sends the packet
out on the next-hop interface defined in the LIB.
In the network core

When a labeled packet arrives at an LSR, the LSR extracts the incoming label
and uses it as an index into the LIB. When the LSR finds the appropriate LIB
entry, it extracts the corresponding outgoing label and swaps it with the
incoming label in the packet. The LSR then sends the packet on the outgoing
interface to the appropriate next hop specified in the LIB entry.
Eventually, the packet reaches the edge of the MPLS network. At that point,
an LER removes the encapsulating label, and the packet continues to its
destination according to conventional IP routing methods.
In hop-by-hop routes
The basic LSP is a hop-by-hop LSP. A hop-by-hop LSP is part of a tree from
every source to a particular destination. See Figure 3, “Hop-by-hop LSP,”
(page 25). For these LSPs, MPLS builds a set of trees that duplicate the
destination-based trees that IP uses to forward traffic. MPLS converts the
destination-based trees into label-switching trees.
With IP routing, each router along a path examines a packet’s destination and
chooses a new link. With MPLS, the packet follows the same path it would
take with IP routing, but the packet is assigned a label and link at the ingress
LER. When the packet arrives at the next hop, its label is replaced with the
241-5701-445 2.2S1
next label along the tree toward the destination and sent to the corresponding
link. In this way, the packet follows the IP routing path, but its IP header is
never checked along the route.
At each node, MPLS creates the tree by allocating a label for every next-hop
MPLS destination and exchanging the labels with those peers. The exchange
is accomplished through LDP request and mapping messages. For example,
in figure “Hop-by-hop LSP” (page 25), LSR G maps incoming labels 14, 23,
and 24 to outgoing label 30.
Note: In the diagrams in this section, the node labelling (A, B, C)

represents the actual IP addresses used by the software.
Figure 3
Hop-by-hop LSP
21 D F
B 14 24 H
29
12 E G
23 30
C 5
LIB
In Out
14 30
23 30
24 30
PPT 2888 003 AA

In explicit routes
One of the major advantages of MPLS is its ability to steer traffic, for example
to avoid congestion or to meet the QoS of the traffic. MPLS allows the
network operator at the source node to determine an explicit route LSP (ER-
LSP) that defines the path the traffic will take. Multiple ER-LSPs, with
different quality of service, can be configured to the same destination.
Unlike the hop-by-hop LSP, the ER-LSP does not have to follow the IP tree.
Instead, the ER-LSP builds a path from source to destination. See figure “ER-
LSP” (page 26).To build this path, MPLS embeds the explicit route into the
label request message using the protocol called constraint-based routing
using LDP (CR-LDP).
Figure 4
ER-LSP
LIB
In Out
A 14 4
Route = 21 D F
{ D,F,H } 14
B 4 H
2
E G
PPT 2888 004 AA
There are two types of ER-LSPs: strict ERs and loose ERs. A strict ER
specifies the exact path a packet will take. MPLS at the source node explicitly
indicates all the hops along the path between the end points. A loose ER
specifies some, but not all, of the hops a packet must traverse on the way to
its destination.
241-5701-445 2.2S1
Figure “Strict and loose ER LSPs” (page 27) shows the difference between
strict and loose ERs. The strict ER in the illustration is specified at LER A as
{LSR B, LSR D, LSR E}. In establishing a strict ER, MPLS does not need to
check the IP routing tables, since the exact route is defined.
The loose ER in figure “Strict and loose ER LSPs” (page 27) is specified at
LER A as {LSR E}. In the illustration, the complete path can be either
{LER A, LSR B, LSR D, LER E} or {LER A, LSR C, LSR D, LER E}. In
the loose segment between LER A and LSR E, MPLS checks the IP routing
tables during call setup to determine the best next hop to the next specified
ER hop in the route.
In Passport MPLS, loose ERs are pinned ERs. This means that, after the route
is set up, it does not change unless failure occurs, even if the IP routing tables
change.
Figure 5
Strict and loose ER LSPs
B D E
A C
Strict ER
Loose ER
PPT 2888 005 AA
The network operator can specify each hop in an ER as either an ingress

interface address or an IPv4 prefix. For example, in figure “ER specification”
(page 28), the strict ER can be identified at LER A as {LSRB_ID, 20.1.2.6,
20.1.2.8}.

Figure 6
ER specification
20.1.2.5 20.1.2.7
B D E
20.1.2.4 20.1.2.6 20.1.2.8
A C
20.1.2.3
PPT 2888 006 AA
MPLS in Passport nodes

For ER-LSPs, Passport nodes have both LER and LSR functionality. This
means that Passport nodes can originate ER-LSPs. For hop-by-hop LSPs,
Passport nodes act only as ATM LSRs. This means that a Passport node can
receive and pass on LSP traffic, but cannot originate a hop-by-hop LSP.
241-5701-445 2.2S1
29
Chapter 2
MPLS description
For an explanation of how MPLS operates, see the following sections:
• “MPLS protocols” (page 29)
• “Creation of LSPs” (page 34)
• “Traffic engineering with MPLS” (page 38)
• “MPLS using ATM media” (page 40)
• “LSP recovery” (page 42)
MPLS protocols
The MPLS protocols are used to set up, maintain, and tear down label
switched paths (LSPs). The protocols allow LSP establishment by mapping
network-layer routing information to data link-layer switched paths. MPLS
routes are not supported in other protocols. LSPs are similar to static routes,
and do not get exported; they appear only in the local routing table. For a
description of MPLS protocols, see the following sections:
• “Label distribution protocol” (page 29)
• “Constraint-based routing using LDP” (page 32)
Label distribution protocol

The basic signaling protocol in MPLS is the label distribution protocol
(LDP). As its name indicates, LDP provides the method of distributing label
binding information between MPLS nodes, or peers.

30 Chapter 2 MPLS description
LDP messages
There are four categories of LDP messages:
• discovery messages
These hello messages announce and maintain the presence of an LSR in
the network. An LSR periodically sends a hello message as a UDP packet
to the LDP port of all its neighbors.
• session messages
These messages establish, maintain, and terminate sessions between
LDP peers. When an LSR learns of another LSR through the hello
message, it begins the LDP initialization procedure by opening a TCP
connection. In the initialization procedure, the LSRs exchange
initialization messages. When the procedure is successfully completed,
the two LSRs are peers.
At this stage, the LSRs exchange address messages, which are used to
create databases of mapping between peer LDP identifiers and next-hop
addresses. After an LSR has advertised its interface addresses, it can send
label request or label mapping messages. If there is no other information
to exchange, LSR peers exchange keepalive messages to maintain the
session. To terminate a session, the LSR sends a shutdown message.
241-5701-445 2.2S1
Chapter 2 MPLS description 31
• advertisement messages
These messages set up LSPs by creating, changing, and deleting label
mappings for FECs. An LSR requests a label with the request message
and advertises a label mapping with the mapping message.
The times at which the LSRs send these messages depend on the label
advertisement mode and the label distribution control mode. Passport
MPLS uses the downstream-on-demand label advertisement mode and
the ordered label distribution mode.
In the downstream-on-demand mode, shown in figure “Downstream-on-

demand label advertisement” (page 32), the upstream LSR requests label
mappings and the downstream LSR assigns the labels and informs the
upstream LSR. In the illustration, LSR B, on the egress side, is the
downstream LSR, and LSR A, on the ingress side, is the upstream LSR.
In the ordered distribution control mode, an LSR transmits a label

binding only when it is the egress LSR for that FEC or when it has
received the binding from a downstream LSR. Otherwise, the LSR must
wait until it receives a label before returning a label to the next upstream
LSR.
• notification messages
These messages provide advisory information, such as status information
and signal error conditions.

Figure 7
Downstream-on-demand label advertisement
Ingress Request Egress

side side
router router
A B
Upstream Mapping Downstream
PPT 2888 007 AA
LDP encoding
LDP uses a type-length-value (TLV) encoding scheme for the information
carried in LDP messages. Each LDP message is made of specific TLVs. For
example, the label request message contains a FEC TLV that defines the FEC
for the LSP as an IPv4 address or a router identifier (IPv4 address prefix). The
address list TLV in the address message defines the interface addresses of the
advertising LDP peer. The label mapping message contains a FEC TLV and a
label TLV. A label TLV contains the VCI of the ATM VCC link.
Constraint-based routing using LDP

Constraint-based routing using LDP (CR-LDP) is an extension of the LDP
protocol. CR-LDP allows forwarding on the basis of constraints such as
explicit routes or traffic parameters. CR-LDP permits the traffic engineering
that is essential to the management and predictability of large networks.
241-5701-445 2.2S1
CR-LDP builds on the LDP protocol, using the same mechanisms and
messages for peer discovery, session establishment, label distribution, and
error handling. The extensions to LDP are implemented in the following
added TLVs in the label request and label mapping messages:
• explicit route (ER) and ER-hop TLVs
The ER TLV contains a list of nodes that defines the path of an ER-LSP.
The ER TLV is made of one or more ER-hop TLVs. Each ER-hop TLV
defines one hop in the ER, using an IPv4 address prefix or a router
identifier, and specifies whether the ER is strict or loose.
• traffic parameters TLV

This TLV defines the required characteristics of a constraint-based LSP.
This TLV is included in a CR-LDP label request message to specify the
traffic parameters needed for the requested ER-LSP. When the LSR
receives the request, MPLS negotiates with the ATM software to reserve
the requested bandwidth. If the resources are available, the LSR reserves
the bandwidth. If not, the LSR returns a notification message with the
resource_unavailable status code. The TLV contains the following fields:
— the peak data rate (PDR) and peak burst size (PBS) fields define the
maximum rate at which data can be sent to the ER-LSP
— the committed data rate (CDR) and committed burst size (CBS)
fields define the rate at which the MPLS domain commits to being
available to the ER-LSP
— the frequency field constrains the amount of variable delay that the
network can introduce into the CDR
• LSP identifier (LSPID) TLV
This TLV provides a unique identifier for the LSP within the MPLS
network.

Creation of LSPs
Before data can transfer over an LSP, the LSP must be set up using the LDP
or CR-LDP protocol. For more information on LSP call setup see the
following sections:
• “Call setup for hop-by-hop LSPs” (page 34)
• “Call setup for ER-LSPs” (page 35)
Note: In the diagrams in this section, the node labelling (A, B, C)

represents the actual IP addresses used by the software.
Call setup for hop-by-hop LSPs

Figure “Call setup for hop-by-hop LSPs” (page 35) shows the hop-by-hop
LSP setup process. The diagram shows the downstream-on-demand label
advertisement mode and the ordered distribution control mode used in the
Passport network.
1 At LER A, MPLS generates a label request message. LER A determines
the link to the next hop (LSR B in the example) from the IP routing table,
and sends on a label request message to LSR B.
2 At LSR B, MPLS receives the label request. MPLS determines the link
to the next hop (LSR D in the example) from the IP routing table, and
sends on a label request message. The same process occurs at LSR D.
3 The label request message terminates at the destination LER, node F.
MPLS at node F sends a label mapping message back to LSR D. The
mapping message contains the label for LSR D to use in sending packets
to LER F.
Because the underlying layer-2 media is ATM, MPLS uses the VCI of the
ATM VCC as the label. The mapping between the FEC and the VCC is
maintained in the LIB. To determine the FEC/label mapping, the LSRs
negotiate with the ATM software to reserve a VCC.
In the example, MPLS at LER F sends a message to LSR D containing

the label 17.
4 MPLS at LSR D receives the mapping message and updates the LIB with
the label information for LER F. In the example, MPLS updates the
database with 17 as the outgoing label for FEC 20.1.2.3.
241-5701-445 2.2S1
5 This process continues until the originating LER receives the mapping
message and establishes the LSP.
Figure 8
Call setup for hop-by-hop LSPs
Routing table
Routing table Addr Next hop
Addr Next hop 20.1.2.3 LSR D
20.1.2.3 LSR B
2
Label B D
1 request
3
A F
IP packet
20.1.2.3
20.1.2.3
Label
mapping
4
LIB LIB
In FEC Out In FEC Out
12 20.1.2.3 03 03 20.1.2.3 17
LSP
LDP messages
PPT 2888 008 AA
Call setup for ER-LSPs

Figure “Call setup for ER-LSPs” (page 36) illustrates the ER-LSP setup
process for a strict ER. The process takes the following steps:
1 MPLS at LER A generates a label request message. The message
contains ER-hop TLVs that define the ER path through nodes C and E to
LER F.

2 At LSR C, MPLS receives the label request message and determines

from the ER hop list that the next-hop node is LSR E. Since the route is
pre-defined, there is no need to check the IP routing table. MPLS
removes LSR C from the path list, and sends the message to LSR E. The
process repeats at LSR E.
3 At LER F, the request message terminates. MPLS sends a label mapping
message back to LSR E. The mapping message contains the label for
node E to use in sending packets to LER F. In the example, the label is 13.
4 LSR E receives the mapping message, and updates the LIB entry for
LER F.
5 This process continues until LER A receives the mapping message and
establishes the ER.
Figure 9
Call setup for ER-LSPs
Label
request:
C,E,F B D
1
20.1.2.3
A F
IP packet 2 3
20.1.2.3 Label
5 C E mapping
LIB 4 LIB
In FEC Out In FEC Out
07 20.1.2.3 19 19 20.1.2.3 13
ER
CR-LDP messages
PPT 2888 009 AA
241-5701-445 2.2S1
Call setup for a loose ER is a combination of the process for a hop-by-hop

LSP and the process for a strict ER. The loose ER setup works like the strict
ER setup for those segments of the route that have defined end points. In the
loose segments, MPLS accesses the IP routing tables to get next-hop
information.
LDP/CR-LDP interworking
Figure “LDP/CR-LDP interworking” (page 38) shows a situation in which
the LDP and CR-LDP protocols work together. In this case, traffic flows up
to a point in the network core on an LSP. At a certain LSR, traffic engineering
conditions require the traffic to continue on an ER-LSP. LDP/CR-LDP
interworking allows a tandem LSR to aggregate LDP traffic at the LDP/CR-
LDP boundary into a traffic-engineered core based on CR-LDP.
There are three possible interworking situations:

• LDP to CR-LDP to LDP
In this case, an LSP begins in the LDP domain, tunnels through the CR-
LDP domain, and terminates in another LDP domain.
• CR-LDP to LDP
In this case, an LSP begins in the CR-LDP domain and ends in the LDP
domain.
• LDP to CR-LDP
In this case, an LSP begins in the LDP domain and terminates in the CR-
LDP domain.
In the first interworking situation, the first and last nodes in the CR-LDP
domain handle the conversion from one protocol to the other. In the other two
cases, only one conversion is needed, and the egress CR-LDP node or the
ingress CR-LDP node handles the conversion.
In LDP to CR-LDP interworking, the ingress node MPLS in the CR-LDP

domain translates all ingress LDP messages into CR-LDP messages. The
network operator at that node provisions the interworking ER-LSP and inserts
an ER hop list into the label request message. (The provisioned FEC element

must match the FEC in the hop-by-hop request message exactly.) In the
example in figure “LDP/CR-LDP interworking” (page 38), the ER-hop TLVs
specifying LSR F and LSR H are inserted into the label request at LSR D.
If the LSP terminates in the LDP domain, the egress LSR in the CR-LDP
domain translates the CR-LDP messages back into LDP messages.
Figure 10
LDP/CR-LDP interworking
Label
request
A { F,H}
21 D F
14
B 6 24 H
29
12 E G
C 5 LDP CR-LDP
PPT 2888 010 AA
Traffic engineering with MPLS

With the increasing demand and explosive growth of the Internet, carriers
need a network infrastructure that is dependable and offers consistent,
predictable network performance. The traffic engineering capabilities of
MPLS provide a solution for this situation. The cornerstone of the MPLS
solution is the ER-LSP, which the network operator can manipulate to control
the transport of IP traffic.
The ER-LSP can be used to map traffic flows onto the network, independently
of the layer-3 topology, so that each application receives the QoS it needs.
MPLS allows the network operator to configure an LSP group, with multiple
241-5701-445 2.2S1
LSPs, to the same FEC destination. Each LSP group has up to four active
primary LSPs, with different QoS and up to seven hot standby backup LSPs
for each primary LSP, to the same FEC destination.
Each LSP in an LSP group is configured to a particular service category called

MPLS service category (MSC). Each MSC has its own QoS requirements.
There are a maximum of eight MSC classes (0-7) in an LSP group. The
network operator can define a one-to-one mapping between IP class of
service (COS) and MPLS service category (MSC). Each of the four currently
available IP COS values (0,1,2,3) can be mapped to a unique MSC value of 0
to 7. As there are four IP COS values and eight MSC values, it is expected that
some MSC values will not be mapped to an IP COS value.
Figure “MPLS traffic engineering” (page 40) shows a simple example of

MPLS traffic engineering. In the example, a video server is configured at
LSR A on the ingress side, and a video client is configured at LSR F on the
egress side. Regular IP traffic runs across an ATM connection from LSR A to
LSR F, following a best-effort, shortest path. If the video stream is introduced
on this path, the path becomes congested, and the QoS will degrade. With
MPLS, the network operator can configure an ER-LSP through LSR B and
LSR D. The ER-LSP forces the video traffic to follow the longer route, but
maintains the QoS.
To guarantee the service in case of link failures, the network operator can
configure a maximum of seven standby LSPs per primary LSP. A standby
LSP is an LSP that can take over the traffic carried by the primary LSP, or
another standby LSP, if that LSP should fail. The standby LSP serves in the
same MPLS service category (MSC) as the primary LSP.
Standby LSPs are hierarchically ordered under the primary LSP. The ordering
determines the order in which a standby LSP takes over in the event of a
primary failure (and which standby would take over in the event of a standby
failure). In order to provide fast switchover capability, a standby LSP is in the
established state, and occupies bandwidth along the backup LSP path.
LSP2 represents a standby LSP path from LSR A through LSR C and LSR E
to LSR F. If a link fails on LSP1, the traffic switches to LSP2, the first standby
in the primary LSP’s standby list.

Since the primary LSP is intended to be the preferred LSP for traffic use, a
check of all the primary LSPs under all LSP groups is performed every five
seconds. If a primary LSP is found to be available to carry traffic, but has a
standby that is currently carrying the traffic, the data path is switched to that
of the primary LSP.
Figure 11
MPLS traffic engineering
LSP1
B D
router router
A F
From server To client

C E
LSP2
IP traffic
Hot stand-by
ER-LSP
PPT 2888 011 AA
MPLS using ATM media

The supporting layer-2 medium for Passport MPLS is ATM. For information
on the interaction between MPLS and ATM see the following sections:
• “Label encapsulation” (page 41)
• “Ships-in-the-night operation” (page 41)
• “QoS mapping” (page 41)
241-5701-445 2.2S1
Label encapsulation
Passport MPLS supports two types of label encoding:
• single-level VCI encoding
• null shim header encoding
For operation in the Passport network, MPLS uses the ATM VCI as the label.
The label is contained in the combined VCI and VPI fields of the ATM header.
The shim header, defined by MPLS standards, is a generic label that is placed
between the layer 2 and layer 3 headers. The shim label is commonly used for
PPP and LAN hardware. Passport MPLS places a null shim label in the
headers at the LERs to support interworking with LSRs from other vendors
whose products use shim headers.
Ships-in-the-night operation
Passport MPLS interacts with ATM in the operating mode called ships-in-the-
night. In this mode, MPLS and ATM control planes share hardware ports, but
work independently. This mode of operation allows a Passport node to
function simultaneously as an ATM switch and an MPLS LSR. The MPLS
control plane provides IP-based services, and the ATM control plane provides
ATM-based services. The two control planes share memory, VPI/VCI space,
processing capacity, and traffic management capabilities.
In ships-in-the-night mode, MPLS and ATM share the ATM VPI/VCI space.
Initially, the network operator configures the MPLS label range. Then, the
VPI/VCI label range for MPLS is negotiated with the ATM software during
LDP peer initialization. After negotiation, MPLS can use only the VPI/VCI
range agreed to. ATM can use the entire VPI/VCI space.
The network operator defines one VCC as the MPLS control channel for each
LDP interface.
QoS mapping
To support mission-critical traffic, carriers need to be able to guarantee an
end-to-end QoS for a traffic path. To do this, the network operator configures
an ER-LSP with a set of traffic parameters provisioned to define its QoS. The

QoS values defined by MPLS traffic parameters map directly to ATM service
categories. Table “Mapping of MPLS traffic parameters to ATM service
categories” (page 42) shows this mapping.
After the ER-LSP is set up over ATM media with the appropriate QoS, its
MPLS traffic is treated the same as ATM traffic. Bandwidth reservation and
traffic management for the ER-LSP are based on the corresponding ATM
service category indicated by its traffic parameters.
Table 1
Mapping of MPLS traffic parameters to ATM service categories
ATM service MPLS traffic parameters

category
PDR PBS CDR CBS Frequency
CBR.1 PCR CDVT PCR CDVT Very frequent
(CLP0+1) (CLP0+1)
VBR.3 (rt) PCR CDVT SCR (CLP0) MBS (CLP0) Frequent
(CLP0+1)
VBR.3 (nrt) PCR CDVT SCR (CLP0) MBS (CLP0) Unspecified
(CLP0+1)
UBR PCR CDVT — — Unspecified
(CLP0+1)
LSP recovery
If a failure occurs during LSP setup, the LSR immediately downstream from
the failure point releases the LSP to the egress LER. The LSR immediately
upstream from the failure point sends a notification message to the ingress
LER to tear down the connection.
The ingress LER releases the LSP to the failure point and begins a recovery
process. If there is a hot stand-by path configured, the LER shifts the traffic
to the stand-by path. Otherwise, the LER attempts to set up a new LSP to the
destination. This rerouting attempt is called global repair.
241-5701-445 2.2S1
43
Chapter 3
Configuring MPLS
For information on how to configure MPLS, see the following sections:
• “Implementation of MPLS” (page 43)
• “Prerequisites to configuring MPLS” (page 45)
• “Installing MPLS software” (page 45)
• “Configuring ports and interfaces” (page 46)
• “Configuring LSPs” (page 57)
• “LDP/CR-LDP interworking configuration” (page 67)
• “Locking and unlocking an LSP” (page 70)
For general configuration information and basic configuration procedures,

see 241-5701-600 Passport 7400, 15000 Configuration Guide. For more
detailed definitions of the components you use to configure MPLS, see
241-5701-060 Passport 7400, 15000 Components.
Implementation of MPLS
The figure“MPLS and related components” (page 44) shows the component
structure for MPLS, and its related components and subcomponents.

44 Chapter 3 Configuring MPLS
Figure 12
MPLS and related components
EM
Vr
Ip
Mpls
Ldp
Peer
Session
Adjacency
LspGroup
Lsp
Te
CrQos
Msc
LdpQ
IpForward
Ipv4Addr
MscMap
Path
Hop
XcMap
PP
IpPort
MplsPort
Ldplf
InSeg
OutSeg
AtmMpe
AtmConn
Atmlf
Vcc
PPT 3019 001 AA
Nep
241-5701-445 2.2S1
Chapter 3 Configuring MPLS 45
Prerequisites to configuring MPLS

Before you configure MPLS on a Passport node, you must
• remove any pre-PCR2.2 version of MPLS from the node.
• make sure that the IP software is installed on the node (for more
information, see 241-5701-810 Passport 7400, 15000 Configuring IP)
• make sure that the atmmpe (wanDte) software is installed on the node
(for more information, see 241-5701-810 Passport 7400, 15000
Configuring IP)
Installing MPLS software

You can install MPLS software after the base software and the IP and ATM
MPE features have been installed on the Passport node. To install MPLS
software, use the following procedure:
1 Add the MPLS application to the application version list of the Software
component.
set sw avl mpls_<version>
where:
<version> is the application version from the Passport Release
Supplement.
2 Add a logicalProcessorType component.
add sw lpt/<lpt_name>
where:
<lpt_name> is any mnemonic (for example, mpls_lp).
3 Set the LPT feature list to include the MPLS feature.
set sw lpt/<lpt_name> fl mplsCrldp
where:
<lpt_name> is the mnemonic you used in step 2.

Configuring ports and interfaces

Before you can configure MPLS, you must set up the logical ports and
interfaces for the MPLS software to use. To do this setup, use the following
procedures:
• “Configuring the virtual router and protocol port” (page 46)
• “Configuring the ATM media and links” (page 47)
• “Configuring the IP port” (page 50)
• “Configuring the MPLS port” (page 54)
• “Configuring the MPLS component” (page 51)
Configuring the virtual router and protocol port

The first stage in configuring MPLS is to create the virtual router, the IP
component, and the protocol port. The figure “Component tree for
configuring the virtual router and protocol port” (page 46) shows the
components configured in this procedure.
Figure 13
Component tree for configuring the virtual router and protocol port
EM
VirtualRouter (Vr)
Ip
ProtocolPort (Pp)
PPT 3019 002 AA
1 Add a Vr component.
add Vr/<vrId>
where:
<vrId> is an alphanumeric string of up to eight characters that identifies
the VR.
2 Add an Ip component as a subcomponent of the Vr component.
241-5701-445 2.2S1
add Vr/<vrId> Ip
where:
<vrId> is the name assigned to this VR.
3 Add a ProtocolPort (PP) component as a subcomponent of the Vr
component.
add Vr/<vrId> pp/<pp_id>
where:
<pp_id> is an alphanumeric string of up to 20 characters that identifies
the PP.
Configuring the ATM media and links

After the VR and PP are configured, you need to perform the following tasks:
• Configure the atmmpe service.
• Configure the ATM interface.
• Link the AtmMpe component to the PP you defined previously.
• Link the AtmMpe component to the ATM interface.
• Link the PP to the AtmMpe component.
The figure “Component tree for configuring the ATM media and links”
(page 48) shows the components configured in this procedure.

Figure 14
Component tree for configuring the ATM media and links
EM
VirtualRouter (Vr)
ProtocolPort (Pp)
AtmMultiprotocolEncapsulation (AtmMpe)
AtmConnection (Ac)
AtmInterface(Atmlf)
VirtualChannelConnection (Vcc)
NailedUpEndpoint (Nep)
PPT 3019 003 AA
1 Add the AtmMpe component.

add AtmMpe/<mpe_name>
where:
<mpe_name> is a decimal in the range 0 to 255
2 Add the AtmConnection component as a subcomponent of the AtmMpe
component.
add AtmMpe/<mpe_name> AtmConn/<conn>
where:
<mpe_name> is the identifier assigned to this AtmMpe component.
<conn> is a decimal in the range 0 to 255.
3 Link the AtmMpe component to the VR PP.
set AtmMpe/<mpe_name> linkToProtocolPort Vr/<vrId> pp/
<pp_id>
where:
241-5701-445 2.2S1
<pp_id> is the identifier assigned to this PP.

4 Add the AtmIf component.
add atmIf/<n> Vcc/<vpi.vci>
where:
<n> is the instance value of the AtmIf component in the range of 1 to
1024.
<vpi.vci> is the identifier of the VP and VC of the virtual channel.
5 Define the ATM VCC as a nailed-up connection.
add atmIf/<n> Vcc/<vpi.vci> Nep
where:
<n> is the instance value of the AtmIf component.
6 Modify the ATM VCC atmServiceCategory if desired.
set atmIf/<n> vcc/<vpi.vci> vcd Tm atmServiceCategory
constantBitRate
where:
vcd is the VirtualChannelDescriptor.
Note: When an atmIf/<n>/<vpi.vci> channel is created, the default
atmServiceCategory unspecifiedBitRate is used. If you anticipate that the
user traffic on the link will run near its maximum capacity, provision the
atmServiceCategory with the constantBitRate value, to ensure that the
control traffic flowing through the channel will not starve and LSPs will not
be affected.
7 Link the AtmConn component to the Nep component.
set atmMpe/<mpe_name> AtmConn/<conn> AtmConnection
AtmIf/<n> Vcc/<vpi.vci> Nep
where:
<conn> is the identifier assigned to this instance of the AtmMpe AtmConn
subcomponent.


<vpi.vci> is the identifier of the VP and VC of the virtual channel
8 Link the PP component to the AtmMpe component.
set Vr/<vrId> pp/<pp_id> linkToMedia
<media_application>
where:
<media_application> is the identifier of the AtmMpe component.
Configuring the IP port

To configure the IP port, you need to add an IP port as a subcomponent of the
PP and define its IP address. The figure “Component tree for configuring the
IP port” (page 50) shows the components configured in this procedure.
Figure 15
Component tree for configuring the IP port
EM
VirtualRouter (Vr)
ProtocolPort (Pp)
IpPort
IpLogicalInterface (LogicalIf)
PPT 3019 004 AA
1 Add an IpPort component as a subcomponent of the PP component.

add Vr/<vrId> pp/<pp_id> IpPort
where:
241-5701-445 2.2S1
2 Define the IP address for the port.

add Vr/<vrId> pp/<pp_id> IpPort logicalIf/<ip_address>
where:
<ip_address> is the 32-bit address assigned to this logical interface.
Note: An LSP connection created on a specific LdpIf component is
pinned to the ipLogicalInterface component address provisioned under
the IP Port of the corresponding protocol port.The LdpIf component must
be disabled prior to modifying or deleting the ipLogicalInterface
component.
3 Define a network mask for the protocol port.
set Vr/<vrId> pp/<pp_id> IpPort logicalIf/<ip_address>
netMask <mask>
where:
<ip_address> is the 32-bit address assigned to this logical interface.
<mask> is the network mask to be used with the IP address.
Configuring the MPLS component

Before you can configure the MPLS port, you need to create the MPLS
component under the VR and provision MPLS and LDP parameters. The
figure “Component tree for configuring the MPLS component” (page 52)
shows the components and attributes configured in this procedure.
Note: MPLS is supported on one virtual router only.

Figure 16
Component tree for configuring the MPLS component
EM
VirtualRouter (Vr)
MultiprotocolLabelSwitching (Mpls)
adminstatus
IsrIdProv
IspGroupPolicy
Ldp
maxLspPerPeer
keepAliveHoldTimer
helloTimer
failedInitThreshold
loopDetection
hopCountLimit
PPT 3019 005 AA
1 Add the Mpls component as a subcomponent of the Vr component.

add Vr/<vrId> mpls
where:
2 Add the Ldp component as a subcomponent.
add Vr/<vrId> Mpls Ldp
3 Provision the Mpls component parameters.
set Vr/<vrId> mpls adminStatus <status> lsrIdProv
<ip_address> lspGroupPolicy <policy>
where:
<status> is enabled (the default) to enable the LDP protocol on this
node to establish relationships with neighbor LSRs, or disabled to disable
LDP.
<ip_address> is an IP address for the node (known as the LSR
identifier), or 0 (the default) to indicate that the VR router ID must be used
241-5701-445 2.2S1
as the node address for MPLS. If the Ospf routerid attribute is provisioned,
then the LsrId attribute must be the same.
Note: If the LsrId attribute is changed, the MPLS ports will go down. This
service interruption is not reported.
<policy> is restrictive (the default) to define a restrictive policy (the LSR
accepts LSPs for those LspGroups defined on this LSR), or liberal to
define a liberal policy (the LSR accepts LSPs for all LspGroups except
those that are administratively disabled).
4 If required, change the routing preference. See 241-5701-805 Passport
7400, 15000 Understanding IP for more information.
To change the routing preference attribute for MPLS LDP, enter the
following command:
set Vr/<vrId> Mpls defaultLdpMplsRtePref <route_pref>
To change the routing preference attribute for MPLS CRLDP, enter the
following command:
set Vr/<vrId> Mpls defaultCrLdpMplsRtePref
<route_pref>
where:
<route_pref> is the routing preference. The attribute is a decimal
number between 1 and 255 where 255 means the route is never put in the
forwarding table.
Note: Attribute default is 8 for MPLS LDP and 10 for MPLS CRLDP.
5 Provision the Ldp component parameters.
set Vr/<vrId> mpls ldp maxLspPerPeer <max_lsp>
keepAliveHoldTimer <ka_time> helloTimer <h_time>
failedInitThreshold <threshold> loopDetection <loop>
hopCountLimit <limit>
where:
<max_lsp> is a decimal number between 1 and 2000 that specifies the
upper limit on the number of LSPs that can be set up for an LDP
adjacency.
<ka_time> is the number of seconds in the range 1 to 15 specified for
the keepalive hold timer interval.

<h_time> is the number of seconds in the range 1 to 10 specified for the

hello timer interval.
<threshold> defines the threshold of initialization attempts in the range
of 1 to 20. If this threshold is exceeded,
failedInitSessionThresholdExceeded notification is generated.
<loop> is on to indicate that the LSP loop detection capability is enabled,
or off to indicate that it is disabled. When you enable loop detection, you
must set the hopCountLimit attribute.
<limit> specifies the number of hops allowed for each LSP in the range
2 to 40.
Note: Deleting the MPLS component does not delete the MPLS port. All
ports must be deleted before deleting the MPLS component.
Configuring the MPLS port

After the MPLS component has been created, you need to create the MPLS
port under the protocol port and link the MPLS port to the nailed-up ATM
connection. The figure “Component tree for configuring the MPLS port”
(page 55) shows the components and attributes configured in this procedure.
241-5701-445 2.2S1
Figure 17
Component tree for configuring the MPLS port
EM
VirtualRouter (Vr)
ProtocolPort (Pp)
MplsPort
minorUtilAlarmThreshold
majorUtilAlarmThreshold
criticalUtilAlarmThreshold
utilAlarmState
LabelDistributionProtocolIf (LdpIf)
mediaName
atmLabelMinIn
atmLabelMinOut
atmLabelMaxIn
atmLabelMinOut
PPT 3019 006 AA
1 Prior to adding the MplsPort component, ensure that the IP port is

unlocked and operational. Once this has been verified, add an MplsPort
component as a subcomponent of the PP component.
add Vr/<vrId> pp/<pp_id> mplsPort
where:
When you add the MplsPort component, the system automatically adds
the LdpIf component as its subcomponent. Only one LdpIf component
can be configured under the MplsPort component. If more than one LdpIf
component is added, the LdpIf sessions will not establish.
2 Provision the MplsPort component parameters.

set Vr/<vrId> pp/<pp_id> mplsPort

minorUtilAlarmThreshold <minor>
majorUtilAlarmThreshold <major>
criticalUtilAlarmThreshold <critical> utilAlarmStatus
<status>
where:
<minor> defines the threshold value (between 1 and 100) over which a
minor alarm occurs to indicate three minutes of sustained total average
utilization above the threshold. A value of 100 disables the threshold.
<major> defines the threshold value (between 1 and 100) over which a
major alarm occurs to indicate three minutes of sustained total average
<critical> defines the threshold value (between 1 and 100) over which
a critical alarm occurs to indicate three minutes of sustained total average
<status> is enabled to enable the threshold for the utilization alarms, or
disabled to disable the alarms.
3 Link the MplsPort LdpIf subcomponent to the nailed-up ATM connection.
set Vr/<vrId> pp/<pp_id> mplsPort ldpIf mediaName
AtmIf/<n> Vcc/<vpi.vci> Nep
where:
Note: A change to the AtmMpe AtmConnection component requires that
the change be reflected in the LdpIf mediaName attribute.
4 Provision the MplsPort LdpIf component parameters.
set Vr/<vrId> pp/<pp_id> mplsPort ldpIf atmLabelMinIn
<min_in> atmLabelMaxIn <max_in> atmLabelMinOut
<min_out> atmLabelMaxOut <max_out>
where:
241-5701-445 2.2S1

<min_in> defines the minimum value of the ATM label that this LSR will
receive on this interface in the range 0 to 254 or 0 to 16127.
<max_in> defines the maximum value of the ATM label that this LSR will
receive on this interface in the range 0 to 254 or 0 to 16127.
<min_out> defines the minimum value of the ATM label that this LSR will
send on this interface in the range 0 to 254 or 0 to 16127.
<max_out> defines the maximum value of the ATM label that this LSR
will send on this interface in the range 0 to 254 or 0 to 16127.
Note 1: You cannot set the labelType attribute. It is always set to
atmLabel.
Note 2: The label range must correspond to ATM VCI range values.
Note 3: If label range values span over VPs other than VPI 0, and the
ATM card being used is a CQC-based card, the AtmIf ConnMapOverride
component must be configured appropriately. The
numNonZeroVpisForVccs attribute must be set to include all, or at least
some, of the VPs indicated as desired under the LdpIf component for the
label range. Atm media will permit LSP creation only on those VPs in LdpIf
label range which overlap with the ones specified under the
ConnMapOverride component
Configuring LSPs
Passport nodes do not originate hop-by-hop LSPs. The LSPs that you will be
configuring, then, are ER-LSPs. To configure LSPs, use the following
procedures:
• “Configuring an LSP group and IP forwarding policy” (page 57)
• “Configuring the explicit route path” (page 60)
• “Configuring an ER-LSP” (page 61)
• “Configuring LSP quality of service” (page 64)
Configuring an LSP group and IP forwarding policy

To configure an LSP group, you must add the LspGroup component and
configure the IP forwarding policy for the LSP group. The figure
“Component tree for configuring an LSP group and IP forwarding policy”
(page 58) shows the components configured in this procedure.

Figure 18
Component tree for configuring an LSP group and IP forwarding policy
EM
VirtualRouter (Vr)
LspGroup (LspG)
IpFwdPolicy (IpFwd)
Ipv4Addr (Ipv4)
CosMscMapping (MscMap)
PPT 3019 007 AA
1 Add an LspGroup component under the Mpls component.

add Vr/<vrId> Mpls lspGroup/<lspg_name>
where:
<lspg_name> is the identifier assigned to the LSP group.
2 Add the IpFwdPolicy component
add Vr/<vrId> Mpls lspGroup/<lspg_name> IpFwd
where:
3 Define an ipv4Addr subcomponent of the IpFwd component to specify the
common destination IP address of all LSPs in this group.
add Vr/<vrId> Mpls lspGroup/<lspg_name> IpFwd
ipv4Addr/<ipv4Element>,<ipv4Prefix>
where:
241-5701-445 2.2S1
<ipv4Element> is the IP address of the FEC for the LSP group.

<ipv4Prefix> is the length of the IP address specified in the
ipv4Element.
4 Add the MscMap component for class of service to MPLS service
category mapping.
add Vr/<vrId> Mpls LspGroup/<lspg_name> IpFwd MscMap
where:
5 Configure the bestMatchOverride attribute.
set Vr/<vrId> Mpls lspGroup/<lspg_name> ipv4Addr/
<ipv4Element>, <ipv4Prefix> bestMatchOverride <mode>
where:
<ipv4Element> is the IP address of the FEC for the LSP group.
ipv4Element.
<mode> is enabled or disabled (the default).
6 Configure the class of service to MPLS service category mapping, if
desired.
set Vr/<vrId> Mpls LspGroup/<lspG_name> IpFwd MscMap
<value_COS> <value_MSC>
where:
<value_COS> is an IP class of service category and <value_MSC> is
the MPLS service category to which you would like the class of service to
map.

Configuring the explicit route path

To configure the explicit route path, you must define the hops that form a path.
The figure “Component tree for configuring the explicit route path” (page 60)
shows the components and attributes configured in this procedure.
Figure 19
Component tree for configuring the explicit route path
EM
VirtualRouter (Vr)
Path
Hop
ipv4Addr (ipv4)
ipv4PrefixLen
hopMode (mode)
PPT 3019 008 AA
1 Add a Path subcomponent as a subcomponent of the Mpls component.

add Vr/<vrId> Mpls Path/<path>
where:
<path> is the identifier assigned to this path.
2 Add a Hop subcomponent to the Path component.
add Vr/<vrId> Mpls Path/<path> Hop/<hop>
where:
<hop> is the identifier assigned to this hop.
3 Set the Hop component parameters.
241-5701-445 2.2S1
set Vr/<vrId> Mpls Path/<path> Hop/<hop> ipv4Address

<ipv4Element>, ipv4PrefixLen <ipv4Prefix>, hopMode
<mode>
where:
<hop> is the identifier assigned to this hop.
<ipv4Element> is the IP address of the hop destination.
ipv4Element.
<mode> is strict (the default) to specify a strict hop (this is the next hop in
the path after the last hop specified) or loose to specify a loose hop (this
hop may be more than one hop away from the last hop).
4 Repeat step 2 and step 3 for each hop in the path.
Configuring an ER-LSP
Multiple ER-LSPs, under a common LSP group, can be configured to the
same destination IP address. The figure “Component tree for configuring an
ER-LSP” (page 62) shows the components and attributes configured in this
procedure.

Figure 20
Component tree for configuring an ER-LSP
EM
VirtualRouter (Vr)
LspGroup (LspG)
LabelSwitchedPath (Lsp)
TrafficEngineering (Te)
pathName
pathOnDemand
isPinned
MplsServiceCategory (Msc)
serviceCategory (sC)
standbyLsp (sLsp)
Path
PPT 3019 009 AA
1 Add an Lsp component under the LspGroup component.

add Vr/<vrId> Mpls LspGroup/lspG_name> Lsp/<lspId>
where:
<lspId> is the identifier assigned to the LSP.
2 Add the TrafficEngineering subcomponent under the Lsp component.
add Vr/<vrId> Mpls LspGroup/<lspg_name> Lsp/<lspId> Te
where:
3 Add the MplsServiceCategory subcomponent under the Lsp component.
241-5701-445 2.2S1
add Vr/<vrId> Mpls LspGroup/<lspg_name> Lsp/<lspId>

Msc
where:
4 Set the LSP service category.
set Vr/<vrId> Mpls LspGroup/<lspg_name> Lsp/<lspId>
Msc serviceCategory/<category>
where:
<category> is a value from 0-7 to indicate a primary LSP, or standby to
indicate that the LSP is acting as a standby LSP for a primary LSP.
5 Make the association between the path and the LSP, by setting the
pathname attribute of the TrafficEngineering component.
set Vr/<vrId> Mpls LspGroup/<lspg_name> Lsp/<lspId> Te
pathname <path>
where:
<path> is the full path to be used by the LSP.
6 Set the mode of the pathOnDemand attribute, to specify when the LSP
will be set up.
pathOnDemand/<mode>
where:


<mode> is enabled to activate path on demand for the LSP in LDP to CR-
LDP interworking, or disabled (the default) for non-interworking situations.
7 Set the standby LSPs of the primary or main LSP.
set Vr/<vrId> Mpls LspGroup/<lspg_name> Lsp/<lspId>
Msc standbyLsp <list>
where:
<list> is a list of the LSPs assigned as standby LSPs for this primary.
Configuring a hop-by-hop LSP

To support hop-by-hop LSPs, the LdpQos component must be configured.
See “Configuring LSP quality of service” (page 64) for details on adding the
LdpQos component. Note also that the pathName attribute of the Te
component is not applicable. If this value is already set, the pathName
attribute is ignored. You may leave the pathName attribute blank. For details
on setting the attribute, see “Configuring an ER-LSP” (page 61). There are no
provisioning changes for the cross connect map display. For details, see
“Monitoring and troubleshooting” (page 71).
Configuring LSP quality of service

Under the Lsp component are two subcomponents for setting the MPLS
quality of service for an LSP. The CrLdpQos component represents the MPLS
quality of service for an LSP using the CR-LDP signaling protocol. The
LdpQos component represents the MPLS quality of service for an LSP using
the LDP signaling protocol. Note that the LdpQos component and the
CrLdpQos component are mutually exclusive: only one of the components
may be added under the Lsp component. The figure “Component tree for
configuring LSP quality of service” (page 65) shows the components and
attributes that are configured in this procedure.
241-5701-445 2.2S1
Figure 21
Component tree for configuring LSP quality of service
EM
VirtualRouter (Vr)
LspGroup (LspG)
LdpQos (LdpQ)
CrLdpQos (CrQos)
peakDataRate (pdr)
committedDataRate (cdr)
peakBurstSize (pbs)
committedBurstSize (cbs)
PPT 3019 010 AA
1 For an LSP using the LDP signaling protocol, add the LdpQos
subcomponent under the Lsp component.
add Vr/<vrId> Mpls LspGroup/<lspg_name> Lsp/<lspId>
LdpQos
where:
2 For an LSP using the CR-LDP signaling protocol, add the CrLdpQos
subcomponent under the Lsp component.
add Vr/<vrId> Mpls Lspgroup/<lspg_name> Lsp/<lspId>
CrLdpQos
where:


3 Set the maximum rate at which traffic should be sent to the path.
set Vr/<vrId> Mpls Lspgroup/<lspg_name> Lsp/<lspId>
CrLdpQos peakDataRate <rate>
where:
<rate> is a value which specifies the maximum rate for traffic to the path.
4 Set the committed data rate.
CrLdpQos committedDataRate <rate>
where:
<rate> is a value which specifies the committed data rate.
5 Set the maximum burst size.
CrLdpQos peakBurstSize <size>
where:
<size> is a value which specifies the maximum burst size.
6 Set the committed burst size.
CrLdpQos committedBurstSize <size>
where:
241-5701-445 2.2S1

<size> is a value which specifies the committed burst size.
LDP/CR-LDP interworking configuration

Configuring LDP/CR-LDP interworking depends on which of the following
cases is in effect:
• LDP to CR-LDP to LDP
In this case, an LSP begins in the LDP domain, tunnels through the CR-
LDP domain, and ends in another LDP domain. LDP messages are
translated to CR-LDP and back again, as the LSP enters each domain. To
configure this case, you must
— set the pathOnDemand attribute of the ER-LSP at the first node in

the CR-LDP domain (this attribute causes MPLS to wait for an LDP
request before setting up the LSP)
— configure the LDP interface on the last node in the CR-LDP domain
as an interworking interface
• CR-LDP to LDP
In this case, the LSP begins in the CR-LDP domain and ends in the LDP
domain. To configure this case, you need to configure the LDP interface
on the last node in the CR-LDP domain as an interworking interface.
• LDP to CR-LDP
In this case, the LSP begins in the LDP domain and terminates in the CR-
LDP domain. To configure this case, you must configure the
pathOnDemand attribute of the ER-LSP at the first node in the CR-LDP
domain.
See the following information to configure interworking:

• “Considerations for configuring LDP/CR-LDP interworking” (page 68)
• “Configuring LDP/CR-LDP interworking” (page 68)

Considerations for configuring LDP/CR-LDP interworking

Note the following considerations for configuring interworking:
• Global repair is not supported when the CR-LDP LSPs are interworking
with LDP.
• Hot stand-by paths are not supported when the CR-LDP LSPs are
interworking with LDP.
• Multiple ipv4 addresses in a hop-by-hop request message are not
supported.
• The last hop ipv4 address in the hop list corresponds to the ipv4 address
outside the Passport domain. The egress LDP in the domain is configured
for interworking.
Configuring LDP/CR-LDP interworking

The figure “Component tree for configuring LDP/CR-LDP interworking”
(page 69) shows the components and attributes that are configured in this
procedure.
241-5701-445 2.2S1
Figure 22
Component tree for configuring LDP/CR-LDP interworking
EM
VirtualRouter (Vr)
LspGroup (LspG)
TrafficEngineering (Te)
pathOnDemand
ProtocolPort (Pp)
MplsPort
LabelDistributionProtocolIf (LdpIf)
IdpInterworking (IdpInw)
PPT 3019 011 AA
Use the following procedure to configure LDP/CR-LDP interworking.
1 Configure the ER-LSP. (See “Configuring LSPs” (page 57) for details.)
2 At the first node in the CR-LDP domain, provision the pathOnDemand
attribute of the ER-LSP.
pathOnDemand <mode>
where:
<lspId> is the identifier assigned to this LSP.
<mode> is enable to enable path-on-demand for the LSP, or disable (the
default) to disable path-on-demand for the LSP in non-interworking
situations.
3 At the last node in the CR-LDP domain, provision the LdpInterface
component for interworking.

set Vr/<vrId> pp/<pp_id> mplsPort LdpIf

ldpInterworking <iw>
where:
<iw> is true to enable LDP/CR-LDP interworking for the interface, or false
(the default) to disable LDP/CR-LDP interworking for the interface.
Locking and unlocking an LSP

If you wish to change the quality of service, path, hop, or FEC destination for
an LSP, you must lock and then unlock the LSP for the changes to take effect.
The following steps describe how to lock and unlock an LSP:
1 To lock an Lsp component instance:

lock Vr/<vrId> Mpls LspGroup/<lspg_name> Lsp/<lspId>
Te
where:
2 To unlock an Lsp component instance;
unlock Vr/<vrId> Mpls LspGroup/<lspg_name> Lsp/<lspId>
Te
where:
241-5701-445 2.2S1
71
Chapter 4
Monitoring and troubleshooting
For information on monitoring and troubleshooting MPLS, see the following
sections:
• “Tracing an LSP” (page 71)
• “Operational information on LSP groups and LSPs” (page 74)
• “Tracing the peers of a node” (page 77)
• “Troubleshooting” (page 79)
For general information about maintenance procedures, see 241-5701-600

Passport 7400, 15000 Configuration Guide.
Tracing an LSP
To trace an LSP, you normally need to examine the operational attributes of
the LSP segments and the XcMap component at a number of Passport nodes.
Figure “Tracing an LSP” (page 72) shows a simplified three node topology
that you can use as a reference.
To trace an LSP path across multiple nodes, use the following procedures:
• “Displaying the XcMap on the ingress node” (page 72)
• “Displaying the InSegment on the next node” (page 73)
• “Displaying the XcMap on the next node” (page 73)
• “Following the path” (page 74)

72 Chapter 4 Monitoring and troubleshooting
Figure 23
Tracing an LSP
Start
Ingress tracing Tandem Egress
node node node
A B B
VCC label
PPT 2888 012 AA
Displaying the XcMap on the ingress node

The first step in tracing the LSP is to display the XcMap component of your
starting point, which is often the first node in the LSP. (In figure “Tracing an
LSP” (page 72), the starting point is the ingress node.)
1 Determine the name of the XcMap component by displaying the

crossConnectMapName attribute for the LSP.
d Vr/<vrId> Mpls LspGroup/<lspg_name> Lsp/<lspId>
where:
2 Display the XcMap component, using the identifier returned after
displaying the crossConnectMapName attribute.
d Vr/<vrId> Mpls XcMap/<crossConnectMapName>
where:
<crossConnectMapName> is the identifier assigned to the XcMap
component.
241-5701-445 2.2S1
Chapter 4 Monitoring and troubleshooting 73
The system displays the operational attributes of the XcMap component.

These attributes include the component names of the MplsPort
InSegment and MplsPort OutSegment components of the LSP at this
node. The InSegment component and OutSegment component identifiers
are the VCC labels for those segments of the LSP. In the case of an
ingress node, there is no incoming segment, so only the OutSegment
component data is displayed.
Displaying the InSegment on the next node

After you have the name of the MplsPort OutSegment component on the
ingress node, you can display it as the InSegment component on the next node
in the LSP. In figure “Tracing an LSP” (page 72), the next node after the
ingress node is the tandem node.
1 Display the MplsPort InSegment component on the next node.

d Vr/<vrId> pp/<pp_id> mplsPort inSegment/<vcc_label>
where:
<vrId> is the name assigned to the VR.
<vcc_label> is the label, or VCC identifier, for the InSegment (which is
the OutSegment of the previous node).
Displaying the XcMap on the next node

To determine the OutSegment component identifier on the next node, you
need to display the XcMap component.
1 Display the XcMap component.

d Vr/<vrId> Mpls XcMap/<crossConnectMapName>
where:
<crossConnectMapName> is the identifier assigned to the XcMap
component.
The system displays the operational attributes of the XcMap component.
These attributes include the component names of the MplsPort
InSegment and mplsPort OutSegment components of the LSP at this
node. If this were the last hop of the path, MplsPortOutSegment
component would be blank.

Following the path

With the name of the MplsPort OutSegment from the XcMap component of
the second node, you can display the MplsPort InSegment on the next node in
the LSP. In figure “Tracing an LSP” (page 72), the next node is the egress
node. With longer LSPs, you can continue to follow the path by
• using the outgoing segment you know to find out the incoming segment
identifier of the next node
• displaying the XcMap component of the next node to find out the
identifier of the outgoing segment
Operational information on LSP groups and LSPs

To discover operational information about the multiple LSPs under the
LspGroup component, use the following procedures:
Note: These procedures are done in operational mode. For details on

operational mode, see 241-5701-275 Passport 7400, 15000
Commissioning Guide.
• “Displaying information on LSP groups” (page 74)

• “Displaying information on LSPs” (page 75)
Displaying information on LSP groups

1 To view a list of all the LSP groups under the Mpls component:
list Vr/<vrId> Mpls LspGroup/*
where:
2 To view operational information on all LspGroup component instances:
display Vr/<vrId> Mpls LspGroup/*
where:
3 To view operational information for a given LspGroup component
instance:
display Vr/<vrId> Mpls LspGroup/<lspg_name>
241-5701-445 2.2S1
where:
4 To view a list of all the subcomponents of an LspGroup component:
list Vr/<vrId> Mpls LspGroup/<lspg_name>
where:
Displaying information on LSPs

1 To view a list of all the LSPs under the Mpls component:
list Vr/<vrId> Mpls LspGroup/* Lsp/*
where:
2 To view operational information on all Lsp component instances:
display Vr/<vrId> Mpls LspGroup/* Lsp/*
where:
3 To view operational information for a given Lsp component instance:
display Vr/<vrId> Mpls LspGroup/<lspg_name> Lsp/
<lspId>
where:
4 To view a list of all the subcomponents of an Lsp component:
list -p Vr/<vrId> Mpls LspGroup/<lspg_name> Lsp/
<lspId>
where:


5 To view operational information on the MPLS service category for all Lsp
component instances:
display Vr/<vrId> Mpls LspGroup/* Lsp/* Msc
where:
Provisioning the alarm severity for a specific LSP

To specify if a failed LSP should generate a major alarm, use the following
command:
set Vr/<vrId> MplsGroup/<lspg_name> Lsp/<lspId> Te

alarmControl major
where:
To specify if a failed LSP should generate a critical alarm, use the following
command:
set Vr/<vrId> MplsGroup/<lspg_name> Lsp/<lspId> Te

alarmControl critical
where:
To disable alarms on a specific LSP, use the following command:

alarmControl none
where:
241-5701-445 2.2S1

Tracing the peers of a node

To trace the peers of a node, use the following procedures:
• “Displaying the Ldp component” (page 77)
• “Listing the peers of a node” (page 77)
• “Listing the sessions of a peer” (page 78)
• “Listing the adjacencies of a session” (page 78)
Displaying the Ldp component

To determine if a Passport switch has an active peer, display the Ldp
component.
1 d -o vr/<vrId> Mpls Ldp

where:
The system displays the number of active peers and sessions, as well as
the total number of attempted sessions on the Vr.
Listing the peers of a node

Use the following procedure to list the peers of a Passport node.
1 l -o Vr/ <vrId> Mpls Ldp /*

where:
The system lists all of the active peers, if any. Each peer instance is the
routerId of the peer.
2 d -o Vr/<vrId> Mpls Ldp Peer/<peer>
where:
<peer> is the identifier assigned to the peer.

The system display the hello mode, number of established sessions, and
number of attempted sessions for the peer instance.
Listing the sessions of a peer

Use the following procedure to list the sessions of a peer.
1 l -o Vr/<vrId> Mpls Ldp peer/<peer> session/*

where:
The system lists all of the sessions corresponding to that peer. A session
instance represents the local routerId and its corresponding port.
2 d -o Vr/<vrId> Mpls Ldp Peer/<peer> session/<session>
where:
<session> is the identifier assigned to the session.
The system displays the operational state of the session, remote LdpIf,
transport Ipv4 address, the local LdpIf interface component name and the
protocol version. The session may have multiple adjacency instances.
The remote LdpIf represents the adjacency instance that co-exists with
this session on the same connection.
Listing the adjacencies of a session

Use the following procedure to list the adjacencies of a session and their
corresponding operational attribute.
1 l -o Vr/(vrId> Mpls Ldp Peer/<peer> session/<session> adj/*

where:
<adj> is the identifier assigned to the adjacency.
241-5701-445 2.2S1
The system lists all the adjacencies corresponding to the session. An

adjacency instance is the corresponding port on the peer.
2 d -o Vr/<vrId> Mpls Ldp Peer/<peer> session/<session> adj/<adj>
where:
<adj> is the identifier assigned to the adjacency.
The system displays the name of its LdpIf component.
Troubleshooting
To solve problems that occur with MPLS, use the following sections:
• “Statistics” (page 79)
• “Solving problems” (page 80)
Statistics
Table “MPLS interface statistics” (page 79) lists the statistics reported by the
MPLS interface.
Table 2
MPLS interface statistics
Statistic Reported by Reported by Reported by

MplsPort InSegment OutSegment
inLabelsUsed yes no no
inOctets no yes no
inPackets no no no
inDiscards no yes no
inErrors no yes no
failedLabelLookup no no no
outLabelsUsed yes no no
(Sheet 1 of 2)

Table 2 (continued)
MPLS interface statistics
Statistic Reported by Reported by Reported by

MplsPort InSegment OutSegment
outOctets no no yes
outPackets no no no
outDiscards no no yes
outErrors no no no
inUtil no no no
inTrafAboveMinorUtil no no no
AlarmThresh
inTrafAboveMajorUtil no no no
AlarmThresh
inTrafAboveCritUtil no no no
AlarmThresh
outUtil no no no
outTrafAboveMinorUtil no no no
AlarmThresh
outTrafAboveMajorUtil no no no
AlarmThresh
outTrafAboveCritUtil no no no
AlarmThresh
(Sheet 2 of 2)
Solving problems
The main source for troubleshooting information is the label switched path
(LSP). If a label switched path (LSP) has come up successfully, the
operStatus attribute will indicate established. If an LSP has not been
successfully established, the operStatus attribute will indicate idle.
241-5701-445 2.2S1
If the operStatus attribute indicates that the LSP is idle, the administrator can
refer to the lastTearDownReason attribute for information on why the LSP
has not been established. (Note that it is not possible to determine the node in
question.)
2> d vr/0 mpls lspGroup/<lspg_name> lsp/<lspId>
Vr/0 Mpls LspG/179 Lsp/1
adminState = unlocked
operationalState = enabled
usageState = busy
operStatus = established
direction = uniDirectionalOut
crossConnectMapName = Vr/0 Mpls XcMap/1140854775
retryCount = 63
pathFailureCount = 5
lastTearDownReason = badLooseNode
pathUpDateTime = 2001-02-08 11:03:24.33
alarmControlOper = none
Table 3
Troubleshooting the LSP
Tear Down Reason Trouble Shooting Solution
loopDetected The hop list for the ER contains a loop. Check hop lists for
loops and correct
noRoute A remote peer is down and a route for the specified Check remote peers
LSP cannot be established. and determine which
one(s) are down.
Remedy problem and
return to service.
noLabelResources 1) The label resources for a specific peer do not Change the range of
have any more labels available. labels or stop routing
2) The atmLabelMinIn and the atmLabelMaxIn LSPs through this
attributes are not a subset of the AtmIf CA peer.
attributes minAutoSelectedVciforVpiZero and
maxAutoSelectedVciforVpiZero.
badStrictNode A bad hop exists in the path for a specific strict ER Check your hop list
LSP. and remedy the bad
hop.
(Sheet 1 of 2)

Table 3 (continued)
Troubleshooting the LSP
Tear Down Reason Trouble Shooting Solution
badLooseNode A bad hop exists in the path for a specific loose ER Check your hop list
LSP and remedy the bad
hop
sessRejNoHello A situation can arise when a session sends an init Check the version of
before the hello. This might happen between software being used
different versions of the software. Software that and make sure it is
conforms to the specification will not result in this the latest version.
problem being seen.
TrafficParaUnavailab A label was not setup as a result of the traffic Provide a traffic TLV
le parameters not being available. for the ER-LSP.
labelRequestAbort A label request got aborted as a result of The problem should
configuration on the switch. remedy itself once
the configuration
changes have taken
effect. Check the LSP
status to see if it gets
established, or refer
to the last tear down
reason again.
erLocked The LSP ER is locked. Unlock the ER LSP.
peerDown An egress peer on the Passport shelf is down. Check the passport
and bring the Peer
into service.
(Sheet 2 of 2)
241-5701-445 2.2S1
Multiprotocol Label Switching
Guide
Release 2.2
Copyright © 2001 Nortel Networks.

All Rights Reserved.
NORTEL NETWORKS, the globemark design, the NORTEL

NETWORKS corporate logo, DPN, DPN-100, and PASSPORT are
trademarks of Nortel Networks.
Publication: 241-5701-445
Document status: Standard
Document version: 2.2S1
Document date: February 2001
Printed in Canada

Multi Protocol Label Switching Guide

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Multi Protocol Label Switching Guide

Enviado por

Direitos autorais:

Formatos disponíveis

Passport 7400, 15000

Copyright © 2001 Nortel Networks.

Passport 7400, 15000 Multiprotocol Label Switching Guide 2.2S1

Passport 7400, 15000 Multiprotocol Label Switching Guide 2.2S1

Configuring LDP/CR-LDP interworking 68

Passport 7400, 15000 Multiprotocol Label Switching Guide 2.2S1

Passport 7400, 15000 Multiprotocol Label Switching Guide 2.2S1

About this document

The following topics are discussed in this section:

Who should read this document and why

Passport 7400, 15000 Multiprotocol Label Switching Guide 2.2S1

What you need to know

How this document is organized

What’s new in this document

Multiple LSPs per FEC

• “Configuring MPLS” (page 43)

Alarms and Statistics

Configuring a hop-by-hop LSP

Nonproportional spaced plain type represents system generated text or

• nonproportional spaced bold type

Passport 7400, 15000 Multiprotocol Label Switching Guide 2.2S1

Words that appear in italics in text are for naming.

See the following Passport documents for information related to MPLS:

How to get more help

Passport 7400, 15000 Multiprotocol Label Switching Guide 2.2S1

What is MPLS technology?

Essentially, MPLS forwards a packet by swapping labels at each node in its

Passport 7400, 15000 Multiprotocol Label Switching Guide 2.2S1

Packet Packet label Packet

Forwarding Forwarding Forwarding

PPT 2888 001 AA

MPLS is an emerging standard for network-layer packet forwarding, based on

How is MPLS implemented in Passport networks?

The Passport implementation of MPLS takes advantage of the distributed

Passport 7400, 15000 Multiprotocol Label Switching Guide 2.2S1

Why use MPLS?

How does MPLS work?

For more information on MPLS operation, see the following sections:

LSP for FEC1

LSR LSR LER

LER LSR LER

LSP for FEC2

PPT 2888 002 AA

At the edge of the network

Passport 7400, 15000 Multiprotocol Label Switching Guide 2.2S1

In the network core

Note: In the diagrams in this section, the node labelling (A, B, C)

PPT 2888 003 AA

Passport 7400, 15000 Multiprotocol Label Switching Guide 2.2S1

PPT 2888 004 AA

PPT 2888 005 AA

The network operator can specify each hop in an ER as either an ingress

Passport 7400, 15000 Multiprotocol Label Switching Guide 2.2S1

20.1.2.4 20.1.2.6 20.1.2.8

PPT 2888 006 AA

MPLS in Passport nodes

Label distribution protocol

Passport 7400, 15000 Multiprotocol Label Switching Guide 2.2S1

In the downstream-on-demand mode, shown in figure “Downstream-on-

In the ordered distribution control mode, an LSR transmits a label

Passport 7400, 15000 Multiprotocol Label Switching Guide 2.2S1

Ingress Request Egress

Upstream Mapping Downstream

PPT 2888 007 AA