Alcatel-Lucent Multiprotocol Label Switching Student Guide v2-1-Dl

Alcatel-Lucent Multiprotocol Label
Switching (MPLS)
Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute
Module 0 Course Introduction
Module Objectives
Alcatel-Lucent Career Certification Flow

y
y
y
y
y
Introduction
Objectives
Timeline
Prerequisites and Follow-on
Administration
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 0 | 2
All rights reserved 2011 Alcatel-Lucent
Alcatel-Lucent Multiprotocol Label Switching

This course is part of the Alcatel-Lucent Service Routing Certification (SRC) Program. See www.alcatellucent.com/src for more information on the SRC program.
To locate additional information relating to the topics presented in this manual, refer to the following:
Technical Practices for the specific product
Internet Standards documentation such as protocol standards bodies, RFCs, and IETF drafts
Technical support pages of the Alcatel-Lucent website located at: http://www.alcatel-lucent.com/support
Module 0 - Page 2
Alcatel-Lucent Multiprotocol Label Switching Course Information
The Alcatel-Lucent SRC Program Five Certifications

ALCATEL-LUCENT
NETWORK ROUTING SPECIALIST I
ALCATEL-LUCENT
NETWORK ROUTING SPECIALIST II
4 DAYS / 1 COURSE / 1 WRITTEN EXAM
18 DAYS / 4 COURSES / 4 WRITTEN EXAMS /

1 PRACTICAL LAB EXAM
ALCATEL-LUCENT
ALCATEL-LUCENT
TRIPLE PLAY ROUTING PROFESSIONAL MOBILE ROUTING PROFESSIONAL
32 DAYS/ 7 COURSES / 7 WRITTEN EXAMS /

2 PRACTICAL LAB EXAMS
36 DAYS / 8 COURSES / 8 WRITTEN EXAMS /

1 PRACTICAL LAB EXAM
ALCATEL-LUCENT
SERVICE ROUTING ARCHITECT
49 DAYS / 11 COURSES / 11 WRITTEN EXAMS / 2 PRACTICAL LAB EXAMS
Module 0 | 3
3
Module 0 - Page 3
Module 0 | 4
SRC Courses and Exams
4
Module 0 - Page 4
Exam Number
Exam Pre-requisites
(4A0-XXX)
Alcatel-Lucent Scalable IP Networks
4A0-100
NA
Alcatel-Lucent Interior Routing Protocols
4A0-101
NA
Alcatel-Lucent Border Gateway Protocol
4A0-102
NA
4A0-103
NA
Alcatel-Lucent Services Architecture
4A0-104
NA
Exam Name
Alcatel-Lucent Virtual Private LAN Services
4A0-105
NA
Alcatel-Lucent Virtual Private Routed Networks
4A0-106
NA
Alcatel-Lucent Quality of Service
4A0-107
NA
Alcatel-Lucent Multicast Protocols
4A0-108
NA
Alcatel-Lucent Triple Play Services
4A0-109
NA
Alcatel-Lucent Advanced Troubleshooting
4A0-110
NA
Alcatel-Lucent IP/MPLS Mobile Backhaul Transport
4A0-M01
NA
Alcatel-Lucent Mobile Gateways for the LTE Evolved

Packet Core
4A0-M02
NA
Alcatel-Lucent Network Routing Specialist II Lab Exam
NRSII4A0
100, 101, 103, 104
Alcatel-Lucent Mobile Routing Professional Lab Exam
MRP4A0
100, 101, 103, 104, 107, M01, M02, NRSII4A0
Alcatel-Lucent Service Routing Architect Lab Exam
ASRA4A0
100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110,
NRSII4A0
Module 0 | 5
SRC Program Exam Profile
Module 0 - Page 5
Exam Delivery
Written Exams
Delivered by Prometric
Global provider of testing services
5000+ test sites worldwide
Register at:
www.prometric.com/alcatel-lucent
Lab Exams
Written at Alcatel-Lucent sites

NRS II Certification
Half-day lab exam
MRP Certification
Half-day lab exam
SRA Certification
Full-day lab exam
Register at:
www.alcatel-lucent.com/src/examreg
Module 0 | 6
Module 0 - Page 6
SRC Program
Global Reach, Flexible Delivery Options
On-site delivery at your business location anywhere in the world
Delivery from any of the following Alcatel-Lucent University locations
globally
Europe
Antwerp, Belgium
Newport, UK
Paris, France
Americas
Plano, USA
Ottawa, Canada
Mexico City, Mexico
Sao Paulo, Brazil
APAC
Shanghai, China
Sydney, Australia
Melbourne, Australia
Wellington, New Zealand
Bangalore, India
Chennai, India
Gurgaon, India
Mumbai, India
Class schedules posted @ www.alcatel-lucent.com/src

Registration online @ www.alcatel-lucent.com/src/coursereg
Module 0 | 7
7
Module 0 - Page 7
Your Own Service Router Lab Now you can have one
Need access to a lab to help you:

Prepare for your NRS II and SRA exams?
Practice and build your service routing knowledge and configuration skills?
The Alcatel-Lucent Exam Preparation service provides:
Remote, private access (724) to an Alcatel-Lucent service router lab:

six-node fully meshed network three-hour time slots available
Access to a suite of over 30 lab practice scenarios with optimal solutions
Access to traffic simulation and analysis tools
To find out more and sign up visit http://www.alcatel-lucent.com/src/examprep
Module 0 | 8
Module 0 - Page 8
Credit for other IP Certifications

Cisco or Juniper certified?
You can receive exemptions from
some of the SRC exams, if you
hold any one of the Cisco or
Juniper certifications identified
Certifications must be valid to

receive exemptions
Submit your request for
exemptions at: http://www.alcatellucent.com/src/exemptions
Module 0 | 9
9
Module 0 - Page 9
MPLS is a label switching technology that combines the traffic

engineering capability of ATM with the flexibility and scalability of
IP. MPLS provides the ability to establish connection-oriented paths
over a connectionless IP network, and facilitates a mechanism to
engineer network traffic patterns independently of routing tables.
MPLS technology offers many services, including layer 2 and layer 3
VPN services, traffic engineering, and resiliency.
This 5-day instructor-led course is designed to introduce and explore
MPLS concepts and related signaling protocols. It examines the LDP
and RSVP protocols and their position in the MPLS topology. To
reinforce the course objectives, there will be discussions,
comprehensive lab exercises, and case studies.
Module 0 | 10
Module 0 - Page 10
Alcatel-Lucent MPLS Course Goal
Module 0 | 11
Provide the participants with a foundation knowledge of MPLS and

related protocols, and their application and implementation in an
Alcatel-Lucent network environment.
Module 0 - Page 11
Alcatel-Lucent MPLS Course Content

Course Introduction
Module 1 Introduction to MPLS
Module 2 Fundamentals of MPLS
Module 4 Resource Reservation Protocol
Module 5 Traffic Engineering
Module 6 Resiliency
Module 0 | 12
Module 0 - Page 12
Module 3 Label Distribution Protocol
Alcatel-Lucent MPLS Course Objectives

Upon successful completion of this course, you should be familiar
with:
The drivers for MPLS
MPLS control and data plane operation
MPLS terminology and uses in an Alcatel-Lucent environment
LDP and RSVP protocol operation and configuration

The options available for traffic engineering in an MPLS network,
including configuration and operation
How to traffic engineer in a hierarchical network using LDP-overRSVP
The available options for achieving resiliency with MPLS networks
The implementation of fast re-route in an Alcatel-Lucent
environment
Module 0 | 13
Module 0 - Page 13
Alcatel-Lucent MPLS Course Timeline

Day 1
Module 0 Course Introduction
Day 2
Lab
Lab
Lab
Lab
3.1 MPLS Infrastructure Verification and IGP Configuration

3.2 Configuring and Verifying the Provider Core for LDP
3.3 Enabling LDP ECMP
3.4 Applying Export Policy for Label Distribution
y
y
y
y
Day 3
Module 4 Resource Reservation Protocol
y Lab 4 IGP-Based RSVP LSP Establishment

Module 0 | 14
Module 0 - Page 14
Alcatel-Lucent MPLS Course Timeline (contd)

Day 4
Module 5 Traffic Engineering (contd)
Lab
Lab
Lab
Lab
Lab
5.1
5.2
5.3 5.4
5.5
Configuring Link Coloring for Constraint-Based LSP Tunnels

Diffserv TE LSP Maximum Allocation Method (MAM)
Diffserv TE LSP Russian Doll Model (RDM)
Configure LDP over RSVP across OSPF Areas
Configure RSVP for IP Routing
y
y
y
y
y
Day 5
Module 6 Resiliency
y
y
y
y
Lab
Lab
Lab
Lab
6.1 Enabling Primary and Secondary LSP Tunnels

6.2 Using SRLG for Path Resiliency
6.3 FRR Facility Backup Protection
6.4 FRR One-to-One Protection
Module 0 | 15
Module 0 - Page 15
Alcatel-Lucent MPLS Course Prerequisites and Follow-on

Suggested Prerequisites
In order to fully appreciate the concepts to be discussed in this
course, it is strongly recommended that the following courses
will have already been successfully completed:
Alcatel-Lucent Scalable IP Networks
Alcatel-Lucent Interior Gateway Protocols
MPLS Exam
To ensure full comprehension of the material covered in this
course, it is recommended that the student register for, and
take, the Alcatel-Lucent MPLS exam following successful
completion of this course.
Suggested Follow-on Courses
Based on the material covered in this course, it is recommended
that this course be followed with the Alcatel-Lucent Services
Architecture course.
Module 0 | 16
Module 0 - Page 16
Module 0 | 17
Alcatel-Lucent MPLS Symbols and Icons
Typical graphic symbols found in this courseware.
Module 0 - Page 17
Administration
Registration
Facility Information
Restrooms
Communications
Materials
Schedule
Introductions
Name and Company
Experience
Questions
Module 0 | 18
Module 0 - Page 18
www.alcatel-lucent.com/src
3FL-30635-AAAA-ZZZZA Edition 01

Switching
Module 1 Page 1
Module Objectives
Upon successful completion of this module, you should be able

to:
Define Multiprotocol Label Switching (MPLS) Standards and basic
terminology
Explain the MPLS data plane operations
Identify advantages of MPLS over IP-only networks
Module 1 | 2

This course is part of the Alcatel-Lucent Service Routing Certification (SRC) Program. See www.alcatel-lucent.com/src
for more information on the SRC program.
Module 1 Page 2
Describe MPLS service and resiliency drivers
Module 1 MPLS Overview
Section 1 MPLS Drivers
Module 1 Page 3
Section Objectives
In this section, we will introduce the role of MPLS in:

Improving forwarding performance
Traffic Engineering applications
Building High Available Networks
Delivering Layer 2 and Layer 3 Services
Triple Play Solutions
Building a BGP Free Core
Module 1 | 4
This section provides a general overview of the diverse services and applications that became available with the
establishment of MPLS tunnels, and all their related features.
Module 1 Page 4
Consolidation of Services over a common infrastructure
Multiprotocol Label Switching
RFC 3031 describes the Multiprotocol Label Switching (MPLS)

architecture
Label Switching describes that an MPLS domain switches, rather

than routes, packets in the Service Provider Core
MPLS routers forward packets using pre-determined labels
Module 1 | 5
Multiprotocol Label Switching (MPLS) allows routers to forward traffic based on a simple label embedded in the packet
header. An MPLS router examines the label to determine the next-hop for the packet. This simplifies the forwarding
process and separates it from the routing protocol, which determines the route that traffic will take across the
network.
MPLS is a label switching technology that sets up a specific path for a sequence of packets. Each packet is identified by
a label inserted in the packet and forwarding occurs based on this label.
MPLS is independent of any routing protocol but is considered multiprotocol because it works with the Internet Protocol
(IP), Asynchronous Transport Mode (ATM), and Frame Relay (FR) network protocols.
In the case of IP networks, any IGP routing protocol may be used to establish the IGP infrastructure.
The MPLS Working Group of IETF at http://www.ietf.org/html.charters/mpls-charter.html may be used as a further
reference.
Module 1 Page 5
The term Multiprotocol indicates that an MPLS architecture can

transport payloads from many different protocols (IPv4, IPv6,
Ethernet, ATM, Frame Relay, etc.)
Label Switching was initially considered an improvement over IP packet

switching, as it involves a simpler lookup.
However, with the advances in hardware technology, MPLS for L3
forwarding alone has become obsolete in recent years.
Module 1 | 6
Initially, engineers developed a label switching protocol to improve packet processing in IP routers. Routers did their
work in software rather than hardware, and MPLS packet switching could improve performance. Routing was considered
to be slower and more cumbersome.
Routing an IP packet requires that the device process the packet up to Open Systems Interconnect (OSI) Layer 3. The
router looks at the destination IP address in the IP header and compares it against the routing table entries, locating
the longest, or best, match. This process can be quite resource intensive, depending on the routing table size.
The MPLS Label Binding Table lookup process is simpler. The table only contains the forwarding information associated
with an exact match, rather than a longest match, so the forwarding table can be smaller than a routing table. The
nodes forward traffic using a predetermined label sent down a preselected path and replaced at each hop, so they can
decide much more quickly where to send the packets next.
Modern manufacturing and hardware advances have negated much of the speed benefits gained when using MPLS versus
routing strictly for moving IP packets. Routers now use special purpose hardware, namely Application-Specific
Integrated Circuits (ASIC), to forward IP packets in the data plane. The packet processing time differences between the
two techniques is so insignificant that this argument becomes invalid.
Module 1 Page 6
Improved Switching Performance
Same path is used for both traffic with hop-by-hop IP forwarding.

In case of congestion, packet drops occur.
Alternative links not- or under-utilized.
Module 1 | 7
Routing protocols cannot make use of all available network resources because of their limited mechanisms for selecting
the best path.
Routing protocols do not provide routers with any visibility into network resource utilization, and therefore the routers
do not recognize congestion on the network links, underutilized alternate paths, or idle links.
Distributing the aggregate network traffic load over all available resources becomes difficult in conventional IP routing,
and IP hyperaggregation remains a problem.
MPLS can help engineers correct hyperaggregation issues with traffic engineered label switch paths that are planned
and designed to better balance the traffic load in a hierarchical, highly reliable network infrastructure.
Module 1 Page 7
Traffic Engineering IP Hyperaggregation
MPLS offers manageable and scalable tools that engineer the traffic
flows for better utilization of network resources.
Module 1 | 8
Traffic Engineering refers to the ability to optimize the use of network resources; that is, utilizing all the links and
router processes in the most efficient way as possible.
With reference to the above slide, using an IP-only network on router R3, traffic from both routers R1 and R2 will be
forwarded to router R4, based on the IGP best path (lowest cost) decision. This can cause congestion (bottleneck) issues
on the links depicted along the blue path, while the links along the red path might be underutilized, or not used at all.
IP does not have the inherent capability to tackle such issues because of its design. Equal Cost Multiple Path (ECMP) is
thus offered as a possible solution. It adjusts the IGP costs of both paths equally, so that load balancing can be
achieved. However, this would quickly prove to be a non-scalable and unmanageable approach for large networks.
Solving the problem for a certain portion of the network, or for certain sets of traffic flows, would create problems for
others.
With the RSVP-TE protocol, MPLS can offer a better and easy-to-use solution to service providers. In this example, the
network administrator can easily steer the traffic originating from router R2 over the bottom path, through router R5,
which is completely different from the IGP chosen path.
MPLS Traffic Engineering is covered in greater detail in Module 5.
Module 1 Page 8
Traffic Engineering MPLS RSVP
MPLS offers a rich set of traffic protection mechanisms that surpass the
IGP convergence times.
Module 1 | 9
In the event of unexpected network resource failure, such as within a link or complete node, the ability of the network
to respond as quickly as possible becomes extremely important. The total amount of time it takes to reroute traffic
over other links/nodes is called convergence time.
The convergence times offered by an IP-only network depend on a number of factors but, in any case, they can be
unsatisfactory, and even unacceptable, for certain mission-critical traffic types or customers.
MPLS provides outstanding rerouting performance, with easily configurable features.
Using Fast Reroute, each router can signal a protection LSP that takes a path away from the potential point of failure in
advance. This can be the next-node or next-link along the path of the Primary LSP, as shown in the above slide.
Fast Reroute has a proven field record of providing less than 50 milliseconds of convergence times for large numbers of
LSPs after detecting failure.
In cases where end-to-end protection of primary LSPs is required, secondary LSPs can also be used. In normal
circumstances, the traffic is forwarded over the primary LSP. If the primary LSP fails, the secondary can take over.
Using the standby option on the secondary LSP further improves the convergence times after failure detection.
Fast reroute and Secondary (standby) LSP features can be used individually or in conjunction for any configured primary
LSP.
MPLS fast convergence (resiliency) features are covered in greater detail in Module 6.
Module 1 Page 9
High Available MPLS Networks
Module 1 | 10
MPLS is mature, standards-based technology that continues to evolve in many service provider networks around the
globe.
The real advantage of MPLS is its versatile and unmatched ability to support all the aforementioned services,
applications, and solutions over a converged networking infrastructure.
Its resiliency and security features are provided by the inherent tunneling and traffic protection mechanisms covered in
this section.
Module 1 Page 10
Consolidation of Services Over a Common Infrastructure
Virtual Private Wire Services (VPWS) provide point-to-point

transport of legacy networking technologies (ATM, FR, TDM) as
well as ubiquitous Ethernet.
Module 1 | 11
A Virtual Private Network (VPN) offers a private, isolated and secure connection between customer sites. Business VPN
Services are among the most important applications and are a significant source of revenue for service providers.
For the customer demanding service to connect two remote sites that require dedicated point-to-point connectivity, a
Virtual Leased Line (VLL ) or Virtual Private Wire Service VPWS) can be utilized. As the name implies, a VLL emulates a
private leased line connection over a packet-based core infrastructure. It is the simplest type of VPN to deploy with
minimal resource requirements, which is ideal for point-to-point connectivity scenarios.
From the customers perspective, the service provider network that provides the VLL service acts like an end-to-end
wire. For this reason, this type of service is also referred to as a Virtual Private Wire Service (VPWS). An industry
standard exists under the name pseudowire to allow for interoperability across different providers willing to provide
this service. In Alcatel-Lucent parlance, this is called a Pipe service.
If the User Network Interface (UNI) at both sides of the connection are Ethernet based, the service is called an ePipe.
An important benefit of MPLS is its ability to support legacy access technologies such as ATM, FR or TDM. These traffic
types can easily be transported through aPipe, fPipe and cPipe respectively, thanks to the transparent nature of the VLL
connection.
A similar service can be provided over a pure IP-network, as well by using Generic Routing Encapsulation (GRE) tunnels,
which utilize an IP header. Security concerns can further be addressed using IPSec on top of the GRE tunnels via
encryption. Although such solutions work, they bring high operational overhead and are slow and not scalable.
The advantage of MPLS is the ease of provisioning and maintenance, and of providing a scalable, highly available, and
standards-based solution.
Module 1 Page 11
Layer 2 Point-to-Point VPN Services (VPWS)
VPLS (Virtual Private LAN Service) connects multiple customer

sites, emulating a Layer 2 bridged environment.
Module 1 | 12
In relation to the VPN requirements presented, Virtual Private LAN Service (VPLS) enables multipoint connectivity at OSI
Layer 2 for enterprise customers.
In the above figure, a VPLS service is illustrated with three participating service routers. The service acts a bridged
Layer 2 multipoint VPN, connecting various geographically dispersed customer sites. The service provider network acts
like an Ethernet bridge or switch, from the perspective of the customer. All customer end devices connected to the
same VPLS service appear to be on the same broadcast domain.
Thus, there is also a clear demarcation of functionality and responsibility between the service provider and the
customer. The service provider simply provides Layer 2 connectivity, based on MAC address communication. With this,
the customers can maintain their routing control tasks themselves.
VPLS supports features such as VLAN trunking, double tagging (also known as Q-in-Q), VLAN translation, and several
variations of the Spanning Tree Protocol (STP) to avoid Layer 2 broadcast storms.
The Alcatel-Lucent Service Router implementation addresses possible scalability concerns by introducing the
Hierarchical VPLS (H-VPLS) and Provider Backbone Bridging (PBB) features.
Virtual Private LAN Services and related features are covered in detail in the dedicated VPLS course of the SRC
program.
Module 1 Page 12
Layer 2 Multipoint VPN Services (VPLS)
A VPRN (Virtual Private Routed Network) service connects multiple

customer sites while maintaining separate, isolated route tables for each
customer.
Module 1 | 13
The multipoint connectivity needs of customers can also be addressed via the use of Layer 3 (IP) VPN Services.
Alcatel-Lucent calls this type of service a Virtual Private Routed Network (VPRN). The term peering model is also used
in the industry for such solutions, because peer relationships between the customer and provider edge routers are
necessary to exchange IP routing information.
The privacy concerns in IP-VPN services are addressed by Virtual Routing and Forwarding (VRF) instances on the service
router. Each IP-VPN customer is allocated a separate VRF, which isolates routing information and enables the use of
overlapping private IP address spaces at each customer site.
Isolation is achieved inherently in the core, thanks to the tunneling concept that uses labels.
IP-VPN services are typically offered as managed services and are usually preferred by customers willing to offload their
routing control tasks to the service provider.
Prior to MPLS, IP-VPN services could still be offered on IP-only networks through routing policies and packet filters that
achieve isolation and separation between different customers. This approach can easily become overwhelmingly
complex and administratively non-scalable or unmanageable, however, hence the extensive MPLS feature set.
Module 1 Page 13
Layer 3 Multipoint VPN Services (VPRN)
Module 1 | 14
A Triple Play network provides IPTV, Video On-Demand, VoIP, Internet access, and other IP-based applications for
subscribers (residential home users). The Triple Play solution allows service providers to provide combined data,
Internet access, and video and voice applications to large numbers of customers.
The Triple Play reference architecture in the diagram is based on two major network elements, optimized for their
respective roles: the Broadband Service Aggregator (BSA) and the Broadband Service Router (BSR).
BSA devices have Layer 2 service capabilities that forward traffic using Layer 2 mechanisms. They also have the Quality
of Service (QoS) and packet filtering capabilities necessary to enforce higher-level policies. BSAs terminate Layer 2
access traffic, forward the traffic over MPLS tunnels, and then terminated the tunnels on the BSRs.
The BSRs are highly scalable, high throughput devices that perform routing and additional QoS and subscriber
management functions.
The connectivity between the BSAs and BSRs is provided through a secure and resilient VPLS infrastructure. The
combined security features of this model prevent unauthorized access, denial of service, and theft of service.
Broadband Service Access Network (BSAN) devices are typically Digital Subscriber Line Access Multiplexer (DSLAM)
devices, which terminate physical connections from home user devices. The BSANs connect the home users to the BSAs.
Module 1 Page 14
The Triple Play Solution
BGP traffic is tunneled through the core, removing the need for the
routers inside the IP/MPLS core to maintain BGP routing information.
Module 1 | 15
Packet forwarding in a service provider IP network is possible only if the routes to all destination prefixes are known on
each router.
In many typical deployments, BGP is used to bring external routing information from other autonomous systems to
provide connectivity to the global internet. The number of IPv4 prefixes in the global internet table has exceeded well
beyond 300,000 as of 2010 (http://bgp.potaroo.net/).
In the IP-only case, normally all the routers in the service provider domain need to contain these external routes in
their BGP tables for packet forwarding to work end-to-end. This includes even the core (P) routers, which might not
have to offer directly BGP related services on themselves, unlike the PE routers.
However, by using MPLS shortcut tunnels between the PE devices and the BGP Peering Router(s), external traffic can be
label-switched through the tunnels in a transparent fashion from the perspective of the P or core routers; hence the
term, BGP-Free Core.
For reference, Route Reflectors are commonly used to reduce the amount of internal BGP peering sessions. The same
tunneling methodology can be applied to remove the burden of keeping and processing a high number BGP routes from
core routers and relaxing the memory and CPU resources on these routers.
Module 1 Page 15
BGP-Free IP/MPLS Core
Section Summary
This section provided an overview on:

y The function of MPLS in Business VPN Services
y The function of MPLS in Triple Play Solutions
y The function of MPLS in providing a BGP-Free Core
y Traffic Engineering capabilities of MPLS

y Traffic Protection mechanisms offered by MPLS
y How IP/MPLS networks serve as a common infrastructure for the
consolidation of multiple services and access technologies.
Module 1 | 16
Module 1 Page 16
Module 1 MPLS Overview
Section 2 Introduction to MPLS
Module 1 Page 17
Section Objectives
In this section we will:

Offer a brief definition of MPLS and provide RFC references.
Introduce the concept of a label.
Define the basic terminology used in MPLS (P/PE/CE, LER, LSR,
FEC)
Present the requirements for label signaling protocols in MPLS and
relate the LIB/LFIB relationship to the RIB/FIB of IP routing
protocols.
Module 1 | 18
This section provides an overall review of some of the fundamental principles of Multiprotocol Label Switching. An
introduction to the technology and its related terminology is also provided.
The concepts are presented in a way that allows for comparison with normal IP routing that can help highlight the
packet forwarding differences and the benefits introduced by MPLS.
The end of the section takes a glimpse into the tables maintained on MPLS enabled routers to pave the way for
following modules, in which the control plane perspective will be analyzed from a much deeper perspective.
Module 1 Page 18
Introduce the data plane operation of MPLS (Push, POP, Swap)
The following routing process occurs at each router:

y Check and remove the L2 encapsulation header of the incoming
packet.
y Examine the L3 (IP) header and perform a longest match lookup on the
destination IP address in the forwarding table.
y Determine the next hop interface.
y Build a new L2 encapsulation header and forward the packet to the
next hop router.
Module 1 | 19
The end-to-end IP packet forwarding process relies on a hop-by-hop forwarding paradigm.

Every router in the network builds a routing table using the routing protocols and the information that they receive
from the other routers. When data arrives at the router, it uses the routing table to determine the next hop to the
destination. The routing table contains a list of network destinations with the next-hop address to be used to reach
them.
When a packet is received, each router choose the best path over which to forwarding the packet by using its Layer 2
association and Layer 3 routing tables.
Module 1 Page 19
IP Routing Overview
Module 1 | 20
Packet forwarding includes the following key actions:

1. Data link layer frame validation performs basic frame length and FCS verification and frame sanity checks.
When a router receives a frame from a LAN, it reads the destination MAC address to ensure that it is the intended
recipient of the frame. Then, if it is the intended recipient, the router checks the FCS for errors related to the
frame. If there are any errors, the router discards the frame.
2. Network-layer protocol demultiplexing determines the upper protocol that needs to receive encapsulated data.
This step is performed after the L2 information is removed so that the payload is handed to the correct upper layer.
3. IP packet validation performs basic IP header verification.
The router verifies the packet before performing further processing. The version and ToS fields are examined and
removed. The TTL field should be greater than 1; if the TTL = 1, the packet is discarded because its TTL is finished.
4. Forwarding decision finds a path to the destination
The router checks its routing table for a route to the packets destination. If it finds a match between the packets
destination IP address and one of the prefixes (every entry is checked), it chooses the egress interface. If it does not
find a match, it drops the packet.
5. Data link frame construction encapsulates packet.
The IP packet is encapsulated in the L2 frame that corresponds to the egress interface. If the interface is Ethernet,
new source and destination MAC addresses are added, the router sets the frames type field and creates a new FCS.
The packet is sent to the physical layer for transport.
Module 1 Page 20
IP Routing Process on a Single Router
MPLS Terminology
iLER : Ingress Label Edge Router
eLER: Egress Label Edge Router
LSR : Label Switch Router
Service architecture terminology

PE : Provider Edge Router
P : Provider (Core) Router
CE : Customer Edge Router
Module 1 | 21
Customer edge devices

A customer edge (CE) device resides on the customer premises. The CE device provides access to the service provider
network over a link to one or more provider edge (PE) routers. The end user typically owns and operates these devices.
The CE devices are unaware of tunneling protocols or VPN services that are provided by the service provider.
Provider edge devices
A provider edge (PE) device has at least one interface that is directly connected to the CE devices. In addition, a PE
device usually has at least one interface that connects to the service providers core devices or routers. The PE device
must be able to connect to different CE devices over different access media, so it is usually able to support many
different interface types. The PE device is the customer's gateway to the VPN services offered by the service provider.
Provider router
Provider (P) routers are located in the provider core network. The P router supports the service providers bandwidth
and switching requirements over a geographically dispersed area. The P router does not connect directly to the
customer equipment.
LER (Label Edge Router)
The LER MPLS router resides in the boundary between the MPLS domain and the customer domain (hence the keyword
edge). In this sense, it is similar to the PE. This naming convention refers to routers function in the MPLS datagram
forwarding process. An LER may be an:
Ingress LER (iLER): Non-MPLS traffic enters the MPLS domain through the iLER. The iLER adds a label to the nonMPLS traffic and sends it to the next hop LSR.
Egress LER (eLER): MPLS traffic exits the MPLS domain through the eLER. The eLER removes the label from the MPLS
packet and forwards the unlabeled packet to the CE router.
LSR (Label Switched Router)
The LSR resides within the MPLS domain. It connects the iLER and eLER to form a path for forwarding labeled traffic
through the MPLS domain. When an LSR receives labeled traffic, it replaces the incoming (ingress) label with an
outgoing (egress) label and forwards the labeled packet to the next hop router.
Whether a router is iLER, eLER, or LSR depends on where that router resides in the MPLS domain as well as the direction
in which traffic flow. A different CE-CE pair or traffic flow direction could change these roles.
Module 1 Page 21
MPLS Terminology: PE, P, CE, LER, LSR
Labels are pushed onto packets as they enter the service provider
network. They are swapped across the network and popped as
they leave the network.
Module 1 | 22
The above slide illustrates the basic data plane forwarding process of MPLS labeled packets.
A label header is a fixed length entity the router inserts into the packets as they enter the Service Provider Core
Network. The process occurs on the first router (PE) attached to the CE device and is called a Push operation.
The packet that comes in from the CE router, indicated as Data in this figure, can be any type of non-MPLS traffic,
depending on the type of service (the different service types will be presented in the next section).
The Provider (P) routers simply check the incoming label against their Label Forwarding Database to find out the
interface and outgoing label needed to forward the packet to the next-hop. The PE router at the other end of the flow
strips the incoming label and sends the packet again as unlabeled to the other CE router.
The details of the label structure and concepts, such as label stacking, are explained in Module 2.
Building the Label Forwarding Database is explained more in detail later in this section.
Module 1 Page 22
MPLS Label Switching: Push, Swap & Pop
LSP Label Switched Path

An LSP is a logical entity that represents the MPLS label
connection between Label Edge Routers.
Another commonly used synonymous term is transport tunnel.
Module 1 | 23
A Label Switched Path (LSP) can be defined as a sequence of labels and label actions performed on MPLS routers to
forward data packets from point A to point B, using label switching.
A Label Switched Path always starts from an iLER and ends at an eLER. An LSP is thus an end-to-end, unidirectional path
that can carry traffic from Router A to Router B.
In the above slide, traffic flows from left-to-right. The flow of MPLS labeled packets in the other direction, that is,
right-to-left, would be represented by another LSP pointing in the reverse direction. In that case, the roles of the iLER
and eLER routers in the figure would be swapped.
The encapsulation and forwarding of packets using labels is also referred to as tunneling; as such, LSPs are often called
as tunnels.
Tunnels must be established prior to the arrival of data packets. Label negotiation and distribution protocols are used
to build the tunnels with negotiated label values. The details of these control processes and exact mechanisms of MPLS
protocols will be covered in the upcoming modules.
Module 1 Page 23
MPLS Terminology: LSP
FEC (Forwarding Equivalence Class) in IGP
FEC Forwarding Equivalence Class

A FEC is a group of IP packets forwarded in the same manner, over
the same path, and with the same forwarding treatment.
y For example: An entry in route table for 10.1.1.0/24 with nexthop address 15.15.15.15
y Two received packets with addresses 10.1.1.1 and 10.1.1.2 will
both be forwarded to the same next-hop, 15.15.15.15. In this
manner, it could be said that they both share the same FEC.
In IP-based routing, FEC lookup is done at each hop.
Module 1 | 24
Forwarding Equivalence Class (FEC) allows for the classification of packets into groups based on common criteria.
In IP networks, the most commonly used Forwarding Equivalence Class (FEC) is the packets destination IP addresses
(prefixes).
By definition, FECs can be based on other administrative criteria, such as the markings inside packets that indicate
Class of Service information.
In IP routing, packets are reclassified at each hop along their forwarding paths, according to their destination IP
addresses.
Module 1 Page 24
For IP-only networks, FECs usually correspond to an IP prefix in the

route table.
FEC (Forwarding Equivalence Class) in MPLS
In MPLS, FECs can be defined based on destination IP prefixes, and

other administrative criteria.
The FEC lookup determines the next hop LSR and the label the
source router pushes onto the packet.
The LSRs then simply perform swap operations based on the
previously determined label values.
Module 1 | 25
The tunnels are established before the data packets arrive on the ingress router. When the label associations to the
tunnels are also known, the ingress LER decides if the data packet will be forwarded via normal IP routing or via label
switching. The choice depends on the service configuration of the router associated with the incoming interface on
which the packet was received.
If label switching is to be used, the ingress LER chooses the tunnel and pushes the label onto the packet before sending
it to the next LSR.
The LSRs along the path do not need to reclassify the packets as they receive them; they merely swap the labels
according the previously determined and negotiated values.
Module 1 Page 25
In MPLS-based forwarding, FEC lookup is done only at the ingress

LER on incoming data packets.
9 FEC lookup is done only at the iLER
Module 1 | 26
When an iLER receives a packet, it makes a decision to forward the packet via an MPLS tunnel (LSP). As indicated in the
previous slide, this depends on the definition of the service the ingress interface is associated with.
If the iLER decides to use an MPLS tunnel to forward the packet, it performs an FEC lookup in its Label Binding Table.
As the name implies, the Label Binding Table contains FECs received from other routers and their label associations.
In this example, and throughout this course, the FEC corresponds to an IP prefix (an IP address plus a subnet mask) that
exists on a router.
In the figure above, FEC x belongs to router R5, which is why we have LSP 1 pointing to, or terminating on, router R5.
FEC y belongs to router R6; therefore, the final destination for LSP 2 is router R6.
Through the lookup operation, the iLER finds out that the packet needs to be forwarded through LSP 1, thus a label with
a value of Label1 is pushed onto the packet and sent to router R1, which is the next-hop LSR. The rest of the story is
as explained in previous slides.
The exchange of label bindings and the process of building the binding tables are summarized in the following slides.
Module 1 Page 26
MPLS FEC Lookup at Ingress LER
Routing Protocols exchange routing updates on the control plane

With this information the Control Processor Module (CPM)
populates the RIB (Routing Information Base)
Module 1 | 27
Every router consists of a Control Plane and a Data Plane. Data packet processing and forwarding take place on the Data
Plane. The Control Plane is like the command center of the router; communication with other routers via protocols and
maintenance functions inside the router takes place here. The Control Plane, therefore, always needs to be one step
ahead of the Data Plane.
The two functions are usually divided among different hardware components within the system. On Alcatel-Lucent 7750
Service Routers, the hardware component that performs the control plane functions is called the Control Processor
Module, or CPM, and the component that performs the data packet processing and forwarding functions is called the Input
Output Module, or IOM.
When a routing protocol is enabled on the routers of a network, a series of actions is initiated. In this and the following
slides, the information exchange between a single router pair is briefly discussed. It is then easy to extend these principles
to any number of devices in the network.
First, with the more modern link state protocols (OSPF and IS-IS), an adjacency relationship is established between the
routers. If the two routers agree on the parameters, they exchange routing updates with each other to synchronize their
topology databases and build their Routing Information Base (RIB).
In this course, only the link-state protocols are considered (OSPF and IS-IS), since these are the only choices in todays
Service Provider Networks.
The SRC AIRP course examines the Interior Routing Protocols in much greater detail.
Module 1 Page 27
Building Tables: IP Control Plane
Based on their protocol metrics, the CPM chooses the best routes
from the RIB and writes them into the Route Table.
Module 1 | 28
Inside the RIB, various next-hop alternatives to certain destinations might exist, depending on the link and node
redundancy in the network. The responsibility of the router is to choose the best paths to all the given destinations. In
the case of link protocols, the Shortest Path First, or SPF, algorithm performs this function.
The SPF algorithm uses metrics to calculate the best path. In link-state protocols, metric is defined as a function of the
physical link bandwidth. The higher the bandwidth, the lower the metric, and the lower the cost of getting to
destinations via that link.
The router places the SPF chosen routes in the Route Table.
Module 1 Page 28
Building Tables: IP Control Plane
The routing information is transferred to the Data Plane (the Input

Output Modules) and is stored in the FIB (Forwarding Information
Base).
Module 1 | 29
The Route Table thus contains the best (lowest cost) paths to all possible destination prefixes. To be able to perform
data packet forwarding functions, this information needs to be transferred to all the data plane components. The
database that is maintained on the data plane for this purpose is called the FIB (Forwarding Information Base).
The FIB is virtually an image of the Route Table that is calculated from the entries in the RIB of the control plane. Since
the FIB exists on the data plane, it does not need the extra information related to the control plane. In this manner, we
can loosely think of it as a lightened version of the Route Table.
On Alcatel-Lucent 7750 Service Routers, identical copies of the routers FIB exists on every operational IOM. Dedicated
internal processes exist to keep these databases synchronized and up-to-date.
The command to display the route table entries on the 7750 SR is show router route-table.
The command to display the forwarding table entries on a certain IOM card that is installed in slot number <x> is show
router fib <x>.
Module 1 Page 29
Building Tables: IP Control Plane Data Plane Interaction
IP Forwarding takes place in the Data Plane using the information

available in the Forwarding Information Base.
Module 1 | 30
Once the Forwarding Information Base (FIB) is populated, it is used to forward native (unlabeled) IP packets on the
router.
(The detailed data packet forwarding process was explained on Pages 6 and 7.)
Module 1 Page 30
Building Tables: IP Data Forwarding
MPLS Protocols Exchange label bindings for their FECs and build the
LIB (Label Information Base).
Module 1 | 31
An IGP routing protocol in the network is a mandatory prerequisite to making the core network MPLS-capable. This
brings several additional capabilities and applications, the most important of which will be covered in the next section.
When an operator starts the MPLS label signaling protocol on the routers, the routers establish protocol sessions first.
The routing information present in the route tables allow the routers to create these sessions.
After sessions are established, routers exchange label bindings for FECs (destination IP prefixes) that are known to
them. The information that is sent and received is stored in a database that is called the Label Information Base, or LIB.
When this process is completed on the end-to-end path of an LSP (tunnel), label forwarding can take place.
The details of this process depend on the MPLS label signaling protocol that is used, which will be covered later in the
course.
Module 1 Page 31
Building Tables: MPLS Control Plane
Label Binding Information is transferred to the Data Plane and is

stored in the LFIB (Label Forwarding Information Base).
Module 1 | 32
Just as a FIB is required for native IP traffic, a Label Forwarding Information Base (LFIB) needs to be stored on the data
plane for forwarding label switched packets.
A selection process might be performed on the LIB when constructing the LFIB. Thus, the LIB might contain some
redundant entries, those are not actually used on the data plane (LFIB) at a given time. This depends on the actual
MPLS label distribution protocol implementation, either Label Distribution Protocol (LDP) or Resource Reservation
Protocol with Traffic Engineering extensions (RSVP-TE), the details of which are covered in their individual sections.
Module 1 Page 32
Building Tables: MPLS Control Plane Data Plane Interaction
A label is pushed onto the packet at the iLER and label swapping takes
place at the LSR, using the LFIB in the Data Plane.
Module 1 | 33
When an iLER receives a packet, it makes a decision to forward the packet via an MPLS tunnel (LSP). As indicated in the
previous slide, this depends on the definition of the service with which the ingress interface is associated.
If the iLER decides to use an MPLS tunnel to forward the packet, it will perform an FEC lookup in its LFIB. This process
will allow the packet to be encapsulated with a label and forwarded to the next-hop LSR.
For the sake of simplicity, a single label is being used to illustrate the basic concepts of MPLS label switching. In reality,
however, more than one label is often imposed onto the data packet, depending on the type of service or application.
This is called a label stack, which will be explained in Module 2.
The LSR then swaps the label with another, again consulting the LFIB stored locally on itself.
In some exceptional cases, the LSR might impose a further label onto the incoming stack in addition to the swap
operation. We will see an example of this in Module 6.
Module 1 Page 33
Building Tables: MPLS Data Forwarding on iLER and LSR
The label of the incoming packet from the LSR is popped at the eLER
using the LFIB in the Data Plane.
Module 1 | 34
The LSR processing is the same as explained in the previous slide.

The eLER is the last MPLS hop router, where the tunnel ends (terminates). This router pops the incoming label(s),
locates the outgoing interface, and forwards the original data packet outside the core MPLS network (towards the CE).
Module 1 Page 34
Building Tables: MPLS Data Forwarding on LSR and eLER
Section Summary
This section covered:

y Review of IP Routing mechanism
y Introduction to basic MPLS terminology (LER, LSR, LSP, FEC,
label)
y IP Control and Data Planes overview (RIB and FIB)
Module 1 | 35
y MPLS Control and Data Planes overview (LIB and LFIB)
Module 1 Page 35
Module Summary
MPLS allows optimum routing with Layer 3 awareness over any

Layer 2 medium, solving many issues of traditional IP forwarding.
MPLS label switching technology provides the ability to establish
connection-oriented paths over a connectionless IP network.
MPLS allows Service Providers to build highly reliable and scalable

core networks, and offer customers IP and differentiated services,
based on QoS and other features.
A Forwarding Equivalence Class (FEC) is a group of IP packets that
will be forwarded over the same path with the same forwarding
treatment.
Module 1 | 36
Module 1 Page 36
Module Summary (contd)
MPLS Traffic Engineering allows Service Providers to control and

optimize traffic flows in an MPLS domain, independent of the IP
routing tables.
RSVP-TE enables MPLS traffic-engineering for increased resiliency,
reliability, and performance.
The router at the beginning of an LSP is the ingress LER (iLER).

The router at the end of an LSP is the egress LER (eLER).
The MPLS control plane (CPM) exchanges routing information and
label bindings, and maintains the RIB, route-table, and LIB.
The MPLS data plane (IOM) stores the FIB and LFIB, and forwards
labeled or unlabeled packets, based on information contained in
these tables and the packets header.
Module 1 | 37
Module 1 Page 37
A Label Switched Path (LSP) defines an ingress to egress path

through a network that is followed by all packets assigned to a
specific FEC.
LSPs are unidirectional in nature.
The three label operations are PUSH, SWAP, and POP.
The label swapping mechanism requires packet classification at

the ingress of the network to assign an initial label to each packet.
The label swapping mechanism in an LSR replaces the incoming
label with the outgoing label, and directs the packet to the
outbound port for transmission to the LSP next-hop address.
The egress LER will remove MPLS labels from the packet and
forward unlabeled IP packets outside the MPLS domain.
Module 1 | 38
Module 1 Page 38
Four tables are maintained by routers in an MPLS network

Routing Information Base (RIB)
Forwarding Information Base (FIB)
Label Information Base (LIB)
Label Forwarding Information Base (LFIB)
Module 1 | 39
MPLS allows network operators to design a network that

Avoids bottlenecks with TE LSPs
Recovers quickly from outages with secondary paths and fast
reroute
Supports L2 and L3 consumer and business services, including
mobile and triple play service architectures
Transparently tunnels BGP routed traffic through a BGP-free
core
Module 1 Page 39
Learning Assessment
1. The router at the beginning of an LSP is the ________.

2. A router in the MPLS domain that resides between the ingress and
egress routers is called a(n) _______ .
3. The router at the end of an LSP is the_____________________.
5. Define an MPLS Forwarding Equivalence Class (FEC).

6. What information is contained in the LFIB?
7. An iLER and an eLER perform what forwarding operations on a
packet?
Module 1 | 40
1. The router at the beginning of an LSP is the ingress Label Edge Router (iLER).
2. A router in the MPLS domain that resides between the ingress and egress routers is called a Label Switch Router
(LSR).
3. The router at the end of an LSP is the egress Label Edge Router (eLER).
4. Define the three MPLS label operations.
PUSH An MPLS header is inserted into an IP packet
SWAP An existing MPLS header is exchanged for a new MPLS header
POP An MPLS header is removed from an IP packet
5. Define an MPLS Forwarding Equivalence Class (FEC).
An MPLS FEC is a group of packets forwarded in the same manner, over the same path, and with the same
forwarding treatment.
6. What information is contained in the LFIB?
The active labels matching the best path to the destination FEC.
7. An iLER and an eLER perform what forwarding operations on a packet?
Switching and routing switching a labelled packet and routing an unlabeled packet.
Module 1 Page 40
4. Define the three MPLS label operations.
www.alcatel-lucent.com

Switching
Module 2 Page 1
Module Objectives

to:
Explain the data plane implications of MPLS.
Describe the management plane functions that are available to
MPLS.
Module 2 |

To locate additional information related to the topics presented in this manual, refer to the following:
Module 2 introduces the concepts related to forwarding of MPLS packets in the data plane. The MPLS label stack, its
application in VPN services, and the fields inside the MPLS label header are all explained.
In the second part of the module, the general control plane principles of MPLS dynamic signaling protocols are
explained. Label distribution and control and retention modes are examined from a generic perspective. The actual
operation of these modes depends on the protocol implementation, which will be investigated in the later LDP and
RSVP-TE modules.
Labels that are reserved for special uses, such as implicit and explicit null and router alert label, are explained at the
end of the module.
Module 2 Page 2
Explain the control plane implications of MPLS.
Section 1 Understanding the Data Plane Implications of MPLS
Module 2 Page 3
Section Objectives

Explain the MPLS Label Stack Operation.
Explain pipe vs. uniform mode operation with respect to TTL, EXP,
and the impact to a label stack.
Explain frame vs. cell mode label implementation.
Module 2 |
This section explains the key elements related to forwarding of MPLS data packets.
MPLS label stacking is explained first, along with the justification for the need of a stack in the example of VPN
services.
Then, several fields inside the MPLS header (label value, Experimental, Bottom of Stack and Time to Live) are
introduced.
The actual use of these fields, as influenced by the mode of implementation (pipe vs. uniform mode), is explained in
step-by-step detail.
The Alcatel-Lucent (ALU) SR OS mode of implementation for processing these fields is also considered.
Finally, the two encoding options for the MPLS label are explained, frame mode v. cell mode, together with ALU SR OS
implemented frame mode of operation.
Module 2 Page 4
Explain the MPLS Label structure in detail (label values, EXP, S,

TTL fields).
In Frame Mode, the MPLS Label is inserted between OSI Layer 2

and the encapsulated data (Payload).
Module 2 |
MPLS headers are inserted between the Layer 2 of the network interface and the encapsulated MPLS Payload.
As explained in the previous module, MPLS initially transported IP packets to their destination FEC with label
encapsulation, providing higher network performance. As such, MPLS is also often known as a Layer 2.5 protocol, since
the label is inserted as a shim between the Layer 2 and Layer 3 headers.
Today, MPLS also supports VPN services as well as IGP and BGP tunnels, extending its use. An MPLS Payload can consists
of a variety of protocols and services, so in this course we generically label the green payload field as Data.
A label stack can be formed by encapsulating labels with other labels, each layer providing a specific function on the
network. For example, the router places a service label on the customers payload to identify the VPN to which it
belongs. Then, to move this labeled payload through the MPLS domain, the same router adds to the stack top a
transport label. If the operator runs Fast Reroute, discussed in Module 6, a router may add a bypass tunnel label to the
stack. The SR OS supports up to six stacked labels.
Stacked labels support a wide range of MPLS-based services, including VPLS, VPRN, MPLS Fast-Reroute, trace, ping, or
Traffic Engineering applications.
Technically, a packet can have any number of labels in it, depending on the number of applications being used. The
maximum number of labels that can be carried is governed by the physical interfaces maximum packet size as well as
the routers implementation of the MPLS protocols.
Module 2 Page 5
MPLS (Frame Mode) Label Stack Implementation
The MPLS Transport (Outer) tunnel can encapsulate multiple

Service (Inner) tunnels.
Module 2 |
The service provider IP/MPLS network supports all customer services - including scalable and standards based VPN
solutions - over a consolidated, shared backbone.
The above figure shows the logical service construct for simple point-to-point connectivity services. In this model, only
the edge (PE) routers are service aware. For each VPN customer, service instances are configured on all the
participating PE routers.
A service instance is a virtual software entity in the service router. Different service instances provide isolation
between different customers, which provides inherent security and the ability to apply local, customized settings for
each customer. Different logical service instances also allow for a very granular and scalable allocation of resources
across different customers.
Referring again to the figure above, the separate logical service tunnels connect the service instances that belong to
the same customer on both PE routers.
The MPLS transport tunnel (depicted in red) can multiplex and transport several service tunnels. The intermediate (P)
routers are only aware of the transport tunnel. The transport tunnel encapsulates (hides) the service tunnels from the P
routers. Because the P routers have no visibility over the services instances or the service tunnels connecting these
instances, they need only look at the outermost label to make their forwarding decisions. This improves both network
performance and scalability.
A more detailed discussion on the Alcatel-Lucent service model offered in the SRC ASA (Alcatel-Lucent Service
Architecture) course. The important point to understand here is the concept of tunneling and label stacking.
Module 2 Page 6
The Need for a Label Stack for VPN Services
Module 2 |
This diagram assumes that the routers have already signaled the tunnels and their associated label values prior to the
arrival of data traffic at the iLER. We discuss these MPLS control plane fundamentals in the next module.
Looking at the left side of the figure above, the ingress PE (router R1) processes each customers data traffic into a
dedicated service. From there, router R1 delivers the data into their corresponding service tunnels. Router R1 pushes a
separate, previously signaled service label on top of each packet. Router R1 pushes onto the appropriate data packets
service label S1 for Customer A and service label S2 for Customer B.
The same edge-to-edge transport tunnel forwards the labeled packets to the core. Router R1 pushes transport label T1
onto the label stack and sends the twice-labeled packet towards router R2.
As an LSR, router R2 processes only the top label in the stack. Router R2 swaps transport label T1 with transport label
T2 and sends the packet on to router R3. Router R2 leaves the remaining parts of the packet, service label X and the
encapsulated customer data, untouched.
When the egress PE router R3 receives the packet, it processes the transport label T2 first, popping it from the top of
the stack.
Router R3 needs the second label so that it can select the appropriate service instance to which it will send the data
packet. Since router R3 forwarded the service label S1 to router R1, router R3 knows the data belongs to Service 1 and
Customer A. Similarly, if the router R3 receives the packet with a service label S2, the data belongs to Customer Bs
Service 2.
Module 2 Page 7
MPLS Label Stack Operation for VPN Services
Customer Layer 2 Header is preserved at iLER.
Module 2 |
Layer 2 and Layer 3 VPN services treat customer packets differently.

The two main Layer 2 VPN services are Virtual Private Wire Services (VPWS) and Virtual Private LAN Services (VPLS). As
Layer 2 services, they are transparent to the customer. The service forwards the entire customer-generated L2 payload
transparently between the two CE devices.
For example, assume Ethernet data link connections between all routers:
(*) The CE1 Layer 2 header uses CE1s source MAC address and CE2s destination MAC address. Router R1 (**), the ingress
LER, encapsulates the entire frame within two MPLS labels, an MPLS transport label and a service label, and an Ethernet
frame header. The frames source MAC address is that of router R1s egress interface and the destination MAC address is
that of router R2s ingress interface. The top label (transport) tunnels the customers traffic hop by hop from the
ingress to the egress LER, while the bottom label (service) identifies the edge to edge service to which the payload
belongs.
The egress LER extracts the customers payload from the service providers headers, and forwards the original Layer 2
frame to CE2. CE2 accepts this packet, since its own L2 MAC address is the destination.
Module 2 Page 8
MPLS Encapsulation for Layer 2 VPN Services
Customer Layer 2 Header is removed at iLER.

A new Layer 2 Header is built by eLER.
Module 2 |
The Layer 3 (IP) VPN service solution is Virtual Private Routed Network (VPRN).
In this model, the service instances maintain isolated routing tables and decide on a per service basis how to forward
the packets to their destinations. The PE routers form peer relationships with the CE routers inside the respective
service instances.
Again, assuming Ethernet data link connections between all routers:
(*) The Layer 2 header sent from CE1 to router R1 has a source MAC address of the CE1, and a destination MAC address
of the PE1 service interface. From the customers perspective, PE1 is the next-hop to the destination network, CE2.
Router R1, the ingress PE router, removes the Layer 2 header, processes the IP packet, and forwards only the IP header
and payload, encapsulated within two MPLS headers.
(**) Router R1 encapsulates the MPLS packet with the egress service provider interface Layer 2 header. The source MAC
address is that of router R1 and the destination MAC address is that of router R2.
(***) The egress LER (router R3) removes the service headers and processes the packet as any IP packet, finding a route
in the services IGP routing table, building a new Layer 2 header and forwarding the packet to CE2. The source MAC
address is that of the service interface on router R3 and the destination MAC is that of the CE2 interface.
Module 2 Page 9
MPLS Encapsulation for Layer 3 (IP) VPN Services
MPLS Label Header
Name
Size (bits)
Purpose
Label
MPLS Label
20
The MPLS label Value
EXP*
Experimental
QoS mapping from TOS/COS bits
Bottom of Stack
Flag to indicate bottom of MPLS stack
TTL
Time to Live
Packet lifetime in MPLS hops
Each MPLS header is fixed 4 bytes in size

* RFC 5462 renames the EXP field to Traffic Class
Module 2 |
10
Each MPLS header in the MPLS stack includes the following four fields:
Label (20 bits): The most significant 20 bits in the MPLS header is the label, which contains the value information.
Labels can be given values ranging from 0 to 1,048,575. The next slide shows the allocation of this large range into
different pools that are used for various purposes or applications.
EXP (3 bits): The next 3 bits are experimental bits. They are called this because when the MPLS protocol was first
introduced as a standard, there was no clear view on how they would be used. These bits are now used solely for
Quality of Service marking in all the implementations. RFC 5462 renames this filed as Traffic Class. Module 5 discusses
this fields use.
Abstract from RFC 5462: EXP Field Renamed to Traffic Class Field
The early Multiprotocol Label Switching (MPLS) documents defined the form of the MPLS label stack entry. This
includes a three-bit field called the EXP field. The exact use of this field was not defined by these documents, except
to state that it was to be reserved for experimental use.
Although the intended use of the EXP field was as a Class of Service (CoS) field, it was not named a CoS field by
these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a
number of standards documents define its usage as a CoS field.
To avoid misunderstanding about how this field may be used, it has become increasingly necessary to rename this
field. This document changes the name of the field to the Traffic Class field (TC field). In doing so, it also updates
documents that define the current use of the EXP field.
S (1bit): The S bit indicates the bottom of stack. In a stack of multiple labels, the label at the bottom of the stack has
an S bit value of 1, while all others are set to 0.
TTL (3 bits): The Time To Live (TTL) field inside the MPLS header functions like the TLL field inside the IP header. The
TTL value is decremented at each LSR hop to prevent packets from getting stuck in infinite forwarding loops. In the
event of such a loop, the TTL value eventually runs down to 0 and the packet is discarded.
Module 2 Page 10
Field
MPLS Label Range Allocation on Alcatel-Lucent SR OS
MPLS Label Field is 20 bits.

Possible values: 0 1,048,575
Label Usage
0-15
Reserved (Special Use) Labels
16 31
Reserved for future use
32 1, 023
Reserved for static LSPs
1, 024 2, 047
2, 048 18, 431
Statically assigned for services
18, 432 - 32, 767
32, 768 131, 071
Dynamically assigned by MPLS protocols
131, 072 1, 048, 575
MPLS Label Ranges are not configurable.

Module 2 |
11
20 bits are allocated for the Label Value in the MPLS Header.
The decimal value range that can be achieved with 20 bits is from 0 to 1,048,575. This entire range is further divided
into several sub-ranges on service routers, as shown in the above slide.
The label ranges are fixed in the SR OS code, and are not configurable.
Note the label values between 0 and 15. RFC 3032 reserves this range for special applications.
A basic overview of the MPLS control plane processes is needed to better understand the use of these labels; as such, it
will be covered at the end of the next section.
Module 2 Page 11
Label Values
MPLS Header: EXP Field
MPLS Experimental (EXP) Field consists of 3 bits.

Used solely to convey QoS (Quality of Service) information.
Only the EXP field inside the top label is significant in processing.
There are two approaches to EXP Handling:
y Pipe Mode
y Uniform Mode
The Alcatel-Lucent SR OS only implements Pipe Mode.
Module 2 |
12
The MPLS Experimental bits are used to carry the Class of Service information of the transported data traffic over the
path of an LSP. This information, inside the label header, allows LSRs to apply different Quality of Service treatments
to various types of MPLS encapsulated traffic (a full discussion of Quality of Service principles and techniques is part of
the SRC QoS (Quality of Service) course).
In the following slides, we will examine the processing of the EXP field based on the mode of implementation defined in
the standard.
Module 2 Page 12
RFC 5462 renamed to Traffic Class Field (February 2009).
At iLER, the EXP fields of all MPLS labels are set to the same value,
using administrative configuration.
The DSCP value inside the customer packet header is preserved.
Module 2 |
13
Pipe mode is implemented in the service routers for the processing of Experimental bits.
The customer router may mark the Differentiated Services Code Point (DSCP) field of the IP header to indicate the class
of service for the type of traffic it is sending. The ingress LER router may use this information to do the initial
classification and prioritization of the customer packet, but this value has no influence in determining the EXP field of
the tunnel header(s).
The EXP fields inside the MPLS tunnel headers are set to a specific value (X) via explicit administrative configuration.
Remember that only the top (transport) header is significant for processing at the LSR. Nonetheless, in the service
router implementation, all the tunnel headers are set to the same EXP value. This is mainly to support certain intervendor compatibility scenarios, including a special feature called Penultimate Hop Popping, which is covered at the end
of the next section.
By default, the EXP settings are not altered by the LSRs, and this is usually the desired behavior to maintain a
consistent end-to-end QoS implementation. However, if there is a requirement to change the EXP markings on an LSR,
the service router also has the necessary configuration tools to do so.
Again by default, the DSCP value inside the customer packet is preserved.
For the sake of simplicity, we assume an IP forwarded datagram here (typically for a Layer 3 service), but the same
principles hold true also for Layer 2 services.
Module 2 Page 13
MPLS Header: EXP Field Pipe Mode (SR OS Implementation)
At iLER, the first 3 bits of the DSCP field inside the customer packet
are copied to the EXP field of MPLS header.
The DSCP value inside the customer packet is preserved.
Module 2 |
14
The above figure provides a step-by-step summary of EXP processing across an LSP in uniform mode implementation.
It is important to note that the service router implementation only supports the pipe mode and, at the time of this
publication, no other configuration option exists to make it operate.
Again for simplicity, we consider IP forwarding and only one MPLS label is shown. In principle, however, more can
certainly exist in the label stack. What happens to the EXP fields of those other labels would vary from vendor to
vendor.
In the uniform mode implementation, the ingress LER automatically copies the first three most significant bits of the
DSCP field inside the customer IP header onto the EXP field of the outgoing MPLS packet.
At the egress LER, the EXP bits may or may not be copied back into the DSCP field of the customer packet; it depends
on the vendors and their specific implementation or configuration. Usually, however, this value would be untouched.
Module 2 Page 14
MPLS Header: EXP Field Uniform Mode (non-SR OS behavior)
The S bit indicates the bottom of the MPLS stack.
Module 2 |
15
A packet might contain various MPLS label headers, forming a label stack.
The S (bottom of stack) bit is only one bit in length and set to 1 at the bottom header to indicate the end of the stack.
This bottom header resides closest to the customer payload; the remaining headers, with the stack bit set to 0, serve to
transport the payload to the tail end PE routers.
Module 2 Page 15
MPLS Header Bottom of Stack (S) Bit
MPLS Header Time to Live (TTL) Field
The 8-bit MPLS Time to Live (TTL) Field functions similarly to the IP
TTL field.
A packet with a TTL of 0 is not transmitted to the next-hop.
In most cases, only the TTL field inside the top label is significant
in processing.
There are two approaches to MPLS TLL Handling:
y Pipe Mode
y Uniform Mode
The Alcatel-Lucent SR OS only implements Pipe Mode.
Module 2 |
16
Time To Live (TTL) is a well known loop avoidance mechanism in IP forwarding.

The 8 bit MPLS header TTL field is used similarly as is the IP header TTL field, which is decremented by 1 at each IP
hop. If the TTL value drops to 0, the packet is discarded and is not transmitted to the next-hop.
Label processing is always based on the outer label in the stack, which provides information about the operations to
perform on the packet's label stack, including modifications to the MPLS TTL header field.
RFC 3443 defines Time To Live processing in MPLS Networks. It defines TTL handling for two approaches to MPLS LSPs:
Uniform mode and Pipe mode.
Uniform mode The MPLS network is visible from the outside, thus MPLS nodes handle TTL as any other IP node. The
iLER decrements and maps the IP TTL to the MPLS TTL, decrements the MPLS TTL at each LSR, and then maps the final
MPLS TTL to the IP header TTL on egress.
Pipe mode The MPLS network is invisible from the outside, in the sense that the network appears a single pipe
between the ingress and egress LER. TTL handling in the MPLS network is independent of the IP TTL. The IP TTL is
decremented by the ingress LER and the egress LER, but not by any intermediate LSRs.
The Alcatel-Lucent SR OS for implements pipe mode for VPN services. There are slight differences in the way it is
implemented for Layer 2 and Layer 3 VPN services, which will be explained in the next slides.
Module 2 Page 16
It is used as a protection mechanism against forwarding loops.
The IP TTL in the customer packet is kept intact.

The MPLS TTL inside the top label is decremented at each LSR.
Module 2 |
17
The figure above explains the end-to-end processing of the TTL headers inside the MPLS and IP headers.
At the ingress LER, the IP TTL of the customer packet is untouched because this is a Layer 2 service and no processing is
done on the IP header. The customer frame is encapsulated within 2 labels: the Transport and the Service labels.
The ingress LER sets the TTL field of both MPLS labels is set to 255 by default.
Recall that only the transport label is significant for processing at the LSR. Nonetheless, the service label is also given a
TTL value. This is mainly to support certain inter-vendor compatibility scenarios, including a special feature called
Penultimate Hop Popping. This feature is covered at the end of the next section.
While performing the swap operation on the transport label, router R2 decrements the TTL of only the top label by 1.
All other TTL values remain intact, as they are transparent to the LSR.
Again, the ingress LER does not touch the TTL of the customer packet because no processing is done on the IP header
for a Layer 2 service.
Module 2 Page 17
TTL Processing for Layer 2 VPN Services in Pipe Mode
The IP TTL in the customer packet is decremented by 1 at iLER and

eLER.
Module 2 |
18
Unlike the previous scenario, on the above slide, the ingress LER decrements the TTL of the incoming customer packet
by 1. This is because the packet belongs to a Layer 3 service, and the router processes the IP header.
At ingress LER, the TTL of the transport label is set to 255. The TTL of the service label, however, is set to the
decremented IP TTL of the customer packet (in this case, 4).
All other TTL values remain intact since they are transparent to the LSR.
The egress LER (router R3) also decrements the IP TTL of the customer packet by 1 before sending it to CE2.
Module 2 Page 18
TTL Processing for Layer 3 (IP) VPN Services in Pipe Mode
The (decremented) IP TTL in the customer packet is copied onto

the MPLS TTL at iLER.
The MPLS TTL is copied onto the IP TTL in the customer packet at
eLER.
Module 2 |
19
The SR OS only supports pipe mode for TTL processing in VPN services. At the time of this publication, the router cannot
operate in uniform mode.
Again for the sake of simplicity, we only consider IP packet forwarding and only one MPLS label is shown. In principle,
however, more labels can exist in the label stack. What happens to the TTL fields of those other labels would vary from
vendor to vendor and depend their specific modes of configuration.
In uniform mode, the ingress LER decrements the IP TTL of the customer packet by 1 and also copies this value to the
MPLS header (4).
All other TTL values remain intact because they are transparent to the LSR.
The egress LER (router R3) copies the TTL of the MPLS header to the TTL of the IP header inside the customer packet
before sending it to CE2.
Module 2 Page 19
TTL Processing in Uniform Mode (non-SR OS behavior)
Only Frame Mode is implemented on the Alcatel-Lucent SR OS.

The MPLS header in Frame Mode is also called a Shim header.
In Cell Mode, MPLS label information may be carried in ATM VPI/VCI
or Frame Relay DLCI fields.
Module 2 |
20
The above slide illustrates the two types of MPLS label implementations.
The MPLS label values may be carried in an MPLS specific Shim header or in a technology specific Layer 2 header, as is
the case in ATM or Frame Relay. With ATM, the VPI/VCI field in the cell header is used as the MPLS label. With Frame
Relay, the DLCI is used.
The MPLS encoding technique of implementing a label in the existing Layer 2 header is sometimes referred to as cell
mode MPLS, and is not supported by Alcatel-Lucent Service Routers.
Module 2 Page 20
MPLS Frame Mode vs. Cell Mode Implementation.
Section Summary

y Introduction to the MPLS Label Stacking mechanism.
Label Value
EXP Field
S (Bottom of Stack) Field
TTL Field
y Processing of EXP and TTL fields in pipe and uniform modes.

y MPLS Frame Mode vs. Cell Mode Implementation.
Module 2 |
21
MPLS headers can be imposed on each other, forming a label stack.

VPN services use two tunnels, namely the transport and service tunnels.
The transport tunnel identifies the destination PE router and can encapsulate various service tunnels.
The service tunnels carry the traffic of an individual customer inside the transport tunnel.
The label values range between 0-1,048,575; this range is further divided into several segments.
The Experimental bits are used to carry Quality of Service information. Alcatel-Lucent Service Routers support the
pipe mode of EXP implementation.
The Bottom of Stack bit indicates the bottom of the label stack when set to 1.
The TTL field is used to discard packets in case they are caught in forwarding loops. Alcatel-Lucent Service Routers
support the pipe mode of TTL implementation for VPN services.
Labels are encoded using the MPLS Frame mode on Alcatel-Lucent Service Routers. Cell mode is not supported.
Module 2 Page 21
y Explanation of MPLS Header fields:
Section 2 Understanding the control plane implications of MPLS
Module 2 Page 22
Section Objectives

Explain the requirement for IGP and label distribution protocols.
Discuss the various label distribution and control and retention
modes.
Introduce the various MPLS signaling protocols.
Explain the use of MPLS reserved labels (0-15).
Explain the Alcatel-Lucent Service Router support for the various
presented modes and features.
Module 2 |
23
In this section, we will take a behind the scenes look at MPLS operations, which includes the control plane processes
that run continuously in the background to keep the network operational and optimized.
The section starts by introducing the requirement for control plane processes, namely the routing and label signaling
protocols enabled on the routers.
To understand the various implementation options offered to protocol and equipment vendors by the MPLS RFC 3031,
we will discuss the following modes:
Label Distribution: Downstream Unsolicited and Downstream On Demand
Label Control: Ordered and Independent
Label Retention: Conservative and Liberal
The concepts are explained from a generic point of view as far as possible because the actual details of implementation
might differ from one protocol to the next.
The following modules are dedicated to the exact mechanisms, based on each MPLS signaling protocol, LDP, and RSVPTE covered in this course.
Finally, the control and data plane perspectives of using MPLS reserved labels in the range of 0 -15 will be explained at
the end of the section.
Module 2 Page 23
Introduce the various label space implementation modes.
For tunnels to be established:

y Routers must know about each others FECs.
y Label bindings for FECs must be negotiated between the routers.
Module 2 |
24
An FEC basically corresponds to an IP prefix.

For proper MPLS operation, the routers must be aware of each other and learn the location of every routers FECs. This
task is accomplished when all routers run a scalable and optimized routing protocol, such as OSPF or ISIS.
The next step is to deploy a certain mechanism to exchange label bindings for certain selected FECs between the
routers. Dedicated MPLS protocols have been implemented to serve this purpose, and will be introduced later in the
section.
Module 2 Page 24
Requirement for IP/MPLS Control Processes
IGP is responsible for distributing and maintaining network reachability

information; that is, the IGP FECs.
Module 2 |
25
Routing protocols are also called Interior Gateway Protocols (IGP).

Interior Gateway Protocols are covered in detail in the SRC AIRP course. Here, only a very brief overview is given to
explain the related MPLS principles.
After the adjacencies are established between the routers, they exchange routing information and populate their IP
Forwarding Tables.
In the above example, each router holds an FEC, which is basically an IP prefix, that shows up as a local entry in the
forwarding table.
After all the databases are synchronized, or when IGP is converged, the routers have the FECs present on other routers
indicated as remote entries in the forwarding tables.
At this point, only IP forwarding takes place, using the information in the IP Forwarding Tables.
NOTE: As a more advanced topic, MPLS Traffic Engineering will be discussed later in this course. To be able to support
most of the features covered in this context, a routing protocol is required in the network that can carry extended
information in its updates. This will be covered in greater detail in Module 5.
Module 2 Page 25
Requirement for an Interior Gateway Protocol
The FECs IP prefixes are exchanged and the other routers tunnel
destinations are known, thanks to IGP.
A signaling protocol is needed to negotiate the MPLS labels and
establish the tunnels.
Module 2 |
26
The Interior Gateway (Routing) Protocol is responsible for distributing the reachability information throughout the
network and ensuring that paths are re-optimized after certain network failure events.
To be able to establish the MPLS LSPs in the network and enable label forwarding of packets, a common protocol needs
to be enabled on all participating routers.
This protocol will define the set of rules and procedures for how the routers exchange the labels and agree on their
meanings.
At this point, RFC 3031 that sets the ground rules for the MPLS Architecture (in capital letters):
THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE LABEL DISTRIBUTION PROTOCOL.
A number of protocols have been standardized for this purpose.
In the following pages, we will discuss some of the main design principles that a label distribution (signaling) protocol
must meet.
Module 2 Page 26
Requirement for MPLS Signaling Protocols
Direction of the Data Traffic Flow provides the reference points.

The router that is closer to the source is called Upstream.
The router that is closer to the destination is called Downstream.
Module 2 |
27
Before going further to explain the control plane perspective of MPLS Label signaling protocols, we will describe two
terms that will be used in several upcoming discussions: Upstream and Downstream.
As with many other concepts in MPLS, the definition of these terms depends on the direction of the data traffic flow
under consideration. Throughout this course, the assumed data traffic flow is left to right (in almost any case, traffic
flows both ways; but, for the sake of simplicity, only one direction is taken into account here).
Therefore, the customer router on the left becomes the source and the router on the right becomes the destination of
data traffic.
Hence, the definition of an upstream router is a router that is closer to the source of a data packet, relative to another
router. Hence, router R1 is an upstream router for router R2, and router R2 is an upstream router for router R3.
The definition of a downstream router is a router that is farther from the source, or closer to the destination, of a data
packet, relative to another router. Thus, router R2 is a downstream router for router R1, and router R3 is a downstream
router for router R2.
Data traffic flows in the downstream direction, from an upstream router to a downstream router.
Control plane processes reverse this order, as we will explain the in the following slides.
Module 2 Page 27
Upstream and Downstream Reference
Label Distribution Modes
RFC 3031 does not assume the use of a single signaling protocol
and offers various implementation alternatives that control label
distribution and maintenance.
y Downstream on Demand
Module 2 |
28
If MPLS forwarding wants to be used in the network, the routers must first generate and advertise label bindings for
their selected FECs. This populates the label forwarding tables and defines the paths of Label Switched Paths in a
consistent manner. A common dynamic MPLS signaling protocol is enabled on all participating routers for this purpose.
However, RFC 3031, which defines the Multiprotocol Label Switching Architecture, does not assume the use of a single
signaling protocol. In addition, various implementation alternatives are offered in the RFC that describe the ways to
distribute and retain FEC label bindings.
Therefore, IP/MPLS router vendors must comply to the principles dictated in this RFC when implementing one or more
of the standardized protocols into their equipment.
Network operators, in turn, need to know the intrinsic characteristics of all implementations in order to decide which
to deploy in their network. This knowledge might become more valuable when operating in a multi-vendor environment,
where different vendors might use different implementation modes for the same protocol.
In the following pages, the distribution and control and retention modes are explained from a general perspective.
The actual details of MPLS signaling protocols in the Alcatel-Lucent Service Router portfolio will be covered in greater
detail in later modules.
Module 2 Page 28
The two modes that define the process to distribute label bindings
for FECs in an MPLS enabled network are:
y Downstream Unsolicited
Module 2 |
29
For simplicity, only router R3 is used to explain the different label distribution mechanisms. Here, router R3 is the
downstream router for FEC Z, which is a local IP prefix on R3. To put it in another way, router R3 is the egress for data
traffic that is destined to FEC Z.
The two label distribution methods can be described as follows:
Downstream Unsolicited (DU) mode - a router operates distributes a label binding to its MPLS neighbors without
first being asked. In other words, if the router decides to advertise a label binding for a particular FEC, it does so
regardless of whether any other router needs that label or not.
Downstream on Demand (DoD) mode - a router operates distributes a label binding to another router only if that
router explicitly requests it.
Module 2 Page 29
Downstream Unsolicited vs. Downstream on Demand Distribution
Router R3 advertises a label binding for its FEC Z and this is

propagated to all the upstream routers.
Module 2 |
30
Router R3 is operating in Downstream Unsolicited Mode. It has also formed a peering relationship with router R2, using a
common label distribution protocol.
Router R3 decides to advertise a label binding for its FEC, Z. It generates a binding with a label value of 100 and
allocates this locally in its label binding table, inside the memory.
Router R3 advertises this label binding right away, without waiting for an explicit request from its neighbors.
Router R2 receives the label binding from router R3 and records it. Notice that the control plane operates in opposite
direction to the data plane. This means that, in the data plane, router R2 now knows that it needs to send MPLS packets
with a label of 100 to router R3, for FEC Z.
Router R2 notices that it also has an upstream neighbor (router R1), which means that router R2 can also be an LSR for
data packets coming from router R1. For this purpose, it generates a local binding with a label of 200, allocates it in
the table, and advertises it to router R1.
Router R2 now has another label action: besides pushing labels onto unlabeled packets originating on R2 and targeting
FEC Z, router R2 swaps label 200 with label 100 when transporting labeled packets from R1 to FEC Z.
Finally, router R1 receives the label binding from router R2 and chooses the label action: to push data packets with a
label of 200 and send them to router R2.
NOTE: Downstream Unsolicited mode is used by the LDP protocol; its actual implementation will be explained in more
detail in Module 3.
Module 2 Page 30
Downstream Unsolicited Label Distribution
Router R1 makes an explicit request for a label binding for FEC Z.

The request is forwarded down to router R3, the owner of the FEC.
Module 2 |
31
Router R3 is in Downstream on Demand mode, so it has not yet generated a label binding for its FEC Z.
Router R1 decides that it needs a label binding for FEC Z, since it needs to establish a tunnel going in that direction.
Router R1 sends a label request message to its downstream neighbor, router R2, which then delivers this to router R3,
the owner of the FEC.
It is now up to router R3 to respond to this request.
Module 2 Page 31
Downstream on Demand Label Distribution Request
Router R3 responds to the request from router R1 by advertising a

label binding to router R2.
Router R2 also generates its own label binding and advertises it to
router R1.
Module 2 |
32
Router R3 receives a request from router R1 to advertise a label binding for its FEC Z.
(From this point, the process closely resembles the steps for Downstream Unsolicited Mode.)
Router R3 generates a label binding and advertises it to router R2, which then forwards this to router R1, the requester
of the label binding.
Once router R1 receives the label binding, all downstream routers along the LSP path also have their labels in place. At
this point, the LSP (tunnel) is established (shown on the next slide).
NOTE: Downstream on Demand mode is used by the RSVP-TE protocol; its actual implementation will be further
examined in Module 4.
Module 2 Page 32
Downstream on Demand Label Distribution - Response
Label Forwarding Information Base (LFIB) tables are populated and the
LSP gets established.
Module 2 |
33
As a result of the label binding advertised from the egress router R3, and forwarded by router R2, the label connection
is now complete and the LSP is established from router R1 towards the direction of router R3. The routers build a Label
Forwarding Information Base (LFIB) containing the labels associated with the best IGP or constrained path to the
destination.
Data forwarding can now take place with the negotiated labels.
Module 2 Page 33
Result of Label Distribution for both modes (Data Forwarding)
Label Distribution Control Modes
The two modes that define the order in which nodes create and
advertise FEC label bindings in an MPLS enabled network are:
Module 2 |
34
RFC 3031 specifies two label distribution modes, Ordered Control and Independent Control, that define the label
binding advertisement order of operation for LSP setup.
When a router operates in Ordered Control label distribution mode, it only distributes a label for a FEC for which it is
the egress LER for that FEC or it has already received from its next-hop a label binding for that FEC.
When a router operates in Independent Control label distribution mode, it distributes labels for its known FECs to its
upstream routers, regardless of whether is has received a label from the downstream routers that actually own the
FECs. This corresponds to the way that conventional IP datagram routing works; each node makes an independent
decision with regards to how to treat each packet, and relies on the routing algorithm to converge rapidly so that each
datagram can be correctly delivered.
To ensure that traffic in an FEC follows a path with a specified set of properties (for example, that the traffic does not
traverse any node twice, or that a specified amount of resources are available to the traffic), Ordered Control must be
used. With Independent Control, LSRs may begin label switching traffic in the FEC before the LSP is completely set up,
which can cause traffic in the FEC to follow a path that does not have the specified set of properties.
Therefore, Ordered Control label distribution mode is used for both transport protocols LDP and RSVP-TE on AlcatelLucent Service Routers. However, it should be noted that Ordered Control and Independent Control modes are fully
interoperable.
Module 2 Page 34
Ordered Control
Independent Control
Module 2 |
35
In the above example, router R2 already has an entry for FEC Z in its IP Forwarding Table, with a next-hop of router R3.
If router R2 is operating in Ordered Control mode, it will wait for its downstream neighbor, router R3, to advertise a
label for FEC Z first. When it receives the label binding from router R3, router R2 will further advertise it to its
upstream neighbor, router R1. This ensures a loop-free network where routers only advertise labels for FECs associated
with valid routes.
If router R2 is operating in Independent Control mode, it will not wait for router R3 to advertise the label binding; it
will make an independent decision to advertise a label binding for FEC Z to its upstream neighbor, router R1. This
speeds MPLS convergence but risks loops in the instance where the advertising router does not have a valid route to the
destination FEC.
Module 2 Page 35
Ordered Control vs. Independent Control
Label Retention Modes
Module 2 |
36
RFC 3031 specifies two retention modes, Liberal and Conservative, that define methods of retaining the label bindings
received from downstream neighbors.
In Liberal label retention mode, a router stores all the labels it receives from other routers in the LIB.
In Conservative label retention mode, a router validates the labels received from other routers and only stores the
valid labels in its label database.
Module 2 Page 36
The two modes that define the way routers maintain the received
label bindings in their tables are:
y Conservative
y Liberal
Module 2 |
37
In the above example, router R1 has received a label binding for FEC Z but has decided that it does not need the label
nor the tunnel to router R3.
The two scenarios illustrated summarize how router R1 will react in either of the retention mode implementations.
There are various reasons for choosing an implementation, which depend on the protocol and scenario being
considered. In general:
Liberal label retention mode allows for quicker adaptation to routing changes, but consumes more memory
resources
Conservative label retention mode requires an LSR to maintain fewer labels, making it less resource intensive but
possibly slower to react to routing changes.
NOTE: LDP uses liberal retention and is covered in Module 3. RSVP-TE uses conservative retention and is covered in
Module 4.
Module 2 Page 37
Conservative Retention vs. Liberal Retention Mode
Label Distribution and Retention Summary
Most implementations use one of the following combinations:

Conservative Label Retention with Downstream On Demand
Liberal Label Retention with Downstream Unsolicited
Other combinations of label signaling and retention are possible but
not used.
Protocol
Distribution Mode
Control Mode
LDP
Downstream Unsolicited
Ordered
RSVP
Downstream on Demand
Ordered
Module 2 |
38
Retention Mode
Liberal
Conservative
The matrix shown above summarizes the combinations of MPLS label signaling modes and label retention modes.
Most implementations use one of the following combinations:
Conservative Label Retention with Downstream On Demand
Liberal Label Retention with Downstream Unsolicited
Module 2 Page 38
SR OS combinations shown below.
Per Platform vs. Per Interface Label Space
SR OS
Module 2 |
39
The concept of label space is useful for discussing the assignment and distribution of labels. There are two types of
label spaces: per platform and per interface.
Per platform label space assigns a single label per FEC per device, or platform, used by all the devices interfaces.
Per interface label space assigns a unique label to each FEC per interface, usually based on interface specific resources,
such as Frame Relay DLCI or ATM VPI/VCI.
Per platform label space uses fewer label resources than per interface. With per platform labels, the same label may be
used to forward a packet from an LSR, regardless of which physical port is used to forward that packet. This is common
in the Ethernet scenario.
The Alcatel-Lucent Service Routers implement per platform label space.
Module 2 Page 39
SR OS
IGP-based tunnels (only)

Simple configuration
Automatic tunnel creation
No Traffic Engineering Support
IGP dependant convergence times
Also called Link or Interface LDP
Downstream Unsolicited
Liberal Retention
Fully customizable tunnel paths

Ability to run more complex path
calculations with additional
administrative constraints.
Superior traffic protection
mechanisms.
Higher administrative overhead.
Conservative Retention
Module 2 |
40
LDP creates IGP-based LSPs. Label exchange and signaling creates the LSP paths, which are determined by the IGP
algorithm in use, typically a shortest path algorithm. The IGP route selection determines the best path the LSP uses for
that FEC. Each downstream router also independently chooses the label it will use to forward labeled packets to the
destination, just as though the routers were forwarding the traffic strictly at Layer 3.
LDP provides no redundancy, no traffic protection mechanisms beyond multiple possible IGP paths and ECMP. One could
consider LDP best effort forwarding, completely dependent on the IGP.
RSVP-TE, oh the other hand, establishes LSP tunnels that enable the allocation of resources along the defined path,
which could be simply the IGP chosen path, or a set of strictly defined downstream routers. RSVP-TE allows per LSP
path bandwidth allocation, allowing the head end (iLER) to choose the path that meets the specified bandwidth
requirement.
RSVP-TE also supports LSP establishment based on the IGP, using a constraint based algorithm such as CSPF (constraintbased Shortest Path First), or based on explicitly defined paths. IGPs require additional protocol extensions to allow
CSPF to be implemented.
Finally, RSVP-TE includes a rich set of protection mechanisms, namely secondary path and Fast Reroute protection, that
surpass the convergence times offered by IGP.
Module 2 Page 40
MPLS Transport Label Signaling Protocols
Used for Layer 2 VPN Services

RFC 4447 specifies its use
Creates an end-to-end session
between two PE routers.
Used for Layer 3 (IP) VPN Services

Called Multi-Protocol due to its
support for different address
families other than standard IPv4
Based on RFC 4364
Module 2 |
41
Beyond LDP and RSVP-TE, SR OS routers use other MPLS label signaling protocols, which are usually configured and used
when implementing MPLS-based services. Their role is to signal the inner (service) label of the MPLS label stack, thus
they serve a different purpose from LDP or RSVP-TE.
Targeted LDP (T-LDP)
Targeted LDP is used in the implementation of services across an MPLS network. It signals the label that identifies the
particular service, from the eLER to the iLER, such as an ePipe or VPLS. T-LDP is discussed in the SRC Alcatel-Lucent
Service Architecture (ASA) course.
Multiprotocol BGP (MP-BGP)
RFC 4364 defines the Multiprotocol extensions to BGP (MP-BGP) as enhancements to the BGP protocol that supports
MPLS signaling for Layer 3 VPNs. Multiprotocol extensions to BGP (MP-BGP) are discussed in the SRC VPRN (Virtual
Private Routed Networks) course.
Module 2 Page 41
MPLS Service Label Signaling Protocols
MPLS Special Use Labels
Label values 0-15 are reserved for special uses.
Label Usage
IPv4 Explicit Null
Router Alert
IPv6 Explicit Null
Implicit Null
4-15
Module 2 |
42
Label values 0 15 are reserved for use in special applications. These applications are:
Value of 0 represents IPv4 Explicit NULL label
Value of 1 represents Router Alert Label and cannot be at the bottom of the stack
Value of 2 represents IPv6 Explicit NULL label
Value of 3 represents Implicit NULL label
Values 4 15 are reserved for future use
The use of label values 0 3 will be explained in the following pages, although not in sequential order.
NOTE: RFC 3032 specifies that the IPv4 and IPv6 Explicit Null label values have to be at the bottom of the stack. This
restriction has since been removed, as described in RFC 4182.
Module 2 Page 42
Label Value
Router R3 receives packets destined to FEC Z with a label of 100

and always pops them.
Module 2 |
43
The above slide illustrates the normal mode of operation for an LSP that starts on router R1 and ends on router R3.
Router R3 normally receives packets from router R2 with a label of 100 for FEC Z.
Router R3 pops the transport label 100 and sends the original data to its destination.
Module 2 Page 43
Before Implicit Null Normal Operation
On router R3, the result of the label lookup process for packets
destined to FEC Z is always a pop action.
If router R3 wants to save some processing resources, it can
request the penultimate router (router R2) to send the packets
with no transport label.
Router R3 expresses this desire by advertising a label binding for
FEC Z with a value of 3.
Module 2 |
44
Continuing the scenario from the previous page, router R3 can save some CPU processing resources if it does not have to
perform a lookup in its label binding database for FEC Z. Therefore, in this situation it is preferable for router R3 if
router R2 sends packets for FEC Z without labels.
Router R3 signals this request to router R2 by advertising a label binding for its FEC Z, with a label value of 3. This is
called an implicit null request (keep in mind that this is a control message regarding a control plane process).
Router R2 records this label in its label binding table.
On the next page, we see the implication of the implicit null advertisement on the data plane.
Module 2 Page 44
MPLS Implicit Null
The penultimate hop (router R2), honors the request of router R3 and
pops the transport label.
Although the egress label value is displayed as 3, this value can never
exist in an MPLS label of a data packet.
Module 2 |
45
As seen in the figure above, router R2 now has an egress label of 3 for FEC Z.
However, router R2 will not swap the incoming data packets with a label value of 3, as label value 3 can never appear
in the encapsulation header. Instead, router R2 forward the unlabeled packet to router R3. Router R3 still acts as the
LER for that tunnel.
Router R3 is the last hop for this FEC, which makes router R2 the penultimate (the second to last) router. Router R2
now pops the label, thus this behavior is referred to as Penultimate Hop Popping (PHP)
NOTE: The penultimate hop only pops the transport label. It leaves other labels (for example, service labels) in the
stack so that router R3 can still perform service selection based on the service label value.
The primary benefit to using PHP is that it enables a single lookup on the eLER, potentially optimizing the routers
performance. However, any additional information carried in the MPLS header, such as QoS parameters in the EXP bits,
is lost over the last link between the penultimate router and the eLER, and, as a result, the packet may not receive its
proper QoS treatment at the eLER.
Module 2 Page 45
Penultimate Hop Popping (result of Implicit Null advertisement)
Alcatel-Lucent SR OS Support for Penultimate Hop Popping (PHP)
As a penultimate router, Alcatel-Lucent SR OS running routers

have always had the inherent support to honor any PHP request.
It is possible to configure an SR OS router to advertise implicit null
as the last hop router.
Supported for both LDP and RSVP-TE protocols.
Introduced for small-scale MPLS nodes such as the 7705 SAR.
Module 2 |
46
Alcatel-Lucent Service Routers have always had implicit null support as a penultimate hop. That is, if any last hop
router advertises an implicit null, the Service Router understands and honors this request. On the data plane, it pops
the transport label, instead of swapping it, before sending the packet.
The implicit null feature was introduced for deployment scenarios where small-scale Service Router products, such as
the Alcatel-Lucent 7705 SAR (Service Aggregation Router), are used as egress nodes.
The SR OS supports implicit null signaling on both LDP and RSVP-TE protocols.
Configuration required for LDP: configure router ldp implicit-null-label
Configuration required for RSVP-TE: configure router rsvp implicit-null-label
NOTE: If the RSVP-TE process is already running, you must administratively shut down the RSVP process to enable
implicit null label generation. Of course, this can be service effecting.
The configuration steps required then are:
configure router rsvp shutdown
configure router rsvp implicit-null-label
configure router rsvp no shutdown
Module 2 Page 46
SR OS
Router R3 still wants to save some CPU resources, but needs the
QoS information included in the EXP bits.
Router R3 sends to router R2 a label value of 0 (2 for IPv6).
Router R3 pops the label directly without doing a label lookup;
router R3 records the EXP bit value for QoS processing.
Module 2 |
47
The label generated by the egress LER may be the MPLS label value of 0 (zero), known as the IPv4 Explicit Null.
The Explicit Null label solves the issue of PHP, in which the QoS of the packet was lost. The penultimate router
forwards the Explicit Null label with the packet, so the packet retains the EXP value. The eLER can thus treat the
packet based on its EXP value before it pops the Explicit Null label.
Module 2 Page 47
MPLS Explicit Null
The penultimate hop (router R2), honors the request of router R3 and
sends the packet with a label value of 0.
Router R3 immediately pops the label when it sees a value of 0.
Module 2 |
48
If the eLER advertises the label value of 0 to the penultimate LSR, the eLER will receive packets for the FEC containing
an outer MPLS label of 0 from the penultimate LSR.
The MPLS label value of 0 instructs the receiving device, in this case the eLER, to pop the outer label. The next header
in the packet is then inspected and a second lookup is performed at the eLER on that header.
The second header could be another MPLS header, in the case of a multiple label stack, or the IP packet header.
The SR OS has always supported explicit null processing as the penultimate router, although SR routers do not generate
the explicit null label.
Module 2 Page 48
Result of Explicit Null Advertisement
Alcatel-Lucent SR OS Support for Explicit Null
As a penultimate router, Alcatel-Lucent SR OS routers have always

had the inherent support to honor any explicit null request.
The Service Router does not send any explicit null requests as the
last hop.
CPU utilization is not a concern on the Service Router.
Module 2 |
49
Module 2 Page 49
Used in several OAM (Operational, Administration, Maintenance)

applications.
Indicates to the receiving router that the packet must be passed to
the control plane for processing.
Module 2 |
50
The Router Alert label is used in certain OAM (Operational, Administration, Maintenance) applications.
Service Routers contain a diverse set of OAM features that test and monitor various aspects of service and network
health.
Some of these OAM commands require the use of a special label, namely the Router Alert Label (such as MAC-ping and
SDP-ping). The actual use of these commands is covered in SRC ASA and VPLS courses.
From an MPLS perspective, the router sending these OAM commands inserts an additional Router Alert label with a value
of 1.
When the receiving router processes (decapsulates) the MPLS headers on the data plane, it realizes that the underlying
data packet must be passed internally to the control plane, instead of forwarded on another physical interface. As a
result, the OAM message gets processed by the Control Module and necessary actions are taken.
Module 2 Page 50
MPLS Router Alert Label
Section Summary

y The requirement for an IGP in MPLS networks
y Label distribution modes
y Label distribution control modes
y MPLS label negotiation protocols for transport and service

tunnels.
y MPLS reserved labels for special use cases.
y Alcatel-Lucent Implicit Null (PHP) and Explicit Null support
Module 2 |
51
An IGP must be running for MPLS functionality to work in the network
MPLS supports two label distribution modes, Downsteam Unsolicated and Downstream on Demand
MPLS supports two label distribution control modes, Ordered Control and Independent Control
MPLS supports two label retention modes, Liberal Label Retention and Conservative Label Retention
MPLS supports two label space implementation modes, Frame Mode and Cell Mode
SR OS routers use LDP and RSVP-TE for tunnel labels, and T-LDP and MP-BGP for service labels
Label values 0-15 are reserved for special use, such as implict null (3), explicit null (0), and router alert (1)
SR OS routers support implicit and explicit null label processing, and can generate implicit null labels via LDP and
RSVP-TE
Module 2 Page 51
y Label retention modes

y Label space implementation modes
Module Summary
Module 2 |
52
Stacked labels support VPN services as well as MPLS resiliency

features (FRR).
Label stacking allows a single set of unidirectional LSPs to support
multiple VPN services simultaneously.
A label stack is a sequence of last-in, first-out MPLS labels.
Each label header, 32 bits (4 bytes) long, contains a 20 bit label
field, 3 EXP bits, 1 S-bit (Bottom of Stack) and an 8 bit TTL field.
EXP (TC) bits typically transport quality of service information.
Operating exclusively in Pipe mode, the SR OS routers set a TC
(EXP) field value independent of the customer marking.
S-bit = 1 indicates the last entry in the label stack; S-bit = 0 for all
other label stack entries.
In Pipe mode, the SR OS sets the labels TTL independently of the
incoming packets TTL.
Module 2 Page 52
Multiprotocol
Alcatel-Lucent
Label Switching
Multiprotocol Label Switching v2.1
Module 2 |
53
An MPLS label may reside in MPLS specific Shim Header (frame

mode) or in an existing data link header such as ATM or Frame Relay
(cell mode).
IGP routing is a prerequisite for MPLS configuration.
Control plane traffic flows upstream against the downstream data
flow.
An LSR generates labels based on the contents of the local FIB,
which are propagated to other routers representing the label value
that each LSR expects to receive in packets destined to that
particular FEC.
A label binding is the association between an FEC and a label that
represents a specific LSP.
An LSR uses Downstream Unsolicited (DU) label distribution to
distribute label bindings without a specific label request.
An LSR uses Downstream On Demand (DOD) label distribution to
explicitly request a label binding for a particular FEC.
Module 2 Page 53
Using Ordered Control, an LSR distributes label mappings only for the
FECs for which it has already received a label mapping for the FEC
next-hop.
An LSR distributes label mappings independently of other LSRs using
Independent Control mode.
Label retention may either be Liberal or Conservative.
Liberal Label Retention mode allows an LSR to retain all labels it has
received from all peers in memory.
Conservative Label Retention mode allows an LSR to retain only the
received labels that are being used.
Per platform label space is used for interfaces that can share the
same labels.
Per interface label space is used for interfaces that use interface
resources for labels such as ATM or Frame Relay.
Multiprotocol
Alcatel-Lucent
Label Switching
Module 2 |
54
Module 2 Page 54
LDP and RSVP-TE signal transport tunnel labels.

T-LDP and MP-BGP signal service tunnel labels.
SR OS routers support Penultimate Hop Popping (PHP), both as
penultimate LSRs and as eLERs.
PHP eliminates the requirement for the egress router to perform
two packet lookups.
Multiprotocol
Alcatel-Lucent
Label Switching
Module 2 |
55
The explicit null label tells the eLER not to look up the label, but to
pop it on ingress.
The router alert label tells the recipient to pass the packet to the
control plane.
Module 2 Page 55
Learning Assessment
1. What is the bottom label in a label stack called?

2. In a service architecture, the intermediate routers swap labels in
which tunnel only?
4. Describe the encapsulating headers used to move a L3 VPN service

payload between the ingress PE routers and the next-hop
downstream node.
5. In the SR OS pipe mode operation, the head end maps a routerassigned value to which two egress label fields?
6. The SR OS dynamic label assignments start at _______ and end at
_______.
Module 2 |
56
1. What is the bottom label in a label stack called?

The Inner label or service header.
2. In a service architecture, the intermediate routers swap labels in which tunnel only?
The transport tunnel only.
3. In a service architecture, the head-end and tail-end PE routers process which two tunnel headers?
Transport and service headers.
4. Describe the encapsulating headers used to move a L3 VPN service payload between the ingress PE routers and the
next-hop downstream node.
A layer 2 header moves the entire payload from the P to the PE router. The L2 header encapsulates the point-topoint transport tunnel and end-to-end service tunnel headers. The service tunnel header encapsulates the
customers L3 packet header and data.
5. In the SR OS pipe mode operation, the head end maps a router-assigned value to which two egress label fields?
EXP and TTL fields.
6. The SR OS Dynamic label assignments start at 131071 and end at 32768.
Module 2 Page 56
3. In a service architecture, the head-end and tail-end PE routers

process which two tunnel headers?
Learning Assessment (contd)
7. True or False: The SR OS LDP implementation uses Downstream

on Demand label distribution, ordered control, and liberal label
retention.
9. MPLS routers depend on what protocol to distribute the

reachability information the routers use to generate LFIB entries?
10. What label distribution method requires that the iLER request
and and wait to receive a label from the next-hop before
forwarding data downstream?
11. Which control mode ensures a loop-free LSP path?
7.
Module 2 |
57
True or False: The SR OS LDP implementation uses Downstream on Demand label distribution, ordered control,
and liberal label retention.
False.
8.
True or False: The SR OS RSVP-TE implementation uses Downstream on Demand label distribution, ordered
control, and Conservative label retention.
True.
9.
MPLS routers depend on what protocol to distribute the reachability information the routers use to generate LFIB
entries?
The IGP.
10. What label distribution method requires that the iLER request and wait to receive a label from the next-hop
before forwarding data downstream?
DoD.
11. Which control mode ensures a loop-free LSP path?
Ordered control
Module 2 Page 57
8. True or False: The SR OS RSVP-TE implementation uses

Downstream on Demand label distribution, ordered control, and
conservative label retention.
12. LDP implements liberal label retention mode to speed network

convergence in what way?
13. Which label space, implement by the SR OS routers, conserves
label resources?
15. SR OS routers support PHP in what way(s)?

16. What special use label tells the next-hop router to process the
received packet in the control plane?
Module 2 |
58
12. LDP implements liberal label retention mode to speed network convergence in what way?
Populate the LFIB with new labels to represent the IGP lowest cost path to destination.
13. Which label space, implemented by the SR OS routers, conserves label resources?
Per platform.
14. What is a primary difference between LDP and RSVP-TE signaled LSPs?
RSVP builds IGP-based tunnels only, while RSVP-TE allows constraint-based tunnels.
15. SR OS routers support PHP in what way(s)?
They both accept and generate implicit null labels.
16. What special use label tells the next-hop router to process the received packet in the control plane?
The router alert label tells the receiving router to pass the packet to the control plane.
Module 2 Page 58
14. What is a primary difference between LDP and RSVP-TE signaled

LSPs?

Switching
Module 3 Page 1
Module Objectives

to:
Explain the control plane operation of LDP in detail.
Investigate additional features related to LDP.
Module 3 |

Technical Practices for the specific product.
Internet Standards documentation, such as protocol standards bodies, RFCs, and IETF drafts.
Technical support pages of the Alcatel-Lucent website, located at: http://www.alcatel-lucent.com/support
Module 3 focuses on the operational and implementation principles of Label Distribution Protocol (LDP).
The theoretical perspective of fundamental LDP mechanisms is explained with practical configuration details that
reinforce the learning process.
Module 3 Page 2
Demonstrate the ability to configure LDP in an Alcatel-Lucent

environment.
Module 3 - Label Distribution Protocol
Section 1 Operational Principles of LDP
Module 3 Page 3
Section Objectives

Explain the LDP peer discovery and session establishment
processes.
Investigate the label distribution process for Link LDP and explain
how the label databases are populated.
Module 3 |
This section provides a detailed explanation of how routers establish and maintain LDP sessions and how they exchange
labels over these established sessions.
LDP enabled routers maintain two label databases one in the control plane and one in the data plane. Section 1
describes how the routers populate these databases as well as the IGP interaction for the process.
Both the theoretical and practical details of the subject matter are examined, to provide a method to relate the two
perspectives to each other.
Module 3 Page 4
Describe the prerequisites and parameters to establish LDP

sessions.
Label Distribution Protocol (LDP) Introduction
RFC 3036, later updated by RFC 5036, defines LDP as a label

distribution protocol
The LDP sessions enable the exchange of label/FEC binding

(mapping) information.
The LDP protocol in the Alcatel-Lucent 7750 product family is used
for:
1. Link LDP - Establishing Transport Tunnels
2. Targeted LDP - Establishing Service Tunnels between PE
routers.
Module 3 |
RFC 3036 defines LDP as an MPLS label distribution protocol. Routers running the LDP protocol establish LDP sessions
with other LDP routers. The LDP sessions allow them to exchange of label/FEC binding (mapping) information.
To support MPLS label switching, routers must distribute labels for the FECs (IP prefixes) listed in the FIB (route table).
Though multiple interior routing protocols exist, (RIP, OSPF, IS-IS, and so on), modifying each routing protocol to
support label distribution became too difficult. Therefore, Label Distribution Protocol (LDP) was introduced to carry
label binding information for FECs, regardless of the routing protocol used in the network.
The LDP protocol in the Alcatel-Lucent 7750 product family is used for:
Establishing Transport Tunnel LSPs.
Establishing Targeted LDP sessions between directly or indirectly connected peers.
Providing shortcut tunnels to label switch native IP traffic (explained later in Module 5).
Module 3 Page 5
Routers configured for LDP establish an LDP session between them

and become peers.
Link LDP is used to establish transport tunnels.

y iLER uses the transport tunnel to reach the eLER.
Targeted LDP is used to establish L2 VPN service tunnels.
y eLER uses the service tunnel for service de-multiplexing.
Module 3 |
The service provider IP/MPLS network supports all customer services - including scalable and standards based VPN
solutions - over a consolidated, shared backbone.
For example, the above slide illustrates how MPLS tunnels might be used to support the logical service construct for
simple point-to-point connectivity services. Only the edge (PE) routers know the services exist; service instances are
configured on all the participating PE routers for each VPN customer. Hence, a single set of MPLS transport tunnels can
carry traffic for hundreds of point-to-point service instances. The transport tunnels do not care what they transport,
for to them the service traffic becomes just another payload.
A service instance is a virtual software entity in the service router. Different service instances provide isolation
between different customers, which provides inherent security and the ability to apply local customized settings for
each customer. Different logical service instances also allow for an especially granular and scalable allocation of
resources across customers.
A more detailed discussion on the Alcatel-Lucent service model is included in the SRC ASA (Alcatel-Lucent Service
Architecture) course. The important point to understand here is the concept of tunneling and label stacking.
Module 3 Page 6
Transport Tunnels and Service Tunnels
Link LDP sessions are created between all directly adjacent LDP
routers.
Routers exchange label bindings with each other over LDP sessions.
This creates a full-mesh of transport tunnels in the network.
It relies on IGP for operation and convergence.
Module 3 |
Link LDP requires all participating routers to establish peering relationships and sessions between each other. After the
sessions are established, routers exchange label bindings with each other for their selected FECs. The routers maintain
the sessions by exchanging periodic keepalive messages.
Label exchange occurs in a flooding manner, much like how IGP topology information is distributed throughout the
network. The routers perform a selection process on the received labels to decide which next-hop router and label will
be used to reach all the other Label Switching Routers. This way, logical entities called Label Switched Paths (LSPs) or
tunnels will be created in a full-mesh fashion between every possible source and destination router pair in the LDP
network.
LDP relies on the underlying Interior Gateway Protocol (IGP) to establish the sessions, obtain FEC information, and
maintain the tunnels.
Failure recovery times also depend on the performance of the IGP convergence times, but this will be discussed later in
Module 6.
Module 3 Page 7
Link LDP Overview
Link LDP Operation Overview
The following four processes create and maintain a Link LDP

session:
y Session Establishment and Management LDP sessions are built

between LDP peering routers. Sessions are maintained via
keepalive messages.
y Label Management After sessions are established, LDP
distributes label bindings, and withdraws them if necessary.
y Notification LDP uses notification messages to alert LDP
peering routers about errors.
Module 3 |
In the first process, LDP enabled routers discover each other via Hello messages, using a process similar to OSPF.
The routers send hello messages on all the LDP enabled network links, targeting the multicast address 2240.0.2 and the
well-known UDP port 646. After the routers successfully discover and acknowledge each other, they send periodic hello
messages to keep the adjacency alive.
When the discovery phase is complete, a single LDP session is established between each router pair, regardless of how
many parallel network links may exist between the two.
The primary objective of LDP is to distribute labels by distributing label mapping messages over the established
sessions.
If the FEC for which a label was distributed becomes unavailable, the egress router for the FEC will direct its peers to
clear their label associations by issuing label withdraw messages. Label withdraw messages are acknowledged by the
receiving routers via label release messages (this process is explained in further detail in Section 2).
If errors are encountered at any point during the peering session, routers will inform each other via notification
messages.
Module 3 Page 8
y Peer Discovery Routers use LDP Hello messages to

automatically discover other LDP peers.
LDP Main Message Categories Summary
LDP uses both UDP and TCP for transport services.

UDP based messages:
Discovery messages periodically announce and maintain an LDP
router in a network.
Session messages establish, maintain, and terminate sessions
between LDP peers.
Advertisement messages create, change, and delete label
mappings for FECs.
Notification messages signal errors and other events.
Module 3 |
There are four categories of LDP messages:

1. Discovery messages - periodically announce and maintain the presence of an LDP router in a network.
2. Session messages - establish, maintain, and terminate sessions between LDP peers.
3. Advertisement messages - create, change, and delete label mappings for FECs.
4. Notification messages - signal errors and other events of note.
Operating LDP correctly requires the reliable and ordered delivery of messages. To satisfy these requirements, LDP uses
TCP as a transport protocol for session, advertisement, and notification messages (for everything, except the UDP based
discovery mechanism).
Module 3 Page 9
TCP based messages:
10.10.10.x/32 addresses are the system (default loopback)

interface addresses.
Module 3 |
10
The above diagram explains the main principles of LDP operation that are used throughout this module.
System IP interfaces are created on the Service Routers by default and are crucial to the operation of the routers in
various contexts.
Unique addresses need to be assigned to the system IP addresses to maintain proper operation.
A prefix length of 32 is assigned to system IP interfaces, which implies a single host; the host is the router itself in this
case.
Module 3 Page 10
Link LDP Operation Reference Topology
A:R4>config>router#
-------------------------------interface "toR6"
address 10.4.6.4/24
port 1/1/4
exit
A:R4>config>router>ldp#
-------------------------------interface-parameters
interface "toR6"
exit
exit
A:R6>config>router#
-------------------------------interface "toR4"
address 10.4.6.6/24
port 1/1/4
exit
IP Interface
Configuration
interface "toR4"
exit
exit
Link LDP
Configuration
Module 3 |
11
When a router is configured from scratch, some basic hardware provisioning is necessary to initialize several data plane
components. It involves the following:
Provisioning Input Output Modules (IOMs) with the correct card type.
Provisioning Media Dependent Adapters (MDAs) with the correct MDA type.
Enabling network ports (they are shutdown by default).
When the hardware is provisioned, IP interfaces are configured on the network. It is a good idea to use the ping tool
after this step, to verify IP reachability to the neighboring device.
Link LDP is enabled in the configure router ldp context, and then under the interface-parameters subcontext. All the network interfaces that will take part in the LDP domain must be added into this sub-context.
When LDP is enabled, a series of processes are triggered, which take place via the exchange of several LDP packet
types. In the end, an LDP session is created between all adjacent routers and label distribution can occur.
These processes are explained by a single router pair, routers R4 and R6, in the reference topology.
The same sequence of events occurs on every other router pair in the network.
Module 3 Page 11
Link LDP Initial Configuration
A:R4# show router ldp status

===============================================================================
LDP Status for LSR ID 0.0.0.0
===============================================================================
Admin State
: Up
Oper State
: Down
Created at
: 05/15/2010 14:02:40 Down Time
: 10d 20:15:38
Oper Down Reason
: systemIpDown
Oper Down Events
: 0
A:R4>config>router#
-------------------------------interface system"
address 10.10.10.4/32
exit
System
IP Interface
Configuration
A:R6>config>router#
-------------------------------interface system"
address 10.10.10.6/32
exit
Module 3 |
12
At this point, the LDP routers do not even attempt to initiate the LDP neighbor discovery process because the system IP
addresses are not configured on both. The LDP operational status remains down, with the status code indicating that
the System IP interface is down. This error message can be the result of an address that is not configured, or a system
interface that is administratively disabled (with a shutdown command).
It is sufficient to specify an IP address with a /32 prefix length to enable the system IP address, but the administrator
must ensure that each router uses a unique system IP address in the network.
If any two adjacent routers in the network have overlapping system IP addresses, they will be unable to establish any
form of peering (IGP or LDP). When non-adjacent routers have the same system IP addresses, strange routing problems
occur in the network that could be difficult to troubleshoot.
Module 3 Page 12
Link LDP Requirement for System IP Interface
LDP Hello Messages are sent to the all-routers multicast

destination IP address (224.0.0.2) and UDP port 646.
Module 3 |
13
After LDP is enabled on the previously created IP interfaces, and unique system IP addresses are assigned on both
routers, the routers start exchanging packets that relate to a series of processes.
The first of these processes is peer discovery. Once LDP is enabled on an interface, the router sends out an LDP Hello
packet to find out about its neighbor(s) on that link segment. This process is very similar to link-state IGP protocols
(OSPF and IS-IS).
LDP Hello messages are sent to the reserved all-routers multicast address 224.0.0.2. This is to ensure that, if several
routers are attached to the same broadcast segment, all will receive the hello message, and process it if they also have
LDP enabled on their interfaces.
When routers receive a hello response, they identify the router in the source of the hello message as a Link LDP peer
and mark the network interface as an active Link LDP adjacency.
LDP Hello messages are sent over the transport layer protocol UDP with the designated destination port number 646.
A number of parameters is included in the hello messages. The most important of these are indicated in bold in the
above figure and are explained in the following slides.
Module 3 Page 13
Link LDP Peer Discovery Process (Hello Adjacency)
Parameter Exchange in LDP Hello Messages
LDP-ID (LDP Identifier): 6-byte field that identifies an LSR uniquely

along with its label space. Used in all the LDP messages.
Hello Timeout: Routers continue exchanging LDP Hellos after a

successful discovery. A neighbor is declared down if no hello
messages are received from that neighbor within the timeout
period.
Module 3 |
14
Among the most important parameters in LDP operation are:

LDP-ID: 6-byte field that identifies an LSR uniquely along with its label space. This identifier is also included in all
the subsequent LDP messages.
NOTE: In Module 2, an LSR was defined as an intermediate router along a Label Switched Path (LSP) that performs a
label swap operation on incoming labeled packets. In general MPLS terminology, an LSR refers to any MPLS capable
router, regardless of its function and placement in relation to the path of an LSP.
Transport Address: The routers establish the TCP connection by targeting the other routers transport address.
Each router needs to choose and advertise its transport address to the peer.
Hello Timeout: Specifies the time period that a router will wait for further hello messages before it declares its
neighbor down.
Configuration Sequence Number: Specifies a sequence of numbers 4 octets long that identifies the configuration
state of the sending LSR. The receiving LSR uses this to detect configuration changes on the sending LSR.
Module 3 Page 14
Transport Address: A necessary parameter to establish the

subsequent LDP session with the neighbor.
LDP Identifier
The first four octets identify the LSR and must be a globally unique
value.
Typically, the system IP address is assigned as the LSR-ID.
The last two octets identify a specific label space within the LSR.
For platform wide label spaces, the last two octets of the LDP
Identifier are always set to zero.
Example: 10.10.10.4:0
Module 3 |
15
An LDP identifier is a six octet quantity used to identify an LSR label space.
The first four octets identify the LSR and must be globally unique values, such as a 32 bit router ID assigned to the LSR.
The last two octets identify a specific label space within the LSR and are always set to zero for platform wide label
spaces.
Alcatel-Lucent Service Routers use platform wide label spaces; therefore, the last two octets are always set to zero in
the LDP identifiers.
When an LSR uses LDP to advertise more than one label space to another LSR, it uses a separate LDP session for each
label space. This is referred to as per interface label space and, in this situation, the last two octets of the LDP
identifier for per interface label spaces are not zero.
For example, when an LSR has two links to a peer and both are ATM and use per interface labels, it advertises more
than one label space to the peer and, hence, uses more than one LDP identifier, in the range 4000-5000.
Another example of when an LSR would use multiple LDP identifiers is when the LSR has two links to the same LSR peer,
one of which is Ethernet, which uses per platform labels, and the other of which is ATM or Frame Relay, which uses per
interface labels.
Module 3 Page 15
An LDP identifier is a 6-byte quantity used to identify an LSR and its

label space.
Periodic Hellos are sent to ensure that the adjacency is up.

Hello Interval = Hello Timeout/Hello Factor
Module 3 |
16
When there is physical link failure, lower layer detection mechanisms usually warn upper layer protocols about the
problem to prompt them to converge again. To cover corner-case situations, where failures go undetected by the lower
layer mechanisms, the periodic hello exchange mechanism is deployed in LDP.
After the routers complete the discovery process, they continue to send out hello messages to their neighbors at predefined intervals. The router expects to hear an LDP hello message from its neighbor within the specified hello timeout
period. You can configure the LDP hello timeout either globally or per interface. The default hello timeout is 15 secs.
The hello factor determines how many hello messages the router sends in the timeout period. You may also configure
the hello factor either globally or per interface. The default hello factor is 3 messages/timeout period. Divide the
timeout by the factor value, and you get the interval between hello messages.
For example: Hello interval (time between hellos) = Hello timeout hello factor = 15 3 =5. By default, the routers
send one hello over 5 seconds. Note that you cannot configure the hello interval, but knowing this value helps you
determine how often you should observe the routers exchange hello message.
If the routers have multiple interfaces, they send a separate set of hello messages on each of the links.
Module 3 Page 16
LDP Periodic Hellos and Hello Timeout
hello 15 3
interface "toR2
exit
interface "toR3
exit
interface "toR4
hello 45 3
exit
hello <timeout> <factor>

Timeout = 15 seconds & Factor = 3
(153 = 5 seconds Hello Interval)
(global setting)
(453 = 15 seconds Hello Interval )
(overrides the global setting)
Module 3 |
17
When configured directly under the interface-parameters subcontext, the hello parameters apply to all the network
interfaces configured for LDP.
To override the global settings, individual settings can be applied per interface.
Hello parameters are configured in the following format:
*A:R1>config>router>ldp>if-params# hello
- hello <timeout> <factor>
- no hello
<timeout>
: [3..65535]
<factor>
: [1..255]
The no form of this command restores the default settings: Timeout = 15, and Factor = 3.
In the above slide, and with the displayed settings, router R1 sends hello messages to neighbors routers R2 and R3 at 5
second intervals.
With the override settings at interface level, hello messages are sent to router R4 at 15 second intervals.
Module 3 Page 17
Hello Timeout Configuration
Neighbors exchange their locally configured Hello Timeout values

inside the hello messages.
LDP adjacency can be established, even if the timeout values do
not match.
The lower value is used on both sides.
Module 3 |
18
Each router specifies the locally configured hello timeout period in the hello message that they send to the peer.
The hello timeout values do not need to match on both routers for the discovery process to succeed. A silent
negotiation takes place, in which the routers set the operational timeout period to the lower of the received or
advertised values. This determines the hello sending interval, according to the hello factor.
Hello Interval is set to the operational hello timeout value divided by the locally configured factor.
Module 3 Page 18
Hello Timeout Mismatch
Link LDP Successful Hello Adjacency
A:R6# show router ldp discovery detail

------------------------------------------------------------------------------Interface "toR4"
------------------------------------------------------------------------------Local Address
: 10.10.10.6
Peer Address
: 10.10.10.4
Adjacency Type
: Link
State
: Established
Up Time
: 0d 01:36:43
Hold Time Remaining : 12
Hello Mesg Recv
: 1452
Hello Mesg Sent
: 1436
Local IP Address
: 10.4.6.6
Remote IP Address
: 10.4.6.4
Local Hello Timeout: 45
Remote Hello Timeout: 15
Local Cfg Seq No
: 1708861572
Remote Cfg Seq No
: 1071982260
Module 3 |
19
The status of the discovery process relevant to all the configured LDP peerings can be verified with the show router
ldp discovery command.
Local and Peer Addr are actually the system IP addresses of each router, as advertised in the LSR-ID portion of the
LDP identifier included in the hello messages.
The possible values for AdjType are Link and Targeted. In this case, only a link LDP adjacency exists between the
two routers.
The State is Estab (a truncated form of Established). This indicates that the two routers have successfully passed
the initial discovery stage and are ready to create a session.
If the detail keyword is appended to the command, more details are displayed relating to the adjacency.
The Hold Time Remaining is reset to 15 (by default) every time a hello message is received from the peer.
The Hello Mesg Recv and Sent show the number of messages received and sent during the uptime of the adjacency.
Local and Remote IP Address refer to the directly connected IP interface at each side of the connection.
The output also shows the locally configured hello timeout and the timeout value that was received from the directly
connected peer. As mentioned before, the operational timeout value is set to the lower of these two values - 15 in this
case.
Routers also include a sequence number in the hello messages. This is a 4-byte unsigned configuration number that
indicates the configuration state of the sending router. It is used by the receiving router to detect configuration
changes on the sending router. The sending router increments the configuration sequence number whenever there is a
configuration change (such as the hello timeout).
Module 3 Page 19
A:R6# show router ldp discovery

===============================================================================
LDP Hello Adjacencies
===============================================================================
Interface Name
Local Addr
Peer Addr
AdjType State
------------------------------------------------------------------------------toR4
10.10.10.6
10.10.10.4
Link
Estab
-------------------------------------------------------------------------------
After a successful LDP adjacency, an LDP session must be

established.
The Transport Addresses, signaled between the two routers,
determines:
y Which router initiates the session (to TCP destination port 646).
y Which IP addresses the routers use to establish the session.
Transport addresses are exchanged via LDP Hello messages.
Module 3 |
20
After an adjacency is established between the two LDP routers, using UDP Hello messages, an LDP session is required for
the reliable exchange of label advertisement messages.
Initially, the routers set up a TCP connection over which the LDP session runs. Like any other TCP application, LDP takes
advantage of TCP reliability mechanisms, such as sequence number tracking, acknowledgment, and retransmission, to
ensure that all messages are sent and received correctly by both peers.
In a TCP session, one side (the router with the higher transport address) always assumes the active role and initiates the
TCP connection with its LDP neighbor. LDP uses TCP well-know port number 646.
The routers first need to decide which will be active and start the session establishment process. Another parameter to
determine is the address to use to establish the session on both sides. Both of these concerns are addressed by the
transport address, which is included in the LDP hello messages. A router chooses between the directly connected IP
address or the system IP address to use as a transport address.
The decision depends on two inter-related implementation options, the chosen label space and label implementation.
Module 3 Page 20
Transport Address requirement to establish LDP sessions
With per-platform label space and frame mode implementation,

only 1 LDP session is required between the routers because the
routers exchange the same set of labels per FEC on both
interfaces.
Alcatel-Lucent Service Routers use per-platform label space and
frame mode implementation.
Module 3 |
21
Recall the two types of label spaces and frame/cell mode interface implementations that were introduced in Module 2.
If a router pair has 2 frame mode interfaces, as in the example above, the same set of labels are advertised for the
specified FECs on both interfaces. The label values are picked from a global reserve of labels, identified as per-platform
label space. The routers maintain only one LDP session across the two interfaces.
However, if the router pair has 2 cell-mode interfaces, as with ATM or Frame Relay connections, the router needs to
advertise separate labels on each interface. Each label binding is relevant for each interface in the cell mode of
operation. In this case, 2 separate LDP sessions will be required between the 2 routers, as shown on the right.
Another scenario, not shown in the figure above, is a router pair with a frame mode and a cell mode interface between
each other. Again, two sessions will be established between the routers.
Module 3 Page 21
LDP Session Considerations for Multiple Links
To create a single LDP session, the routers advertise a common

transport address on both interfaces.
On Alcatel-Lucent Service Routers, the transport address is set to
the System IP Address by default in LDP Hello messages .
Module 3 |
22
Only frame mode interfaces and per-platform label space are implemented on Alcatel-Lucent Service Routers.
As such, in the case of multiple interfaces between 2 routers, a single LDP session needs to be established to be able to
advertise a single set of labels for the selected FECs of each router.
This necessitates the use of a single, unique address as the transport address to be advertised inside the LDP Hello
messages in the discovery phase.
System IP addresses need to be unique to each router; for this reason, the system IP address is used as the transport
address by default on Alcatel-Lucent Service Routers.
Module 3 Page 22
Default Transport Address for Alcatel-Lucent Service Routers
transport-address system
interface "toR2
exit
interface "toR3
exit
interface "toR4
transport address interface
exit
global setting (default)
can be changed for possible

interoperability reasons
Module 3 |
23
Although the transport address is set as the system IP address by default on the Service Router, if there is a
requirement to interoperate with another vendor router, it is possible to configure the router to use the directly
connected interface address as the transport address.
In the example above, the transport address of 10.10.10.1 is advertised to routers R2 and R3. This is the global setting
directly under the interface parameters LDP sub-context. It is the default setting and can be displayed by typing info
detail in the configure router ldp context.
An administrator can override this setting on a per interface basis, as shown in the diagram.
NOTE: The default global setting can also be modified to interface, which will apply to all the configured network
interfaces in the LDP context.
Module 3 Page 23
Changing the Default Advertised Transport Address
A:R4# show router ldp session

===============================================================================
Peer LDP Id
Adj Type
State
Msg Sent Msg Recv Up Time
-----------------------------------------------------------------------------10.10.10.6:0
Link
Nonexistent
4
4
0d 00:00:16
-----------------------------------------------------------------------------A:R4# show router fib 1
=========================================
Prefix
Protocol
NextHop
----------------------------------------10.4.6.0/24
LOCAL
10.4.6.0 (toR6)
10.10.10.4/32
LOCAL
10.10.10.4 (system)
----------------------------------------Alcatel-Lucent Multiprotocol Label Switching v2.1
10.10.10.6/32 must be in the

IP Forwarding Table!
Module 3 |
24
The show router ldp session command provides information about the status of the LDP session.
At this stage, the output displays the state of the session as Nonexistent. This implies that a session has not been
attempted by the router.
This can be the result of a lack of the system IP address of the peer in the IP routing (forwarding) table that is specified
in the transport address portion of the LDP hello message.
An Interior Gateway Protocol needs to be configured between the 2 routers to advertise the system IP addresses and
other relevant routing information.
NOTE (1): Configuring an IGP is, in fact, a common practice, even before starting to configure LDP. Here, it is
mentioned at this step to illustrate the possible root cause of such errors.
NOTE (2): Static-routing can also be used to populate the routing table with the system IP addresses of the peers.
Except in very specific cases, however, it is not used in practice.
Module 3 Page 24
IGP Requirement for LDP Sessions
A:R4>config>router>ospf#
-------------------------------area 0.0.0.0
interface system
exit
interface toR6
interface-type p2p*
exit
OSPF
Configuration
A:R4# show router fib 1

=========================================
Prefix
Protocol
NextHop
-----------------------------------------
<........ snipped ........>

10.10.10.6/32
10.4.6.6 (toR6)
OSPF
-------------------------------area 0.0.0.0
interface system
exit
interface toR4
interface-type p2p*
exit

=========================================
Prefix
Protocol
NextHop
-----------------------------------------
<........ snipped ........>

10.10.10.4/32
10.4.6.4 (toR4)
Module 3 |
25
OSPF
An IGP is configured to exchange routing information between the 2 routers. This is necessary to inform each router
about the system IP address (transport address) of the peer. After the session is established, IGP will again be required
to distribute IP prefix (FEC) information across the network.
The relevant OSPF configurations are shown in the figure above. A single (backbone) area is used in the network with an
area-ID of 0.0.0.0 (when configuring, it is sufficient to type only a single zero to represent this ID).
It is important to remember to add the system interfaces in the OSPF configuration, as this is necessary to advertise the
system IP addresses. As a result, the system IP address of the peer is added to the routing and forwarding table of each
router, along with other possible prefixes advertised by the peer.
For the sake of clarity, only the system IP addresses are shown in the figure.
Now that the system IP addresses are known, the routers can begin the LDP session establishment process (described on
the next page).
interface-type p2p*: The actual command used here is interface-type point-to-point. The default setting for
the interface-type is broadcast, which is actually intended for multi-access segments (that is, multiple routers
attached to a common Layer-2 segment). Initial convergence on broadcast segments take more than 40 seconds because
of Designated Router election. It is therefore recommended practice to use the point-to-point setting for directly
connected segments on which only 2 routers exist.
Module 3 Page 25
Enabling IGP
The router with the higher transport address (router R6) initiates
the LDP session to TCP destination port 646 of the neighbor.
Module 3 |
26
The use of the transport address is evident here.

The router with the higher transport address initiates the LDP session. The session request is sent via an Init message to
TCP destination port 646 of the neighboring LDP router. In the example, router R6 is the initiator of the LDP session. It
chooses an arbitrary TCP source port number from the dynamic port range (49,15265,535), as specified by IANA (in this
case, 50309 is chosen).
Several parameters are included in the Init messages, such as the LDP version, LDP identifier of the sending device,
keepalive timeout period, and the LDP identifier of the receiving device.
NOTE: Only the LDP messages are depicted in the above illustration; TCP transport connection details are not included,
for the sake of clarity.
A session is established when a router receives a keepalive message from the peer in response to the keepalive message
that is sent.
The keepalive interval is governed by the configured keepalive timeout value, which is also included in the Init
messages.
Module 3 Page 26
Link LDP LDP Session Establishment
Link LDP Successful Session Establishment
A:R4# show router ldp session detail

------------------------------------------------------------------------------Session with Peer 10.10.10.6:0
------------------------------------------------------------------------------Adjacency Type
: Link
State
: Established
Up Time
: 0d 00:00:51
Max PDU Length
: 4096
KA/Hold Time Remaining: 22
Link Adjacencies : 1
Targeted Adjacencies : 0
Local Address
: 10.10.10.4
Peer Address
: 10.10.10.6
Local TCP Port
: 646
Peer TCP Port
: 50309
Local KA Timeout : 30
Peer KA Timeout
: 30
Mesg Sent
: 22
Mesg Recv
: 23
FECs Sent
: 1
FECs Recv
: 1
GR State
: Capable
Label Distribution
: DU
Module 3 |
27
The status of the session establishment process related to the configured LDP peerings can be verified with the show
router ldp session command.
The State needs to be Established for an operational LDP session to exist between the routers.
The possible values for the Adjacency type are Link and Targeted. In this case, only a link LDP adjacency exists
between the two routers.
If the detail keyword is appended to the command, more details relating to the session are displayed.
The remaining Holdtime is reset to 30 (by default) every time a keepalive message is received from the peer.
The command also displays the total number of session messages received and sent during the uptime of the
session, in this case 20 sent and 21 received.
Local and Remote IP addresses refer to the configured system IP addresses.
The local TCP port is 646, which means this router has assumed the passive role in the session. The active side
(router R6) has chosen a port number of 50309 (explained on the previous page).
The output also shows the locally configured keepalive timeout and the timeout value received from the peer, both
30 seconds.
With the session established, the peers can initiate the label generation and distribution process. The label
distribution mode is indicated as DU, which refers to Downstream Unsolicited, the default mode of operation for
LDP running Service Routers.
Module 3 Page 27
A:R4# show router ldp session

==============================================================================
LDP Sessions
==============================================================================
Peer LDP Id
Adj Type
State
-----------------------------------------------------------------------------10.10.10.6:0
Link
Established
20
21
0d 00:00:47
------------------------------------------------------------------------------
Periodic Keepalives are sent to ensure that the session is up.

Keepalive Interval = Keepalive Timeout Keepalive Factor
Module 3 |
28
When there is physical link failure, lower layer detection mechanisms usually warn upper layer protocols about the
problem to prompt them to reconverge. To cover corner-case situations, where failures go undetected by lower layer
mechanisms, the periodic keepalive exchange mechanism is deployed in LDP.
After the session is established, the routers continue to send keepalive messages towards the neighbor at pre-defined
intervals. A router expects to hear an LDP keepalive message from the neighbor within the specified keepalive timeout
period.
Keepalive Timeout = Keepalive Interval x specified Hello Factor.
The keepalive factor provides a measure of how many keepalive message intervals should elapse before declaring the
peer down.
Module 3 Page 28
LDP Periodic Keepalives and Keepalive Timeout
keepalive 30 3
interface "toR2
exit
interface "toR3
exit
interface "toR4
keepalive 90 3
exit
(global setting)
Timeout = 30 seconds & Factor = 3
(Keepalive Interval = 303 = 10 seconds)
(Keepalive Interval = 903 = 30 seconds)

(overrides the global setting)
Module 3 |
29
When configured directly under the interface-parameters subcontext, the keepalive parameters apply to all the
network interfaces configured for LDP.
To override the global settings, individual settings can be applied per each interface.
Keepalive parameters are configured in this format:
*A:R1>config>router>ldp>if-params# keepalive
- keepalive <timeout> <factor>
- no hello
<timeout>
: [3..65535]
<factor>
: [1..255]
The no form of this command restores the default settings: Timeout = 30, and Factor = 3.
A Keepalive Timeout of 30 divided by a Factor of 3 equal a Keepalive Interval of 10
In the figure above, and with the displayed settings, router R1 sends keepalive messages to neighbors routers R2 and R3
at 10 second intervals.
With the override settings at interface level, keepalive messages are sent to router R4 at 30 second intervals.
Module 3 Page 29
Keepalive Timeout Configuration
Peers exchange their locally configured keepalive timeout values inside

the Init messages.
LDP session can be established, even if the keepalive timeout values do
not match.
The lower value is used on both sides.
Module 3 |
30
Each router specifies the locally configured keepalive timeout period in the Init message that they send to the peer.
The keepalive timeout values do not need to match on both routers for the session to be established. A silent
negotiation takes place, in which routers set the operational timeout period to the lower of either the received or
advertised values. This determines the keepalive sending interval, according to the keepalive factor.
Keepalive Interval will be set to the operational keepalive timeout value divided by the locally configured factor.
Module 3 Page 30
Keepalive Timeout Mismatch
Link LDP sessions are created between all adjacent routers.

Alcatel-Lucent Service Routers generate an LDP label binding only for
their own System IP Address, by default
Labels will be flooded and a full mesh of transport tunnels will be
created.
Module 3 |
31
Link LDP sessions are created between each router pair in the network, as described on the previous pages.
Now label bindings for selected FECs can be exchanged on the established LDP sessions. In this case, an FEC is nothing
but an IP prefix in the routing table.
In an IP/MPLS service network, transport tunnels are only required to carry VPN service traffic between the routers.
Thus, the routers only need to know how to reach other routers, using a certain label. For this purpose, it is sufficient
to distribute labels for the system IP addresses of the routers only.
Recall that the system IP interface is a loopback interface by default, and should be reachable as long as the router is
operational. Even if a physical interface goes down, other routers should be able to reach the system interface of the
router via another interface. This provides resiliency in routing.
Each router generates a label binding for its own system IP address only and distributes this information to its directly
connected peers, with which active LDP sessions exist. Upon receipt of this message, each receiving router generates its
own label binding for the prefix and forwards the information in the network.
This way, label bindings are distributed in a flooding fashion, much like IGP. LDP has embedded mechanisms to prevent
possible indefinite loops during this process.
As a result, each router will have a label binding for the system IP address of every other router in the network. The
sequence of labels and label actions, starting from an ingress data point to an egress data point, is logically represented
by an LSP, or a (transport) tunnel.
Module 3 Page 31
Alcatel-Lucent Service Router Default Label Advertisement
LAB 3 Section 3.1 and 3.2
Module 3 |
32
MPLS Infrastructure and LDP Configuration/

Configuring and Verifying the Provider Core for LDP
Module 3 Page 32
Verifying Alcatel-Lucent Service Router LDP Default Settings
===============================================================================
LDP Parameters (LSR ID 10.10.10.4)
===============================================================================
------------------------------------------------------------------------------Interface Parameters
------------------------------------------------------------------------------Keepalive Timeout : 15 sec
Keepalive Factor : 3
Hold Time
: 15 sec
Hello Factor
: 3
Propagate Policy
: system
Transport Address : system
Deaggregate FECs
: False
Route Preference : 9
Label Distribution : downstreamUnsolicited Label Retention
: liberal
Control Mode
: ordered
Loop Detection
: none
-------------------------------------------------------------------------------
The command output above displays the Alcatel-Lucent Service

Router LDP default settings.
Module 3 |
33
The default implementation parameters used by the ALU Service Routers can be displayed with the show router ldp
parameters command.
Note the parameters depicted in bold. These are router defaults and cannot be modified.
Downstream Unsolicited label distribution mode
Labels are distributed to all LDP peers with active LDP sessions.
Ordered Control Mode
An LDP router generates and distributes a label for its own prefixes only (by default, the System IP address
only).
Upon receipt of a label mapping from a downstream peer, an LDP router generates its own label mapping for
that IP prefix and distributes it to other peers (if any).
Liberal Label Retention
An LDP router keeps all the labels it has received from peers in the control plane.
In the data plane, only one label is used as the active label for a given IP prefix.
Module 3 Page 33
A:R4# show router ldp parameters
Label distribution for prefix 10.10.10.6/32 will initiate at router R6

(egress LER) and will propagate towards router R1 (ingress LER).
Module 3 |
34
The above slide illustrates the distribution of labels in the network.

Router R1 is the ingress Label Edge Router, where the data traffic enters the core network. Router R6 is the egress
Label Edge Router, where the data traffic leaves the core network. Thus, the data traffic flows from the upstream to
the downstream; from left to right.
A Label Switched Path, which is a logical construct made up of a contiguous sequence of labels from routers R1 to R6,
will need to be established. Therefore, router R6 will be the tunnel destination point, which is represented in the IP
routing table uniquely with the system IP address of 10.10.10.6/32.
The control plane process regarding the distribution of labels for prefix 10.10.10.6/32 will be initiated by its owner,
router R6.
The propagation of labels in the network will be explained step-by-step in the following pages, with router R1 as the
ingress LER.
Module 3 Page 34
Label Distribution Case Study
Router R6 generates a label for its system IP address 10.10.10.6/32

in its LIB (Label Information Base) and distributes it to routers R4
and R5 over the previously established LDP sessions.
Module 3 |
35
Prefix 10.10.10.6/32 is configured as a system IP address on router R6; in other words, router R6 is the egress for prefix
10.10.10.6/32. Therefore, router R6 must initiate the entire label distribution process for its own system IP address.
For this purpose, router R6 picks an available label from the range allocated by MPLS protocols for dynamical
assignment (32768 - 131071) and associates it with prefix 10.10.10.6/32; that is, it generates a label binding for prefix
10.10.10.6/32. Label 131071 is locally reserved for prefix 10.10.10.6/32 on router R6 for use by LDP. No other prefix
can be assigned to this label, and no other dynamic protocol can use this label on router R6.
Router R6 sends out a label mapping message to both routers R4 and R5 to inform the peers of this label binding. The
destination IP address of the label mapping message is either 10.10.10.4 or 10.10.10.5.
Recall that LDP uses platform wide label space implementation on the Service Routers; therefore, the same label
(131071) is distributed to both neighbors.
LDP operates in Downstream Unsolicited mode; therefore, router R6 does not need to receive requests from its
neighbors to distribute the label binding. If there is an active session, the generated label binding is distributed towards
the other peer right away. Router R6 chooses the label that it wishes its peers to use when forwarding data to R6.
Module 3 Page 35
Label Generation and Distribution on router R6 (egress LER)
Label Information Base (LIB) on router R6
Peer: The LDP peers address to which this router sent or from
which it received a label for this FEC. In this example, these are
peers to which R6 sent a label.
Ingress Label: Locally generated and distributed label value.
Egress Label: The label value received from the peer. R6 is the
egress LER for prefix 10.10.10.6/32, so it is not applicable in this
case.
Module 3 |
36
Label generation and distribution is a control plane process that needs to take place before data packets can be
delivered.
Therefore, the generated label for prefix 10.10.10.6/32 is stored in a table or database that is called the Label
Information Base (LIB).
A router maintains entries in the LIB for every prefix for which it has generated and distributed a label binding, as well
as label bindings it has received for those prefixes. Since a router can have multiple directly connected peers, there can
be multiple entries per prefix for each peer.
The label that is locally generated and distributed to a peer is indicated in the IngLbl (Ingress Label) column. Recall that
the control plane and data plane functions operate in the opposite direction to each other. If router A needs to forward
a labeled packet to router B, router A first needs a label. Router B sends the label upstream to router A, so that router
A can forward labeled packets downstream to router B.
Router R6 distributes a label of 131071 to its neighbor, which signals that it wishes to receive the (ingress) labeled data
packets destined to its system IP address with that label.
The EgrLbl (Egress Label), EgrIntf (Egress Interface) and EgrNextHop (Egress Next-Hop) fields are empty; therefore, the
ingress labeled data packets for this prefix have no outgoing transport (outer) labels. This is an indication that router R6
terminates LSPs targeting its FEC 10.10./10.6/32, removing (popping) in the data plane the label 131071 from ingress
packets. Router R6 is where the LSP (Transport Tunnel) to 10.10.10.6/32 terminates or ends.
Module 3 Page 36
A:R6# show router ldp bindings

===============================================================================
LDP Prefix Bindings
===============================================================================
Prefix
Peer
IngLbl
EgrLbl EgrIntf/
EgrNextHop
------------------------------------------------------------------------------10.10.10.6/32
10.10.10.4
131071
---10.10.10.6/32
10.10.10.5
131071
----------------------------------------------------------------------------------
The router checks the next-hop information for the given prefix in
the IP Forwarding Information Base (FIB).
This determines which label binding entry in the LIB will be written
into the LFIB, in case of multiple options.
LFIB is used to label switch the data packets.
Module 3 |
37
In Module 2 we explained that, internally, every router has separate control plane and data plane functionalities. The
figure above provides a high level of view of the consistent interaction between the control and data planes from the
perspective of LDP operation.
All the dynamic routing and signaling protocol operations occur in the control plane. As a prerequisite, the Routing
Information Base (RIB), which serves as a database to store all the routing protocol entries, has already been populated.
The best routes are chosen from this database of possible alternatives and written into the Route Table. Finally, a copy
of this route table is installed in the data plane, in the form of a Forwarding Information Base (FIB).
Once the operator enables LDP on the router and/or interfaces, the routers form LDB adjacencies. The Label
Information Base (LIB) contains all the label bindings that have been sent to or received from the active peers.
Recalling that LDP operates in Downstream Unsolicited mode, this implies a flooding behavior similar to IGP. Therefore,
there are multiple options (multiple egress labels and next-hop routers) to reach certain destination prefixes. Again, the
best of the possible options needs to be chosen and indicated in the data plane as the active label binding to label
switch the packets.
As mentioned earlier, LDP has a strong reliance on IGP in this context. This means that LDP will use the IGP active nexthop to determine which label it will use to forward traffic for a particular FEC.
The Forwarding Information Base (FIB) contains the active IP next-hop information. The router checks the FIB,
determines the active next-hop, and installs the label that has been received from that active next-hop in the Label
Forwarding Information Base (LFIB).
This will become more evident as we move through the case study and track the label distribution process.
Module 3 Page 37
Building the Label Forwarding Information Base (LFIB)
(LIB)

===============================================================================
LDP Prefix Bindings
===============================================================================
Prefix
Peer
IngLbl
EgrLbl EgrIntf/
EgrNextHop
------------------------------------------------------------------------------10.10.10.6/32
10.10.10.4
131071
---10.10.10.6/32
10.10.10.5
131071
----------------------------------------------------------------------------------
(FIB)

=========================================
Prefix
Protocol
NextHop
----------------------------------------10.10.10.6/32
LOCAL
10.10.10.6 (system)
-----------------------------------------
(LFIB)
The router is the egress point for the

prefix. (Label action must be POP).
A:R6# show router ldp bindings active

===============================================================================
LDP Prefix Bindings (Active)
===============================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
------------------------------------------------------------------------------10.10.10.6/32
Pop 131071
----------------------------------------------------------------------------------
Module 3 |
38
Router R6 has not received any label bindings for 10.10.10.6/32 from its neighbors, indicated by the fact that the
egress label, interface, and next-hop fields are empty in the show router ldp bindings command output that
displays the LIB.
This is expected, because router R6 is the egress LER for LSPs, targeting its own system IP address. The single FIB entry,
showing router R6s system interface as the LOCAL next-hop also indicates the target prefix resides on router R6.
NOTE: The command to display the FIB on the ALU Service Routers is show router fib X. X is the IOM (Input Output
Module) hardware slot number on the chassis. In theory, all installed IOMs have the same copy of the FIB.
Appending the active keyword to the show router ldp bindings command shows the labels that are actively
used, and the corresponding label actions on the data plane. This is the Label Forwarding Information Base (LFIB). In the
example, the entry says that if the router receives data packets labeled data packets with transport (outer) labels of
131071, it will POP the label and analyze the next encapsulation header.
Both the FIB and LFIB are uniform throughout the entire data plane. Regardless of which data plane component (IOM)
the packets travel through, they are subject to the same treatment.
Module 3 Page 38
Label Forwarding Information Base (LFIB) on router R6
Upon receipt of the label mapping message from router R6 (eLER)

for prefix 10.10.10.6/32, router R4 generates its own label binding
and distributes to other peers (routers R2 and R5).
Module 3 |
39
1. Router R6 sends a label mapping message to routers R4 and R5. (Only router R4 is considered here, for the sake of
clarity.)
Upon receipt of the message, router R4 receives the label binding for prefix 10.10.10.10.6/32 and writes it into its LIB,
as an egress label towards router R6.
2, 3. Seeing that there are other active LDP peers present, router R4 generates its own label binding for 10.10.10.6/32
and distributes it to routers R2 and R5. The destination IP of the label mapping message here is either 10.10.10.2
(router R2) or 10.10.10.5 (router R5).
Module 3 Page 39
Label Generation and Distribution on router R4
Label Information Base (LIB) on router R4
R6
R2 and R5
Label binding received from R6

Label binding locally generated and distributed to R2 and R5
Module 3 |
40
The slide shows router R4s LIB, where it has received from router R6 a label binding for prefix 10.10.10.6/32, and has
distributed its own label binding to the other peers, routers R2 and R5. For this particular FEC, router R4 now has 3 LIB
entries.
The first 2 rows of the LIB display the label generated by router R4 and advertised to both peers, routers R2 and R5. It
is an ingress label because this is the label that router R4 expects to receive in the data plane, if the neighbors choose
router R4 as the next-hop to reach router R6.
The third row indicates the label binding received from router R6, the owner of the prefix. It is an Egress Label because
this is the label used when sending labeled packets to router R6 in the data plane. The physical egress interface and the
resolved next-hop IP address are also included in the output for this entry.
However, this is not the complete picture on router R6. The label distribution case study is continued on the next
pages.
Module 3 Page 40

===============================================================================
LDP Prefix Bindings
===============================================================================
Prefix
Peer
IngLbl
EgrLbl EgrIntf/
EgrNextHop
------------------------------------------------------------------------------10.10.10.6/32
10.10.10.2 R2
131070
---10.10.10.6/32
10.10.10.5 R5
131070
---10.10.10.6/32
10.10.10.6 R6
-131071 1/1/4
10.4.6.6
-------------------------------------------------------------------------------
LDP routers flood labels to their peers

Both routers R2 and R5 flood label mappings for prefix 10.10.10.6/32 to
router R4 and their other peers.
Module 3 |
41
In a redundant network, a router may receive multiple label mapping messages from several peers for the same prefix.
Label mapping messages are propagated through the network in a flooding fashion and, as a result, router R4 receives a
label binding for prefix 10.10.10.6/32 from routers R2 and R5.
Module 3 Page 41
Label Flooding in the LDP Network
Updated Label Information Base (LIB) on router R4
The label mappings received from routes R2 and R5 are also written
into the LIB in the EgrLbl (Egress Label) column.
This is a consequence of using Liberal Label Retention (all label
bindings are kept in the LIB).
Router R4 has chosen router R6 as the active next-hop for
10.10.10.6/32; therefore, only the entry for router R6 has an
associated Egress Interface and Egress Next-Hop IP address.
Module 3 |
42
In this slide, router R4 has now received a label binding for prefix 10.10.10.6/32 from routers R2 and R5. Notice that
the EgrLbl field now shows these received labels; compare the above slides Egress entries with the previous slides
router R4 LIB snapshot.
As described earlier, an egress label indicates that the router can potentially use the peer that advertised the label as a
next-hop to send labeled data packets. Also, recall that all label bindings are kept in the LIB when using Liberal Label
Retention mode, which allows for faster path transition in network link failures.
However, only a single egress label and a single egress interface are required to label switch the packets in the data
plane. This implies that the router needs to make a local selection from among the alternatives that are present in the
LIB, and install the chosen entry in the LFIB.
The above output illustrates the outcome of this selection process. Only the entry for router R6 has a physical egress
interface as well as a resolved next-hop IP address, which indicates that label 131071 and port 1/1/4 will be used when
sending labeled packets for prefix 10.10.10.6/32. The details of this selection process regarding the LIB, FIB and LFIB
interaction are explained on the next page.
NOTE: An exception to the one egress label and one egress interface per prefix rule arises if Equal Cost Multiple Path
(ECMP) is enabled on the router. ECMP is discussed in the next section.
Module 3 Page 42

===============================================================================
LDP Prefix Bindings
===============================================================================
Prefix
Peer
IngLbl
EgrLbl EgrIntf/
EgrNextHop
------------------------------------------------------------------------------10.10.10.6/32
10.10.10.2 R2
131070
131068
--10.10.10.6/32
10.10.10.5 R5
131070
131069
--10.10.10.6/32
10.10.10.6 R6
-131071 1/1/4
10.4.6.6
-------------------------------------------------------------------------------

===============================================================================
Prefix
Protocol
NextHop
------------------------------------------------------------------------------10.10.10.6/32
OSPF
10.4.6.6 (toR6) R6
===============================================================================
===============================================================================
Prefix
Op
IngLbl
EgrLbl
------------------------------------------------------------------------------10.10.10.6/32
Swap 131070
131071
1/1/4
10.4.6.6
Module 3 |
43
To sum up:
Router R4 receives a label binding for prefix 10.10.10.6/32 from router R6 (131071 in the egress column).
Router R4 generates its own label binding for the same prefix and distributes to routers R2 and R5 (131070 in the
ingress column for both entries).
Router R4 receives additional label bindings for prefix 10.10.10.6/32 back from routers R2 and R5 (131068 and
131069 in the egress column).
On the data plane, regardless of the interface, the packet is received. Router R4 expects to receive the same label from
its peers for prefix 10.10.10.6/32 (Ingress Label 131070).
An egress label and egress interface must be chosen from among the three options. Router R4 checks the FIB to identify
the IP next-hop for prefix 10.10.10.6/32.
The IP next-hop is router R6, so router R4 installs the label received from router R6 as the active egress label and
displays the associated egress physical interface and next-hop IP address that will be used in data forwarding.
As indicated earlier, redundant entries in the LIB help to increase failure recovery times. For example, if the interface
between routers R4 and R6 goes down, router R4 can place in its LFIB the label it received from router R5, sending the
traffic instead to router R5 immediately after IGP convergence. More aspects of LDP and network convergence are
covered in Module 6 Resiliency.
NOTE: Router R4 also has a Push entry for prefix 10.10.10.6/32 in the LFIB, for cases where it is the ingress LER for
data traffic. This is not discussed here for the sake of a more straightforward example, and because the case study
focuses on where router R1 is the ingress, and router R6 is the egress, LER specifically.
Module 3 Page 43

===============================================================================
LDP Prefix Bindings
===============================================================================
Prefix
Peer
IngLbl
EgrLbl EgrIntf/
EgrNextHop
------------------------------------------------------------------------------10.10.10.6/32
10.10.10.2 R2
131070
131068
--10.10.10.6/32
10.10.10.5 R5
131070
131069
--10.10.10.6/32
10.10.10.6 R6
-131071 1/1/4
10.4.6.6
-------------------------------------------------------------------------------
Router R1 receives separate label mapping messages for prefix

10.10.10.6/32 from both of its peers (routers R2 and R3).
It must choose and populate one of them in the LFIB.
Module 3 |
44
Eventually router R1, which has the ingress LER role in this case study, receives two label bindings for prefix
10.10.10.6/32 from both of its peers. Router R1 writes both of these entries in the LIB.
Router R1 needs to select a next-hop router and label to install in the LFIB for data forwarding. This is explained on the
next page.
Module 3 Page 44
Label Bindings Received on router R1 (ingress LER)

===============================================================================
Prefix
Protocol
NextHop
------------------------------------------------------------------------------10.10.10.6/32
OSPF
10.1.2.2 (toR2) R2
===============================================================================
===============================================================================
Prefix
Op
IngLbl
EgrLbl
------------------------------------------------------------------------------10.10.10.6/32
Push
-131068
1/1/4
10.1.2.2
Module 3 |
45
As illustrated in the table above:

An egress label and egress interface must be chosen from among the two alternatives. Router R1 checks the FIB to
identify the IP next-hop for prefix 10.10.10.6/32.
Router R2 is the IP next-hop, so router R1 installs in its LFIB the label it received from router R2 as the active egress
label, also including the egress physical interface and next-hop IP address that it will use in data forwarding. The
unlabeled data packets coming in on router R1 have a label of 131068 pushed onto them and get forwarded on interface
1/1/4 towards router R2.
As indicated earlier, redundant entries in the LIB help to increase failure recovery times. For example, if the interface
between routers R1 and R2 goes down, router R1 can install in its LFIB the label it received from router R3 and forward
this traffic to router R3 immediately after IGP convergence. More aspects of LDP and network convergence are covered
in Module 6 Resiliency.
NOTE: Router R1 also has a Swap entry for prefix 10.10.10.6/32 in the LFIB, for cases where it is a transit LSR for
data traffic. This is not discussed here for the sake of a more straightforward example, and because the case study
focuses on where router R1 is the ingress LER specifically. Router R1 as a transit LSR is discussed later in this section.
Module 3 Page 45

===============================================================================
LDP Prefix Bindings
===============================================================================
Prefix
Peer
IngLbl
EgrLbl EgrIntf/
EgrNextHop
------------------------------------------------------------------------------10.10.10.6/32
10.10.10.2 R2
131066N
131068 1/1/4
10.1.2.2
10.10.10.6/32
10.10.10.3 R3
131066U
131067
---------------------------------------------------------------------------------

===============================================================================
Prefix
Op
IngLbl
EgrLbl
------------------------------------------------------------------------------10.10.10.6/32
Push
-131068
1/1/4
10.1.2.2
Module 3 |
46
After the label distribution is completed in the control plane, data traffic can be label switched using the constructed
label forwarding entries in the LFIB. This is actually a return to the data plane forwarding process presented in Modules
1 and 2, with LDP specific information.
Router R1 is the ingress LER for this case study. Therefore, the incoming data packets are labeled with an MPLS label
value of 131068 and forwarded on physical interface (port) 1/1/4 to next-hop 10.1.2.2 (router R2). This implies a
Push operation on router R1.
NOTE: There are two reasons why router R1 would choose to label switch the incoming data traffic with labels
negotiated by LDP, as opposed to using native IP forwarding. The first is that the ingress LER interface on which the
data traffic arrives is configured as an access interface, part of a VPN service provisioned on router R1. The VPN service
is then configured to use an LDP transport tunnel to get the packets across the network. The other reason is that MPLS
forwarding for IP traffic, also known as an LDP-shortcut feature, has been enabled on router R1.
The details of Alcatel-Lucent service implementation is covered in the SRC Services Architecture course.
The LDP-shortcut feature is covered in Module 5 of this course.
Module 3 Page 46
Data Plane Revisited Label Push Operation on router R1

===============================================================================
Prefix
Op
IngLbl
EgrLbl
------------------------------------------------------------------------------10.10.10.6/32
Swap 131068
131070
1/1/2
10.2.4.4
Module 3 |
47
The data traffic arriving from router R1 with an ingress label of 131068 is swapped on router R2 and transmitted with an
egress label of 131070 towards router R4. The LDP Label Forwarding Information Base (LFIB) is consulted, as seen in the
figure above, for this operation.
Module 3 Page 47
Data Plane Revisited Label Swap Operation on router R2

===============================================================================
Prefix
Op
IngLbl
EgrLbl
------------------------------------------------------------------------------10.10.10.6/32
Swap 131070
131071
1/1/4
10.4.6.6
Module 3 |
48
The data traffic arriving from router R2 with an ingress label of 131070 is swapped on router R4 and transmitted with an
egress label of 131071 towards router R6. The LDP Label Forwarding Information Base (LFIB) is consulted, as seen in the
figure above, for this operation.
Module 3 Page 48
Data Plane Revisited Label Swap Operation on router R4

===============================================================================
Prefix
Op
IngLbl
EgrLbl
------------------------------------------------------------------------------10.10.10.6/32
Pop 131071
----
Module 3 |
49
The data traffic arriving from router R4 with an ingress label of 131071 is popped on router R6.
The label that is popped is a transport (outer) label. Router R6 processes the remaining labels, if there are any, and
forwards the original data packet towards its destination, without any labels.
Module 3 Page 49
Data Plane Revisited Label Pop Operation on router R6

Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn
===============================================================================
Prefix
Peer
IngLbl
EgrLbl EgrIntf/
EgrNextHop
------------------------------------------------------------------------------10.10.10.1/32
10.10.10.2
131070U
---10.10.10.1/32
10.10.10.3
131070U
---10.10.10.2/32
10.10.10.2
-131071 1/1/4
10.1.2.2
10.10.10.2/32
10.10.10.3
131071U
131066
--10.10.10.3/32
10.10.10.2
131069U
131066
--10.10.10.3/32
10.10.10.3
-131071 1/1/3
10.1.3.3
10.10.10.4/32
10.10.10.2
131068N
131070 1/1/4
10.1.2.2
10.10.10.4/32
10.10.10.3
131068U
131069
--10.10.10.5/32
10.10.10.2
131067U
131069
--10.10.10.5/32
10.10.10.3
131067N
131068 1/1/3
10.1.3.3
10.10.10.6/32
10.10.10.2
131066N
131068 1/1/4
10.1.2.2
10.10.10.6/32
10.10.10.3
131066U
131067
---------------------------------------------------------------------------------
Router R1 has generated and advertised label 131066 to routers R2 and R3.
The entry for router R2 is marked as N (Not In Use), because router R2 is currently
the IGP next-hop for 10.10.10.6/32 (it cannot be an upstream neighbor).
The entry for router R3 is marked as U (In Use), because router R3 can become an
upstream neighbor if an IGP topology change affects it.
Module 3 |
50
The above slide illustrates the full LIB on router R1. Again, prefix 10.10.10.6/32 is used as an example.
As described earlier, as a result of the flooding behavior of LDP, routers distribute labels to all other peers, whether
they are on the IGP best path or not.
However, if a peer is on the IGP best path to reach a certain prefix, the label distributed to that peer is marked with an
N, indicating that the label is not in use. This means that the label is not activated because the peer is a downstream
router at the moment, and thus cannot be an upstream router at the same time.
This is the case shown in the figure above. Router R1 is using router R2 as the IGP next-hop to reach 10.10.10.6/32; that
is, router R2 is a downstream router to router R1. This means that router R2 is currently closer to the destination than
router R1. Under these topological constraints, router R2 will not attempt to use router R1 as a downstream router.
Hence, the label advertised to router R2 is marked with N Not In Use.
Why does router R1 advertise the label to router R2 if it will not be used? To speed up convergence and decrease
service downtime by reducing the amount of flooding required during a link failure that causes a topology change. If,
for example, router R2 lost all of its links, except the link between routers R1 and R2, it would have no choice but to go
through router R1 to reach router R6. In that case, router R2 would start using the label received from router R1
(131066) to send data traffic right away. (The symbol on router R1 would change to U then).
On the contrary, router R3 is not on the IGP best path to reach 10.10.10.6/32, so router R3 may use the label received
from router R1 at any given time. A possible scenario is explained on the next two pages.
Module 3 Page 50
Full LIB View on router R1 All Label Bindings

===============================================================================
Prefix
Op
IngLbl
EgrLbl
------------------------------------------------------------------------------10.10.10.1/32
Pop 131070
---10.10.10.2/32
Push
-131071
1/1/4
10.1.2.2
10.10.10.2/32
Swap 131071
131071
1/1/4
10.1.2.2
10.10.10.3/32
Push
-131071
1/1/3
10.1.3.3
10.10.10.3/32
Swap 131069
131071
1/1/3
10.1.3.3
10.10.10.4/32
Push
-131070
1/1/4
10.1.2.2
10.10.10.4/32
Swap 131068
131070
1/1/4
10.1.2.2
10.10.10.5/32
Push
-131068
1/1/3
10.1.3.3
10.10.10.5/32
Swap 131067
131068
1/1/3
10.1.3.3
10.10.10.6/32
Push
-131068
1/1/4
10.1.2.2
10.10.10.6/32
Swap 131066
131068
1/1/4
10.1.2.2
-------------------------------------------------------------------------------
Router R1 has also installed an entry with a swap action for when it
becomes a downstream router for any peer.
If a peer sets router R1 as the IGP next-hop, having this label
readily available in the LFIB will save time.
Module 3 |
51
The case study presented uses router R1 as the ingress LER for data traffic.
However, a peer may have to use router R1 as a downstream router when sending the traffic. In such a scenario, router
R1 already has a label distributed to its peers (131066), and a label action associated with it. An example is presented
on the next page, wherein router R1 becomes a downstream router for its peer and performs a label swap action.
After IGP convergence takes place, routers can immediately resume label switching the data traffic, without waiting for
label negotiation.
More information on IGP and MPLS convergence is covered in Module 6 of this course.
Module 3 Page 51
Full LFIB View on router R1 All Possibilities

------------------------------------------------------------------------------10.10.10.6/32
Swap 131066
131068
1/1/4
10.1.2.2
-------------------------------------------------------------------------------
Module 3 |
52
When router R3 is the ingress LER for data traffic destined to router R6:
The traffic path is router R3-R5-R6, when all links are operational, and assuming all link costs are equal.
If the link router R3-R5 fails, the traffic path is routers R3-R2-R4-R6.
If the R3-R2 link also fails, router R3 would have no option but to use the path shown above. Router R1 thus becomes a
downstream router for router R3, performing a label swap action.
After IGP convergence, router R3 starts pushing the label 131066, which is already available in the LIB. This is again a
result and an advantage of using liberal label retention.
Module 3 Page 52
Label Swap Action in the LFIB for router R1
A:R1# show router tunnel-table

===============================================================================
Destination
Owner Encap TunnelId Pref
Nexthop
Metric
------------------------------------------------------------------------------10.10.10.2/32
ldp
MPLS
9
10.1.2.2
100
10.10.10.3/32
ldp
MPLS
9
10.1.3.3
100
10.10.10.4/32
ldp
MPLS
9
10.1.2.2
200
10.10.10.5/32
ldp
MPLS
9
10.1.3.3
200
10.10.10.6/32
ldp
MPLS
9
10.1.2.2
300
===============================================================================
Module 3 |
53
To sum up, when LDP is enabled in the network, all routers generate a label binding for their own system IP address and
distribute to their peers by default. The distribution mode is downstream unsolicited, so a router does not need to wait
for an additional trigger, nor request the label mapping message from its peers.
The labels are flooded throughout the network and, eventually, all the routers have a Label Switched Path (transport
tunnel) to reach all the other routers. A full-mesh of tunnels is created.
In the example above, the show router tunnel-table command output displays the tunnels made available on
router R1, via LDP label negotiation. Assuming router R1 is always the ingress Label Edge Router, an LDP-made tunnel
exists towards all the other routers, represented by their system IP addresses. (The figure only shows the tunnels
initiated on router R1, for the sake of clarity.)
When using LDP, a router does not have an end-to-end view of a tunnel. As indicated with the LIB and LFIB outputs
earlier, an LDP router only knows the egress label and the next-hop router to reach the tunnel destination. The
consistent sequence of labels and their associated label actions from an ingress to an egress point constitute the tunnel.
When using LDP signaled transport tunnels, an LSP is merely a logical construct, not an actual end-to-end tunnel.
NOTE: The Pref (Preference) value is assigned internally by the router. For LDP based tunnels, this value is always set
to 9. For RSVP-TE based tunnels, it is set to 7. There is no configuration parameter to change this value and it is only
used in specific cases. For example, in a Layer 3 VPN (VPRN) service, multiple tunnel options exist to reach a certain
destination. If the router has to choose between tunnels offered by different protocols (LDP or RSVP-TE), it uses the
preference value. As with the IGP, the router prefers the lower numeric value over the higher.
Module 3 Page 53
End Result Full-Mesh of LDP Tunnels (router R1 as ingress LER)

===============================================================================
Destination
Nexthop
Metric
------------------------------------------------------------------------------10.10.10.1/32
ldp
MPLS
9
10.2.4.2
200
10.10.10.2/32
ldp
MPLS
9
10.2.4.2
100
10.10.10.3/32
ldp
MPLS
9
10.2.4.2
200
10.10.10.5/32
ldp
MPLS
9
10.4.5.5
100
10.10.10.6/32
ldp
MPLS
9
10.4.6.6
100
===============================================================================
Module 3 |
54
The show router tunnel-table command output above displays the tunnels available on router R4, assuming that
router R4 is the ingress point of those tunnels.
A similar view would be present on all the other routers, hence the full-mesh of LDP tunnels.
Note that the metric values in the tunnel table output correspond to the IGP metric value, which is yet another
indication of strong LDP-IGP dependence. Tunnels created by LDP label negotiation strictly follow the IGP determined
paths.
Module 3 Page 54
End Result Full-Mesh of LDP Tunnels (router R4 as ingress LER)
MPLS OAM Tools LSP-Ping
*A:R1# oam lsp-ping prefix 10.10.10.6/32

LSP-PING 10.10.10.6/32: 80 bytes MPLS payload
Seq=1, send from intf toR2, reply from 10.10.10.6
udp-data-len=32 ttl=255 rtt=3.59ms rc=3 (EgressRtr)
Used to validate the reachability of the prefix through the LDP

tunnel.
Unidirectional facility. Tests the LSP in one direction only.
Prefix keyword must be specified in the command.
Sends 1 packet only, by default. send-count option can be
used to send more in a single batch.
Module 3 |
55
The MPLS lsp-ping command is a commonly used troubleshooting tool and is part of the general OAM (Operational,
Administrational and Maintenance) toolkit provided to network operators.
The router where the command is executed is the ingress of the LDP tunnel. The router that owns the prefix specified
in the command is the egress of the LDP tunnel.
The LSP-Ping utility performs a unidirectional test; it checks the MPLS tunnel in a single direction only from the ingress
to the egress router. If the tunnel needs to be tested in the opposite direction as well, the command must be run on the
egress router, with the roles swapped.
The above slide illustrates the use of LSP-Ping facility.
It is important to specify the prefix keyword, otherwise the following warning message is displayed:
Send failed. The lsp-name does not exist.
This is because an LSP created via LDP does not have any name, and is represented by the destination prefix (FEC).
(Note: With RSVP-TE signaling, a name is given to LSPs, which is specified when using the lsp-ping command).
By default, the command sends a single request packet. It is also possible to send more test packets, as shown in the
following example:
*A:R1# oam lsp-ping "to_R6" send-count 3
LSP-PING to_R6: 92 bytes MPLS payload
Module 3 Page 55
---- LSP 10.10.10.6/32 PING Statistics ---1 packets sent, 1 packets received, 0.00% packet loss
round-trip min = 3.59ms, avg = 3.59ms, max = 3.59ms, stddev = 0.000ms
MPLS Echo Request packets are sent labeled (within the MPLS
tunnel).
Module 3 |
56
The LSP-Ping command uses MPLS Echo Request and MPLS Echo Reply packets.
The MPLS Echo Request packets are sent encapsulated within the MPLS labels that are signaled for the target prefix.
The TTL value in the outgoing packet is set to 255.
In the figure above, the MPLS Echo Request is forwarded all the way down to router R6, the egress router of prefix
10.10.10.6/32.
The MPLS Echo Request messages are sent over UDP with a destination port of 3503, and a source port value that router
R1 chooses arbitrarily.
The Echo Request message contains the target FEC (prefix) value that the egress router needs to check.
Module 3 Page 56
MPLS OAM Tools LSP-Ping: MPLS Echo Request
MPLS Echo Reply packets are sent unlabeled (IP-routed).
Module 3 |
57
Recall that LSP-Ping performs a unidirectional test on the MPLS tunnels.

For this reason, the egress router returns the MPLS Echo Reply packet without using any MPLS labels. The packet is IProuted, which means that the IP Forwarding Table is used to deliver the packet back to the ingress router.
The UDP packet has a source port equal to 3503 and a destination port value that is arbitrarily chosen by router R1
(opposite of the Request packet).
In the figure above, router R6 sends an MPLS echo reply in response to the MPLS echo request sent by router R1.
Two values were observed in the reply from router R6 in the example LSP-Ping command output presented in the
previous pages:
rtt=3.59ms rc=3 (EgressRtr)
RTT stands for Round Trip Time and is a measure of the total time delay between sending the echo request and
receiving the echo reply packet.
RC stands for Return Code and is used by the egress router to indicate the status of the prefix; that is, whether it is
under normal operational, or failure, conditions.
Router R6 has included a return code of 3, which indicates that it has learned that it is the Egress Router for this prefix,
which is expected.
Please refer to RFC 4379 for more information on MPLS return codes.
Module 3 Page 57
MPLS OAM Tools LSP-Ping: MPLS Echo Reply
MPLS OAM Tools LSP-Traceroute
*A:R1# oam lsp-trace prefix 10.10.10.6/32

lsp-trace to 10.10.10.6/32: 0 hops min, 0 hops max, 104 byte packets
10.10.10.2
10.10.10.4
10.10.10.6
rtt=1.63ms rc=8(DSRtrMatchLabel)
rtt=3.80ms rc=3(EgressRtr)
Used to gather hop information along the tunnels path.

Unidirectional facility; tests the LSP in one direction only.
Prefix keyword must be specified in the command.
Sends separate request packets per downstream router.
The MPLS TTL values are incremented at each request.
rc values indicate the return codes.
Module 3 |
58
The LSP-Traceroute utility also uses MPLS echo request and reply messages.
LSP-traceroute gathers hop information through the path of an LSP. The command is implemented using a special
solution involving the MPLS TTL values. This solution is explained in detail in the following slides.
Separate MPLS Echo Request messages are sent per downstream router.
Upon receipt of the MPLS echo request message, each downstream router checks the prefix in their label database and
responds accordingly.
The keyword rc in the command output above is the Return Code, as specified in RFC 4379.
There are 14 return codes defined in the RFC (values 0-13) that can indicate problem conditions, their root causes, or
proper operation.
LSP-traceroute facility is illustrated above. Two LSRs, routers R2 and R4, have returned a code of 8 (DSRtrMatchLabel),
meaning that they were able to find a downstream label mapping for the incoming label. On the last line, router R6 has
included a return code of 3 (EgressRtr), which means that it has found out that it is the egress point for this prefix (a
label pop action in its LFIB).
All of the above point to a proper, error-free LSP operation.
Module 3 Page 58
1
2
3
Router R1 sends MPLS Echo Request with MPLS TTL = 1

TTL expires on router R2 and the packet is analyzed on router R2.
Module 3 |
59
The LSP-Traceroute utility tests all the downstream routers to gather hop information along the path of an LSP by
sending separate MPLS Echo Request packets to each downstream router.
The TTL value of the outgoing packet is set to 1 in the first Echo Request packet that is sent out from router R1.
Router R2 receives the packet and decrements the TTL to 0. It then processes the rest of the packets contents in the
control plane.
Module 3 Page 59
LSP-Trace MPLS Echo Request to router R2
Router R2 sends back an MPLS Echo Reply.

The Echo Reply packet is IP-routed.
Module 3 |
60
Router R2 analyzes the Echo Request packet and checks the specified FEC in its label database. It finds an egress
(downstream) label mapping for prefix 10.10.10.6/32, which means that it is a transit router for the prefix.
Router R2 indicates this by setting the return code to 8 (DSRtrMatchLabel) in the MPLS Echo Reply packet that is
returned.
The Echo Reply packet is unlabeled and IP routed, as in the case of LSP-Ping.
Router R2 is not the egress router for prefix 10.10.10.6/32, so the LSP-Trace operation needs to continue.
Module 3 Page 60
LSP-Trace MPLS Echo Reply from router R2

Router R4 analyzes the request and sends back a reply.
Module 3 |
61
The MPLS TTL value is set to 2 in the next Echo Request packet.
Router R4 receives the packet and decrements the TTL to 0. Router R4 then processes the rest of the packets contents
in the control plane.
Router R4 analyzes the Echo Request packet and checks the mentioned FEC in its label database. It finds an egress
(downstream) label mapping for prefix 10.10.10.6/32, which means it is a transit router for the prefix.
Router R4 indicates this by setting the return code to 8 (DSRtrMatchLabel) in the MPLS Echo Reply packet that is
returned.
Router R4 is not the egress router for prefix 10.10.10.6/32, so the LSP-Trace operation needs to continue.
Module 3 Page 61
LSP-Trace MPLS Echo Request and Reply To and From R4

Router R6 analyzes the request and sends back a reply.
Module 3 |
62
The MPLS TTL value is set to 3 in the next Echo Request packet.
Router R6 receives the packet and decrements the TTL to 0. Router R6 processes the rest of the packets contents in
the control plane.
Router R6 analyzes the Echo Request packet and checks the specified FEC in its label database. It does not find any
egress (downstream) label mapping for prefix 10.10.10.6/32, which means it is the egress router for the prefix.
Router R6 indicates this by setting the return code to 3 (EgressRtr) in the MPLS Echo Reply packet that is returned.
Router R6 is the egress router for the prefix, so the LSP-Trace operation stops.
Module 3 Page 62
LSP-Trace MPLS Echo Request and Reply To and From Router R6
Section Summary

LDP Peer Discovery
LDP Session Establishment
LDP Label Distribution
LDP Transport Tunnel (LSP) creation
OAM LSP-Ping and LSP-Traceroute
Module 3 |
63
To sum up:
LDP Hello messages are exchanged between all directly connected and LDP enabled router pairs.
LDP Hello messages are sent over UDP port 646.
An LDP identifier is included in all the LDP messages.
An LDP-ID is a 6-byte field that identifies both the router and its label space uniquely in the LDP domain.
An LDP-ID consists of an LSR-ID (4 bytes) and a label space ID (2 bytes).
The LSR-ID is set to the system IP address, and the label space ID is set to 0 on the ALU Service Routers (per
platform label space).
The lower value for the hello timeout indicated in the hello messages is used by both peers.
Routers continue exchanging periodic hello messages after a successful discovery.
The router with the higher transport address initiates the LDP session to TCP port 646 of the peer by sending an LDP
Init message.
The lower value for the keepalive timeout indicated in the Init messages is used by both peers.
Routers continue to exchange periodic keepalive messages after a successful session establishment.
Labels are distributed in downstream unsolicited mode only for the system IP addresses in ordered control mode.
All received labels are kept in the Label Information Base (LIB) in liberal label retention mode.
The label received from the active IGP next-hop is used as the active label in the Label Forwarding Information
Base (LFIB) for data plane switching.
The path of a packet label switched through an LDP based tunnel to a certain destination is identical to the path of
a packet that is routed to that same destination via IGP decisions.
The OAM LSP-Ping and LSP-Traceroute commands are implemented using MPLS echo request and reply messages.
LSP-pings verifies the reachability of the destination prefix.
LSP-traceroute provides intermediate hop information.
Module 3 Page 63
LIB and LFIB Maintenance
Section 2 Additional LDP Features
Module 3 Page 64
Section Objectives
In this section we will introduce:

ECMP for LDP
LDP Export and Import Policy Implementation
Label Withdraw and Release Actions
Targeted LDP
LDP Authentication
Module 3 |
65
The fundamental principles of Link LDP operation were presented in the previous section.
In this section, additional topics related to LDP will be covered, including:
How to achieve MPLS traffic load balancing, using ECMP.
How to distribute label bindings for prefixes other than the system IP address, using export policies.
How to control the way label bindings are received from peers, using import policies.
How to resolve specific prefix FECs when a more general aggregate prefix is used in a multi-area IGP deployment.
How routers maintain the LIB and LFIB with additional label management actions; label withdraw and release
messages.
How to enable and configure targeted LDP sessions.
How to enable LDP authentication to harden the network security.
Module 3 Page 65
LDP aggregate-prefix-match feature
2 Paths are available from router R1 to router R6, with equal costs.
The IGP Shortest Path First (SPF) algorithm normally uses a tiebreaker rule to choose either router R2 or router R3 as next-hop (on
the ALU Service Router, this is the lowest next-hop IP address).
The LDP Tunnel to router R6 is also established on the IGP best path.
Module 3 |
66
Redundant paths can exist in the network between any traffic source and destination point.
When the total IGP cost to get from a particular source to a particular destination is the same for different paths, the
paths are referred to as Equal-Cost Multi-Path (ECMP).
In the example above, router R1 has 2 ECMP routes to reach router R6, with a path cost of 300.
The standard Shortest Path First (SPF) implementation dictates the selection of a single path to a destination.
Therefore, a tie-breaker rule is used in the case of multiple paths sharing the same total cost value.
On the ALU Service Routers, the tie-breaker rules state that the path with the lowest next-hop, directly connected
interface address be used as the active path on the data plane.
The LDP next-hop is also set to the selected IGP next-hop as a result of IGP dependence (explained in the previous
section).
Module 3 Page 66
Equal-Cost Multi-Path (ECMP)
LFIB on router R1 Without ECMP Enabled

===============================================================================
Prefix
Protocol
NextHop
------------------------------------------------------------------------------10.10.10.6/32
OSPF
10.1.2.2 (toR2) R2
===============================================================================
===============================================================================
Prefix
Op
IngLbl
EgrLbl
------------------------------------------------------------------------------10.10.10.6/32
Push
-131068
1/1/4
10.1.2.2
Module 3 |
67
The above slide illustrates the state of the LIB, FIB, and the LFIB tables without ECMP enabled on router R1. This is the
situation described in the previous section.
Router R2 is the IGP next-hop, as illustrated in the FIB, and the label from router R2 is used as the active egress label in
the LFIB.
Module 3 Page 67

===============================================================================
LDP Prefix Bindings
===============================================================================
Prefix
Peer
IngLbl
EgrLbl EgrIntf/
EgrNextHop
------------------------------------------------------------------------------10.10.10.6/32
10.10.10.2 R2
131066N
131068 1/1/4
10.1.2.2
10.10.10.6/32
10.10.10.3 R3
131066U
131067
---------------------------------------------------------------------------------
Without ECMP enabled, router R1 forwards all the incoming traffic

to router R2, on the IGP best path.
Other links in the network are not utilized; inefficient use of
resources.
Module 3 |
68
The figure above again illustrates the data forwarding path from router R1 to router R6 without ECMP enabled on router
R1.
Router R2 is the active IGP and LDP next-hop, and the traffic is being switched with the previously negotiated label
values on the path R1-R2-R4-R6. Assuming that there is 100 Mbps ingress data traffic, all this traffic travels over this
path.
The path R1-R3-R5-R6 is not currently utilized, even though all of the links on the path are physically available. From
the service providers perspective, this might be an inefficient or non-optimal use of network resources, which can have
negative implications concerning the return value of infrastructure investments and congestion control.
Module 3 Page 68
Data Forwarding Without ECMP Enabled
Enabling ECMP
Configured at a global level for all the applicable protocols (OSPF,

ISIS, RIP, LDP)
*A:R1# configure router ecmp ?
- ecmp <max-ecmp-routes>
- no ecmp
: [0..16]
A maximum of 16 ECMP routes can be configured.

All ECMP routes must have been learned from the same routing
protocol (same preference).
Multiple next-hops are installed in the Forwarding Table for the
same prefix, if the total end-to-end costs are equal.
LDP also installs multiple entries in the LFIB for the prefix with
different egress labels received from the ECMP peers.
Module 3 |
69
ECMP can be enabled to optimize the use of network resources in such scenarios.
When enabled, ECMP is applicable for all active IGP protocols (OSPF, IS-IS, RIP) as well as LDP.
(As a result of its limitations, RIP is not used in todays IP/MPLS networks. It is mentioned only for the sake of
completeness.)
The candidate paths, however, must be identical to be used for ECMP; they must have the same cost values as well as
the same preference values. Since the costs must be equal, all the ECMP routes must be offered by the same IGP
protocol.
By default, OSPF has a protocol preference of 10 and IS-IS has a preference of 15 (for Level-1 routes) and 18 (for Level-2
routes). It is possible to modify the default preference values, if required.
The route with the lower preference value is preferred.
NOTE: If OSPF and IS-IS are running at the same time, provide a common route, and are both configured to use the
same preference value by the administrator, the router chooses the OSPF route over the IS-IS based route, according to
the current Service Router implementation.
When ECMP is active, multiple next-hops can be installed in the FIB for IP Forwarding. As a result, LDP installs multiple
entries in the LFIB corresponding to the IP next-hops.
An example of the LIB, FIB, and LFIB tables is presented on the following slide.
Module 3 Page 69
<max-ecmp-routes>
LFIB on router R1 With ECMP Enabled

===============================================================================
Prefix
Protocol
NextHop
------------------------------------------------------------------------------10.10.10.6/32
OSPF
10.1.2.2 (toR2) R2
10.1.3.3 (toR3) R3
===============================================================================
===============================================================================
Prefix
Op
IngLbl
EgrLbl
------------------------------------------------------------------------------10.10.10.6/32
Push
-131068
1/1/4
10.1.2.2
10.10.10.6/32
Push
-131067
1/1/3
10.1.3.3
Module 3 |
70
When ECMP is enabled, the FIB contains 2 entries for prefix 10.10.10.6/32 with both routers R2 and R3 set as active IP
next-hops.
As with the FIB, 2 entries are present in the LFIB with Push actions, as displayed in the show router ldp
bindings active command output.
Module 3 Page 70

===============================================================================
Prefix
Peer
IngLbl
EgrLbl EgrIntf/
EgrNextHop
------------------------------------------------------------------------------10.10.10.6/32
10.10.10.2 R2
131067N
131068 1/1/4
10.1.2.2
10.10.10.6/32
10.10.10.3 R3
131067N
131067 1/1/3
10.1.3.3
-------------------------------------------------------------------------------
Since the routers use liberal label retention, router R1s LIB already
contains two labels, one each received from routers R2 and R3.
When ECMP is enabled, router R1 installs two forwarding entries in
the FIB and the LFIB.
An internal hashing algorithm distributes the traffic flows across the
two links in a load balancing fashion.
Module 3 |
71
After ECMP is enabled, router R1s LFIB contains 2 active egress labels to reach router R6, received from routers R2 and
R3. Router R1 can now distribute the incoming traffic flows over the 2 active links by encapsulating every flow with a
label received from either router R2 or router R3.
Traffic flow can be loosely defined as the data activity between a source and destination pair. Several criteria can be
used to define the source and destination, depending on the application and point of reference.
Traffic arriving at an ingress LER might be:
Traffic from an IP source address to an IP destination address.
Traffic from an IP source and TCP/UDP source port to an IP address and TCP/UDP destination port.
For traffic arriving at an LSR:
Traffic coming in on a port with certain MPLS label stack values.
An internal hashing algorithm, on a per-flow basis, chooses the link on which the iLER will forward incoming data
traffic. This depends on the MPLS configuration as well as the type of traffic and certain flow characteristics, as
mentioned above.
NOTE: SR OS does not implement per-packet load balancing. Sending packets from the same flow over different links
can cause sequencing problems at the eLER, since the links can experience different delay characteristics. In this case,
packets arrive out of order, causing delay, jitter, and packet loss.
Module 3 Page 71
Data Forwarding With ECMP Enabled
Module 3 |
72
LAB 3 Section 3.3 Enabling LDP ECMP
Module 3 Page 72
ALU Service Routers distribute a label for their system IP addresses

only, by default.
An export policy can be used to distribute labels for other local
prefixes, if needed.
Local prefixes can belong to directly connected interfaces or can
be loopback interfaces.
Module 3 |
73
Recall that a router generates and distributes a label binding for its system IP address only.
However, if desired, it is possible for the router to generate and distribute a label for its local prefixes.
A local prefix is a prefix that is owned by the router itself, an interface that is configured directly on the router
under consideration. It can be an interface directly connected to another router, or an interface that is set to operate
in loopback mode, much like the system interface, which is the default loopback interface.
Additional local prefixes are distributed by configuring and applying an export policy for LDP, a process that is
explained in the following pages.
Module 3 Page 73
Distributing Additional Prefixes via Export Policy
Configuring and Verifying Loopback Interfaces

Configure the interfaces
Verify the prefixes in the local FIB

=========================================
Prefix
Protocol
NextHop
----------------------------------------...............
......
192.168.6.1/32
LOCAL
192.168.6.1 (LP1)
192.168.6.2/32
LOCAL
192.168.6.2 (LP2)
Module 3 |
74
The configuration snapshots above illustrate how to configure and verify new loopback interfaces.
An interface needs to have either a physical port or the loopback keyword specified, as well as an IP address/prefix
length, to become operational.
Interfaces that are configured to establish IP connectivity to other routers/systems have a physical port configured for
them.
Interfaces that are not used to connect to other routers/systems, but that are required to remain IP interfaces that are
up and reachable as long as the router itself is functional, are called loopback interfaces. Loopback interfaces are
configured with the loopback keyword.
The only exception to the rule is the system IP address, which is the default loopback interface, as was explained in the
first section. The system IP address only needs a configured IP address to become operational. The loopback keyword is
not required and is implied for the system interface.
NOTE: The example here illustrates the distribution of labels for loopback interface IP prefixes, but the same procedure
can be applied to non-loopback, directly connected interfaces as well.
Module 3 Page 74
A:R6>config>router#
-------------------------------interface LP1"
address 192.168.6.1/32
loopback
exit
interface LP2"
address 192.168.6.2/32
loopback
exit
Configuring a Policy To Distribute Additional Prefixes
*A:R6>configure router ldp export "LDP_export"
Enter edit mode

Arbitrary prefix-list name
List (range) of prefixes to be matched
Arbitrary policy name
List of statements to be used
as a match condition
Distribute the matched prefixes
(in relation to the export function)
Exit edit mode
(make the changes effective)
Apply the policy to LDP
as an export policy
Module 3 |
75
Policies are administrative entities or templates that allow the administrator to impose additional controls over the way
the router functionalities or protocols operate. Policies are often used to override the default behavior of certain
protocols and perform additional tasks.
An example policy configuration is shown above. On the Alcatel-Lucent Service Routers, all of the policy-related
configurations are done in the configure router policy-options CLI context, regardless of which protocol or
feature the policy needs.
In the policy-options context, the operator first issues the begin command to enter policy edit mode; this opens the
policy editing application enabling policy modifications. Any new or existing changes become effective only upon once
the operator issues a commit command, ending the editing session and saving the changes.
A policy is defined with the policy-statement command, followed by the choice of an arbitrary name. The policy
names, however, are restricted to a maximum of 32 characters. If the name contains space characters, you must
enclose the entire name with double quotation marks (" ").
A policy can contain multiple entries that specify match conditions, and the action to be executed in case of a
match. These conditions can differ, depending on the protocol on which the policy will be applied and the purpose of
the policy. The entries are sequenced, meaning they are given numbers ranging from 1 to 4,294,967,295. In turn,
entries are evaluated in sequential order, starting from the lowest numerical value.
In terms of the given example, the purpose of the policy is to generate and distribute label bindings for the newly
created loopback addresses that override the default behavior of LDP, which only works for the system IP address.
To accomplish this, a prefix list that contains the statement 192.168.6.0/24 longer is created and arbitrarily
named (loopbacks in this example). The longer keyword provides for a more general statement, saving the operator
from having to specify the prefixes individually, as prefix 192.168.6.1/32 exact and prefix 192.168.6.2/32 exact.
If high-precision is required for prefixes to advertise in the subnet, the latter statements may be preferred. If even
lower-precision is required, the from protocol direct statement can be used to redistribute all the directly connected
(local) prefixes.
It is important to remember that a policy needs to be applied under the relevant protocol to become functional.
Module 3 Page 75
*A:R6>configure router policy-options

begin
prefix-list "loopbacks"
prefix 192.168.6.0/24 longer
exit
policy-statement "LDP_export"
entry 10
from
exit
action accept
exit
exit
exit
commit
*A:R6>config>router>policy-options#
---------------------------------------------3 prefix-list "loopbacks"
prefix 192.168.6.0/24 longer
exit
1 policy-statement "LDP_export"
entry 10
from
2
exit
5 action accept
exit
exit
exit
----------------------------------------------

=========================================
Prefix
Protocol
NextHop
----------------------------------------10.1.2.0/24
OSPF
10.4.6.4 (toR4)
10.1.3.0/24
OSPF
10.5.6.5 (toR5)
...........
....
...........
192.168.6.1/32
LOCAL
192.168.6.1 (LP1)
4
192.168.6.2/32
LOCAL
192.168.6.2 (LP2)

===============================================================================
Prefix
Peer
IngLbl
EgrLbl EgrIntf/
EgrNextHop
------------------------------------------------------------------------------192.168.6.1/32
10.10.10.4
131065
131065
--192.168.6.1/32
10.10.10.5
131065
131065
--192.168.6.2/32
10.10.10.4
131064
131064
--192.168.6.2/32
10.10.10.5
131064
131064
---
Module 3 |
76
The SR OS executes the label distribution policy, used for distributing labels for the additionally configured loopback
interfaces, as follows:
NOTE: We assume that loopback interfaces are already configured and the policy has been applied under the LDP
context.
1.
The router begins the policy execution process with the lowest numbered entry, number 10.
2.
Entry 10 includes a from statement. This indicates that the router will process a match on the contents of the
prefix-list called loopbacks.
3.
The router evaluates prefix-list loopbacks. This list states that any available prefix within the 192.168.6.0/24
subnet is a valid match condition.
4.
The router then scans the forwarding table entries locate the any matching prefixes. In this instance, the router
finds two matches with prefixes 192.168.6.1/32 and 192.168.6.2/32. These belong to the configured loopback
interfaces.
The router will only match on prefixes actively available in the FIB. For example, if a loopback interface is
administratively shutdown, the route table manager (RTM) does not include this prefix in the FIB. The router will
not match on the inactive prefix.
5.
The router checks the policys action statement in the policy to determine what action will be performed on
the matched prefixes. This example sets the action to accept, which means generate label bindings for valid
matches and distribute the labels to all active LDP peers.
6.
A LIB check shows the desired outcome: For prefix 192.168.6.1/32, router R6 generates label 131065 and
distributes it to both routers R4 and R5. Similarly, for prefix 192.168.6.2/32, router R6 generates label 131064
and distributes that label to both peers.
NOTE: The peers will signal labels back to router R6 for these same prefixes. In this example, we gray out the
Egress Label column for the sake of clarity.
7.
There are no more entries to be executed in the policy, so the process can be concluded.
Module 3 Page 76
Policy Execution Methodology
ALU Service Routers accept all label bindings received from peers,
by default.
An import policy can be used to reject certain label bindings upon
receipt.
In practice, the router still keeps the received labels, but does not
generate and distribute its own bindings to other peers.
Module 3 |
77
On the receiving end, the default behavior of Alcatel-Lucent Service Routers is to accept all label bindings received
from peers. The receiving router, in turn, generates its own label bindings for the prefixes and forwards them to other
peers.
It is possible, however, to use an import policy to prevent a selection, or all, of the received label bindings from being
further processed by the router, for administrative reasons. An example of these reasons is to prevent potential label
flooding when interoperating with a router under a different administration.
As illustrated in the following pages, the router still stores the received label bindings from the peers in the LIB, but
does not install them in the LFIB or propagate the message any further.
Module 3 Page 77
Rejecting Prefixes via Import Policy
Configuring a Policy To Reject All Prefixes
*A:R6>configure router ldp import "LDP_import"
Enter edit mode

Arbitrary policy name
Implicit <match any>
Exit edit mode

(make the changes effective)
Apply the policy to LDP

as an import policy
Module 3 |
78
An LDP import policy is illustrated above.

The general principles of policy implementation have been explained in the previous export policy example. The
specific purpose in this example is to completely override the default behavior of LDP in the receiving direction.
The default behavior states that all label bindings distributed by peers are accepted and processed for further
propagation. If the from statement is not specified, any or all received label bindings for prefixes may provide a
valid match condition.
The action is set to reject to reverse this default LDP behavior.
You must apply the configured policy under the LDP context as an import policy to bring it into effect.
Module 3 Page 78
*A:R6>configure router policy-options

begin
policy-statement "LDP_import"
entry 10
<no from statement>
action reject
exit
exit
commit
LFIB After Applying the Import Policy on router R4
After applying the import policy, all forwarding entries, except the
system IP address of router R4 itself, are removed from the LFIB,.
The entry for 10.10.10.4/32 is not a received, but a locally
generated label binding; therefore, it remains.
Module 3 |
79
The impact of the import policy is even more evident in the LFIB output.
All the forwarding entries have disappeared, except the one for the system IP address for router R4 itself.
Router R4 will only accept traffic arriving on an LDP tunnel on which its system interface IP is the target FEC, looking
for the ingress label 131071.
Module 3 Page 79

===============================================================================
===============================================================================
Prefix
Op
IngLbl
EgrLbl
------------------------------------------------------------------------------10.10.10.4/32
Pop 131071
---------------------------------------------------------------------------------No. of Prefix Bindings: 1
An LDP router issues a label withdraw message to instruct its peers

to remove a label binding that was previously distributed.
Upon receipt of a label withdraw message, the receiving router
responds with a label release message, which acts as an
acknowledgment mechanism.
Module 3 |
80
In the example above, the router no longer can forward traffic to the prefix 192.168.6.1/32, a prefix for which it had
earlier distributed a label binding via an LDP export policy. Any condition which would cause a router to remove a
prefix from its FIB would cause the withdrawal message, such as a failed link or shut down interface. Additionally,
removing an applied export policy from the LDP context can cause a router to send a label withdraw message to its
peer(s). A Label Release message is sent in this case by the receiving peer, which acknowledges the receipt and
withdrawal of the label.
The label for a given FEC may be withdrawn, and as a result invalidated, if:
An MTU change on the interface causes a router to withdrawal the previously assigned label and re-signal the FEC
with the new MTU.
A network change, such as a failed interface, causes the router to remove a FEC from its FIB. The router had
previously generated and advertised a label for this FEC.
The router is configured to stop generating labels for specified FECs (for example, the removal of the export
policy).
A service manager command is issued to clear the labels, the labels are withdrawn, and new label mappings are
issued (for example, clear router ldp instance).
An LDP Label Release message may be generated if:
The LSR receives a label withdraw message from a peer.
The LSR operates in Conservative label retention mode, and receives a label from a peer that is not the next-hop
router for the FEC.
The LSR operates in Conservative label retention mode, and the peer from whom it received the label for a FEC is
no longer the next-hop router for that FEC (for example, the result of a network failure or topological change).
There is no more memory to store a received label and the label is released.
Module 3 Page 80
Label Withdraw and Release Messages
-------------------------------area 0.0.0.1
interface system
exit
interface toR4
exit
interface LP1
exit
interface LP2
exit
exit
-------------------------------area 0.0.0.0
interface system
exit
interface toR2
exit
area 0.0.0.1
area-range 192.168.6.0/24
interface toR6
exit
Module 3 |
81
A large IGP domain can be split into several areas to increase scalability.
To further benefit from the area design, route aggregation (summarization) can be enabled on the Area Border Routers
(ABR) to reduce the number of prefixes that are advertised and stored by the routers.
In the above example, router R4 is an OSPF Area Border Router that connects Area 0 and Area 1.
Router R6 advertises both of its prefixes 192.168.6.1/32 and 192.168.6.2/32 to router R4 via OSPF.
Route summarization occurs on router R4, and router R4 advertises a single aggregate prefix 192.168.6.0/24, as a result
of the area-range command.
Router R6 distributes 2 separate label bindings for its prefixes 192.168.6.1/32 and 192.168.6.2/32 to router R4. Router
R4 generates its own label bindings for these prefixes and again distributes 2 separate label bindings to router R2.
NOTE: In practice, Area 1 can contain many routers advertising specific prefixes within the aggregated 192.168.6.0/24
network, or even a larger network or networks. In such a case, aggregation would be beneficial to database and route
table optimization.
Module 3 Page 81
Multi-Area IGP with Route Aggregation (Summarization)

=========================================
Prefix
Protocol
NextHop
----------------------------------------...............
......
192.168.6.0/24
OSPF
10.2.4.4 (toR4)

Prefix
Peer
IngLbl
EgrLbl
===================================================
192.168.6.1/32
10.10.10.4
-131065
192.168.6.2/32
10.10.10.4
-131064

Prefix
Op
IngLbl
EgrLbl
=============================================
LDP needs an exact match in the FIB
<NO entries for 192.168.6.1/32

& 192.168.6.2/32>
Module 3 |
82
Router R2 has received a single aggregate prefix of 192.168.6.0/24 via OSPF, as indicated in the FIB output.
Router R2 has also received 2 separate label bindings for prefixes 192.168.6.1/32 and 192.168.6.2/32, as indicated in
the LFIB output (show router ldp bindings).
To be able to resolve these LDP prefixes and install forwarding entries in the LFIB, router R2 looks for an exact match
for both of the prefixes in the FIB, by default.
Exact matches for the /32 prefixes do not exist in the FIB, so no entries are installed in the LFIB (show router ldp
bindings active). A possible solution to this problem is introduced in the next page.
Module 3 Page 82
The Need for LDP Exact Prefix Match
LDP Aggregate Prefix Match Feature

=========================================
Prefix
Protocol
NextHop
----------------------------------------...............
......
192.168.6.0/24
OSPF
10.2.4.4 (toR4)

Prefix
Op
IngLbl
EgrLbl
=============================================
192.168.6.1/32
Push
-131065
192.168.6.1/32
Swap 131064
131065
192.168.6.2/32
Push
-131064
192.168.6.2/32
Swap 131063
131064
Aggregate prefixes increase scalability by reducing the topology

database and route table sizes in large multi-area IGP
deployments.
The aggregate-prefix-match feature allows the more specific LDP
prefixes to be resolved by an aggregate prefix in the FIB, and
overrides the default exact prefix match rule.
Module 3 |
83
The configure router ldp aggregate-prefix-match command can be used to allow the router to resolve the
specific LDP advertised prefixes to the FIBs aggregate prefix entry.
As illustrated above, the label forwarding entries are installed into the LFIB of router R2.
This is a useful feature in very large, hierarchical network deployments where route aggregation is required.
Module 3 Page 83
*A:R2>configure router ldp aggregate-prefix-match
Module 3 |
84
LAB 3 Section 3.4 Applying Export Policy for Label Distribution
Module 3 Page 84
Link LDP is used to establish transport tunnels.

y iLER uses the transport tunnel to reach the eLER.
Targeted LDP is used to establish service tunnels.
y eLER uses the service tunnel for service de-multiplexing.
Module 3 |
85
Module 1 explained that an IP/MPLS network can be used to consolidate various types of services and applications. An
important portion of these applications is MPLS-enabled business VPN services. With MPLS VPN services, enterprise
customers may interconnect their various sites over the common service provider infrastructure, while enjoying the full
benefits of the MPLS technology, like security, privacy, cost-efficiency, and high reliability. The service instances that
belong to the same customer are virtually interconnected by separate service tunnels. This provides isolation between
the traffic from different customers.
SR OS routers use two LDP versions, Link LDP and Targeted LDP (T-LDP). We use Link LDP to establish transport tunnels
in the network that label switch traffic through the core, in a manner that is transparent to the core routers.
Alternately, we use T-LDP to signal service labels and establish service tunnels for Layer 2 VPN services, such as VLL and
VPLS.
Service tunnels tunnel VPN traffic through the MPLS core from PE router to PE router; these service tunnels depend on
MPLS transport tunnels for reliable, edge-to-edge traffic transport. To improve scalability in the core and provide data
transparency for P or MPLS core routers, service tunnels are carried inside the same transport tunnels. The edge routers
use T-LDP to signal service labels associated with the service tunnels, and the PE routers use these service labels to
identify a particular VPNs traffic.
The MPLS VPN solution implements a 2-label stack; the outer label is the transport label and the inner label is the
service label. The Label Switching Routers (LSR) only process the outer labels and are not service-aware. The service
labels are inserted by the ingress LER and used by the egress LER to demultiplex the traffic coming in on different
service tunnels and direct them to their respective service instances. These stacked labels allow the PE routers to
aggregate traffic for multiple VPN services in a single set of MPLS transport tunnels .
Module 3 Page 85
The Requirement for Targeted LDP
Used to exchange service labels for Layer 2 Services (VLL, VPLS).

Used independently from its Link LDP counterpart.
Peers do not have to be directly connected (typically established
between 2 PE routers that have services configured)
Also used in the LDP over RSVP solution (covered in Module 5).
Module 3 |
86
Link LDP and T-LDP have specific purposes; Link LDP forms adjacencies between directly connected peers, supporting
hop-by-hop transport tunnels, where T-LDP forms adjacencies between indirectly connected peers, such as when
multiple P routers separate the two PE routers. Link LDP signals tunnel labels; T-LDP signals service labels.
Additionally, a VPN does not have to use Link LDP tunnels, as it can be configured to use RSVP-TE based transport
tunnels, as well. T-LDP may run without LDP enabled on the individual interfaces.
For a Layer 2 VPN service, the following combinations are possible when implementing the service:
Transport Tunnel LDP and Service Tunnel Targeted-LDP
Transport Tunnel RSVP-TE and Service Tunnel Targeted-LDP
Transport Tunnel LDP and Service Tunnel Static via static label configuration
Transport Tunnel RSVP-TE and Service Tunnel Static via static label configuration
For a Layer 3 (IP) VPN Service, the service labels are signaled via the MP-BGP (Multi-Protocol Border Gateway Protocol).
Targeted LDP is not utilized in pure Layer 3 VPN service environments.
NOTE: Transport Tunnels can also be established via Static LSP configurations. Static configurations are not covered in
this course; they are not preferred solutions because of their lack of reliability, scalability, and the administrative
complexity involved.
The primary purpose of Targeted LDP is to signal service labels for Layer 2 services. Services are configured on PE
routers, which are typically located at the edges or on the boundaries of the IP/MPLS network. For this reason,
Targeted LDP is designed to be able to also run between non-directly connected routers, unlike Link LDP.
Module 3 Page 86
Targeted LDP (T-LDP) Overview
Process is similar to Link LDP.

The difference is that the UDP discovery (hello) messages are sent
via unicast.
Module 3 |
87
The operation of Targeted LDP is very similar to Link LDP.

Hello messages are exchanged for peer discovery and, later, used as a heartbeat mechanism to maintain the adjacency.
Init messages are exchanged to establish the session.
Keepalive messages are periodically exchanged after a successful session establishment.
The only difference is that the Hello messages are sent via UDP unicast, and not multicast, toward the system IP
address of the peer device, since the peer can be located multiple hops away.
Label management is accomplished via label mapping, advertisement, or release messages over the established
Targeted LDP sessions for the configured Layer 2 services.
Module 3 Page 87
Targeted LDP Operation
Enabling Targeted LDP
When the LDP process is enabled on a router, T-LDP is also enabled

by default (it is sufficient to type configure router ldp to
enable the process).
*A:R4# show router status

=================================================================
Router Status (Router: Base)
=================================================================
Admin State
Oper State
----------------------------------------------------------------Router
Up
Up
OSPFv2-0
Up
Up
.........
..
..
MPLS
Not configured
Not configured
RSVP
Not configured
Not configured
LDP
Up
Up
.........
..
..
Module 3 |
88
Protocols are enabled on the service router by enabling contexts that activate the internal processes needed to run
the protocols.
The command configure router ldp enables the routers LDP processes, both Link LDP and T-LDP. You can verify
this with the show router status command, as shown above.
At this point, only the LDP process is enabled on the local router; no peer relationships exist. The required peer
configurations are explained on the following pages.
NOTE: In the SR OS CLI, the terms LDP and MPLS represent separate contexts, not protocols; in fact MPLS is not a
protocol at all. While LDP is an MPLS label signaling protocol, enabling LDP will not enable features configured under
the MPLS context; the MPLS context relies on the RSVP context, another MPLS signaling protocol.
Nonetheless, LDP does enable MPLS functionality configured under the LDP context, such as T-LDP. LDP configuration
occurs inside the configure router ldp context. Sections 4, 5, and 6 clarify the differences between the LDP and
the MPLS and RSVP contexts.
In short, the use of the LDP and MPLS contexts are independent of each other. LDP can operate without the MPLS
context enabled.
Module 3 Page 88
The show router status command can be used to see a

snapshot of the main processes (protocols) running on the router.
Disabling Targeted LDP
*A:R4>config>router>ldp#
---------------------------------------------interface-parameters
interface "toR6"
Link LDP sub-context
exit
exit
targeted-session
disable-targeted-session
Targeted LDP sub-context
exit
----------------------------------------------
With the configuration above, Link LDP is still active. Only the
targeted sessions are disabled.
The default is: no disable-targeted-session (targeted sessions are
enabled when LDP is enabled).
Module 3 |
89
Two separate sub-contexts are available within the main configure router ldp context for Link LDP and Targeted
LDP configurations.
The interface-parameters sub-context carries out Link LDP configurations, as was explained in Section 1 of this module.
Configure T-LDP under the targeted-session sub-context.
If you wish to completely disable targeted sessions on a router while maintaining Link LDP functionality, the disabletargeted-session command may be used. You might disable targeted sessions if building Layer 3 VPNs or statically
assigning service labels. L3 VPNs signal service labels using MP-BGP, while statically assigned service labels can be used
for mirror services.
The default mode of this command is no disable-targeted-session, which means that targeted session are
enabled, as can be verified by the info detail command output.
Module 3 Page 89
A separate CLI knob exists to completely disable targeted sessions

on a Service Router.
Configuring Targeted LDP Sessions

Two methods to configure T-LDP sessions are:
y Automatic - Using ALU Service Routers, T-LDP sessions are
automatically created via Service Distribution Path (SDP)
configurations, by default.
---------------------------------------------interface-parameters
interface "toR6"
exit
exit
targeted-session
peer 10.10.10.6
exit
exit
----------------------------------------------
Both sides of the T-LDP peering must be configured properly for the
session to be established.
Module 3 |
90
Upon enabling the LDP context, no targeted sessions exist by default on the router.
On the Alcatel-Lucent Service Routers, there are 2 ways that a Targeted LDP session may be created:
1. The automatic method: This requires no explicit peer configuration. If in the configure service sdp context
you configure a Service Distribution Path (SDP) to use the default T-LDP signaling, the router first determines
whether a T-LDP session to the specified peer in the SDP configuration already exists. If it exists, another session
will not be attempted, since a single session between the two routers is sufficient. If a T-LDP session does not
exist, the router will automatically attempt to establish one to the specified peer.
NOTE: The implementation and configuration details of SDPs is beyond the scope of this course. Interested readers
may refer to the SRC Services Architecture course, or the Service Router product manuals and configuration notes
dedicated to services, for more information.
2. The manual method: Peers can also be specified with their system IP addresses via explicit configuration, as seen in
the example above. Both sides of the peering must configured to be able to bring up the T-LDP session.
Among the reasons why the network operator might want to use the manual, instead of the automatic, method are:
The operator may want to modify the session parameters (such as hello or keepalive timeout) from the default
values (see the example on the next page).
The operator may want to avoid peering with certain routers, probably those under a different administration (see
the example on the next page).
The targeted LDP session might be required for a special feature called LDP over RSVP-TE (discussed in Module 5 of
this course).
The targeted LDP session might have to be manually specified for interoperability reasons, if required by another
router vendor.
Module 3 Page 90
y Manual - Configured explicitly by the administrator:
Modifying Peer Parameters
(global settings)
UDP Hello Timeout & Factor
TCP Session Keepalive
Timeout & Factor
The more specific per-peer settings override the default settings.

If peering with a router is not desired, it can be administratively
disabled.
Module 3 |
91
As discussed on the previous page, an operator might want to modify the session parameters for a peer from the default
values.
In the example above, the default timeout and factor values for hello and keepalive messages apply to all peers,
regardless of whether they were created using the automatic or the manual method.
Different hello and keepalive parameters are required for peer 10.10.10.6. This is why the peer is explicitly specified
with the override settings.
The operator wants to avoid Targeted LDP peering with the address 10.10.10.5. For this reason, the peer is explicitly
specified and administratively shutdown to avoid a T-LDP session from being established.
Module 3 Page 91
-------------------------------------------interface-parameters
.........
exit
targeted-session
hello 45 3
keepalive 40 4
peer 10.10.10.6
hello 15 3
keepalive 30 3
exit
peer 10.10.10.5
shutdown
exit
exit
--------------------------------------------
Verifying Targeted LDP Sessions
*A:R1# show router ldp session

==============================================================================
Peer LDP Id
Adj Type
State
-----------------------------------------------------------------------------10.10.10.2:0
Link
Established
12179
12227
0d 09:22:55
10.10.10.3:0
Link
Established
12465
12502
0d 09:36:09
10.10.10.6:0
Targeted
Established
5
6
0d 00:00:07
-----------------------------------------------------------------------------No. of Sessions: 3
*A:R1# show router ldp status
==============================================================================
LDP Status for LSR ID 10.10.10.1
-----------------------------------------------------------------------------Admin State
: Up
Oper State
: Up
Active Adjacencies : 3
Active Sessions
: 3
Active Interfaces : 2
Inactive Interfaces : 0
Active Peers
: 1
Inactive Peers
: 0
Module 3 |
92
The CLI output above illustrates some of the several show commands that can be used to access information regarding
targeted sessions.
The show router ldp peer command output displays information per each targeted peer along with its hello and
keepalive parameters. If a peer is set to operate in passive mode, it will only accept incoming session requests, and will
not assume an active role. The No keyword in the Auto created column indicates that the peer has been manually
defined.
Note that the peer status can be Up, even if the session is not. This just indicates that a peer has been configured, and
that the router is at least trying to bring up the session with the other peer (if it is not configured in passive mode). Both
peers need to be configured properly for the session to be established.
The show router ldp session command output displays the status of the LDP peers.
The keyword established indicates the session is currently up and running at the moment.
If only a Link LDP session is established with a peer, the link adjacency type is displayed as Link
If only a Targeted LDP session is established with a peer, the link adjacency type is displayed as Targeted.
If both Link LDP and Targeted LDP sessions are established with a peer at the same time, the link adjacency is
displayed as Both.
The show router ldp status command output displays the general statistics regarding the LDP process.
Active Adjacencies indicates successfully discovered Link LDP and Targeted LDP peers (via Hello messages).
Active Sessions indicates successfully established Link LDP and Targeted LDP sessions (via Init and Keepalive
messages).
Active Interfaces indicates the number of core interfaces on which Link LDP is enabled.
Active Peers indicates the number of active Targeted LDP peers that are provisioned via either manual or automatic
methods.
Again, note that a session does not need to be established for a peer to be listed.
Module 3 Page 92
*A:R1# show router ldp peer

===============================================================================
Peer
Adm Opr Hello
Hold
KA
KA
Passive
Auto
Factor Time
Factor Timeout Mode
Created
------------------------------------------------------------------------------10.10.10.6
Up
Up
3
45
4
40
Disabled No
-------------------------------------------------------------------------------
LDP Authentication
---------------------------------------peer-parameters
peer 10.10.10.1
authentication-key Secret
exit
exit
Authentication can be enabled to protect LDP against TCP spoofing

attacks.
The same authentication key must be configured on both peers.
An MD5 digest is added to all TCP segments, calculated using the
configured secret for each segment.
Module 3 |
93
LDP sessions are established over the TCP transport layer. A malicious user may try to attack these sessions by sending
spoofed TCP segments. Message Digest 5 (MD5) authentication can guard against such attacks.
When enabled, the MD5 authentication algorithm adds a signature to each TCP segment, also known as an MD5 digest.
The MD5 password (Secret in the above example) is used to calculate a unique MD5 digest for each TCP segment and
is never transmitted to the other end in clear text format. The receiving end verifies the MD5 digest by using its locally
configured MD5 password. If the verification is not successful, the received TCP segment is dropped.
The configured authentication key is also not displayed in clear text form in the configuration outputs.
It rather appears in hashed format, as seen in the example below:
*A:R1>config>router>ldp# info
---------------------------------------------peer-parameters
peer 10.10.10.2
authentication-key "7ZooHlzw8OE8Hs6IKYJ1kiES27LcfN23" hash2
exit
exit
Module 3 Page 93
---------------------------------------peer-parameters
peer 10.10.10.2
authentication-key Secret
exit
exit
LDP Message Types Reference Table

Name
Notification
Function
Signals errors and other events
0x0100
Hello
Announces the presence of an LSR
0x0200
Initialization
Starts the session establishment process
0x0201
KeepAlive
Monitors the integrity of the LDP session transport connection
0x0300
Address
Advertises the interface addresses to an LDP peer
0x0301
Address Withdraw
Withdraws a previously advertised interface address
0x0400
Label Mapping
Advertises a FEC-label binding to an LDP peer
0x0401
Label Request
Requests a FEC-label binding from an LDP peer
0x0402
Label Withdraw
Requests the peer remove from its LIB a previously signaled label
0x0403
Label Release
Signals the peer that the LSR no longer needs specific FEC-label
mappings previously requested of and/or advertised by the peer
0x0404
Label Abort Request
Aborts an outstanding Label Request message
0x3E00 0x3EFF
Vendor Private
Conveys vendor-private information between LSRs
0x3F00 0x3FFF
Experimental
LDP Experimental Extensions undefined uses
Module 3 |
94
Type
0x0001
The table above provides a list of all the supported LDP messages.
Module 3 Page 94
Section Summary

y ECMP for LDP
y LDP Export and Import Policy Implementation
y LDP aggregate-prefix-match feature
y Targeted LDP
y LDP Authentication
Module 3 |
95
To sum up:
The FIB can contain multiple IP forwarding entries when ECMP is enabled.
The LFIB can be populated with multiple MPLS forwarding entries when ECMP is enabled.
An internal load balancing algorithm distributes the incoming data traffic flows over multiple available links.
Label bindings for additional prefixes can be distributed by configuring and applying an LDP export policy.
An LDP import policy can be used to prevent label bindings for a selection, or all, of the received prefixes from
being installed into the LFIB, or from being further distributed to other peers.
In a multi-area IGP deployment, route summarization can occur at area boundaries, causing an aggregate prefix or
prefixes to be advertised into other areas. By default, a specific prefix advertised by LDP cannot be resolved and
installed in the LFIB, unless an exact match prefix is available in the FIB. The aggregate-match-prefix feature helps
to override this limiting rule.
A router can issue a label withdraw message, to instruct its peers to delete a label binding for a prefix that is no
longer available.
Upon receipt of a label withdraw message, the peer responds with a label release message to confirm the label
delete action.
Targeted LDP is used to signal service labels for Layer 2 VPN services, such VLL and VPLS.
Targeted LDP sessions can be established between non-directly connected peers, unlike Link LDP.
Targeted LDP sessions are established similarly to Link LDP, except that the discovery (UDP Hello) messages are
sent in unicast, as opposed to multicast.
Authentication can be enabled on LDP sessions to harden the network security and guard against potential TCP
spoofing attacks.
Module 3 Page 95
y Label Withdraw and Release Actions
Module Summary
The SR OS uses link LDP for transport tunnel and targeted LDP (TLDP) for service tunnel establishment.
LDP establishes tunnel LSPs with directly attached neighbors or
Targeted LDP sessions between non-directly connected peers.
LDP uses four processes to set up and maintain an LDP session:
Peer discovery Hello messages
Session establishment and management
Label management Advertise and withdraw labels
Notification Error alerts
1.
2.
3.
4.
Discovery messages are periodically multicast using LDP port 646

over UDP to the 'all routers on this subnet' address
LDP Session, Advertisement and Notification messages use TCP
port 646.
Module 3 |
96
Module 3 Page 96
An LDP router needs a System ID configured to form an adjacency

An LDP router needs an IGP route to its peers transport address in
order to create a session
LDP signaling informs adjacent nodes of the labels to be used to
forward traffic between them
An LDP identifier is a six octet quantity used to uniquely identify

an LSR's label space; the 4-byte transport address and a 2-byte
label space
The hello timeout (time)/hello-factor (count) determine the hellointerval (period)
Hello timeout and factor values dont need to match between
adjacent LDP peers
Module 3 |
97
Module 3 Page 97
In frame mode/per-platform operation, an SR OS router maintains

one LSP session per peer.
Between two directly connected peers, an LDP adjacency may
exist without an established session.
An LSR will originate a label for only its system address by default
The Alcatel-Lucent LDP default settings are Downstream

Unsolicited label distribution mode, Liberal label retention mode
and Ordered Control mode.
A LDP router chooses the LFIB entry based upon the FIB best path
to the target FEC.
An SR OS router requires an export policy applied in order to
advertise labels for FECs other than its system ID .
OAM LSP-ping and LSP-traceroute are tools to verify LSP operation.
Module 3 |
98
Module 3 Page 98
ECMP LDP enables load balancing of traffic over multiple equal

cost path LSPs.
Use policies to control the export and import of LDP labels.
LDP aggregate prefix match ensures an LDP prefix match when
advertises aggregate prefixes.
Module 3 |
99
SR OS routers enable targeted sessions by default.
Module 3 Page 99
Learning Assessment
1. Give two reasons that an LSR may withdraw a label advertisement.

2. What type of LDP session is formed between two routers sharing a
common data link?
3. List and define the 4 types of LDP messages.
5. What is the port number used for TCP based LDP messages?
6. How is the targeted HELLO packet different from the normal
HELLO packet?
7. An LDP identifier is a ______ byte quantity used to identify an
LSR's label space.
8. Why does an LDP router advertise a label to the next-hop for a
particular FEC?
Module 3 |
100
1. Give two reasons that an LSR may withdraw a label advertisement.

An MTU change or issuing the command to clear the labels will cause the labels to be withdrawn.
2. What type of LDP session is formed between two routers sharing a common data link?
Two routers sharing a common data link form a session referred to as a Link Adjacency.
3. List and define the 4 types of LDP messages.
Discovery messages (UDP based) Announces and maintains the presence of an LSR in a network
Session messages (TCP based) Establishes, maintains, and terminates sessions between LDP peers
Advertisement messages (TCP based) Creates, changes, and deletes label mappings for FECs
Notification messages (TCP based) Provide advisory information and signals error information
4. What is the port number used for UDP based LDP messages?
Well known port number 646 is used for UDP based LDP messages.
5. What is the port number used for TCP based LDP messages?
Well known port number 646 is used for TCP based LDP messages.
6. How is the targeted HELLO packet different from the normal HELLO packet?
A Targeted HELLO is sent to a specific unicast address rather than to the "all routers" group multicast address.
7. An LDP identifier is a six byte quantity used to identify an LSRs label space.
8. Why does an LDP router advertise a label to the next-hop for a particular FEC?
To speed convergence and decrease downtime in the case of a link failure.
Module 3 Page 100
4. What is the port number used for UDP based LDP messages?
9. In order to form an adjacency, an LDP router needs what

configured?
10. Routers forward link LDP Hello messages to which reserved, allrouters address?
12. Which address determines the router that initiates the LDP
session?
13. True or False: An LDP router populates its LFIB by first checking
the RIB and then choosing the label from the FIB.
14. What must you enable on the router to allow it to populate its
LFIB with multiple labels per FEC?
15. By default, which peer generated LDP labels does an SR OS router
reject?
9.
Module 3 |
101
In order to form an adjacency, an LDP router needs what configured?

An LDP router must have a system ID configured to form an adjacency with another LDP router.
10. Routers forward link LDP Hello messages to which reserved, all-routers address?
Link LDP Hellos target the all routers multicast address 224.0.0.2.
11. To create an LDP session, peer routers must have an IGP route to which of the others addresses?
transport address
12. Which address determines the router that initiates the LDP session?
The router with the highest transport address initiates the LDP session.
13. True or False: An LDP router populates its LFIB by first checking the RIB and choosing the correct label from the
FIB.
True
14. What must you enable on a router to allows it to populate its LFIB with multiple labels per FEC?
ECMP
15. By default, what peer generated LDP labels does an SR OS router reject?
SR OS routers accept all label bindings from their peers, by default.
Module 3 Page 101
11. In order to create an LDP session, peer routers must have an IGP
route to which of the others addresses?

Switching
Module 4 Resource Reservation Protocol (RSVP)
Module 4 Page 1
Module Objectives

to:
Introduce the Resource Reservation Protocol (RSVP).
Introduce RSVP with Traffic Engineering (TE) extensions.
Introduce RSVP message types and their uses.
Discuss several methods for reducing RSVP messaging and
processing overhead.
Module 4 |

Module 4 introduces the Resource Reservation Protocol with Traffic Engineering extensions.
Signaling requirements and operational details of establishing and maintaining Label Switched Paths using the RSVP-TE
protocol are all explained in this module.
The real benefits of RSVP-TE protocol namely the Traffic Engineering related features - shall be discussed in the
following modules.
Module 4 Page 2
Explain LSP signaling using RSVP.
Module 4 - Resource Reservation

Protocol
Section 1 Control Plane Overview
Module 4 Page 3
Section Objectives

Introduce the Resource Reservation Protocol (RSVP).
Introduce RSVP with Traffic Engineering (TE) extensions.
Explain LSP signaling using RSVP.
Introduce RSVP message types to establish or clear LSPs, and to
signal error conditions.
LSP-Ping and LSP-Trace for RSVP-TE based LSPs.
Module 4 |
This section briefly examines the Resource Reservation Protocol, which was available before the introduction of MPLS.
The modifications, or extensions, made to RSVP to tailor it for MPLS traffic engineering purposes are then briefly
discussed.
The main purpose of the section, however, is to explain the primary components, as well as the general process, of
establishing LSPs, using the RSVP-TE protocol.
An RSVP-TE based LSP requires session states that are maintained in all of the participating routers on the path of an
LSP. The establishment and periodic maintenance of these sessions, using heartbeat messages, is examined step-by-step
in a simple case study.
The messages used by RSVP to signal, maintain, and clear (tear down) LSPs, or to signal certain error conditions, are
also introduced with case study examples.
Finally, the use of the LSP-Ping and LSP-Trace OAM commands for RSVP-TE based tunnels are presented at the end of
the section.
Module 4 Page 4
Explain RSVP session establishment process for an LSP.
Resource Reservation Protocol (RSVP) Introduction
RFC 2205 originally described RSVP as a signaling protocol for use

with the IP IntServ (Integrated Services) Quality of Service model.
Initially used to signal traffic characteristics and IP traffic flow
requirements.
Requests resources for simplex (unidirectional) flows. Bidirectional
flows require two RSVP sessions, one in each direction.
RFC 3209 later extended RSVP to signal MPLS LSPs.
Module 4 |
Originally, the Resource Reservation Protocol (RSVP) was developed as a network control protocol that a host would use
to request specific qualities of service from the network for particular application data streams or flows. In addition,
RSVP has also been used by routers to deliver quality of service (QoS) requests to all nodes along the paths of the flows,
and to establish and maintain a state that provides the requested service. RSVP requests usually result in the
reservation of resources in each node along the data path. When used with MPLS, RSVP leverages this mechanism to set
up traffic engineered LSPs.
RSVP requests resources for simplex flows but only in one direction (unidirectional). Therefore, RSVP treats a sender as
logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the
same time. Duplex flows require two LSPs, to carry traffic in each direction.
RSVP is not a routing protocol. It operates with unicast and multicast routing protocols that determine where packets
are forwarded. RSVP consults local routing tables to relay its messages.
Module 4 Page 5
Not a routing protocol, but works with the routing protocols.
RSVPTE (Traffic Engineering) Extensions
RSVP was again extended to be used as a label distribution

protocol, according to RFC 3209.
y The ability to make advanced path calculations that are not

restricted to IGP cost values (using link colors, bandwidth
constraints, and so on).
y The use of a rich set of traffic protection features (secondary
paths, Fast Reroute).
y The ability to make resource reservations CAC (Connection
Admission Control) functionality.
Module 4 |
The RSVP protocol has since been extended to support the traffic engineering requirements in MPLS based networks.
RSVP-TE brings major benefits to MPLS networks. They:
Provide access to detailed and customized path information to signal LSPs, which can be completely different from
IGP best path decisions.
Facilitate the use of additional administratively defined attributes for links that enable more complex dynamic
path calculations, to increase resiliency and resource efficiency. This is an improvement to IGP shortest path
calculations, which are restricted by their use of a single parameter or metric, called the link cost, for Link-State
Protocols.
Provide access to preferred features, such as secondary path or Fast Reroute protection, which help to improve the
convergence times offered by standard routing protocols.
Take resource reservation information into account during the LSP establishment process, which ensures that LSPs
only traverse routers that have sufficient resources available. This is called Connection Admission Control (CAC).
Using CAC allows operators to prevent resource overbooking.
Module 4 Page 6
RSVP with Traffic Engineering capability brings major benefits to

MPLS including:
y The ability to administratively define LSP Paths.
RSVP-TE Main Characteristics
Downstream On Demand mode of distribution

y LSPs are only signaled when explicitly requested.
Conservative Label Retention

y Labels are cleared if not needed.
Path and Reservation messages used to signal LSPs.
Session states maintained on all routers along the path of an
LSP.
Module 4 |
The RSVP-TE LSP establishment process is significantly different from the LDP process that was covered in Module 3.
LDP uses a Downstream Unsolicited mode of distribution, with Liberal Label Retention. When LDP is enabled in the
network, labels are advertised for the system IP address of all MPLS routers, by default; an additional trigger is not
necessary. As a result of label flooding in the network, eventually a full mesh of LDP based tunnels are established in
the network. While obviously simple to configure and maintain, LDP is limited by its lack of traffic engineering
capability and its heavy dependence on IGP, in terms of convergence.
RSVP-TE uses a Downstream on Demand (DoD) mode of label distribution. The demand for labels is triggered when an
ingress router sends a PATH message in the downstream direction, towards the egress router. The allocation of labels
follows a hierarchical order; that is, labels are allocated in an orderly fashion, starting from the egress router and
progressing hop-by-hop towards the ingress router in the upstream direction. This is achieved by the propagation of a
RESV (Reservation) message, which travels in the opposite direction to the corresponding PATH message.
In the original RSVP protocol (RFC 2205), a session is defined as a dataflow with a particular destination IP address, IP
protocol ID, and optionally, the destination port ID. RSVP with Traffic Extensions (RSVP-TE) is used to signal end-to-end
MPLS LSPs. Therefore, the concept of an RSVP session is made more general. When using RSVP-TE, an RSVP session is a
connection that contains the mapping of an ingress label and an egress label that belong to the same LSP. This
connection is analogous to the cross-connect concept of an ATM PVC.
Module 4 Page 7
Ordered Control
y Label distribution process follows a hierarchical order.
Router R1 sends a PATH message in the downstream direction and

requests labels to be allocated along the path, in order to have an LSP
to router R6.
In RSVP-TE terminology, the ingress router of the tunnel is also called
Head-End, and the egress router is called Tail-End.
Module 4 |
The above figure illustrates an RSVP LSP path. The ingress label edge router (iLER) transmits an RSVP path message
(path: 10.10.10.6) downstream to the egress label edge router (eLER). The path message contains a LABEL_REQUEST
object, which asks intermediate LSRs and the eLER to provide a label binding for the path.
The signaling protocol model uses downstream-on-demand label distribution. A request to bind labels to a specific LSP
tunnel is initiated by an ingress node through the RSVP Path message. For this purpose, the RSVP Path message is
augmented with a LABEL_REQUEST object.
Module 4 Page 8
RSVP-TE Path Message Flow
RESV messages are sent in the upstream direction and labels are
allocated at each hop.
When router R1 receives the RESV message from its downstream
neighbor, it brings up the LSP.
Module 4 |
The above figure illustrates the propagation of RSVP RESV messages.

Router R6 receives a PATH message requesting that a label is distributed to the upstream neighbor to bring up the LSP
requested by router R1.
Labels are allocated downstream and distributed (propagated) upstream by means of the RSVP RESV message. For this
purpose, the RSVP RESV message is extended with a special LABEL object.
Module 4 Page 9
RSVP-TE Reservation Message Flow
Prerequisites for configuring RSVP-TE LSP
Ensure proper functioning of hardware (IOM, MDA, ports)

Configure network interfaces
Configure IGP
Enable the MPLS context
Module 4 |
10
The logical sequence of actions to configure and signal RSVP-TE based LSPs is presented above.
The basic provisioning of related hardware components, such as the Input-Output Modules (IOMs), Media Dependent
Adapters (MDAs), and the physical ports, must be accomplished before proceeding to any other tasks on the AlcatelLucent Service Routers. Please refer to Alcatel-Lucent Configuration and Hardware manuals for more information.
The remaining steps necessary to complete the prerequisites to configure RSVP-TE based LSPs are outlined above and
explained in more detail in the following pages.
Module 4 Page 10
Configure the interfaces for MPLS

Enable the RSVP context
10.10.10.x/32 addresses are the system (default loopback)

interface addresses.
Module 4 |
11
The above diagram will be used to explain the main principles of RSVP-TE operation throughout this module.
System IP interfaces are created on the Service Routers by default and are crucial to the operation of the router in
various contexts.
Unique addresses need to be assigned to the system IP addresses to maintain proper operation.
The system IP interfaces use a prefix length of 32. This mask value implies a single host, where the host is the router
itself.
Module 4 Page 11
RSVP-TE Operation Reference Topology
A:R1>config>router#
-------------------------------interface "toR2"
address 10.1.2.1/24
port 1/1/4
exit
interface "toR3"
address 10.1.3.1/24
port 1/1/3
exit
interface system
address 10.10.10.1/32
exit
-------------------------------area 0.0.0.0
interface system
exit
interface toR2
interface-type p2p*
exit
interface toR3
interface-type p2p*
exit
Module 4 |
12
The configuration of the core IP interfaces and the system interface is seen in the top CLI capture in the above slide.
Router R1 is used as an example.
The system interface is the default loopback interface; that is, an entity that remains up as long as the router is
operational. The system interface is not bound to any physical interfaces so it can be reached through any of the
routers physical interfaces.
Recall that RSVP-TE is not a routing protocol; it needs an Interior Gateway protocol to distribute the network
reachability information. OSPF and IS-IS are the major protocols used in contemporary IP/MPLS networks.
The configuration of OSPF is seen in the bottom CLI capture. A single backbone area (Area 0) is being used. It is
important to include the system interface in the OSPF configuration, so that other routers are able to reach the
interface.
interface-type p2p*: The actual command used is interface-type point-to-point. The default setting for the
interface-type is broadcast, which is actually intended for multi-access segments (that is, multiple routers attached
to a common Layer-2 segment). Initial convergence on broadcast segments take more than 40 seconds, due to
Designated Router election. Thus, it is recommended practice to use the point-to-point setting for directly connected
segments on which only 2 routers exist.
Module 4 Page 12
Network IP Interface and IGP Configuration
MPLS and RSVP Configuration
A:R1>config>router>rsvp# info
-------------------------------interface "system"
exit
interface "toR2"
exit
interface "toR3"
exit
Automatically added
Manually added
(Display config)
Automatically added
When configured for MPLS, interfaces are automatically enabled for

RSVP as well.
MPLS and RSVP must be enabled similarly on all routers.
Module 4 |
13
Two contexts are used to configure and signal RSVP-TE based LSPs on the ALU Service Routers MPLS and RSVP.
Most LSP related configuration tasks occur from within the MPLS context. Operators create the path definitions and LSPs
and enable or disable features that effect the LSPs operation.
LSPs cannot be established unless MPLS is enabled and properly configured.
Interfaces can only be added into and removed from the MPLS context.
The RSVP context is mainly used to modify the parameters, or enable certain features, that are related to the actual
signaling of LSPs.
The contexts are internally connected to each other in several ways. If you add an interface into the MPLS context, it is
also automatically added into the RSVP context as well. If you remove an interface from the MPLS, it is also removed
automatically from the RSVP context.
The system interface is automatically added to both contexts, since it is usually crucial to the operation of RSVP-TE
based LSPs.
Module 4 Page 13
A:R1>config>router>mpls#
-------------------------------interface "system"
exit
interface "toR2"
exit
interface "toR3"
exit
Enabling and verifying MPLS & RSVP

===========================================================
Admin State
Oper State
----------------------------------------------------------.....
.....
......
MPLS
Down
Down
RSVP
Down
Down

===========================================================
Admin State
Oper State
----------------------------------------------------------.....
.....
......
MPLS
Up
Up
RSVP
Up
Up
Both contexts need to be enabled on all routers.

LSPs can now be configured and signaled.
Module 4 |
14
As of SR OS Software Release 7.0, both MPLS and RSVP contexts are initially disabled by default.
Before making any LSP configurations, it is a good idea to do a sanity check to ensure that the required protocols are up
and running. This can easily be done by using the show router status command, as displayed above.
Both contexts need to be enabled separately by issuing an administrative no shutdown.
The result of this action can be verified by executing the show router status command again. The bottom CLI
capture in the above slide illustrates that both contexts are now both administratively and operationally Up.
For proper operation, similar procedures defined on this and the previous pages must be performed on all the core
routers before attempting to configure LSPs.
Module 4 Page 14
*A:R1# configure router mpls no shutdown

*A:R1# configure router rsvp no shutdown
An RSVP-TE based LSP can have multiple associated LSP-Paths.

One primary and 7 secondary paths can be defined for redundancy.
One LSP-Path is active (carrying data traffic) at a given time.
Module 4 |
15
RSVP-TE LSP introduces the concept of LSP-Path, which is among the advanced traffic protection mechanisms.
The following (rough) definitions can be made for LSP and LSP-Path, in relation to RSVP-TE.
In practical terms, LSP is a logical entity that only exists in the ingress router of a Label Switched Path. LSP represents
the MPLS reachability from an ingress router to an egress router.
LSP-Path is a logical entity that is defined in the ingress router and represents an MPLS label connection that can reach
the egress router of the Label Switched Path. An established LSP-Path consists of a series of RSVP sessions in all the
routers along the LSP-Path.
One LSP can have more than one LSP-Path for redundancy or backup purposes.
An LSP-Path can also be used a primary path, which is usually the preferred path to actively carry data traffic over the
LSP. Optionally, up to 7 secondary paths can be defined within an LSP to provide backup solutions, in case the primary,
or other secondary, paths fail.
Not included in the figure above, an LSP can also have Fast Reroute detour or bypass tunnels to recover traffic in the
fastest way possible, in case of link failures.
Secondary and Fast Reroute protection mechanisms will be covered in greater detail in Module 6.
Module 4 Page 15
LSP and LSP-Path
LSP Path Configuration Options
At least one path definition is needed for an LSP.

A path definition may contain a list of nodes that the LSP-path
must traverse.
A path definition might contain:
y Hops explicitly defined as loose or strict (Module 5)
y An empty list with no explicit hops
A path definition might be used multiple times in different LSPs,
but cannot be used more than once per LSP, whether primary or
secondary.
Module 4 |
16
The main features of configuring RSVP-TE based LSPs are presented above.
An LSP needs at least one path definition to be signaled using RSVP.
The introduction mentioned that one of the major benefits that RSVP-TE is the ability to administratively define the
path of an LSP. Here, the term path is used merely in the sense of a series of routers (that are called as hops in
RSVP terminology) defined in a configuration.
To give ultimate flexibility to network operators, the hops that an LSP must traverse can be defined in a variety of
ways. Hops can be explicitly defined as either loose or strict, if higher administrative control is desired, and
even more constraints can be imposed to calculate the path of an LSP. These techniques will be discussed in Module 5.
In this module, only an empty path list with no specific hops will be used to facilitate the primary objective of the
module: understanding the RSVP-TE LSP and session establishment/maintenance processes.
Path definitions can be seen as templates or passive components. They are only put into use when applied under an
LSP, either as a primary or secondary LSP-Path. A path definition can be used multiple times within the same LSP, or
within different LSPs if it is suitable to do so.
A case study example is presented in the following pages to better illustrate these concepts.
Module 4 Page 16
Each of these nodes is called a hop.
Case Study LSP with Empty Primary Path Definition
no shutdown
exit
lsp "to_R6"
to 10.10.10.6
Arbitrary LSP name
exit
Tunnel Destination IP Address

Use the previously created path definition
as the primary LSP-path.
no shutdown
Administratively enable the LSP
primary "empty_list"
exit
Arbitrary path name

Administratively enable the path
An LSP needs, at minimum, a tunnel destination address and a path

definition.
The tunnel destination address is typically the system IP address of
the egress router.
When the LSP is enabled, an RSVP PATH message is sent
downstream, in an attempt to signal the LSP.
Module 4 |
17
An example path definition and LSP configuration is presented above.

The path definition serves as a template that regulates the path that an LSP shall take.
LSP is actually the active component that gets signaled and established, using the RSVP messaging procedures that are
presented in the following pages.
LSPs should be given meaningful names for operational and troubleshooting convenience. Each operator may have
different naming standards for different entities to streamline the configuration processes.
In the example above, an LSP with a name to_R6 is created. This indicates that the LSP shall reach out to router R6
as the tunnel destination.
Many parameters can be defined under an LSP definition, to enable or disable certain features or functionalities. Most
of the time, however, the default values are suitable.
In principle, two main parameters need to be defined to signal an LSP:
To: Defines the tunnel destination address of the egress router. The most common convention is to use the system
IP address of the egress router, but any IP address that belongs to the egress router can be used. In this example,
the idea is to establish an LSP to router R6, by any means. There is no explicit requirement to regulate through
which physical interface router R6 must be reached, thus it makes more sense to use the system interface address,
since it will remain reachable as long as the router itself is reachable by other routers.
Primary path definition: The previously created path definition, empty_list, is defined as the primary path. It
does not impose any explicit administrative control over the LSP-Path.
The path above can also be defined as a secondary path, although this would preclude use of the MPLS resiliency
features discussed in Module 6.
Module 4 Page 17
-------------------------------path "empty_list"
RSVP PATH Message
Internet Protocol:
Source: 10.10.10.1
R1 (ingress LER) System @IP
Dest. : 10.10.10.6
R6 (egress LER) System @IP
Options: Router Alert
Each receiving router must examine

the encapsulated RSVP message
RSVP PATH Message:

<SENDER TEMPLATE>
<HOP>
RSVP Objects (Information Blocks)
<EXPLICIT ROUTE>
............
The PATH message uses end-to-end addressing.

The Router Alert option instructs each router along the path to
process the RSVP contents in control plane.
Module 4 |
18
When the configuration on the previous page is complete and the LSP is enabled, the ingress router attempts to signal
the LSP-Path by sending out an RSVP Path message. This is the request message that was presented in the protocol
introduction. It travels downstream towards the egress router to trigger label allocations.
An RSVP Path message is encapsulated in an IP header. The source IP address is typically the configured system IP
address of the ingress router. The destination IP address is taken from the to portion of the LSP configuration. In our
example, this is the system IP address of the egress router.
As seen above, the Path message uses end-to-end addressing. Even if the Path traverses multiple intermediate hops, the
intended recipient is the router that is at the end of the tunnel. As a result of this addressing scheme, the intermediate
routers would normally be tempted to simply pass the message on, without analyzing the rest of its contents.
Therefore, they would normally forward the packet to their IGP next-hop, without decapsulating the RSVP header and
processing its contents.
According to the implementation of RSVP-TE LSP signaling (that will be presented step-by-step in the following pages),
all the intermediate routers are also required to process the RSVP message contents. To ensure this, the Router Alert
option is set in the IP header; this instructs all receiving routers to decapsulate and process the RSVP message in their
control plane and take any necessary action.
The information relevant to the signaling of an LSP is contained within several information blocks, referred to as
objects in official RSVP parlance. Some of these objects will be presented in this and the ensuing modules of this
course.
For a full description of RSVP objects, please refer to RFC 3209.
Module 4 Page 18
<SESSION>
If the RSVP message does not list any hops, the IGP forwarding table is
used to forward the PATH message at each router.
Module 4 |
19
If explicit hops are defined in the path definition, they are included in the RSVP message as sequential hops. The
routers consult this list of hops to determine to which next-hop they should forward the PATH message. (This will be
discussed in the next module).
An empty path definition was used in the LSP Path definition that was presented in the previous pages. Hence, the
primary path definition does have any explicitly defined hops.
In this case, the router reverts to default IGP decisions. That is, it looks up the destination IP address specified in the IP
header of the Path message (which is taken from the to field of the LSP configuration) and determines the next-hop.
In the example above, router R2 is the IGP chosen next-hop to reach prefix 10.10.10.6/32 of router R6; therefore, the
message gets forwarded to router R2.
Module 4 Page 19
Forwarding the PATH Message with Empty Hop List
Router R1 creates the PATH message and a Path State Block (PSB).
Router R1 stores the PATH message in the PSB and forwards the message to
the next-hop.
The HOP object contains router R1s egress interface IP address.
The LABEL REQUEST object indicates that router R1 expects a label.
Module 4 |
20
For the sake of clarity, only two of the many objects inside the RSVP PATH message are displayed in the figure above.
The HOP object contains the egress IP address of the interface on router R1, on which the PATH message is forwarded.
This address is used by router R2 when forwarding the RESV message back to router R1, at a later stage.
The LABEL REQUEST object is an indicator that router R1 is asking for a label from router R2 to establish the LSP.
However, because of the Ordered Control mode of implementation, and because router R2 is not the egress router for
the LSP, router R1 will wait for its own downstream neighbor (router R4) to distribute a label first. It therefore needs to
pass the PATH message to router R4 (described on the following page).
Router R1 creates a Path State Block (PSB) right after sending the Path message to router R2. The Path State Block
stores all the details of the Path message that is sent to router R2. This is required because router R2 needs to identify
which LSP the message is intended for when it receives the RESV (reservation) message later. The router matches values
in the previously sent PATH message and the newly received RESV message in order to associate them to the LSP.
PSB is combined with RSB (Reservation State Block, presented in the following slides) to make up a session that belongs
to the LSP. The session will need to be refreshed at certain intervals. The PSB (and the RSB) also stores timers to
perform the refresh function.
Module 4 Page 20
Forwarding the PATH Message from router R1 to router R2
Router R2:
Receives the PATH message.
Creates the PSB.
Stores the PATH message in the PSB.
Looks up the destination in FIB.
Regenerates and forwards the PATH message.

=================================
Prefix
Protocol
NextHop
--------------------------------...............
......
10.10.10.6/32
OSPF
10.2.4.4 (toR4)
Module 4 |
21
The sequence of events that take place on router R2 are illustrated above.
Upon receipt of the PATH message, router R2 creates its own Path State Block (PSB). The PSB stores all the contents of
the PATH message, but we show only the HOP object for the sake of clarity. 10.1.2.1 is router R1s (the upstream
routers) egress interface IP address, on which the PATH message was sent. Router R2 will use this information later.
Router R2 realizes that there are no explicitly defined hops in the RSVP message. As a result, router R2 reverts to the
default mechanism in forwarding the PATH message; that is, it looks up the destination IP address in the FIB.
Router R4 is listed as the next-hop for prefix 10.10.10.6/32, therefore router R2 forwards the PATH message to router
R4.
In the outgoing PATH message, the HOP object is set to router R2s outgoing interface IP address, 10.2.4.2.
The process of forwarding the PATH message is similar for router R4.
Module 4 Page 21
Forwarding the PATH Message from router R2 to router R4
PATH messages are forwarded downstream to router R6.

A Path State Block is created at each hop, storing the PATH
message sent by the upstream router.
Router R6 is the tunnel destination.
Router R6 needs to send a RESV message back to router R4.
Module 4 |
22
In the figure above, the complete end-to-end forwarding of the PATH message from the ingress router (R1) towards the
egress router (R6) is displayed.
PSBs are created on all the routers that receive and process the PATH message.
Eventually, the PATH message reaches router R6, at which point the propagation of the PATH message stops.
Router R6 owns the destination IP address specified in the PATH message. It is also the egress router for the LSP and
now needs to respond to the request of the ingress router (R1) with a reservation message.
Module 4 Page 22
End-to-End Forwarding of the PATH message
Router R6 allocates a label (131067) and sends back a RESV message.

The destination IP address is the upstream routers egress interface IP
address (advertised previously in the HOP object of the PATH message,
and stored in the PSB).
Module 4 |
23
Router R6 has received a PATH message to have labels allocated to signal an LSP that was initiated by router R1.
Router R6 checks its dynamic label-range (32,768 131,071) and allocates a label that has not yet been reserved by any
signaling protocol. In the example above, the label that router R6 locally allocates for the LSP request by router R1 is
131,067. This label value is indicated in the LABEL object of the RESV message that is sent to router R4.
Unlike the PATH message, which uses end-to-end addressing, the RESV message uses hop-by-hop addressing. That is,
router R6 does not perform a FIB lookup to determine where the RESV message should be forwarded; rather, it uses
previously received information.
To find out which upstream neighbors directly connected IP address should be used as the destination IP address of the
RESV message, router R6 checks the HOP object inside the PSB that was created when the PATH message was received.
The HOP object in the PSB contains the address 10.4.6.4, which is the interface IP address of router R4. This is why the
RESV message is sent to router R4.
The corresponding source IP address for router R6 is 10.4.6.6, as seen above. The HOP object of the RESV message sent
to router R4 is set to the egress interface IP address of the sending router, router R6.
Note: The RESV message actually contains more objects (information blocks), which are omitted here for clarity. Other
objects will be introduced in the following modules.
Module 4 Page 23
Forwarding the RESV message from router R6 to router R4
The Reservation State Block (RSB) stores the RESV message.

When a PSB and RSB are both present, an RSVP session is created for
the LSP.
Session type is Terminate on router R6, as it is the tunnel
destination.
Module 4 |
24
A Reservation State Block (RSB) is created on router R6 once a label is allocated for the LSP and the RESV message sent.
The RSB basically stores the original RESV message sent to the upstream neighbor.
When a PSB and RSB are both present on a router, an RSVP session is created for the LSP to store the necessary LSP
parameters. The R6 RSVP session represents the LSP that was originally created on router R1.
Router R6 has an ingress label and no egress label, since it is the egress router for the LSP. As a result, router R6 has an
RSVP session with type terminate for the LSP. In other words, router R6 is where the LSP terminates, or ends.
Within the data plane context, router R6 expects labeled packets from router R4 with a label of 131,067. Upon receipt
of such packets, router R6 will Pop their labels and process the rest of the packets contents.
Note: Unlike LDP, router R6 advertises the label to router R4 only, and not to both neighbors.
Module 4 Page 24
Creating the RSVP session on router R6
Router R4 receives the RESV message and creates the RSB.

Router R4 regenerates the RESV message and forwards it upstream.
An RSVP session is created for the LSP with type Transit.
Module 4 |
25
When router R4 receives the RESV message, it immediately creates the Reservation State Block to track the state of the
reservation in the future.
Recall that an RSVP session is created for an LSP when both a PSB and RSB are present on router R6. This session type is
transit, since router R4 is a Label-Switch router for the LSP and performs a swap operation. The associated ingress and
egress label values for this example are shown above.
Router R4 updates its contents and thus builds a new RESV message. The destination address used in the RESV message
is taken from the HOP object of the previously created PSB.
The HOP object of the RESV Message is set to the sending routers (R4s) egress interface IP address, which is 10.2.4.4.
Label 131,064 is reserved and advertised by router R4.
Module 4 Page 25
Forwarding the RESV message from router R4 to router R2
RESV messages are forwarded upstream to router R1.

An RSVP session is created on each router along the LSP.
Router R1 puts the LSP into an operationally Up state.
The RSVP session type on router R1 is originate.
Module 4 |
26
The end-to-end forwarding story of the RESV message is illustrated above.

Each router locates the upstream router by checking the HOP object inside the PSB that was created in the PATH
message forwarding stage.
Each router locally allocates a label in its database and advertises it to its neighbor.
As soon as an RESV message is received from the downstream neighbor, an RSB is created on each router.
The presence of both the PSB and RSB gives rise to the creation of an RSVP session that represents the LSPs on all
routers along the path. The session contains the ingress and egress labels for the LSP, along with other parameters.
Note that this mapping of the ingress label and interface to an egress label and interface is analogous to the crossconnect functionality in ATM PVCs.
When router R1 finally receives the RESV message with the egress label mapping, it marks the LSP as operationally
up.
Data traffic can now be label switched over this LSP, if the operator so chooses.
Module 4 Page 26
End-to-End Forwarding the of the RESV message
Verifying the LSP on the Originating Router
*A:R1# show router mpls lsp to_R6 path detail

------------------------------------------------------------------------------LSP to_R6 Path empty_list
------------------------------------------------------------------------------LSP Name
: to_R6
Path LSP ID : 57586
From
: 10.10.10.1
To
: 10.10.10.6
Adm State
: Up
Oper State : Up
Path Name
: empty_list
Path Type
: Primary
Path Admin : Up
Path Oper
: Up
OutInterface: 1/1/4
Out Label
: 131062
Path Up Time: 0d 00:01:25
Path Dn Time: 0d 00:00:00
The above commands display the LSP status and details on router R1.
Module 4 |
27
Since the LSP is only configured on the ingress router (the rest is dynamic RSVP signaling), the show router mpls
lsp command can only be used on the ingress router of the LSP. The command output indicates that router R1 is the
router where the LSP originates. (It is possible to view the status of the LSP on the routers by specifying additional
keywords, as will be presented in the following pages.)
The most significant parameters are the LSP-Name and destination IP address (as specified in the to field of the LSP
configuration). Fastfail Config refers to the Fast Reroute feature, explained in Module 6, which is not yet enabled.
The LSP is both administratively and operationally up.
More extensive information is displayed with the show router mpls lsp lsp-name path detail command.
LSP to_R6 has only one primary path, which is named empty_path because it does not have any specific explicit
hops defined. Router R1 is an ingress router for the LSP, hence it only has an egress interface label associated. The
Path Up or Path Down timers are useful in troubleshooting problems with an LSP. These fields can reveal if and
when a path state transition has occurred.
Note: The detail output contains much more information than is displayed above, but is omitted for clarity reasons.
Module 4 Page 27
*A:R1# show router mpls lsp

===============================================================================
MPLS LSPs (Originating)
===============================================================================
LSP Name
To
Fastfail
Adm
Opr
Config
------------------------------------------------------------------------------to_R6
10.10.10.6
No
Up
Up
------------------------------------------------------------------------------LSPs : 1
Verifying the RSVP Session on the Originating Router
*A:R1# show router rsvp session originate

===============================================================================
From
To
Tunnel LSP
Name
State
ID
ID
------------------------------------------------------------------------------10.10.10.1
10.10.10.6
1
57586 to_R6::empty_list
Up
------------------------------------------------------------------------------Sessions : 1
LSP ID: Each LSP-Path (primary or secondary) have its own LSP ID.
Session Name: Format is LSP-Name :: Path-Name
Tunnel ID, LSP ID, and Session Name are used to identify a unique
RSVP session that belongs to a signaled LSP on all routers.
Tunnel ID and LSP ID are internally assigned by the originating router
(not configurable).
Session Name is taken from the LSP configuration.
Module 4 |
28
An RSVP session is established on all the routers along the path of an LSP. To uniquely identify an RSVP session among
other sessions, certain parameters are used.
Tunnel ID is an integer internally assigned to an LSP by the originating router. All the signaled LSP-Paths of an LSP share
the same Tunnel ID. This includes the primary path and all the signaled secondary paths.
To distinguish between the different LSP-Paths of an LSP, the LSP ID is used.
Neither the Tunnel ID nor the LSP ID is administratively configurable.
The RSVP session name is inherited from the LSP-Name and Path-Name configuration on the originating router, as shown
in the example above. Since the different paths of an LSP must have different path names, their RSVP session names are
also different.
If a primary path has one-to-one Fast Reroute protection, its detours have the same Tunnel ID and LSP ID as the primary
path. They are distinguished from the primary path, and from each other, by their different session names. This will be
explained further in Module 6.
RSVP Sessions need to be periodically refreshed to keep the LSP operational.
Module 4 Page 28
Tunnel ID: Shared by all LSP-Paths that belong to the same LSP.
Verifying the LSP on a Transit Router
*A:R2# show router mpls lsp transit (lsp-name to_R6::empty_list) detail

------------------------------------------------------------------------------LSP to_R6::empty_list
------------------------------------------------------------------------------From
: 10.10.10.1
To
: 10.10.10.6
State
: Up
...........................
In Interface
: 1/1/4
In Label
: 131062
Out Interface
: 1/1/2
Out Label
: 131064
Previous Hop
: 10.1.2.1
Next Hop
: 10.2.4.4
===============================================================================
The above commands display the transit LSP status and details on
router R2.
Module 4 |
29
On a transit router, which is responsible for performing a swap action for the LSP in the data plane, the previously
presented commands should be used together with the transit keyword.
The show router mpls lsp transit detail command output displays the ingress and egress labels and interface
information, and other relevant details regarding the LSP, all of which are not displayed here.
Module 4 Page 29
*A:R2# show router mpls lsp transit

===============================================================================
From
To
In I/F
Out I/F State LSP Name
------------------------------------------------------------------------------10.10.10.1
10.10.10.6
1/1/4
1/1/2
Up
to_R6::empty_list
------------------------------------------------------------------------------LSPs : 1
*A:R2# show router rsvp session transit detail

------------------------------------------------------------------------------LSP : to_R6::empty_list
------------------------------------------------------------------------------From
: 10.10.10.1
To
: 10.10.10.6
Tunnel ID
: 1
LSP ID
: 57586
Style
: SE
State
: Up
Session Type
: Transit
In Interface
: 1/1/4
Out Interface : 1/1/2
In Label
: 131062
Out Label
: 131064
Previous Hop
: 10.1.2.1
Next Hop
: 10.2.4.4
.........................
..........................
Path Recd
Resv Recd
: 247
: 244
Path Sent
Resv Sent
: 246
: 238
The above command displays the transit RSVP session status and
details on router R2.
Module 4 |
30
The transit RSVP session status can be displayed with the show router rsvp session transit detail command.
The command output also displays the total count of all the received Path and Resv messages.
A low number of messages can indicate that the session has a relatively lower uptime.
Module 4 Page 30
Verifying the RSVP Session on a Transit Router
Verifying the LSP on the Last Hop Router
*A:R6# show router mpls lsp terminate (lsp-name to_R6::empty_list) detail

------------------------------------------------------------------------------LSP to_R6::empty_list
------------------------------------------------------------------------------From
: 10.10.10.1
To
: 10.10.10.6
State
: Up
.............................
In Interface
: 1/1/4
In Label
: 131067
Previous Hop
: 10.4.6.4
===============================================================================
The above commands display the LSP status and details that
terminate on router R6.
Module 4 |
31
The command outputs above displays the LSP related information on the terminating router, where the LSP ends.
Note that router R6 only has an associated ingress label and interface, as it is the egress router for the LSP.
Module 4 Page 31
*A:R6# show router mpls lsp terminate

===============================================================================
From
To
In I/F
Out I/F State LSP Name
------------------------------------------------------------------------------10.10.10.1
10.10.10.6
1/1/4
n/a
Up
to_R6::empty_list
------------------------------------------------------------------------------LSPs : 1
*A:R6# show router rsvp session terminate detail

------------------------------------------------------------------------------LSP : to_R6::empty_list
------------------------------------------------------------------------------From
: 10.10.10.1
To
: 10.10.10.6
Tunnel ID
: 1
LSP ID
: 57586
Style
: SE
State
: Up
Session Type
: Terminate
In Interface
: 1/1/4
Out Interface : n/a
In Label
: 131067
Out Label
: n/a
Previous Hop
: 10.4.6.4
Next Hop
: n/a
.........................
..........................
Path Recd
Resv Recd
: 254
: 0
Path Sent
Resv Sent
: 0
: 254
The above command displays the RSVP session status and details
that terminates on router R6.
Module 4 |
32
The show router rsvp session terminate command lists only the RSVP sessions with type Terminate on the
router.
If more information is required, the detail keyword can be specified, as seen in the example above.
Note that, because router R6 is the egress router, it only receives PATH messages and sends RESV messages for the LSP.
Module 4 Page 32
Verifying the RSVP Session on the Last Hop Router
Other RSVP Message Types
PATH Tear: Used to clear the LSP in the downstream direction

toward the egress router.
RESV Tear: Used to clear the LSP in the upstream direction toward
the ingress router.
PATH Error: A node reports errors related to a PATH message
received from an upstream router.
RESV Error: A node reports errors related to a RESV message

received from a downstream router.
Hello: Used as a heartbeat mechanism for RSVP.
ACK: Used to acknowledge initial PATH and RESV messages
(disabled by default).
Summary Refresh: Used to replace the LSP refreshing PATH and
RESV messages to reduce overhead (disabled by default).
Module 4 |
33
RSVP message types other than PATH and RESV messages are presented above.
These different message types are examined later in the module.
Module 4 Page 33
LSP is initially established.

Operator shuts down the LSP
PathTear messages are sent downstream to clear the RSVP sessions
and tear down the LSP.
Module 4 |
34
For any number of administrative reasons, the operator might want to bring down the LSP. This is done by issuing a
shutdown command in the LSP configuration of the ingress router. If an LSP, or a specific LSP-Path, is no longer
needed, it should be removed from the network to release the resources. This is how Conservative Label Retention
works.
As discussed earlier, the routers along the path of an RSVP-TE LSP store not only labels, but also session state
information. When it wishes to tear down an LSP and release its resource, the ingress router sends out a PATH Tear
message, which travels all the way downstream towards the egress router. When a router receives a PATH Tear, it
clears the corresponding RSVP session and the related state blocks to release the sessions resources.
Module 4 Page 34
Shutting Down an LSP PathTear Message
LSP is initially established.

Link between routers R4 and R6 fails.
Router R6 detects the failure and clears the RSVP session.
Router R4 does the same and also sends a ResvTear message
upstream.
Module 4 |
35
If a transit or egress router detects a fatal error condition that impacts an LSP, it immediately sends out an RESV Tear
message to instruct all its upstream neighbors to clear their RSVP sessions associated with that LSP.
This way, all the routers are informed about the problem and, since the LSP is torn down, data traffic is not blindly
forwarded downstream. Tear messages ensure traffic is not black-holed at the point of failure.
In the example above, the link between routers R4 and R6 fails. Router R6 clears its session and, since it has no other
downstream neighbors to notify, it does not need to take any further action.
Router R4, however, is a transit router for the LSP and sends out an RESV Tear message in the upstream direction,
instructing all the other routers to clear their sessions.
The ingress routers (R1) response to LSP failure will be discussed in the following modules.
Module 4 Page 35
Link Failure ResvTear Message
A Path Error message may be sent upstream if a router cannot

forward the PATH message any further during initial establishment.
Possible reasons include:
y The destination address is unreachable.
y Insufficient resources are available to support the LSP paths bandwidth
reservations (covered in Module 5).
Module 4 |
36
A PATH message is sent downstream to establish an LSP.

If any router along the LSP-Path cannot forward the PATH message, it sends back a PATH Error message to inform the
ingress (originating) router of the problem.
Within the error message, the notifying router (R4 in the example above) also includes an error code that indicates the
source of the problem. The list of error codes can be found in RFC 2205 and RFC 3209, defined for RSVP and RSVP-TE.
When the ingress router (R1) receives the PATH Error message, it puts the LSP into an operationally down state and
sends out a PATH Tear message.
For instance, if router R4 is unable to deliver the PATH message because of a routing problem, it indicates this with an
error code that means No route available toward destination. The LSP operational status will be down on router R1 in
this case, and the show router mpls lsp lsp-name path detail command output can provide a useful hint
to the problems cause.
LSP Name
: to_R6
Path LSP ID : 33288
From
: 10.10.10.1
To
: 10.10.10.6
Adm State
: Up
Oper State
: Down
Path Name
: empty_list
Path Type
: Primary
Path Admin
: Up
Path Oper
: Down
......................
.......................
Failure Code: noRouteToDestination
Failure Node: 10.2.4.4
NOTE: PATH Error messages are also used in the Fast Reroute implementation, which is covered in Module 6 of this
course.
Module 4 Page 36
Path Error Messages
A Reservation Error message may be sent downstream if a router

cannot forward the RESV message any further.
Any sort of reservation failure or a change in the reservation status
can cause the RESV error condition.
Tear may not make it to iLER if link from router R1 to router R2
caused the error.
Module 4 |
37
Normally, an MPLS router runs a sanity check before forwarding the PATH message to the next downstream hop. It
determines whether the destination next-hop is reachable and, when using RSVP bandwidth reservations, if there are
enough resources available.
In the figure above, router R2 performs this check and forwards the PATH message. However, as a result of a
reservation state change or any resource allocation problem, router R2 might not be able to forward the RESV message
upstream. In this case, router R2 sends back a RESV Error message downstream, which is in the opposite direction of
RESV message propagation.
Note that the RESV Error message, much like the PATH Error message, is only informational. It does not affect the
session state on the routers. For this reason, when the egress router (R6) receives the RESV error message, it sends a
RESV Tear message upstream to clear the RSVP sessions that belong to the LSP on all routers.
Module 4 Page 37
Reservation Error Messages
RSVP is a soft state protocol; sessions must be constantly refreshed.

PATH and RESV messages are exchanged between all RSVP
neighbors at periodic intervals.
Sessions time out if they are not refreshed within a certain period.
Module 4 |
38
After the LSP-Path has been established, it must be refreshed periodically to maintain its operational state. As a softstate protocol, RSVP requires a constant refresh of all the RSVP sessions. This is done by using the same PATH and RESV
messages that were initially used to establish the sessions. If certain refresh messages are not received as expected, the
RSVP sessions expire and are cleared to release the occupied resources.
It is important to note that the RSVP state is refreshed at every hop by the PATH and RESV messages generated between
the directly adjacent routers. For each router, in every PATH state, the router generates a PATH message to the nexthop downstream router at every refresh interval. For each router, every time a PATH message is received for a session,
the Path State Block is refreshed and the expiration timer is reset.
In the upstream direction, the RESV message is generated to refresh the Reservation State Block of the RSVP session in
the same manner.
Recall that both the Path State Block and the Reservation State Block need to be actively present for an RSVP session to
stay operational.
Module 4 Page 38
RSVP Session Refresh
Session times out on router R4 due to missing PATH or RESV

message.
Router R4 clears the RSVP session.
PathTear message is sent downstream.
ResvTear message is sent upstream.
Module 4 |
39
Another example of PathTear and ResvTear messages is illustrated above.

If, for any reason, the RSVP session state times out on a router, a proactive approach is required to immediately clear
all the RSVP sessions that belong to the LSP. For this purpose, the router that detected the timeout sends a PathTear
message downstream and a ResvTear message upstream. Both messages are propagated to all the routers along the LSP.
Module 4 Page 39
RSVP Session Timeout PathTear and ResvTear Messages
Configuring the Refresh Time and Keep Multiplier

*A:R1>config>router>rsvp# refresh-time ?
- no refresh-time
- refresh-time <seconds>
<seconds>
: [1..65535]
*A:R1>config>router>rsvp# keep-multiplier ?
- keep-multiplier <number>
- no keep-multiplier
: [1..255]
Refresh Time is locally configurable on each router. It determines

how frequently Refresh messages will be sent.
Applies to all RSVP sessions on the router.
Keep Multiplier is a decimal value that determines the session
timeout interval.
The no form of the commands restores the default values.
Module 4 |
40
The RSVP refresh time configuration on a router determines how frequently refresh messages are sent out of the router.
The refresh time can be locally configured on each router and the refresh timer should be configured consistently on all
the routers to avoid strange timeout issues.
The default value for sending out PATH and RESV refresh messages is 30 seconds.
To keep CLI results simple, the ALU Service Router CLI info command does not display default values. However, the
info detail command output also displays the default values of configuration parameters that are not visible in the
info output.
In addition to sending out refresh messages, a router also expects to receive constant refresh messages from its RSVP
neighbors, to be able to keep sessions active. If a router does not receive any refresh messages within a certain
interval, the sessions time out and the router sends out the appropriate Tear messages, as discussed in the previous
page. The keep-multiplier parameter governs the timeout interval. The keep-multiplier roughly determines how many
missed messages a router can tolerate before declaring a session down.
Section 2 of this module explains the optimizations done on these timers.
The no refresh-interval and no keep-multiplier commands may be used to quickly restore the default values,
if they had been modified.
Module 4 Page 40
<number>
MPLS OAM LSP-Ping and LSP-Trace
*A:R1# oam lsp-ping "to_R6

LSP-PING to_R6: 92 bytes MPLS payload
*A:R1# oam lsp-trace "to_R6

lsp-trace to to_R6: 0 hops min, 0 hops max, 116 byte packets
1
2
3
10.10.10.2
10.10.10.4
10.10.10.6
rtt=3.13ms rc=3(EgressRtr)
Similar functionality as described in Module 3.

The LSP-Name must be specified in the commands.
Module 4 |
41
The operational principles of the LSP-Ping and LSP-Trace commands were explained in Module 3 (LDP) of this course.
The same functionality is used with RSVP-TE tunnels as well, with the major difference being in the syntax. The name
given to the LSP on the originating router must be specified in the commands, instead of with the prefix keyword.
Module 4 Page 41
---- LSP to_R6 PING Statistics ---1 packets sent, 1 packets received, 0.00% packet loss
Section Summary
Introduction to RSVP-TE
LSP establishment using PATH and RESV messages
Configuration prerequisites for RSVP LSPs
RSVP sessions implementing Path State Blocks (PSBs) and
Reservation State Blocks (RSBs)
PATH Tear and RESV Tear messages used to tear down RSVP
sessions
PATH Error and RESV Error messages used to signal error
conditions
RSVP Session Refresh Process
LSP-Ping and LSP-Trace OAM commands
Module 4 |
42
Resource Reservation Protocol has been used in the past to manage reservations for IP flows in the Integrated
Services Quality of Service model.
RSVP Traffic Engineering extensions support advanced MPLS signaling capabilities.
Network interfaces need to be added into the MPLS context to be able to signal RSVP-TE based LSPs.
The router automatically adds MPLS interfaces into the RSVP context.
Both MPLS and RSVP contexts are, by default, administratively disabled; they need to be individually enabled.
An LSP needs at least the egress routers destination IP address and a primary path entry.
A definition can contain explicitly defined hops that regulate the path an LSP takes.
RSVP-TE uses PATH and RESV messages to signal LSPs.
If a path definition contains hop definition, the IGP forwarding table is consulted to determine where the PATH
message will be forwarded to.
A Path State Block is created to store the sent or received PATH message.
PATH and RESV messages contain several objects that contain a range of information.
The PATH and RESV messages HOP object represents the egress interface IP address on which the router sent the
message.
To forward the RESV message back toward the ingress LER, routers use the address stored in their PSBs HOP field.
A Reservation State Block is created to store the sent or received RESV message.
When a PSB and RSB are both present, and ingress and egress labels are allocated, the router creates an RSVP session
to represent the LSP.
An RSVP session type is originate on an ingress router, transit on an intermediate router, and terminate on an
egress router, along the path of an LSP.
Sessions must be periodically refreshed to maintain their active states.
PATH Tear and RESV Tear messages are sent to tear down existing RSVP sessions.
PATH Error and RESV Error messages are sent to signal error conditions.
Module 4 Page 42
Configuring basic LSP Paths and LSPs
Module 4 - Resource Reservation

Protocol
The second section of Module 4 focuses on several features and techniques that optimize failure detection times
without compromising the router performance in RSVP-TE.
Module 4 Page 43
Section 2 RSVP Session-Refresh Optimization
Section Objectives
In this section, we will discuss the several mechanisms used to

optimize failure detection time and router resource consumption:
RSVP-TE Hello Protocol
RSVP Refresh Overhead Reduction
Reliable message delivery using MESSAGE-ID and MESSAGE-ACK
Summary Refresh messages
Module 4 |
44
The default session refresh time is 30 seconds in RSVP. While lowering this timer can yield better failure detection and
convergence results compared to the default, it can also negatively impact the routers processing performance.
To improve detection times without compromising the system performance, several methods have been proposed and
implemented.
The first method that will be discussed is the HELLO extension to RSVP. With this addition, directly connected RSVP
routers build neighbor relationships with each other and track the RSVP sessions running between them.
To prevent all RSVP sessions from being refreshed at the same time, one can set random refresh timers on the RSVP
sessions, as proposed in RFC 2205 Section 3.7.
The Refresh Reduction method, introduced in RFC 2961, reduces the number of refresh messages. It is also explained in
this section.
Module 4 Page 44
Refresh-Time Randomization (RFC 2205 Section 3.7)
To maintain the LSPs state, routers periodically send PATH and RESV
refresh messages.
The global refresh time setting tells the routers when to send refresh
messages; the default refresh time is 30 seconds.
A shorter refresh time allows faster RSVP failure detection but
creates greater CPU overhead.
Module 4 |
45
Recall that the default RSVP refresh-time is 30 seconds, which applies to all RSVP sessions on the router. This means
that every 30 seconds, routers needs to exchange PATH and RESV messages to prevent RSVP sessions from timing out.
Decreasing the RSVP refresh-time may be a tempting alternative for faster detection and convergence. In a network
with a large number of LSPs and RSVP sessions, however, this might present a drawback with the number of messages
and processing involved. More messages mean the router spends more time processing these messages, which could
negatively impact the time the router spends on other processes.
NOTE: A router does not necessarily have to wait for 30 seconds to realize loss of connectivity to a neighbor. There are
now several other lower-level detection mechanisms that can notify all the higher level protocols of physical failures.
The RSVP timeout mechanism can be seen as a last resort measure, in case failures go undetected by lower-level
detection features. More aspects of failure detection and convergence are covered in Module 6
Module 4 Page 45
Impact of Lower Refresh Timers for Faster Detection
A router can potentially have thousands of RSVP sessions.

Normally, each session needs to be refreshed separately, by the
constant exchange of PATH and RESV messages.
Failure detection and reduction of resource consumption need to be
optimized.
Module 4 |
46
As illustrated in the figure above, routers can have a huge number of RSVP sessions in a scaled network. All these RSVP
sessions require periodic refreshes to maintain their active states.
Certain criteria need to be taken into consideration when tuning the system timers. While lowering the timers can
speed up detection and convergence, it can also increase the number of state-refresh messages generated. If the timers
are increased, this drawback is alleviated, but a slower reaction to network failure and longer convergence times can
result.
Operators must balance both performance and resources for these scenarios. Several aspects of this issue are presented
later in the section.
Module 4 Page 46
The Need for RSVP Session Refresh Optimization
Hello protocol was introduced to speed up convergence without

reducing refresh time.
Routers exchange Hello messages on each RSVP-enabled interface.
The default Hello timer value is 3 seconds.
Upon missing several Hello messages, the neighbor is declared down,
and all RSVP sessions related to that neighbor are cleared.
Module 4 |
47
As explained on the previous page, decreasing RSVP refresh times is not always recommended because, if there are
many RSVP sessions, it can result in a large number of session-refresh messages needing to be exchanged.
The Hello Protocol was introduced to RSVP-TE to alleviate this problem. It is inherited from link-state routing protocols,
such as OSPF and IS-IS, and, with it, directly adjacent RSVP enabled routers can exchange RSVP Hello messages and
build a neighbor relationship.
Alcatel-Lucent Service Routers are enabled to exchange RSVP Hello messages, by default. In a process that is slightly
different from link-state protocols, routers begin sending Hello messages only after there is at least one active RSVP
session running on the interface. If there are no active sessions, no Hello messages are sent. However, once the Hello
mechanism is initiated, it continues to run indefinitely, even after all the active sessions go down.
The keep-multiplier value configured in the global RSVP context also applies to RSVP Hello protocol. The keepmultiplier determines how many hello messages must be missed before a router declares a neighbor down. In case of a
hello timeout, ALL the RSVP sessions running on that interface are cleared.
By default, RSVP Hello messages are sent every 3 seconds.
Module 4 Page 47
RSVP-TE HELLO Protocol
Configuring the Hello-Interval
*A:R2>config>router>rsvp# interface to_R6

*A:R2>config>router>rsvp>if# hello-interval
- hello-interval <milli-seconds>
- no hello-interval
: [0..60000] - only multiples of 1000 allowed
Hello Interval is configurable per interface.

The default value is 3000 milliseconds (3 seconds).
The no form of the command restores the default value.
Setting the value to zero disables the Hello mechanism.
Module 4 |
48
The RSVP-TE Hello extension is configured on a per-interface basis. If two routers have more than one IP routing
interface between them, each link needs a separate Hello adjacency.
The Hello Interval is configurable in multiples of 1000 milliseconds. The default value is 3000 milliseconds, or 3 seconds.
If the Hello Interval value is changed and the default value needs to be restored, the no hello-interval command
form can be used to easily accomplish this. This is equivalent to typing hello-interval 3000 in the configuration.
It is also possible to disable sending hello messages on an interface by setting the hello-interval value to zero.
Module 4 Page 48
<milli-seconds>
Verifying RSVP neighbors
Neighbors remain Up by the constant receipt of Hello messages.

The keep-multiplier value in the global RSVP context
(configure>router>rsvp>) also determines the Hello Timeout value.
Hello Timeout = Hello-Interval x Keep-Multiplier
Default Timeout = 3000 ms x 3 = 9000 ms.
Module 4 |
49
The neighbor adjacencies that are established using RSVP Hello messages can be verified with the show router rsvp
neighbor command.
The keep-multiplier in the global RSVP configuration (not per-interface) can be used to determine the Hello timeout
value, and the RSVP session timeout.
A router needs to constantly receive Hello messages from its neighbor to keep the adjacency up. A neighbor becomes
down if no Hello messages are received within the timeout interval. This is 9 seconds, by default.
Module 4 Page 49
*A:R2# show router rsvp neighbor

===============================================================================
Neighbor
Interface
Hello Last Oper
Flags
Change
===============================================================================
10.1.2.1
toR1
Up
0d 01:04:00
10.2.4.4
toR4
Up
0d 01:04:00
------------------------------------------------------------------------------Neighbors : 2
===============================================================================
Refreshing all (or many) RSVP sessions at the same time

(synchronization) should be avoided.
Each time, the refresh-time transmit interval is set to a random value
in the 50%-150% range of the configured value.
The effective refresh timeout is also increased to accommodate this.
Module 4 |
50
If a router has a large number of active RSVP sessions, refreshing all (or many) of them at the same time can cause a
sudden burst of message traffic and CPU processing. To avoid any possible side effects to this, RFC 2205 proposes a
level of randomness when sending out refresh messages for RSVP sessions.
After sending each refresh message, the interval to send the next refresh message is set to a random value in the 50%150% range of the configured refresh-time value.
The effective session refresh timeout is not a direct factor of the keep-multiplier value, to avoid any premature loss of
state. In principle, the timeout must satisfy the following condition:
Session Timeout (Keep-Multiplier + 0.5)*1.5*Refresh-Time
According to the formula above, and with the default values of the Refresh-Time (30 s.) and Keep-Multiplier (3), the
session timeout should be set to at least 157.5 seconds after each successful refresh.
Module 4 Page 50
Session Refresh Time Randomization
Displaying Refresh Timers and the PSB (Path State Block)
PSB CurrState: PRIMARYS_CONNECTED PrevState: PRIMARYS_INIT Flags: 0x0

LocalLabel 131062 OutLabel 131064
Incoming IfIndex: toR1(2)
Refresh interval 30, Send Path refresh in 36 secs, Path Refresh timeout 154 secs
Send Resv refresh in 28 secs
PrevHop: Addr -> 10.1.2.1 LIH 2
DnStream Nbr: Addr-> 10.2.4.4 IfIndex toR4(3)
UpStream Nbr: Addr-> 10.1.2.1 IfIndex toR1(2)
The above command displays the Path State Block (PSB) for the
established RSVP session on a transit router.
The next Path Refresh message will be sent in 36 seconds (higher
than the configured interval of 30).
The Path Refresh timeout is reset every time a PATH message is
received.
Module 4 |
51
A Path State Block (PSB) is created for each RSVP session on all the participating routers, as explained in the first
section. PSB stores the original PATH message as well as the relevant timers to refresh the session.
The command output shown above displays the contents of the PSB on router R2, which is a transit LSR for the LSP in
the case study example.
The values in the Session object are To: 10.10.10.6 - 1 - 10.10.10.1, where 10.10.10.6 is the tunnel destination, 1 is
the Tunnel ID, and 10.10.10.1 is the tunnel source IP address.
The Previous Hop IP address is 10.1.2.1, as advertised by router R1 in the PATH message.
The output PSB CurrState: PRIMARYS_CONNECTED states the session is currently connected, which indicates the
session is active. The keyword PRIMARY has no relation to the LSP-Path type as primary or secondary. It is relevant to
the RSVP state machine only.
The current state of the timers related to session refresh can also be seen in the PSB output.
The configured refresh interval is 30 seconds, which is the default value.
The time left to send the next PATH refresh message can indicate the operator modified the refresh timeout mentioned
in the previous page.
The output indicates that the session will timeout if no refresh message is received within 155 seconds, which
corresponds with the formula presented on the previous page.
Module 4 Page 51
*A:R2# tools dump router rsvp psb detail

-------------------------------------------------------------------------------PSB:
P2P: Session (To: 10.10.10.6 - 1 - 10.10.10.1), Sender (10.10.10.1 - 57586) PHop 10.1.2.1
RSVP Refresh Overhead Reduction
Recommended in RFC 2961.

Its purpose is to reduce the RSVP messaging overhead.
Maintains the states of all RSVP sessions and can quickly detect
message loss or network failures.
Introduces a new object: Message-ID
A Summary-Refresh message replaces all subsequent refresh
messages (PATH and RESV) for all active sessions.
The Summary-Refresh message contains a list of the Message-IDs
of all active sessions
If Reliable Delivery is also enabled, the initial RSVP messages
during LSP establishment are ACKnowledged.
Module 4 |
52
Recall that RSVP is a soft-state protocol that requires constant PATH and RESV refresh messages on every LSP-Path that
is established. This may cause scalability issues when there are many RSVP sessions on a router. The router must handle
thousands of PATH and RESV messages, especially during a network failure. Too many incoming messages may cause a
system message queue overflow. Delay or loss of messages may cause the LSPs to go operationally down and interrupt
the data traffic. The routers CPU and memory resources may also be exhausted because of large numbers of messages
being processed.
RFC 2961 describes some RSVP-TE extensions that reduce the RSVP messaging overhead while maintaining the states of
all LSP-Paths and the ability to quickly detect message loss or network failures.
The refresh-reduction feature can be enabled on a hop-by-hop basis. Both peers must agree on the refresh-reduction
capability before the feature can be used.
The refresh-reduction feature is disabled by default. When enabled on an interface, the router includes a Message ID to
all the outgoing RSVP messages. The Message ID is an integer that easily and uniquely identifies an RSVP session.
When both sides are enabled for refresh-reduction, the individual PATH and RESV messages are replaced by a single
Summary Refresh message. The Summary Refresh message contains a list of only the Message IDs of the active sessions
between the two routers.
The refresh-reduction feature also has an option called reliable-delivery. When enabled, the first RSVP messages used
to establish the session are explicitly acknowledged to ensure that the messages are received by the other end without
problems. Summary Refresh messages are not subject to this mechanism; that is, they do not need to be acknowledged.
These steps are detailed in the following pages.
Module 4 Page 52
Both RSVP neighbors need to be Refresh Reduction capable.
When the refresh-reduction feature is enabled, a unique Message-ID

per RSVP session is included to all RSVP messages (except Hello).
An Acknowledgement can be requested from the neighbor to confirm
the delivery of individual messages.
If the neighbor supports the feature, it sends back an ACK message
that includes the Message ID of the received message.
If a change occurs in the session state, the Message-ID is
incremented.
Module 4 |
53
When the refresh-reduction feature is enabled on a router, it starts sending all the RSVP messages (except Hello) with a
unique Message ID object.
The format of the Message ID object as defined in RFC 2961 can be seen below. The total length of the Message ID
object is 8 bytes.
The Message Identifier integer value is contained within a 4-byte field.
RSVP sessions are given Message Identifier values, starting from 1. The Message Identifier value is incremented if there
is a change in the operational or reservation state of a session. This way, the receiving router is notified when the RSVP
contents are changed.
8 bits are allocated for the Flags field. When the value of this field is set to 0x01, it means that the sending router
requests an acknowledgement for the message that it sent. This is optional, as explained in the previous page.
The Epoch field contains a value that indicates when the Message Identifier sequence has been reset. It is a random
value and only changes when the router reboots or the RSVP process is reset.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Flags
Epoch
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Message_Identifier
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Module 4 Page 53
Message ID and Reliable Message Delivery
If no ACK is received within the rapid-retransmit-timer interval,

the message will be re-sent up to the rapid-retry-limit number of
times.
Module 4 |
54
If the reliable-delivery option is enabled, the sending router requests an acknowledgment from the other party.
A timer is introduced to regulate the time to re-send the message, in case an acknowledgment is not received. This
interval is controlled by the rapid-transmit-interval setting.
The rapid-retry-limit setting determines up to how many times the message should be retransmitted if the
acknowledgment is not received.
If two peers set different capabilities, that is one node is refresh-reduction-capable bit while the other is not, the
refresh reduction capable node will still attempt to perform reliable message delivery with its peer. In this case, the
RSVP session still succeeds, but the peers exchange no acknowledgements.
The routers indicate if they are refresh reduction capable in the RSVP message header.
Module 4 Page 54
Rapid Retransmit Timer and Retry Limit
When both RSVP neighbors are enabled for Refresh Reduction, only a
Summary Refresh message is exchanged; individual PATH and RESV
(and ACK) messages are not needed to refresh each session.
The Summary Refresh message contains a list of the Message-IDs of
all the RSVP sessions running on that interface.
Module 4 |
55
The Refresh-Reduction feature decreases the number of refresh messages that are sent between RSVP neighbors.
When both neighbors are enabled for Refresh Reduction, and after they successfully negotiate this capability, the
routers start sending a single Summary Refresh message instead of individual PATH and RESV messages. This is a new
and more efficient way of refreshing the RSVP states of LSPs. The Summary-Refresh message uses only the Message
Identifier value received from the RSVP messages within the Message ID object. This significantly reduces the signaling
cost, since the Message Identifier is 4 bytes while the PATH message is usually a few hundred bytes per LSP-Path.
RFC 2961 states: Each Summary Refresh message MUST occupy exactly one IP datagram. If it exceeds the MTU
(Maximum Transmission Unit) of the link, the datagram is fragmented by IP and reassembled at the recipient node.
Module 4 Page 55
RSVP Refresh Reduction Summary Refresh Message
Configuring Refresh-Reduction and Rapid Retransmit Parameters
*A:R1>config>router>rsvp# interface "toR2"

---------------------------------------------refresh-reduction
reliable-delivery
Configured per RSVP interface

Enable Message-ID & Summary Refresh
Request ACK (Optional)
exit
----------------------------------------------
<hundred-milliseco*> : [1..100]
*A:R1>config>router>rsvp# rapid-retry-limit
- no rapid-retry-limit
- rapid-retry-limit <limit>
<limit>
: [1..6]
Restore default
Default: 5 (500 ms)
Restore default
Default: 3 (retries)
Module 4 |
56
The Refresh-Reduction feature must be configured on an interface basis. A router can use Summary Refresh messages
with one neighbor, and choose to not use the feature with another neighbor, depending on the neighbors capabilities.
Reliable-delivery is an optional setting that makes the sending router request acknowledgment for the individual PATH
and RESV messages that are sent. Note that when both neighbors start exchanging Summary Refresh messages,
individual PATH and RESV messages are no longer sent to refresh the sessions, so the acknowledgment mechanism is not
needed beyond that point.
The rapid-retransmit-time and the rapid-retry-limit are set under the global RSVP context, applying to all interfaces.
(The use of these commands was explained in the previous pages.)
NOTE: If the msg-pacing feature is enabled in the RSVP context, the Reliable Message Delivery feature cannot be used;
both features cannot coexist on a router. RSVP Message Pacing is a rate-limiting function that controls the burst of RSVP
messages. The below configuration snippet provides an example:
*A:R1>config>router>rsvp#info
---------------------------------------------msg-pacing
period 1000
max-burst 1000
exit
..................
---------------------------------------------The max-burst parameter defines the number of messages that can be sent out per interval. The period parameter
defines that interval in milliseconds. This sample configuration limits the RSVP message rate to 1,000 messages per
second. This feature is mutually exclusive from the reliable-delivery feature.
Module 4 Page 56
*A:R1>config>router>rsvp# rapid-retransmit-time
- no rapid-retransmit-time
- rapid-retransmit-time <hundred-milliseconds>
*A:R1# show router rsvp neighbor

===============================================================================
RSVP Neighbors
===============================================================================
Legend :
LR - Local Refresh Reduction
RR - Remote Refresh Reduction
LD - Local Reliable Delivery
RM - Remote Node supports Message ID
===============================================================================
Neighbor
Interface
Hello Last Oper
Flags
Change
===============================================================================
10.1.2.2
toR2
Up
0d 03:23:06
LR LD RR RM
------------------------------------------------------------------------------Neighbors : 1
===============================================================================
The command output above contains Flags that indicate the

Refresh-Reduction capability on the local and the neighbor router.
Module 4 |
57
The LR flag is set when the local router has the refresh-reduction feature enabled.
The LD flag is set when the local router has the reliable-delivery option enabled.
The RM flag indicates that the neighbor (remote node) supports the Message ID implementation.
The RR flag is set when the neighbor sets the Refresh-Reduction-Capable bit in its RSVP messages, as shown in the
packet capture in the previous page.
Module 4 Page 57
Verifying Refresh-Reduction capability in the CLI
Module 4 |
58
Lab 4 IGP-Based RSVP LSP Establishment
Module 4 Page 58
Section Summary

RSVP Hello Extensions
RSVP Refresh Overhead Reductions
Message ID
Reliable Delivery Using ACK Messages
Summary Refresh Messages
Module 4 |
59
The Hello feature was introduced into the RSVP-TE protocol as an extension to monitor the health of the RSVP
interface.
The RSVP-TE Hello protocol uses Hello packets to constantly check the RSVP adjacency over the RSVP interface.
If the RSVP Hello protocol times out in an RSVP interface, all RSVP sessions running on that interface are cleared,
and the corresponding LSP is rerouted or torn down.
With the RSVP-TE Hello protocol, the RSVP sessions can have longer refresh intervals and rely on the Hello protocol
to detect RSVP adjacency failures, if they are undetected by lower-level mechanisms.
Several techniques are involved in the reduction of the RSVP session refresh overhead:
Randomizing the refresh timers to prevent all or many of the RSVP sessions from being refreshed at the
same time. This is an internal optimization and is transparent to the user.
Reliable RSVP message delivery using ACK messages.
Summarizing RSVP refresh messages to reduce overhead.
When refresh reduction is enabled, the refresh-reduction capability is negotiated between each RSVP peering interface
using Flag values inside the messages. The feature is used only if both sides can support it; otherwise, the routers ignore
the flags and Message IDs.
Module 4 Page 59
RSVP Refresh Time Randomization
Module Summary
RSVP is a signaling protocol that defines procedures for signaling

constraints and reserving the necessary downstream resources to
provide a requested service to all nodes along a data path.
RSVP makes use of two main message types to establish tunnel
reservations, the Path Message and the Resv Message.
RSVP with Traffic engineering extensions provides the following

MPLS benefits:
y Administratively define LSP paths
y Signaled constrained-path LSPs using link colors, bandwidth
reservations, hop limits, and other characteristics
y Secondary paths and fast reroute
y Connection admission control (CAC)
RSVP can work either with explicit paths or with paths discovered
by CSPF and IGP.
Module 4 |
60
Module 4 Page 60
An RSVP-TE LSP can have a primary and up to 7 secondary paths, or

8 secondary paths.
An RSVP session consists of a PSB and RSB maintained on each
router.
Routers use tear and error messages to update the reservation
state.
Hello and refresh messages maintain the reservation state and

identify errors.
Refresh-time randomization ensures that routers do not send out a
burst of refresh messages at regular intervals.
Summary refresh messages use Message IDs to refresh multiple
RSVP session with a single packet.
Module 4 |
61
Module 4 Page 61
Learning Assessment
1. What are the two message types used by RSVP to establish a

tunnel session?
2. What label advertisement mode does RSVP-TE use?
4. Where does RSVP look for find the path it uses to forward
messages?
5. Which RSVP terms describe the iLER and the eLER?
6. RSVP PATH and RESV messages flow in which directions?
7. True or False: Placing interfaces into the MPLS context
automatically enables MPLS and RSVP.
8. What hop definition combinations can an RSVP LSP path include?
Module 4 |
62
1. What are the two message types used by RSVP to establish a tunnel session?
Path Message and Resv Message
2. What label advertisement mode does RSVP-TE use?
3. What RSVP object reduces refresh message processing by allowing the receiver to easily identify a message that
contains unchanged state information?
The message ID object reduces refresh message processing.
4. Where does RSVP look to find the path it uses to forward messages?
FIB
5. Which RSVP terms describe the iLER and the eLER?
In RSVP terminology, the iLER is the head-end router and the eLER is the tail-end router.
6. RSVP PATH and RESV messages flow in which directions?
RSVP PATH messages flow downstream, and RESV messages flow upstream.
7. True or False: Placing interfaces into the MPLS context automatically enables MPLS and RSVP.
False
8. What hop definition combinations can an RSVP LSP include?
An RSVP LSP path definition may include both loose and strict hops, or none at all.
Module 4 Page 62
3. Which RSVP object reduces refresh message processing by

allowing the receiver to easily identify a message that contains
unchanged state information?
9.
What two components must be defined when building an LSP?
10. What addressing format does an RSVP path message use?

11. Why does a router create a PSB?
13. Which two messages take down RSVP RESV and PATH sessions,
respectively?
14. RSVP routers exchange _______ messages to maintain active
RSVP sessions.
15. True or False: A router sends a Hello to set up an RSVP
adjacency.
9.
Module 4 |
63
What two components must be defined when building an LSP?

An LSP needs, at a minimum, a tunnel destination address and a path definition.
10. What addressing format does an RSVP path message use?

An RSVP path message uses end-to-end addressing.
11. Why does a router create a PSB?
Because the PSB stores all the path message details that allows the router to identify the corresponding RESV
message and forward it upstream.
12. Which three combined values identify a unique RSVP session?
The combined Tunnel ID, LSP ID, and session name identify a unique RSVP session.
13. Which two messages take down RSVP RESV and PATH sessions, respectively?
RSVP RESV and Path Tear messages take down RSVP sessions, while error messages report RSVP resource problems.
14. RSVP routers exchange refresh messages to maintain active RSVP sessions.
15. True or False: A router sends a Hello to set up an RSVP adjacency.
False.
Module 4 Page 63
12. Which three combined values identify a unique RSVP session?

Switching
Module 5 - Page 1
Module Objectives

to:
Discuss MPLS Traffic Engineering features, including:
y MPLS TE in a flat network (single IGP area)
y MPLS TE in a hierarchical network (multiple IGP areas)

y MPLS shortcuts for IP forwarding
Module 5 |

This module takes an in-depth look into the Traffic Engineering features offered by RSVP-TE.
With MPLS Traffic Engineering, network operators get access to an abundance of features to have better administrative
control over the traffic flows in their network.
The last two sections of the module deal with special Traffic Engineering related solutions such as MPLS TE over
multiple IGP areas and using the MPLS tunneling feature to forward native IP traffic.
Module 5 - Page 2
y MPLS bandwidth management features
Module 5 MPLS Traffic Engineering
Section 1 MPLS Traffic Engineering Fundamentals
Module 5 - Page 3
Section Objectives

Review the drivers for Traffic Engineering (TE)
Understand how these attributes are signaled via IGP (OSPF and
IS-IS TE extensions)
Discuss the operation of CSPF (Constraint-Based Shortest Path
First) algorithm.
Discuss the use of ERO (Explicit Route Object) for signaling TEbased LSP paths.
Module 5 |
This section first makes a generic introduction to MPLS Traffic Engineering concepts and methods.
Additional information that can be attributed to network links and propagated in IGP updates are presented.
The protocol extensions that have been made to both link-state protocols (OSPF and IS-IS) are shown.
The section takes a progressive approach by first presenting the high-level MPLS TE approaches and then demystifying
the real solutions in step-by-step manner.
The internal processes of the routers as to the use of the additional IGP attributes are also presented with a simplified,
cognitive approach. The modified version of the Shortest Path First (SPF) algorithm that is used for TE purposes (CSPF)
is explained in detail.
RSVP-TE takes a different approach in signaling the LSP paths calculated by CSPF than presented in Module 4. The
Explicit Route Object that ensures the CSPF calculated path messages traverse the correct desired hops is explained at
the end of the section, after the CSPF calculation procedures are understood.
Module 5 - Page 4
Discuss the additional information required in TE (administrative

constraints).
Traffic Engineering Introduction
Traffic Engineering basically refers to the techniques used to

manipulate traffic flows in the network to:
y Optimize resource usage by utilizing redundant links
y Avoid potential congestion points and packet drops in the

network
Module 5 |
Optimizing the network resource usage is a major concern among the operators to protect their investments and
maximize their revenues, while providing the desired level of service qualities to their customers.
To accomplish this, the operators often require certain set of tools to engineer the traffic patterns in the network to
match certain needs. If the network lacks adequate capacity planning and a flexible, future-proof design; bottlenecks
(congestion points) may easily arise resulting in packet loss and degradation in the service qualities offered to
customers.
Module 5 - Page 5
y Administratively define traffic paths based on various

constraints
Possible Hyperaggregation Solutions without MPLS
Add more bandwidth (buy new links)

y Drawbacks:
Expensive
Some links might still be underutilized
Modify IGP costs to allow for load balancing

y Drawbacks:
Almost impossible to find a solution for all traffic
Hard to manage and not scalable
Use Policy-Based Routing at each hop

y Drawbacks:
Very complicated to implement and maintain
Prone to errors and routing loops
Module 5 |
As we mentioned in Module 1, MPLS can help solve hyperaggregation issues. To overcome the bottleneck, certain
solutions outside of the MPLS context may be employed, along with their shortcomings.
Placing bandwidth wherever there is a traffic requirement is called Traffic Management; this is one approach to the
hyperaggregation problem. In the network planning phase, designers must carefully assess traffic patterns to provide
proper predictions of future network usage, and the underlying transport network should reflect these pre-assessments.
However, transport circuits can be very expensive resources, and bandwidth requirements at different parts of the
network might also change over time. Therefore, network engineers must closely monitor resource requirements in the
case any expansion circuits are needed. All these factors make overall bandwidth planning a strategic task.
Another solution might be to adjust the links IGP costs to allow for load-balancing solutions, such as ECMP. The
problem with this approach, however, is that no solution can fit all possible network patterns between every source and
destination pair combinations. With the addition of new links or failure of existing ones, this solution can easily fall into
pieces.
One other technique that might be used to steer the traffic flows to desired destinations is policy-based routing. With IP
forwardings hop-by-hop nature, network designers can implement traffic control entities, called policies. At each hop,
redirecting the traffic to different hops in an attempt to equally distribute the aggregate bandwidth or to minimize
delay for time-sensitive traffic. Even in a small network, this method can quickly become unmanageable and nonscalable, requiring that the operators manually modify the policy entries each time a new demand arises. Even if the
administrator deploys special automation tools to streamline the processes, risks of configuration errors causing traffic
black-holing or loops are high.
Module 5 - Page 6
Traffic patterns might change over time
Traffic Engineering with MPLS (RSVP-TE)
RSVP-TE can bring the following benefits, in terms of Traffic

Engineering:
y The ability to administratively define customized LSP Paths.
y The ability to make bandwidth reservations for LSPs CAC

(Connection Admission Control) functionality.
Module 5 |
When a service provider chooses MPLS along with RSVP-TE signaling, they have an abundance of Traffic Engineering
features at their disposal.
As discussed, controlling the paths of traffic flow is a difficult task using IP forwarding, because of the inherent hop-byhop nature of the protocols. RSVP-TE offers easily configured and maintained solutions by extending the capabilities of
the existing protocols and introducing new implementations around them.
Traffic engineering extensions to certain IGPs introduce enhancements to the existing routing protocols, which allow
them to carry additional link information no longer limited to IGP costs only. These extra characteristics, called link
constraints, allow the operator to automate the path determination process in a way more advanced than policy-base
routing can provide.
RSVP with Traffic Engineering, or RSVP-TE, brings a tactical Traffic Engineering approach. By allowing network
operators to reserve LSP bandwidth, for example, capacity planning can make easier traffic load distribution easier.
This approach puts the traffic where the available bandwidth is, as opposed to adding more bandwidth.
In resiliency terms, RSVP-TE allows pre-established LSP protection paths that can promptly react to network failures.
The shorter convergence times offered by these resiliency features, including secondary LSP paths and Fast Reroute
techniques, easily surpass convergence times that an IGP alone can achieve. This courses last module discusses several
TE resiliency features and MPLS protection mechanisms in great detail.
Module 5 - Page 7
y The ability to use additional link constraints other than IGP

cost, to make advanced path calculations.
The entire LSP path can be manually defined by Head-End.

High administrative control vs. configuration overhead.
Fixed Path configuration LSP path cannot be established if a node
or link along the strict path is down.
Module 5 |
One RSVP-TE approach allows an administrator to specifically define the path that an LSP shall take, using RSVP-TE
strict hop path definitions.
The operator may define the entire LSP path. As an example, the operator can define the following LSP path: The LSP
shall originate on router R1, go through routers R3 and R5 and finally terminate at router R6. This manually defined
strict path may differ completely from that which the IGP might have chosen. This option gives the ultimate
administrative control in steering the traffic path.
However, this method also requires the administrator manually define all the LSP hops. In a large network with a many
LSPs, using all strict hop paths can impose a high burden on the operational personnel. Any changes, additions and
deletions require manual intervention.
A strict hop LSP path configuration is a fixed definition, requiring the LSP to go over an exact set of hops. If one of the
defined links or nodes becomes unavailable, the LSP cannot forward traffic. RSVP-TE resiliency techniques, presented in
Module 6, However, can overcome this limitation.
Module 5 - Page 8
Strict LSP path Definitions
RSVP-TE Path Calculations using Constraints
Advanced Path Calculations can be made using additional

constraints including:
y Bandwidth Reservation Information
y Explicit Route (strict and loose hops)

y Shared Risk Link Group (SRLG)
Also called source-based forwarding because the LSP Head-End
dynamically calculates and signals the entire path.
Module 5 |
Rather than administratively defining the entire LSP path, an administrator can control an LSPs path by defining and
assigning a constraint to the LSP. Constraint-based forwarding automates the path definition processes and simplifies
administrative tasks. Well-defined algorithms are embedded into computers or machines to perform mundane,
repetitive tasks, and can support constraint-based forwarding paths.
For instance, the standard Shortest Path First (SPF) algorithm uses a constraint when calculating the routes in a network
the links cost. The cost is usually a function of the links bandwidth, and in general, the higher the links bandwidth,
the lower the cost. The routers choose the lowest cost link from themselves to the destination network as the best
path.
Using the link bandwidth as a sole path calculation constraint limits your options, however. Accordingly, network
operators may want the routers to consider other characteristics when choosing the best forwarding path, such as
bandwidth availability or path delay characteristics. Administratively defined constraints allow the network designer to
categorize certain links by these additional constraints to better streamline the path selection process.
Available constraints include those listed here:
Bandwidth reservations specifying a certain bandwidth amount the LSP requires on a specified path
Administrative groups also known as link coloring, specifying links that we either do or do not want the LSP to use
Hop limits limiting the number of hops over which the LSP path can transport traffic from head end to tail end
Explicit hops specifying either strict (have to go there directly) or loose (have to go there eventually) hops as part
of the path definition
Shared Risk Link Groups (SRLG) telling the head end to exclude from a backup path any links already used by the
primary path
Though not all inclusive, this list demonstrates the network design options that RSVP-TE offers the network operator.
The rest of this section discusses techniques that facilitate the advanced path determination process at the Head-End of
the LSP traffic. This source-based forwarding concept is completely opposite of IP forwarding, which totally revolves
around the idea of destination-based routing.
Module 5 - Page 9
y Administrative Groups (Link Colors)

y Hop Limit
A bandwidth constraint can be specified in LSP configuration.

Router R1 looks for an available path.
RSVP-TE signals the calculated path with the specified bandwidth.
Module 5 |
10
Using RSVP-TE, an operator may set LSP bandwidth reservations as a constraint with which it can control traffic flow in
the network. The operator manually assigns to the LSP a predicted, fixed bandwidth requirement, and the network
operator must first determine the value. This value may be based on a customers Service Level Agreement (SLA), or
based on predicted maximum, or average bandwidth use.
The LSP Head-End uses a links unreserved bandwidth amount to determine if that link is a possible candidate to
support the LSP. The head end eliminates the links which do not match the constraint from consideration, choosing the
best path from those left. From those remaining links, the head end signals the LSP over the IGPs chosen best of the
remaining paths to the destination.
Module 5 - Page 10
RSVP-TE Bandwidth Reservation
Bandwidth reservations are done in control plane only.

Actual bandwidth utilization in data plane not considered.
Operators must also enforce correct QoS policies in the network
design.
Module 5 |
11
At this point, the RSVP-TE bandwidth reservation is purely a control plane mechanism. That is, when the Head-End finds
an available LSP path and requests bandwidth on that path, the router control plane tentatively reserves the
bandwidth.
This reservation only applies to the initial LSP setup and does not consider potential congestion in the data plane. If an
available path is found with a sufficient amount of unreserved bandwidth, the LSP is established over those links;
however, the routers do not enforce the bandwidth reservation constraint on the data plane, where packet processing is
performed. Hence, possible congestion scenarios might arise where an LSP forwards more traffic than they reserved on
a link.
To address this concern, the Alcatel-Lucent Service Routers support granular and highly scalable Quality of Service
(QoS) policies that can be applied at every congestion point in the network. On a packet level, the routers prioritize
traffic and service it in different hardware queues to attain different service quality levels, which are applied on the
routers data plane.
Best network design practices dictate that the operator use congruent QoS and Bandwidth reservation policies for
better network resource usage predictability.
Module 5 - Page 11
RSVP-TE Bandwidth Reservation vs. Quality of Service
Router R1 looks for an available path for LSP-2.

LSP path is calculated and signaled on the redundant links.
Module 5 |
12
In this slide, an operator is setting up an LSP on router R1, targeting router R6. The operator wants to reserve 600 Mbps
of bandwidth for the LSP.
Using RSVP-TE, router R1 automatically searches for a network path that satisfies the required bandwidth constraint.
As we see, LSP1 has already reserved 600 Mbps of bandwidth on the networks upper links. On these links, only 400 Mbps
is left to be reserved. LSP2 needs more that 400 Mbps.
Thus, router R1 eliminates from consideration the top links and discovers that the lower links have sufficient unreserved
bandwidth to support the LSP. Router R1 then signals an LSP path traversing those links.
The unreserved bandwidth figures in the diagram are those that exist before router R1 establishes LSP2. Once LSP2
becomes operational, the network routers advertise the remaining link bandwidths.
Module 5 - Page 12
Dynamic Path Calculation Using Bandwidth Constraints
Administrative groups (colors) can be defined on links.

Grouping can be made on any arbitrary criteria.
Head-end can calculate a path that go through or avoid links with
certain criteria.
Module 5 |
13
RSVP-TE allows an operator to combine links that share similar characteristics into administrative groups. Admin groups
can be defined based on any physical or logical constraint that reflect the characteristics of the links.
An example is a network composed of all 1Gbps transmission links. From an IGP perspective, the cost values of these
links are typically the same. In other words, from the standard SPF algorithm perspective, they are all of equal value.
However, some of these links might be satellite links with variable delay characteristics. The operator would prefer that
delay sensitive traffic, such as voice, follow an LSP path that avoided these links. If the operator increased the links
IGP cost, all traffic would go around these links, including time-insensitive traffic which could be transmitted over the
satellite links without notable service degradation.
If the satellite links in this example are made members of the same administrative group, the operator can set a
generic path statement that directs the routers to look for a suitable path excluding the links in that administrative
group.
Administrative groups are also called link colors to provide an intuitive way with which to work with them. Links can be
associate with different colors and later be referred to as green links, blue links, and so on. The routers can then
be configured to include or exclude those links in calculating the LSP paths.
While providing great flexibility, administrative group definitions have to be carefully designed and incorporated in the
network. Errors in the group definitions might result in situations where the Head-End cannot successfully signal certain
LSPs because the router is unable to find a suitable constrained path for them.
Module 5 - Page 13
Administrative Groups (Link Colors)
A hop-limit can be imposed on the LSP path.

A path is considered ineligible if it does not meet the hop-limit
constraint (even though it has a better IGP metric).
The hop-limit count includes the head-end router.
Module 5 |
14
An operator might wish to impose a limit on the number of routers an LSP path can traverse. For example, they may
want to limit the total delay experienced by applications handling time-critical (real-time) traffic.
In the figure above, the upper path R1-R2-R4-R6 has an overall IGP cost of 300.
If a hop-limit of 3 is imposed on the LSP that is being established on router R1, router R1 will not consider this upper
path because it involves 4 hops, including the originating (source) router.
The only remaining possible path then is the lower path, consisting of 3 hops.
Despite its high IGP cost, router R1 chooses this path as matching the constraints set on the LSP path, and uses it to
forward the LSPs traffic.
Module 5 - Page 14
Hop-Limit
A TE (Traffic Engineering) metric can be defined on links that may be

different than the IGP metric (default: equal).
The Head-End can alternatively use the TE-Metric in calculating the
LSP path.
Module 5 |
15
The IGP metric usually represents link bandwidth. Though this metric is useful in many cases, an operator might want to
use separate traffic-engineering metric values on specific links.
Following a similar example as on the previous page, the upper path R1-R2-R4-R6 consists of links with low IGP cost
values (higher physical bandwidth). The total upper path IGP cost is 300, which is much better than the lower path cost
of 2000. Therefore, under normal circumstances, all traffic tends to flow through the upper links.
However, some of the links in the upper portion of the topology might be satellite links with statistically higher delay
and jitter (delay variation) characteristics. To reflect these delay properties, the network administrator may assign to
these links a custom, separate Traffic Engineering (TE) metric that is higher than the other links IGP metrics.
Router R1 takes these TE metric values into account when calculating an LSP path planned to support real-time traffic
applications. While all other traffic types follow the upper path, the real-time traffic follows the lower path based upon
the lower TE metric.
Module 5 - Page 15
TE-Metric
Allows us to create secondary and/or FRR LSP paths that are

automatically disjointed from the primary path for maximum
resiliency.
Module 5 |
16
Shared Risk Link Group (SRLG) is a concept similar to administrative groups presented earlier. Again we create groups
and assign links to those groups, but here we are controlling how the head end builds backup LSP paths. SRLG is
particularly useful in providing the maximum level link redundancy when using either one of, or both of the secondary
path or Fast Reroute LSP protection mechanisms.
SRLG works as follows:
1. Router R1 establishes a primary LSP path that will carry the LSP traffic as long as it is operational. The primary
LSP path might travel down links the router choose based on administrative constraints such as bandwidth or hoplimit; however, the primary path does not consider the SRLG constraint.
2. Router R1 then analyzes the primary LSP path. The router checks the primary LSP path to see if any links are a
member of any Shared Risk Link Groups assigned to them beforehand. In the example above, the primary LSP path
links are members of the SRLG-1 group.
3. When calculating a secondary LSP path or a Fast-Reroute protection tunnel path; the routers try to find a path
that does not go over any of the links that are a member of SRLG-1.
This allows the protection tunnel paths to be automatically disjointed from the primary LSP path. If one of the links on
the primary LSP path fails, there could be a possibility that other links in the same SRLG might fail as well, possibly due
to the underlying transmission media characteristics. SRLGs ensure that the secondary or FRR protection tunnels follow
a different path than the primary so that the LSP finds a viable path over which to forward its traffic.
Module 6 introduces secondary and fast reroute protection, where the use and application of Shared Risk Link Groups
are also explained.
Module 5 - Page 16
Shared Risk Link Groups (SRLG)
A dynamic routing protocol is required to distribute the additional

link constraints within the network.
An enhanced algorithm is needed to make path calculations using the
specified constraints.
Module 5 |
17
Additional administrative constraints can be configured locally on each router in the network.
When the network administrator wishes the traffic engineering application on any router to calculate a path using any
of the constraints, it is an obvious requirement that the router already has the relevant information readily available in
its possession. If, for instance, the link between R4-R6 is made a member of administrative group GREEN by means of
local configuration on router R4, this information must be propagated to the rest of the network, including router R1.
It is also strictly required that this information be up-to-date, because constraints might be added or deleted on the
links on any router at any time. As a result, a dynamic, quick-adapting mechanism is needed. This is most conveniently
achieved via the use of a dynamic protocol.
After the Traffic Engineering related information is distributed in the network, another requirement is to allow for an
algorithm that takes into account also the additional constraints specified by the administrator. The standard SPF
(Shortest Path First) algorithm uses only the IGP metric values to make path calculations; therefore, an enhancement is
needed to suit the Traffic Engineering requirements.
The implemented solutions are presented on the following pages.
Module 5 - Page 17
Defining the Prerequisites for MPLS Traffic Engineering
IGP Traffic Engineering Extensions
An (enhanced) routing protocol is needed to carry additional link

constraint information.
Global view over the entire topology is required.
Traffic Engineering extensions have been made both to OSPF and

IS-IS.
The extended versions are referred to as OSPF-TE and IS-IS-TE.
Alcatel-Lucent Service Routers support both.
Traffic Engineering support must be explicitly enabled in
configuration.
Module 5 |
18
Traffic Engineering requires that information regarding the additional link attributes be known everywhere in the
network. When an administrative constraint is defined on a link attached to a certain router, this new information must
be immediately propagated to all the other routers. Similarly, if an attribute is deleted from a certain link; an update
must be triggered right away to keep the TE information up-to-date and synchronized throughout the network.
The event-triggered nature of these requirements imply a link-state routing protocol. Distance Vector Protocols such as
RIP (Routing Information Protocol) are not suitable, since these protocols provide knowledge about only the directly
connected neighbors, and not the whole topology.
However, the traditional link-state implementations have been designed to carry only the link IGP metric information.
To facilitate MPLS Traffic Engineering, developers defined extensions to the two link-state protocols OSPF and IS-IS
which are used widely in service provider networks today. Similar functionality is offered by both protocols in Traffic
Engineering terms. Alcatel-Lucent Service Routers fully support Traffic Engineering extensions to both OSPF and IS-IS.
To enable traffic engineering support, one simply enables the feature in the routing protocol, configure router ospf
traffic-engineering or configure router isis traffic-engineering. Details regarding TE configuration are covered in
Section 2 of this module.
Module 5 - Page 18
A link-state routing protocol is best suited.
OSPF-TE Extensions Opaque LSA Support
Enhancements defined in RFC 2370: The OSPF Opaque LSA Option

3 Opaque LSA Types were defined: Type 9, 10 and 11.
The difference is in their flooding scope.
The exact use of the Opaque LSAs is not defined in the RFC.
Module 5 |
19
IETF (Internet Engineering Task Force) defined the general guidelines concerning enhancements in the OSPF protocol in
RFC 2370 (later made obsolete by RFC 5250).
RFC 2370 defines 3 different Opaque LSA (Link State Advertisement) types 9, 10, and 11. Opaque LSAs provide a
generalized mechanism to allow for the future OSPF extensibility. All three Opaque LSA types consist of a standard LSA
header followed by application-specific information.
Opaque LSAs may be used directly by OSPF or indirectly by an application in order to distribute information throughout
the OSPF domain.
RFC 2370 does not define the exact use for Opaque LSAs, and MPLS-TE is simply one implementation. The Opaque LSA
itself defines the container used to transport the information, not the information itself.
Module 5 - Page 19
Opaque LSAs provide a generalized mechanism to allow for the

future extensibility of OSPF.
Type 10 LSA is flooded to all the routers within the same area.
Type 10 LSA (Area Opaque) is used for MPLS Traffic Engineering.
Many IGP deployments use a single area due to MPLS Traffic
Engineering requirements.
Module 5 |
20
MPLS-TE only uses type 10 opaque LSAs. The other two types, types 9 and 11, have other applications and are not
pertinent to this discussion. Each opaque LSA type transports information within a certain portion of the routing
domain, and routers flood type 10 opaque LSAs only within the OSPF area in which they originate; Area Border Routers
(ABRs) and Autonomous System Boundary Routers (ASBRs) do not forward these LSAs between areas.
In standard MPLS Traffic Engineering applications, type 10 opaque LSAs distribute the additional link constraint
information. IGP domains are mostly implemented as a single backbone area to facilitate a straightforward
implementation of Traffic Engineering, though techniques do exist to extend TE capabilities beyond area boundaries.
We discuss LDP over RSVP later in this module.
Module 5 - Page 20
Type 10 Opaque LSA Area Local LSA
Enabling OSPF Traffic Engineering
The following configuration is required on all the IP/MPLS routers

to enable traffic-engineering support for OSPF.
configure router ospf traffic-engineering
TED stores Opaque LSA (Type 10) information.

Opaque LSAs should only be forwarded to those routers that
understand them.
A neighbor is considered opaque-capable if it sets the O-bit in the
Options field of its Database Description packets.
Module 5 |
21
When opaque capable routers and non-opaque capable OSPF routers are mixed together in a routing domain, the
Opaque LSAs are not flooded to the non-opaque capable routers. As a general design principle, optional OSPF Link State
advertisements are only flooded to those routers that understand them. Note that the Alcatel-Lucent Service Routers
are opaque capable by default.
An opaque capable router learns of its neighbor's opaque capability at the beginning of the "Database Exchange
Process", receiving Database Description packets from a neighbor in the ExStart state.
A neighbor advertises that it is opaque capable by setting the O-bit in Database Description packets Options field; no
other packet type sets the O-bit.
Then, in the next step of the Database Exchange process, Opaque LSAs are included in the Database summary list that is
sent to the neighbor if and only if the neighbor is opaque capable. When flooding Opaque LSAs to adjacent neighbors, a
opaque capable router looks at the neighbor's opaque capability.
Opaque LSAs are only placed on the Link State retransmission lists of opaque-capable neighbors. However, when sending
Link State Update packets as multicasts, a non-opaque-capable neighbor may (inadvertently) receive Opaque LSAs. The
non-opaque capable router will then simply discard the LSA, having received LSAs containing unknown Link State types.
In the OSPF TE implementation, the router stores opaque LSAs in a dedicated database called the TED (Traffic
Engineering Database).
Module 5 - Page 21
A Traffic Engineering Database (TED) is created on all the routers.
IGP Link State Database (LSDB) still exists after enabling TE.
LSDB and TED are separate from each other.
Additional link attributes are only present in TED.
Module 5 |
22
An opaque-capable router maintains a specialized database called the Traffic Engineering Database (TED). The TED
contains the network link attributes and topology information needed by the router so that it can compute Traffic
Engineered paths independent of the IGP topology database, and therefore the IP routed topology.
TED contains the topological constraints learned via OSPF Opaque LSAs or IS-IS TLVs.
Topology Link State information learned from the IGP, via flooding within the area
Attributes associated with the state of network resources carried by Link State IGP extensions
Administrative policy requirements, obtained from user configuration, may be used as additional constraints when
calculating a constraint based route.
Module 5 - Page 22
Traffic Engineering Database
IGP LSDB might contain various LSA types (Types 1-7) that describe
all the links that are OSPF enabled (plus external prefixes
redistributed via policy).
TED contains only Type 10 Opaque LSAs that describe the RSVPenabled interfaces.
Module 5 |
23
When OSPF-TE is enabled, the router builds the TED from all the stored LSAs and the local links running OSPF. The
OSPF-TE TED has a different view of the network topology from the regular IGP Link State Database (LSDB). The TED
contains additional administrative constraint information that can be used to perform more sophisticated path
calculations. The TED and the Link State Database (LSDB) are decoupled and have no correlation with each other.
Since the function of the OSPF-TE TED is to make advanced MPLS LSP Path calculations, OSPF routers do not generate
Opaque LSAs for OSPF interfaces that on which the operator has not enabled RSVP.
Another major difference between TED and the LSDB is that the TED only contains information received from Type 10
LSAs. The LSDB might contain external prefixes advertised by the ASBR into the OSPF AS, called type 4,5 and 7 LSAs.
The LSDB might also contain prefixes from other OSPF areas generated by the ABRs (Area Border Routers). For a
network that contains broadcast link segments, Type 2 LSAs are generated by Designated Routers on each broadcast
segment. For a more detailed discussion of the LSA Types and their uses, refer to the SRC AIRP (Interior Routing
Protocols) course.
Module 5 - Page 23
Contents of IGP LSDB vs. Contents of TED
Multiple Type Length Values (TLV) can exist in an opaque LSA.

MPLS TE information is carried in Type 10 Opaque LSA TLVs.
TLVs bring flexibility to OSPF.
Module 5 |
24
The Opaque LSA starts with the standard LSA header. The LSA payload consists of one or more nested TLV triplets for
extensibility.
The Length field defines the length of the value portion in octets (thus a TLV with no value portion would have a length
of zero). The TLV is padded to four-octet alignment; padding is not included in the length field (so a three octet value
would have a length of three, but the total size of the TLV would be eight octets). Nested TLVs are also 32-bit aligned.
Unrecognized types are ignored. Only Types 1 and 2 are used.
Module 5 - Page 24
Opaque LSA Format
TLV Types for OSPF Type 10 Opaque LSA
Two types of (Top-Level) TLVs exist:

y Router Address TLV
Used to advertise the 4-octet router-ID of an OSPF router
Only one Router Address TLV per router
Used to advertise the RSVP enabled router links
One LSA can contain one link TLV with information for a single link
Carries a set of sub-TLVs that carry TE-related information about a
single link
Module 5 |
25
An LSA contains one top-level TLV. The two values define two sub-types of the Type 10 LSA:
Router Address Type 1
The Router Address TLV specifies a stable IP address of the advertising router that is always reachable.
It is typically implemented as a loopback address.
On the Alcatel-Lucent Service Routers, it is by default derived from the System IP address assigned to the router.
As soon as you enable traffic-engineering on the router, it advertises its RID with a Router Address TLV.
Link Type 2
The Link TLV describes a single link.
Only one Link TLV is carried in each LSA.
It is a variable length set of unordered sub-TLVs.
Routers only send link TLVs for those interfaces on which RSVP is enabled.
Module 5 - Page 25
y Link TLV
Link TLV Sub Types
The following sub-TLVs of the Link TLV are defined:

1. Link type (1 octet)
2. Link ID (4 octets)
3. Local interface IP address (4 octets)
4. Remote interface IP address (4 octets)
5. Traffic Engineering metric (4 octets)

6. Maximum bandwidth (4 octets)
7. Maximum reservable bandwidth (4 octets)
8. Unreserved bandwidth (32 octets)
9. Administrative group (4 octets)
10. Shared Risk Link Group (SRLG) (optional) (length variable)
Module 5 |
26
There are 10 defined sub-TLVs transported in the Link TLV:

1.
Link type (1 octet)
2.
Link ID (4 octets)
3.
Local interface IP address (4 octets)
4.
Remote interface IP address (4 octets)
5.
Traffic Engineering metric (4 octets)
6.
Maximum bandwidth (4 octets)
7.
Maximum reservable bandwidth (4 octets)
8.
Unreserved bandwidth (32 octets)
9.
Administrative group (4 octets)
10. Shared Risk Link Group (SRLG) (optional) (length variable)
Module 5 - Page 26
-------------------------------area 0.0.0.0
interface toR6
interface-type point-to-point
exit
LINK INFO TLV (for link toR6 on R4)

y
y
Sub TLVsy
y
y
Link Type : 1
Link ID: 10.10.10.6
Local Interface IP Address: 10.4.6.4
Remote Interface IP Address: 10.4.6.6
TE Metric: 100
(point-to-point)
(Router ID of neighbor)
(equal to IGP metric by default)

Module 5 |
27
The Link Type sub-TLV type 1 defines the type of the link:
Point-to-point (1)
Multi-access (broadcast) (2)
For a link segment that only two routers reside on either end, point-to-point type should be configured and used. The
default interface-type is broadcast, whereby the initial adjacency establishment takes longer as a result of a mandatory
Designated Router (DR) election, which takes around 40 seconds. DR election is not required on a point-to-point
interface, speeding up the initial convergence times.
The Link ID sub-TLV type 2 identifies the other end of the link. For point-to-point links, this is the Router ID of the
neighbor. For multi-access links, this is the interface address of the designated router. The Link ID is identical to the
contents of the Link ID field in the Router LSA for these link types.
The Local Interface IP Address sub-TLV type 3 specifies the IP address(es) of the interface corresponding to this link. If
there are multiple local addresses on the link, they are all listed in this sub-TLV.
The Remote Interface IP Address sub-TLV type 4 specifies the IP address(es) of the neighbor's interface corresponding to
this link. This and the local address are used to discern multiple parallel links between systems. If the Link Type of the
link is Multi-access, the Remote Interface IP Address is set to 0.0.0.0.
The Traffic Engineering metric sub-TLV type 5 specifies the link metric for Traffic Engineering purposes. This metric
may be different than the standard OSPF link metric. On the Alcatel-Lucent Service Routers, the TE metric is set equal
to the standard IGP metric of the link by default. It is possible to override this setting via explicit configuration, which
is described in Section 2.
Module 5 - Page 27
Example First Five Link Sub TLVs
Specifies the physical link capacity in the egress direction.

Fixed value (unless port speed is changed in configuration, if
applicable).
Expressed in Kilobits per second (Kbps), such as the other two
bandwidth constraints.
Module 5 |
28
The Maximum Bandwidth sub-TLV type 6 specifies the maximum bandwidth that can be used on this link, in this
direction (from the system originating the LSA to its neighbor), in IEEE floating point format. This is the true link
capacity. The units are bits per second.
The Maximum Bandwidth sub-TLV is four octets in length. The units carried inside the Opaque LSAs are bytes per
second. The SR OS CLI represents bandwidth in kilobits per second.
Module 5 - Page 28
Maximum Bandwidth Sub-TLV
Maximum Reservable Bandwidth Sub-TLV
Specifies the amount of bandwidth that may be reserved on the

link in the egress direction
Allows for a subscription percentage to be defined per RSVP
interface
Default subscription is 100 (Max. Resv. BW = Max. BW)

Over-booking and under-booking is possible
Module 5 |
29
The Maximum Reservable Bandwidth sub-TLV type 7 specifies the maximum bandwidth that may be reserved on a given
link, in the egress direction (the same direction as the LSP is being established). The values for this TLV is configured as
a percentage of the Maximum Bandwidth.
Note that this value may exceed the maximum bandwidth, enabling link oversubscription, or smaller than the maximum
bandwidth, thus under-subscribing the link. The default value is 100 (%), which means that it is equal to the Maximum
Bandwidth presented in the previous page.
The units carried in the Opaque LSA updates are expressed in bytes per second.
The Maximum Reservable Bandwidth sub-TLV is four octets in length.
Module 5 - Page 29
The subscription percentage is a change in the booking factor of

the link. Possible values: 0-1000
Module 5 |
30
The example above demonstrates the different configuration options for the Maximum Reservable Bandwidth:
1. Subscription set to 100 in CLI (default): The Maximum Reservable Bandwidth by RSVP-TE LSPs is equal to the
Maximum Bandwidth (true link capacity).
2. Subscription set to a value higher than 100: An over-booking factor is introduced to allow the RSVP-TE LSPs
reserve more bandwidth than the true link capacity. This is a typical implementation where the administrator
wishes to make use of Statistical Multiplexing Gain, where the assumption is that the real bandwidth utilization of
the links exceeding the real capacity is a negligible probability.
3. Subscription set to a value higher than 100: The Maximum Reservable Bandwidth by RSVP-TE LSPs is lower than the
true link capacity. This can also be referred to as under-booking, which can be used in cases where the bandwidth
reservations are supposed to use only a small portion of the real link bandwidth.
Module 5 - Page 30
Example Maximum Reservable Bandwidth
Unreserved Bandwidth Sub-TLV
Specifies the amount of bandwidth not yet reserved on the link in

the egress direction.
Updated each time an LSP reserves or releases bandwidth on the
link.
Contains one bandwidth value for each priority level.

By default, all LSPs have the same priority.
By default, all priority levels have the same unreserved bandwidth.
Module 5 |
31
The Unreserved Bandwidth sub-TLV type 8 specifies the amount of bandwidth not yet reserved at each of the eight
priority levels in IEEE floating point format. The values correspond to the bandwidth that can be reserved with a setup
priority of 0 through 7, arranged in increasing order with priority 0 occurring at the start of the sub- TLV, and priority 7
at the end of the sub-TLV. The initial values (before any bandwidth is reserved) are all set to the Maximum Reservable
Bandwidth. Each value will be less than or equal to the Maximum Reservable Bandwidth. The units are bytes per second.
The Unreserved Bandwidth sub-TLV is 32 octets in length.
LSP priorities are explained in Section 3, under the title LSP Soft Preemption.
Module 5 - Page 31
8 different LSP priorities can exist (See Section 3).
Module 5 |
32
The Unreserved Bandwidth value is a dynamic value that is updated each time an LSP reserves or releases bandwidth on
a link. The example above demonstrates three different scenarios illustrating the use of this TLV. The example assumes
a single priority level (default) for the sake of simplicity.
1. In the initial condition, in which no LSP is established on the link, the Unreserved Bandwidth is equal to the
Maximum Reservable Bandwidth defined for the link. No custom subscription value is defined, so this value equals
to 1 Gbps.
2. An LSP is established with 600 Mbps of bandwidth reserved. The Unreserved Bandwidth value on the link is
immediately updated and reduced to 400 Mbps. The new value is also propagated to other OSPF routers by means
of an Opaque LSA inside the Unreserved Bandwidth Sub-TLV.
3. The operator shuts down the LSP which is no longer deemed necessary, or removes its bandwidth reservation in
the configuration. As the LSP is being cleared (with a PATH Tear or RESV Tear messages), its bandwidth
reservation is also removed from the interface. The unreserved bandwidth value is again 1 Gbps. The OSPF
neighbors are informed of the new situation via another Opaque LSA advertisement.
Module 5 - Page 32
Example Unreserved Bandwidth
Administrative Group Sub-TLV
4-octet (32 bits) sub-TLV

Each bit represents an administrative group
The least significant bit is called Group-0
When a link is added to a group, the corresponding bit is set in the
Administrative Group Sub-TLV.
A link can be a member of multiple groups.
Module 5 |
33
The Administrative Group sub-TLV type 9 contains a 4-octet bit mask assigned by the network administrator. Each set
bit corresponds to one administrative group assigned to the interface. A link may belong to multiple groups. By
convention, the least significant bit is referred to as Group 0, and the most significant bit is referred to as Group 31.
The Administrative Group is also called Resource Class/Color.
Module 5 - Page 33
The most significant bit is called Group-31
Admin Group Sub TLV: 00000010 (16)

Decimal (2^4)
Hexadecimal
Admin Group names and values are arbitrary.

The 4th bit position is set in the Admin Group Sub TLV.
Module 5 |
34
The example above illustrates the membership assignment of an interface to an administrative group.
The Alcatel-Lucent Service Routers provide an intuitive way in working with administrative groups as opposed to some
other vendor implementations. Network designers can define administrative group names and associate them with
globally unique group numbers that can vary between 0-31. A common convention is to use color names for
administrative groups, which allow for a user-friendly method of configuring and perceiving them. In principle, any
arbitrary names can be defined. The choice of administrative group numbers is also completely arbitrary.
In the example above, an administrative group called GREEN is defined by the administrator and associated with a value
of 4 in CLI.
The interface toR6 is then assigned to this administrative group GREEN. In the consecutive Opaque LSAs advertised to
other OSPF routers, the administrative group Sub-TLV which consists of 4 octets (32 bits) is updated accordingly.
According to the implementation, the bit position corresponding to the CLI configured value is set to 1 in this Sub-TLV.
In this example, the 4th bit position is set as seen in the figure above. This is also referred to as a bitmap
representation.
In the TED CLI output which is actually presented later in the section, the Sub-TLV is expressed both in hexadecimal and
decimal format.
Module 5 - Page 34
Example Single Administrative Group Membership

Decimal (2^10 + 2^4)
Hexadecimal
The 4th and 10th bit positions are set in the Admin Group Sub TLV.
Module 5 |
35
On TE enabled router, an interface can be made a member of multiple administrative groups, if necessitated by the
network design. The above example is used to illustrate this concept.
An additional administrative group is defined with name BROWN and a group value of 10. The interface toR6 is made a
member of this new administrative group, together with the previous group, GREEN. The 10th bit position in the Sub-TLV
in the Opaque LSA pertaining to the link to reflect this change.
Module 5 - Page 35
Example Multiple Administrative Group Memberships
Opaque LSAs are flooded through the area and the Traffic
Engineering Databases are populated.
Module 5 |
36
Opaque LSAs are stored in each routers individual and self-contained Traffic Engineering Databases (TEDs).
Routers propagate the Opaque LSAs to each TE capable OSPF neighbor. The received Opaque LSAs on a certain router
are checked against the existing TED and the TED is updated as necessary. As a result of this flooding mechanism, all
routers attain a common view of the topology from a Traffic Engineering perspective.
Module 5 - Page 36
Opaque LSA Exchange
Opaque LSA Flooding
Opaque LSAs are flooded in the following cases:

y Link-state change (up/down)
y Change to link constraints (configuration change)
y When the IGP periodic flooding timer expires (to prevent LSAs
from being aged out)
Module 5 |
37
There are various reasons why Opaque LSAs might be advertised and flooded within the network, which include:
Changes in the link status (a link that goes operationally down or up).
Administrative changes in the link configuration. If attributes, such as administrative groups, Shared Risk Link
Groups (SRLG), and TE metric, are included or removed under the interface, an Opaque LSA is advertised
immediately to inform the other routers.
An LSP reserving or releasing a certain amount of bandwidth reserved on the link. By default, Opaque LSA updates
are immediately triggered in these cases. An optimization technique used to augment this behavior is introduced in
Section 3 under the title RSVP-TE Bandwidth Update Trigger.
Link State Updates are, by definition, event triggered. However, LSAs are also refreshed periodically to prevent
them from aging out. An individual age timer is defined for each LSA entry on every router. For OSPF, the initial
age timer is 0 and is incremented every second until 3600 seconds (the maximum age timer) elapse. If the router
receives no further update for this LSA within this time, the router removes the LSA from the database and the
prefix is deemed unreachable. The maximum age timer in OSPF is not configurable. The periodic refresh time is
around half of the maximum age timer in OSPF. In the IS-IS implementation, the maximum age timer is configurable
and is set to 1200 seconds by default. The refresh timer is equal to half of the maximum age timer.
Module 5 - Page 37
y Changes in the reserved bandwidth
*A:R1# show router ospf opaque-database

===============================================================================
Type Id
Link State Id
Adv Rtr Id
Age Sequence
Cksum
------------------------------------------------------------------------------Area 0.0.0.0
1.0.0.1
10.10.10.1
1305 0x80000012 0xef10
Area 0.0.0.0
1.0.0.2
10.10.10.1
602 0x80000024 0xc635
Area 0.0.0.0
1.0.0.3
10.10.10.1
602 0x80000025 0xad75
Area 0.0.0.0
1.0.0.1
10.10.10.2
268 0x80000012 0xf30a
Area 0.0.0.0
1.0.0.2
10.10.10.2
1347 0x80000023 0x1911
<. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >
Area 0.0.0.0
1.0.0.3
10.10.10.5
846 0x80000021 0x977b
Area 0.0.0.0
1.0.0.4
10.10.10.5
838 0x80000022 0xf06
Area 0.0.0.0
1.0.0.1
10.10.10.6
176 0x80000011 0x6f0
Area 0.0.0.0
1.0.0.2
10.10.10.6
475 0x80000020 0xfd13
Area 0.0.0.0
1.0.0.3
10.10.10.6
496 0x80000026 0x64a1
------------------------------------------------------------------------------No. of Opaque LSAs: 22
The show router ospf opaque-database command is used

to display the list of opaque LSAs.
Module 5 |
38
The show router ospf opaque-database command displays the list of Opaque LSAs generated and received by the
router. The advertising router ID field indicates the source router that generated the LSA.
The output above is taken on router R1 with a router ID of 10.10.10.1. Not all the Opaque LSAs are shown in the figure
above, for the sake of clarity.
Module 5 - Page 38
Viewing the Opaque Database
*A:R1# show router ospf opaque-database adv-router 10.10.10.4

=============================================================
Type Id
Link State Id
Adv Rtr Id
------------------------------------------------------------Area
0.0.0.0
1.0.0.1
10.10.10.4
Area
0.0.0.0
1.0.0.2
10.10.10.4
Area
0.0.0.0
1.0.0.3
10.10.10.4
Opaque LSA for:
Area 0.0.0.0
1.0.0.4
10.10.10.4
------------------------------------------------------------No. of Opaque LSAs: 4
Module 5 |
(Router ID of R4)
(Interface toR2)
(Interface toR6)
(Interface toR5)
39
A useful way of examining the TED in a large network is through filtering the Opaque-Database output by specifying the
advertising router ID of the router under inspection.
In the example above, router R4 has a router ID of 10.10.10.4, which is derived by default from its system IP address
(10.10.10.4/32). The Opaque Database (TED) output indicates that 4 Opaque LSAs are advertised by router R4 in total.
The Link State ID field is used to distinguish between the different LSAs advertised by a router. In the Traffic
Engineering implementation, Opaque LSAs are given Link ID numbers starting from 1.0.0.1, where the last octet is
incremented for each additional Opaque LSA generated by the router.
Router R4 has 3 OSPF and RSVP enabled interfaces and it has generated three separate Opaque LSAs for each of these
interfaces.
Please note that this command output contains only the LSAs header information. The actual information the LSA
carries may be observed by adding the detail keyword, illustrated on the following pages.
Module 5 - Page 39
Viewing the Opaque Database Per Router
Router ID TLV for router R4
===============================================================================
OSPF Opaque Link State Database (Type : All) (Detailed)
===============================================================================
------------------------------------------------------------------------------Opaque LSA
------------------------------------------------------------------------------Area Id
: 0.0.0.0
Adv Router Id
: 10.10.10.4
Link State Id
: 1.0.0.1
LSA Type
: Area Opaque
Sequence No
: 0x80000002
Checksum
: 0x1ced
Age
: 107
Length
: 28
Options
: E
Advertisement
:
ROUTER-ID TLV (0001) Len
4 : 10.10.10.4
The Router ID is derived from the System IP address by default.

Essential for TE operation (needs to be unique).
Module 5 |
40
The Router Address TLV specifies a stable IP address of the advertising router that is always reachable if there is any
connectivity to it; this is typically implemented as a loopback address. The key attribute is that the address does not
become unusable if an interface is down.
In the Alcatel-Lucent Service Router implementation, the router ID value is by default derived from the explicit System
IP address configuration. For TE purposes, an explicitly defined Router ID should be the same as the System interface
address.
Utmost care must be taken to have unique System IP addresses and in turn, unique router IDs all over the network, to
ensure proper IGP and Traffic Engineering operation.
Module 5 - Page 40
A:R1# show router ospf opaque-database adv-router 10.10.10.4 detail

<. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >
------------------------------------------------------------------------------Opaque LSA
------------------------------------------------------------------------------Area Id
: 0.0.0.0
Adv Router Id
: 10.10.10.4
Link State Id
: 1.0.0.3
LSA Type
: Area Opaque
Sequence No
: 0x80000005
Checksum
: 0xa449
Age
: 6
Length
: 124
Options
: E
Advertisement
:
LINK INFO TLV (0002) Len 100 :
(Interface toR6)
Sub-TLV: 1
Len: 1
LINK_TYPE
: 1
Sub-TLV: 2
Len: 4
LINK_ID
: 10.10.10.6
Sub-TLV: 3
Len: 4
LOC_IP_ADDR : 10.4.6.4
Sub-TLV: 4
Len: 4
REM_IP_ADDR : 10.4.6.6
Sub-TLV: 5
Len: 4
TE_METRIC
: 100
Sub-TLV: 6
Len: 4
MAX_BDWTH
: 1000000 Kbps
Sub-TLV: 7
Len: 4
RSRVBL_BDWTH : 1000000 Kbps
Sub-TLV: 8
Len: 32
UNRSRVD_CLS0 :
P0: 400000 Kbps P1: 400000 Kbps P2: 400000 Kbps P3: 400000 Kbps
P4: 400000 Kbps P5: 400000 Kbps P6: 400000 Kbps P7: 400000 Kbps
Sub-TLV: 9
Len: 4
ADMIN_GROUP : 00000010 (16)
(GREEN)
Module 5 |
41
Continuation of the command on the previous page reveals more Opaque LSA information generated by router R4.
One of the three Opaque LSAs generated for each network interface is shown in the figure above.
The 9 Sub-TLV types have been previously introduced in this section. Under the Sub-TLV 8 (Unreserved Bandwidth)
section, the 8 possible priority values can be observed with their respective bandwidth reservation information. As
mentioned earlier, by default all LSPs reserve bandwidth at a single common level (Level 0), which results in the same
unreserved bandwidth values to be seen for all priority levels. The priority values are used in conjunction with the LSP
Soft Preemption feature, explained in Section 3.
The Admin-Group Sub-TLV indicates the hexadecimal and decimal values corresponding to the only administrative group
defined for the interface, GREEN.
Module 5 - Page 41
Link Info TLV for R4-R6 link
ISIS-TE Extensions
Enhancements defined in RFC 3784.

Four TLVs used by IS-IS TE:
y Traffic Engineering Router ID TLV: Used to advertise the 4-octet
router-ID of an IS-IS router
y Extended IS Reachability TLV: Used to carry the TE related

information (bandwidthm admin-group, etc.) Contains 7 types of SubTLVs in the LINK INFO TLV (see next page)
y Shared Risk Link Group (SRLG) TLV : Used to carry SRLG membership
information (see Module 6)
Module 5 |
42
IS-IS as a link-state routing protocol is defined in RFC 1195. Traffic Engineering enhancements that apply to a single
area IS-IS network is defined in RFC 3784.
A 4-octet router ID is advertised for an IS-IS router that provides a unique and stable address that is always reachable by
Traffic Engineering applications. The router ID is derived from the System IP address by default, as in the case of OSPF.
An Extended IP reachability TLV is defined by the RFC, although this is not specifically used for TE applications and is
mentioned here for the sake of completeness.
The new extended IS reachability/neighbors TLV (type 22) contains a new data structure, consisting of:
7 octets of system ID and pseudonode number
3 octets of default metric
1 octet of length of sub-TLVs
0-244 octets of sub-TLVs,
where each sub-TLV consists of a sequence of
1 octet of sub-type
1 octet of length of the value field of the sub-TLV
0-242 octets of value
An additional TLV is defined for SRLG memberships and is optional. Inclusion of this TLV depends on whether an SRLG
configuration exists on the interface or not.
Module 5 - Page 42
y Extended IP Reachability TLV: Contains a 4-octet IP Prefix (Not used

for TE purposes)
IS-IS LINK INFO TLV Sub-TLV Types
IS-IS TE Sub-TLV codes and definitions

Length (octets)
Name
Administrative group (color)
IPv4 interface address
IPv4 neighbor address
Maximum link bandwidth
10
Reservable link bandwidth
11
32
Unreserved bandwidth
18
TE Default metric
250-254
Reserved for vendor specific extensions
255
Reserved for future expansion
Module 5 |
43
The IS-IS TE Sub-TLVs exist inside TLVs. TLVs are used to add extra information to IS-IS packets. The table above
summarizes the IS-IS TLVs used in TE implementations.
The implementation and use of the IS-IS Sub-TLVs is similar to the OSPF TE extensions covered earlier in the module;
the discussions are not repeated here.
Module 5 - Page 43
Sub-TLV type
Enabling IS-IS Traffic Engineering
The following configuration is required on all the IP/MPLS routers

to enable Traffic Engineering support for IS-IS.
configure router isis traffic-engineering
Accordingly, no separate command exists to view the Traffic

Engineering related information.
The show router isis database [level 1/2] detail
command can be used to display TE information.
Similar functionality is offered as in OSPF-TE.
Module 5 |
44
Alcatel-Lucent Service Routers have inherent support for IS-IS Traffic Engineering, as well as OSPF-TE.
Similar to OSPF, enabling the IS-IS TE extensions an a Service Router requires an explicit configuration as displayed
above.
When IS-IS TE is enabled, the Traffic Engineering information is disseminated in the extended TLVs described in the
previous page. The TLVs are included in the same Link State PDU control packets together with the standard IGP TLVs.
This behavior is different than OSPF, where the TE information is carried within separate LSAs called Opaque, or Type
10 LSAs.
As a consequence, the TE related information is stored in the same database with the standard IS-IS routing
information. The Traffic Engineering TLVs can be displayed in the show router isis database [level 1/2]
detail command output. The level number (1 and/or 2) depends on the specific area hierarchy of the IS-IS IGP
network. An IS-IS interface might exist on either one of, or both of the hierarchy levels.
When compared to OSPF, IS-IS offers similar functionality, in terms of Traffic Engineering.
Module 5 - Page 44
Traffic Engineering information is carried in extended TLVs and within

the same Link State PDUs along with standard IGP TLVs.
Standard Shortest Path First (SPF) algorithm uses only the link costs.
An enhanced algorithm is needed to take into account the
administratively defined constraints when making path calculations.
Constraint-Based Shortest Path First (CSPF) is the solution.
Module 5 |
45
After the Traffic Engineering related information is acquired via the flooding of Opaque LSAs or TE TLVs, the router
must decide how to calculate a path for the LSP to router R6 with the additional specified administrative constraints.
The regular SPF algorithm comes up short because it only takes into account the metric (cost) values assigned to the
links. This is the limiting factor of standard IGP implementations, leading to issues such as hyperaggregation, as
presented earlier.
At this point, a more sophisticated mechanism is required; it must have the ability to work with additional constraints
that can be fed as parameters into the execution of the path calculation algorithm. This has been achieved by
modifying the standard SPF algorithm to meet the Traffic Engineering demands. The enhanced version of the algorithm
is called CSPF (Constraint-Based Shortest Path First) and is introduced in greater detail in the following pages.
Module 5 - Page 45
The Requirement for an Enhanced Algorithm
Constrained-Based Shortest Path First (CSPF)
Used to make path calculations with additional administrative

constraints.
How the algorithm basically works:
1. Prune the links that do not meet the specified constraints.
2. Use the standard SPF algorithm to calculate the LSP path.
RSVP is responsible for signaling after path calculation.
Module 5 |
46
The CSPF algorithm is used to make path calculations that take additional administrative constraints, such as link
colors, bandwidth, and TE metric, into account.
The use of CSPF for an LSP is optional, and is up to the discretion of the network administrator. CSPF is disabled by
default for each LSP that is created in configuration.
The high-level overview of CSPF operation is rather simple and straightforward. CSPF works on the Traffic Engineering
Database and tries to calculate a path that satisfies the additional administrative constraints explicitly specified in the
LSP configuration.
To accomplish this, CSPF first prunes (disregards) the links that do not meet the administratively defined constraints.
This creates a temporary view of the topology excluding the non-conforming links.
The head end router uses a regular SPF calculation on the CSPF results to determine the hops that the LSP path will
traverse. Then, RSVP signals the end-to-end forwarding path for the LSP.
The above processes are illustrated by some examples in the following pages.
Module 5 - Page 46
Enabled on a per LSP basis (disabled by default).
CSPF is required to calculate a path to router R6 that avoids

(excludes) all the green links.
CSPF will consult the TED and execute the constraints.
Module 5 |
47
In the above example, the links contain additional attributes that have been propagated throughout the network and
are present in the TED of every router. The router R4 link to router R6 is assigned to administrative group GREEN, as is
the router R3 to router R5 link. The unreserved bandwidth values only represent administrative constraints, and do not
reflect the actual data plane utilization figures.
The administrator configures an LSP on router R1 that targets the tail end router R6, and tells router R1 to find a path
that avoids or excludes any GREEN links in the network. Without the availability of the Traffic Engineering Database and
the use of CSPF, the path calculation would be based solely on the IGP link costs, which would yield the same path
definition for each repetitive case under stable conditions.
With the TE related information at hand, and CSPF enabled on the LSP, router R1 is capable of making path calculations
that can override the standard IGP decisions.
Module 5 - Page 47
Example-1 CSPF using Administrative Groups
SPF Run:
Candidate Path #1: R1-R2-R4-R5-R6 (IGP Cost = 400)
Candidate Path #2: R1-R3-R2-R4-R5-R6 (IGP Cost = 500)
Resulting Path: R1-R2-R4-R5-R6
Module 5 |
48
As mentioned, the first step in the execution of the CSPF algorithm is to prune the links that do not meet the
administrative constraints. The figure above illustrates this concept. Router R1 has a view over the entire network
topology, with the GREEN links pruned from the picture.
The next step is to run a regular SPF calculation in the resulting topology to determine the hops that the LSP path will
traverse. Again from a high-level perspective, there are two alternative path definitions to reach router R6 from router
R1. Following the regular SPF rules, router R1 chooses the path with the lowest cumulative IGP cost.
Module 5 - Page 48
Example-1 CSPF view of the TED with constraints
CSPF is required to calculate a path to router R6 that avoids:

y All the GREEN links; AND
y All the links that do NOT have 600 Mbps of unreserved bandwidth
CSPF will consult the TED and execute the constraints.

Module 5 |
49
The example in this figure demonstrates the use of multiple constraints within the same LSP configuration.
For a link to be eligible in the TE path calculation, it must satisfy all the constraints specified by the administrator.
That is, a link has to be NON-GREEN, and must have 600 Mbps of unreserved bandwidth, to be taken into consideration
by the CSPF algorithm.
In the example above, links R4-R6 and R3-R5 are eliminated because they are both members of administrative group
GREEN. The link R1-R2 is also eliminated because it only has 400 Mbps of unreserved bandwidth.
Module 5 - Page 49
Example-2 CSPF using Admin-Group & Bandwidth Constraints
SPF Run:
Candidate Path #1: R1-R3-R2-R4-R5-R6 (IGP Cost = 500)
Resulting Path: R1-R3-R2-R4-R5-R6
Module 5 |
50
The topology after the administrative constraints are executed is illustrated in the figure above. This is an intuitive way
of showing how the CSPF process visualizes the network topology with the specified constraints.
In this example, the pruning of the links that do not conform to the constraints yields to a single path possibility, the
consecutive hop list: R1-R3-R2-R4-R5-R6.
Recall that CSPF is only responsible for making calculations on a router. The signaling of the LSP path is handled by
RSVP, and is explained in the following pages.
Module 5 - Page 50
Example-2 CSPF view of the TED with constraints
CSPF has calculated a path with the specified constraints that is

different from the IGP-based path.
A specific method is needed to ensure that the RSVP PATH message
follows the hops calculated by CSPF.
Module 5 |
51
Signaling of an IGP based RSVP-TE LSP was explained in Module 4. If the path definition does not contain any specific
hops and/or CSPF is disabled, the LSP path follows the normal IGP best path. That is, the RSVP PATH message is
forwarded using the IGP forwarding decisions.
When specific constraints are defined for the LSP, CSPF can calculate a path that is different from the IGP based path.
A method needs to be introduced to ensure that the RSVP PATH message goes through the exact hops calculated by
CSPF, and the LSP gets signaled over those hops. This solution is explained in the next page.
Module 5 - Page 51
Signaling the Path Calculated by CSPF
Internet Protocol:
Source: 10.10.10.1
Dest. : 10.10.10.6
Options: Router Alert
RSVP PATH Message:
<SESSION>
<SENDER TEMPLATE>
<HOP>
<EXPLICIT ROUTE>
............
In this example, CSPF has calculated the entire LSP path.

The end-to-end path information is inserted into the Explicit Route
Object (ERO) of the RSVP PATH message.
The ERO is updated at each hop.
Module 5 |
52
The hop information calculated by CSPF is included in the Explicit Route Object (ERO) field of the RSVP PATH message
generated by the Head-End router. Upon receipt of the PATH message, the consecutive hops are obliged to inspect the
ERO to determine the next-hop for the LSP path.
The Explicit Route Object field is modified at each hop, so that a receiving router sees an IP address of its own at the
top of the hop list.
Module 5 - Page 52
Explicit Route Object (ERO)
Module 5 |
53
In this example, CSPF has calculated a path for the LSP that consists of nodes R1-R3-R5-R6.
The ERO sent from the Head-End (router R1) consists of 3 hops. The first entry is the interface IP address of the nexthop router, which is router R3. When router R3 receives the PATH message, it first verifies that the top entry is a valid
IP address of its own. Router R3 then checks the destination IP address, which belongs to another downstream router.
To determine the next-hop for this address, router R3 does NOT consult the IGP forwarding example, as in the example
presented in Module 4. Since an ERO is present, it must be used.
Router R3 determines the next-hop by checking the next entry in the hop list, 10.3.5.5. It removes the top entry,
10.1.3.3, and forwards the PATH message to router R5.
A similar process occurs on router R5, which forwards the PATH message on to router R6.
Router R6 verifies the remaining ERO entry and determines that it is this LSPs final destination. Router R6 sends an
RSVP RESV message back to router R5, which then forwards it to router R3. Router R3 forwards the RESV message to
router R1, thus establishing the LSP.
Module 5 - Page 53
Signaling the Path using ERO
LINK ID
LOCAL IP ADDRESS
REMOTE IP ADDRESS
UNRESERVED BW
ADMIN_GROUP
:
:
:
:
:
10.10.10.6
10.4.6.4
10.4.6.6
400,000 Kbps
00000010 (16)
LINK ID
LOCAL IP ADDRESS
REMOTE IP ADDRESS
UNRESERVED BW
ADMIN_GROUP
:
:
:
:
:
10.10.10.4
10.4.6.6
10.4.6.4
1,000,000 Kbps
0 None
Administrative constraints are executed in the egress direction only

(in the same direction as the LSP setup).
The constraints can be asymmetrical on the link.
Bandwidth is checked and reserved in the egress direction only.
Module 5 |
54
It is important to note that the administrative constraints apply only in the egress direction. They are checked and
executed in the same direction as the LSP that is being established.
As mentioned, administrative constraints are locally configured parameters on individual router links that are
propagated to other routers via IGP-TE updates. As seen in the example above, it is perfectly possible to have an
administrative group called GREEN configured on one side of the link, and no group definition on the other side. In the
reference figure above, the GREEN administrative group constraint can only be considered for an LSP that is established
towards router R6.
Accordingly, bandwidth reservations are performed and checked in the egress direction only. If an LSP is established
with a 600 Mbps bandwidth reservation from router R4 towards router R6, router R4 checks whether unreserved
bandwidth is available on the link to router R6 and makes the reservation in the same direction, if possible. In the
ingress direction, router R6 does not perform any check against available bandwidth reservation.
Module 5 - Page 54
Administrative Constraints Special Remarks
CSPF Special Remarks
Bandwidth reservation can still take place without CSPF. However,

path failures can occur due to insufficient bandwidth at a
downstream node on the IGP path (See Section 3 Working with
RSVP-TE Bandwidth Reservations).
CSPF calculates only the loose hops in the LSP path definition (See
Section 2).
CSPF plays an important role in Fast Reroute protection and Global
Revertive behavior (See Module 6).
Module 5 |
55
Special considerations using CSPF are:

CSPF is disabled for an LSP by default. If CSPF functionality is desired, it must be explicitly enabled in
configuration. Any administrative constraints that may have been specified for the LSP are disregarded if CSPF is
not enabled. In that case, the LSP path is NOT calculated by CSPF procedures and is signaled using the standard IGP
forwarding mechanism, as explained in Module 4.
Routers can reserve bandwidth for an LSP even without CSPF enabled. The bandwidth reservation request is
signaled within the FLOW_SPEC object of the RSVP PATH message. When a router receives a PATH message, it
checks whether a specific bandwidth reservation request has been made for the LSP, and performs the reservation
if available. However, if the requested bandwidth is not available at a downstream node, the LSP setup fails and a
RESV Error message is generated back towards the Head-End. CSPF can alleviate these issues beforehand by
calculating a path that has the requested reservable bandwidth available end-to-end. Section 3 of this module
explains this process in greater detail.
Section 2 explains that path definitions may be formed by loose and/or strict hop definitions. When CSPF is
enabled, it performs path calculations only on the loose hop portion(s) of the LSP path definition. More details
follow in the next section.
Fast Reroute (FRR) is a popular RSVP Traffic Engineering resiliency mechanism that uses CSPF to calculate
protection tunnels signaled to support the FRR feature. Using Global Revertve behavior, an LSPs Head-End
router can re-optimize the LSP once the failure condition that caused FRR activation is removed. Module 6 includes
detailed discussions on FRR and the Global Revertive mechanisms.
Module 5 - Page 55
The constraints are not taken into account if CSPF is not enabled on
the LSP. The path is signaled using standard IGP procedures (as
presented in Module 4).
Section Summary
In this section we covered:

Drivers for Traffic Engineering (TE)
Administrative constraints used in MPLS TE
OSPF and IS-IS Traffic Engineering extensions
Use of the Explicit Route Object (ERO) in signaling TE-based LSP
paths
Module 5 |
56
Traffic Engineering refers to the collection of mechanisms used to steer traffic around the network to avoid
congestion points or bottlenecks that eventually lead a well-known phenomenon called hyperaggregation.
Network designers and operators strive to use the network resources in the most efficient way possible to
guarantee different levels of service quality towards customers and maximize profits.
Several methods have been proposed and tried in the networks to perform Traffic Engineering tasks using standard
IGP techniques, which have generally proven to be unscalable and unmanageable.
MPLS offers more straightforward and easy to use features to implement TE in the network.
Several administrative constraints can be defined on the network links to overcome the limitation of standard IGP,
which relies solely on the link costs for path calculation, such as:
Administrative Groups
TE-metric
Hop-limit
Bandwidth Reservation
Shared Risk Link Groups (SRLG)
OSPF and IS-IS routing protocols have been extended to support the traffic engineering extensions that can be
defined on the links.
OSPF TE information is carried in separate Type 10 Opaque LSAs, with a single area scope.
IS-IS TE information is carried in extended IS reachability TLVs within the same Link State PDU protocol packets are
used to carry standard IS-IS routing information.
The standard Shortest Path First (SPF) algorithm has been enhanced to make path calculations based on the
specified administrative constraints. The enhanced algorithm is called CSPF.
When asked to calculate a path to a certain tunnel destination, CSPF first prunes the links that do not meet the
constraints and runs a standard SPF algorithm on the resulting topology based on cost values.
The Explicit Route Object (ERO) is populated by the hop information calculated by CSPF. Routers determine the
next-hop for the RSVP PATH message by checking the ERO when it is present.
Module 5 - Page 56
Operation of the CSPF algorithm
Section 2 Configuring Traffic Engineering in a Flat (Single Area)

Network
Module 5 - Page 57
Section Objectives
In this section we will discuss:

Configuring administrative constraints on the links (administrative
group, TE-metric)
Configuring path definitions using strict and loose hops
CLI Show commands to monitor the LSP path state
Possible configuration errors and failure scenarios
The CSPF path-check tool
Module 5 |
58
This section covers the configuration principles of LSPs with certain Traffic Engineering requirements.
Examples of configuring administrative constraints such as administrative groups and TE metric are presented.
The possible variations of composing path definitions with strict and loose hops are explained with different examples.
Several verification and monitoring commands to display the status of LSP paths are included.
The section also covers several scenarios to illustrate possible failures that can result from configuration errors in the
path definitions, or other problems such as path unavailability because of additional constraints or link failures.
Aspects related to bandwidth reservations are not covered in this section; Section 3 is dedicated to this.
A useful CLI verification tool to check CSPF path availability is introduced at the end of the section, with various
examples.
Module 5 - Page 58
Specifying constraints in LSP path configuration
Configuring TE based LSPs
Configuring LSPs using Traffic Engineering involves:

y Enabling Traffic-Engineering in the IGP configuration
Administrative Groups
TE metric
Bandwidth Subscription percentage (Section 3)
SRLG Groups (Module 6)
y Creating a path definition

y Specifying one more of the administrative constraints in LSP
configuration
y Enabling CSPF in the LSP configuration
Module 5 |
59
As mentioned in the previous section, Traffic Engineering must be enabled on all the OSPF or IS-IS routers in the
network to propagate the TE information related to the links.
Various administrative constraints can be specified on the links, such as administrative groups, TE-metric, and so on,
depending on the pertinent network design. A bandwidth subscription percentage can be defined on a link to allow for
an oversubscription or undersubscription rate. This is covered in section 3 of this module.
A path definition may be composed by using different combinations of strict and loose hops. The path definition can
also be perceived as a constraint for CSPF during path calculation.
The administrator might choose to specify one or multiple constraints in the LSP configuration. If enabled, CSPF prunes
the links that do not meet the constraints and calculates a path using the remaining links. The constraints are not taken
into account if CSPF is not enabled.
Module 5 - Page 59
y Defining additional attributes for the links:
-------------------------------admin-group GREEN" 4
-------------------------------admin-group GREEN" 4
interface "toR6"
admin-group GREEN"
exit
The Administrative Group name-to-value associations should be

consistent on all the routers.
Module 5 |
60
Administrative Groups are defined in the global MPLS context. In the example above, an administrative group is defined
with the name GREEN and a value of 4 on router R4. The interface to router R6 is then made a member of this
administrative group. As a result, the 4-bit position is set in the 32-bit admin-group Sub-TLV in the Opaque LSA.
If a path calculation needs to be made on router R1 with the same administrative group constraint, the same group to
value association must be defined on router R1. When an include or exclude statement is used in an LSP configuration
for an admin-group name, CSPF can then search for links with the corresponding admin-group value in the TED, if
required. Note that, in the TED, only the admin group values are present, not the names.
In principle, different admin group names can be used on different routers for the same admin group value. However,
this is very bad practice because it can cause troubleshooting nightmares if a certain value corresponds to different
group names on different routers.
Module 5 - Page 60
Administrative Group Definitions
-------------------------------interface "toR3
te-metric 400
exit
-------------------------------interface "toR6"
te-metric 500
exit
Module 5 |
61
A Traffic Engineering metric can be defined on the links that can be different from the standard IGP metric, as
illustrated in the figure above.
Module 5 - Page 61
Traffic Engineering Metric Configuration
RSVP-TE Explicit Path Definitions
A path definition may contain a list of nodes that the LSP path
must traverse.
Each of these abstract nodes is called a hop. Hops can be either
strict or loose.
Module 5 |
62
A path may contain a list of abstract nodes that the LSP path must go through. Each of these abstract nodes is a hop. A
hop is expressed as an IP address (interface or system IP address of a router) in the path. Therefore, the path is the list
of the routers that an LSP path must traverse. The hops are specified in sequential order in the path definition.
A hop in the list can have a strict or loose character. Strict or loose describes the relationship between two consecutive
hops in the path definition. This is explained via several examples in the following pages.
Module 5 - Page 62
The path configuration is used to regulate the actual path that an

LSP takes. It is considered as a constraint in the CSPF calculation.
Strict and Loose Hop Definitions
If enabled, CSPF:
y Calculates the intermediate hops to reach a loose hop
y Checks if a strict hop is valid.
A path definition may be composed by using:
y Fully loose or empty path list
y Fully strict hops
y Mixture of strict and loose hops
Module 5 |
63
Hops can be specified as either strict or loose inside the path definition.
A hop specified as a strict hop must be an immediate next-hop to the previous hop in the hop list definition of the path.
This means that the two routers must have a direct Layer 3 connection between each other if a strict hop is being used.
If the strict hop is the first hop in the path definition, then it must be an immediate next-hop router of the Head-End
router (the Head-End router IP address is not specified in the path list and is considered an implicit first hop).
If a hop is specified as a loose hop, there is no stringent requirement for it to be an immediate next-hop to the previous
hop. It can be any downstream node from the Head-End node towards the tunnel destination.
CSPF acts differently on the strict and loose hops in a path definition. If enabled in the LSP configuration, CSPF
calculates the intermediate hops from the previous node towards a loose hop. In other words, it fills in the missing gaps
in the path definition with a loose hop.
CSPF is not strictly required for an LSP comprised of only strict hops but, if enabled, it runs a sanity check on the strict
hops and verifies whether they are valid. This avoids unnecessary signaling attempts in case configuration or operational
errors are present that impact the LSP path.
Several combinations are possible when creating path definitions for an LSP using strict and loose hops. Examples are
included in the following pages to illustrating different scenarios.
Module 5 - Page 63
Strict or loose describe the relationship between two consecutive

hops in the list.
y Strict Hop: A hop specified as a strict hop must be an
immediate next-hop router to the previous hop in the list.
y Loose Hop: A hop specified as a loose hop might be any
downstream node to the previous hop in the list. It does not
have to be an immediate next-hop.
Fully Loose Path Configuration
-------------------------------path "empty_list"
-------------------------------path fully_loose
hop 10 10.10.10.6 loose
no shutdown
no shutdown
exit
exit
lsp "to_R6
to 10.10.10.6
lsp "to_R6
cspf
to 10.10.10.6
primary "empty_list
primary fully_loose
exclude GREEN
exclude GREEN
exit
exit
no shutdown
no shutdown
exit
exit
Both path configurations above are considered as fully loose.

If the path definition is empty, the destination address defined in the
to field of the LSP configuration is used by CSPF.
CSPF calculates the entire end-to-end path to 10.10.10.6 .
Module 5 |
64
A fully loose path definition provides a relaxed path constraint for CSPF, so that no specific regulation is imposed on the
intermediate hops of the LSP path by the administrator. CSPF can calculate an end-to-end path for the LSP from the
Head-End to the Tail-End router, taking into account the administrative constraints specified for the LSP path.
A fully loose path definition might contain a single hop the Tail-End (tunnel destination) router specified in the to
field of the LSP configuration.
It is also valid to have an empty path definition with no explicit hops specified. In this case, CSPF again tries to
calculate a path to the tunnel destination specified in the to field of the LSP configuration.
A path definition is administratively shutdown by default. It is important to remember that they must be explicitly
enabled by issuing a no shutdown command at the end of the path definition.
Module 5 - Page 64
cspf
path empty_list"
no shutdown
exit
lsp "to_R6
cspf
to 10.10.10.6
primary "empty_list
CSPF calculates the entire

path from router R1 to router
R6, avoiding the GREEN links.
exclude GREEN
exit
Module 5 |
65
The example above illustrates the use of a fully loose path definition.
The path definition does not contain any hop information, so CSPF has the fully liberty in choosing the hops for the LSP
path, ensuring only that they comply with the administrative group constraint specified under the primary LSP path
definition.
In calculating the required path, CSPF first prunes all the links that are members of administrative group GREEN. In the
resulting topology, the path with the lowest IGP cost is chosen from the LSP Head-End to the Tail-End. The signaled LSP
path goes around the GREEN links.
Module 5 - Page 65
Fully Loose LSP path Establishment
CSPF Calculated Loose Path CLI View

*A:R1# show router mpls lsp "to_R6" path detail
------------------------------------------------------------------------------LSP Name
: to_R6
Path LSP ID : 54132
From
: 10.10.10.1
To
: 10.10.10.6
Adm State
: Up
Oper State : Up
. . . . . . . . . . . . .
. . . . . . . . . . . . .
Path Trans : 1
CSPF Queries: 1
Actual Hops :
10.1.3.1(10.10.10.1)
-> 10.1.3.3(10.10.10.3)
-> 10.3.5.5(10.10.10.5)
-> 10.5.6.6(10.10.10.6)
Record
Record
Record
Record
Label
Label
Label
Label
:
:
:
:
N/A
131071
131071
131071
ComputedHops:
10.1.3.1
-> 10.1.3.3
-> 10.3.5.5
-> 10.5.6.6
The ERO is calculated by CSPF using a fully loose path definition.

The RRO (Record Route Object) is explained in Module 6.
Module 5 |
66
The show router mpls lsp <lsp-name> path [<path-name>] detail command is one of the most handy and
frequently used CLI monitoring commands to get extensive information regarding the LSP path(s) belonging to an LSP.
The Operational State of the LSP path is Up, which indicates that it is functioning properly.
One CSPF calculation has taken for the LSP path so far, as indicated by the CSPF Queries: 1 output.
No explicit hops have been defined by the administrator, who has preferred an empty path definition.
The Computed Hops field is of special interest here. This field is populated by the result of the CSPF calculation that
has taken place after enabling the LSP. Four hops have been computed by CSPF; the first is the Head-End and the last is
the Tail-End router of the LSP. None of the links in the computed LSP path is a member of the administrative group
GREEN.
The Explicit Route Object (ERO) of the RSVP PATH message sent from router R1 (Head-End) consists of the hops visible
in the Computed Hops output, except the first hop, 10.1.3.1, which is the interface IP address of router R1 itself.
The Record Route Object field has a particular use in the RSVP-TE Fast Reroute implementation and is explained in
Module 6.
Module 5 - Page 66
ExplicitHops:
No Hops Specified
Fully Strict Path Configuration
-------------------------------path fully_strict_A"
-------------------------------path fully_strict_B"
hop 10 10.1.3.3 strict
hop 10 10.10.10.3 strict
hop 20 10.10.10.5 strict
hop 30 10.10.10.6 strict
no shutdown
no shutdown
exit
lsp "to_R6
lsp "to_R6
to 10.10.10.6
to 10.10.10.6
primary fully_strict_A
primary fully_strict_B
exit
exit
no shutdown
exit
no shutdown
exit
A strict hop must be an immediate next-hop router.

Both interface (preferred) and/or system IP addresses may be used.
The LSP MUST go through all the strict hops. CSPF not needed.
Module 5 |
67
Alternatively, an LSP path can be completely comprised of strict hops. This option gives ultimate control to the network
administrator in determining the specific hops that an LSP path should take. Using the fully strict option, all the hops
along the LSP path needs to be explicitly specified, except the Head-End node.
Specifying interface or system IP addresses for the hops are both accepted as valid configurations by the Alcatel-Lucent
Service Routers. However, using the interface addresses is a recommended practice. Problems can occur in the rather
unlikely cases in which the system IP address is not resolved to an immediate next-hop. This can be caused by improper
IGP metric issues.
A fully strict hop LSP path fails if at least one of the hops in the path definition becomes unavailable as a result of link
failure or other problems. This is a downside unless protection mechanisms, such as secondary or fast reroute
protection paths, are used.
Since the path definition is fixed, CSPF does not need to be enabled in the LSP configuration. If enabled, CSPF runs a
sanity check on the strict hops and verifies their validity.
Module 5 - Page 67
exit
path fully_strict_A"
no shutdown
exit
The ERO is populated by the

manual strict hop configurations.
lsp "to_R6
to 10.10.10.6
primary fully_strict_A
Module 5 |
68
The example above illustrates an LSP path definition composed of only strict hops.
The first strict hop is router R3, from router R1.
The second strict hop is router R5, from router R3.
The third and the final strict hop is router R6, from router R5.
NOTE: The entries in the path definition are enumerated with values between 1-1,023. The specified values need not be
consecutive, but have to be in an increasing order. A common convention is to use hop values in powers of 10 (probably
rooted in the legacy BASIC programming language), but this is by no means mandatory. It has the bleak advantage of
being able to insert an additional hop between any two entries after the initial configuration.
Module 5 - Page 68
Fully Strict LSP path Establishment
Fully Strict LSP path with CSPF disabled CLI View

------------------------------------------------------------------------------LSP Name
: to_R6
Path LSP ID : 54134
From
: 10.10.10.1
To
: 10.10.10.6
Adm State
: Up
Oper State : Up
. . . . . . . . . . . . .
. . . . . . . . . . . . .
Path Trans : 1
CSPF Queries: 0
-> 10.3.5.5
-> 10.5.6.6
Configured Hops
ERO
Actual Hops :
10.1.3.1(10.10.10.1)
-> 10.1.3.3(10.10.10.3)
-> 10.3.5.5(10.10.10.5)
-> 10.5.6.6(10.10.10.6)
ResigEligib*: False
LastResignal: n/a
Record
Record
Record
Record
Label
Label
Label
Label
:
:
:
:
N/A
131071
131071
131071
CSPF Metric : 0
The Computed Hops field is not visible if CSPF is disabled.

CSPF can be enabled to verify the fully strict hops.
Module 5 |
69
The Explicit Hops field indicates the strict hops specified in the path definition.
The ERO of the RSVP PATH message sent from router R1 to router R3 contains these IP addresses as an explicit path list.
The Computed Hops field is not visible in the CLI output if CSPF is disabled in the LSP configuration.
As mentioned, CSPF can verify the strict hops in the path definition before attempting to signal the LSP path, if it is
enabled.
Module 5 - Page 69
ExplicitHops:
10.1.3.3
Mix of Loose and Strict Hops Path Configuration

-------------------------------path mixed-1"
-------------------------------path mixed-2"
hop 10 10.10.10.5 loose
hop 20 10.10.10.6 strict
hop 30 10.10.10.6 loose
no shutdown
exit
no shutdown
lsp "to_R6
exit
cspf
cspf
to 10.10.10.6
to 10.10.10.6
primary mixed-2
primary mixed-1
exclude GREEN
exclude GREEN
exit
exit
no shutdown
exit
no shutdown
exit
Both path configurations above are valid.

CSPF only calculates the loose portion of the path.
CSPF also checks that the strict hops are valid.
Module 5 |
70
Another alternative in creating path definitions is to use hybrid path definitions, where a mixture of strict and loose
hops are being used.
In the mixed path example above, mixed-1 (on the left) consists of two strict hops and one loose hop. CSPF is enabled
in the LSP configuration, so it first checks if 10.1.2.2 (router R2) is a valid strict hop for the Head-End router, R1. It
then checks if 10.2.4.4 (router R4) is a valid strict hop for the previous, that is 10.1.2.2 (router R2). CSPF finally
calculates a path from 10.2.4.4 (router R4) to 10.10.10.6 (router R6) that avoids any of the GREEN links.
In the second example, mixed-2 (on the right) takes the opposite approach. Here CSPF first calculates a path to
10.10.10.5 (router R5), which is defined as a loose hop. The administrative constraint must be taken into account,
which specifies that any GREEN links must be avoided along the first portion of the LSP path. CSPF then verifies that
10.10.10.6 (router R6) is a valid next-hop for 10.10.10.5 (router R5).
CSPF calculates ALL of the intermediate hops in a loose portion of the path definition. The ERO of the RSVP Path
message in this case is composed of strict hops provided by the administrator, and the hops calculated by CSPF for the
loose portion(s).
Module 5 - Page 70
lsp "to_R6
Mixed Hop LSP path Establishment

hop 30 10.10.10.6 loose
no shutdown
exit
lsp "to_R6
cspf
to 10.10.10.6
primary mixed-1
CSPF determines whether the strict

hops are valid.
CSPF calculates the loose portion of
the path, honoring the admin group
constraint.
exclude GREEN
Module 5 |
71
The above slide illustrates the CSPF path calculation process when using a mixture of strict and loose hops, as described
on the previous page. The loose portion of the LSP path is calculated by CSPF, taking into account the administrative
group constraint, which requires that all the GREEN links should be avoided. The LSP path consequently traverses over
router R5 to honor this constraint.
Module 5 - Page 71
path mixed-1"
Using TE-Metric in CSPF calculation
-------------------------------path "empty_list"
no shutdown
exit
lsp "to_R6
cspf use-te-metric
to 10.10.10.6
exit
no shutdown
exit
By default, CSPF uses the IGP metric values of the links.

The use-te-metric keyword needs to be specified for CSPF to take
the TE metric values into account.
Module 5 |
72
Recall that customary Traffic Engineering values can be specified for the links inside the MPLS interface contexts. The
TE metric values are propagated within the network inside IGP TE updates.
However, CSPF uses the standard IGP metric values of the links as presented in the Link State Database of the router.
The use-te-metric option must be specified, and CSPF must be enabled in the LSP configuration, in order to be able
to use the TE metric values present in the Traffic Engineering Database (TED).
Module 5 - Page 72
primary "empty_list
path empty_list"
no shutdown
exit
lsp "to_R6
cspf use-te-metric
to 10.10.10.6
primary "empty_list
exit
Path #1: R1-R2-R4-R6 (TE Cost = 700)

Path #2: R1-R3-R5-R6 (TE Cost = 600)
CSPF-Calculated Path: R1-R3-R5-R6
exit
Module 5 |
73
The above slide illustrates the use of the TE metric values in CSPF calculations.
Two alternative paths exist in the ring topology between routers R1 and R6.
Path #1 has a cumulative TE cost value of 700, and Path #2 has a cumulative TE cost of 600.
If the use-te-metric option is enabled in the CSPF configuration, Path #2 will be selected as the LSP path to be
established.
Module 5 - Page 73
Traffic Engineering Metric Configuration
LSP path Failure Scenarios

LSP path establishment failures can occur due to:
y Invalid hop configuration in path definition
y Certain hops becoming unavailable
y No path found with the given constraints
y The Head-End router can detect problems related to the
immediate next-hop only.
y In case of other problems, the Head-End router sends an RSVP
PATH message and receives a PATH Error message back; along
with the failure code indicating the root cause.
If CSPF is enabled:
y The Head-End router validates the path in the TED. If problems
are detected, a PATH message is not sent.
Module 5 |
74
Failures can occur before, during or after an LSP path is established. Possible problems include configuration errors, link
failures or stringent administrative constraints preventing the LSP path from being established. Slightly different
behavior can be observed, depending on whether CSPF is enabled in the LSP configuration.
If CSPF is disabled for the LSP, the Head-End router has no way of knowing if the intermediate hops of an LSP path are
valid or not. It does not have an end-to-end view over the LSP path and can only determine issues related to the
immediate downstream hop. If the next-hop is valid, the Head-End sends out the RSVP PATH message, in the hope that
it will make its way all the way down to Tail-End and receive a RESV message back. This might not be possible in some
cases as presented in the following pages.
CSPF runs a complete check on the specified path definition, and can detect certain potential problems even before the
Head-End attempts to signal the LSP path. CSPF has the entire network topology at its disposal, by virtue of the Traffic
Engineering Database.
Module 5 - Page 74
If CSPF is not enabled:
path wrong-1"
hop 10 10.10.10.5 strict
hop 20 10.10.10.6 strict
no shutdown
exit
Router R5 cannot be a strict hop

for router R1.
No PATH message is sent from
router R1.
Module 5 |
75
The example above illustrates an invalid strict hop configuration that is specified as a next-hop for the Head-End
router, router R1.
As mentioned, a strict hop MUST be an immediate, directly connected next-hop for the previous hop in the list. In this
case, there is no previous hop in the list.
Even if CSPF is not enabled for the LSP, router R1 is capable of determining that router R5 cannot be a strict next-hop
for it by consulting the IGP forwarding table. Accordingly, router R1 does not attempt to signal the LSP path and keeps
it operationally DOWN.
Module 5 - Page 75
Failure Case1 Invalid Strict First Hop
path wrong-2"
no shutdown
exit
Router R1 sends the PATH message

despite the intermediate hop
error.
Router R3 detects the error in the
ERO.
Router R3 sends back a PATH
ERROR.
Module 5 |
76
If there is a strict hop configuration error at an intermediate hop, router R1 cannot check this if CSPF is not enabled for
the LSP under consideration. In this case, router R1 attempts to signal the LSP path by sending out a PATH message,
only to receive a PATH Error message sent by router R3, which is the router that the configuration error is detected on
in the ERO.
Here, the problem stems from the fact that both the first and second hops refer to the same router, R3.
Module 5 - Page 76
Failure Case2A Incorrect Hop (CSPF NOT Enabled)
Failure Case2A CLI Display
------------------------------------------------------------------------------LSP to_R6 Path wrong-2

------------------------------------------------------------------------------LSP Name
: to_R6
Path LSP ID : 54064
From
: 10.10.10.1
To
: 10.10.10.6
Adm State
: Up
Oper State : Down
Path Name
: wrong-2
Path Type
: Primary
Path Admin : Up
Path Oper
: Down
OutInterface: n/a
Out Label
: n/a
. . . . . . . . . . . . .
. . . . . . . . . . . . .
Path Trans : 2
CSPF Queries: 0
Failure Code: badNode
ExplicitHops:
10.1.3.3
-> 10.3.5.3
-> 10.5.6.6
Next-hop (router R3) returns a PATH Error message with RSVP Error Code:
Routing Problem and Error Value: Bad Strict Node
CLI displays:
y Failure Code: badNode
y Failure Node: 10.1.3.3 (node that identified error)
Module 5 |
77
The path failure information is visible in the show router mpls lsp <lsp-name> path [<path-name>] detail
command output. According to the RFC specification, router R3 indicates an error code of Routing Error and an error
value of Bad Strict Node to provide an idea about the source of the problem. Both the LSP and the LSP path are
operationally DOWN because of the strict hop configuration error.
Module 5 - Page 77
path wrong-2"
no shutdown
exit
CSPF detects the error on

router R1.
No PATH message is sent.
Module 5 |
78
CSPF can detect the problems anywhere in the LSP path definition and prevent unnecessary signaling.
The LSP path is again put to an operationally down state, but this time with a failure code of No CSPF Route To
Destination.
Module 5 - Page 78
Failure Case2B Incorrect Hop (CSPF Enabled)
Failure Case2B CLI Display
------------------------------------------------------------------------------LSP to_R6 Path wrong-2

------------------------------------------------------------------------------LSP Name
: to_R6
Path LSP ID : 54064
From
: 10.10.10.1
To
: 10.10.10.6
Adm State
: Up
Oper State : Down
Path Name
: wrong-2
Path Type
: Primary
Path Admin : Up
Path Oper
: Down
OutInterface: n/a
Out Label
: n/a
. . . . . . . . . . . . .
. . . . . . . . . . . . .
Path Trans : 2
CSPF Queries: 1
Failure Code: noCspfRouteToDestination
ExplicitHops:
10.1.3.3
-> 10.3.5.3
-> 10.5.6.6
CSPF on Head-End (router R1) performs a sanity check on the

configured fully strict hop path and detects the problem.
No CSPF Route To Destination failure code is indicated each time
CSPF calculation fails with the given path definition (and constraints).
Module 5 |
79
The CLI output above indicates that the CSPF process on router R1 has been unable to find a valid path with the
specified path and/or administrative constraint definitions.
The fully strict hop LSP path remains down until the configuration error is corrected.
Module 5 - Page 79
no shutdown
exit
Router R1 sends the PATH message.

Router R5 sends back a PATH Error.
LSP cannot be established as long as
the link is down.
Module 5 |
80
In the example above, all the strict hop definitions are correct from a configuration perspective, but a physical link
failure makes the last hop (10.5.6.6) invalid. With CSPF disabled, router R1 has no way of knowing that this last hop has
become unavailable; so it forwards the PATH message downstream anyway. Router R3 also does the same and forwards
the message on to router R5.
Router R5 is the immediate router that is connected to one side of the failed link. Upon receipt of the RSVP PATH
message, it realizes that the message cannot be delivered any further, and so informs the LSP Head-End about the
problem. This is done again with a PATH Error message sent upstream.
Even though the router R1 will continuously try to establish the LSP on the fully strict path, all of these attempts will
fail until the failure on the R5-R6 link is removed.
Module 5 - Page 80
Failure Case3A Strict Hop Link Failure (CSPF NOT Enabled)
no shutdown
exit
CSPF detects the problem.

No PATH message is sent.
LSP cannot be established as long
as the link is down.
Module 5 |
81
If CSPF is enabled, it can detect that the last hop in the path definition is invalid by checking the Traffic Engineering
Database. CSPF process reports to router R1 about this problem, which does not attempt to signal the LSP path until the
failure condition is removed.
Module 5 - Page 81
Failure Case3B Strict Hop Link Failure (CSPF Enabled)
path empty_list"
no shutdown
exit
lsp "to_R6
cspf
to 10.10.10.6
primary "empty_list
include GREEN
If include statement is used, ALL

the links along the LSP path must
be a member of the specified
admin group.
exit
Module 5 |
82
The last failure example covers a specific case of using include statements in administrative group definitions.
The rule states that ALL the links along the candidate LSP path must be members of the specified administrative group
for that path to be considered as eligible. In this case, CSPF is unable to find an eligible path to router R6 because none
of the links, except the link between router R4 and router R6, comply with the administrative constraint.
Care must be exercised in using include statements together with administrative groups. Many network designers try to
stick to using exclude statements only, to make things more straightforward and predictable.
Module 5 - Page 82
Failure Case4A Admin Group Include statement
path empty_list"
no shutdown
exit
lsp "to_R6
cspf
to 10.10.10.6
Using include, CSPF prunes a link if

it is NOT a member of admin-group
GREEN.
primary "empty_list
include GREEN
exit
Module 5 |
83
The above slide illustrates the network topology as contemplated by the CSPF process after executing the
administrative group constraint. All of the links, except the link between router R4 and router R6, are pruned,
rendering the network useless for establishing LSP paths using include statements.
Module 5 - Page 83
Failure Case4A CSPF View
Failure Case4B : Admin Group Exclude statement
path empty_list"
no shutdown
exit
lsp "to_R6
cspf
to 10.10.10.6
primary "empty_list
exclude GREEN
If exclude statement is used, the

router considers ALL the links
EXCEPT those that are members of
the specified admin group.
exit
Module 5 |
84
Module 5 - Page 84
Failure Case4B CSPF View
path empty_list"
no shutdown
exit
lsp "to_R6
cspf
to 10.10.10.6
primary "empty_list
exclude GREEN
Using exclude, CSPF prunes just the

admin-group GREEN links, choosing
the best path among the
remainder.
exit
Module 5 |
85
Module 5 - Page 85
Using CSPF to Check TE Availability

It is possible to check whether a TE path is available to a certain
destination without having to configure and signal an LSP.
CSPF provides such a test function with the following command:
If a source (from) address is not specified, it is the router where

the command is issued.
A different source address can be specified.
Several constraints can be specified.
The command returns the hop information, if a path is available.
Module 5 |
86
At times, network operators might want to check for path availability from a certain source router to a specified
destination. In an IP routed network, ping and traceroute can be used for testing reachability. Using traffic engineering,
it might be desirable to find an answer to questions such as: Can I find a path from router R1 to router R6 avoiding
GREEN links? If so, what would the path be like? While an LSP can be configured with certain constraints for testing
purposes, this method is not so efficient and creates unnecessary signaling in the network.
Alcatel-Lucent Service Routers provide a useful tool to run path availability checks without needing to configure and
signal LSPs. The tools perform router mpls cspf command can be used on any Traffic Engineering enabled
router to calculate a path to a certain destination, together with several optional constraints. The command returns the
hop information, if a path is available.
The starting point for the test path is the router on which the command is issued. However, a from address can
optionally be specified to change this.
Several examples are included in the following pages to illustrate the use of the CSPF Path Check Tool.
Module 5 - Page 86
tools perform router mpls cspf to destination [constraints]
*A:R1# tools perform router mpls cspf to 10.10.10.6 bandwidth 500

CSPF Path
To
: 10.10.10.6
Path 1
: (cost 300)
Start: 10.10.10.1
Egr:
10.1.3.1
Egr:
10.3.5.3
Egr:
10.5.6.5
End:
10.10.10.6
-> Ingr:
-> Ingr:
-> Ingr:
10.1.3.3
10.3.5.5
10.5.6.6
(met 100)
(met 100)
(met 100)
Module 5 |
87
In the example above, the operator wants to determine whether a path is available from router R1 to router R6 that
can reserve 500 Mbps of bandwidth on the links. CSPF returns the viable hop information for the required path, should
an LSP be signaled with that constraint.
Keep in mind that CSPF path check tool is just a local calculation process. No LSP is signaled and no bandwidth is
reserved on the links by the use of this command.
Module 5 - Page 87
CSPF Path Check Example1 Using Bandwidth
*A:R1# tools perform router mpls cspf to 10.10.10.6 exclude-bitmap 16

CSPF Path
To
: 10.10.10.6
Path 1
: (cost 400)
Start: 10.10.10.1
Egr:
10.1.2.1
Egr:
10.2.4.2
Egr:
10.4.5.4
Egr:
10.5.6.5
End:
10.10.10.6
->
->
->
->
Ingr:
Ingr:
Ingr:
Ingr:
10.1.2.2
10.2.4.4
10.4.5.5
10.5.6.6
(met
(met
(met
(met
100)
100)
100)
100)
Module 5 |
88
In this second example, the operator wants to determine whether a path is available from router R1 to router R6 that
avoids the GREEN links. The CSPF path check tool does not accept administrative group names as input, and requires
the hexadecimal or decimal equivalents of the bitmap values as seen in the TED to be specified. The calculation of
these values were explained in Section 1.
Module 5 - Page 88
CSPF Path Check Example2 Using Exclude-Bitmap
*A:R1# tools perform router mpls cspf to 10.10.10.6 include-bitmap 16
MINOR: CLI No CSPF path to "10.10.10.6" with specified constraints.
Module 5 |
89
The example above illustrates that if an include statement must be used, ALL the links along the LSP path must belong
to the specified administrative group. There is no such contiguous path between router R1 and router R6, which is why
CSPF is unable to return hop information with the specified constraints.
Module 5 - Page 89
CSPF Path Check Example-3 Using Include-Bitmap
*A:R1# tools perform router mpls cspf from 10.10.10.3 to 10.10.10.6 exclude-bitmap 16
To
: 10.10.10.6
From
: 10.10.10.3
Path 1
: (cost 400)
Start: 10.10.10.3
Egr:
10.2.3.3
Egr:
10.2.4.2
Egr:
10.4.5.4
Egr:
10.5.6.5
End:
10.10.10.6
->
->
->
->
Ingr:
Ingr:
Ingr:
Ingr:
10.2.3.2
10.2.4.4
10.4.5.5
10.5.6.6
(met
(met
(met
(met
100)
100)
100)
100)
Module 5 |
90
The example above illustrates that a different source address can be specified within the command, which can be
different from the router on which the command is being used. CSPF on router R1 is capable of calculating a path
between any two points in the network as long as they are present in the TED.
Module 5 - Page 90
CSPF Path Check Example4 Different Source Router
Module 5 |
91
LAB 5 Section 5.1 Link Coloring for Constraint-Based LSP Tunnels
Module 5 - Page 91
Section Summary

Configuring administrative constraints on the links (administrative
group, TE-metric)
Configuring path definitions using strict and loose hops
CLI Show commands to monitor the LSP path state
Possible configuration errors and failure scenarios
The CSPF path-check tool
Module 5 |
92
Traffic Engineering must be enabled in the IGP (OSPF or IS-IS) configuration of all the MPLS routers to have the TE
functionality with RSVP.
Additional administrative constraints, such as administrative groups or TE metric, can be configured on the links
inside the MPLS context.
A path definition may be composed of a combination of loose and strict hops. If enabled, CSPF:
Determines that the strict hops are valid
Calculates the exact intermediate hops to a loose hop
When LSP paths (primary and/or secondary) are configured in the LSP context, optional constraints may be
specified to regulate the path that will be taken. CSPF needs to be explicitly enabled in the LSP context to take
these constraints into account.
The show router mpls lsp <lsp-name> path [<path-name>] detail command is one of the most
commonly used commands to check for the status and details of LSP paths. The Failure Code and Failure Node
fields in the output provide useful information as to the source of a potential problem.
If CSPF is not enabled for the LSP, the Head-End cannot detect errors or reachability problems regarding the
intermediate hops along the path. In such a case, an RSVP PATH message is sent, which is responded to by a PATH
Error message by the node detecting the error.
If enabled, CSPF checks and verifies the entire path before signaling by consulting the local Traffic Engineering
Database.
The tools perform router mpls cspf command provides a useful path check tool to test Traffic Engineering
availability to a certain destination with several optional constraints. No LSP is signaled by the use of this
command. If a bandwidth constraint is specified, no bandwidth is reserved on the links.
Module 5 - Page 92
Specifying constraints in LSP path configuration
Section 3 Working with Bandwidth Reservations
Module 5 - Page 93
Section Objectives

Bandwidth Reservation using RSVP-TE and CSPF
IGP TE Bandwidth Update Trigger
Bandwidth Reservation Styles
Least Fill Feature
LSP Soft Preemption (setup and hold priorities)
DiffServ-TE
Module 5 |
94
This section begins with a recap of bandwidth reservations using RSVP-TE. The significance of enabling CSPF in the LSP
configuration is also emphasized.
SR OS includes a feature to define thresholds for advertising the unreserved bandwidth values for the links, rather than
having immediately triggered updates upon every LSP bandwidth reservation and release. The optimization option is
introduced in the section.
The different bandwidth reservation options over shared links for LSP paths belonging to the same LSP are introduced.
The Make-Before-Break (MBB) concept refers to the adaptive behavior of LSP paths to minimize service downtime in
case of changing bandwidth reservation values on-the-fly.
This section explains the least-fill feature used to achieve more balanced bandwidth reservations over redundant links,
and discusses in detail the LSP Soft-Preemption feature using LSP setup and hold priorities.
The section concludes by having an elaborate discussion on the Diffserv-Aware Traffic Engineering (DiffServ-TE) feature.
Module 5 - Page 94
Make-Before-Break (MBB) Behavior
Bandwidth Reservations Recap
An LSP can be configured with a bandwidth constraint at the HeadEnd router.

If enabled, CSPF checks the TED at the Head-End to find an
available path with sufficient unreserved bandwidth.
Each router along the path also checks if the requested bandwidth
is available on the egress interface.
The bandwidth-check operation is called CAC (Connection
Admission Control).
Module 5 |
95
The network administrator can optionally define a certain amount bandwidth reservation in the LSP path configuration.
In the Service Router CLI, the bandwidth reservation values are expressed in Megabits per second (Mbps).
The bandwidth reservation values are only used in the admission phase of the LSP, that is, during initial establishment.
Once the LSP is established, the routers do not perform further checks on the real, utilized bandwidth of the LSP in
relation to the reserved bandwidth.
The required bandwidth reservation is included in the FLOW_SPEC object of the RSVP PATH message sent by the HeadEnd. Upon receipt of the RSVP PATH message, each router checks whether the requested bandwidth is available on the
egress interface that the LSP is going to traverse. This operation is called CAC (Connection Admission Control).
If the CAC operation fails at a certain downstream node, an RSVP PATH Error message is sent to inform the Head-End of
the LSP. If CSPF is not enabled, the errors might persist, so that the Head-End might continuously attempt to signal the
LSP over the links with insufficient reservable bandwidth. CSPF helps to overcome these problems by making a path
calculation upfront in the Traffic Engineering Database, looking for an available path.
Module 5 - Page 95
Bandwidth request is signaled in the RSVP PATH message.
The Need for CAC (Connection Admission Control)
It is possible that the LSP has not been computed by CSPF and the
requested bandwidth reservation might not be available at a
downstream router.
The state change might have been caused by another LSP being set
up, originating at another router.
The Traffic Engineering Database might not be 100% up to date at
the time of CSPF computation, most possibly due to Opaque LSA
throttling (see the Bandwidth Thresholds topic in this section.
Module 5 |
96
Even if the path is calculated by CSPF, the Connection Admission Control procedures might still be required.
If another LSP happens to reserve bandwidth on the desired links within the brief time interval between the CSPF path
calculation and the actual signaling, the LSP setup might fail due to insufficient reservable bandwidth.
As a result of the RSVP-TE Bandwidth Update Trigger feature (introduced later in the section), the local TED might not
be fully up-to-date about the latest bandwidth reservation status of the links. In this case, the LSP Head-End must be
informed again with CAC failure error. The RSVP-TE Bandwidth Update Trigger feature also involves an option to
trigger an immediate IGP update, in case of encountering a CAC failure on a link. This is to synchronize the nodes in the
network with the correct TE information to avoid further problems.
Module 5 - Page 96
Even if the LSP was computed by CSPF, the reservation state might
have changed between the computation and signaling.
The PATH message contains the bandwidth requirement.

Each router performs a CAC on the egress interface.
If the requested bandwidth is available, the PATH message is
forwarded to the downstream hop.
No bandwidth is reserved at this stage.
Module 5 |
97
The example above illustrates the Connection Admission Control (CAC) process performed on each router along an LSP
path.
An LSP is configured with 600 Mbps of bandwidth on router R1, which sends out a PATH message in an attempt to signal
the LSP path. Router R1 itself first determines whether the required bandwidth is available on the link before sending
out the message. This succeeds and the message is delivered to router R2.
Upon receipt of the PATH message, router R2 also verifies that the bandwidth is available and forwards the message to
R4.
R4 repeats the same procedure and the PATH message gets delivered to the tunnel destination, router R6.
It is important to note that the CAC process is just a sanity check performed on the interface. The routers do not
reserve any bandwidth at this stage, as it is uncertain that the CAC will succeed in all the remaining downstream nodes
along the LSP path.
Module 5 - Page 97
Connection Admission Control During PATH Message Flow
Bandwidth is reserved at each upstream hop.

The unreserved bandwidth values are updated and flooded.
Correct QoS policies also needed on the Data Plane for rate
limiting the traffic.
Module 5 |
98
After the bandwidth is verified by the CAC process on each router and the PATH message gets to delivered to the TailEnd router, R6. An RESV message is propagated upstream to establish the RSVP sessions for the LSP path. It is at this
stage that the requested bandwidth is reserved on the egress link of each upstream router.
Upon reserving the bandwidth, the routers send out IGP advertisements to inform the other nodes in the network about
the updated unreserved bandwidth values on the links.
It should be emphasized once again that RSVP bandwidth reservation is strictly a control plane process. The reserved
bandwidth values do not have any regulatory impact on the actual utilization on the data plane of the routers. AlcatelLucent Service Routers offer a wide set of Quality of Service policies and features to perform rate limiting controls on
the data plane.
Module 5 - Page 98
Bandwidth Reservation During RESV Message Flow
Bandwidth Reservation on the RSVP Interface CLI View
===============================================================================
RSVP Interfaces
===============================================================================
Interface
Total
Active
Total BW Resv BW
Adm Opr
Sessions Sessions (Mbps)
(Mbps)
------------------------------------------------------------------------------system
Up Up
toR2
1
1
1000
600
Up Up
toR3
0
0
1000
0
Up Up
------------------------------------------------------------------------------Interfaces : 3
===============================================================================
Total BW: The Maximum Reservable Bandwidth on the interface.

y Equal to the physical bandwidth by default (subscription = 100)
y Over-subscription (>100) and under-subscription (<100) possible.
Resv BW: The total amount of Reserved Bandwidth by ALL LSPs

crossing the interface.
Unreserved BW: Total BW Resv BW
Module 5 |
99
The show router rsvp interface command output displays the total amount of reservable bandwidth, and the
amount of bandwidth out of this total that has been reserved by LSPs on each link.
The physical bandwidth of all links in the example topology are 1 Gbp; the Total BW value equals this value by default.
It is possible to over-book or under-book this capacity by configuring a subscription rate. An example is shown in the
following page.
The Resv BW value is updated every time an LSP reserves bandwidth on a link, or releases its previous bandwidth
reservation. It reflects the total amount of reserved bandwidth by all LSPs crossing that link in the egress direction.
The unreserved bandwidth values are advertised in the IGP TE updates. These values can simply be calculated by
subtracting the Reserved Bandwidth from the Maximum Reservable Bandwidth.
Module 5 - Page 99
A:R1# show router rsvp interface
Example Configuring an Interface for Under-Subscription
A:R4# show router rsvp interface

==================================================================
Interface
Total
Active
Total BW Resv BW
Adm Opr
Sessions Sessions (Mbps)
(Mbps)
-----------------------------------------------------------------system
Up Up
toR2
0
0
1000
0
Up Up
toR6
0
0
400
0
Up Up
-----------------------------------------------------------------Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 5 |
100
A subscription rate of 40 is applied for the interface toR6 on router R4. This reduces the Maximum Reservable
Bandwidth to 400 Mbps on the link, as is illustrated in the show router rsvp interface command output above.
Module 5 - Page 100
A:R4>config>router>rsvp#
-------------------------------interface toR6
subscription 40
lsp "to_R6
to 10.10.10.6
primary fully_loose
bandwidth 600
exit
The PATH message is sent on the

IGP based path.
Router R4 returns a PATH Error
indicating the source of the
problem.
Module 5 |
101
The example above illustrates the Connection Admission Control failure that can encountered on any router along the
path of an LSP.
IF CSPF is not enabled for the LSP, router R1 does not have a way of knowing the bandwidth reservation status of all the
links along the LSP path. In this case, an RSVP PATH message is sent blindly with the required bandwidth value over
the IGP chosen best path. Routers R1 and R2 have the bandwidth available, so the CAC process succeeds on these
routers and the PATH message gets delivered to the next-hop.
As a result of CAC, router R4 discovers that it does not have the requested bandwidth available on the egress link.
Therefore, it rejects the PATH request and sends back a PATH Error message that contains certain fields and flags to
indicate the source of the problem. Monitoring of this fault condition in the CLI is presented on the next page.
Module 5 - Page 101
Example LSP Setup Failure due to CAC Error
CAC Error CLI Display
------------------------------------------------------------------------------LSP to_R6 Path fully_loose

------------------------------------------------------------------------------LSP Name
: to_R6
Path LSP ID : 52736
From
: 10.10.10.1
To
: 10.10.10.6
Adm State
: Up
Oper State : Down
Path Name
: fully_loose
Path Type
: Primary
Path Admin : Up
Path Oper
: Down
OutInterface: n/a
Out Label
: n/a
. . . . . . . . . . . . .
. . . . . . . . . . . . .
Path Trans : 0
CSPF Queries: 0
Failure Code: admissionControlError
The failure code returned in the PATH Error message by router R4 is

displayed in the output above on router R1 (Head-End).
The LSP will remain down until:
y The requested bandwidth becomes available on the link
y The bandwidth request is lowered or removed on the LSP
Module 5 |
102
The operational status of the LSP and the LSP path both appear to be down.
The Failure Code field in the command output above provides a clear indication of the source of the problem.
The admissionControlError indicates that a bandwidth reservation failure has occurred at one of the downstream
nodes.
The downstream node that the failure was detected is also indicated in the Failure Node field. The IP address of
10.2.4.4 belongs to router R4.
With CSPF disabled, router R1 continuously tries to establish the LSP path over the IGP best path. The consecutive path
setup attempts will continue to fail, unless router R4 has the 600 Mbps of reservable bandwidth available on the link, or
the LSP path bandwidth request is lowered or removed by the administrator.
Module 5 - Page 102
lsp "to_R6
to 10.10.10.6
cspf
primary fully_loose
bandwidth 600
exit
CSPF finds an available path for

the LSP.
LSP is signaled.
Module 5 |
103
The above slide illustrates yet another example of CSPF while using administrative constraints. If CSPF is enabled,
router R1 does not try to establish the LSP over the IGP selected best path, where the requested bandwidth is not
available.
By consulting the TED, CSPF finds a path that has available bandwidth to accommodate the reservation request by the
LSP. As described earlier, the calculated hops are included in the ERO of the PATH message and the LSP gets signaled
over the desired path.
Module 5 - Page 103
Example Successful LSP Setup with CSPF
IGP TE Bandwidth Update Trigger Introduction
By default, each time the Reserved Bandwidth on a link changes,

an IGP (OSPF or IS-IS) update is triggered.
This can create a churn in a scaled network with large number of
LSPs constantly reserving or releasing bandwidth.
In that case, updates are triggered only when the Reserved

Bandwidth value crosses certain thresholds on the link.
Thresholds can be defined in the up (rising) or down (falling)
direction.
Module 5 |
104
The default behavior of the Service Router is to generate an immediate IGP TE Update when an LSP reserves or releases
bandwidth on an attached link. In a scaled network with many LSPs, the intense amount of updates propagated and
processed can create a certain amount of overhead.
The Bandwidth Update Trigger feature optimizes the flooding behavior. When enabled, only the significant updates are
sent regarding the bandwidth reservations on the links.
Since the interpretation of significant might change from network to network and operator to operator, the Service
Router allows the definition of custom threshold values for the total amount of reserved bandwidth on the RSVP links.
Thresholds can be defined in the up and/or down directions, as explained in the following pages.
Module 5 - Page 104
When enabled, the IGP TE Bandwidth Update Trigger feature

allows to define bandwidth thresholds.
By default, Link-State Advertisements are sent as soon as the

bandwidth reservation state of a link changes.
The LSA is flooded through the network.
Module 5 |
105
The above slide illustrates the default behavior of propagating IGP TE updates.
If the amount of reserved bandwidth changes with an LSP setup or is cleared, an LSA is immediately generated and
flooded through the network. All the receiving routers need to process this LSA and update their Traffic Engineering
Databases, which also consumes processing resources.
Module 5 - Page 105
Bandwidth Update Default Mode of Operation
When enabled, Link-State Advertisements are sent only when the

configured thresholds are crossed on the link.
Up and Down thresholds can be configured to different values.
Min. 1 and Max. 16 thresholds can be defined in either direction.
Module 5 |
106
If the IGP TE Bandwidth Update feature is enabled, custom thresholds can be defined on the RSVP interfaces in both up
and down directions.
In the up direction, as bandwidth reservations increase on the link, IGP TE updates are sent only when the reserved
bandwidth amount rises above the defined thresholds. In the example above, updates are triggered when the reserved
bandwidth crosses 20%, 50%, 70%, 90%, and 95% of the maximum reservable bandwidth on the link.
Similarly, updates are triggered when the amount of reserved bandwidth on the link falls below the defined thresholds
in the down direction. The threshold values are again defined in percentages of the maximum reservable bandwidth.
The SR OS allows the operators to define up to 16 threshold values in both directions. If the IGP TE Bandwidth Update
feature is enabled, at least one threshold value must be specified in either direction.
Default threshold values also exist that apply in case custom values are not described. These values are shown later in
the section.
Module 5 - Page 106
Up and Down Thresholds
Configuring IGP TE Update Thresholds
Threshold based IGP TE Updates are enabled as below:

configure router rsvp te-threshold-update
configure router rsvp te-up-threshold 20 50 70 90 95
Down thresholds must be configured in descending order:

configure router rsvp te-down-threshold 95 90 80 40 20
Possible to override the global values under RSVP interfaces.

Module 5 |
107
The above slide illustrates the CLI configuration command to enable the IGP TE Bandwidth Update feature.
Once enabled, custom threshold values can be configured in up and down directions.
In the up direction, the threshold values must be configured in ascending order. Similarly, the down thresholds must be
configured in descending order (the Service Router CLI issues a warning if done otherwise).
The configurations shown above are done at the global RSVP context, which apply to all the RSVP enabled interfaces. If
it is desirable to use different values for a certain interface or interfaces, the same te-up-threshold and te-downthreshold configurations are available at the interface level.
Module 5 - Page 107
Threshold values apply to all RSVP interfaces when configured under

the global context.
Up thresholds must be configured in ascending order:
CAC Failure and Timer Triggered IGP TE Updates
In case of a CAC (Connection Admission Control) Failure, an

immediate update can be triggered if the following command is
enabled:
Periodic updates can also be enabled with a timer value in the 1 300 seconds range.
configure router rsvp te-threshold-update update-timer 300
Module 5 |
108
Two more optional commands are also available with the IGP TE Bandwidth Update feature.
The on-cac-failure option instructs the router to immediately send out an IGP TE update in case an LSP setup
attempt fails because of unavailable bandwidth. The idea behind this is that the Head-End router of the LSP might not
be fully in sync with the actual bandwidth reservations in the network, and is trying to reserve more bandwidth than is
readily available. This option lets the router to send an update, regardless of the configured thresholds, for the sake of
bringing all the routers up-to-date about the status of bandwidth reservations.
Another optional configuration parameter is the update-timer. If configured, the router sends out periodic IGP TE
updates for its links, even if no change has occurred in the reservation status of the links.
Module 5 - Page 108
configure router rsvp te-threshold-update on-cac-failure
Default TE Threshold Update Values
When te-threshold-update is enabled in the RSVP context, the

default te-down-threshold and te-up-threshold level values are
valid.
configure router rsvp te-threshold-update
IgpThresholdUpdate
Up Thresholds(%)
Down Thresholds(%)
Update Timer
Update on CAC Fail
:
:
:
:
:
Enabled
0 15 30 45 60 75 80 85 90 95 96 97 98 99 100
100 99 98 97 96 95 90 85 80 75 60 45 30 15 0
N/A
Disabled
A:R4# show router rsvp interface "toR6"
detail
IGP Update
Up Thresholds(%)
: 0 15 30 45 60 75 80 85 90 95 96 97 98 99 100
Down Thresholds(%) : 100 99 98 97 96 95 90 85 80 75 60 45 30 15 0
IGP Update Pending : No
Next Update
: N/A
* indicates inherited values
Module 5 |
109
*
*
The above slide illustrates the default threshold values programmed into the SR OS, if the te-threshold-update
feature is enabled.
The first show router rsvp status command output displays the values that apply to all the RSVP interfaces of the
router. As seen in the second show router rsvp interface detail command output, these values are
automatically inherited by all the interfaces. As mentioned, it is possible to override these values at an interface level.
Module 5 - Page 109
A:R4# show router rsvp status
RSVP-TE Bandwidth Reservation Styles
Reservation Style refers to the way resources are reserved for an

RSVP session at each hop of the LSP path.
For example, a Primary and a hot-standby secondary LSP path

(Secondary LSP protection is discussed in Module 6)
There are two reservation styles defined:
y Shared Explicit (SE): Bandwidth can be shared on the common
link. The total reservation is the maximum reservation made by
either LSP path. This is the default.
y Fixed Filter (FF): The total reservation is the sum of all individual
LSP path bandwidth reservations.
Module 5 |
110
As explained in greater detail later in Module 6 (Resiliency), an LSP can have multiple LSP paths configured to provide
resiliency. An LSP path configured as primary, always has precedence and carries the traffic under normal conditions.
Optionally, a hot-standby secondary LSP path can be defined to protect traffic in case of a failure impacting the
primary LSP path. In this case, the amount of bandwidth that will be reserved on the links that the primary and
secondary LSP paths might be sharing is of particular interest. Although sharing links between redundant LSP paths is
not desired, it can be inevitable in some cases as a result of topological or other reasons.
The Alcatel-Lucent Service Routers support two of the reservation styles defined in RFC 2205: Shared Explicit (SE) and
Fixed Filter (FF).
In the Shared Explicit reservation style, the LSP paths should share the bandwidth on the common link(s). The total
amount of bandwidth counted by the router for the LSP is the largest bandwidth reservation requested by all the LSP
paths. This is the default and recommended method.
Conversely, the Fixed Filter reservation requires the routers to maintain separate bandwidth reservation for the LSP
paths, even though they belong to the same LSP, and despite the fact that only one of these LSP paths is carrying the
data traffic at a given time. Accordingly, the total amount of bandwidth reserved for the LSP is the sum of all the
individual bandwidth reservation values of all established LSP paths. This is not a recommended and used method,
but still supported because of compliance reasons.
Module 5 - Page 110
When multiple LSP paths belonging to the same LSP reserve

bandwidth over a common link, reservation style determines how
much bandwidth is reserved by the LSPs.
Multiple LSP paths are known to belong to the same LSP, if they have
the same Tunnel ID.
With the default SE style, 500 Mbps (max. of 500M and 300M)
is reserved on the shared links (R1-R2 and R4-R6).
Module 5 |
111
In the example above, an LSP is configured with a primary and a (hot) standby secondary LSP path. Since the primary
LSP path is operational, it is carrying the data traffic. The standby secondary LSP path is also established to
immediately take over in case the primary fails.
The primary LSP path is configured for 500 Mbps and the standby secondary LSP path is configured for 300 Mbps of
bandwidth. They are both traversing over the common links between R1-R2 and R4-R6.
Routers R1 and R4 only reserve 500 Mbps for both LSP paths in the default Shared Explicit reservation style. Because
they belong to the same LSP configuration, the two LSP paths are identified by their common tunnel ID (10), assigned by
the Head-End. They are discriminated by their different LSP IDs.
Module 5 - Page 111
Example Shared Explicit (SE) Style Bandwidth Reservation
With the FF style, 800 Mbps (500M+300M) is reserved on the shared

links (R1-R2 and R4-R6).
Not recommended.
Module 5 |
112
The Fixed Filter reservation style is more resource intensive. Using this method, the sum of both bandwidth reservations
by the two LSP paths (500 Mbps and 300 Mbps) is accounted for on the common links. This why the links R1-R2 and R4R6 have only 200 Mbps of reservable bandwidth left on them after both LSPs are established.
The reservation style of an LSP can be changed from the default SE to FF with the following configuration (this is not
recommended):
A:R1>configure router mpls lsp toR6 rsvp-resv-style ff
Module 5 - Page 112
Example Fixed Filter (FF) Style Bandwidth Reservation
Make-Before-Break (MBB) Introduction
MBB is one of the RSVP-TE resiliency features.

Allows live LSP constraint changes with no traffic loss.
The traffic is switched to the new LSP path after it is operationally

up.
The old LSP path is torn down only after a successful switchover.
Module 5 |
113
After an LSP is successfully established, the bandwidth reservation value can be changed in configuration on the HeadEnd router. The objective, however, is to minimize the service downtime that might be caused as a result of this
operation.
For this purpose, a new LSP path is established first with the new bandwidth information. During the setup of the new
LSP, data traffic remains on the old LSP path.
Once the new LSP is established, the Head-End router of the LSP swiftly moves the traffic over to the new LSP path.
After a successful handover of traffic from the old LSP path to the new one, the old LSP path is torn down with a Path
Tear message issued by the Head-End.
If the new LSP path cannot be established for some reason, traffic remains on the old path.
This behavior is called Make-Before-Break (MBB), also referred to as adaptive.
MBB is not limited to changing bandwidth information on the LSP path. Changes in other configuration parameters might
also trigger the MBB behavior.
Module 5 - Page 113
If a parameter (for example, bandwidth) is changed on an

established LSP, a new LSP path is signaled first.
lsp "to_R6
to 10.10.10.6
cspf
primary fully_loose
bandwidth 600
exit
LSP is established with 600M of

reservation.
Only 100M is available on the upper
links due to other reservations.
Module 5 |
114
In the example above, an LSP is established with 600 Mbps of bandwidth over the links in the upper portion of the
network. Another LSP or LSPs also reserves bandwidth, therefore only 100 Mbps is left unreserved in the upper half.
The links in the lower half still have 1000 Mbps of unreserved bandwidth.
Module 5 - Page 114
MBB Example Initial Condition
lsp "to_R6
to 10.10.10.6
cspf
primary fully_loose
bandwidth 800
exit
Change configured bandwidth while

LSP in service
CSPF looks for an available path
with the new bandwidth
constraint.
Module 5 |
115
A configuration change is performed by the administrator, increasing the bandwidth reservation from 600 Mbps to 800
Mbps. Since CSPF is enabled, it is obliged to search for an available path that can accommodate the updated bandwidth
in the TED.
Module 5 - Page 115
MBB Example Bandwidth Increase
With Shared Explicit, CSPF only looks for the delta amount of 200M
(800M-600M) on the existing LSP path. It is not available there.
CSPF calculates a new path using the available links.
Module 5 |
116
Since the new LSP path belongs to the same LSP, CSPF first tries to increment bandwidth by the delta amount of 200
Mbps on the existing LSP path. This is in relation to using the default bandwidth reservation style, shared explicit. Only
100 Mbps is left unreserved on the previously chosen LSP path, so CSPF is forced to look for an alternative path.
CSPF finds a new LSP path with the hops: R1-R3-R5-R6. This path is then signaled by RSVP, as shown on the next page.
Module 5 - Page 116
MBB Example New Path Calculation
The new LSP path is established with the same tunnel ID and an
incremented LSP ID.
Data traffic stays on the old LSP path during this process
Module 5 |
117
The new LSP path is signaled by RSVP over the links in the lower half. Until the signaling is completed, data traffic
assigned to the LSP remains on the old LSP path.
Note that the new LSP path has the same tunnel ID as the old one. This can have a consequence on the bandwidth
reservation style, as described earlier. The LSP ID of the new LSP path is incremented to distinguish the two LSP paths.
Module 5 - Page 117
MBB Example Signaling the New Path
Data Traffic is switched over to the new LSP path.

Both LSP paths co-exist for a brief period of time.
Module 5 |
118
Once the new LSP path is established, the Head-End switches the traffic over to it. In other words, the data is
forwarded with new labels that are assigned to the new LSP path over the redundant links.
During this process, both LSP paths co-exist over the network for a short interval, occupying resources at the same
time. Because of this, admission control errors might be encountered if the two LSP paths go over common links and
fixed-filter reservation style is used.
Module 5 - Page 118
MBB Example Traffic Switchover
Router R1 sends a PATH Tear message to tear down the old LSP.
RSVP sessions that belong to the old LSP are cleared on all routers.
Module 5 |
119
After a successful switchover, the old LSP path is torn down with a PATH Tear message. The RSVP sessions and the
bandwidth reservation for the LSP path are cleared on all the participating routers.
Module 5 - Page 119
MBB Example Tearing Down the Old LSP
MBB Remarks
If a new LSP path cannot be established, traffic stays on the old

LSP path (do not break if you cannot make).
MBB is enabled by default.
MBB can be disabled per LSP (not recommended):
configure router mpls lsp to_R6 no adaptive
Module 5 |
120
The Make-Before-Break mechanism has other uses as well. These include:

Using Fast Reroute, the traffic is switched over to a protection tunnel if the primary LSP path fails. The LSP HeadEnd can then find another path for the primary, or re-establish it over the existing links if the failure is removed.
The switchover from the FRR protection tunnel to the new primary LSP path is performed in an MBB fashion. This is
covered in greater detail in Module 6.
If the global-resignal timer is effective for the LSP, the Head-End might look for a better path for all its CSPFenabled active LSP paths at regular intervals. If a better path is found for an LSP path, the traffic is switched over
to it in an MBB fashion. This is also one of the topics covered in detail in Module 6.
The LSP Soft Pre-emption feature explained later in this section also utilizes the MBB.
If for some reason the new LSP path cannot be established, the Head-End does not break the old LSP path.
Make-Before-Break is enabled for LSPs by default, and can be disabled with the CLI command shown in the figure above.
This is not recommended practice.
Module 5 - Page 120
MBB is also used when:

y Reverting traffic back from the Fast-Reroute protection mode
(explained in Module 6)
y Automatically resignaling the existing LSP path for optimization
(explained in Module 6)
y LSP soft pre-emption (explained later in this section)
Least-Fill Bandwidth Reservation Rule
Applies to the case when the Head-End router has multiple paths
with equal IGP costs to a certain LSP destination.
By default, CSPF randomly chooses one of the equal cost links each
time an LSP is configured to the destination.
The east-fill configuration option instructs CSPF to choose the

links with the least amount of bandwidth reservations.
CSPF must be enabled on the LSP.
ECMP need NOT be enabled in the configure router ecmp
context for the least-fill feature to work.
Module 5 |
121
In a topology with multiple equal cost paths between a Head-End and Tail-End router, CSPF still needs to choose one of
the available paths that have the required bandwidth available. The default selection is done in a random manner to
allow for dispersion in bandwidth reservations. However in some cases, this might lead to an unbalanced distribution of
bandwidth reservation on the alternative paths.
The least-fill option can be enabled in the LSP configuration to force CSPF to choose the path with the least amount of
bandwidth reservation.
The ECMP (Equal Cost Multiple Path) feature introduced earlier in Module 3 (LDP) is not required for the least-fill
feature to function.
Module 5 - Page 121
This might lead to an unbalanced distribution of bandwidth

reservation on the links.
2 LSPs are already established on different links with different

bandwidth reservations.
The two paths have equal IGP costs.
Module 5 |
122
In the example above, two LSPs are already established on the two alternative paths with 500 and 200 Mbps of
bandwidth reservation respectively. 500 Mbps is left unreserved on the upper half, and 800 Mbps is yet unreserved on
the lower half of the topology.
Both paths have the same cumulative IGP cost, making them equally preferable for CSPF.
Module 5 - Page 122
Example Initial Condition
lsp 3
to 10.10.10.6
cspf
primary fully_loose
bandwidth
300
exit
CSPF randomly chooses one of

the available paths for LSP 3.
Unbalanced bandwidth
reservation on the links.
Module 5 |
123
A third LSP is configured on router R1, and requests 300 Mbps of bandwidth. Both paths are eligible, and there is the
likelihood that CSPF will choose the upper path. This would result in an uneven distribution of bandwidth reservation
over the two paths. In this scenario, the upper path has 800 Mbps of reserved bandwidth, while the lower path only has
200 Mbps.
Module 5 - Page 123
Example LSP 3 Without Least-Fill
lsp 3
to 10.10.10.6
cspf
least-fill
primary fully_loose
bandwidth
300
exit
CSPF chooses the least occupied

path when least-fill is enabled.
Leads to more balanced
bandwidth distribution.
Module 5 |
124
If the least-fill option is enabled in the LSP configuration, CSPF is mandated to prefer the path with the least amount of
bandwidth reservation. This results in a more balanced reserved bandwidth distribution.
Module 5 - Page 124
Example LSP 3 With Least-Fill
LSP Soft Preemption
Allows more important LSP paths to preempt less important

LSP paths, if they contend for the same resources.
LSP paths can be given different priority values to denote their
importance.
The unreserved bandwidth values at each priority level of a link
are signaled via IGP TE.
Module 5 |
125
Careful network planning is essential when working with RSVP-TE bandwidth reservations. Network designers need to
ensure that LSPs are distributed over different paths in the most efficient manner possible.
Even with the most elaborate network design, situations might arise where an LSP or LSPs cannot be established as a
result of insufficient reservable bandwidth on the links.
The LSP Soft Preemption feature allows the operator to define relative priorities for LSPs that use bandwidth
reservations. This lets a more important LSP, with a better priority value, to preempt (or bump) another, less
important LSP, to free up the bandwidth that it requires on the links.
To accommodate this, LSP paths are given specific priority values to denote their importance. In addition, bandwidth
reservations are performed more granularly, at 8 different priority values.
The unreserved bandwidth values at each priority level are signaled in IGP TE updates, within the Unreserved_BW SubTLV.
Module 5 - Page 125
Works in conjunction with bandwidth reservations.
Soft Preemption LSP Setup and Hold Priorities
Setup and Hold Priorities are defined for an LSP path.

Possible values for both priorities range from 0 to 7.
A lower numerical value indicates a better priority or a more
important LSP. 0 is the best priority.
LSP A can preempt LSP B if the setup priority of LSP A is better

than the hold priority of LSP B.
Setup and Hold Priorities of an LSP are signaled in the
SESSION_ATTRIBUTE object of the RSVP PATH message.
Module 5 |
126
LSP paths have two priority values associated to them: Setup and Hold Priorities.
Both the setup priority and the hold priority indicate with their relative values whether an LSP can preempt another
LSP. The lower the priority value, the higher the importance. The setup priority indicates how important the LSP is to
preempt the other LSPs, while the holding priority indicates how the weight of that LSP to hold on to its reservations on
the links.
The RSVP PATH message includes a SESSION_ATTRIBUTE object that indicates the setup and hold priorities of the LSP,
along with other fields.
Module 5 - Page 126
A higher numerical value indicates a worse priority or a less

important LSP. 7 is the worst priority.
Configuring Setup and Hold Priorities
The default value for the Setup priority is 7 (the LSP can never
preempt another existing LSP).
The default value for the Hold priority is 0 (once established, the
LSP can never be preempted by another LSP).
Best practice is to set them equal.

In CLI, the first value denotes the setup priority and the second
value denotes the hold priority of an LSP path:
primary fully_loose
bandwidth 400
priority 2 2
exit
Module 5 |
127
The default setup priority for an LSP is 7, which is the worst, or least important, priority value for an LSP. With this
priority value, the LSP cannot preempt any other LSPs that are already established.
The default hold priority for an LSP is 0, which is the best, or most important, priority value for an LSP. With this
priority value, no other LSP can preempt this LSP once it is established.
It is not possible to configure a setup priority that is numerically higher than its hold priority. If this were the case for
two different LSPs contending for bandwidth on the same links, undesirable conditions would occur, where the two LSPs
would continuously preempt each other in an indefinite loop.
The recommended practice is to set both priority values equal, for simpler management. When the routers signal an
LSP, they measure the unreserved bandwidth at their desired setup priority. Then they compare the setup priority at
that level to the hold priority set by existing LSPs. If the new LSP has a higher setup priority and needs the bandwidth
reserved by an low hold priority LSP, the new LSP can preempt the old. The unreserved bandwidth shown in the opaquedatabase represents bandwidth dedicated to a specific hold priority.
For example, LSP A, with setup and hold priorities = 5, reserves 600M of bandwidth on a 1G link. Without
oversubscription, this leaves 400M bandwidth unreserved at P5 and lower. Since higher setup priorities (0-4) can
preempt a hold priority of 5, P0-P4 show all of the links bandwidth, 1000M, as unreserved.
LSP B, with setup and hold priorities = 3, needs 500M of bandwidth on the same link as LSP A. The Head-End checks the
TED for links that (1) provide the needed bandwidth, and (2) can be preempted, if necessary. Since both LSPs must use
the same link, the Head-End determines that LSP B, with setup priority 3, beats LSP A, with hold priority 5. At hold
priority 3, all of the links bandwidth is available, so the Head-End preempts LSP A to obtain the necessary bandwidth
for LSP B. Now, only P0-P2 show all the links bandwidth unreserved, and P3-P7 show only 400M unreserved.
LSP A stays down, as CSPF cannot find a path with the necessary amount of unreserved bandwidth available.
Module 5 - Page 127
The setup priority of an LSP cannot be numerically lower than its

hold priority (to avoid preemption loops).
Unreserved Bandwidth
on links:
R1-R2
R2-R6
P2 = hold priority
This shows that an LSP with a setup priority of 0 or 1 still sees

unreserved bandwidth of 1000M on the links (using CSPF).
The lower priority LSPs only have available that bandwidth which LSP 2
left unreserved, as LSP2 can preempt them.
Module 5 |
128
Initially, both of the links in the example above have 1000 Mbps of unreserved bandwidth. In turn, the unreserved
bandwidth values per each priority level are also set to 1000 Mbps (1,000,000 Kbps).
An LSP is configured with 400 Mbps of bandwidth and a priority value (both setup and hold) of 2.
As a result, the unreserved bandwidth values at priority level 2 and worse priority levels (3-7) are decreased to 600
Mbps. If another LSP with priority between 2-7 wants to reserve bandwidth, it can only do this up to 600 Mbps.
On the other hand, an LSP with a priority value of 0 or 1 can still reserve up to 1000 Mbps on the link. This is because it
can preempt the existing LSP at priority level 2, and clear its bandwidth to make room for its own.
Module 5 - Page 128
Unreserved Bandwidth per Priority Level
Preemption Example First LSP Set-up
* Assume equal setup and hold
LSP 1 is setup on the shortest IGP

path, reserving 400M at priority
level 2.
Module 5 |
129
The examples on this and the following series of pages are used to illustrate the use of LSP priorities and soft
preemption.
In the figure above, LSP 1 is established on the shortest IGP path between router R1 and router R6 with a bandwidth
reservation of 600 Mbps. The LSP is configured with a priority value of 2.
The unreserved bandwidth values are updated on the links that the first LSP traverses, as shown in the figure.
Module 5 - Page 129
priorities per LSP
Preemption Example Second LSP Set-up
LSP 2 is also setup on the shortest

IGP path, reserving 300M at
priority level 5.
Module 5 |
130
A second LSP is configured on router R1, requesting for 300 Mbps of bandwidth at priority level 5. The bandwidth is
available on the shortest IGP path, so LSP 2 is also established on the same path.
At this point,
- an LSP with a priority between 5-7 can only reserve 300 Mbps,
- an LSP with a priority between 2-4 can reserve 600 Mbps,
- an LSP with a priority between 0-1 can still reserve 1,000 Mbps,
on the shortest IGP path.
Module 5 - Page 130
priorities per LSP
Preemption Example Third LSP Set-up
The shortest path does not have

the 500M at P7 level that LSP 3
requests, so the LSP is established
on the other path.
Module 5 |
131
A third LSP is configured on router R1, requesting 500 Mbps at priority level 7. As the figure above illustrates, this
bandwidth is not available at that level on the shortest IGP path. Therefore, CSPF calculates an alternate path for this
LSP, going over the hops R1-R3-R5-R6. The unreserved bandwidth value at P7 is updated on the lower path.
Module 5 - Page 131
priorities per LSP
Example Fourth LSP Setup Attempt Without Priorities
Without explicit priorities, a new LSP 4 requesting 600M at this time

will not be established.
This is because, by default, all LSPs reserve bandwidth at priority level
7 and they cannot preempt each other.
Module 5 |
132
Recall that the default setup priority for all LSPs is 7, and the default hold priority is 0, which does not allow for
preemption between the LSPs.
If these default values were used, a fourth LSP that is asking for 600 Mbps of bandwidth would not get established,
because of insufficient reservable bandwidth on any of the paths.
The following pages resume the story presented on the previous pages using the priority values.
Module 5 - Page 132
priorities per LSP
Both paths have the required bandwidth at

P3 level.
CSPF chooses the lowest cost path.
Module 5 |
133
LSP 4 is established with 600 Mbps of bandwidth reservation at priority level 3.

CSPF checks the Traffic Engineering Database for an available path. As is illustrated in the figure above, both paths
have the required bandwidth at the P3 level, so both are eligible. CSPF chooses the shortest IGP path.
Module 5 - Page 133
Example Fourth LSP Setup Attempt With Priorities
LSP 2 at Priority 5 with 300M must be

preempted.
After the setup of LSP 4, no more
bandwidth is available at levels P3 and
below.
Module 5 |
134
LSP 4 is established over the shortest IGP path chosen by CSPF. The unreserved bandwidth values at priority level
between 3-7 drop to zero. This means that all the LSPs at a worse priority level than 3 must be preempted.
In this example, LSP 2 must be preempted because there is no more room for the 300 Mbps it reserved on the shortest
IGP path.
Module 5 - Page 134
Preemption Example Fourth LSP Setup
CSPF finds a new path for LSP 2.

LSP 2 switches over to the new path in a
make-before-break fashion.
Module 5 |
135
When the preemption process is initiated, LSP 2 is not immediately torn down, so as to avoid service impact.
CSPF searches for an alternative path for the LSP. The lower path has the required 300 Mbps of bandwidth at Priority
level 5, so the new LSP 2 gets established over that path. The data traffic is then switched over to the new LSP and
the old LSP is torn down, as imposed by the Make-Before-Break behavior introduced earlier.
As opposed to the scenario presented in one of the previous pages with the default priorities, all LSPs are eventually
established using the preemption techniques.
Module 5 - Page 135
Preemption Example After Preemption
CLI Show Commands
A:R1# show router mpls lsp 2" path detail

------------------------------------------------------------------------------LSP 2 Path fully_loose
------------------------------------------------------------------------------LSP Name
: 2
Path LSP ID : 52752
From
: 10.10.10.1
To
: 10.10.10.6
Adm State
: Up
Oper State : Up
. . . . . . . . . . . . .
. . . . . . . . . . . . .
Last MBB
:
MBB Type
: SoftPreemption
MBB State
: Success
Ended At
: 06/21/2010 00:50:31
Old Metric : 200
Viewing the Unreserved Bandwidth values in the TED:

A:R1# show router ospf opaque database adv-router 10.10.10.1 detail
. . . . . . . . . . .
Sub-TLV: 8
P0: 1000000
P4:
0
. . . . . . . . . . . . . . . . . . . . . . .
Len: 32
UNRSRVD_CLS0 :
Kbps P1: 1000000 Kbps P2: 600000 Kbps P3:
Kbps P5:
0 Kbps P6:
0 Kbps P7:
Module 5 |
136
0 Kbps
0 Kbps
The Make-Before-Break state of an LSP is displayed in the show router mpls lsp <lsp-name> path [<pathname>] detail command output.
In the first figure above, the last MBB was initiated by the LSP Soft Preemption process and was successful. The time
that the switchover to the new LSP path took place is indicated in the output. The old metric value, which is calculated
by the IGP metric values of the links on the old LSP path by default, can also be seen.
The unreserved bandwidth values per priority level are visible in the TED detail output, as presented in the second
figure above. As mentioned, these values are propagated to other routers in the network by means of IGP TE updates.
Module 5 - Page 136
Viewing the MBB state of an LSP:
RSVP Preemption-Timer and LSP Retry-Timer
When MBB is initiated on a preempted LSP, CSPF looks for an

available path for a maximum duration determined by the
preemption-timer:
The default preemption-timer value is 300 seconds.

If no new path is found within 300 seconds, CSPF turns the
preempted LSP path operationally down.
Until the preemption-timer expires, CSPF can try at regular
intervals determined by the retry-timer of the LSP:
configure router mpls lsp to_R6 retry-timer <seconds>
The default retry-timer is 30 seconds.

Module 5 |
137
A global preemption-timer, which governs the maximum interval that an LSP can conclude its make-before-break
process, is defined. This is set to 300 seconds by default.
When the preemption process kicks off, the first CSPF re-calculation attempt is performed after 30 seconds, by default.
This interval is determined by the retry-timer, which is configurable per LSP. If an available path is found, the data
traffic is switched over to it in an MBB fashion.
If a new LSP path is not found at the first attempt, CSPF can keep making new calculations at retry-timer intervals.
During this time, the old LSP path is still not torn down and continues forwarding the traffic.
If, for some reason, no new path is found before the preemption-timer expires, the LSP path is set to an operationally
down state and starts discarding traffic.
Module 5 - Page 137
configure router rsvp preemption-timer <seconds>
DiffServ (Differentiated Services) Overview
RFC 2475 describes the DiffServ architecture that defines the

various Quality of Service Mechanisms.
The objective is to provide different qualities of service for
different types of traffic for optimal bandwidth management.
These groups are called behavior aggregates or in Service

Router terminology: Forwarding Classes.
Separate queuing, buffering, policing, shaping, dropping
techniques can be applied on packets mapped to different
forwarding classes.
Performed on the Data Plane of the router.
Full details covered in the SRC Quality of Service course.
Module 5 |
138
To regulate the actual traffic flows on the data plane, several models have been proposed and used.
An alternative method to the Differentiated Services model presented briefly on this page is the Integrated Services
model, described in RFC 1633. The Integrated Services model aims at maintaining dedicated Quality of Service
characteristics for each traffic flow, on all the devices that flows are forwarded on. This model has not found
widespread use because of serious limitations on scalability. The routers need to keep track of QoS characteristics for
individual flows, which can be a considerable process and memory intensive task for the routers.
The Differentiated Services model aims to solve these scalability issues by aggregating the numerous microflows into a
limited number of macroflows. The classification of microflows into macroflows can be done using several fields or
markings in the packet headers. The macroflows are named as forwarding classes in the Alcatel-Lucent Service Router
parlance. Up 8 Forwarding Classes can be defined and used on the Service Routers. Packets that belong to specific
forwarding classes can be subject to separate rate limiting, queuing, buffering, policing, and shaping characteristics,
based on the policy configurations. These procedures are all performed in the data plane of the router, where the
actual customer traffic flows through.
The Differentiated Services model is mentioned briefly to explain the main concepts for Traffic Engineering here.
A more elaborate discussion on DiffServ and other related topics can be found in the Quality of Service course of the
SRC program.
Module 5 - Page 138
Built around the classification of all flows into a small number of

groups, to increase scalability.
QoS Forwarding Classes on the Service Router
Default
Class
Type
High
Priority
(Premium)
Assured
Best
Effort
FC
ID
FC Name
FC
Designation
Definition
Network
Control
NC
Intended for network control traffic.
High-1
H1
Intended for network control traffic or

delay/jitter sensitive traffic.
Expedited
EF
High-2
H2
Low-1
L1
Intended for assured traffic. Also the default

priority for network management traffic.
Assured
AF
Intended for assured traffic.
Low-2
L2
Best Effort
BE
Intended for delay/jitter sensitive traffic.
Intended for best effort traffic.
Module 5 |
139
The SR/ESS supports eight internal forwarding classes. The graphic shows the default definitions. Users can create QoS
policies that determine which traffic will be mapped on ingress and egress into these forwarding classes. As we have
seen previously, Classifiers can inspect PDUs and many different layers of the OSI models to ensure that the data traffic
is properly marked as it enters and leaves the forwarding classes.
Think of forwarding classes as virtual pipes, configured as services between PE devices in the core of a network. These
macroflows can further be categorized into three class types:
High Priority
High priority forwarding classes are serviced before other forwarding classes. These forwarding classed (FC ID 4, 5, 6,
and 7) are high priority because they are intended for real-time traffic.
Assured
Assured forwarding provides services with a committed information rate (CIR) and a peak information rate (PIR) in the
same way that traditional edge WAN services like Frame Relay do. Assured FC traffic is normally marked as high-priority
or low-priority so that when the network experiences congestion, low priority traffic becomes essentially discard
eligible, and will be discarded in favor of high priority traffic.
Best Effort
The Best Effort forwarding classes do not guarantee delivery. This class is best effort because, at best, the network
will treat packets in this class like low priority packets in the Assured forwarding class.
Module 5 - Page 139
All types of IP or MPLS encapsulated traffic can be mapped to 8

different QoS Forwarding Classes on the Service Router:
DiffServ Aware Traffic Engineering (DiffServ-TE) Overview
DiffServ-TE allows making bandwidth reservations to be performed

on a per-class basis.
Defined in RFC 3564.
Provides more granularity in terms of bandwidth reservations.
DiffServ-TE is a control plane mechanism.

Consistent QoS mechanisms still needed on the data plane.
Module 5 |
140
Diffserv Aware Traffic Engineering (DiffServ-TE), defined in RFC 3564, enables more granular bandwidth reservations,
based on class type.
By default, all LSPs reserve bandwidth from a common pool, which is determined by the maximum reservable
bandwidth defined on each individual link. Different priority levels can be defined, as presented earlier in the section,
but this lacks class differentiation between the LSPs. DiffServ-TE takes the bandwidth reservations one step further by
enabling the option to define separate pools of reservable bandwidth, based on class type.
It is important to note that DiffServ-TE is also a purely control plane mechanism. It does not have a direct impact on
the operations performed on the data plane of the router.
By careful design, the forwarding class definitions in DiffServ-based QoS applied on the data plane can be correlated
with the class definitions in the RSVP DiffServ-TE context applied on the control plane. This would obviously bring the
ultimate benefit in overall Traffic Management.
Module 5 - Page 140
Provides a link between Forwarding Class based Quality of Service

and MPLS Traffic Engineering.
DiffServ-TE Class Type
8 Class Types (CTs) can be defined in DiffServ-TE.

A CT can be seen as a network-wide Forwarding Class.
LSPs can be assigned a specific Class Type. Mapping of FCs to LSPs
is done at the SDP level.
Possible Class Type values are: CT0 through CT7

The Class Type information of an LSP is included in the RSVP PATH
message for CT1 through CT7.
If the Class Type information is missing in the PATH message, CT0
is assumed (for backwards compatibility with non-DiffServ-TE
compliant routers).
Module 5 |
141
An important definition in DiffServ-TE is Class Type. A Class Type can be perceived as a network-wide forwarding class,
defined in the context of RSVP-TE bandwidth reservations. Similar to QoS Forwarding Classes, up to 8 Class Types can
also be defined in the DiffServ-TE context.
In the Diffserv-TE context, the Maximum Reservable Bandwidth of a link can be divided into separate pools per Class
Type. The different models that can be used to perform this division is introduced later in the section.
In turn, a certain Class Type can be configured for an LSP at the Head-End. Using DiffServ-TE, the LSP reserves
bandwidth from the pool that is allocated for its specific Class Type. In order to accomplish this, the Class Type
information for an LSP is signaled within the RSVP PATH message. This way, all routers along the LSP path are made
aware of which Class Type pool they should reserve the bandwidth from.
The possible Class Type values are between CT0 and CT7. For backwards compatibility with routers that do not support
DiffServ-TE, the default Class Type 0 is not indicated in the RSVP PATH messages. For routers that support DiffServ-TE,
this means that if the Class Type information is missing the PATH message; CT0 is implied.
Class based forwarding over MPLS LSPs allows the user to direct service packets into specific LSPs based on the
packets forwarding class
Mapping of FCs to LSPs is done at the SDP level
Traffic is classified on ingress using a SAP ingress policy. The traffic is then assigned a FC based on the policy.
Under the SDP, the FC is then mapped to an LSP
There is a verification command under the SDP configuration context to ensure that the FC to CT mapping in the
SDP is the same as the FC to CT mapping in the RSVP configuration:
config>service>sdp>class-forwarding>enforce-diffserv-lsp-fc
The default behavior is NOT to check
The mapping of CT to FC is done under the RSVP configuration
config>router>rsvp>diffserv-te# fc be 0
Module 5 - Page 141
RSVP-TE can reserve bandwidth based upon the class type in

combination with a preemption priority.
The default Class Type value of an LSP is CT0.

8 different priorities can be defined with values from 0 through 7.
The priority values determine the preemption order, as covered earlier
in this section.
Module 5 |
142
The above slide illustrates the default mode of operation (even without DiffServ-TE is enabled).
All the LSPs have an implicit Class Type value of CT0 and they can reserve bandwidth at 8 different priority values. The
process is as explained earlier in the section, in LSP Soft Preemption.
Module 5 - Page 142
Default Class Type CT0
CSPF algorithm is enhanced to make path calculations based on the 8

different Class Type and Priority values.
In theory, 64 CT-Priority combinations would be possible that need to
be advertised by IGP-TE.
Module 5 |
143
DiffServ-TE takes the granularity in bandwidth reservations one step further, by introducing the Class Type concept.
By extending Class Types from the default CT0 to CT7, and combining them with the 8 different priority levels that can
be assigned to LSPs, a bandwidth reservation matrix is achieved as illustrated in the figure above.
Theoretically, this would result in 64 different combinations for an LSP when making bandwidth reservations.
In practice, this is not really the case, as explained on the following page.
Module 5 - Page 143
Class Type Priority Matrix
RFC 4124 limits the number of CT-Priority combinations that can be

advertised by IGP-TE to 8, to avoid possible churn in the network.
The combination of a CT and priority is called a TE Class.
The TE classes must be configured consistently all over the network.
Module 5 |
144
The IETF (Internet Engineering Task Force) decided to limit the number of usable LSP Class Type-Priority combinations
to 8 (after heated discussions). The regulation is described in RFC 4124.
Therefore, the 8 CT-Priority combinations must be carefully chosen during the initial network design phase.
To streamline the implementations, each CT-Priority combination is assigned to a separate entity, named TE Class. The
TE Class definitions must be consistently configured on all the DiffServ-TE capable routers in the network.
CT0 is by common convention assigned to LSPs that carry traffic in the lowest QoS priority class, named Best Effort.
Relatively more important traffic classes are assigned increasing Class Type values, CT1, CT2, and so on.
Although the decision depends totally on the specific network design, generally, it might be a good idea to associate
numerically higher (worse) priority levels with lower Class Types (CT0, CT1, and so on), if preemption is required
between the LSPs from different Class Types. Certain examples are presented later in the section to demonstrate in
which cases this approach would apply.
Module 5 - Page 144
Traffic Engineering Class (TE Class)
There are 2 models that define how the Maximum Reservable

Bandwidth will be allocated per class-type:
y Maximum Allocation Model (MAM)
y Russian Dolls Model (RDM)
Bandwidth allocation per class-type is called a Bandwidth Constraint.

Module 5 |
145
Another important decision in DiffServ-TE deployments is the choice of the bandwidth allocation model.
A bandwidth allocation model determines how the Maximum Reservable Bandwidth will be divided across different pools
dedicated for each Class Type.
Two models have been defined and are supported by the Service Router:
Maximum Allocation Model (MAM)
Russian Dolls Model
These models are explained in the following pages with definitive examples.
In the RFC and the Service Router CLI, the amount of bandwidth allocation defined for a Class Type is called a
Bandwidth Constraint (BC).
Module 5 - Page 145
Bandwidth Constraint (BC) per Class-Type
Maximum Reservable Bandwidth is divided per Class Type.

Each class type is given a fixed (guaranteed) Bandwidth Constraint.
The sum of all values must be no greater than 100 (%).
No bandwidth sharing is allowed between different CTs.
Module 5 |
146
Using the Maximum Allocation Model (MAM), each Class Type is assigned a fixed percentage of the Maximum Reservable
Bandwidth on each RSVP-TE link. This allows for a more straightforward bandwidth allocation scheme, with clear
separation between Class Types.
The LSPs in each Class Type can reserve bandwidth from their dedicated pool.
No bandwidth sharing is allowed between different Class Types. This means an LSP in a certain CT is not allowed to
reserve bandwidth from a pool that is designated for another CT.
A bandwidth constraint of zero can be defined for unused Class Types. The sum of the bandwidth constraints for all
Class Types cannot exceed 100.
Module 5 - Page 146
Improves bandwidth efficiency by allowing CTs to share bandwidth.

The unused bandwidth by CT1 and CT2 can be used by CT0.
The unused bandwidth by CT2 can be used by CT1.
Requires preemption (different priorities between CTs).
Module 5 |
147
The Russian Dolls Model (RDM) is named after the infamous decorative items invented in Russia, also called matryoshka.
A matryoshka doll is a set of wooden dolls of decreasing sizes placed one inside the other.
This naming convention is intuitive, as the visualization of the Class Types in RDM resembles the nested structure in
matryoshka dolls. Only 3 Class Types are shown in the figure above for the sake of simplicity.
In the Russian Dolls Model, a lower CT (for example, CT0) is allowed to reserve from the unused portion of bandwidth of
the pools defined for the upper CTs (CT1, CT2, and so on). This model allows bandwidth sharing between different Class
Types, as opposed to the Maximum Allocation Model. This can be useful in cases where a hierarchical model needs to be
deployed for bandwidth reservations in the network.
As an example, CT0 can be assigned to LSPs carrying the least important type of traffic, namely best effort traffic.
None, or very low portion, of the Maximum Reservable Bandwidth can be defined for CT0, and the LSPs in this Class
Type can be allowed to reserve bandwidth from the pools belonging to the upper classes, as long the bandwidth is not
used by those classes. If, for example, an LSP at CT0 has reserved bandwidth from the CT1 pool, and an LSP at CT1 must
be established requiring that bandwidth, the LSP at CT0 will be preempted to make room for the more important LSP.
For this reason, correct priorities must also be carefully assigned to LSPs belonging to different Class Types.
A case study is covered in the following pages to illustrate the use of both bandwidth allocation models.
Module 5 - Page 147
Russian Dolls Model (RDM)
Requirements are:
y Voice LSPs are considered as more important as they carry more delay
sensitive traffic.
y Voice LSPs should never be driven away from their shortest path because of
Data LSPs.
y A Voice LSP should never preempt another Voice LSP.
y A Data LSP should never preempt another Data LSP.
Module 5 |
148
The case study above covers a scenario for a fictitious service provider providing two types of services: Voice and Data.
The DiffServ-TE feature will be used with RSVP-TE LSPs that are going to be created for each type of service.
The general guidelines and requirements are as follows:
1. Voice LSPs are considered more important because they carry more delay sensitive traffic.
2. Voice LSPs should never be driven away from their shortest path because of Data LSPs.
3. A Voice LSP should never preempt another Voice LSP.
4. A Data LSP should never preempt another Data LSP.
Item #1 is assured by assigning the Voice Class to a higher Class Type in DiffServ-TE (and higher Forwarding Class in data
plane QoS).
Item #2 is assured by assigning a lower numerical (better) priority value for Voice traffic.
Item #3 is assured by assigning the same priority value for all Voice LSPs.
Item #4 is assured by assigning the same priority value for all Data LSPs.
A bandwidth constraint of 20 (%) is defined for each Class Type. The actual amount of reservable bandwidth assigned
for the Class Types depends on the allocation model that is being used.
The case study is repeated for both bandwidth allocation models (MAM and RDM) in the following pages.
Module 5 - Page 148
DiffServ-TE Example Voice and Data Traffic
Using the Maximum Allocation Model

(MAM), each Class Type is given a fixed
portion of the maximum reservable
bandwidth on the links.
Module 5 |
149
A bandwidth constraint of 20 (%) is defined for each Class Type.

Using MAM, each Class Type is given a fixed portion of the Maximum Reservable Bandwidth on each network link.
The Maximum Reservable Bandwidth is 1 Gbp for all the links in the case study, so that each Class Type is effectively
given 200 Mbps of dedicated reservable bandwidth on each link.
The pools assigned to the Class Types are illustrated in the figure above for links both in the upper and lower portion of
the network topology. This is the initial arrangement, with no LSPs established so far.
Module 5 - Page 149
DiffServ-TE Example Bandwidth Allocation Using MAM
LSP 1 is established on the shortest path,

taking up all the bandwidth allocated for
the data (CT0) pool.
Module 5 |
150
A Data LSP is configured with Class Type 0, preemption priority 1, and bandwidth 200 Mbps. It is established on the
shortest IGP path, and occupies the entire pool that is designated for CT0.
Module 5 - Page 150
DiffServ-TE Using MAM First Data LSP
Another data LSP is being established.

It is not allowed to use the bandwidth
allocated for CT1 on the shortest path,
thus it is signaled on the other path.
Module 5 |
151
Another Data LSP (LSP 2) is configured with the same CT and priority values and 100 Mbps of bandwidth.
There is no more room in the dedicated CT0 pool on the shortest IGP path, thus the LSP is established on the longer
path, occupying half of the CT0 pool there.
As is illustrated above, an LSP at a certain Class Type is not allowed to reserve bandwidth from the pool that is
dedicated to another Class Type, even if the reservable bandwidth is not in use by any other LSP at that time. This can
be seen as a less efficient way of reserving bandwidth with the Maximum Allocation Model, as opposed to its
straightforward nature.
Module 5 - Page 151
DiffServ-TE Using MAM Second Data LSP
A Voice LSP gets established on the

shortest path reserving bandwidth from
the CT1 pool.
The unreserved bandwidth in the Voice
pool cannot be used by Data LSPs.
Module 5 |
152
If a Voice LSP needs to be established on router R1 to router R6, it has the dedicated reservable bandwidth available in
the CT1 pool. In the example above, a voice LSP is established with 100 Mbps, taking up only half of the CT1 pool. The
other half of the CT1 pool can only be used by another Voice LSP in the same CT class.
Module 5 - Page 152
DiffServ-TE Using MAM Voice LSP
Using the Russian Dolls Model (RDM), the

Data LSPs in CT0 are allowed to use the
unoccupied portion of the bandwidth pool
allocated to Voice LSPs in CT1.
Module 5 |
153
The slide above illustrates the bandwidth reservation pools, if the Russian Dolls Model is used.
Using this model, Data LSPs in Class Type 0 are allowed to overflow to the CT1 pool if there is unused bandwidth in that
pool. However, a Voice LSP can preempt a Data LSP occupying its bandwidth pool, if necessary.
Module 5 - Page 153
DiffServ-TE Example Bandwidth Allocation Using RDM
The first data LSP gets established

reserving 200M that is allocated for CT0.
Module 5 |
154
A Data LSP is configured with 200 Mbps of bandwidth constraint. It is established on the shortest path, taking up all the
bandwidth in the CT0 pool.
Module 5 - Page 154
DiffServ-TE Using RDM First Data LSP
The second data LSP is allowed to use the

unoccupied bandwidth pool on the
shortest path defined for the Voice Class
CT1.
Module 5 |
155
Another Data LSP is configured with 100 Mbps of bandwidth constraint. Unlike the Maximum Allocation Model, it is also
established on the shortest IGP path, reserving available bandwidth from the CT1 pool.
Module 5 - Page 155
DiffServ-TE Using RDM Second Data LSP
The Voice LSP requires 200M on the shortest

path and claims back its bandwidth allocation.
One of the data LSPs is preempted.
The Voice class cannot reserve more than
200M.
Module 5 |
156
A Voice LSP is configured with 200 Mbps of bandwidth constraint.

In accordance with the initial requirement, that Voice LSPs are never driven away from their shortest path because of
Data LSPs, the Voice LSP preempts one of the Data LSPs to free up bandwidth for itself. This takes place thanks to the
relative priority values assigned to the LSPs, and LSP 2 is forced to move out of the shortest path. LSP 2 is established
on the longer path as a result of preemption.
In this model, what is possible for Data LSPs is not possible for Voice LSPs. That is, LSPs in the Voice Class are not
allowed to reserve more than 200 Mbps in total on the links. Therefore, in the real network design phase, it is important
to ensure that enough bandwidth is allocated for this Class Type, and that the remaining bandwidth is given to the
lower Class Type(s).
Module 5 - Page 156
DiffServ-TE Using RDM Voice LSP
Clear isolation between CTs

Easier to understand and manage
Less efficient bandwidth allocation
No preemption required between
LSPs from different CTs
Allows sharing between CTs

More complex
More efficient bandwidth allocation
Different preemption priorities
required between LSPs from
different CTs
Module 5 |
157
A comparison of both allocation models is provided above.

While the Maximum Allocation Model provides clear isolation between the Class Types in distributing the Maximum
Reservable Bandwidth, it is less efficient because it does not allow for any form of bandwidth sharing between Class
Types. The Russian Dolls Model provides a way to achieve bandwidth sharing, but it might be more difficult to
understand and implement.
Because bandwidth sharing is not allowed in the Maximum Allocation Model, preemption is not required between LSPs
belonging to different Class Types. This can be a criterion in model selection, if preemption is not desired in the
network for certain reasons. The Russian Dolls Model, on the other hand, requires the use of preemption and relative
priorities between Class Types because of its bandwidth sharing feature.
Module 5 - Page 157
Comparison MAM vs. RDM
Enabling DiffServ-TE
The MPLS context must be shutdown before DiffServ-TE can be

configured (migrations must be carefully planned):
configure router mpls shutdown
configure router rsvp diffserv-te [mam | rdm]
If not specified, the default is MAM (Maximum Allocation Model).

The following are configured at minimum in the DiffServ-TE context:
A:R1>configure router rsvp diffserv-te
[no] class-type-bw
[no] te-class
- Configure bandwidth percent for class type

- Configure TE Class
Module 5 |
158
Enabling DiffServ-TE in an already deployed RSVP-TE based MPLS network might require additional maintenance tasks,
because an administrative shutdown of the entire MPLS context is required. This can introduce service downtime,
depending on the method of migration used. Certain automatization techniques, such as custom developed scripting
tools, can be used to streamline the migration process and minimize downtime. Careful planning is required, regardless
of the preferred migration method.
DiffServ-TE is enabled in the RSVP context with the bandwidth allocation model of choice. MAM (Maximum Allocation
Model) is the default model. Changing the allocation model from one to another also requires a shutdown of the MPLS
context.
The two essential configuration items, class-type-bw and te-class, are explained in the following pages.
Module 5 - Page 158
DiffServ-TE is configured in the RSVP context together with the

allocation model of choice:
Configuring and Verifying Bandwidth Constraints
Bandwidth constraints are specified per Class Type in percentage

values (of the maximum reservable bandwidth):
class-type-bw ct0 20 ct1 20 ct2 0 ct3 0 ct4 0 ct5 0 ct6 0 ct7 0
For a Max. Reservable BW of 1 Gbps, these values translate to:

Maximum Allocation Model
A:R1#
show router rsvp interface "toR2" detail
. . . . . . . . . . . . .
Bandwidth Constraints for
BC0 : 200000
BC1 : 200000
BC2 : 0
BC3 : 0
. . . . . . . . .
Class Types (Kbps)
BC4: 0
BC5: 0
BC6: 0
BC7: 0
Russian Dolls Model

A:R1#
show router rsvp interface "toR2" detail
. . . . . . . . . . . . .
Bandwidth Constraints for
BC0 : 400000
BC1 : 200000
BC2 : 0
BC3 : 0
. . . . . . . . .
Class Types (Kbps)
BC4: 0
BC5: 0
BC6: 0
BC7: 0
(BC0 = CT0 + CT1)

Module 5 |
159
The Bandwidth Allocation (bandwidth pools) for each Class Type is defined with the class-type-bw command. The
percentage values of the Maximum Reservable Bandwidth can be specified in any order for all the 8 Class Types.
If a certain Class Type is not used, a value of 0 can be specified for it in the configuration. The sum of all the
configured bandwidth percentages cannot exceed 100.
The configuration of the bandwidth allocation percentages per Class Type is irrespective of the allocation model.
However, the actual bandwidth constraints are calculated depending on the allocation model specified when enabling
DiffServ-TE.
Using the Maximum Allocation Model, each Class Type is given a fixed, dedicated bandwidth pool. For this reason, the
bandwidth percentage values translate directly into the values seen in the figure on the left. Both CT0 and CT1 are
allocated 200 Mbps of reservable bandwidth, separately.
Using the Russian Dolls Model, bandwidth sharing is allowed between the Class Types. For this reason, the bandwidth
constraint for CT0 is calculated as the sum of the actual reservable bandwidth for both CT0 and CT1 classes; that is,
400 Mbps. (Recall that, in this model, a CT1 LSP should be able to preempt a CT0 LSP occupying bandwidth in the CT1
pool).
Module 5 - Page 159
A bandwidth value of 0 can be specified for non-used Class Types.

The sum of all values cannot exceed 100.
Bandwidth Constraints in the IGP TED
Bandwidth allocation information about each link is carried in a new

Sub-TLV called Bandwidth Constraints.
Recall that these numbers indicate the distribution of the maximum

reservable bandwidth per Class Type, as configured in the RSVP
DiffServ-TE context.
Although different routers can use different bandwidth allocation
models and constraints, best practice is to use the same settings for
easier configuration, maintenance, and troubleshooting.
Module 5 |
160
The Bandwidth Constraints calculated by the router for each Class Type and for each RSVP link are advertised in the
network within the IGP TE updates. For this purpose, a new Sub-TLV has been introduced with the intuitive name,
Bandwidth Constraints. The bandwidth allocation model used is also indicated in the Sub-TLV.
Module 5 - Page 160
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sub-TLV: 17
Len: 36
TELK_BW_CONST:
BW Model : MAM
BC0: 200000 Kbps BC1: 200000 Kbps BC2:
0 Kbps BC3:
0 Kbps
BC4:
0 Kbps BC5:
0 Kbps BC6:
0 Kbps BC7:
0 Kbps
Configuring the TE classes
Up to 8 combinations of Class Types and Priorities must be chosen.

Each combination is mapped to a TE class.
A:R1#configure router rsvp diffserv-te

te-class 0 class-type 1 priority 0
te-class 1 class-type 0 priority 1
Module 5 |
161
Recall that a TE class is one of the 64 possible combinations of the Class Types and priorities.
The configuration of the TE classes must be consistent throughout the network to avoid LSP setup problems.
Module 5 - Page 161
TE classes are configured individually on each router, and must be

consistent throughout the whole MPLS network.
Configuring LSPs Using Class-Type and Priorities
A:R1# configure router mpls

lsp Data-1"
to 10.10.10.6
cspf
primary fully_loose"
bandwidth 200
priority 1 1
class-type 0
exit
no shutdown
exit
If no class-type is specified, CT0 is assumed.

The configured Class-Type and priorities MUST correspond to one of
the TE-Classes configured earlier in the RSVP context.
Best practice is to configure Setup and Hold Priorities equal.
Module 5 |
162
After enabling DiffServ-TE in the network, extra care must be taken when configuring the priority and class-type values
for the LSPs. It is still the best practice to use the same setup and hold priority for the LSP, as mentioned in the Soft
Preemption topic in this section.
With these principles in mind, the configured priority and Class Type values must correspond to one of the TE classes
defined in the RSVP DiffServ-TE context, as explained in the previous page. LSP establishment failures can occur if
errors are present. An example is included in the next page.
If a Class Type is not configured, it is implicitly assumed that the LSP belongs to CT0.
Module 5 - Page 162
Class-Type information can be specified in the LSP configuration,

along with the preemption (setup and hold) priorities.
Class-Type Priority Mismatch
The following error is displayed in the CLI if the configured ClassType and priorities of an LSP do not map correctly to a TE-Class
configured in the RSVP context:
------------------------------------------------------------------------------LSP mismatch Path fully_loose
------------------------------------------------------------------------------Adm State
: Up
Oper State : Down
Path Name
: fully_loose
Path Type
: Primary
Path Admin : Up
Path Oper
: Down
OutInterface: n/a
Out Label
: n/a
SetupPriori*: 6
Hold Priori*: 6
Preference : n/a
Bandwidth
: 100 Mbps
Oper Bw
: 0 Mbps
Hop Limit
: 255
Class Type : 1
...................................
........................
Failure Code: invCtAndSetupAndHoldPri
(Invalid Class-Type and Setup and Hold Priority)

Module 5 |
163
The CLI output shown above illustrates a possible configuration error caused by specifying incompatible priority and
Class Type values for the LSP. Since the combination does not correspond to a configured TE-Class, the LSP path is set
to an operationally down status, with the failure code indicating the source of the problem.
Module 5 - Page 163
A:R1# show router mpls lsp mismatch" path detail
Viewing the Bandwidth Reservations per TE-Class
The following output displays the reserved and unreserved bandwidth

values per TE-Class on a given link:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bandwidth for TE Class Types (Kbps)
TE0-> Resv. Bw
: 0
Unresv. Bw
: 200000
TE1-> Resv. Bw
: 200000
Unresv. Bw
: 0
TE2-> Resv. Bw
: 0
Unresv. Bw
: 0
TE3-> Resv. Bw
: 0
Unresv. Bw
: 0
TE4-> Resv. Bw
: 0
Unresv. Bw
: 0
TE5-> Resv. Bw
: 0
Unresv. Bw
: 0
TE6-> Resv. Bw
: 0
Unresv. Bw
: 0
TE7-> Resv. Bw
: 0
Unresv. Bw
: 0
Bandwidth values are updated each time a reservation is made by

an LSP in a certain TE class.
Updated values are advertised to other routers via IGP TE.
Module 5 |
164
The reserved and unreserved bandwidth values for each TE class can be observed in the show router rsvp
interface <interface_name> detail command output. If the figures change as a result of reservation or clear
actions, the updated values are propagated to the network within IGP TE update messages.
Module 5 - Page 164
A:R1# show router rsvp interface "toR2" detail
Bandwidth Reservations per TE-Class in the TED
There is no separate TLV defined in the IGP-TE to carry bandwidth

values per TE-class.
After DiffServ-TE is enabled, the existing Unreserved Bandwidth
values per priority indicate the per TE-class values in the TED.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sub-TLV: 8
Len: 32
UNRSRVD_CLS0 :
P0: 200000 Kbps P1:
0 Kbps P2:
0 Kbps P3:
0 Kbps
P4:
0 Kbps P5:
0 Kbps P6:
0 Kbps P7:
0 Kbps
P0 should now be interpreted as TE0, P1 as TE1 and so on.

(compare with the output on the previous page)
Module 5 |
165
The unreserved bandwidth values for each TE class are propagated in IGP TE updates. However, no additional TLV is
defined to convey this information. On the contrary, the existing Sub-TLV 8 (Unreserved Bandwidth) per priority level is
still used after DiffServ-TE is enabled. This requires an implicit change in nomenclature while interpreting these values:
P0 stands for TE0, P1 stands for TE1, and so on.
Module 5 - Page 165
Module 5 |
166
LAB 5 Section 5.2 and 5.3 DiffServ TE LSP MAM and RDM
Module 5 - Page 166
Section Summary

RSVP-TE Bandwidth Reservation principles
Bandwidth Reservation Styles:

y Shared Explicit
y Fixed Filter
Make-Before-Break (MBB) behavior
Least-Fill Feature
DiffServ-TE applications
Module 5 |
167
A bandwidth constraint can be specified for LSP paths in the Head-End LSP configuration.
If CSPF is enabled for the LSP, it looks for an available path in the network that satisifies the bandwidth constraint.
A CAC (Connection Admission Control) check is performed on all the routers along the LSP path to verify the
requested amount of bandwidth before delivering the RSVP PATH message.
The te-threshold-update option can be enabled in the RSVP context to optimize the amount of IGP TE updates
that are flooded in the network.
Custom up and down thresholds can be defined when using the te-threshold-update feature.
Additionally, configuration options exist to trigger IGP TE updates in case of CAC failures and periodically using a
specified update timer.
The bandwidth reservation styles determine how bandwidth is reserved for multiple LSP paths that belong to the
same LSP and traverse through a shared link.
The Shared Explicit reservation style requires that routers reserve the maximum bandwidth constraint defined for
any of the LSP paths that belong to the same LSP on the shared link.
The Fixed Filter reservation style requires that routers reserve the sum of the individual bandwidth constraints
defined for all the LSP paths on the shared link.
Make-Before-Break is targeted to reduce the service downtime when a new LSP path needs to be configured for an
existing LSP path.
The least-fill feature allows CSPF to choose the path with the least amount of reserved bandwidth when there are
multiple equal cost paths. This is an optimization attempt towards achieving more balanced bandwidth distribution
over the alternative links.
Module 5 - Page 167
IGP TE Bandwidth Update Trigger using:

y Up and Down Thresholds
y On-CAC-Failure
y Periodic Update Timer
Section Summary

LSP Soft Preemption using:
y Setup and Hold Priorities
y Bandwidth Reservation per Priority Level
y Class-Type (CT) definitions
y Bandwidth allocation per class type based on two models:
Russian Dolls Model (RDM)
Module 5 |
168
LSP Setup and Hold Priorities can be used to enable preemption between different LSP paths.
The priority values range from 0 to 7.
0 is the best priority, given to the most important LSPs.
7 is the least priority, given to the least important LSPs.
Best practice is to set the setup and hold priorities for simpler maintenance and comprehension.
An LSP with a better priority level can preempt LSPs with worse priority levels if they are contending for the same
RSVP-TE bandwidth resources on the same links.
The DiffServ-TE feature enables bandwidth reservations, based on LSP Class Types, with preemption priorities.
The combination of a Class Type and a preemption priority is called a TE Class.
Up to 8 TE Classes can be defined, which must be consistent throughout the RSVP-TE based network.
There are two bandwidth allocation models to determine the bandwidth allocation pools per Class Type.
The Maximum Allocation Model provides separation between Class Types, with fixed bandwidth allocation values for
each Class Type. Preemption is not required between LSPs from different Class Types.
The Russian Dolls Model allows for bandwidth sharing between different Class Types. As a result, preemption is
required between LSPs from different Class Types.
Module 5 - Page 168
Diffserv Aware Traffic Engineering (Diffserv-TE) using:
Section 4 Traffic Engineering in a Hierarchical Network
Module 5 - Page 169
Section Objectives
Module 5 |
170
The LDP-over-RSVP solution used to provide Traffic Engineering in Hierarchical IGP networks is discussed in this section.
The theoretical and configurational principles of LDP-over-RSVP are explained.
Module 5 - Page 170
The LDP-over-RSVP solution
Scalability concerns might arise in very large flat IGP deployments.

N*(N-1) LSPs might be required for an RSVP-TE full-mesh
(N: number of MPLS routers).
Transit LSRs, especially, might be over-burdened.
Module 5 |
171
Using a flat (single area) IGP network is simple and straightforward from a design and operational perspective.
However, certain scalability issues might arise as the number of routers in the area grow (usually to the scale of
thousands of routers). The number of routes to be propagated and processed by the routers might become resource
intensive for the routers and can have an effect on their performance.
Deploying RSVP Traffic Engineering in a single area is also fairly easy to implement. On the other hand, having a full
mesh of RSVP-TE LSP requirements can be resource intensive, especially for the transit LSRs. Routers need to maintain
session states for thousands of LSPs in this case.
Module 5 - Page 171
Scalability Concerns in Flat (Single Area) IGP Networks
The IGP domain might be split into multiple areas, introducing

hierarchy.
Advantage: Scalability is increased.
Disadvantage: Traffic Engineering cannot work across areas.
Module 5 |
172
The solution to the scalability problems presented on the previous page is introducing hierarchy into the IGP design.
In relation to this, network designers might want to deviate from a single area and split the IGP domain into multiple
areas. In a hierarchical IGP network, the routing information is self-contained within each area. As a result, the routers
that are internal to the area need to keep track of the topology changes only within their own area. The communication
between different areas is handled by the Area Border Routers that reside on the boundary between two areas.
Only the OSPF hierarchy is presented in this example for simplicity. IS-IS has a slightly different and simpler approach
towards area hierarchy, which is composed of only 2 levels. The main principles of the LDP-over-RSVP solution also
apply to the IS-IS protocol. For a full discussion of the design and operational principles of multiple area IGP networks,
please refer to the SRC Interior Routing Protocols course.
Scalability issues are addressed by introducing hierarchy into the IGP network. On the downside, Traffic Engineering
cannot be performed end-to-end across multiple areas. Recall that the Type 10 Opaque LSAs used to convey Traffic
Engineering have a local area scope; they are not propagated to routers outside the area that they were originated in.
Module 5 - Page 172
IGP Hierarchy Multiple Areas
Type 10 Opaque LSAs are blocked at the Area Border Routers.

Routers have TE information only for their own area.
CSPF based LSPs (using TE features) to other areas do not work.
Module 5 |
173
The above slide illustrates the limitation mentioned on the previous page.
In a multiple area IGP network, Traffic Engineering information within each area cannot cross the area boundaries
delimited by the Area Border Routers. Thus, the Traffic Engineering Database on PE1 does not contain any entries about
the links that reside in other IGP areas.
If an LSP is created on PE1 towards PE2 and CSPF is enabled, CSPF will issue a No CSPF Route Destination error
because it will not have the information on how to reach PE2, which resides in another area. The implication of this is
that Traffic Engineering features are related to the use of CSPF and administrative constraints (administrative groups,
TE metric, SRLG, bandwidth reservations, Fast Reroute, and so on).
Note that an IGP-directed LSP, as presented in Module 4, or an LDP-based tunnel, as explained in Module 3, can still be
used to achieve end-to-end transport tunnel connectivity, but with the lack of TE related features.
LDP-over-RSVP tunneling is the solution to this limitation, and is presented in the following pages.
Module 5 - Page 173
`Traffic Engineering Limitation Across Areas
CSPF based LSPs using TE features can be configured within each

individual area.
A method is required to stitch these LSPs together to have end-toend tunnel connectivity between the PE routers.
Module 5 |
174
The above slide illustrates that, in a hierarchical network, Traffic Engineering features can be used separately within
each area. CSPF based LSPs can be created, extending to the boundaries of an area.
In the figure above, a CSPF based LSP originates on PE1 and terminates on ABR1.
Another CSPF based LSP originates on ABR1 and terminates on ABR2.
A third LSP is configured on ABR2 that terminates on PE2.
Without an additional mechanism, these three LSPs are unaware or unrelated to each other. For a contiguous
forwarding path from PE1 to PE2, a special method is required stitch or interconnect these separate CSPF based LSPs.
This is presented on the next page.
Module 5 - Page 174
`Traffic Engineering Based LSPs in Each Area
RSVP-TE LSP stitching is performed by the Area Border Routers.

T-LDP sessions are configured to perform the stitching of RSVP-TE
based LSPs to obtain an end-to-end tunnel connectivity.
Module 5 |
175
The interconnection of the separate CSPF based LSPs in the figure above is accomplished by T-LDP.
T-LDP sessions are configured between each PE-ABR and ABR-ABR pair to associate the individual LSPs with each other.
Recall that Targeted LDP sessions can run between non-directly connected peers, which is perfectly suited for this
application.
Module 5 - Page 175
`The T-LDP Stitching Solution
Without LDP-over-RSVP, VPN services can be offered via LDP transport

tunnels across multiple areas; lacks TE enhanced features.
Module 5 |
176
The above slide illustrates end-to-end service connectivity provided by LDP based transport tunnels. LDP relies solely on
the routing information provided by standard IGP, and is devoid of any sophisticated Traffic Engineering features.
Module 5 - Page 176
`VPN Service Offering with No TE Capabilities
LDP-over-RSVP brings enhanced TE resiliency (fast-reroute, secondary

LSPs, and so on) on a per IGP area basis.
Module 5 |
177
In a hierarchical network, the Service Provider can add a new dimension to inter-area service offerings by introducing
the LDP-over-RSVP solution. From a forwarding perspective, the LDP transport tunnel can be encapsulated within an
RSVP-TE based LSP configured in each area. The individual RSVP-TE based LSPs can fully enjoy the benefits of Traffic
Engineering within their respective areas. This enhancement can bring quality improvements in the service offerings
provided to customers.
Module 5 - Page 177
`VPN Service Offering with Added TE Capabilities
The LDP-over-RSVP solution is implemented using a 3-Label MPLS

Stack.
y The outermost labels are signaled on each single RSVP-TE LSP path.
y The LDP Transport labels are signaled over T-LDP sessions.
y The VPN Service Label signaling methods are as defined in Module 2.
Module 5 |
178
From a labeling perspective, the LDP-over-RSVP solution is implemented using a three label MPLS stack.
This generic approach is common to both Layer and Layer 3 VPN services, such as VLL, VPLS, and VPRN.
The signaling of the labels in the LDP-over-RSVP stack is as follows:
Within each area, RSVP-TE based LSPs are created, involving the PE routers, ABRs, and the transit routers inside the
area. The labels signaled for these LSPs are used as the outermost labels in the stack and encapsulate the LDP
traffic.
Within each area, T-LDP sessions are created between the routers at the area boundaries (PE-ABR and ABR-ABR
pairs). LDP transport labels are exchanged over these sessions. Note that this is different from the traditional
implementation, in which Link LDP is used to signal the transport labels. These labels are located in the middle of
the stack and encapsulate the VPN Service Labels.
The bottom label in the stack is the VPN Service Label. VPN Service Labels are exchanged by the PE routers that
have the VPN services configured on them. Separate service labels are signaled for each customer VPN service.
These labels encapsulate the customer traffic, namely the VPN Service Payload. As mentioned in Module 2, VPN
Service Labels are signaled by T-LDP for Layer 2 services, and by MP-BGP for Layer 3 services.
Module 5 - Page 178
LDP-over-RSVP Label Stack
The end-to-end data plane forwarding is shown for a VPN service

utilizing the LDP-over-RSVP solution; in one direction only.
Module 5 |
179
The above slide illustrates a representation of end-to-end data forwarding for a VPN service, using the LDP-over-RSVP
solution. The illustration shows the forwarding of traffic from PE1 to PE2 only, for the sake of clarity. A similar process
also occurs in the opposite direction for bi-directional traffic.
The VPN service label is signaled between the two PE routers, using the methods described in the previous page, and is
not modified by any of the routers along the forwarding path. PE1 pushes the VPN label onto the service payload, which
is indicated as Data, and is encapsulated by two other labels. PE2 uses this label to locate the VPN service that the
packet belongs to.
The LDP labels are negotiated by the T-LDP sessions running between each router pair.
PE1 and ABR1 negotiate a label called LDP1 with each other. PE1 pushes this label onto the stack, which is
encapsulated by the RSVP label RSVP11.
The LDP label is not touched by LSR1, since it is a transit LSR and can only process the top RSVP label in the stack.
The RSVP tunnel terminates on ABR1, so the label RSVP12 is popped. This exposes the LDP label LDP1, which is
swapped with label LDP2 by ABR1, which is responsible for stitching.
The process goes on until PE2, creating end-to-end service tunnel connectivity using the LDP-over-RSVP methodology.
Module 5 - Page 179
`LDP-over-RSVP Unidirectional Packet Walkthrough
Prerequisites for Configuring LDP-over-RSVP
On all the routers (including the transit LSRs):

Network IP Interfaces must be configured (including the System IP
address).
If TE features are required in each individual area, trafficengineering must be enabled in the IGP.
Network interfaces must be configured in the MPLS context.
The MPLS context must be administratively enabled.
The RSVP context must be administratively enabled.
Module 5 |
180
The general prerequisites mentioned earlier for configuring RSVP-TE based LSPs also apply in this context, as shown
above. The main difference is that the IGP domain is split into multiple areas, and area configuration should be
carefully performed on the routers.
Module 5 - Page 180
Network IP interfaces must be configured in the IGP context with

correct area information.
RSVP-TE based LSPs are configured in each area between each of the
following pairs using any methods presented earlier in the module
(loose/strict hop, CSPF enabled/disabled, with/without constraints)
y PEABR
y ABRABR
Module 5 |
181
One of the building blocks to implementing the LDP-over-RSVP solution is configuring RSVP-TE based LSPs in each area.
For uni-directional traffic, LSPs are created in both directions. Any of the desired Traffic Engineering features regarding
the use of administrative constraints and CSPF can be deployed in the LSP configurations.
Note that the configuration steps presented in this section are approached systematically, for clarity purposes. The
actual configurations do not necessarily have to follow this order.
Module 5 - Page 181
`Configuring RSVP-TE LSPs in Each Area
Configuring T-LDP with Tunneling Option
In the LDP-over-RSVP solution, Targeted LDP sessions must be

configured between each of the following pairs:
y PEABR
y ABRABR
The reason T-LDP is used: Targeted peers do not need to be directly

connected.
tunneling keyword must be specified in the LDP peer configuration
to enable LDP-over-RSVP tunneling.
A:Rx#configure router ldp
targeted-session
peer <Peer System IP Address>
tunneling
exit
exit
Module 5 |
182
Another important aspect in the LDP-over-RSVP implementation is the configuration of T-LDP sessions. T-LDP sessions
are required to stitch the individual RSVP-TE LSPs on the Area Border Routers. Manual peer relationships must be
defined on each of the PE and ABR routers participating in the solution.
Recall that, with T-LDP, sessions can run between non-directly connected neighbors. This is usually the case between
PE-ABR and ABR-ABR router pairs, which is why T-LDP is used.
T-LDP exchanges labels for the System IP addresses between each T-LDP peer. In order to activate the tunneling of LDP
labels over RSVP, the tunneling keyword must be specified in the LDP peer configuration.
Note that, if Link LDP is also running in the network (configured under the interface-parameters sub-context of LDP),
the transport tunnels created by Link LDP take precedence over the LDP-over-RSVP tunnels. To overcome this default
behavior and use LDP-over-RSVP tunnels instead of Link LDP, the following configuration option can be activated:
A:R5# configure router ldp prefer-tunnel-in-tunnel
Module 5 - Page 182
Routers exchange labels for their System IP addresses over the T-LDP
sessions.
PE1
targeted-session
peer 10.10.10.2
tunneling
exit
exit
ABR1
targeted-session
peer 10.10.10.1
tunneling
exit
exit
peer 10.10.10.4
tunneling
exit
exit
exit
PE2
ABR 2
targeted-session
peer 10.10.10.2
tunneling
exit
exit
peer 10.10.10.6
tunneling
exit
exit
exit
Module 5 |
183
targeted-session
peer 10.10.10.4
tunneling
exit
exit
An overall view of configuring T-LDP sessions in the example LDP-over-RSVP deployment is seen in the figure above.
Module 5 - Page 183
`Network Example Configuring T-LDP with Tunneling Option
Enabling LDP-over-RSVP in the IGP
The following must be enabled on all the PE routers and ABRs to

allow for LDP-over-RSVP processing:
configure router [ospf | isis] ldp-over-rsvp
Module 5 |
184
With the LDP-over-RSVP solution, the LDP prefixes are resolved by RSVP-TE LSPs reaching out to those prefixes (System
IP addresses of the PEs or ABRs). To facilitate this, the configuration item displayed above must be enabled inside the
IGP context on all the PE routers and ABRs.
Module 5 - Page 184
After this point, RSVP-TE based LSPs are considered in the SPF
calculations to resolve the LDP advertised prefixes.
Verifying LDP-over-RSVP
When LDP-over-RSVP is active, the LDP prefixes are resolved to an

RSVP LSP; instead of a physical interface:
*A:R1# show router ldp bindings active
The LspId indicated in the above output is actually the Tunnel

ID of the resolving RSVP-TE based LSP:
*A:R1# show router rsvp session
==========================================================================
From
To
Tunnel LSP
Name
State
ID
ID
-------------------------------------------------------------------------10.10.10.1
10.10.10.2
147
18944
LSP1::fully_loose
Up
Module 5 |
185
As explained in Module 3, the show router ldp bindings active command output displays the LFIB (Label
Forwarding Information Base) of the router that is used in data plane forwarding.
The output shown above is taken on router R1, which resides in OSPF area 1. There is an entry in the output for prefix
10.10.10.6/32, which belongs to router R6 and resides in area 2. Without LDP-over-RSVP, the EgrIntf/LspID field would
indicate a physical interface resolved by IGP, such as 1/1/4. With LDP-over-RSVP activated, this field indicates the
Tunnel ID of the LSP that resolves the LDP prefix 10.10.10.6/32.
The resolving LSP with the indicated Tunnel ID can be verified with the show router rsvp session command, as
seen above.
Module 5 - Page 185
==========================================================================
Prefix
Op
IngLbl
EgrLbl
-------------------------------------------------------------------------. . . . . . .
10.10.10.6/32
Push
-131068
LspId 147
10.10.10.2
--------------------------------------------------------------------------
RSVP-TE resiliency features can be used to protect the LSPs in each

IGP area (covered in Module 6).
Module 5 |
186
To benefit from the LDP-over-RSVP solution, resiliency options, such as secondary LSP path or Fast Reroute Protection
features, can be used for each RSVP-TE based LSP. This might increase the quality of the service offerings provided to
business VPN customers by virtue of improved convergence times.
Aspects related to convergence and resiliency are covered in Module 6.
Module 5 - Page 186
LDP-over-RSVP Resiliency LSP path Protection
Multiple Area Border Routers can be used to increase resiliency.

PE routers have LSPs and T-LDP sessions to both ABRs.
PE routers choose the closest ABR in their area.
Full-Mesh of LSPs and T-LDP sessions required between the ABRs.
Module 5 |
187
Having a single Area Border Router for each area can present a single point of failure, which is not desirable.
An area can become isolated from the rest of the network, if the single ABR that it relies on experiences router failure.
For this reason, it might be a good idea to use multiple ABRs to mitigate the risks of prolonged service downtimes in the
event of ABR failure. An example is shown in the figure above.
To ensure proper functioning of LDP-over-RSVP solution in this scheme, PE routers should be made T-LDP peers with all
the ABRs in their area. Accordingly, PE routers should have RSVP-TE LSPs configured with all their ABRs. From a
forwarding perspective, the decision mechanism on each ABR choose the closest ABR to deliver the traffic.
In order to have inter-connectivity between all areas, the ABRs should have a full-mesh of RSVP-TE LSPs and T-LDP
peerings through the backbone network.
Module 5 - Page 187
LDP-over-RSVP Resiliency Multiple ABRs
Module 5 |
188
LAB 5 Section 5.4 Configuring LDP over RSVP across OSPF Areas
Module 5 - Page 188
Section Summary

The scalability concerns in flat IGP networks.
The LDP-over-RSVP solution using:

y RSVP-TE based LSPs in each IGP area
y Stitching of the LSPs at the Area Border Routers using T-LDP
The LDP-over-RSVP MPLS label stack implementation
Configuring and verifying LDP-over-RSVP.
Resiliency Options in LDP-over-RSVP deployments
Module 5 |
189
Scalability issues might arise in very large IGP deployments using a flat area design.
If hierarchy is introduced, end-to-end Traffic Engineering does not work across multiple areas.
The LDP-over-RSVP solution enables a segmented form of Traffic Engineering that is self-contained within each
area.
End-to-end service level connectivity for RSVP-TE LSPs is achieved with stitching performed by the ABRs using TLDP sessions.
A three-label stack is implemented for VPN Services using LDP-over-RSVP tunneling.
The outermost label is the RSVP label.
The middle label is the LDP label (signaled by T-LDP).
The bottom label is the VPN service label (signaled by T-LDP for Layer 2 services and by MP-BGP for Layer 3
services).
T-LDP peers must be configured between each PE-ABR and ABR-ABR pairs with the tunneling option.
The ldp-over-rsvp option must be enabled in the IGP context on all PE and ABR routers to be able to resolve the
LDP prefixes via RSVP LSPs.
Resiliency features, such as secondary LSP paths or Fast Reroute protection, can be used for RSVP-TE LSPs within
each area.
Multiple ABRs can be used to avoid a single point of failure and further improve the overall network resiliency.
Module 5 - Page 189
The Traffic Engineering limitations in Hierarchical IGP

deployments.
Section 5 MPLS for IP Routing (MPLS shortcuts)
Module 5 - Page 190
Section Objectives

LDP-Shortcut for BGP next-hops
RSVP-TE Shortcut for BGP next-hops
LDP-Shortcut for IP forwarding
6PE IPv6 tunnels over MPLS
Module 5 |
191
The MPLS-shortcut features used to resolve BGP next-hops and native IP prefixes with either LDP or RSVP-TE tunnels is
explained in this section.
Module 5 - Page 191
RSVP-TE Shortcut for IP forwarding
Router R6 is an ASBR (Autonomous

System Boundary Router)
Router R6 has learned several prefixes
from AS 200 over external BGP.

=================================
Prefix
Protocol
NextHop
--------------------------------192.168.1.0/24
BGP
10.6.7.7 (toR7)
192.168.10.0/24
10.6.7.7 (toR7)
Module 5 |
192
BGP
The BGP (Border Gateway Protocol) is the dominating protocol used to interconnect Autonomous System entities
throughout the world. BGP has two types: external BGP (eBGP) and internal BGP (iBGP).
External BGP is used to exchange routing information between different Autonomous Systems (AS). The standard
definition of an Autonomous System is: A group of routers and other networking equipments under a common
administration. It can be perceived as a service provider network, or any other organization that runs its own custom
policies to communicate with the rest of the world. AS numbers are organized and distributed by the IANA (Internet
Assigned Numbers Authority).
In the example above, a service provider network with an AS number of 100 receives external routing information from
another AS 200 via external BGP. Router R6 acts as an Autonomous System Boundary Router (ASBR) that is responsible
for the interaction with the outside world. Router R6 receives several prefixes from router R7, the ASBR in AS 200. The
prefixes are depicted as 192.168.1.0/24 to 192.168.10.0/24 in this simplified example, but keep in mind that there can
be many more.
The next-hop for these prefixes in the FIB of router R6 is 10.6.7.7, which is the directly connected interface address of
router R7.
Module 5 - Page 192
Acquiring External Routing Information
A:R1# show router bgp routes

=================================
Network
Next-Hop
--------------------------------192.168.1.0/24
10.10.10.6
192.168.2.0/24
10.10.10.6
192.168.10.0/24
10.10.10.6
Router R6 advertises the external prefixes

via internal BGP to router R1.
Router R1 first stores the prefixes in its
BGP Database.
The next-hop address is 10.10.10.6/32.
It needs to be resolved to a directly
connected IP address in the FIB.
Module 5 |
193
Router R6 has several options to propagate the external prefixes into its own Autonomous System. One option is to
perform route redistribution from BGP to IGP (OSPF or IS-IS), but this is not a preferred method. An important reason is
that the IGP databases might be overwhelmed by the amount of prefixes advertised by BGP. Interior Gateway Protocols
are not designed to handle extensive routing information. Another reason is that the valuable information carried in
extensive BGP protocol fields, the attributes, are lost during redistribution.
Therefore, the preferred method is to use the second type of BGP, which is internal BGP (iBGP). While external BGP
sessions typically run between directly connected peers, internal BGP sessions are typically formed between nondirectly connected peers, as shown in the figure above. eBGP sessions run between routers in different autonomous
systems, while iBGP sessions are formed between routers within the same autonomous system.
Router R6 advertises the prefixes that it learned from router R7 to router R1, over the established iBGP session. A
common convention here is to use a BGP configuration option next-hop-self on router R6, which changes the next-hop
information on the BGP prefixes from 10.6.7.7 to 10.10.10.6. This simplifies the resolution process within the
autonomous system, since the routers (should) already know how to reach to 10.10.10.6 (the system IP address of
router R6). Another option is to redistribute the 10.6.7.7 prefix into IGP on router R6, which requires additional policy
configuration.
In the example above, all traffic destined to the external prefixes will be directed to 10.10.10.6, according to the FIB
output on router R1. Router R1 performs a double lookup process to accomplish the forwarding. The 10.10.10.6 address
needs to be resolved to a directly connected IP address with a second lookup.
Module 5 - Page 193
Propagating Information Through Internal BGP

=================================
Prefix
Protocol
NextHop
--------------------------------192.168.1.0/24
BGP
10.1.2.2 Indirect (toR2)
The BGP next-hop address 10.10.10.6

resolves to the directly connected
interface address of router R2.
The BGP traffic is forwarded via the IP
next-hop according to the FIB
192.168.10.0/24
BGP
10.1.2.2 Indirect (toR2)
Module 5 |
194
The second lookup process mentioned in the previous page is illustrated in the figure above. The BGP next-hop address
10.10.10.6 is resolved to the directly connected IP address to router R2 (10.1.2.2), because it is the selected IGP nexthop.
The entries are marked Indirect, to refer to this double lookup process.
Module 5 - Page 194
BGP Default Next-Hop Resolution
Using IP routing, all routers along the forwarding path should have
all the BGP prefixes and valid next-hop information in their FIB.
Because of certain BGP design rules, a full-mesh of iBGP sessions are
required within the core (covered in the SRC BGP course).
This can bring an additional burden on the core routers having to
deal with a large number of BGP routes.
Module 5 |
195
Using native IP routing, all the routers along the forwarding path must have proper routing information regarding the
external BGP prefixes.
Consider the traffic destined to the 192.168.1.0/24 network in the example above. Router R1 sends the traffic with a
destination IP address of 192.168.1.50. If router R2 does not have an entry for this address in its FIB, it will discard the
traffic because it will not know where to send the packets.
Therefore, to attain proper forwarding, all the routers in the network should acquire the external routing information
via iBGP, and store this information in their BGP and FIB tables. This might bring an excessive load on the core routers,
in cases where they must deal with a large number of BGP routes. (At the time of this writing, the full BGP Internet
Routing Tables consist of more than 300,000 entries).
Note that the full aspects of the BGP implementation are covered in the BGP course of the SRC program; only the basic
principles are mentioned here.
Module 5 - Page 195
iBGP Full Mesh Requirement in the Core
If an MPLS tunnel to router R6 exists, the traffic towards external

networks can be label switched, instead of routed.
The core routers (for example, routers R2 and R4) do not need to
run BGP nor store a large number of external prefixes in their FIB.
Module 5 |
196
To get rid of the iBGP full mesh requirement in the core network, and save the core routers (R2 and R4 in this example)
from having to process a large number of BGP routes, MPLS shortcut-tunnels can be used.
Using this feature, traffic destined to external destinations are encapsulated into an MPLS tunnel that extends to the
ASBR. Thanks to the inherent MPLS forwarding mechanism, the core routers (R2 and R4) only perform label switching,
and are oblivious to the encapsulated BGP traffic inside the tunnel.
Module 5 - Page 196
BGP Next Hop Resolution via MPLS
Enabling MPLS Tunneling for BGP Traffic
MPLS tunneling for BGP is enabled with the following command:

A:R1# configure router bgp igp-shortcut {ldp|rsvp-te|mpls} [disallow-igp]
If the mpls keyword is specified, the router:

y First checks if an RSVP-TE LSP exists to the BGP next-hop address.
y If NO RSVP-TE LSP is available, it checks if an LDP label exists to the
prefix of BGP next-hop IP address (for example, 10.10.10.6/32)
y If none of the above are available, normal IGP forwarding is used; unless
disallow-igp option is enabled (BGP prefixes become unreachable if no
MPLS tunnel is available).
Module 5 |
197
The MPLS tunneling feature is enabled with the igp-shortcut feature in the BGP context. There are several options
that influence the decision-making process on the router that performs the forwarding of packets:
ldp: The LDP based tunnel is used to encapsulate the BGP traffic. If an LDP tunnel is not available towards the BGP
next-hop, native IP forwarding is used.
rsvp-te: An RSVP-TE based LSP is used to encapsulate the BGP traffic. If there is no available RSVP-TE LSP towards
the BGP next-hop, native IP forwarding is used.
mpls: RSVP-TE LSPs are preferred over LDP based tunnels to encapsulate the BGP traffic. If neither is available,
native IP forwarding is used.
disallow-igp: For all the options above, disable the fallback option to native IP forwarding, in case an MPLS tunnel
is not available.
Module 5 - Page 197
If only one of the shortcut options (LDP or RSVP-TE) is set, the router
can only use the specified type of tunnel.

======================================================================
Destination
Nexthop
Metric
----------------------------------------------------------------------10.10.10.6/32
rsvp MPLS 148
7
10.1.2.2
300
10.10.10.6/32
rsvp MPLS 23
7
10.1.2.2
500
10.10.10.6/32
ldp
MPLS
9
10.1.2.2
300
Tunnel Preference values are fixed. RSVP-TE always has priority over LDP.
If multiple RSVP-TE LSPs exist to the same destination, the one with the
lowest metric is chosen.
If the metrics are equal, the LSP with the lowest Tunnel ID is chosen.
Module 5 |
198
Internally, RSVP-TE based tunnels are preferred over LDP because they are assigned a lower preference value. The
preference value for RSVP-TE based tunnels are 7 and LDP based tunnels are 9, as shown in the show router
tunnel-table output above. These values are fixed, and not configurable.
The metric values displayed in the table are calculated as follows:
For CSPF disabled LSP paths with one or more strict hops, the metric is set to 65535.
For CSPF disabled LSP paths with NO strict hops (IGP directed), the metric is equal to the total IGP cost of the
path.
For CSPF enabled LSP paths, the metric is equal to the total IGP cost of the CSPF calculated path.
For LDP based tunnels, the metric is equal to the total cost of the IGP path.
The metric value for an RSVP-TE based LSP can be set to a custom value as follows:
A:R1>config>router>mpls>lsp# metric [0..65535]
Module 5 - Page 198
Tunnel Table Entries

=================================
Prefix
Protocol
NextHop
--------------------------------192.168.1.0/24
BGP
10.10.10.6 (Transport:RSVP LSP:148)
The BGP-sourced traffic is now label

switched through the core via the RSVP-TE
based LSP.
RSVP-TE resiliency features (Fast Reroute)
can bring more added value.
192.168.10.0/24
BGP
Module 5 |
199
The FIB output above displays the resolution of BGP next-hop addresses via an RSVP-TE LSP. The tunnel ID of the
resolving LSP is indicated in the output (148).
Module 5 - Page 199
RSVP-TE LSP Tunneling for BGP Traffic

=================================
Prefix
Protocol
NextHop
--------------------------------192.168.1.0/24
BGP
10.10.10.6 (Transport:LDP)
.
.
.
.
LDP Tunneling for BGP Traffic
The BGP-sourced traffic is now label

switched through the core using the LDP
signaled transport labels for prefix
10.10.10.6/32.
192.168.10.0/24
BGP
Module 5 |
200
The FIB output above displays the resolution of BGP next-hop addresses via an LDP Transport Tunnel.
Module 5 - Page 200
MPLS shortcuts can also be used for prefixes learned via IGP.
Both LDP and RSVP-TE based tunnels can be used.
Used to tunnel routed traffic outside of the VPN services context.
Module 5 |
201
Traditionally, MPLS tunneling has been used to carry VPN service traffic or, optionally, to resolve BGP next-hops, as
previously presented. The prefixes learned via IGP are forwarded as native IP packets by default.
The routers allow the use of MPLS tunnels to resolve the prefixes learned via IGP. If the feature is enabled, the traffic
destined to these prefixes can then be encapsulated within the LDP or RSVP-TE tunnels. When the router has a transport
tunnel to the destination, it gives the tunnel priority over the IGP route, and places the tunnel endpoint in the FIB as
the next-hop, indicating the type of tunnel it chose.
Module 5 - Page 201
MPLS Shortcuts for IGP Route Resolution

=================================
Prefix
Protocol
NextHop
--------------------------------192.168.1.0/24
OSPF
192.168.10.0/24
OSPF
A:R1# configure router [ospf | isis] rsvp-shortcut
In case of multiple RSVP-TE LSPs, the one

with the lowest metric is chosen.
If the metrics are equal, the LSP with the
lowest Tunnel-ID is chosen.
Module 5 |
202
If RSVP-TE LSPs need to be used as shortcut tunnels to encapsulate IP traffic, the configuration shown in the figure
above is required in the IGP context. Similar to shortcut feature for BGP next-hops, the LSP with the lowest metric is
chosen if multiple LSPs are available to the destination. If the metrics are equal, the Service Router chooses the LSP
with the lowest tunnel ID.
Module 5 - Page 202
RSVP-TE Shortcuts for IGP Route Resolution

=================================
Prefix
Protocol
NextHop
--------------------------------192.168.1.0/24
OSPF
192.168.10.0/24
OSPF
A:R1# configure router ecmp 2
If ECMP is enabled, multiple LSPs with the

same metric can be installed in the FIB.
The router will perform load-balancing
over multiple LSPs.
Module 5 |
203
If the Equal Cost Multiple Path (ECMP) feature is enabled, multiple LSPs with equal metric values can be installed in the
FIB. The router then forwards the incoming traffic over the multiple LSPs in a load-balancing fashion.
Module 5 - Page 203
RSVP-TE Shortcuts for IGP Route Resolution

=================================
Prefix
Protocol
NextHop
--------------------------------192.168.1.0/24
OSPF
192.168.10.0/24
OSPF
A:R1# configure router ldp-shortcut
Router R6 should advertise the additional

prefixes via an LDP export policy, as
explained in Module 3.
If RSVP-shortcut is also enabled, and an
RSVP-TE LSP exists from router R1 to
router R6, it takes precedence over LDP.
Module 5 |
204
To use the LDP-shortcut feature, LDP labels for the additional prefixes must be present in the LFIB of router R1. This is
accomplished by an LDP-Export policy configured on router R6, as explained in Module 3.
Module 5 - Page 204
LDP Shortcuts for IGP Route Resolution
Module 5 |
205
LAB 5 Section 5.5 Configure RSVP for IP Routing
Module 5 - Page 205
IPv6 Tunneling over MPLS
6PE provides tunneling of IPv6 over IPv4/MPLS network

PE routers run both IPv4 and IPv6
Core routers run only IPv4/MPLS
IPv6 data is encapsulated in two labels
y Inner label is IPv6 Explicit Null
y Outer label is MPLS transport label
MP-BGP used to exchange IPv6 routes across provider core
Module 5 |
206
There are many issues involved in interconnecting IPv4 and IPv6 networks and many strategies for transitioning to IPv6.
One useful technology that makes use of MPLS tunnels is known as 6PE and involves tunneling IPv6 traffic over an
IPv4/MPLS core.
In the 6PE architecture the PE routers of the IPv4/MPLS core run a dual stack of IPv4/IPv6 and exchange the IPv6 routes
using MP-BGP (Multi-Protocol BGP). IPv6 packets are label-switched across the IPv4/MPLS core network. Two labels are
used:
Inner label has the IPv6 Explicit Null value of 2 to indicate that the payload is a native IPv6 packet.
Outer label is the MPLS transport label used for switching across the network.
Module 5 - Page 206
Customer network is IPv6

Provider network is IPv4/MPLS
OSPFv3 or IS-IS used to exchange routes with PE routers
MP-BGP used to carry IPv6 routes over provider core
MPLS tunnels carry IPv6 data
Module 5 |
207
The steps to configure and operate 6PE over an IP/MPLS network can be summarized as follows:
1. PE routers run a dual stack of IPv4 and IPv6 with IPv6 interfaces towards the customer network and IPv4
interfaces toward the service provider core.
2. PE routers use MP-BGP to exchange IPv6 routes learned from customer networks across the core network.
3. IPv6 routes learned through MP-BGP on the PE routers have their next hop resolved through an LDP tunnel.
4. PE routers are configured with static routes or an IPv6 IGP such as OSPF3 or IS-IS to exchange routes with
customer routers. Routes learned through MP-BGP are exported to the customer network.
5. IPv6 data received by the PE routers is encapsulated with two MPLS labels for transmission across the core
network. The inner label has the value of 2 for IPv6 Explicit Null.
Module 5 - Page 207
6PE Topology
PE Configuration for 6PE
PE has dual stack IPv4/IPv6

y Customer-facing interfaces are IPv6
y Core-facing interfaces are IPv4
MP-BGP used to transport customer routes
Module 5 |
208
The listing on the slide shows the configuration on R1 with the dual IPv4/IPv6 stack. The interface towards R8 is IPv6;
the system interface and the interface towards the MPLS core are IPv4.
R1 is configured with a policy to export the IPv6 routes learned from BGP into the IPv6 network with OSPFv3.
*A:R1# configure router ospf3
*A:R1>config>router>ospf3# info
---------------------------------------------asbr
export "bgp_6pe"
area 0.0.0.0
interface "toR8"
exit
exit
---------------------------------------------*A:R1>config>router>ospf3# show router policy "bgp_6pe"
entry 10
from
protocol bgp
family ipv6
exit
action accept
exit
exit
Module 5 - Page 208
*A:R1# show router interface

===============================================================================
Interface Table (Router: Base)
===============================================================================
Interface-Name
Adm
Opr(v4/v6) Mode
Port/SapId
IP-Address
PfxState
------------------------------------------------------------------------------system
Up
Up/Down
Network system
10.10.10.1/32
n/a
toR2
Up
Up/Down
Network 1/1/2
10.1.2.1/27
n/a
toR8
Up
Down/Up
Network 1/1/1
FE80::216:4DFF:FE13:5CAE/64
PREFERRED
------------------------------------------------------------------------------Interfaces : 3
===============================================================================
*A:R1# configure router bgp

*A:R1>config>router>bgp# info
---------------------------------------------group "internals"
family ipv6
export "ospf_6pe"
peer-as 100
neighbor 10.10.10.6
advertise-label ipv6
exit
exit
---------------------------------------------*A:R1>config>router>bgp# show router policy "ospf_6pe"
entry 10
from
protocol ospf3
exit
action accept
exit
exit
BGP peers must support IPv6

advertise-label ipv6 adds IPv6 Explicit Null (2) label
Module 5 |
209
The listing on the previous slide shows that R1 is configured with a policy to export the IPv6 routes learned through BGP
to OSPF3. The routers are actually using MP-BGP to exchange the IPv6 routes. MP-BGP is an extended version of
regular BGP that allows it to carry other address families than simply IPv4. It is typically used for carrying IPv6 or
VPRN routes.
The configuration and operation of MP-BGP is the same as classic BGP. On the 7750 SR we simply specify the address
family to be carried as shown in the slide. IPv4 is the default address family. Notice that the neighbor statement for
R6 also specifies advertise-label. This causes R1 to add the IPv6 Explicit Null label so that the recipient (R6) knows it
is receiving tunneled IPv6 data.
Module 5 - Page 209
PE BGP Configuration for 6PE
IPv6 Next-Hop Resolution for 6PE
===============================================================================
BGP IPv6 Routes
===============================================================================
------------------------------------------------------------------------------RIB In Entries
------------------------------------------------------------------------------Network
: 2001:DB8:1::1/128
Nexthop
: ::FFFF:A0A:A06
From
: 10.10.10.6
Res. Nexthop
: 10.1.2.2 (LDP)
Local Pref.
: 100
Interface Name : toR2
... output omitted ...
Next-hop for IPv6 route is an IPv4 address mapped to IPv6

Next-hop resolved through an LDP tunnel
Module 5 |
210
The slide above shows the route for R7s system address learned through BGP. Note that the next hop is the IPv4 system
address of R6 mapped to an IPv6 address and is resolved through LDP to the next downstream router, R2.
The output below shows the BGP peering of R1 and R6 and the fact that it is enabled for the IPv6 family.
*A:R1# show router bgp summary
===============================================================================
BGP Router ID:10.10.10.1
AS:100
Local AS:100
===============================================================================
BGP Admin State
: Up
BGP Oper State
: Up
Total Peer Groups
: 1
Total Peers
: 1
Total BGP Paths
: 8
Total Path Memory
: 960
Total IPv4 Remote Rts
: 0
Total IPv4 Rem. Active Rts : 0
Total IPv6 Remote Rts
: 1
Total IPv6 Rem. Active Rts : 1
Total Supressed Rts
: 0
Total Hist. Rts
: 0
Total Decay Rts
: 0
... output omitted ...
===============================================================================
BGP Summary
===============================================================================
Neighbor
AS PktRcvd InQ Up/Down
State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
------------------------------------------------------------------------------10.10.10.6
100
1543
0 10h51m28s 1/1/1 (IPv6)
1556
0
===============================================================================
Module 5 - Page 210
*A:R1# show router bgp routes ipv6 2001:DB8:1::1/128 hunt

===============================================================================
BGP Router ID:10.10.10.1
AS:100
Local AS:100
===============================================================================
Legend Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
Origin codes : i - IGP, e - EGP, ? - incomplete, > - best
IPv6 Routes Received for Remote Network
===============================================================================
IPv6 Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------2001:DB8:1::1/128
Remote OSPF3
00h22m21s
150
FE80::216:4DFF:FE13:5CAE-"toR1"
100
2001:DB8:2::1/128
Local
Local
01d02h38m
0
system
0
------------------------------------------------------------------------------No. of Routes: 2
===============================================================================
*A:R8# ping 2001:DB8:1::1 count 1
PING 2001:DB8:1::1 56 data bytes
64 bytes from 2001:DB8:1::1 icmp_seq=1 hlim=62 time=4.20ms.
---- 2001:DB8:1::1 PING Statistics ---1 packet transmitted, 1 packet received, 0.00% packet loss
IPv6 routes are received from remote network

R8 is able to ping R7 across the provider network
Module 5 |
211
Once learned through BGP and installed in the route table the route is exported to OSPFv3 and thus to its neighbor, R8. Router R8
receives the route and is able to ping the system address of the remote IPv6 router (R7) through the MPLS tunnel.
The listing below shows the very simple configuration of the providers core P routers, R2 and R4. They have no IPv6 or BGP
configuration. They are configured as pure IPv4/MPLS routers with IS-IS for the providers core and LDP for the transport tunnels.
*A:R2>config>router# info
#-------------------------------------------------echo "IP Configuration"
#-------------------------------------------------interface "system"
address 10.10.10.2/32
exit
interface "toR1"
address 10.1.2.2/27
port 1/1/2
exit
interface "toR4"
address 10.2.4.2/27
port 1/1/3
exit
#-------------------------------------------------echo "ISIS Configuration"

#-------------------------------------------------isis
level-capability level-2
area-id 49
interface "system"
exit
interface "toR1"
exit
interface "toR4"
exit
exit
#-------------------------------------------------echo "LDP Configuration"
#-------------------------------------------------ldp
interface-parameters
interface "toR1"
exit
interface "toR4"
exit
exit
targeted-session
exit
exit
----------------------------------------------
Module 5 - Page 211
*A:R8# show router route-table ipv6
Section Summary
In this section we covered the theory and configuration principles of:

Resolving BGP next-hops via LDP tunnels
Resolving BGP next-hops via RSVP-TE tunnels
Using RSVP-TE shortcut tunnels for IGP route resolution
Using 6PE to connect native IPv6 networks over an IPv4/MPLS core
Module 5 |
212
The MPLS Shortcuts for BGP next-hops feature is available for both LDP and RSVP-TE based tunnels.
Using MPLS Shortcuts reduces the processing and memory load on transit LSRs.
If the mpls option is used with the igp-shortcut configuration in BGP, RSVP-TE LSPs are preferred over LDP
based tunnels.
If there are multiple RSVP-TE LSPs towards the BGP next-hop, the LSP with the lowest metric is preferred.
If the metric values are equal, the lowest tunnel ID is used as a tie-breaker.
The MPLS shortcuts for IGP route resolution is available.
If the rsvp-shortcut configuration is enabled in the IGP context, and if there are multiple LSPs towards the
destination, the LSP with the lowest metric is preferred.
The lowest tunnel ID can again be used as a tie-breaker.
It is possible to achieve load balancing over multiple RSVP-TE based LSPs with the IGP route resolution feature by
enabling ECMP.
Module 5 - Page 212
Using LDP shortcut tunnels for IGP route resolution
Module Summary
Traffic Engineering manipulates network traffic flows to:

y Optimize resource utilization on redundant links
y Administratively define traffic paths based on constraints
y Engineer paths around potential congestion points
Traditional IGP best path selection is based on a single criteria and

often results in hyper-aggregation and underutilized resources.
LSP constraints include link colors, hop limits, bandwidth
reservations, explicit hops, and shared risk link groups (SRLG).
Constraint based routing automates the path definition process and
simplifies administrative tasks.
Module 5 |
213
Module 5 - Page 213
Bandwidth reservations only apply to the control plane.

Both OSPF and IS-IS support Traffic Engineering extensions.
OSPF support for Traffic Engineering is implemented via Type 10
Opaque LSAs.
IS-IS support for Traffic Engineering is enabled via the definition of

new extended TLVs.
Both Link State protocols support almost identical feature sets for
Traffic Engineering purposes.
The Traffic Engineering Database (TED) stores the information
propagated in the Traffic Engineering IGP extensions.
The TE LSP head-end chooses the LSPs path based on the TED and,
if needed, LSDB.
Module 5 |
214
Module 5 - Page 214
TE-enabled routers exchange Link TLVs once RSVP is enabled on

the interfaces.
Sub-TLVs carry link constraint information.
CSPF prunes the links which do not meet the defined constraints.
Administrative group and SRLG definitions should be consistent

throughout the MPLS domain.
CSPF calculates loose paths and verifies strict hops before sending
the Path message.
The head-end router signals its chosen LSP path by sending the
ERO downstream in the path message.
Enabling the te-metric allows CSPF to consider TE metric values
when calculating the best LSP path.
Module 5 |
215
Module 5 - Page 215
CSPF can identify an error many hops away before the router
signals a path message.
Connection Admission Control (CAC) verifies the bandwidth request
at each hop.
A router assigns a bandwidth reservation from the unreserved
bandwidth on the egress (downstream) interface.
TE bandwidth update triggers control the rate of Opaque LSAs

flooded through the area.
RSVP-TE provides two different reservation styles, the default
Shared Explicit and Fixed Filter.
MBB ensures a new LSP path is valid and operational before moving
traffic from the old one.
Module 5 |
216
Module 5 - Page 216
Least-fill allows the head-end to load balance LSPs through the

MPLS domain.
Operators can configure LSP soft preemption by setting unique
setup and hold priorities along with bandwidth constraints on a per
LSP basis.
DiffServ-TE creates class types to support consistent end-to-end

LSP QoS characteristics.
SR OS routers support DiffServ-TE Maximum Allocation Method
(MAM) and Russian Doll Method (RDM) bandwidth allocation.
LDP-over-RSVP tunnels enable multi-area LSP traffic engineering
on an area-by-area basis.
LDP and RSVP shortcuts allow BGP and IP forwarding for L3 traffic
outside a service context.
Module 5 |
217
Module 5 - Page 217
Learning Assessment
1. What limitation is shared by all IGP protocols when selecting best

paths?
2. Why are Link State protocols better suited for Traffic Engineering
than Distance Vector?
4. Why do network operators implement Traffic Engineering?

5. Available TE constraints include ____________.
6. True or False: Bandwidth reservations apply QoS policies to police
and shape traffic in the core.
7. Assuming an LSP hop-limit constraint of 4 hops, would the headend successfully signal an LSP terminating on the tail-end 4 hops
away?
1.
Module 5 |
218
What limitation is shared by all IGP protocols when selecting best paths?
All IGP protocols are limited to selecting best paths based on limited metrics, such as Hop counts or cost, without
insight into other items, such as link utilization.
2.
Why are Link State protocols better suited for Traffic Engineering than Distance Vector?
Link State protocols are better suited for Traffic Engineering than Distance Vector because they maintain a
database of network topology, which may include the entire domain.
3.
What factor determines the extent of propagation for a link-state packet?

The type of link-state packet determines how far it will propagate.
4.
Why do network operators implement Traffic Engineering?

To define customized LSP paths, use constraints beyond the IGP metrics, and perform CAC.
5.
Available constraints include bandwidth reservations, administrative groups, hop limits, explicit hops, and SRLGs.
6.
True or False: Bandwidth reservations apply QoS policies to police and shape traffic in the core.
False
7.
Assuming an LSP hop-limit constraint of 4 hops, would the head-end successfully signal an LSP terminating on the
tail-end 4 hops away?
No; the hop count includes the head-end, so the tail-end is 5 hops away.
Module 5 - Page 218
3. What factor determines the extent of propagation for a Link State

packet?
8. Define the term disjointed in the context of Shared Link Risk

Groups (SRLGs).
9. SR OS routers generate _____ TLVs as soon as the operator enables
traffic-engineering.
11. Which type of LSA is implemented for OSPF-TE?

12. True or False: The Maximum Reservable Bandwidth on a link may
exceed the Maximum Bandwidth of the link (over-subscription is
allowed).
13. True or False: The Unreserved Bandwidth value for a priority level
on a link must be less than or equal to the Maximum Reservable
Bandwidth.
14. True or False: A given link may be assigned to any number of
Administrative Groups (up to the maximum number of 32 groups).
8.
Module 5 |
219
Define the term disjointed in the context of Shared Link Risk Groups (SRLGs).
Disjointed means that the secondary and fast reroute paths share no links with the primary path.
9.
SR OS routers generate Router ID TLVs as soon as the operator enables traffic-engineering.
10. Link TLVs carry bandwidth, admin group membership, TE metric, and other sub-TLVs.
11. Which type of LSA is implemented for OSPF-TE?
The Opaque Type 10 Area local LSA is implemented for OSPF-TE.
12. True or False: The Maximum Reservable Bandwidth on a link may exceed the Maximum Bandwidth of the link
(over-subscription is allowed).
True.
13. True or False: The Unreserved Bandwidth value for a priority level on a link must be less than or equal to the
Maximum Reservable Bandwidth.
True.
14. True or False: A given link may be assigned to any number of Administrative Groups (up to the maximum number
of 32 groups)
True.
Module 5 - Page 219
10. ___ TLVs carry bandwidth, admin group membership, TE metric,

and other sub-TLVs.
15. What is the purpose of the Router ID TLV?

16. CSPF ____ links which do not meet the specified constraints,
then uses the ____ algorithm to calculate the LSP path.
17. The ____ carries CSPF calculated hop information end-to-end.
19. True or False: CSPF serves no purpose if configured on an LSP
with all strict-hop paths.
20. True or False: A router automatically supports TE metrics if
configured on an interface.
21. Why do the SR OS routers perform Connection Admission Control
(CAC) on bandwidth reserved LSPs?
22. In addition to IGP TE Bandwidth Update thresholds, what
additional features can trigger TE updates?
15.
Module 5 |
220
What is the purpose of the Router ID TLV?

The Router ID TLV provides a stable, reachable address that can be used to create an explicit route.
16.
CSPF prunes links which do not meet the specified constraints, then uses the SPF algorithm to calculate the LSP
path.
17.
The ERO carries CSPF calculated hop information end-to-end.
18.
Administrative constraints may be asymmetrical on a link.
19.
True or False: CSPF serves no purpose if configured on an LSP with all strict-hop paths.
False. CSPF verifies that the hops are valid before sending the path message.
20.
True or False: A router automatically supports TE metrics if configured on an interface.

False. You must enable TE metrics in an LSPs CSPF context.
21.
Why do the SR OS routers perform Connection Admission Control (CAC) on bandwidth reserved LSPs?
The bandwidth may no longer be available downstream, the reservation state may have changed, or the TED
may not be current.
22.
In addition to IGP TE Bandwidth Update thresholds, what additional features can trigger TE updates?
On CAC failure and update timers.
Module 5 - Page 220
18. Administrative constraints may be _______ on a link.
23. Which reservation style provides each sender with a dedicated

reservation that is not shared with other senders?
25. Using SE and MBB, and assuming that an existing LSPs bandwidth
reservation is changes from 400 Mbps to 700 Mbps on a link with
200 Mbps unreserved bandwidth left, how will the head-end
handle the increased bandwidth request?
26. TE least fill chooses an LSPs path based on what characteristic?
27. By default, an LSP has a setup priority of ___ and a hold priority
of ____.
28. The DiffServ-TE ____ ____ _____ allows class types to share
bandwidth reservations.
Module 5 |
221
23.
Which reservation style provides each sender with a dedicated reservation that is not shared with other senders?
FF.
24.
Which reservation style creates a single reservation over a link that is shared by an explicit list of senders?
SE.
25.
Using SE and MBB, and assuming that an existing LSPs bandwidth reservation changes from 400 Mbps to 700
Mbps on a link with 200 Mbps unreserved bandwidth left, how will the head-end handle the increased bandwidth
request?
Signal the new path over another set of links, if possible. The delta, 300 Mbps, between the old bandwidth and
the new is >200Mbps. The head-end leaves the LSP up on the old path until it succeeds in bringing up a new path
supporting the new bandwidth constraint.
26.
TE least fill chooses an LSPs path based on what characteristic?

The path from the head-end to the tail-end with the least reserved bandwidth.
27.
By default, an LSP has a setup priority of 7 and a hold priority of 0.
28.
The DiffServ-TE Russian Dolls Model allows class types to share bandwidth reservations.
Module 5 - Page 221
24. Which reservation style creates a single reservation over a link

that is shared by an associated set of LSP paths?
29. Assuming the DiffServ-TE Maximum Allocation Model (MAM), if a

CT0 LSP uses all of its available reservable bandwidth on one
link, can the head-end signal another LSP in the same class-type?
31. ____ _____ eliminate the need to propagate external routes

throughout the core network.
32. In a 6PE network, which version of IP is run by each of the 3
different types of routers: customer router, PE router and P
router
29.
Module 5 |
222
Assuming the DiffServ-TE Maximum Allocation Model (MAM), if a CT0 LSP uses all of its available reservable
bandwidth on one link, can the head-end signal another LSP in the same class-type?
Yes, if the new LSP can preempt the first AND enough bandwidth exists for that CT along the original path to
meet the new LSPs requirements, or if there is another available path toward the tail-end meeting the new
LSPs constraints within the same CT.
30.
T-LDP sessions between LERs and ABRs and between ABRs and ABRs stitch together individual intra-area RSVP-TE
LSPs.
31.
BGP Shortcuts eliminate the need to propagate external routes throughout the core network.
32.
In a 6PE network the customer routers run IPv6 only, the PE routers run a dual stack of IPv4 and IPv6 and the
provider core (P) routers run only IPv4.
Module 5 - Page 222
30. _____ sessions between LERs and ABRs and between ABRs and
ABRs _____ together individual intra-area RSVP-TE LSPs.

Switching
Module 6 Resiliency
Module 6 Page 1
Module Objectives

to:
Describe the factors that influence MPLS convergence.
Understand and deploy Fast Reroute.

Describe LSP Re-Optimization techniques.
Module 6 |

Module 6 focuses on the convergence aspects and resiliency features of MPLS; as such, secondary LSP-Path and Fast
Reroute protection implementation and configuration details are all described in detail.
Module 6 Page 2
Understand and deploy resiliency, using Standby Secondary and

Non-Standby Secondary paths.
Module 6 Resiliency
Section 1 MPLS Convergence Overview
Module 6 Page 3
Section Objectives

Discuss the factors that influence total network convergence times
for the following scenarios:
y Plain IGP network
y Fast-Reroute protection
y Using LDP based tunnels
y LDP-IGP Sync feature
Module 6 |
This section covers the major aspects of network convergence, including failure detection, propagation, and service
recovery. Various scenarios that use native IP forwarding, secondary LSP-Path and Fast Reroute protection, and LDP
tunnels are presented and analyzed.
Module 6 Page 4
y Secondary LSP-Path protection with RSVP-TE
Network Resiliency Overview
Network reliability is a major concern.

Failures can happen at any time (Murphys Law).
Short reaction and restoration times are highly desirable.
MPLS can bring superior convergence performance.
Module 6 |
Network reliability is one of the main concerns of network operators today. Network failure can be the result of
physical link failures, power failures, and hardware or software failures in network devices. It is therefore important to
take necessary precautions against all imaginable failures that can happen in the network.
One of the key aspects in selecting the right networking technology is how quickly that technology can react to network
failures and quickly restore network services by rerouting the traffic around the failure point. The term convergence
refers to the time that it takes to restore the services. Quick detection of network failures and short convergence times
are crucial to a service providers ability to meet the standards set in the Service Level Agreement (SLA).
With the support of RSVP-TE and CSPF, MPLS can bring significant performance advantages, with respect to convergence
times.
Module 6 Page 5
Convergence is the total time it takes to reroute the traffic around

the network failure point.
Methods to Provide Core Network Resilience
Physical layer redundancy: Backup links, routers, router

components, and so on.
Protocol redundancy: Failure detection mechanisms, timers,
specialized algorithms, and so on.
Using MPLS with RSVP-TE, proactive measures can be taken, before

any failure is suffered.
Using LDP, the convergence times rely strictly on IGP convergence
because of protocol dependence.
Module 6 |
Resiliency is implemented by introducing redundancy at several layers in the network.

Physical layer redundancy is usually the starting point. For maximum resiliency, network devices should be made as
redundant as possible, from a hardware perspective. Network devices can have backup components, such as redundant
control cards, power supplies, fan units, and so on, to minimize the risk of complete router failure. Added to this,
backup links, routers, and redundant connections should also be considered to create alternative forwarding paths for
traffic and mitigate the effects of failure and congestion.
Protocol level redundancy depends on the physical layer redundancy implemented in the network. If alternative paths
are available, dynamic protocols can calculate new paths for traffic, in case of failures. Another important aspect here
is the detection of physical failures by upper layer protocols. Dynamic protocols have built-in timers and mechanisms
for the detection of failures.
IGP protocols are reactionary. A new path is calculated only after the detection of a failure that affects the existing
path. Although this is relatively fast, the convergence times might fall short of the increasing demands of newly
emerging applications, such as video conferencing, voice, online gaming, and so on.
Using MPLS resiliency features, such as secondary LSP-Paths and Fast Reroute with RSVP-TE signaling, protection tunnels
can be created prior to potential failures take place. This is a proactive approach towards providing network resilience.
LDP is also an MPLS signaling protocol, but the IGPs convergence factors limit its resiliency.
Module 6 Page 6
IGP provides reactional resilience: Recovery actions are taken

after a failure has happened.
Convergence Factors
The factors affecting convergence performance are:

y Failure Detection: Identifying and locating the failure.
y Service Recovery: Redirecting traffic to alternative paths and

recovering services.
Module 6 |
The primary aspects of network convergence are:

Failure Detection: Failures are identified and located by the closest network devices.
Failure Propagation: After a failure is detected, other routers in the network are notified of the problem by the
devices that detected the failure. The devices send control messages, depending on the protocol and application.
Service Recovery: Eventually, customer services are recovered by directing traffic around the point of network
failure.
Module 6 Page 7
y Failure Propagation: Notifying other routers about the failure

by disseminating the failure information.
Failure Detection
The network failure must be detected before any action can be

taken to recover the services.
Detection time depends on the:

y Nature and location of the failure
y Mechanisms in place to detect the failure
The two types of failures are:
y Local failure
y Remote failure
Module 6 |
Failure detection time is key to the performance of overall network convergence.

Several factors influence the time it takes to detect a failure. One is the nature and location of the failure. For
example, a physical layer problem that impacts a fiber optic cable might be easy to detect because the laser signal is
lost as a result. However, the router might need to rely on additional mechanisms, such as protocol timers, to detect
software related problems.
The location of failures can be classified as either local or remote. This is explained on the next page.
Module 6 Page 8
Failure detection time is key to network convergence

performance.
Failure Types Local vs. Remote
y When the port goes down at physical layer, all upper protocol layers
are notified to trigger convergence.
In the case of a remote failure:

y The link between two transmission devices goes down
y The local router ports may stay up, if the transmission equipment
does not propagate the failure.
y In that case, the routers need to rely on additional mechanisms, such
as IGP or RSVP hellos, to detect that the adjacency is down.
Module 6 |
Considering a physical layer failure concerning the link directly attached to a router, a local failure is immediately (or
after a very short interval) detected by the routers connected to that link. This initiates convergence and triggers
recovery action on all the upper layer protocols.
In many networks, however, routers are not directly connected by cables; instead, there can be several transmission
devices connecting the router ports. When a failure takes place on the link between two transmission devices, the local
ports on the routers can stay up unless the failure is propagated to the routers. This is referred to as a remote failure
and routers rely on additional mechanisms implemented at protocol level for failure detection in these cases.
Module 6 Page 9
Local failures are immediately detected by routers.
Failure Detection Mechanisms at Protocol Level
IGP Hello: With default timers, it takes approximately 30 seconds

to detect that the adjacency is down.
RSVP Hello: With default timers, it takes approximately 9 seconds
to detect that the adjacency is down.
Setting these timer values very low is not recommended because
of control plane overhead.
Alternative mechanisms (preferred):
y BFD (Bidirectional Forwarding Detection) A lightweight Hello
protocol, used as a heartbeat. Runs at IP-level.
y EFM (Ethernet in the First Mile) Standard Ethernet link-level OAM
implementation. Also referred to as 802.3ah.
y Both BFD and EFM can provide sub-second detection times.
Module 6 |
10
There are several heartbeat mechanisms at different protocol levels to detect failures that go undetected by the
physical layer mechanisms.
Using default IGP Hello Timers, it takes around 30 seconds to detect that an IGP adjacency is lost.
Using default RSVP Hello Timers, it takes around 9 seconds to detect that an RSVP adjacency is lost.
Both Hello timers can be set as low as 1 second; sub-second detection is not possible with Hello timers. However,
aggressive hello timers are usually not recommended because they can bring additional messaging and processing
overhead.
Two alternative methods are widely deployed to provide sub-second detection with low control plane overhead.
Bidirectional Forwarding Detection (BFD) a lightweight heartbeat mechanism that sends and receives simple
periodic protocol packets to determine if the other end of the connection is alive. BFD runs at IP-level (Layer 3)
and is supported by all the major dynamic protocols, as well as by static routes.
Ethernet in the First Mile (EFM) defined in the IEEE specification 802.3ah, EFM provides link-level (Layer 2) OAM
detection.
For configuration and other details of BFD and EFM implementations, please refer to the Service Router Configuration
Guides.
Module 6 Page 10
Minimum value for the IGP and RSVP Hello timer is 1 second.
Using link-state routing protocols (OSPF and IS-IS), updates are

event triggered.
LSAs are propagated through the network as soon as the failure is
detected.
Module 6 |
11
Failure propagation takes place after a failure is detected. Using link-state protocols like OSPF or IS-IS, link-state
update packets are flooded in the network to inform all the routers about the link failure. The receiving routers
compare the information in the link-state update with their link-state Database and update the routing information to
reflect the failure.
Module 6 Page 11
Failure Propagation in IGP
Only the Head-End router of the LSP is aware of the availability of a

pre-configured secondary LSP-Path.
The Head-End router must be notified of any failure that affects the
primary LSP-Path.
The router that detects the failure sends a path error message.
Module 6 |
12
At the Head-End, the operator can protect the primary path with secondary LSP-Path(s). These can be either:
Cold-standby secondary paths - The Head-End only signals these if a failure occurs on the primary path and the HeadEnd cannot move the primary to another path
Hot-standby secondary paths - Become operational even before any failure takes place.
When the primary LSP-Path experiences failure, a PATH Error message containing this information is delivered to the
LSP Head-End. Since the secondary LSP-Path is configured at the Head-End, only the Head-End can activate the
secondary LSP-Path and switch traffic over to it.
Therefore, the Head-End router is the decision point for service recovery action, in the case secondary LSP-Path
protection.
Module 6 Page 12
Failure Propagation Using Secondary LSP-Paths
Using Fast Reroute, the router that detects the failure can take a
local decision to recover the traffic.
A path error message is still sent to inform the LSP Head-End.
Module 6 |
13
Alternatively, Fast Reroute protection tunnels can be created on the routers along the primary LSP-Path, prior to
failure. Should link failure occur, the router that is connected to the failing resource can make a local decision to
recover the traffic; that is closest point to the failure and it is responsible for taking service recovery action.
The LSP Head-End still needs to be informed, as it might want to take further action to move the traffic to a better
path. Again, an RSVP PATH Error message is sent towards the Head-End for this purpose.
Module 6 Page 13
Failure Propagation Using Fast Reroute
Link-State Databases are updated with new LSA information.

All the routers make a new SPF calculation and re-evaluate their IP
Forwarding Tables.
The whole convergence can take up to several seconds, depending
on the size of the network, the number of routes, and so on.
Module 6 |
14
After failure propagation, service recovery action takes place on the routers.
In the case of link-state protocols, when a new link-state update is received, it implies a topology change in the
network and all the routers need to make a new calculation of the SPF algorithm and re-evaluate the path reachability
to destinations in the network.
Total network convergence occurs only when all the routers reach new steady-state conditions after updating their
Forwarding Tables. This process might take up to several seconds in large networks. During this time, traffic might be
prone to discards, black-holes, or loops, so shorter convergence times are important for critical traffic.
Module 6 Page 14
Service Recovery Using IGP
When the Head-End receives the path error message, it switches the
traffic over to the secondary LSP-Path.
Key factor is the propagation time of the path error message.
The switchover from the primary to the secondary path is hitless.
Module 6 |
15
Once notified of the failure impacting the primary LSP-Path, the Head-End performs a traffic switchover to the
secondary LSP-Path, if it is already established. This is the case with the (hot) standby secondary LSP-Path option
(discussed in more detail in Section 2). The switchover to the secondary path is mostly hitless, and there is no traffic
loss in the majority of the cases.
The crucial factor here is the time it takes to deliver the Path Error message from the point of failure to the Head-End.
This depends on factors such as how far from the Head-End router the failure occurs and the propagation delay on each
of the links along the path.
Module 6 Page 15
Service Recovery Using Secondary LSP-Paths
Using Fast Reroute, traffic is recovered in less than 50 ms. after the
failure is detected.
The first upstream router from the point of failure switches traffic to
the backup tunnel that was established before the failure.
Module 6 |
16
If the LSP is configured Fast Reroute, the primary LSP-Path can be protected by a series of local protection tunnels,
established on each possible router along the path. When a failure occurs on the primary LSP-Path, the router that
detects the failure can make a local decision to recover the traffic, without waiting for the LSP Head-End.
Most often, traffic is switched over to a Fast Reroute protection tunnel within 50 milliseconds after the detection of
failure. This brings a clear performance advantage over other resiliency methods.
Module 6 Page 16
Service Recovery Using Fast Reroute
LDP Convergence
LDP has a strong dependence on IGP.

LDP next-hop for a prefix MUST be the same as the IGP next-hop.
Label switching cannot take place otherwise.
Using liberal retention, routers keep the redundant labels from

neighbors other than the IGP next-hop. This helps improve the
convergence times.
Module 6 |
17
By protocol design, LDP relies heavily on IGP, as relates to operation and convergence.
LDP and IGP must have identical forwarding paths. Therefore, LDP must have the same next-hop information in the LFIB
as in the FIB.
When failure is detected, IGP first calculates a new next-hop as a result of the SPF run and updates the FIB. Following
this, LDP installs the label received from the newly determined IGP next-hop in the LFIB. Thus, the two forwarding
tables are synchronized and label switching can take place.
Thanks to liberal label retention, labels received from inactive IGP peers are kept in the control plane LIB. If a peer
becomes the active next-hop, the previously advertised label can immediately be installed in the LFIB and label
switching of traffic can resume.
A case study is presented in the following pages to illustrate these points.
Module 6 Page 17
After failure detection (a common denominator for all resilience

techniques), the most important factor is IGP convergence.
LIB output shows that router R1 has

received two different labels from both
peers.
Router 1 is using the label from router R2
in the data plane (LFIB), as decided by IGP.
The LDP tunnel follows the same path as IP
forwarding.
Module 6 |
18
The initial network condition is depicted in the case study above.

IGP forwarding takes place on the shortest IGP path and router R2 is the next-hop in the FIB of router R1.
Router R1 has received two different LDP labels from both peers, routers R2 and R3, for prefix 10.10.10.6/32, and is
storing them in the LIB. Router R2 is installed in the LFIB, along with the label it has advertised, because it is the IGP
next-hop present in the FIB.
Module 6 Page 18
LDP Convergence Example Initial Condition
Failure is detected.
Router R2 is deleted from the FIB.
Router R2 withdraws its label.
The label is deleted from the LFIB.
Traffic is being discarded.
Module 6 |
19
The link between R2-R6 fails. The failure is detected and propagated to other routers in the network.
Router R1 deletes router R2 from the FIB, breaking the IP forwarding. The label from router R2 is also deleted from the
LFIB and LIB, as a result of the label withdraw and release actions. MPLS label switching cannot take place.
Module 6 Page 19
LDP Convergence Example Link Failure
IGP finds a new next-hop (router R3).

The label from router R3 is readily available
in the LIB.
Router R1 starts using the label from router
R3.
Traffic is being forwarded over the new path.
Module 6 |
20
Router R1 runs a new SPF calculation and installs router R3 as the new IGP next-hop in the FIB.
LDP also installs router R3 as next-hop in the LFIB. The label from router R3 has been previously received and stored in
the LIB, so router R1 starts using it in the LFIB right away. MPLS label switching can continue.
Module 6 Page 20
LDP Convergence Example: Convergence
Module 6 Resiliency
Section 2 LDP-IGP Sync
Module 6 Page 21
The link is restored.

IP next-hop changes back to router R2.
Entry for router R3 is deleted from LFIB.
Router R2 has not advertised a label yet.
Router R1 discards MPLS traffic until it
receives a label from router R2.
Module 6 |
22
Sometimes traffic is lost while reverting to a best IGP next-hop, an example of which is illustrated above.
The link between R2-R6 recovers and updated LSAs propagate through the network. Router R1 runs a new SPF
calculation in response to the topology change and once again installs in the FIB router R2 as the FEC 10.10.10.6/32 IGP
next-hop.
On router R1, the FIB and LFIB entries no longer match: The FIB has router R2 as the next-hop while the LFIB has router
R3 as the next-hop. The LDP RFCs do not allow this and, as a result, router R1 removes router R3 its label from the LFIB.
Label switching cannot take place until router R1 installs a new label binding in the LFIB.
Module 6 Page 22
Link Restoration without LDP-IGP Sync (Possible Issue)
LDP-IGP Sync Feature
After link restoration, IGP converges back to the previous nexthop.

MPLS traffic may be discarded temporarily while waiting for an
LDP label advertisement from the new IGP next-hop.
The feature is enabled, by default, under IGP (OSPF or IS-IS).

A timer value needs to be configured under each network IP
interface on which this feature is desired.
Router advertises the maximum metric (65535) for the recovered
link until the timer expires.
This holds down the new IGP route until the next-hop can generate
a label for the FEC.
Module 6 |
23
To handle problems as described in the previous page, the LDP-IGP Sync feature, also referred to as Draft Jork, allows
the routers to continue using the existing LDP next-hop until the next-hop can signal a label for the FEC. This holds
down the new route and prevents temporary traffic loss during the next-hop transition period.
By default, the SR OS routers enable the LDP-IGP sync feature in the IGP context. Whenever a link becomes unavailable,
the routers adjacent to that link advertise it with a metric of 65535. However, you must configure an LDP sync timer
value on each network interface that will use the feature. This value sets the time in seconds the router will hold
down a new route while the router waits for an associated label.
When LDP-IGP sync is activated, the FIB and LFIB next-hop remains unchanged until the downstream node can set up an
LDP session to its next-hop peer. Once the LDP session succeeds, the downstream node still advertises the high metric
for the LDP sync timer. Once the timer expires, the router waiting for the new label updates its FIB and moves the new
label from its LIB to its LFIB.
This feature also helps to prevent rapid switching between different next-hops, in the case of an unstable (flapping)
network link.
Module 6 Page 23
LDP-IGP Sync Feature, also known as Draft Jork, handles such

issues.
The link is restored.

Router R2 has LDP-IGP Sync enabled.
Router R2 starts advertising the maximum
metric for the link to router R6.
Router R2 waits for the LDP session to router
R6.
Module 6 |
24
With the LDP-IGP sync feature enabled, router R2 starts advertising the maximum IGP metric (65535) to router R1 for
the FEC 10.10.10.6/32. Router R1 waits for router R2 to establish an LDP session to the new next-hop (router R6 in this
example).
The metric is virtually infinite, thus router R1 does not revert the IGP next-hop to router R2. Router R3 is still the nexthop present in the FIB and the LFIB and traffic forwarding resumes on the existing path.
Module 6 Page 24
LDP-IGP Sync Maximum Metric Advertisement
LDP session R2-R6 recovers.

Router R2 starts the LDP-Sync Timer.
Router R2 continues to advertise maximum
metric for the interface.
Router R1 receives label from router R2, but
the FIB and LFIB next-hop remains router R3.
Module 6 |
25
The LDP session between routers R2 and R6 is established and router R2 now advertises an LDP label for FEC
10.10.10.6/32. Router R1 installs this label in its LIB, but still holds the FIB and LFIB next-hops are they were previously.
For the duration of the timer, router R2 continues to advertise the link metric as 65535. Router R1 does not switch over
to the new next-hop until it receives a better metric for the link.
Module 6 Page 25
LDP-IGP Sync Maximum Metric Advertisement
LDP-Sync timer expires.

Router R2 starts advertising normal IGP metric.
Router R1 changes IGP next-hop back to router
R2.
Router R1 changes its LFIB next-hop
accordingly.
Module 6 |
26
When the LDP-Sync timer expires, router R2 advertises the standard IGP link metric, in this case, 100. As a result,
router R1 updates the FIB next-hop to router R2, and installs the label it received from router R2 in the LFIB.
Traffic forwarding continues on the shortest IGP path. Potential temporary traffic loss during next-hop transition period
is therefore prevented by LDP-IGP Sync.
Module 6 Page 26
LDP-IGP Sync Reverting to Router R2
Enabling LDP-IGP Sync
LDP-IGP Sync is enabled under the IGP by default (for example,

OSPF)
A timer value needs to be configured under the IP interfaces for
the feature to work:
Possible values for the LDP Sync-Timer are between 1-1800

seconds.
By default, no timer is configured (the feature is disabled on the
interface).
The timer also helps to handle unstable conditions, such as a
flapping link.
Module 6 |
27
LDP-IGP Sync is enabled by default under the IGP configuration, as shown in the figure above. To activate it, an ldpsync-timer is configured under every interface that will use the feature.
Module 6 Page 27
A:R1>configure router interface toR2 ldp-sync-timer <value>
Verifying LDP-IGP Sync
The following output is displayed while waiting for the LDP session
to come up (the LDP Sync Timer is not yet running):
A:R1# show router ospf interface toR2
After the session comes up, the router waits for the LDP SyncTimer to expire before it activates the new next-hop:
A:R1# show router ospf interface toR2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ldp Sync
: inService
Ldp Sync Wait
: Enabled
Ldp Timer State : Timer Active
Ldp Tm Left
: 7
Module 6 |
28
Use the show router ospf interface <interface-name> detail command to verify the operation of the LDPIGP Sync feature. Only fields related to the LDP-IGP Sync feature are shown in the output above, for clarity.
Ldp Sync displays outOfService if the feature is disabled in IGP, or if an LDP Sync timer is not configured under
the interface. Once a Sync Timer is configured, the output shows inService.
LDP Sync Wait displays Disabled under normal operating conditions. Once a new IGP next-hop is found, it
becomes Enabled, as shown in the first command output.
LDP Timer State displays Wait for Ldp Adj. until an LDP session is established to the newly found IGP next-hop.
It changes to Timer Active, as shown in the second command output, after the LDP session becomes active.
LDP Tm Left displays 0 if LDP-IGP Sync is inactive, or the LDP session to the new IGP next-hop is not yet
established, as shown in the first command output. After the session is established, the timer starts to count down
from the user configured LDP Sync timer. The router starts to advertise normal IGP metrics when the timer expires.
Module 6 Page 28
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ldp Sync
: inService
Ldp Sync Wait
: Enabled
Ldp Timer State : Wait for Ldp Adj.
Ldp Tm Left
: 0
Section Summary
Resiliency principles, using Secondary LSP-Paths and Fast-Reroute

with MPLS Traffic Engineering
LDP dependence on IGP in convergence.
The LDP-IGP Sync feature, to avoid traffic loss when reverting to
the best IGP next-hop.
Module 6 |
29
Several factors influence the network convergence performance.

Failure detection is the time it takes to identify and locate a failure.
Failure propagation is the dissemination of failure information to other routers in the network.
Service recovery refers to actions taken to restore the traffic.
In an IGP network, network convergence occurs when all routers are informed of a failure via IGP updates and reevaluate their forwarding tables by individual SPF calculations.
Using secondary LSP-Paths, the Head-End router is informed of the failure by a Path Error message issued by the
detecting router. The Head-End is the decision point for recovering service over secondary LSP-Paths.
Using Fast Reroute, the router that detects the failure can make a local decision to recover the traffic on a readily
available protection tunnel.
LDP relies on IGP in terms of operation and convergence.
LDP has to use the same next-hop in the LFIB as the IGP next-hop in the FIB.
After a failure, LDP can use the label from the new IGP next-hop - a benefit of liberal label retention.
Temporary traffic loss can result when reverting to a previous IGP next-hop after the removal of network failure.
The LDP-IGP Sync feature mitigates such issues by advertising a maximum metric value for the newly found IGP
next-hop until the expiry of the LDP Sync timer.
Module 6 Page 29

Factors that influence total network convergence:
y Failure detection
y Failure propagation
y Service recovery
Module 6 Resiliency
Section 2 Secondary LSP-Path Protection
Module 6 Page 30
Section Objectives
Secondary LSP Path Selection Rules using:

y Default path-preference values
y Customized path-preference values
Maintaining LSP Path Diversity using:
y Strict Hop LSP Path Definitions
y Administrative Groups
y Shared Risk Link Groups
Module 6 |
31
The secondary LSP-Path protection option is explained in detail in this section.

The use of two secondary LSP-Path configuration modes, Standby and Non-standby, are explained with the use of
examples.
Selection criteria between multiple secondary LSP-Paths, depending on the path-preference values, is then described
and reinforced with case studies.
An important aspect of using secondary LSP-Path protection is ensuring that secondary LSP-Paths do not share any
common links with their protected primary LSP-Paths. Different methods to achieve this are explained at the end of the
section.
Module 6 Page 31

MPLS resiliency using:
y Standby Secondary Paths
y Non-Standby Secondary Paths
Secondary LSP-Path Protection Overview
Up to 8 LSP-Paths can be configured at the Head-End router of an

LSP.
There can be only 1 primary, and up to 7 secondary, LSP-Paths.
Only one LSP-Path forwards the traffic at any time.
If the primary path fails, the available secondary path(s) can

forward the traffic.
The secondary LSPs can be configured as:
y (Hot) Standby Secondary
y Non-Standby Secondary
Module 6 |
32
An LSP configured at a Head-End router can have up to 8 LSP-Paths defined. One of those paths is the primary LSP-Path,
thus a maximum of 7 secondary LSP-Paths can be configured inside the LSP. (It is possible to configure an LSP without a
primary LSP-Path, but this is not recommended.)
Although multiple LSP-Paths are available to an LSP, only one LSP-Path can be active and can forward data traffic at
any given time. The LSP never attempts to load balance the traffic over multiple LSP-Paths.
The primary LSP-Path, once fully functional, is always the preferred path to use. Secondary LSP-Path and Fast Reroute
protection mechanisms are designed and deployed to protect against failures on the primary LSP-Path only. It is the
assumption here that the designated primary LSP-Path is the best path to forward LSP traffic.
There are two modes for secondary LSP-Paths. The first is secondary (Non-standby), which is the default mode. The
second is standby, which may be changed in the configuration.
Case studies are included in the following pages that illustrate the use of both modes.
Module 6 Page 32
As long as it is operationally up, the primary path is always

preferred.
lsp "to_R6
cspf
to 10.10.10.6
primary prim_path
exit
secondary stdby_sec
standby
LSP is enabled.
The Primary LSP-Path is signaled first.
exit
Module 6 |
33
An LSP is configured to 10.10.10.6 with a primary LSP-Path definition, prim_path, and a secondary LSP-Path
definition, stdby_sec. The secondary LSP-Path is configured in Standby mode.
The path configurations for prim_path and stdby_sec are omitted, for the sake of clarity. The resulting paths that
are signaled by RSVP-TE, however, are shown in the output.
When the LSP is enabled, the first priority of router R1 is to signal the primary LSP-Path, regardless of alternative
options configured. The primary LSP-Path is signaled over the path, as shown in the figure above.
Module 6 Page 33
Standby Secondary Primary LSP-Path setup
Standby Secondary Secondary LSP-Path setup
lsp "to_R6
cspf
to 10.10.10.6
primary prim_path
exit
secondary stdby_sec
standby
exit
A standby secondary is configured.

It is signaled right after the primary LSPPath.
Module 6 |
34
Since the secondary LSP-Path is configured in Standby mode, it is also signaled after the primary.
Both LSP-Paths are established, with RSVP sessions in place and labels negotiated.
Module 6 Page 34
As long as it is operationally up, the Primary LSP-Path forwards the

traffic.
The standby secondary path is also established and remains ready, in
case of a failure that affects the primary LSP-Path.
Module 6 |
35
The primary LSP-Path is up, and has precedence over the other LSP-Paths; therefore, router R1 forwards the traffic over
the primary LSP-Path.
The standby secondary LSP-Path is established and it waits in Hot Standby mode, ready to take over the data traffic,
should the primary LSP-Path experience failure.
Module 6 Page 35
Normal Conditions Using the Primary Path
Router R4 sends a path error message upon detecting the link failure.
As the Head-End router, router R1 is responsible for recovering the
traffic.
After receiving the path error message, router R1 switches the traffic
to the standby secondary path.
Module 6 |
36
The link between R4-R6 fails so router R4 issues a PATH Error message upstream, towards the LSP Head-End, to notify
router R1 about the failure on the primary LSP-Path.
Router R1 determines that it has an available standby secondary LSP-Path established and ready to deliver traffic. A
switch takes place on router R1, and the standby secondary LSP-Path becomes the new active path.
The only time lost in this process is the time that it takes the PATH Error message to reach the Head-End. No time is
spent signaling the secondary LSP-Path.
Module 6 Page 36
Failure Case Switchover to Standby Secondary
lsp "to_R6
cspf
to 10.10.10.6
primary prim_path
exit
LSP is enabled.
secondary stdby_sec
The Primary LSP-Path is signaled first.
exit
Module 6 |
37
Presented above is a slightly modified version of the previous case study. In this scenario, the secondary LSP-Path is
configured in Non-standby mode (default).
Again, after the LSP is enabled, the Head-End signals the primary LSP-Path.
Module 6 Page 37
Non-Standby Secondary Primary LSP-Path Setup
lsp "to_R6
cspf
to 10.10.10.6
primary prim_path
exit
secondary stdby_sec
exit
A non-standby secondary LSP-Path is

configured.
As long as the primary LSP-Path is up it is
not signaled.
Module 6 |
38
Unlike the previous case, the secondary LSP-Path is not signaled after the primary LSP-Path is established because it is
configured in non-standby mode.
Module 6 Page 38
Non-Standby Secondary Traffic over Primary LSP-Path
Router R1 receives the path error message from router R4.

It first needs to signal the secondary LSP-Path to restore the traffic.
The traffic is discarded until the secondary path is established.
Module 6 |
39
The link between R4-R6 fails so router R4 issues a PATH Error message upstream, towards the LSP Head-End, to notify
router R1 about the failure on the primary LSP-Path.
Router R1 determines that it has a non-standby secondary LSP-Path, which is not yet signaled. It signals the secondary
LSP-Path with a PATH message and waits for the RESV message response. Data traffic is discarded while router R1 waits.
The total convergence time for a non-standby secondary LSP-Path is thus the propagation time for the PATH Error
message plus the signaling time required for the secondary path. This is obviously worse than the recovery time for a
standby secondary path.
However, a non-standby secondary path is less resource intensive than a standby secondary path, because it does not
consume any RSVP sessions or labels while the primary LSP-Path is up.
Module 6 Page 39
Failure Case Non-Standby Secondary LSP-Path Setup
Router R1 switches the traffic to the established secondary LSP-Path.

Router R1 continuously tries to re-establish the primary.
Module 6 |
40
When the secondary LSP-Path is established, Head-End router R1 starts forwarding the traffic over this path.
The Head-End also tries to restore the primary LSP-Path every 30 seconds, by default. This is determined by the retrytimer configuration for the LSP (explained in Section 3).
Module 6 Page 40
Failure Case Switchover to Non-Standby Secondary LSP-Path
The failure is removed.

Router R1 re-establishes the primary and switches traffic on it.
The non-standby secondary LSP-Path is torn down.
Module 6 |
41
The link between R4-R6 is recovered and router R1 re-establishes the primary LSP-Path over its previously used links.
The traffic is switched to the primary LSP-Path.
The primary LSP-Path is now the active LSP-Path.
The secondary LSP-Path is configured in non-standby mode, therefore it is not needed and is torn down with a PATH
Tear message.
Module 6 Page 41
Primary LSP-Path Recovery with a Non-Standby Secondary
Secondary LSP-Path Selection Overview
As long as it is operationally up, the primary LSP-path is always

preferred.
Multiple secondary LSP-Paths can be configured.
There are two modes in selecting the secondary LSP-Path:

y Default mode, without secondary path-preferences
y Non-Default mode, with secondary path-preferences
Module 6 |
42
If multiple secondary LSP-Paths are configured to protect the same primary LSP-Path, the Head-End must choose one to
become active, upon failure on the primary.
Path-preference for secondary LSP-Paths allows the operator to choose which secondary the LSP uses and in what
order.
The use of path-preference is optional.
Module 6 Page 42
If the primary LSP-path goes down, traffic is switched over to one

of the secondary LSP-Paths.
Default Secondary LSP-Path Selection Criteria
Secondary LSP-Paths are used in the following order:

y Standby secondary path
In case of multiple standby secondary paths, the one with the
highest uptime is used.
y Non-standby secondary path
When an active secondary LSP-path fails, another available

secondary LSP-path can be used.
If the previously failed secondary LSP-path is recovered, the router
does not revert to it.
Module 6 |
43
Using default path-preference values, when there is primary LSP-Path failure:

A standby secondary LSP-Path is chosen over a non-standby secondary LSP-Path
If multiple standby secondary paths exist, the most stable path - that is, the one with the highest uptime - is
selected.
If no standby secondary LSP-Paths are available, the non-standby secondary is signaled and used.
- If multiple non-standby secondary LSP-Paths exist, the first one in the configuration is signaled and used.
In default mode, the Head-End does not revert between secondary LSP-Paths, regardless of whether they have been
configured as standby or non-standby. The Head-End always tries to recover the primary.
Module 6 Page 43
In case of multiple non-standby secondary paths, the first one in

the order of configuration is used.
primary prim_path
exit
secondary Secondary-1
standby
exit
standby
exit
Traffic is on the primary LSP-Path.

Two standby secondary LSP-Paths are
available.
Module 6 |
44
The case study on this and the following four pages illustrates Head-End behavior, using default path-preference values
for standby secondary LSP-Paths.
An LSP is configured with a primary LSP-Path and two standby secondary LSP-Paths.
One of the secondary LSP-Paths comprises four hops and the other, six hops.
Both secondary LSP-Paths are established with the primary.
Module 6 Page 44
Default Secondary LSP-Path Selection Initial Condition
primary prim_path
exit
standby
exit
standby
exit
Primary goes down.

The standby secondary LSP with the longest
uptime is made active.
Module 6 |
45
The primary LSP-Path experiences link failure between R4-R6.

Router R1 activates the secondary LSP-Path with the longer uptime, Secondary-1. The decision is based solely on the
uptime value; it was not influenced by the metric values of the LSP-Paths. Secondary-2 would have been the active path
if it had had the higher uptime value, despite its longer path and higher metric value.
The next case study will introduce path-preference values that can modify this selection process.
Module 6 Page 45
Default Secondary LSP-Path Selection Primary Down
primary prim_path
exit
standby
exit
standby
exit
The active secondary goes down.

Router R1 switches the traffic to the
other standby secondary.
Module 6 |
46
Secondary-1 also goes down because of a failure on the link between R3-R5. At this point, both the primary and
Secondary-1 are down.
Router R1 determines whether another secondary path is available. Secondary-2 is also established, so the traffic is
switched to it.
Module 6 Page 46
Default Secondary LSP-Path Selection Standby-1 Down
primary prim_path
exit
standby
exit
standby
exit
The previously active standby secondary

comes back up.
Router R1 does not switch the traffic back to
it.
Module 6 |
47
The link failure between R3-R5 is removed and Secondary-1 is re-established. It offers a better forwarding path than
Secondary-2, with its 4 hops against 6, but the Head-End does not return to Secondary-1. The traffic remains on
Secondary-2.
Module 6 Page 47
Default Secondary LSP-Path Selection Standby-1 Recovered
Default Secondary LSP-Path Selection Primary Recovered
primary prim_path
exit
standby
exit
standby
exit
Primary LSP-Path comes back.

Router R1 switches the traffic back to the
primary.
Module 6 |
48
The link failure between R4-R6 is removed, and the primary path is re-established.
Router R1 switches the traffic back to the primary LSP-Path.
The standby secondary LSP-Paths remain established, readily available for the next failure.
Module 6 Page 48
Secondary LSP-Path Selection Using Path-Preferences
A path-preference can be defined for standby secondary LSP Paths.

This is not applicable for non-standby secondary LSP-Paths.
Possible values are from 1 to 255.
The lower the configured value, the more preferable the LSP-Path.
The selection is preemptive: If a standby secondary comes up with
a better preference, it becomes the active LSP-Path.
Module 6 |
49
With path-preference, standby secondary LSP-Paths can be assigned preference values, between 1 and 255.
The lower the numerical value assigned, the higher the preference for the LSP-Path.
The default path-preference value for secondary LSP-Paths is 255.
Path-preference values take precedence over uptime values.
As a result, the standby secondary LSP-Path with the optimal forwarding path can be configured to receive priority over
all other secondary paths, regardless of uptime values.
Furthermore, if a standby secondary LSP-Path with a better path-preference value becomes available, traffic is
switched to that path.
Module 6 Page 49
Default value: 255
primary prim_path
exit
standby
path-preference 10
exit
standby
path-preference 20
exit
Traffic is on the primary LSP-Path.

Two standby secondary LSP-Paths are
available with different path preferences.
Secondary-2 least preferred path.
Module 6 |
50
The case study example on this and the following four pages illustrates Head-End behavior, using custom pathpreference values for standby secondary LSP-Paths.
An LSP is configured with a primary LSP-Path and two standby secondary LSP-Paths.
Secondary-1 is configured with a lower (better) path-preference value than Secondary-2, because it goes through a
shorter path. The operator decides that Secondary-1 will be the active forwarding path, if the primary LSP-Path is
down.
Module 6 Page 50
Standby Secondary Path Preference Initial Condition
Standby Secondary Path Preference Primary Down
primary prim_path
exit
standby
path-preference 10
exit
standby
path-preference 20
exit
Primary goes down.

Router R1 selects the standby secondary
path with the lower path preference.
Module 6 |
51
The primary LSP-Path experiences link failure between R4-R6.

Router R1 activates Secondary-1, which has the lower path-preference value.
Module 6 Page 51
primary prim_path
exit
standby
path-preference 10
exit
standby
path-preference 20
exit
The active secondary goes down.

Router R1 switches the traffic to the
other standby secondary.
Module 6 |
52
Secondary-1 also experiences link failure between R3-R5. Now both the primary and Secondary-1 are down.
Router R1 determines whether another secondary path is available. Secondary-2 is also established, so the traffic is
switched to it.
Module 6 Page 52
Standby Secondary Path Preference Standby-1 Down
primary prim_path
exit
standby
path-preference 10
exit
standby
path-preference 20
exit
The secondary with the lower precedence

comes back up.
Router R1 switches the traffic back to it.
Module 6 |
53
The link failure between R3-R5 is removed and Secondary-1 is re-established. Router R1 reverts to Secondary-1 because
that path has a lower path-preference value.
This behavior is different from actions taken with default path-preference values.
Module 6 Page 53
Standby Secondary Path Preference Standby-1 Recovered
Standby Secondary Path Preference Primary Recovered
primary prim_path
exit
standby
path-preference 10
exit
standby
path-preference 20
exit
Primary LSP-Path comes back.

Router R1 switches the traffic back to the
primary.
Module 6 |
54
The link failure between R4-R6 is removed and the primary is re-established.
Router R1 switches the traffic back to the primary LSP-Path.
Both standby secondary LSP-Paths remain established and readily available, in case of more failure.
Module 6 Page 54
Module 6 |
55
LAB 6 Section 6.1 Enabling Primary and Secondary LSP Tunnels
Module 6 Page 55
Maintaining Path Diversity with Secondary LSP-Paths
Care should be taken to avoid sharing links between the primary

and secondary LSP-Paths.
Possible methods to achieve path diversity are:

y Using Fully Strict Hop LSP-Paths
y Using Admin Groups
y Using Shared Risk Link Groups
Module 6 |
56
The network operator must ensure that primary and secondary LSP-Paths follow diverse paths through the network.
This becomes especially important with standby secondary LSP-Paths, where traffic must be switched rapidly in case of
a primary LSP-Path failure. Furthermore, if a secondary LSP-Path shares links with a primary path, and failure occurs on
those links, both LSP-Paths can go operationally down and cause undesired traffic outage.
There are several options available to maintain path diversity, including using fully strict hop LSP-Paths, or
Administrative Group or Shared Risk Link Group definitions. The choice depends mainly on the network topology, traffic
type, or administrative requirements.
Several case study examples are covered in the following pages to illustrate the use of these different options.
Module 6 Page 56
Multiple alternative solutions can exist, depending on the

topology, administrative configuration, and so on.
Using Fully Strict Hop Path Definitions for Path Diversity
--------------------------path prim_path"
--------------------------path sec_path"
to 10.10.10.6
primary prim_path
exit
no shutdown
exit
no shutdown
exit
--------------------------lsp "to_R6
secondary sec_path
exit
The primary and secondary LSP-Paths can be configured with fully

strict hops.
Higher administrative control Create exact, pre-determined paths
for data flow.
Less flexibility The LSP paths cannot be established if one of the
strict hops go down.
Can be hard to manage and scale on a large network.
Module 6 |
57
Strict hop configurations provide the ability to make exact, pre-determined path definitions. This way, operators can
guarantee the paths the LSP-Paths will take. Although this approach is feasible in many cases, it can present certain
disadvantages in other situations, particularly in large, scaled networks. For example:
Scalability: The explicit hop definitions may introduce huge operational overhead in large networks, as a vast
number of paths and hops may have to be configured.
Flexibility: Hop lists can be affected by network topology changes. Adding or removing routers in the topology can
make a path list invalid, which would require a re-definition of the path. This will bring additional configuration
and management overhead.
Manageability: With the increase in the size of LSPs and path definitions, paths can become difficult to maintain
and troubleshoot in a large network.
Module 6 Page 57
no shutdown
exit
--------------------------path prim_path"
--------------------------path sec_path"
no shutdown
exit
no shutdown
exit
Module 6 |
58
Strict hop path definitions are more practical in a small topology with a limited number of redundancy options.
In the example above, router R1 has only two possible paths to reach router R6.
A primary LSP-Path is configured with strict hops, following the path R1-R2-R4-R6.
A secondary LSP-Path is also configured with strict hops, following the path R1-R3-R5-R6.
This can provide the path diversity required in this small scale topology.
Module 6 Page 58
Primary and Secondary Using Fully Strict Hop Paths
Using strict hops, the LSP-Paths must go through the specified hops.
Alternative links cannot be utilized in case of failure (unless Fast
Reroute is in place; covered in Section 3).
Module 6 |
59
A fully strict hop LSP-Path is a fixed definition. If one of the links along the path fails, the LSP-Path will remain down
until the failure is removed.
In the figure above, two routers are added to the previous topology, which increases redundancy in the upper and lower
paths. This brings further resilience against failures, as well as the ability to work with other administrative constraints,
such as bandwidth reservations.
If strict hop definitions are used, the LSP-Paths cannot make use of the available redundant paths.
Note that a solution exists, even with strict hop path definitions, that makes use of the redundant paths. Two
additional secondary LSP-Paths can be added and configured with strict hops to utilize the redundant paths. However,
this would result in more configuration and signaling overhead.
Fast Reroute offers an alternative solution to make use of the redundant links in the topology; it is covered in Section 3.
Module 6 Page 59
Unutilized Links Using Strict Hop Paths
In this example, redundant links in the upper and lower planes are
assigned to different administrative groups.
Primary and secondary LSP Paths can be configured with loose hops
that exclude either one of the groups.
Module 6 |
60
Recall the administrative group concept that was introduced in Module 5. Secondary LSP-Path protection is a good
example of the application of administrative groups.
In the case study above, the redundant links in the upper and lower portions of the network topology are made
members of administrative groups UPPER and LOWER.
Using exclude statements, the different LSP-Paths may be forced to avoid certain group of links in either portion of
the path.
Note: Other design solutions are possible, such as coloring the entire upper and lower planes in different groups and
using include statements.
Module 6 Page 60
Path Diversity Example Using Administrative Groups
Using Administrative Groups for Path Diversity
-------------------------------admin-group UPPER 1
interface "toR4"
admin-group UPPER"
exit
interface toR7
admin-group UPPER
exit
-------------------------------admin-group LOWER 2
interface "toR5"
admin-group LOWER"
exit
interface toR8
admin-group LOWER
exit
The redundant links in the upper plane are members of the

administrative group UPPER.
The redundant links in the lower plane are members of the
administrative group LOWER.
Module 6 |
61
On router R2, links R2-R4 and R2-R7 are members of administrative group UPPER.
On router R7, link R7-R4 is a member of administrative group UPPER.
On router R3, links R3-R5 and R3-R8 are members of administrative group LOWER.
On router R8, link R8-R5 is a member of administrative group LOWER.
Recall that the administrative group definitions can be asymmetrical; that is, they do not have to match on each end of
a link.
If symmetric operation is desired, similar configurations in the opposite direction of traffic flow (right-to-left) can
provide similar functionality on the adjacent routers.
Module 6 Page 61
The following configurations are examples of routers with links

that are members of the administrative groups:
Configuring LSP-Paths with Administrative Constraints
The following configuration is done at the Head-End router of the

LSP, router R1 in this example:
-------------------------------lsp "to_R6
to 10.10.10.6
cspf
primary fully_loose-1
exclude LOWER
exit
secondary fully_loose-2
exclude UPPER
exit
no shutdown
exit
Other design solutions, using administrative groups, are possible

(using include, exclude and so on).
Module 6 |
62
The administrative group name-to-value associations are done at the Head-End router. This creates the link between
the group names in the LSP configuration and the group values in the TED.
Two different fully loose path definitions are created with no specific hops, since a path name can be used only once
within an LSP configuration.
One of the path definitions is configured as a primary LSP-Path, and CSPF must calculate a path that avoids links in the
LOWER administrative group.
The other path definition is configured as a secondary LSP-Path, and CSPF must calculate a path that avoids links in the
UPPER administrative group.
Module 6 Page 62
-------------------------------admin-group UPPER 1
admin-group LOWER 2
path fully_loose-1
no shutdown
exit
path fully_loose-2
no shutdown
exit
Diverse LSP-Paths Using Administrative Groups
The primary LSP-Path can use any of the links in the upper plane.
The secondary LSP-Path can use any of the links in the lower
plane.
Module 6 |
63
The above slide illustrates the possible paths that the primary and secondary LSP-Paths can traverse.
The Primary LSP-Path can go through:
R1-R2-R4-R6
R1-R2-R7-R4-R6
Both path options avoid LOWER links.
The Secondary LSP-Path can go through:
R1-R3-R5-R6
R1-R3-R8-R5-R6
Both path options avoid UPPER links.
Module 6 Page 63
Using SRLG to Maintain Path Diversity with Secondary LSP-Paths
Using administrative groups, primary and secondary LSP-Paths can

use only a certain group of links.
The Shared Risk Link Group (SRLG) feature gives the primary path
freedom in making path decisions.
The rule for CSPF in this case is: Do not use any of the links that
are in the SRLG that the primary LSP-Path goes through.
When the path-preferences of multiple standby LSP-Paths are
equal, the SRLG-enabled standby LSP-Path(s) is preferred.
Module 6 |
64
Administrative groups bring flexibility because they provide path diversity while making use of redundancy in the
network.
However, they require that LSP-Paths use only a certain group of links defined by the constraints.
This can be limiting, especially when trying to use additional constraints, such as bandwidth reservation, for the
primary LSP-Path. Some links may be preferred, given the additional constraints, but the primary LSP-Path may not be
allowed to use them because of administrative group restrictions.
Shared Risk Link Groups (SRLG) add another dimension to establishing controlled redundant paths. SRLG allows the
operators to create secondary LSPs (or Fast Reroute protection tunnels) that are automatically disjointed from the
primary LSP-Path.
The primary LSP-Path is not bound by the SRLG constraint. CSPF can choose the optimal path for the primary LSP-Path,
taking into account any administrative constraints that might be in place. If any of the secondary LSP-Paths are
configured with SRLG constraint, CSPF analyzes the path that the primary LSP-Path is established on. CSPF determines
whether the links on the primary path are members of an SRLG, and then calculates a secondary LSP-Path that avoids
the links in the same SRLG.
SRLG also modifies the secondary LSP-Path selection criteria. When multiple standby secondary LSP-Paths share the
same path-preference value, the path that is established with an SRLG constraint is preferred over those without.
Module 6 Page 64
The secondary LSP-Paths are automatically disjoined from the

primary LSP-Path, if configured for SRLG.
In this example, redundant links in the upper and lower planes are
assigned to different Shared Risk Link Groups.
In general, SRLG memberships can also be defined according to
transmission (Layer-1) characteristics.
Module 6 |
65
The case study that was presented earlier for administrative groups is here modified to reflect Shared Risk Link Group
memberships. The redundant links in the upper and lower planes are now members of different SRLGs, as shown in the
figure above.
The main idea behind SRLG is that links belonging to the same SRLG present the possibility of a shared risk. Examples
include links going through the same fiber optic channel, transmission facility, or router. A condition which causes the
failure of one of these links might impact multiple LSP-Paths in the same group.
Module 6 Page 65
Path Diversity Example using SRLG
Configuring Shared Risk Link Groups
The following configurations are examples of routers with links

that are member of the SRLGs:
-------------------------------srlg-group SRLG-L value 2
interface "toR5"
srlg-group SRLG-L"
exit
interface toR8
admin-group SRLG-L
exit
-------------------------------srlg-group SRLG-U value 1
interface "toR4"
srlg-group SRLG-U"
exit
interface toR7
srlg-group SRLG-U
exit
The redundant links in the upper plane are members of the SRLG
called SRLG-U.
The redundant links in the lower plane are members of the SRLG
called SRLG-L.
Module 6 |
66
On router R2, links R2-R4 and R2-R7 are members of SRLG-U

On router R7, link R7-R4 is a member of SRLG-U.
On router R3, links R3-R5 and R3-R8 are members of SRLG-L.
On router R8, link R8-R5 is a member of SRLG-L.
Module 6 Page 66
Configuring Secondary LSP-Path with SRLG Constraint
The following configuration is done at the Head-End router of the

LSP, router R1 in this example:
-------------------------------lsp "to_R6
to 10.10.10.6
cspf
exit
standby
srlg
exit
no shutdown
exit
CSPF avoids the links that the primary goes through when
calculating the secondary LSP-Path.
If it cannot avoid the primary path links, the secondary fails.
Module 6 |
67
The SRLG name-to-value associations are done at the Head-End router. This creates the link between the group names
in the LSP configuration and the group values in the TED.
The path definitions are the same as those in the previous administrative groups example. The exception is that the
primary LSP-Path is configured with no constraints. CSPF can choose any viable path for the primary.
The secondary LSP-Path is configured with an additional SRLG constraint. After the primary LSP-Path is established,
CSPF will calculate a secondary LSP-Path that avoids all links in the SRLG(s) that the primary LSP-Path traverses.
Module 6 Page 67
-------------------------------srlg-group SRLG-U value 1
srlg-group SRLG-L value 2
path fully_loose-1
no shutdown
exit
path fully_loose-2
no shutdown
exit
The primary LSP-Path traverses the upper plane.

The SRLG-enabled secondary LSP-Path automatically avoids the links
that are members of the SRLG-U group.
Module 6 |
68
The primary LSP-Path is established over the R1-R2-R4-R6 path, in the upper plane.
The R2-R4 link is a member of SRLG-U. Therefore, CSPF prunes all the links that are in the same SRLG when
calculating a path for the secondary. The secondary LSP-Path is established over the R1-R3-R5-R6 path, in the lower
plane.
Module 6 Page 68
SRLG Example Primary with No Constraints
bandwidth 400
least-fill
exit
srlg
exit
Primary LSP-Path goes over the lower plane

because of bandwidth constraints.
Secondary LSP-Path avoids the links in the
lower plane.
Module 6 |
69
In this second variation of the case study, the primary LSP-Path is configured with 400 Mbps of bandwidth reservation
constraint. CSPF determines that this bandwidth is available on the lower plane and establishes the primary over the
R1-R3-R5-R6 path. Accordingly, the secondary LSP-Path is automatically disjointed from the links in the SRLG-L group.
Module 6 Page 69
SRLG Example Primary with Bandwidth Least-Fill Constraint
Verifying Secondary LSP-Paths
The LSP is operationally up as long as one of the configured LSPPaths is up:

A:R1# show router mpls lsp
===============================================================================
LSP Name
To
Fastfail
Adm
Opr
Config
------------------------------------------------------------------------------to_R6
10.10.10.6
No
Up
Up
-------------------------------------------------------------------------------
In case of a non-standby secondary:

A:R1# show router mpls lsp toR6 path
------------------------------------------------------------------------------LSP Name
: to_R6
To
: 10.10.10.6
Adm State
: Up
Oper State : Up
------------------------------------------------------------------------------Path Name
Next Hop
Type
Out I/F
Adm Opr
------------------------------------------------------------------------------prim_path_loose
10.1.3.3
Primary
1/1/3
Up
Up
sec_path_loose
n/a
Secondary n/a
Up
Dwn
===============================================================================
Module 6 |
70
For an LSP to be in an operationally up state, at least one of its LSP-Paths must be up.
In case of a standby secondary path, the secondary can be up, in addition to the primary.
In case of a non-standby secondary path, the secondary can be down, while the primary is up.
Recall that in either case, only primary LSP-Path is active and carrying the LSP traffic.
Module 6 Page 70
Verifying Standby Secondary LSP-Paths
A:R1# show router mpls lsp toR6 path

------------------------------------------------------------------------------LSP Name
: to_R6
To
: 10.10.10.6
Adm State
: Up
Oper State : Up
------------------------------------------------------------------------------Path Name
Next Hop
Type
Out I/F
Adm Opr
------------------------------------------------------------------------------prim_path_loose
10.1.3.3
Primary
1/1/3
Up
Up
sec_path_loose
10.1.2.2
Secondary 1/1/4
Up
Up
sec_path_strict
10.1.2.2
Secondary 1/1/4
Up
Up
===============================================================================
To verify the active LSP-Path (the one forwarding traffic):

A:R1# show router mpls lsp "to_R6" activepath
===============================================================================
MPLS LSP: to_R6 (active paths)
===============================================================================
LSP Name
: to_R6
LSP Id
: 47620
Path Name
: prim_path_loose
Active Path : Primary
To
: 10.10.10.6
Module 6 |
71
The first command output above illustrates that three LSP-Paths are up at the same time for the given LSP.
The command output in the second figure shows that only one of the LSP-Paths - the primary LSP-Path - is active and
carrying the LSP traffic.
Module 6 Page 71
Standby secondary paths are signaled together with the primary:
Standby Secondary LSP-Path Details
The detailed Secondary LSP-Path CLI output:

------------------------------------------------------------------------------LSP Name
: to_R6
Path LSP ID : 47624
From
: 10.10.10.1
To
: 10.10.10.6
Adm State
: Up
Oper State : Up
Path Name
: fully_loose-2
Path Type
: Standby
Path Admin : Up
Path Oper
: Up
OutInterface: 1/1/4
Out Label
: 131065
. . . . . . . . . . . . .
. . . . . . . . . . . . .
Preference : 10
Bandwidth
: No Reservation
Oper Bw
: 0 Mbps
. . . . . . . . . . . . .
. . . . . . . . . . . . .
Actual Hops :
10.1.2.1(10.10.10.1)
Record Label
: N/A
-> 10.1.2.2(10.10.10.2)
Record Label
: 131065
-> 10.2.4.4(10.10.10.4)
Record Label
: 131065
-> 10.4.6.6(10.10.10.6)
Record Label
: 131064
ComputedHops:
10.1.2.1
-> 10.1.2.2
-> 10.2.4.4
-> 10.4.6.6
Srlg
: Enabled
SrlgDisjoint: True
Module 6 |
72
The detailed secondary LSP-Path CLI output are displayed in the above slide.
Path Type indicates that the secondary LSP-Path is configured in standby mode.
Path Oper indicates that the LSP-Path is operationally up.
Preference indicates the custom path-preference value configured for the LSP-Path.
Srlg indicates that the SRLG constraint is enabled for the secondary LSP-Path.
SrlgDisjoint indicates that the secondary LSP-Path is successfully disjointed from the primary LSP-Path.
Module 6 Page 72
A:R1# show router mpls lsp "to_R6" path fully_loose-2 detail
RSVP Sessions for Standby Secondary paths
A separate RSVP session exists for each standby secondary LSPPath, resulting in more resource use:
===============================================================================
RSVP Sessions
===============================================================================
From
To
Tunnel LSP
Name
State
ID
ID
------------------------------------------------------------------------------10.10.10.1
10.10.10.6
155
47620 to_R6::fully_loose-1
Up
10.10.10.1
10.10.10.6
155
Up
10.10.10.1
10.10.10.6
155
Up
------------------------------------------------------------------------------Sessions : 3
===============================================================================
The primary and secondary LSP-Paths share the same Tunnel ID.
The primary and secondary LSP-Paths have different LSP IDs.
Module 6 |
73
Standby secondary LSP-Paths are established with the primary LSP-Path, for maximum resiliency.
This can also be verified in the show router rsvp session command output.
The output indicates that all the LSP-Paths belonging to the same LSP share the same Tunnel-ID. They are identifiable
by their LSP IDs.
Module 6 Page 73
*A:R1# show router rsvp session
Module 6 |
74
LAB 6 Section 6.2 Using SRLG for Path Resiliency
Module 6 Page 74
Section Summary
Secondary LSP Path Selection rules, using:

y Default path-preference values
y Customized path-preference values
Maintaining LSP Path Diversity, using:
y Strict Hop LSP Path Definitions
y Administrative Groups
y Shared Risk Link Groups
Module 6 |
75
Secondary LSP-Paths can be configured in two modes:

Standby secondary paths that are established with the primary.
Non-standby secondary paths that are established only after a failure on the primary.
A primary LSP-path is always preferred over a secondary LSP-Path.
Path selection criteria depends on whether custom path-preference values are defined for the secondary LSP-Paths
and their standby/non-standby statuses.
LSP path diversity helps operators attain maximum redundancy, and can be achieved via the following methods:
Strict hop definitions - provide exact, pre-determined path designations; added administrative overhead and
less flexibility.
Administrative group definitions - enable classification of links to be used for different LSP-Paths; increased
flexibility over strict hop definitions; fixed associations for links.
SRLG definitions - allow CSPF to make path decisions for the primary; secondary LSP-Paths are automatically
disjointed from the links in the same SRLG(s) as the primary path.
Module 6 Page 75
MPLS resiliency, using:

y Standby Secondary Paths
y Non-Standby Secondary Paths
Module 6 Resiliency
Section 3 MPLS Fast Reroute
Module 6 Page 76
Section Objectives

Introduce Fast Reroute (FRR)
Understand FRR signaling requirements
Define FRR operational modes

y One-to-one (detour paths)
y Facility (bypass tunnels)
Define FRR protection types
y Node protection
y Link protection
Explain establishing and using FRR protection tunnels
Discuss LSP Global Revertive Behavior
Module 6 |
77
This section explains the RSVP-TE Fast Reroute protection mechanism.

The signaling requirements and protocol enhancements to creating automatic Fast Reroute protection tunnels are
described, including the Fast Reroute, Detour, and Record Route Objects.
There are several Fast Reroute configuration options available to operators. The operational principles behind the use
of these modes and types are explained.
All of the concepts are illustrated with several case study examples.
Module 6 Page 77
Identify the options used in RSVP messaging to facilitate FRR (RRO,

FRR object, Detour object)
Fast Reroute Overview
MPLS Fast Reroute (FRR) defines ways of automatically establishing

protection paths before a failure.
Allows for sub-50ms failover after link failure detection.
Applicable for LSPs established using RSVP-TE.
Allows protection to be applied as close to the point of failure as
possible.
Module 6 |
78
Network operators expect their networks to be robust and to converge as quickly as possible after a failure. To meet
these demands, the RSVP-TE protocol has been enhanced so that protection tunnels for primary LSP-Paths can be
automatically established.
Recall how secondary LSP-Path protection can be used to provide LSP resilience. One advantage of using secondary LSPPath protection is the high administrative control given to network operators, who can determine the paths of the
secondary protection LSP-Paths. Another benefit is that a secondary LSP-Path protects the entire primary LSP-Path,
end-to-end. Regardless of the number and nature of failures along the primary LSP-Path, the secondary LSP-Path is able
to assume the traffic forwarding responsibilities.
A major disadvantage of secondary LSP-Path protection, however, is its potential operational complexity, the result of
managing a large number of manual path definitions.
Fast Reroute helps to reduce this configuration overhead with automatic path calculation and signaling capabilities. It
also allows the MPLS router closest to the point of failure to recover the traffic. This can improve convergence times
over secondary path protection.
With Fast Reroute, one protection tunnel can be used to protect multiple primary LSP-Paths, as long as they have
shared path segments. This comes with the use of the facility bypass method and helps to reduce the signaling and
session maintenance overhead in the network. The CSPF algorithm that was presented earlier plays an integral role in
the calculation of protection tunnels.
Fast Reroute is applicable for primary LSP-Paths of LSPs signaled by RSVP-TE.
Module 6 Page 78
CSPF plays an important role.
FRR Protection Methods
There are two methods of FRR protection.

y One-to-One Backup
y Facility Backup
The protection method needs to specified in the configuration of

the protected LSP.
FRR can only protect the primary LSP-Path of an LSP.
Module 6 |
79
When an LSP is configured with a Fast Reroute protection request, the operational mode - one-to-one OR facility - must
also be specified in configuration. These modes are mutually exclusive for an LSP; only one mode can be used at any
given time. The characteristics of and differences between these modes are explained in the following pages.
Even though Fast-Reroute is enabled at an LSP level, it is only available for the primary LSP-Path. Secondary LSP-Paths
cannot be protected by Fast Reroute.
If the protection mode is not specified in the LSP Fast Reroute configuration, one-to-one is assumed by default.
Module 6 Page 79
Each LSP can use only one method.
Fast Reroute One-to-One Protection Model
MP
All 3 LSPs go through the same path.

They all request Fast Reroute One-to-One.
A separate protection tunnel is established for each LSP.
The protection tunnel for one-to-one is called a Detour.
Module 6 |
80
In the one-to-one FRR protection mode, each LSP-Path requiring one-to-one backup has a protection tunnel signaled and
dedicated to protect only that LSP-Path. The backup that is signaled is called a detour.
In the figure above, three LSPs are established and each is configured with a one-to-one FRR protection request. As a
result, router R2 calculates and signals a detour tunnel for each of these primary LSP-Paths.
Should there be link failure between R2-R3, the traffic from each primary LSP-Path is rerouted over its designated
detour.
Module 6 Page 80
PLR
Fast Reroute Facility Protection Model
MP
All 3 LSPs go through the same path.

They all request Fast Reroute Facility.
They can all be protected with the same protection tunnel.
The protection tunnel for facility is called a Bypass Tunnel.
Module 6 |
81
If facility Fast Reroute protection is required, a common bypass tunnel can be used to protect multiple primary LSPPaths. This allows resources to be shared more effectively.
In the figure above, one of the LSP-Paths is configured with facility FRR request. A bypass tunnel is created on router
R2, in response to this request. If there is a failure of the link between R2-R3, traffic can be rerouted over this tunnel.
After the bypass tunnel is established, any LSP-Path that goes through the same link can also be protected by that
bypass tunnel.
Module 6 Page 81
PLR
FRR Protection Types
From a topological perspective, both one-to-one and facility

backup can protect different network elements:
y Node Protection Protects against the failure of the next
downstream router.
Possible configuration options for an LSP are:

y One-to-one node protection
y One-to-one link protection
y Facility node protection
y Facility link protection
Module 6 |
82
A Fast Reroute protection tunnel can protect against the failure of the next node or link along the primary LSP-Path.
Although node protection can provide extensive protection for multiple links, it is not always possible because of
topological constraints or administrative reasons.
Link protection is an alternative method that can cover such cases.
When an LSP is configured, the protection type should be indicated along with the protection mode. Node protection is
enabled, by default, and can optionally be disabled.
Module 6 Page 82
y Link Protection Protects against the failure of the link to the

next downstream router.
Fast Reroute Node Protection Model
The Primary LSP-Path has requested node protection.

Router R2 establishes a protection tunnel that detours around the
failed next downstream router, router R3.
Router R3 and all its links are avoided on the protection tunnel
path.
Module 6 |
83
The primary LSP-Path is configured with a Fast Reroute request and node protection is enabled (default).
After the primary LSP-Path is established, router R2 observes the request and signals a protection tunnel that avoids all
of the links that are attached to router R3.
This is the process regardless of the Fast Reroute mode that is in use (one-to-one or facility). More details regarding the
establishment of router protection tunnels, based on the FRR mode, will be discussed later in the section.
Module 6 Page 83
Next
next-hop
Fast Reroute Link Protection Model
The Primary LSP-Path has requested link protection.

Router R2 establishes a protection tunnel that detours around the
failed link to the next downstream router.
Only the link is avoided on the protection tunnel path.
Module 6 |
84
If router protection is disabled in the configuration, link protection is assumed.

After the primary LSP-Path is established, router R2 observes this configuration and signals a protection tunnel that
avoids only the next link attached to router R3.
This is the process regardless of the Fast Reroute mode that is in use (one-to-one or facility). More details regarding the
establishment of link protection tunnels, based on the FRR mode, will be discussed later in the section.
Module 6 Page 84
Next-hop
Node and Link Protection Types
The default method is node protection.
Node protection can be disabled in the LSP configuration

y In this case, the routers only attempt link protection.
Module 6 |
85
With either of the Fast Reroute modes (one-to-one or facility), node protection is enabled by default.
If node protection is enabled in the LSP Head-End configuration, all routers along the primary LSP-Path (except the TailEnd) attempt to establish protection tunnels that avoid the next router in the downstream direction.
However, this might not be possible every time because of topological constraints, or other reasons. If the first node
protection attempt is not successful, the router can make two more attempts to establish a node protection tunnel. If
the third attempt also fails, the router reverts to link protection.
Note: If the first link protection attempt also fails, the router can make up to two more attempts to establish a link
protection tunnel. If all of them fail, the router reverts back to node protection again. This process can go on
indefinitely until a protection path is found. As long as the Fast Reroute request is present on the primary LSP-Path, the
router continuously tries to establish a protection tunnel in this fashion.
Node-protection can be disabled in the LSP configuration. In this case, only link-protection is attempted by the routers.
Module 6 Page 85
If node protection is desired:

y A router may make up to 3 consecutive attempts to establish a
node protection tunnel.
y If this cannot be accomplished, as a result of topological or
other constraints, the router reverts to link protection.
Fast Reroute Router Roles
Routers play different roles in Fast Reroute protection.

Head-End Router Where the primary (protected) LSP-Path is
configured and where it originates.
Point of Local Repair (PLR) Where the protection tunnel

originates.
Merge Point (MP) Where the protection tunnel terminates and
merges into the original protected LSP-Path.
Module 6 |
86
In RSVP-TE Fast Reroute terminology, the routers along the protected primary LSP-Path can assume several roles,
depending on their location in the perspective of the protection tunnels.
Head-End and Tail-End terms refer to the originating and terminating points of an LSP-Path, as already described in
Module 4.
Point of Local Repair (PLR) refers to the originating point of a Fast Reroute protection tunnel.
Merge Point (MP) refers to the terminating point of a Fast Reroute protection tunnel.
Basically, all the routers along the LSP-Path (except the Tail-End) attempt to establish FRR protection tunnels
originating on them; making them all potential PLRs.
The Merge Point selection depends on the protection mode, type and the network topology under consideration. Several
case study examples are included later in the section to demonstrate these variations.
Module 6 Page 86
Tail-End Router Where the primary (protected) LSP terminates.
Point of Local Repair (PLR) is the router where the protection tunnel
originates. When the link fails, the LSP traffic is locally recovered at
this point.
Merge Point (MP) is the router where the protection tunnel
terminates and merges into the original LSP-Path.
Module 6 |
87
The above slide illustrates the Head-End, Tail-End, PLR, and MP concepts.
Router R1 is the Head-End router where the LSP is configured with FRR request.
In this simple topology, only router R2 has a redundant path available to perform FRR. Thus, it assumes the PLR role and
establishes a protection tunnel originating on itself.
Router R3 is the Merge Point where the protection tunnel merges back into the original LSP-Path.
Router R4 is the Tail-End router of the LSP, where the LSP terminates and the traffic is eventually delivered to.
Module 6 Page 87
PLR and MP Roles of Routers in FRR
Fast Reroute LSP-Path and CSPF Requirements
This can be accomplished in several ways:

y A path with fully strict hops (CSPF need not be enabled)
y A path with loose hops (CSPF must be enabled)
y A path with a mixture of strict and loose hops (CSPF must be
enabled)
For a primary LSP-Path that has:
y Loose hops in path definition,
y Fast-Reroute enabled,
y CSPF disabled,
the LSP does NOT come up with failure code looseHopsInFRRLsp
Module 6 |
88
Must CSPF be enabled in the LSP configuration for Fast Reroute to work?
The answer to this question depends on the path definition. To generalize, the Head-End requires that the entire path
with all the individual hops be known prior to signaling the LSP-Path with an FRR request. There are several ways to
achieve this:
If the primary LSP-Path is configured only with strict hops, define the entire path end-to-end; Fast Reroute still
works even if CSPF is not enabled. Protection tunnels are established on every possible PLR and traffic is switched
to it in case of a failure. However, an implication of disabling CSPF is that Global Revertive will not work at the
Head-End, if reverting from a failure. Global revertive is discussed in detail at the end of the section.
If the primary LSP-Path consists of one or more loose hops, CSPF must be enabled in case Fast Reroute protection is
also enabled. CSPF calculates the intermediate hops to reach a certain loose hop, and gives the Head-End visibility
over the entire LSP-Path before signaling it.
Module 6 Page 88
For Fast Reroute to function, the Head-End needs to know the

exact path of the LSP-Path before signaling it.
Fast Reroute Configuration Requirements
Fast Reroute is only configured on the LSP Head-End.

All routers along the primary LSP-Path are required to
automatically establish protection tunnels, based on the
configured method and type.
Module 6 |
89
Configuration of Fast Reroute is a fairly easy task, as opposed to the amount of time and effort required to explain and
understand its operation.
The request to create Fast Reroute protection tunnels is indicated in the LSP configuration at the Head-End, together
with the desired protection mode and type.
This request is signaled to all the routers along the primary LSP-Path within the RSVP PATH message. As a result, all the
available routers assume PLR roles and automatically start the process of calculating and establishing FRR protection
tunnels. No extra configuration is required on any of the routers.
Module 6 Page 89
No extra configuration required on the other routers.
Configuring an LSP for Fast Reroute One-to-One
-------------------------------path fully_loose
no shutdown
lsp "to_R4
to 10.10.10.4
cspf
fast-reroute one-to-one
exit
no shutdown
exit
One-to-one is the default method.

Node-protect is enabled by default.
If the path definition contains loose hops, CSPF needs to be
enabled.
Module 6 |
90
The above slide illustrates example configuration to enable Fast Reroute with one-to-one router protection.
Since the path definition is empty (fully loose) and FRR is enabled, CSPF needs to be enabled in the LSP configuration.
The following pages describe the actions that are taken after the LSP is enabled with this Fast Reroute request, step-bystep. The signaling requirements to trigger these actions are also described.
Module 6 Page 90
node-protect
primary fully_loose
Fast Reroute Signaling Requirements
The RSVP-TE protocol was extended to allow for the automatic

signaling of the protection tunnels.
Introduces two objects:

y Fast_Reroute Object
y Detour Object (only for one-to-one method)
The new objects are also carried in the RSVP PATH messages.
Module 6 |
91
In order to allow for the automatic signaling of Fast Reroute protection tunnels, certain configuration and operational
information need to be conveyed to the other routers. This is accomplished by introducing the new Fast_Reroute and
Detour objects inside the RSVP PATH messages, as defined by RFC 4090.
The description and use of these objects are provided separately in the following pages.
Module 6 Page 91
Defined in RFC 4090.
Signaling the FRR Options
When Fast Reroute is enabled on an LSP, the Head-End includes an

additional Fast_Reroute object in the PATH message.
In the Session_Attribute object of the PATH message, the router

also indicates the following flags:
y local-protection-desired
y node-protection-desired (unless disabled in configuration)
Module 6 |
92
The Fast_Reroute object is mainly used to convey the configuration information regarding the FRR options, as they are
configured at the Head-End of the LSP.
The Fast_Reroute object is included in the RSVP PATH message sent from the Head-End to signal the primary LSP-Path.
The most significant of the options that are signaled is the FRR type, which can be one-to-one or facility.
The Session_Attribute object is always included in the PATH messages, even without FRR. When FRR is enabled, the
local-protection-desired flag indicates that the receiving routers are supposed to establish FRR protection tunnels. In
addition, the protection type is indicated with the node-protection-desired flag set, if it is enabled (by default, router
protection is enabled).
Module 6 Page 92
The protection method is signaled in the Flags field of the

Fast_Reroute object:
y One-to-one (0x01)
y Facility (0x02)
LSP is configured for Fast Reroute with:

y One-to-One
y Node Protection
Module 6 |
93
The example above illustrates the options signaled in the RSVP PATH message sent from the Head-End to establish the
primary LSP-Path.
Module 6 Page 93
Signaling the FRR Options in the PATH message
After the LSP is enabled, primary LSP-Path is signaled first.

Fast Reroute protection is not attempted yet.
Module 6 |
94
A sequence of events follow after enabling the LSP with Fast Reroute request.
The first task is to enable the primary LSP-Path. This is done by the usual forwarding of RSVP PATH and RESV messages.
The routers will attempt to establish the Fast Reroute tunnels after the LSP is successfully established and verified.
Module 6 Page 94
Signaling the Primary LSP-Path
Timing for Fast Reroute Detour Creation
Routers wait for the second RESV (first refresh) message

calculating and signaling the detours.
This is to ensure that the primary LSP-Path is successfully
established end-to-end.
Module 6 |
95
The routers need to verify that the primary LSP-Path is successfully established, before they initiate the setup process
of protection tunnels. As explained in Module 4, LSPs are periodically refreshed after being established.
Accordingly, the first Reservation Refresh message received by a router serves as the trigger to start the pending FRR
process.
Module 6 Page 95
Protected Path
Calculating the Protection Tunnels
Protection tunnels are calculated locally on each PLR.

Calculation is done via the internal CSPF process on each PLR.
Traffic-Engineering must be enabled in the IGP of all the routers.
Module 6 |
96
Fast Reroute protection tunnels are calculated individually by each router assuming the Point of Local Repair (PLR) role.
Calculation is performed by the internal CSPF process embedded in each router. This requires that the Traffic
Engineering Database is readily available on all the routers.
Module 6 Page 96
Upon receipt of the second RESV message, all routers along the
primary LSP-Path (except the Tail-End):
y Assume the PLR (Point of Local Repair) role.
y Calculate separate protection tunnels that originate on
themselves, taking into account the protection method and type
(one-to-one and node-protect in this example)
Detour Calculation Overview
Upon receipt of the second RESV message, routers initiate the

detour calculation process individually.
The process may start at slightly different times on each router as
a result of session refresh time randomization (see Module 4).
Module 6 |
97
The second RESV message after initial establishment serves as a session refresh message to keep the LSP alive.
When a router receives the refresh message for the previously established primary LSP-Path, it initiates the pending
detour calculation process. As a result of the randomization introduced in the session refresh timers, as described in
Module 4, the detour calculation and establishment processes may start at slightly different times on each router.
While testing with Fast Reroute, establishing all the detours along the primary LSP-Path might take a while (mostly up
to 60-70 seconds) because of the reasons described above.
Module 6 Page 97
Protected Path
CSPF Calculation Constraints For FRR
The router just before the Tail-End always performs linkprotection (failure of the Tail-End router is catastrophic for the
LSP).
FRR protection tunnels do not follow any protected path
constraints other than Shared Link Risk Groups (srlg-frr option
needs to be enabled in the global MPLS context, if that is desired).
Module 6 |
98
The requirement for Fast Reroute can also be perceived as a constraint input for CSPF.
Using node-protection, CSPF on each PLR looks for the answer to the following question in the TED: What does the
topology look like without the next downstream router all of its network links?
Using link-protection, the question becomes: What does the topology look like without the link connected to the next
downstream router?
After executing the constraints, a protection tunnel can be calculated and established on the remaining topology.
Constraints, such as administrative groups or bandwidth reservation, are not taken into account when calculating the
FRR protection tunnels, although you can configure bandwidth constraints and hop limits on the detour tunnel.
SRLG concept can also be used for Fast Reroute, if the following system-wide configuration is enabled:
A:R1>config>router>mpls# srlg-frr [strict]
Strict: With the strict option, CSPF will not establish any FRR protection tunnel if there is no path that meets the
SRLG constraint.
Non-Strict: With the non-strict (default) option, if CSPF cannot find a path for the protection tunnel using the SRLG
constraint, it disregards the constraint and tries to establish a tunnel over links that are not complaint to SRLG.
Module 6 Page 98
When computing a protection path on a PLR, the constraints for

CSPF are:
y Node-protect To find a protection path for the primary LSP
that avoids the downstream node and all of its network links.
y Link-protect To find a protection path for the primary LSP
that avoids only the link connected to the downstream node.
The PLR evaluates the Traffic Engineering Database with CSPF.

Using node-protect, the resulting topology is calculated without
the downstream router and all of its network links.
Module 6 |
99
The above slide illustrates the resulting network topology after the CSPF process on router R1 prunes the links according
to the FRR node-protection constraint. The next router R2 and all its network links are pruned from the topology. A
calculation will be performed on the remaining links.
Module 6 Page 99
CSPF View of the Topology with Node-Protect
Merge Point for One-to-One Detour Tunnels
The termination point for a protection tunnel is called the Merge

Point (MP) router.
In other words, the MP is where the protection tunnel and
protected tunnel merge, or meet again.
For One-to-One protection, the detour tunnel terminates as near

to the Tail-End router of the protected LSP as possible.
In other words, the detour tunnel is calculated to the Tail-End,
using the shortest IGP path.
Module 6 |
100
After CSPF pruning, the next question is: Over which links should the protection tunnel be established, and on which
router should it terminate?. The router that the protection tunnel is terminated on and merged with the original
protected path becomes the Merge Point (MP).
The answer to the question above depends on the protection mode (one-to-one or facility) and the resulting network
topology.
Using one-to-one protection, CSPF calculates a path for the detour tunnel towards the Tail-End through the shortest IGP
path. In this case, the actual location of the Merge Point also depends on the topology conditions. Some examples are
included in the following pages to illustrate this.
Merge Point selection and tunnel calculation for Facility Protection will be explained later in the section.
Module 6 Page 100
The location of the MP for a protection tunnel depends on the

protection mode and the actual topology.
Using equal metric values for the links, the detour tunnel has been
calculated, as illustrated in the figure.
The Merge Point (MP) is router R4.
Module 6 |
101
For the topology in this first example, the best IGP path chosen by CSPF for the detour is as shown in the figure above.
The tunnel terminates on router R4, making router R4 the Merge Point for the detour.
Module 6 Page 101
Merge Point For One-to-One Detour Scenario 1
Using different metric values for the redundant links, as shown in

the figure, the detour tunnel from router R1 has terminated on a
different router (R3).
Module 6 |
102
If the metric values are tweaked as shown in the figure, the shortest IGP path towards the Tail-End changes to go over
router R3. In this case, router R3 assumes the Merge Point role for the detour.
Module 6 Page 102
Merge Point For One-to-One Detour Scenario 2
PATH Message for the Detour Tunnel
The PLR sends a separate RSVP PATH message to signal the detour
tunnel.
The detour tunnel uses the same Tunnel ID and LSP ID as the
original primary LSP-Path. This is to identify the association on all
the routers.
The LSP-Name field in the PATH message of the detour tunnel
takes the following format:
y <LSP-Name>::<Path-Name>_detour
y For example, to_R6::fully_loose_detour
Module 6 |
103
When a PLR router calculates a path for the detour, the hop information calculated by CSPF is inserted into the ERO of
the PATH message sent by the PLR. This PATH message is used to signal the detour.
As mentioned, in one-to-one protection, a separate detour tunnel is signaled for each requesting LSP. In this sense, the
detour tunnels are associated and identified with the original LSP-Paths that they are protecting.
This association is achieved by assigning the same Tunnel ID and LSP ID for the detour tunnels as their protected LSPPath. The difference lies in the LSP-Name given to detour tunnels. A _detour suffix is appended to the original LSPPath name to identify the detours.
Module 6 Page 103
The result of the CSPF calculation is included in the Explicit Route

Object (ERO) of the PATH message.
Detour Object used in the Detour PATH Message
A Detour Object is also included in the PATH message sent by the

PLR to signal the detour path.
Among other fields, the detour object contains:

y PLR ID: System IP address of the PLR
y Avoid_Node, depending on the protection mode:
Node protect: System IP address of the protected router
Link protect: The interface IP address of the protected
router
Module 6 |
104
Another enhancement made in the RSVP-TE protocol to support Fast Reroute is the Detour Object.
In one-to-one protection, multiple detours can be created by different PLRs protecting the same LSP.
Accordingly, multiple detours protecting the same LSP might be transiting or terminating on a certain router. The main
purpose of the Detour object is to distinguish between them.
The Detour Object is included in the RSVP PATH message to signal the detour path.
Module 6 Page 104
The detour object helps to distinguish the detour tunnels from

different PLRs.
Router 1 assumes the PLR role as well as Head-End for the LSP.
A PATH message is sent to establish the detour tunnel.
A detour object indicates that the tunnel from router R1 avoids
router R2.
Module 6 |
105
A truncated version of the RSVP PATH message sent by router R1 to signal the detour is shown above.
The ERO field contains the hops that are calculated by the PLR for the detour.
The Detour object indicates the PLR_ID as 10.10.10.1, which is the System IP address of router R1.
The Avoid_Node field indicates that the detour is created to avoid the next router for router R1, which is router R2,
with a System IP address of 10.10.10.2.
Module 6 Page 105
Signaling the Detour Tunnel PLR : R1
The detour tunnel is established and ready to protect the primary

LSP-Path.
A separate RSVP session is maintained on all routers along the
detour path.
Module 6 |
106
Router R1 is the originating router (PLR) for the detour signaled for the primary LSP-Path.
Router R4 is the terminating router, also named as the Merge Point (MP).
Routers R5, R6, R7, and R8 assume transit LSR roles for the detour.
RSVP sessions are created and maintained for the detour on all the participating routers. The session states are
maintained by periodic PATH and RESV messages over the detour path, as with a normal LSP.
Module 6 Page 106
Viewing the RSVP Sessions for One-to-One Detours
A:R1# show router rsvp session
It is possible to filter the command output, based on detour type:

y show router rsvp session detour (originating detours)
y show router rsvp session detour-transit (transiting detours)
y show router rsvp session detour-terminate (terminating
detours)
The detail keyword can be used with each command to see the
session details.
Module 6 |
107
The separate RSVP sessions created for the detours, as well as all the other sessions on the router, can be viewed in the
show router rsvp session command output.
In this example, two sessions are established on router R1. One of the sessions is for the protected primary LSP-Path
and the other session is for the detour associated with this LSP-Path.
The association can be clearly seen from this output, as indicated by the Tunnel ID, LSP ID, and LSP Name fields.
The command output can be filtered to display only the detour session status using the keywords displayed above.
If the detail keyword is used at the end of any of the mentioned commands, extensive information can be obtained
regarding the detours such as ingress/egress labels, total count of messages sent and received, and so on.
Module 6 Page 107
===============================================================================
From
To
Tunnel LSP
Name
State
ID
ID
------------------------------------------------------------------------------10.10.10.1
10.10.10.4
155
47620 to_R4::fully_loose
Up
10.10.10.1
10.10.10.4
155
47620 to_R4::fully_loose_detour
Up
------------------------------------------------------------------------------Sessions : 2
===============================================================================
Router R2 also assumes the PLR role.

Router R2 calculates and signals a detour path that avoids router
R3.
Module 6 |
108
Similar detour path calculation and establishment takes place on router R2, as described for router R1.
CSPF on router R2 prunes all the links that belong to router R3 and achieves the resulting topology as seen in the figure
above.
The detour is signaled and terminated on router R4.
Module 6 Page 108
Router 3 is also requested to perform node-protect by LSP HeadEnd.

Node-protection is not applicable to router R3.
Router 3 reverts to link protection.
Detour tunnel is established.
Module 6 |
109
The router just before the Tail-End always performs link protection, even if router protection is requested by router R1.
For obvious reasons, the failure of the Tail-End router is unrecoverable for the LSP.
Module 6 Page 109
RSVP Record Route Object (RRO)
Record Route Object (RRO) is included, by default, in RSVP PATH

and RESV messages.
Each router along the LSP-Path updates the RRO field.
RRO is used to track the exact path that an LSP-Path takes.
In the context of FRR, routers make special use of the RRO inside
the RESV message.
Labels are also recorded in the RRO of the RESV message.
Module 6 |
110
By default, the Record Route Object (RRO) is included in all the RSVP PATH and RESV messages used to establish and
refresh the LSPs. The RRO is populated by all the routers along the LSP-Path. It provides information about the interface
IP addresses and labels for all the hops along the path.
Having a recorded path information readily available is useful in Fast Reroute implementation, as explained in the
following pages.
Module 6 Page 110
Interface IP addresses are used.
The RRO is updated at each hop of the PATH message.

Each router adds its own IP address connecting to the downstream
router at the top of the list.
Module 6 |
111
When sending the PATH message, the Head-End router R1 inserts its own interface IP address (10.1.2.1) in the RRO list.
Router R2 adds its own address (10.2.3.2) to the top of the list, when forwarding the PATH message to router R3.
Router R3 does the same so that, eventually, router R4 has full visibility over the path that the RSVP PATH message has
traversed.
Module 6 Page 111
Record Route Object in the RSVP PATH Message
An RRO is also present in the RESV message.

Each router adds:
y Its interface IP address connecting to the upstream router
y The label allocated for the LSP
Module 6 |
112
A separate Record Route Object is inside the RSVP RESV messages.

The Tail-End router R4 adds its own interface IP address (10.3.4.4) and the label it reserved for the LSP-Path (400) in
the RRO list.
Router R3 receives the RESV message from router R4. It appends its own interface IP address (10.2.3.3) and the label it
reserved for the LSP to the top of the list.
Router R2 performs a similar operation and, eventually, router R1 has full visibility over the LSP-Path with label
reservation information.
Module 6 Page 112
Record Route Object in the RSVP RESV Message
Using the RRO to report FRR status
When a router successfully establishes a detour tunnel, it sets the

local-protection-available flag for its entry in the RRO of the next
RESV refresh message.
This gives the Head-End FRR status visibility over the entire
primary LSP-Path.
Module 6 |
113
One of the uses of the RRO in the Fast Reroute implementation is the reporting of protection tunnel status to the HeadEnd.
When a PLR router is able to successfully establish a protection tunnel, it sets the local-protection-available flag in
the following RESV refresh messages that it sends.
If node-protection was requested by the Head-End, and a node-protection tunnel is successfully established by the PLR,
the node-protection-available flag is also set. If a link-protection tunnel is established instead, then the flag value
remains at zero.
In the end, the Head-End router has full visibility of the routers and labels along the LSP-Path, as well as the tunnel
protection status on each router.
Module 6 Page 113
If it is able to establish a node protection tunnel, the router also

sets the node-protection-available flag.
Module 6 |
114
The above slide illustrates the reporting of protection tunnel process performed by all the PLRs.
Router R4 is the Tail-End router, and does not perform the PLR role.
Router R3 is able to establish a link protection tunnel and sets only the local protection available flag, which is
indicated with a @ symbol in the SR OS CLI.
Router R2 is able to establish a node protection tunnel and sets both the local protection available (@) and node
protection available (n) flags in the RESV refresh messages.
Module 6 Page 114
Viewing the FRR Status in CLI

A:R1# show router mpls lsp "to_R4" path detail
===============================================================================
Legend :
@ - Detour Available
# - Detour In Use
b - Bandwidth Protected
n - Node Protected
s - Soft Preemption
===============================================================================
. . . . . . . . . . . . .
. . . . . . . . . . . . .
10.1.2.1(10.10.10.1) @ n
-> 10.1.2.2(10.10.10.2) @ n
-> 10.2.3.3(10.10.10.3) @
-> 10.3.4.4(10.10.10.4)
Record
Record
Record
Record
Label
Label
Label
Label
:
:
:
:
N/A
200
300
400
ComputedHops:
10.1.2.1
-> 10.1.2.2
-> 10.2.3.3
-> 10.3.4.4
The Actual Hops field is extracted from the RRO of RESV message
(except the first hop, which is the Head-End router itself).
The FRR status of each router is included in the output.
NOTE: The label values shown above are not actual SR OS generated labels.
Module 6 |
115
The RRO is visible in the Actual Hops field of the show router mpls lsp <lsp-name> path detail command
output.
Note that the label values shown in the example above are simplified values, used for demonstration purposes. The
actual values should be in the dynamic label range between 32,768 and 131,071.
Module 6 Page 115
Actual Hops :
Detour Merging
With FRR one-to-one protection, each router creates a separate

detour tunnel for each protected LSP.
This can lead to a large number detour tunnels in the network.
Detour Merging was introduced in RFC 4090 to help the issue.
The router that performs the merging operation is called a Detour

Merge Point (DMP).
A single PATH message, consisting of a list of the detour objects of
the merged detour tunnels, is sent beyond the DMP.
Detour Merging is a default response and cannot be disabled.
Module 6 |
116
An optimization made in the Fast Reroute One-to-One backup implementation is Detour Merging.
The high number of detour tunnels established for each protected LSP can present considerable signaling and processing
overhead in a scaled network. To help reduce the load, RSVP 4090 allows multiple detour tunnels to merge on a router,
if they protect the same LSP-Path, and if they egress on the same link.
This means that the information in Detour Objects present in all the common detours is merged into a single PATH
message sent over the egress link.
Detour Merging is the default implementation mode on the Alcatel-Lucent Service Routers; there is no configuration
option to disable it.
Module 6 Page 116
If multiple detour tunnels protecting the same LSP-Path use the

same outgoing link on a router, they are merged.
Router R1 signals a detour tunnel to

protect the LSP from a router R2
failure.
The detour goes through router R6.
Module 6 |
117
A case study is presented on this and the following pages to illustrate the Detour Merging concept.
Router R1 establishes a node protection detour tunnel that avoids the next router, R2. This information is visible in the
Detour Object of the PATH message sent by router R1.
The Tunnel_ID, LSP_ID, and Name fields are also indicated to emphasize the resemblance with the other detour path
messages in the following pages.
The attention should be focused on router R6 in the following page, as another detour will transit through it.
Module 6 Page 117
Detour Merging Example First Detour Tunnel Setup
The detour from

router R1 is already
established.
The detour from router

R2 is terminated on
router R6.
The single PATH
message sent to router
R7 contains both
detour objects.
Module 6 |
118
The detour calculated by router R1 is already established, as described on the previous page.
Assuming the PLR role, router R2 also calculates a detour and sends a PATH message to signal it. The Tunnel_ID, LSP_ID,
and LSP_Name fields are identical to those of the detour originated by router R1. This is a clear indication that both
detours are protecting the same LSP-Path. The detour originated by router R2 will also egress on the interface R6-R7.
Realizing this fact, router R6 terminates the detour from router R2 on itself and sends a single PATH message to router
R7.
The Detour Object included in the PATH message sent to router R7 contains the PLR_ID and Avoid_Node fields from both
merged detours.
Router R6 is named as a Detour Merge Point in the RFC terminology, after the merge operation.
Module 6 Page 118
Detour Merging on Router R6
The detour from router R3 is

terminated on router R7.
The single PATH message sent to
router R8 contains both detour
objects from routers R2 and R3.
Module 6 |
119
A similar merging process occurs on router R7 as well, as illustrated in the figure above.
The link protection detour originated by router R3 is terminated on router R7 and merged with the detour PATH
message received from router R6.
Router R7 is also named as a Detour Merge Point after the merge operation.
Module 6 Page 119
Detour Merging on Router R7
Traffic is forwarded on the original primary LSP-Path.

The detour tunnels are also established on the routers and are
ready to be activated, in case of a failure.
Module 6 |
120
The above slide illustrates the normal data plane forwarding operation on the original primary LSP-Path.
Detour tunnels are established on all routers assuming the PLR role, and detour merging has taken place on routers R6
and R7, as described in the previous pages.
Module 6 Page 120
FRR One-to-One Traffic Forwarding On the Original Path
Router R2 detects that the connection to router R3 is lost (it could

be the result of a link or total nodal failure on router R3).
Router R2 performs a label swap from the original primary LSP-Path
to the detour tunnel (from 200 to 60).
Module 6 |
121
When a failure occurs on the link between R2-R3, or if router R3 fails, router R2 will detect the failure along the
primary LSP-Path.
Router R2 has already established a detour tunnel to protect against such failures and is responsible for locally
recovering the traffic. Therefore, router R2 switches the traffic coming in on the primary LSP-Path to the detour
protection tunnel.
The label switching operation is depicted above with simplified label values. 60, 70, 80 and 40 are the label values
previously signaled by RSVP-TE on the detour tunnel.
After the failure, router R2 swaps the incoming (outer) RSVP-TE label of 200 on the primary path with 60 on the detour
path.
Routers R6, R7 and R8 also perform label swapping along the detour path.
Router R4 is the Merge Point for the detour tunnel. Router R4 is also the terminating point for the original protected
LSP-Path.
Therefore, the detour tunnel label 40 is popped, the correct service is identified by the VPN label and the original Data
packet is delivered to the customer end.
Note that the depth of the label stack does not change at any point along the forwarding path.
It will be illustrated later in the section how label forwarding on the bypass tunnel is different for Fast Reroute Facility
protection.
Module 6 Page 121
FRR One-to-One Activating the Detour on Router R2
The main principles of FRR Facility protection are similar to those

of the one-to-one method, with the following exceptions:
y FRR allows multiple LSPs that traverse the same set of hops to
be protected by the same bypass tunnel.
y The Merge Point selection is different.
y In case of a failure, traffic from multiple protected LSPs are
tunneled into the same bypass tunnel at the PLR.
y The PLR performs a push rather than a swap function (to
accomplish the tunneling).
FRR Facility protection reduces the number of required protection
tunnels.
Module 6 |
122
Fast Reroute Facility protection method allows multiple LSPs to be bound to the same bypass tunnel. In this sense, it is
a less resource intensive way of providing FRR protection, in terms of signaling and labels and session states needed to
be maintained.
Since the intention is to protect as many LSPs as possible with the same bypass, the selection of the Merge Point is
optimized to be more topology efficient.
The main principles of Merge Point selection and data plane forwarding in facility bypass tunnels are covered later in
the section.
Module 6 Page 122
Fast Reroute Facility Protection
Configuring an LSP for Fast Reroute Facility
-------------------------------path fully_loose
no shutdown
lsp "to_R4
to 10.10.10.4
cspf
fast-reroute facility
exit
no shutdown
exit
Same configuration as one-to-one; the only required change is the

facility specification.
Node-protect is again enabled by default.
Module 6 |
123
The configuration for facility bypass protection requires a change of the one-to-one keyword to facility, as shown
above. Node protection is again the desired protection type, by default.
Module 6 Page 123
node-protect
primary fully_loose
CSPF View Fast Reroute Facility and Node Protection

Similar to one-to-one, the PLR evaluates the topology according to

the protection type (node or link).
The selection of the Merge Point (MP) is different.
Module 6 |
124
CSPF processing of the node-protection constraint is the same as in the one-to-one detour case.
The selection logic of the Merge Point is different from a one-to-one detour, however, to provide the ability to protect
as many LSPs as possible.
Module 6 Page 124
node-protect
Merge Point Selection in Facility FRR
The main idea of facility protection is to use an established bypass

tunnel for as many LSPs as possible.
Specifically:
y Link-protect MP is the PLRs Next-Hop router (1 hop away)
y Node-protect MP is the PLRs Next-Next-Hop router (2 hops
away)
Module 6 |
125
If multiple LSPs go through a certain shared portion of the network, they can all be protected by the same bypass
tunnel.
In order to accomplish this, the bypass protection tunnel must merge with the protected LSP at the closest point after
the point of failure.
In case of link protection, the closest point after the failure of the next link is the next-hop router along the protected
LSP-Path.
In case of router protection, the closest point after the failure of the next router is the next-next-hop router along the
protected LSP-Path.
These concepts are illustrated with examples in the following pages.
Module 6 Page 125
To accomplish this, the bypass tunnel merges with the original

LSP-Path at the closest downstream router as possible.
Merge Point Selection with FRR Facility Link-Protect

Using link-protect, MP is the PLRs next-hop router.

The protection tunnel is assigned the name bypass-link10.1.2.2
(the interface IP address avoided).
Module 6 |
126
In the example above, the LSP is configured with a facility bypass protection request. Node protection is disabled in
configuration, which means the routers should only attempt link protection.
Router R1 assumes the PLR role and triggers the bypass tunnel calculation process. On the resulting topology, after the
next link is pruned, the first router in the downstream direction is router R2. In other words, router R2 is the router on
which the forwarding of protected LSP traffic can resume right after the point of failure. Router R2 is chosen as the
Merge Point, and the link bypass tunnel is established to terminate on it.
The bypass tunnel established in this case can be identified with the name bypass-link10.1.2.2 in the SR OS CLI
command outputs.
Module 6 Page 126
no node-protect
Merge Point Selection with FRR Facility Node-Protect

Using node-protect, MP is the next-hop router(R3) after the failed

router (R2). Router R3 is the next-next-hop for router R1.
The protection tunnel is assigned the name bypass-node10.10.10.2
(the router avoided).
Module 6 |
127
In the second example above, the facility bypass protection is configured with the default node protection request.
Router R1 again assumes the PLR role and triggers the bypass tunnel calculation process. On the resulting topology,
after the next router is pruned, the first router in the downstream direction is router R3. In other words, router R3 is
the router that the forwarding of protected LSP traffic can resume right after the point of failure. Router R3 is chosen
as the Merge Point, and the bypass tunnel is established to terminate on it.
Router R3 is also named as next-next-hop router in the RFC terminology.
The bypass tunnel established in this case can be identified with the name bypass-node10.10.10.2 in the SR OS CLI
command outputs.
Module 6 Page 127
node-protect
The complete and exact original primary LSP-Path hop and label
information is required for facility FRR.
Next-next-hop and label information are also required.
This information is obtained from the RRO of the RESV message
received on the primary LSP-Path.
Module 6 |
128
Using facility bypass protection, it is crucial to have the hop and label recording enabled over the original protected
LSP-Path. As elaborated more in the following pages, the PLR routers require visibility over the exact path information
for the protected LSPs. This way, they can perform the Merge Point selection to establish the bypass tunnels. PLRs can
also decide if an already established bypass tunnel can be used for another LSP requesting Fast Reroute Facility by
analyzing its recorded route information.
This information is readily available in the Record Reroute Object. The recorded route information is also required
when forwarding the traffic from the original LSP-Path in the bypass tunnel when protection is active in case of a
failure.
NOTE: Recording is enabled on Alcatel-Lucent Service Routers by default. There is an option in the CLI to disable
recording as in the following example:
A:R1>configure router mpls lsp to_R4 primary fully_loose no record
However, this is not a recommended practice because Fast Reroute cannot function in this case.
The SR OS CLI issues the following error if Fast Reroute is activated on an LSP with recording disabled:
A:R1>configure router mpls lsp to_R4 fast-reroute
INFO: MPLS #1017 LSP parameter conflict - Cannot set 'fast-reroute' because 'no record' is already set on primary path
Module 6 Page 128
Requirement for RRO in FRR Facility Protection
Guidelines for Establishing Bypass Tunnels in Facility FRR
When an LSP requests Facility FRR, the router determines:

y Node-protect If it already has a bypass tunnel established
that avoids the next router.
y Link-protect If it already has a bypass tunnel established that
avoids the next link.
If the required bypass tunnel is:
y Already established The LSP is associated to the same bypass
tunnel.
y Not yet established A new bypass tunnel is established and
the LSP is associated to it.
Module 6 |
129
Fast Reroute Facility protection strives to use the resources in a more efficient way by associating multiple protected
LSPs to the same bypass tunnel whenever possible.
In order to accomplish this, the PLR router checks the Record Route Object (RRO) of the LSP that requests facility
bypass. Depending on the protection mode, the methodology of checking the RRO is as follows:
Node Protection: The PLR router checks the RRO of the requesting LSP and determines the next-next-node in the list.
The PLR then determines whether a bypass tunnel terminating on that router is already established. If it is, the new LSP
is also bound to that same bypass tunnel. The protected LSP count of the bypass tunnel is incremented to notify the
change.
On the other hand, if a bypass tunnel to the next-next-node does not yet exist, a new bypass is created. The LSP is
bound to the new bypass tunnel and the protected LSP count is set to 1.
Link Protection: The PLR router in this case again checks the RRO of the requesting LSP and determines the next-node
in the list. The PLR determines whether a bypass tunnel terminating on the next-node is already established. If it is, the
new LSP is also bound to that same bypass tunnel. The protected LSP count of the bypass tunnel is incremented to
notify the change.
On the other hand, if a bypass tunnel to the next-node does not yet exist, a new bypass is created. The LSP is bound to
the new bypass tunnel and the protected LSP count is set to 1.
Module 6 Page 129
The main objective is to use the same facility bypass tunnel for
multiple LSPs.
FRR Facility Example First LSP Setup
Router R1 requests FRR Facility with node-protect.

Router R2 determines whether a node-bypass tunnel to router R4
already exists.
It does not exist, so a new one is established.
Module 6 |
130
The case study here, which will illustrate the bypass tunnel establishment process, will involve two different protected
LSPs.
The first protected LSP established is shown above. Fast Reroute Facility is requested, so router R2 assumes the PLR
role and analyzes the RRO of the LSP. The next-next-hop router is router R4, and router R2 determines whether a
bypass tunnel that terminates on router R4 has already been established. It does not yet exist, so router R2 signals a
new bypass tunnel that avoids the next router R3 with a System IP address of 10.10.10.3/32.
The Protected LSP Count field of the bypass tunnel is set to 1.
Module 6 Page 130
node-protect
node-protect
Another LSP is set up that goes over

the R1-R2-R3-R4 routers.
FRR facility node-protect is
requested.
Module 6 |
131
The second protected LSP is introduced here that shares a common path segment with the previous one.
Hence, it would be possible to use an existing bypass tunnel at certain points.
Module 6 Page 131
FRR Facility Example Second LSP Setup
node-protect
The new LSP is associated with the

existing bypass-tunnel.
The protected LSP count of the
bypass-tunnel is updated.
Module 6 |
132
Router R2 again assumes the PLR role for the new protected LSP. It analyzes the RRO, and determines that the nextnext-hop router is again router R4. A router protection bypass tunnel has already been established for the previous LSP,
so that the new LSP is also bound to that same bypass tunnel.
The Protected LSP Count of the bypass tunnel is incremented to 2 to signify the change.
Module 6 Page 132
FRR Facility Example Node-Bypass on router R2
FRR Facility Example Link-Bypass on router R3
Router R3 has to revert to link protection.

A link-bypass tunnel does not exist on router R3.
A new one is established and the LSP is associated to it.
Module 6 |
133
For the first LSP, router R3 is the router just before the Tail-End. The desired router protection method is not
applicable to router R3, so that it falls back to link protection.
A link protection tunnel has not yet been established on router R3 to terminate on router R4. A new link protection
bypass tunnel is established and the LSP is bound to it.
Module 6 Page 133
node-protect
node-protect
A new bypass tunnel that avoids router

R4 is established.
The LSP is associated to it.
Module 6 |
134
Router R3 again assumes the PLR role for the new protected LSP. It analyzes the RRO and determines that the nextnext-hop router is router R8. This time, it can provide router protection, unlike with the previous LSP.
A router protection bypass tunnel has not yet been established, so that a new one is created and the LSP is bound to it.
Module 6 Page 134
FRR Facility Example Node-Bypass on router R3
node-protect
A new link-bypass tunnel is

established on router R4.
The LSP is associated to it.
Module 6 |
135
Finally, router R4 assumes the PLR role for the second protected LSP. The desired router protection method is not
applicable to router R4, so that it falls back to link protection.
A link protection tunnel has not yet been established on router R4 to terminate on router R8. A new link protection
bypass tunnel is established and the LSP is bound to it.
The bypass tunnel establishment process is completed for both of the protected LSPs.
Module 6 Page 135
FRR Facility Example Link-Bypass on router R4
Traffic flows over the original primary LSP-Paths.

Both LSPs are protected by the same bypass tunnel.
Module 6 |
136
To illustrate and emphasize the use of facility bypass protection tunnels, consider the example in the figure above.
Two LSPs are established between router R1 and router R4 going over the same links. Router R2 has created a link
bypass tunnel assuming the PLR role to protect both LSPs. The Protected LSP Count indicates this.
Module 6 Page 136
Multiple Protected LSPs with a Single Bypass Tunnel
The link R2-R3 fails.

Traffic for both LSPs is tunneled through the same bypass.
Router R3 (MP) needs to be able to distinguish between the traffic
from the two LSPs in order to forward each with the correct labels.
Module 6 |
137
When a failure occurs on the link between R2-R3, the data traffic coming in on both of the original LSP-Paths needs to
be tunneled into the same bypass tunnel.
After the traffic from both LSPs is forwarded over the bypass tunnel, they are delivered to router R3. At this point,
router R3 needs to be able to identify the two different types of traffic from each other in order to continue forwarding
them over their original LSP-Paths.
The challenge here is that, since a single bypass tunnel exists, only a single set of labels are signaled over that bypass
tunnel. Therefore, a special method needs to be implemented so that the traffic from the two LSPs is readily
identifiable at the Merge Point. This methodology is presented in the following pages.
Module 6 Page 137
Encapsulating Traffic in a Bypass Tunnel
Traffic is forwarded on the original primary LSP-Path.

The bypass tunnel is established on router R2 and is ready to be
activated, in case of a link failure.
Module 6 |
138
The label switching on the original protected LSP-Path is depicted in the figure above.
A link bypass protection tunnel is available on router R2, terminating on router R3.
Of particular interest is the label that router R3 receives, which is 300. When the link failure occurs, router R3 still
needs to receive the label 300 from the bypass tunnel, in order to identify which original LSP-Path the traffic belongs
to. This is true for all the protected LSP-Paths going over the same link, which are not shown in the figure above. All
their traffic needs to be forwarded with the same labels that router R3 expects on the original LSP-Paths, so that they
can be distinguished from each other.
The solution to this forwarding paradigm is presented in the following pages.
Module 6 Page 138
FRR Facility Link Protect Traffic On Primary LSP-1
LSP traffic is encapsulated within the bypass-tunnel.

Router R3 still receives the original transport label, 300.
Module 6 |
139
The forwarding solution mentioned in the previous page is shown above for the link protection case.
When Fast Reroute is active, upon a link failure, the label that router R3 expects on the original LSP-Path (300) is
encapsulated into the label signaled for the bypass tunnel.
In more detail, router R2 (PLR) receives the traffic with an outer RSVP-TE label of 200 on the original path. It swaps this
label with 300 and then pushes a label of 60, which was signaled on the bypass tunnel. As a result, the depth of the
label stack changes from 2 to 3 on along the forwarding path of the bypass tunnel.
Router R6 swaps the outer bypass tunnel label with 70.
Router R3 is the MP or the terminating point for the bypass tunnel. Therefore, it pops the label 30 and the original
RSVP-TE label of 300 is exposed. Router R3 performs the normal swap operation for label 300 as it did on the original
LSP-Path, and forwards the traffic with label 400 to router R4.
Module 6 Page 139
FRR Facility Link Protect Traffic On Bypass Tunnel
Using facility node-protect, the PLR needs to know the Next-NextHop Router (MP), and the label it expects.
This information is available in the RRO.
Module 6 |
140
For the facility bypass node protection scenario, the Record Route Object again happens to be the key element.
To be able to deliver the traffic to router R4 on the bypass tunnel with the original label it expects for the LSP-Path,
router R2 check the RRO. The RRO indicates that 400 is the label that R4 expects.
This is true for all the protected LSP-Paths going over the same set of routers (R2-R3-R4), which are not shown in the
figure above. All their traffic needs to be forwarded with the same labels that router R3 expects on their respective
original LSP-Paths, so that they can be distinguished from each other.
Module 6 Page 140
FRR Facility Node Protect Traffic On Primary LSP-1
FRR Facility Node Protect Traffic On Primary LSP-1
LSP traffic is encapsulated within the bypass-tunnel.

Router R2 swaps transport tunnel label 200 with 400
Module 6 |
141
When Fast Reroute is active, upon a failure that results in the loss of communication to router R3, the label that router
R4 expects on the original LSP-Path (400) is encapsulated into the label signaled for the bypass tunnel.
In more detail, router R2 (PLR) receives the traffic with an outer RSVP-TE label of 200 on the original path. It swaps this
label with 400 and then pushes a label of 60, which was signaled on the bypass tunnel. As a result, the depth of the
label stack changes from 2 to 3 on along the forwarding path of the bypass tunnel.
Router R4 is the MP or the terminating point for the bypass tunnel. Therefore, it pops the label 40 and the original
RSVP-TE label of 400 is exposed. Router R4 performs the normal pop operation for label 400 as it did on the original
LSP-Path, and delivers the traffic to the correct service instance based on the VPN label. Eventually, the VPN label is
also popped and the original data traffic is forwarded towards the customer end.
Module 6 Page 141
R4 receives transport
tunnel label 400
Viewing the RSVP Sessions for Facility Bypass Tunnels
===============================================================================
From
To
Tunnel LSP
Name
State
ID
ID
------------------------------------------------------------------------------10.10.10.1
10.10.10.4
155
47620 to_R4::fully_loose
Up
10.10.10.5
10.10.10.8
158
18432 to_R8::fully_strict
Up
10.10.10.1
10.4.8.4
63491 8
bypass-node10.10.10.3
Up
------------------------------------------------------------------------------Sessions : 3
===============================================================================
Bypass Tunnels should be perceived as separate LSPs.

They do not belong to any primary LSP-Paths.
They have different Tunnel IDs, LSP-IDs, and Session Names (unlike
one-to-one detours).
Primary LSP-Paths are associated to Bypass Tunnels by the PLRs, as
per request.
Module 6 |
142
In the case of Fast Reroute one-to-one protection, separate detours are created that are dedicated to protect a single
LSP-Path.
It has been explained that this is not the case in facility protection. Once a bypass tunnel is created upon the request of
an LSP, it stands as a separate LSP entity, and future LSPs are associated to it as necessary. In other words, the
individual LSPs do not own the bypass tunnels; they are bound to the bypass tunnels and protected by them whenever
applicable.
This can also be observed by the fact that bypass tunnels are assigned totally unique Tunnel IDs and LSP IDs, as shown in
the example output above.
Module 6 Page 142
A:R2# show router rsvp session
Viewing the Facility Bypass Tunnel Details
===============================================================================
MPLS Bypass Tunnels (Detail)
===============================================================================
------------------------------------------------------------------------------bypass-node10.10.10.3
------------------------------------------------------------------------------To
: 10.4.8.4
State
: Up
Out I/F
: 1/1/1
Out Label
: 131068
Up Time
: 0d 03:22:04
Active Time
: n/a
Reserved BW
: 0 Kbps
Protected LSP Count : 2
Type
: Dynamic
SetupPriority
: 7
Hold Priority
: 0
Class Type
: 0
Actual Hops
:
10.2.6.6
-> 10.6.7.7
-> 10.7.8.8
-> 10.4.8.4
===============================================================================
The above command displays bypass-tunnel details.
Module 6 |
143
The details of a bypass protection tunnel are indicated above. The Protected LSP Count field displays the number of
LSPs that are bound to this bypass tunnel.
Module 6 Page 143
A:R2# show router mpls bypass-tunnel detail
Viewing the List of Protected LSPs
===============================================================================
MPLS Bypass Tunnels
===============================================================================
Legend : m - Manual
d - Dynamic
p - P2mp
===============================================================================
To
State Out I/F
Out Label
Reserved
Protected Type
BW (Kbps) LSP Count
------------------------------------------------------------------------------10.4.8.4
Up
1/1/1
131069
0
2
d
Protected LSPs to_R4::fully_loose
From: 10.10.10.1
To: 10.10.10.4
to_R8::fully_strict
From: 10.10.10.5
To: 10.10.10.8
------------------------------------------------------------------------------Bypass Tunnels : 1
===============================================================================
The above command displays the list of LSPs protected by the

bypass tunnel.
The detail option can be used for more information.
Module 6 |
144
The above command can be used to see the list of the LSPs protected by the bypass tunnel.
As with many other CLI commands, the detail keyword can be appended to the end of the command to retrieve more
extensive information.
Module 6 Page 144
A:R2# show router mpls bypass-tunnel protected-lsp
What Happens After Failure is Recovered By FRR?
The Head-End, notified of the failure, is also aware that the traffic
is protected by FRR.
The Primary LSP-Path remains up, with the FRR protection active
on the PLR.
This is independent of the protection method and type.
Module 6 |
145
Establishing Fast Reroute protection tunnels and forwarding traffic over the protection tunnels after a failure has
occurred in the network has been discussed in this section so far.
The rest of the section focuses on the events that take place after Fast Reroute protection has been activated by a PLR
router, and the actions that are taken by the Head-End after being informed of this fact.
After detecting the failure and immediately recovering the traffic on the protection tunnel, the next priority of the PLR
router is to inform the Head-End of the new situation. It sends a PATH Error message in the form of an RSVP Notify
Error. The Error Value field indicates that the tunnel is locally repaired at the PLR router issuing the Error message.
This tells the Head-End router that traffic forwarding still continues on the primary LSP-Path; the sole difference is that
it is on an FRR protection tunnel, and not on the original path. As a result, the Head-End does not set the primary LSPPath status to down, and keeps it operationally up and active. This is applicable to all the one-to-one/facility and
router/link protection cases.
If a standby secondary path exists, the Head-End, upon learning that a PLR has recovered the traffic, will move traffic
to the standby LSP, using MBB. If only a secondary exists, the traffic stays on the FRR path, unless the detour or bypass
tunnel fails.
There might be further actions that are taken by the LSP Head-End upon being informed of the FRR status. The
conditions and details of these actions are covered later in the section.
Module 6 Page 145
If failure occurs at a router other than the Head-End, the PLR:

y Switches the traffic to the protection tunnel
y Sends a PATH ERR message back to Head-End with:
Error Code: RSVP Notify Error
Error Value: Tunnel Locally Repaired
A Primary LSP-Path has been established on the shortest IGP path.

A link-protect FRR detour path is also available on router R2.
Traffic is running on the Primary path.
Module 6 |
146
The case study above is used to illustrate the concepts related to the events and actions taken after an FRR protection
tunnel activation.
A primary LSP-Path is configured with no specific hops and CSPF enabled. No additional constraints are specified for the
LSP-Path. CSPF calculates the entire LSP-Path based on the link costs. The path R1-R2-R4-R6 is chosen and signaled.
Fast Reroute one-to-one is also requested for the LSP. Router R2 signals a link protection detour that goes over routers
R7 and R8. Note that routers R1 and R4 can also establish detours going over the lower plane of the topology, but only
the detour of router R2 is shown for the sake of simplicity.
No link failures exist at present, and traffic forwarding takes place on the original LSP-Path.
Module 6 Page 146
Traffic on Primary LSP-Path
Link between R2-R4 fails.

Router R2 activates FRR and sends a Path ERR to Head-End.
Head-End is informed of the failure and local recovery.
Primary LSP-Path remains UP.
Module 6 |
147
Link failure takes place and router R2 switches the traffic on the link protection detour.
Router R2 sends a PATH Error message towards router R1 that serves as a notification.
Router R1 is informed that the traffic it is pushing on the primary LSP-Path resumes on a protection tunnel established
by router R2.
Router R1 keeps the LSP-Path operationally up.
Module 6 Page 147
Failure Case FRR Switchover and PLR Reporting
The FRR status is also visible in the RESV Session Refresh messages.
The # sign indicates that FRR is active on the router.
Module 6 |
148
The PLR sets the FRR in-use flag in the consecutive RESV Session Refresh messages that it sends. This provides a
continuous indication about the FRR status over the PLR, and is also useful for monitoring purposes in the CLI.
This flag can be observed in the Actual Hops field of the show router mpls lsp <lsp-name> path detail
command output.
Module 6 Page 148
FRR In-Use Flag in the RESV Refresh Message
Primary LSP-Path is active, running on FRR detour path.

The current path (R1-R2-R7-R8-R4-R6) consists of 6 hops.
A better path is available in the network.
Module 6 |
149
Router R1 is aware that the primary LSP-Path is recovered on a Fast Reroute protection tunnel, but also accounts for
the possibility that it might not be the best forwarding path available in the network at the moment.
If CSPF is enabled for the LSP, router R1 can initiate the process to look for a better path for the primary LSP-Path.
The general guidelines for this process are explained in the following pages.
Module 6 Page 149
Suboptimal Traffic Forwarding with Primary-FRR Path
Global Revertive Behavior
The traffic on Primary-FRR might be following a sub-optimal path.

If CSPF is enabled for the LSP, the Head-End will start the retrytimer.
The default retry-timer value is 30 seconds, configurable per LSP.
If a path with a better metric than one being used (total metric of
Primary-FRR) is found, traffic is switched to it in an MBB fashion.
The Head-End can keep trying at every retry-timer expiry, until a
better path is found.
This behavior is called Global Revertive.
Module 6 |
150
As mentioned in the previous page, router R1 considers the possibility that a more optimal forwarding path might exist
in the network after Fast Reroute protection is activated.
If CSPF is enabled for the LSP, the receipt of the PATH Error message from the PLR initiates the Global Revertive
procedure on the Head-End.
As the first action, the Head-End initiates the retry-timer. The retry-timer is a configurable parameter per LSP, and is
set to 30 seconds by default.
At the first expiry of the retry-timer, the Head-End makes a new CSPF calculation for the primary LSP-Path. If a path
better than the existing one (primary-on-FRR) is found, the Head-End performs a switchover to it, using the MBB
procedures described earlier.
If a better path is not found, the retry-timer is reset and a new calculation is done at the next expiry of the timer. This
process can continue until a better path is found for the primary LSP-Path. If the link failure is removed until the retrytimer expires, this can again be the original primary LSP-Path that existed before the failure.
The case study continues with a scenario to illustrate these concepts in the following pages.
Module 6 Page 150
The first optimization attempt will be made 30 seconds after the

receipt of Path Error.
Router R1 receives a Path Error with a tunnel-locally-repaired value.

Router R1 starts the retry-timer (by default, 30 seconds).
Module 6 |
151
Since CSPF is enabled for the LSP, router R1 starts the retry-timer upon receiving the PATH Error message.
The retry-timer value is set to 30 seconds by default.
Module 6 Page 151
Retry-Timer Initiation
The retry-timer expires.

A CSPF calculation is run for the Primary LSP-Path.
CSPF finds a better path that consists of 5 hops.
Module 6 |
152
When the retry-timer expires, router R1 runs a new CSPF calculation for the primary LSP-Path.
The path calculated is R1-R3-R5-R11-R6. This path has a better metric than the existing primary-on-FRR path, which
goes over a larger number of hops. Router R1 decides to signal this new path.
Module 6 Page 152
Retry-Attempt for Primary on FRR
Router R1 establishes the new Primary LSP-Path and switches traffic over in
MBB fashion.
The old primary LSP-Path and its detours are torn down.
If the protection type is facility, the bypass tunnel is not torn down if it still
protects other LSPs.
Module 6 |
153
The new primary LSP-Path is signaled, traffic is switched over to it, and a PATH TEAR message is sent to tear down the
old LSP-Path.
The PATH Tear message serves to clear all the session states regarding the original LSP-Path and the detour tunnels that
are associated with it.
Note that this explanation is valid for the one-to-one protection case used in this example. If the protection mode is
facility, the existing bypass tunnel might still be protecting other LSPs in the network. In this case, the bypass tunnel is
not torn down. However, if this is the only LSP that the bypass tunnel is protecting, the bypass tunnel is also torn down,
as it is no longer needed at the moment.
Module 6 Page 153
Make-Before-Break Switchover to New Primary LSP-Path
If the original Primary LSP-Path is active, the retry-timer is inactive.

A new detour is created for the new Primary.
Module 6 |
154
The retry-timer is only activated when using a Fast Reroute protection tunnel. Since the traffic is now on the original
data path of the new primary LSP-Path, the retry-timer is inactive. Router R1 will not attempt new CSPF queries for the
LSP-Path.
In the meanwhile, new detours are established on the new primary LSP-Path because the FRR request is still present in
the PATH message sent on this new path.
Module 6 Page 154
Retry-Timer Inactivation
Retry-Timer and Retry-Limit Configuration

The retry-timer is configurable per LSP:
A:R1>configure router mpls lsp to_R6 retry-timer [1..600]
There is also a configurable retry-limit per LSP:

A:R1>configure router mpls lsp to_R6 retry-limit [0..10000]
The default retry-limit is 0 (retry until a better path is found).
Module 6 |
155
It is possible to customize the retry-timer value per LSP, as shown in the first figure above.
There is also a retry-limit under the LSP configuration. This can be used to instruct the Head-End router to stop making
new CSPF calculations after a certain number attempts are reached. The default value is set to zero, which means the
Head-End should try indefinitely until a path better than the primary-on-detour path is found for the LSP.
Module 6 Page 155
The default retry-timer value is 30 seconds.
(Global) Resignal-Timer
If calculated by CSPF, an active LSP-Path stays on its current path

indefinitely, until a failure occurs. This is the default behavior.
If preferred, a global resignal-timer can be enabled to override
this default behavior:
The minimum configurable resignal-timer is 30 minutes.

When the resignal-timer expires, the Head-End router makes a new
CSPF calculation for all its originating CSPF-enabled active LSPPaths:
y If a better path is found, the traffic is switched in an MBB
fashion.
y If no better path is found, the traffic stays on the existing
path.
Module 6 |
156
Another characteristic of LSP-Paths calculated by CSPF is that they tend to remain on their current path indefinitely,
until impacted by failure.
The implication of this is that a better path might become available after the initial CSPF calculation and LSP
establishment, but the Head-End will not attempt to switch to it under steady-state network conditions.
To override this default behavior, a global resignal timer can be activated right under the MPLS context. Note that this
is a system-wide configuration; it applies to all CSPF enabled LSP-Paths.
This timer is disabled by default. If enabled, the minimum configurable timer value is 30 minutes.
Once the resignal timer is enabled, at every expiry of this timer the Head-End checks the active LSP-Paths (the ones
that are forwarding the LSP traffic) at that time. The Head-End then triggers a new CSPF calculation for all these active
paths.
The signaling of a newly calculated path depends on the current forwarding path. Since the objective now is
optimization, The Head-End switches to the new path only if it is better than the existing one. The metric values are
compared to perform this decision.
Module 6 Page 156
A:R1>configure router mpls resignal-timer [30..10080]
The link failure between R2-R4 is removed.

A better path exists, but traffic remains on the existing path.
Module 6 |
157
The case study above is used to illustrate the concepts related to global LSP re-optimization.
Traffic is currently forwarded along the primary LSP-Path, over 5 hops.
The failure on the link between R2-R4 is removed, presenting a better path between routers R1 and R4, consisting of
only 4 hops.
The Head-End will remain unaware of this fact until the configured resignal-timer expires.
Module 6 Page 157
Failure Recovery Suboptimal Forwarding on Primary
The global resignal-timer expires.

Router R1 runs a CSPF calculation for all its active CSPF-enabled LSP-Paths.
A better path is found for the primary LSP-Path.
Module 6 |
158
The resignal timer expires and router R1 triggers a new CSPF calculation for all the originating active LSP-Paths that
have CSPF enabled in their LSP configurations.
For the LSP-Path under consideration, the CSPF calculation yields to a better path that goes over the R1-R2-R4-R6 path.
Router R1 will switch to this LSP-Path in a make-before-break fashion.
Module 6 Page 158
Global Resignal Attempt for CSPF Enabled LSP-Paths
Router R1 establishes the new primary LSP-Path.

Traffic is switched over in a make-before-break fashion.
Module 6 |
159
Router R1 has calculated a new primary LSP-Path that goes over the R1-R2-R4-R6.
The RSVP-TE signaling of this path is performed and the traffic is switched over to it in a hitless fashion.
A PATH Tear message is sent on the now-old primary LSP-Path to tear it down, along with its detours.
Module 6 Page 159
Global Resignal MBB Switchover
The resignal timer is reset.

After 30 minutes, all the active CSPF-enabled LSP-Paths will be
re-evaluated.
Module 6 |
160
The LSP is running again on the most optimal path available in the network. New detours are established as usual.
The resignal-timer will keep on running as long as it is enabled. Router R1 will repeat the re-optimization process every
time the resignal-timer expires. In this example, this happens every 30 minutes.
Module 6 Page 160
Resetting the Resignal-Timer
Module 6 |
161
LAB 6 Section 6.3 and 6.4 Fast Reroute Facility and One-to-One
Module 6 Page 161
Section Summary
Fast Reroute Protection types

y Node-Protect
y Link-Protect
The process of establishing Fast Reroute Tunnels
PLR and MP concepts
DMP concept for one-to-one detours
Module 6 |
162
A separate detour tunnel is established for each protected LSP-Path, using one-to-one protection.
A single bypass tunnel can be used to protect multiple LSP-Paths that request facility protection.
Point of Local Repair (PLR) is the router performing the Fast Reroute protection.
Merge Point (MP) is the router on which the protection tunnel terminates and merges with the original LSP-Path.
In node protection, the PLR establishes a protection tunnel that avoids the next router along the original LSP-Path.
In link protection, the PLR establishes a protection tunnel that avoids the next link along the original LSP-Path.
Node protection is enabled by default, and all PLRs attempt to signal router protection tunnels. If this is not
possible, they can fall back on link protection.
CSPF is used to calculate the protection tunnels on the PLRs.
Protection tunnels are automatically signaled. Only the LSP on the Head-End is configured with the FRR
requirements. No additional configuration is required on any of the routers.
In one-to-one protection, multiple detours protecting the same LSP-Path can be merged if they transit a common
router and egress on a common link. The router performing the merging process on the detours is called a Detour
Merge Point (DMP).
Detour Merging takes place automatically and is enabled by default. It cannot be disabled in configuration.
Module 6 Page 162

Fast Reroute Protection Methods
y One-to-One Detour
y Facility Bypass
Section Summary (contd)
Forwarding Traffic on One-to-One Detours

y Each protected LSP is forwarded via its own dedicated detour
y The PLR performs a swap to the detour label
y The depth of the label stack does not increase.
Forwarding Traffic on Facility Bypass Tunnels
y Traffic from multiple LSPs is encapsulated within the bypass
tunnel
y The PLR performs a push of the bypass label
y The depth of the label stack increases by one label
Module 6 |
163
Enhancements were defined in RFC 4090 to enable the automatic signaling of protection tunnels.
The Fast_Reroute Object is included in the RSVP PATH message used to signal the original LSP-Path. The desire to
establish FRR tunnels and the protection mode (one-to-one or facility) is signaled in this object.
The protection type (router or link) is included in the SESSION_ATTRIBUTE object of the PATH message.
The Detour_Object is included in the RSVP PATH message used to signal the detour tunnel in one-to-one protection.
The Detour_Object indicates the PLR_ID and the protected resource (link or router ID) of the PLR performing the
protection.
In one-to-one protection, the PLR swaps the incoming RSVP-TE label on the original LSP-Path with the label signaled
on the detour path. The depth of the label stack does not increase as a result of this operation.
In facility protection, the PLR swaps the incoming RSVP-TE label on the original LSP-Path with the label that the MP
expects again on the original LSP-Path. The PLR then pushes the label signaled on the bypass tunnel. The depth of
the label stack increases by one label as a result of this operation.
Module 6 Page 163
RSVP-TE Fast Reroute Extensions in RFC 4090

y Fast_Reroute Object
y Detour Object
Section Summary (contd)
The use of Record Route Object (RRO)

Configuring and verifying One-to-One Detours
LSP Global Revertive Behavior, using:
y Retry-timer Initiated upon failure
y Resignal-timer If enabled, runs periodically and re-evaluates
all the CSPF enabled active LSP-Paths
The role of CSPF in Global Revertive
Module 6 |
164
The Record Route Object (RRO) is included in all RSVP PATH and RESV messages by default.
The RRO provides exact and actual hop information about the path, together with label values.
The RRO is required for Fast Reroute functionality.
One-to-one detours have the same Tunnel ID and LSP ID as their respective protected LSPs. They are identified by
the (_detour) suffix appended to the original path names.
Facility bypass tunnels have individual and unique Tunnel and LSP IDs. LSPs are associated to bypass tunnels as
required.
The PLR router issues a PATH Error message when it activates the FRR tunnel. This notifies the Head-End of the
protection status.
The Head-End keeps the LSP-Path up and active upon receiving the PATH Error.
If CSPF is enabled in the LSP configuration, the Head-End can try to find a better path, as long as the primary LSPPath is on a protection tunnel. The retry attempts can occur at every retry-timer intervals.
The default retry-timer is 30 seconds and is configurable per LSP.
A retry-limit is also configurable and is set to 0 (retry forever) by default.
If calculated by CSPF, an LSP stays on the current path under stable network conditions. By default, it does not
attempt to switch to a more optimal path even if one becomes available after initial LSP-Path establishment.
A global resignal-timer can be configured to make a new CSPF calculation for all the active originating LSP-Paths on
a router in an attempt to find a better forwarding path.
The minimum configurable resignal timer is 30 minutes.
The Head-End switches to the newly calculated LSP-Path, only if it is better than the existing path.
Module 6 Page 164
Configuring and verifying Facility Bypass Tunnels
Module Summary
Total convergence time includes failure detection, failure

propagation, and service recovery.
Protocol level failure detection depends on IGP and RSVP hello
timers, and BFD and EFM implementation.
An LSP Head-End must wait for timers to expire or error messages
to detect a failure downstream.
LDP-IGP Sync ensures that the Head-End does not replace an active
LFIB entry until is receives a label from its peer.
The Head-End router moves traffic to a secondary path as soon as
it learns of a failure on the primary path.
By default, the Head-End moves traffic to the standby secondary
path with the longest uptime.
Module 6 |
165
Module 6 Page 165
By default, the Head-End will not move traffic back to a previously

used secondary LSP path.
Using secondary path preferences, the operator can control the
order in which the Head-End selects standby paths.
A network operator can ensure path diversity using strict paths,
admin groups, and Shared Risk Link Groups.
SRLG allows the Head-End to choose the optimal path while

ensuring the secondary and fast reroute paths dont share a
common link with the primary, if possible.
MPLS Fast Reroute (FRR) defines ways of pre-configuring and
signaling backup paths before a failure.
FRR allows traffic to flow almost continuously.
Module 6 |
166
Module 6 Page 166
The one-to-one backup method creates detour LSPs for each

protected LSP at each potential point of local repair.
The facility backup method creates a bypass tunnel to protect a
potential failure point.
An FRR Point of Local Repair (PLR) identifies a link or node failure
and moves traffic to a detour or bypass tunnel.
An FRR Merge Point (MP) returns traffic to the original LSP path
downstream of the failure.
SR OS routers enable FRR one-to-one and node protection by
default.
Merge point locations differ between FRR one-to-one and facility
bypass.
Module 6 |
167
Module 6 Page 167
An FRR Detour Merge Point (DMP) merges multiple detours that

share the same egress link on the DMP router.
The retry-timer and retry-limit values determine how long the
Head-End will try to bring the primary LSP-path back up after a
failure.
Module 6 |
168
The resignal-timer, if set, allows the Head-End to reoptimize the

primary LSP path.
Module 6 Page 168
Learning Assessment
1. LDP convergence time depends mostly on what value?

2. How many Primary LSP paths can be configured per LSP?
3. How many Secondary LSP paths can be configured per LSP?
5. The Head-End routers chooses the backup path in what order?

6. In what circumstances will the Head-End revert traffic to a
previous secondary path?
7. If an LSP includes admin group green for use by the primary path
and red for the secondary paths, and a green link between the
Head-End and the tail-end routers is unavailable, over which path
will the Head-End signal the primary path?
1.
Module 6 |
169
LDP convergence time depends mostly on what value?

IGP convergence.
2.
How many Primary LSP paths can be configured per LSP?

1
3.
How many Secondary LSP paths can be configured per LSP?

8 secondary, or 7 secondary and 1 primary.
4.
What is the term used for an LSP with one or multiple associated backup tunnels?
Protected LSP
5.
The Head-End routers chooses the backup path in what order?

1. Standby secondary path, 2. Standby with the highest uptime, 3. Non-standby secondary, 4. First non-standby in
the configuration order
6.
In what circumstances will the Head-End revert traffic to a previous secondary path?
Only if standby path-preferences are configured.
7.
If an LSP includes admin group green for use by the primary path, and red for the secondary paths, and a green link
between the Head-End and the tail-end routers is unavailable, over which path will the Head-End signal the primary
path?
It cannot signal the primary path on any other link, so it will signal the secondary, if possible.
Module 6 Page 169
4. What is the term used for an LSP with one or multiple associated
backup tunnels originating at that hop?
8.
If the operator configures SRLG, does the primary path have to

choose links which are members of a defined SLRG group for the
secondary to come up on a disjointed path?
9.
What is the term used for the LSP that is used to re-route traffic
around a failure in one-to-one backup?
10. What is the term used for the techniques to repair LSP tunnels
quickly when a node or link along the LSPs path fails?
11. What is the name of the Head-End LSR of a backup tunnel or a
detour LSP?
12. What are the two methods used to protect links and nodes
during network failure?
13. True or False: FRR facility attempts to return protected traffic
as close to the tail-end as possible.
8.
Module 6 |
170
If the operator configures SRLG, does the primary path have to choose links that are members of a defined SLRG
group for the secondary to come up on a disjointed path?
No; the primary path does not consider SRLG links. CSPF chooses a path for the secondary that avoids links chosen
by the primary, if possible.
9.
What is the term used for the LSP that is used to re-route traffic around a failure in one-to-one backup?
Detour LSP
10. What is the term used for the techniques to repair LSP tunnels quickly when a node or link along the LSPs path
fails?
Local Repair
11. What is the name of the Head-End LSR of a backup tunnel or a detour LSP?
Point of Local Repair (PLR)
12. What are the two methods used to protect links and nodes during network failure?
One-to-one Backup and Facility Backup
13. True or False: FRR facility attempts to return protected traffic as close to the tail-end as possible.
False. Facility bypass returns traffic to the original path as close downstream from the failure point as possible.
Module 6 Page 170
14. By default, a router will attempt to protect the downstream

node ____ times before reverting to link protection.
16. A PLR signals the ______ ______ to inform the downstream

routers of the path over which it chooses to signal the detour
tunnel.
17. The detour tunnel may terminate at the merge point or at a
__________ _______ __________.
18. Before building a bypass tunnel, the PLR checks the ____ of the
requesting LSP to determine if a tunnel already exists around the
protected link and node.
19. The process the Head-End enacts to attempt to return the
protected LSP path to operation is called ________ __________.
Module 6 |
171
14. By default, a router will attempt to protect the downstream node 3 times before reverting to link protection.
15. The Head-End router needs to know the exact path of the protected path before signaling the protection tunnel.
16. A PLR signals the detour object to inform the downstream routers of the path over which it chooses to signal the
detour tunnel.
17. The detour tunnel may terminate at the merge point or at a detour merge point.
18. Before building a bypass tunnel, the PLR checks the RRO of the requesting LSP to determine if a tunnel already
exists around the protected link and node.
19. The process the Head-End enacts to attempt to return the protected LSP path to operation is called Global
Revertive.
Module 6 Page 171
15. The Head-End router needs to know the _____ path of the
protected path before signaling the protection tunnel.

Alcatel-Lucent Multiprotocol Label Switching Student Guide v2-1-Dl

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Alcatel-Lucent Multiprotocol Label Switching Student Guide v2-1-Dl

Caricato da

Copyright:

Formati disponibili

Alcatel-Lucent Multiprotocol Label

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Module 0 Course Introduction

Alcatel-Lucent Career Certification Flow

Alcatel-Lucent Multiprotocol Label Switching v2.1

All rights reserved 2011 Alcatel-Lucent