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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 0 - Page 2

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 0 | 3

All rights reserved © 2011 Alcatel-Lucent

•3 Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 0 - Page 3

3

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 0 | 4

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

SRC Courses and Exams

All rights reserved © 2011 Alcatel-Lucent

•4 Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 0 - Page 4

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

Alcatel-Lucent Multiprotocol Label Switching

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 0 | 5

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

SRC Program Exam Profile

All rights reserved © 2011 Alcatel-Lucent

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

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 0 | 6

All rights reserved © 2011 Alcatel-Lucent

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

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 0 | 7

All rights reserved © 2011 Alcatel-Lucent

•7 Alcatel-Lucent Multiprotocol Label Switching v2.1

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:

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ Remote, private access (7×24) 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 0 | 8

All rights reserved © 2011 Alcatel-Lucent

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

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ Certifications must be valid to receive exemptions ƒ Submit your request for exemptions at: http://www.alcatellucent.com/src/exemptions

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 0 | 9

All rights reserved © 2011 Alcatel-Lucent

•9 Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 0 - Page 9

Alcatel-Lucent Multiprotocol Label Switching

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 0 | 10

All rights reserved © 2011 Alcatel-Lucent

Module 0 - Page 10

Alcatel-Lucent MPLS ― Course Goal

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 0 | 11

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Provide the participants with a foundation knowledge of MPLS and related protocols, and their application and implementation in an Alcatel-Lucent network environment.

All rights reserved © 2011 Alcatel-Lucent

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 0 | 12

All rights reserved © 2011 Alcatel-Lucent

Module 0 - Page 12

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 0 | 13

All rights reserved © 2011 Alcatel-Lucent

Module 0 - Page 13

Alcatel-Lucent MPLS ― Course Timeline Day 1 ƒ Module 0 ― Course Introduction ƒ Module 1 ― Introduction to MPLS ƒ Module 2 ― Fundamentals of MPLS Day 2 ƒ Module 3 ― Label Distribution Protocol 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

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

y y y y

Day 3 ƒ Module 4 ― Resource Reservation Protocol y Lab 4 – IGP-Based RSVP LSP Establishment

ƒ Module 5 ― Traffic Engineering Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 0 | 14

All rights reserved © 2011 Alcatel-Lucent

Module 0 - Page 14

Alcatel-Lucent MPLS ― Course Timeline (cont’d) Day 4 ƒ Module 5 ― Traffic Engineering (cont’d) 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

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 0 | 15

All rights reserved © 2011 Alcatel-Lucent

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

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 0 | 16

All rights reserved © 2011 Alcatel-Lucent

Module 0 - Page 16

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 0 | 17

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Alcatel-Lucent MPLS ― Symbols and Icons

All rights reserved © 2011 Alcatel-Lucent

Typical graphic symbols found in this courseware.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 0 - Page 17

Administration ƒ Registration ƒ Facility Information ƒ Restrooms ƒ Communications ƒ Materials

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ Schedule ƒ Introductions • Name and Company • Experience ƒ Questions

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 0 | 18

All rights reserved © 2011 Alcatel-Lucent

Module 0 - Page 18

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

www.alcatel-lucent.com/src

3FL-30635-AAAA-ZZZZA Edition 01

Alcatel-Lucent Multiprotocol Label Switching

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Module 1 — Introduction to MPLS

Alcatel-Lucent Multiprotocol Label Switching v2.1

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 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.alcatel-lucent.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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 2

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ Describe MPLS service and resiliency drivers

Module 1 ― MPLS Overview

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 1 — MPLS Drivers

Alcatel-Lucent Multiprotocol Label Switching v2.1

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 4

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 4

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 5

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 5

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 6

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 6

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 7

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 7

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Traffic Engineering ― IP Hyperaggregation

ƒ MPLS offers manageable and scalable tools that engineer the traffic flows for better utilization of network resources. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 8

All rights reserved © 2011 Alcatel-Lucent

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 under–utilized, 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 8

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Traffic Engineering ― MPLS RSVP

ƒ MPLS offers a rich set of traffic protection mechanisms that surpass the IGP convergence times. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 9

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 9

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

High Available MPLS Networks

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 10

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 10

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 11

All rights reserved © 2011 Alcatel-Lucent

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 customer’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 11

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Layer 2 Point-to-Point VPN Services (VPWS)

ƒ VPLS (Virtual Private LAN Service) connects multiple customer sites, emulating a Layer 2 bridged environment. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 12

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 12

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 13

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 13

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Layer 3 Multipoint VPN Services (VPRN)

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 14

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 14

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 15

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 15

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 16

All rights reserved © 2011 Alcatel-Lucent

Module 1 – Page 16

Module 1 ― MPLS Overview

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 2 — Introduction to MPLS

Alcatel-Lucent Multiprotocol Label Switching v2.1

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 18

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 18

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 19

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 19

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

IP Routing Overview

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 20

All rights reserved © 2011 Alcatel-Lucent

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 packet’s destination. If it finds a match between the packet’s 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 frame’s type field and creates a new FCS. The packet is sent to the physical layer for transport.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 20

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

IP Routing Process on a Single Router

MPLS Terminology ƒ iLER : Ingress Label Edge Router ƒ eLER: Egress Label Edge Router ƒ LSR : Label Switch Router Alcatel-Lucent Multiprotocol Label Switching v2.1

Service architecture terminology ƒ PE : Provider Edge Router ƒ P : Provider (Core) Router ƒ CE : Customer Edge Router Module 1 | 21

All rights reserved © 2011 Alcatel-Lucent

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 provider’s 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 provider’s 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 router’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 21

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 22

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 22

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 23

All rights reserved © 2011 Alcatel-Lucent

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, LSP’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 23

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 24

All rights reserved © 2011 Alcatel-Lucent

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 packet’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 24

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 25

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 25

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 26

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 26

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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)

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 27

All rights reserved © 2011 Alcatel-Lucent

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 today’s Service Provider Networks. The SRC AIRP course examines the Interior Routing Protocols in much greater detail.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 27

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 28

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 28

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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). Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 29

All rights reserved © 2011 Alcatel-Lucent

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 router’s 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 is show router fib .

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 29

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 30

All rights reserved © 2011 Alcatel-Lucent

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.)

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 30

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Building Tables: IP Data Forwarding

MPLS Protocols Exchange label bindings for their FECs and build the LIB (Label Information Base). Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 31

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 31

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Building Tables: MPLS Control Plane

Label Binding Information is transferred to the Data Plane and is stored in the LFIB (Label Forwarding Information Base). Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 32

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 32

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 33

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 33

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 34

All rights reserved © 2011 Alcatel-Lucent

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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 34

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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)

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 35

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

y MPLS Control and Data Planes overview (LIB and LFIB)

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 36

All rights reserved © 2011 Alcatel-Lucent

Module 1 – Page 36

Module Summary (cont’d)

ƒ 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.

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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 packet’s header. Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 37

All rights reserved © 2011 Alcatel-Lucent

Module 1 – Page 37

Module Summary (cont’d)

ƒ 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.

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 38

All rights reserved © 2011 Alcatel-Lucent

Module 1 – Page 38

Module Summary (cont’d)

ƒ 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)

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 39

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

• 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 All rights reserved © 2011 Alcatel-Lucent

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?

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 | 40

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 1 – Page 40

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

4. Define the three MPLS label operations.

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

www.alcatel-lucent.com

3FL-30635-AAAA-ZZZZA Edition 01

Alcatel-Lucent Multiprotocol Label Switching

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Module 2 — Fundamentals of MPLS

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 1

Module Objectives

Upon successful completion of this module, you should be able to: ƒ Explain the data plane implications of MPLS. ƒ Describe the management plane functions that are available to MPLS.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

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.alcatel-lucent.com/src for more information on the SRC program. To locate additional information related 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 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 2

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ Explain the control plane implications of MPLS.

Module 2 ― Fundamentals of MPLS

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 1 — Understanding the Data Plane Implications of MPLS

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 3

Section Objectives

In this section we will: ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

4

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 4

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

5

All rights reserved © 2011 Alcatel-Lucent

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 customer’s 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 interface’s maximum packet size as well as the router’s implementation of the MPLS protocols.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 5

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

MPLS (Frame Mode) Label Stack Implementation

ƒ The MPLS Transport (Outer) tunnel can encapsulate multiple Service (Inner) tunnels.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

6

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 6

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

The Need for a Label Stack for VPN Services

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

7

All rights reserved © 2011 Alcatel-Lucent

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 customer’s 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 B’s Service 2.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 7

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

MPLS Label Stack Operation for VPN Services

ƒ Customer Layer 2 Header is preserved at iLER.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

8

All rights reserved © 2011 Alcatel-Lucent

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 CE1’s source MAC address and CE2’s 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 frame’s source MAC address is that of router R1’s egress interface and the destination MAC address is that of router R2’s ingress interface. The top label (transport) tunnels the customer’s 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 customer’s payload from the service provider’s headers, and forwards the original Layer 2 frame to CE2. CE2 accepts this packet, since its own L2 MAC address is the destination.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 8

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

MPLS Encapsulation for Layer 2 VPN Services

ƒ Customer Layer 2 Header is removed at iLER. ƒ A new Layer 2 Header is built by eLER. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

9

All rights reserved © 2011 Alcatel-Lucent

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 customer’s 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 service’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 9

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

3

QoS mapping from TOS/COS bits

S

Bottom of Stack

1

Flag to indicate bottom of MPLS stack

TTL

Time to Live

8

Packet lifetime in MPLS hops

ƒ Each MPLS header is fixed 4 bytes in size * RFC 5462 renames the EXP field to “Traffic Class” Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

10

All rights reserved © 2011 Alcatel-Lucent

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 field’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 10

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Reserved for future use

2, 048 – 18, 431

Statically assigned for services

18, 432 - 32, 767

Reserved for future use

32, 768 – 131, 071

Dynamically assigned by MPLS protocols

131, 072 – 1, 048, 575

Reserved for future use

ƒ MPLS Label Ranges are not configurable. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

11

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 11

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

12

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 12

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

13

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 13

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

14

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 14

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

MPLS Header: EXP Field ― Uniform Mode (non-SR OS behavior)

ƒ The S bit indicates the bottom of the MPLS stack.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

15

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 15

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

16

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 16

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

17

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 17

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. ƒ The MPLS TTL inside the top label is decremented at each LSR.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

18

All rights reserved © 2011 Alcatel-Lucent

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). 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 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 18

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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 inside the top label is decremented at each LSR. ƒ The MPLS TTL is copied onto the IP TTL in the customer packet at eLER. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

19

All rights reserved © 2011 Alcatel-Lucent

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). 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 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 19

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

20

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 20

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

MPLS Frame Mode vs. Cell Mode Implementation.

Section Summary

ƒ This section covered: 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

21

All rights reserved © 2011 Alcatel-Lucent

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 21

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

y Explanation of MPLS Header fields:

Module 2 ― Fundamentals of MPLS

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 2 — Understanding the control plane implications of MPLS

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 22

Section Objectives

In this section we will: ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

23

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 23

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ Introduce the various label space implementation modes.

ƒ For tunnels to be established: y Routers must know about each other’s FECs. y Label bindings for FECs must be negotiated between the routers.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

24

All rights reserved © 2011 Alcatel-Lucent

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 router’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 24

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Requirement for IP/MPLS Control Processes

ƒ IGP is responsible for distributing and maintaining network reachability information; that is, the IGP FECs.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

25

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 25

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

26

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 26

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

27

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 27

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

28

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 28

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ The two modes that define the process to distribute label bindings for FECs in an MPLS enabled network are: y Downstream Unsolicited

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

29

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 29

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

30

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 30

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

31

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 31

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

32

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 32

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Downstream on Demand Label Distribution - Response

ƒ Label Forwarding Information Base (LFIB) tables are populated and the LSP gets established. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

33

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 33

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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:

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

34

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 34

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ Ordered Control ƒ Independent Control

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

35

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 35

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Ordered Control vs. Independent Control

Label Retention Modes

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

36

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 36

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ The two modes that define the way routers maintain the received label bindings in their tables are: y Conservative y Liberal

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

37

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 37

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

38

Retention Mode Liberal Conservative

All rights reserved © 2011 Alcatel-Lucent

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 38

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ SR OS combinations shown below.

Per Platform vs. Per Interface Label Space

SR OS

Module 2 |

39

All rights reserved © 2011 Alcatel-Lucent

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 device’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 39

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Alcatel-Lucent Multiprotocol Label Switching v2.1

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

• Fully customizable tunnel paths • Ability to run more complex path calculations with additional administrative constraints. • Superior traffic protection mechanisms. • Higher administrative overhead. • Downstream on Demand • Conservative Retention

Module 2 |

40

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 40

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

• 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

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 41

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

MPLS Service Label Signaling Protocols

MPLS Special Use Labels

ƒ Label values 0-15 are reserved for special uses.

Label Usage

0

IPv4 Explicit Null

1

Router Alert

2

IPv6 Explicit Null

3

Implicit Null

4-15

Reserved for future use

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

42

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 42

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Label Value

ƒ Router R3 receives packets destined to FEC Z with a label of 100 and always pops them. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

43

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 43

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

44

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 44

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

45

All rights reserved © 2011 Alcatel-Lucent

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 router’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 45

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

46

All rights reserved © 2011 Alcatel-Lucent

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 46

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

47

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 47

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

48

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 48

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Result of Explicit Null Advertisement

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

49

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

50

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 50

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

MPLS Router Alert Label

Section Summary

ƒ This section provided an overview on: 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

51

All rights reserved © 2011 Alcatel-Lucent

ƒ

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 51

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

y Label retention modes y Label space implementation modes

Module Summary

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

52

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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 label’s TTL independently of the incoming packet’s TTL. All rights reserved © 2011 Alcatel-Lucent

Module 2 – Page 52

Module Summary (cont’d)

Alcatel-Lucent Multiprotocol Label Switching v2.1

Multiprotocol Alcatel-Lucent Label Switching Multiprotocol Label Switching v2.1

Module 2 |

53

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Multiprotocol Alcatel-Lucent Label Switching Multiprotocol Label Switching v2.1

Module 2 |

54

All rights reserved © 2011 Alcatel-Lucent

Module 2 – Page 54

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Module Summary (cont’d)

Module Summary (cont’d)

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Multiprotocol Alcatel-Lucent Label Switching Multiprotocol Label Switching v2.1

Module 2 |

55

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

All rights reserved © 2011 Alcatel-Lucent

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 _______.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

56

All rights reserved © 2011 Alcatel-Lucent

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 customer’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 56

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

3. In a service architecture, the head-end and tail-end PE routers process which two tunnel headers?

Learning Assessment (cont’d)

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?

Alcatel-Lucent Multiprotocol Label Switching v2.1

7.

Module 2 |

57

All rights reserved © 2011 Alcatel-Lucent

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 57

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

8. True or False: The SR OS RSVP-TE implementation uses Downstream on Demand label distribution, ordered control, and conservative label retention.

Learning Assessment (cont’d)

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?

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 |

58

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 2 – Page 58

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

14. What is a primary difference between LDP and RSVP-TE signaled LSPs?

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

www.alcatel-lucent.com

3FL-30635-AAAA-ZZZZA Edition 01

Alcatel-Lucent Multiprotocol Label Switching

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Module 3 — Label Distribution Protocol

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 1

Module Objectives

Upon successful completion of this module, you should be able to: ƒ Explain the control plane operation of LDP in detail.

ƒ Investigate additional features related to LDP.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

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.alcatel-lucent.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 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 2

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ Demonstrate the ability to configure LDP in an Alcatel-Lucent environment.

Module 3 - Label Distribution Protocol

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 1 — Operational Principles of LDP

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 3

Section Objectives

In this section we will: ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

4

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 4

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

5

All rights reserved © 2011 Alcatel-Lucent

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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 5

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

6

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 6

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

7

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 7

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

8

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 8

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

9

All rights reserved © 2011 Alcatel-Lucent

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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 9

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ TCP based messages:

ƒ 10.10.10.x/32 addresses are the system (default loopback) interface addresses.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

10

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 10

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

A:R6>config>router>ldp# -------------------------------interface-parameters interface "toR4" exit exit

Link LDP Configuration

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

11

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 11

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

System IP Interface Configuration

A:R6>config>router# -------------------------------interface “system" address 10.10.10.6/32 exit

Module 3 |

12

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 12

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

13

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 13

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

14

All rights reserved © 2011 Alcatel-Lucent

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 router’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 14

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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 Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

15

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 15

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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 Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

16

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 16

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

LDP Periodic Hellos and Hello Timeout

A:R1>config>router>ldp# -------------------------------interface-parameters hello 15 3 interface "toR2“ exit interface "toR3“ exit interface "toR4“ hello 45 3 exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

hello Timeout = 15 seconds & Factor = 3 (15÷3 = 5 seconds Hello Interval) (global setting) (45÷3 = 15 seconds Hello Interval ) (overrides the global setting) Module 3 |

17

All rights reserved © 2011 Alcatel-Lucent

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 - no hello

: [3..65535]



: [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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 17

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

18

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 18

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

19

All rights reserved © 2011 Alcatel-Lucent

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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 19

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

20

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 20

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

21

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 21

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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 .

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

22

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 22

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Default Transport Address for Alcatel-Lucent Service Routers

A:R1>config>router>ldp# -------------------------------interface-parameters transport-address system interface "toR2“ exit interface "toR3“ exit interface "toR4“ transport address interface exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

global setting (default)

can be changed for possible interoperability reasons

Module 3 |

23

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 23

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 24

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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 -----------------------------------------

10.10.10.6/32 10.4.6.6 (toR6)

Alcatel-Lucent Multiprotocol Label Switching v2.1

OSPF

A:R6>config>router>ospf# -------------------------------area 0.0.0.0 interface system exit interface toR4 interface-type p2p* exit

A:R6# show router fib 1 ========================================= Prefix Protocol NextHop -----------------------------------------

10.10.10.4/32 10.4.6.4 (toR4)

Module 3 |

25

OSPF

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 25

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Enabling IGP

ƒ The router with the higher transport address (router R6) initiates the LDP session to TCP destination port 646 of the neighbor. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

26

All rights reserved © 2011 Alcatel-Lucent

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,152–65,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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 26

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

27

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 27

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:R4# show router ldp session ============================================================================== LDP Sessions ============================================================================== Peer LDP Id Adj Type State Msg Sent Msg Recv Up Time -----------------------------------------------------------------------------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 Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

28

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 28

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

LDP Periodic Keepalives and Keepalive Timeout

A:R1>config>router>ldp# -------------------------------interface-parameters keepalive 30 3 interface "toR2“ exit interface "toR3“ exit interface "toR4“ keepalive 90 3 exit

(global setting) Timeout = 30 seconds & Factor = 3 (Keepalive Interval = 30÷3 = 10 seconds)

Alcatel-Lucent Multiprotocol Label Switching v2.1

(Keepalive Interval = 90÷3 = 30 seconds) (overrides the global setting) Module 3 |

29

All rights reserved © 2011 Alcatel-Lucent

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 - no hello

: [3..65535]



: [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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 29

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

30

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 30

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

31

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 31

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Alcatel-Lucent Service Router Default Label Advertisement

LAB 3 Section 3.1 and 3.2

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

32

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

MPLS Infrastructure and LDP Configuration/ Configuring and Verifying the Provider Core for LDP

All rights reserved © 2011 Alcatel-Lucent

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

33

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 33

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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). Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

34

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 34

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

35

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 35

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Label Generation and Distribution on router R6 (egress LER)

Label Information Base (LIB) on router R6

ƒ Peer: The LDP peer’s 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

36

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 36

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

37

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 37

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Building the Label Forwarding Information Base (LFIB)

(LIB)

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 ----------------------------------------------------------------------------------

(FIB)

A:R6# show router fib 1 ========================================= 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 ----------------------------------------------------------------------------------

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

38

All rights reserved © 2011 Alcatel-Lucent

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 R6’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 38

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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). Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

39

All rights reserved © 2011 Alcatel-Lucent

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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 39

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

40

All rights reserved © 2011 Alcatel-Lucent

The slide shows router R4’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 40

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:R4# show router ldp bindings =============================================================================== 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

41

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 41

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

42

All rights reserved © 2011 Alcatel-Lucent

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 slide’s Egress entries with the previous slide’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 42

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:R4# show router ldp bindings =============================================================================== 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 -------------------------------------------------------------------------------

Label Forwarding Information Base (LFIB) on router R4

A:R4# show router fib 1 =============================================================================== Prefix Protocol NextHop ------------------------------------------------------------------------------10.10.10.6/32 OSPF 10.4.6.6 (toR6) R6 A:R4# show router ldp bindings active =============================================================================== LDP Prefix Bindings (Active) =============================================================================== Prefix Op IngLbl EgrLbl EgrIntf/LspId EgrNextHop ------------------------------------------------------------------------------10.10.10.6/32 Swap 131070 131071 1/1/4 10.4.6.6

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

43

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 43

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:R4# show router ldp bindings =============================================================================== 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

44

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 44

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Label Bindings Received on router R1 (ingress LER)

Label Forwarding Information Base (LFIB) on router R1

A:R1# show router fib 1 =============================================================================== Prefix Protocol NextHop ------------------------------------------------------------------------------10.10.10.6/32 OSPF 10.1.2.2 (toR2) R2 A:R1# show router ldp bindings active =============================================================================== LDP Prefix Bindings (Active) =============================================================================== Prefix Op IngLbl EgrLbl EgrIntf/LspId EgrNextHop ------------------------------------------------------------------------------10.10.10.6/32 Push -131068 1/1/4 10.1.2.2

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

45

All rights reserved © 2011 Alcatel-Lucent

As illustrated in the table above: ƒ Router R1 receives a label binding for prefix 10.10.10.6/32 from router R2 (131068 in the egress column). ƒ Router R4 receives a label binding for prefix 10.10.10.6/32 from router R3 (131067 in the egress column). 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 45

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:R1# show router ldp bindings =============================================================================== 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 ---------------------------------------------------------------------------------

A:R1# show router ldp bindings active =============================================================================== Prefix Op IngLbl EgrLbl EgrIntf/LspId EgrNextHop ------------------------------------------------------------------------------10.10.10.6/32 Push -131068 1/1/4 10.1.2.2

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

46

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 46

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Data Plane Revisited ― Label Push Operation on router R1

A:R2# show router ldp bindings active =============================================================================== Prefix Op IngLbl EgrLbl EgrIntf/LspId EgrNextHop ------------------------------------------------------------------------------10.10.10.6/32 Swap 131068 131070 1/1/2 10.2.4.4

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

47

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 47

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Data Plane Revisited ― Label Swap Operation on router R2

A:R4# show router ldp bindings active =============================================================================== Prefix Op IngLbl EgrLbl EgrIntf/LspId EgrNextHop ------------------------------------------------------------------------------10.10.10.6/32 Swap 131070 131071 1/1/4 10.4.6.6

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

48

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 48

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Data Plane Revisited ― Label Swap Operation on router R4

A:R6# show router ldp bindings active =============================================================================== Prefix Op IngLbl EgrLbl EgrIntf/LspId EgrNextHop ------------------------------------------------------------------------------10.10.10.6/32 Pop 131071 ----

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

49

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 49

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Data Plane Revisited ― Label Pop Operation on router R6

A:R1# show router ldp bindings 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

50

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 50

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Full LIB View on router R1 ― All Label Bindings

A:R1# show router ldp bindings active =============================================================================== Prefix Op IngLbl EgrLbl EgrIntf/LspId EgrNextHop ------------------------------------------------------------------------------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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

51

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 51

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Full LFIB View on router R1 ― All Possibilities

A:R1# show router ldp bindings active ------------------------------------------------------------------------------10.10.10.6/32 Swap 131066 131068 1/1/4 10.1.2.2 -------------------------------------------------------------------------------

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

52

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 52

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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 ===============================================================================

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

53

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 53

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

End Result ― Full-Mesh of LDP Tunnels (router R1 as ingress LER)

A:R4# show router tunnel-table =============================================================================== Destination Owner Encap TunnelId Pref 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 ===============================================================================

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

54

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 54

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

55

All rights reserved © 2011 Alcatel-Lucent

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 Seq=1, send from intf toR2, reply from 10.10.10.6 udp-data-len=32 ttl=255 rtt=3.31ms rc=3 (EgressRtr) Seq=2, send from intf toR2, reply from 10.10.10.6 udp-data-len=32 ttl=255 rtt=3.19ms rc=3 (EgressRtr) Seq=3, send from intf toR2, reply from 10.10.10.6 udp-data-len=32 ttl=255 rtt=3.20ms rc=3 (EgressRtr)

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 55

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

---- 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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

56

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 56

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

MPLS OAM Tools ― LSP-Ping: MPLS Echo Request

ƒ MPLS Echo Reply packets are sent unlabeled (IP-routed).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

57

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 57

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.19ms rc=8(DSRtrMatchLabel) rtt=3.80ms rc=3(EgressRtr)

ƒ Used to gather hop information along the tunnel’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

58

All rights reserved © 2011 Alcatel-Lucent

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 LSR’s, 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 58

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

59

All rights reserved © 2011 Alcatel-Lucent

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 packet’s contents in the control plane.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 59

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

LSP-Trace ― MPLS Echo Request to router R2

ƒ Router R2 sends back an MPLS Echo Reply. ƒ The Echo Reply packet is IP-routed. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

60

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 60

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

LSP-Trace ― MPLS Echo Reply from router R2

ƒ Router R1 sends MPLS Echo Request with MPLS TTL = 2 ƒ Router R4 analyzes the request and sends back a reply. ƒ The Echo Reply packet is IP-routed. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

61

All rights reserved © 2011 Alcatel-Lucent

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 packet’s 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. The Echo Reply packet is unlabeled and IP routed, as in the case of LSP-Ping. Router R4 is not the egress router for prefix 10.10.10.6/32, so the LSP-Trace operation needs to continue.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 61

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

LSP-Trace ― MPLS Echo Request and Reply To and From R4

ƒ Router R1 sends MPLS Echo Request with MPLS TTL = 3 ƒ Router R6 analyzes the request and sends back a reply. ƒ The Echo Reply packet is IP-routed. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

62

All rights reserved © 2011 Alcatel-Lucent

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 packet’s 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. The Echo Reply packet is unlabeled and IP routed, as in the case of LSP-Ping. Router R6 is the egress router for the prefix, so the LSP-Trace operation stops.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 62

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

LSP-Trace ― MPLS Echo Request and Reply To and From Router R6

Section Summary

This section covered: ƒ LDP Peer Discovery ƒ LDP Session Establishment ƒ LDP Label Distribution ƒ LDP Transport Tunnel (LSP) creation ƒ OAM LSP-Ping and LSP-Traceroute

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

63

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 63

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ LIB and LFIB Maintenance

Module 3 ― Label Distribution Protocol

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 2 — Additional LDP Features

Alcatel-Lucent Multiprotocol Label Switching v2.1

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

65

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 65

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

66

All rights reserved © 2011 Alcatel-Lucent

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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 66

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Equal-Cost Multi-Path (ECMP)

LFIB on router R1 Without ECMP Enabled

A:R1# show router fib 1 =============================================================================== Prefix Protocol NextHop ------------------------------------------------------------------------------10.10.10.6/32 OSPF 10.1.2.2 (toR2) R2 A:R1# show router ldp bindings active =============================================================================== LDP Prefix Bindings (Active) =============================================================================== Prefix Op IngLbl EgrLbl EgrIntf/LspId EgrNextHop ------------------------------------------------------------------------------10.10.10.6/32 Push -131068 1/1/4 10.1.2.2

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

67

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 67

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:R1# show router ldp bindings =============================================================================== 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

68

All rights reserved © 2011 Alcatel-Lucent

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 provider’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 68

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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 - 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

69

All rights reserved © 2011 Alcatel-Lucent

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 today’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 69

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute



LFIB on router R1 With ECMP Enabled

A:R1# show router fib 1 =============================================================================== Prefix Protocol NextHop ------------------------------------------------------------------------------10.10.10.6/32 OSPF 10.1.2.2 (toR2) R2 10.1.3.3 (toR3) R3 A:R1# show router ldp bindings active =============================================================================== LDP Prefix Bindings (Active) =============================================================================== Prefix Op IngLbl EgrLbl EgrIntf/LspId EgrNextHop ------------------------------------------------------------------------------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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

70

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 70

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:R1# show router ldp bindings =============================================================================== 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 R1’s 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

71

All rights reserved © 2011 Alcatel-Lucent

After ECMP is enabled, router R1’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 71

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Data Forwarding With ECMP Enabled

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

72

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

LAB 3 Section 3.3 Enabling LDP ECMP

All rights reserved © 2011 Alcatel-Lucent

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

73

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 73

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Distributing Additional Prefixes via Export Policy

Configuring and Verifying Loopback Interfaces Configure the interfaces

Verify the prefixes in the local FIB A:R6# show router fib 1 ========================================= 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)

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

74

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 74

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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"

Alcatel-Lucent Multiprotocol Label Switching v2.1

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

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 75

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

*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 prefix-list "loopbacks" 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 prefix-list "loopbacks" 2 exit 5 action accept exit exit exit ----------------------------------------------

6

A:R6# show router fib 1 ========================================= 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)

A:R6# show router ldp bindings =============================================================================== 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 ---

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

76

All rights reserved © 2011 Alcatel-Lucent

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 policy’s “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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 76

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

77

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 77

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Rejecting Prefixes via Import Policy

Configuring a Policy To Reject All Prefixes

*A:R6>configure router ldp import "LDP_import"

Alcatel-Lucent Multiprotocol Label Switching v2.1

Enter “edit” mode Arbitrary policy name Implicit

Exit “edit” mode (make the changes effective)

Apply the policy to LDP as an import policy

Module 3 |

78

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 78

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

*A:R6>configure router policy-options begin policy-statement "LDP_import" entry 10 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

79

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 79

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:R4# show router ldp bindings active =============================================================================== LDP Prefix Bindings (Active) =============================================================================== Prefix Op IngLbl EgrLbl EgrIntf/LspId EgrNextHop ------------------------------------------------------------------------------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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

80

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 80

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Label Withdraw and Release Messages

A:R6>config>router>ospf# -------------------------------area 0.0.0.1 interface system exit interface toR4 exit interface LP1 exit interface LP2 exit exit

A:R4>config>router>ospf# -------------------------------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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

81

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 81

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Multi-Area IGP with Route Aggregation (Summarization)

A:R2# show router fib 1 ========================================= Prefix Protocol NextHop ----------------------------------------............... ...... 192.168.6.0/24 OSPF 10.2.4.4 (toR4)

A:R2# show router ldp bindings Prefix Peer IngLbl EgrLbl =================================================== 192.168.6.1/32 10.10.10.4 -131065 192.168.6.2/32 10.10.10.4 -131064

A:R2# show router ldp bindings active Prefix Op IngLbl EgrLbl =============================================

LDP needs an exact match in the FIB

Alcatel-Lucent Multiprotocol Label Switching v2.1



Module 3 |

82

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 82

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

The Need for LDP Exact Prefix Match

LDP Aggregate Prefix Match Feature

A:R2# show router fib 1 ========================================= Prefix Protocol NextHop ----------------------------------------............... ...... 192.168.6.0/24 OSPF 10.2.4.4 (toR4)

A:R2# show router ldp bindings active 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

83

All rights reserved © 2011 Alcatel-Lucent

The configure router ldp aggregate-prefix-match command can be used to allow the router to resolve the specific LDP advertised prefixes to the FIB’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 83

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

*A:R2>configure router ldp aggregate-prefix-match

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

84

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

LAB 3 Section 3.4 Applying Export Policy for Label Distribution

All rights reserved © 2011 Alcatel-Lucent

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

85

All rights reserved © 2011 Alcatel-Lucent

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 VPN’s 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 .

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 85

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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). Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

86

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 86

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Targeted LDP (T-LDP) Overview

ƒ Process is similar to Link LDP. ƒ The difference is that the UDP discovery (hello) messages are sent via unicast. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

87

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 87

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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 ......... .. ..

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

88

All rights reserved © 2011 Alcatel-Lucent

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 router’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 88

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

89

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 89

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

*A:R1>config>router>ldp# ---------------------------------------------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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

90

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 90

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

91

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 91

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

*A:R1>config>router>ldp# -------------------------------------------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 Msg Sent Msg Recv Up Time -----------------------------------------------------------------------------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 Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

92

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 92

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

*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

*A:R2>config>router>ldp# ---------------------------------------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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

93

All rights reserved © 2011 Alcatel-Lucent

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 93

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

*A:R1>config>router>ldp# ---------------------------------------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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

94

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Type 0x0001

All rights reserved © 2011 Alcatel-Lucent

The table above provides a list of all the supported LDP messages.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 94

Section Summary

ƒ This section provided an overview on: y ECMP for LDP y LDP Export and Import Policy Implementation y LDP aggregate-prefix-match feature y Targeted LDP y LDP Authentication

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

95

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 95

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

96

All rights reserved © 2011 Alcatel-Lucent

Module 3 – Page 96

Module Summary (cont’d)

ƒ An LDP router needs a System ID configured to form an adjacency ƒ An LDP router needs an IGP route to its peer’s transport address in order to create a session ƒ LDP signaling informs adjacent nodes of the labels to be used to forward traffic between them

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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 don’t need to match between adjacent LDP peers

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

97

All rights reserved © 2011 Alcatel-Lucent

Module 3 – Page 97

Module Summary (cont’d)

ƒ 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

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

98

All rights reserved © 2011 Alcatel-Lucent

Module 3 – Page 98

Module Summary (cont’d)

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

99

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ SR OS routers enable targeted sessions by default.

All rights reserved © 2011 Alcatel-Lucent

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?

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 |

100

All rights reserved © 2011 Alcatel-Lucent

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 LSR’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 100

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

4. What is the port number used for UDP based LDP messages?

Learning Assessment (cont’d)

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? Alcatel-Lucent Multiprotocol Label Switching v2.1

9.

Module 3 |

101

All rights reserved © 2011 Alcatel-Lucent

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 other’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 3 – Page 101

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

11. In order to create an LDP session, peer routers must have an IGP route to which of the other’s addresses?

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

www.alcatel-lucent.com

3FL-30635-AAAA-ZZZZA Edition 01

Alcatel-Lucent Multiprotocol Label Switching

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Module 4 — Resource Reservation Protocol (RSVP)

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 1

Module Objectives

Upon successful completion of this module, you should be able 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

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.alcatel-lucent.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 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 2

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ Explain LSP signaling using RSVP.

Module 4 - Resource Reservation Protocol

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 1 — Control Plane Overview

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 3

Section Objectives

In this section we will: ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

4

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 4

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

5

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 5

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ Not a routing protocol, but works with the routing protocols.

RSVP–TE (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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

6

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 6

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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 LSP’s are only signaled when explicitly requested.

ƒ Conservative Label Retention y Labels are cleared if not needed. ƒ Path and Reservation messages used to signal LSP’s. ƒ Session states maintained on all routers along the path of an LSP.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

7

All rights reserved © 2011 Alcatel-Lucent

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 LSP’s. 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 7

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

8

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 8

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

9

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 9

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

10

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 10

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ Configure the interfaces for MPLS ƒ Enable the RSVP context

ƒ 10.10.10.x/32 addresses are the system (default loopback) interface addresses. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

11

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 11

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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 A:R1>config>router>ospf# -------------------------------area 0.0.0.0 interface system exit interface toR2 interface-type p2p* exit interface toR3 interface-type p2p* exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

12

All rights reserved © 2011 Alcatel-Lucent

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 router’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 12

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

13

All rights reserved © 2011 Alcatel-Lucent

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 LSP’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 13

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:R1>config>router>mpls# -------------------------------interface "system" exit interface "toR2" exit interface "toR3" exit

Enabling and verifying MPLS & RSVP *A:R1# show router status =========================================================== Admin State Oper State ----------------------------------------------------------..... ..... ...... MPLS Down Down RSVP Down Down

*A:R1# show router status =========================================================== 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

14

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 14

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

*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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

15

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 15

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

16

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 16

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

17

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 17

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:R1>config>router>mpls# -------------------------------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:

RSVP Objects (Information Blocks)

............

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

18

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 18

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute



ƒ If the RSVP message does not list any hops, the IGP forwarding table is used to forward the PATH message at each router. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

19

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 19

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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 R1’s egress interface IP address. ƒ The “LABEL REQUEST” object indicates that router R1 expects a label. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

20

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 20

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

A:R2# show router fib 1 ================================= Prefix Protocol NextHop --------------------------------............... ...... 10.10.10.6/32 OSPF 10.2.4.4 (toR4)

Module 4 |

21

All rights reserved © 2011 Alcatel-Lucent

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 R1’s (the upstream router’s) 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 R2’s outgoing interface IP address, 10.2.4.2. The process of forwarding the PATH message is similar for router R4.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 21

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

22

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 22

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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 router’s egress interface IP address (advertised previously in the HOP object of the PATH message, and stored in the PSB). Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

23

All rights reserved © 2011 Alcatel-Lucent

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 neighbor’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 23

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

24

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 24

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.” Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

25

All rights reserved © 2011 Alcatel-Lucent

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 router’s (R4’s) egress interface IP address, which is 10.2.4.4. Label 131,064 is reserved and advertised by router R4.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 25

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.” Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

26

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 26

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

27

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 27

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

*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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

28

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 28

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

29

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 29

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

*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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

30

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 30

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

31

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 31

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

*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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

32

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 32

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

33

All rights reserved © 2011 Alcatel-Lucent

RSVP message types other than PATH and RESV messages are presented above. These different message types are examined later in the module.

Alcatel-Lucent Multiprotocol Label Switching v2.1

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

34

All rights reserved © 2011 Alcatel-Lucent

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 session’s resources.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 34

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

35

All rights reserved © 2011 Alcatel-Lucent

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 router’s (R1) response to LSP failure will be discussed in the following modules.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 35

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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 path’s bandwidth reservations (covered in Module 5). Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

36

All rights reserved © 2011 Alcatel-Lucent

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 problem’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 36

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

37

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 37

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

38

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 38

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

39

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 39

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

: [1..65535]

*A:R1>config>router>rsvp# keep-multiplier ? - keep-multiplier - 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

40

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 40

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute



MPLS OAM ― LSP-Ping and LSP-Trace

*A:R1# oam lsp-ping "to_R6“ LSP-PING to_R6: 92 bytes MPLS payload Seq=1, send from intf toR2, reply from 10.10.10.6 udp-data-len=32 ttl=255 rtt=3.27ms rc=3 (EgressRtr)

*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=1.57ms rc=8(DSRtrMatchLabel) rtt=2.24ms rc=8(DSRtrMatchLabel) rtt=3.13ms rc=3(EgressRtr)

ƒ Similar functionality as described in Module 3. ƒ The LSP-Name must be specified in the commands.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

41

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 41

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

---- LSP to_R6 PING Statistics ---1 packets sent, 1 packets received, 0.00% packet loss round-trip min = 3.27ms, avg = 3.27ms, max = 3.27ms, stddev = 0.000ms

Section Summary This section covered: ƒ 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 Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

42

All rights reserved © 2011 Alcatel-Lucent

ƒ 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 router’s 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 PSB’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 42

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 43

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

44

All rights reserved © 2011 Alcatel-Lucent

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 router’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 44

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ Refresh-Time Randomization (RFC 2205 – Section 3.7)

ƒ To maintain the LSP’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

45

All rights reserved © 2011 Alcatel-Lucent

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 45

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

46

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 46

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

47

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 47

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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 - 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

48

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 48

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute



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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

49

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 49

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

*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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

50

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 50

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

51

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 51

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

*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-ID’s of all active sessions ƒ If “Reliable Delivery” is also enabled, the initial RSVP messages during LSP establishment are ACKnowledged.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

52

All rights reserved © 2011 Alcatel-Lucent

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 router’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 52

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

53

All rights reserved © 2011 Alcatel-Lucent

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

1

2

3

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

|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 53

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

54

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 54

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

55

All rights reserved © 2011 Alcatel-Lucent

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.”

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 55

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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 ----------------------------------------------

: [1..100]

*A:R1>config>router>rsvp# rapid-retry-limit - no rapid-retry-limit - rapid-retry-limit

: [1..6]

Alcatel-Lucent Multiprotocol Label Switching v2.1

Restore default Default: 5 (500 ms)

Restore default Default: 3 (retries)

Module 4 |

56

All rights reserved © 2011 Alcatel-Lucent

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 neighbor’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 56

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

*A:R1>config>router>rsvp# rapid-retransmit-time - no rapid-retransmit-time - rapid-retransmit-time

*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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

57

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 57

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Verifying Refresh-Reduction capability in the CLI

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

58

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Lab 4 ― IGP-Based RSVP LSP Establishment

All rights reserved © 2011 Alcatel-Lucent

Module 4 – Page 58

Section Summary

This section covered: ƒ RSVP Hello Extensions ƒ RSVP Refresh Overhead Reductions • Message ID • Reliable Delivery Using ACK Messages • Summary Refresh Messages

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

59

All rights reserved © 2011 Alcatel-Lucent

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 59

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

60

All rights reserved © 2011 Alcatel-Lucent

Module 4 – Page 60

Module Summary (cont’d)

ƒ 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.

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

61

All rights reserved © 2011 Alcatel-Lucent

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?

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 |

62

All rights reserved © 2011 Alcatel-Lucent

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? Downstream on Demand 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 62

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

3. Which RSVP object reduces refresh message processing by allowing the receiver to easily identify a message that contains unchanged state information?

Learning Assessment (cont’d)

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

9.

Module 4 |

63

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 4 – Page 63

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

12. Which three combined values identify a unique RSVP session?

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

www.alcatel-lucent.com

3FL-30635-AAAA-ZZZZA Edition 01

Alcatel-Lucent Multiprotocol Label Switching

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Module 5 — Traffic Engineering

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 1

Module Objectives

Upon successful completion of this module, you should be able 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

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.alcatel-lucent.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 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 2

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

y MPLS bandwidth management features

Module 5 ― MPLS Traffic Engineering

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 1 — MPLS Traffic Engineering Fundamentals

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 3

Section Objectives

In this section we will: ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

4

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 4

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

5

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 5

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

6

All rights reserved © 2011 Alcatel-Lucent

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 forwarding’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 6

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

— 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

7

All rights reserved © 2011 Alcatel-Lucent

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 course’s last module discusses several TE resiliency features and MPLS protection mechanisms in great detail.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 7

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

8

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 8

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

9

All rights reserved © 2011 Alcatel-Lucent

Rather than administratively defining the entire LSP path, an administrator can control an LSP’s 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 link’s cost. The cost is usually a function of the link’s bandwidth, and in general, the higher the link’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 9

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

10

All rights reserved © 2011 Alcatel-Lucent

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 customer’s Service Level Agreement (SLA), or based on predicted maximum, or average bandwidth use. The LSP Head-End uses a link’s 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 IGP’s chosen best of the remaining paths to the destination.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 10

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

11

All rights reserved © 2011 Alcatel-Lucent

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 router’s data plane. Best network design practices dictate that the operator use congruent QoS and Bandwidth reservation policies for better network resource usage predictability.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 11

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

12

All rights reserved © 2011 Alcatel-Lucent

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 network’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 12

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

13

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 13

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

14

All rights reserved © 2011 Alcatel-Lucent

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 LSP’s traffic.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 14

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

15

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 15

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

TE-Metric

ƒ Allows us to create secondary and/or FRR LSP paths that are automatically disjointed from the primary path for maximum resiliency. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

16

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 16

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

17

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 17

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

18

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 18

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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 LSA’s is not defined in the RFC.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

19

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 19

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

20

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 20

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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 LSA’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

21

All rights reserved © 2011 Alcatel-Lucent

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 packet’s 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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 21

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

22

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 22

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

23

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 23

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

24

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 24

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

25

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 25

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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)

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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) Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

26

All rights reserved © 2011 Alcatel-Lucent

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)

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 26

A:R4>config>router>ospf# -------------------------------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

Alcatel-Lucent Multiprotocol Label Switching v2.1

(point-to-point) (Router ID of neighbor)

(equal to IGP metric by default) Module 5 |

27

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 27

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

28

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 28

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

29

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 29

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ The subscription percentage is a change in the booking factor of the link. Possible values: 0-1000

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

30

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 30

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

31

All rights reserved © 2011 Alcatel-Lucent

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”.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 31

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 8 different LSP priorities can exist (See Section 3).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

32

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 32

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

33

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 33

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

34

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 34

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Example ― Single Administrative Group Membership

ƒ Admin Group Sub TLV: 00000410 (1040) Decimal (2^10 + 2^4) Hexadecimal

ƒ The 4th and 10th bit positions are set in the Admin Group Sub TLV. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

35

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 35

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Example ― Multiple Administrative Group Memberships

ƒ Opaque LSAs are flooded through the area and the Traffic Engineering Databases are populated. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

36

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 36

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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)

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

37

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 37

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

38

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 38

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

(Router ID of R4) (Interface toR2) (Interface toR6) (Interface toR5)

39

All rights reserved © 2011 Alcatel-Lucent

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 LSA’s header information. The actual information the LSA carries may be observed by adding the detail keyword, illustrated on the following pages.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 39

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

40

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 40

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:R1# show router ospf opaque-database adv-router 10.10.10.4 detail

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)

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

41

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 41

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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)

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

42

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 42

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

3

4

Administrative group (color)

6

4

IPv4 interface address

8

4

IPv4 neighbor address

9

4

Maximum link bandwidth

10

4

Reservable link bandwidth

11

32

Unreserved bandwidth

18

3

TE Default metric

250-254

Reserved for vendor specific extensions

255

Reserved for future expansion

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

43

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 43

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

44

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 44

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

45

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 45

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

46

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 46

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

47

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 47

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

48

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 48

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

49

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 49

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

50

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 50

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

51

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 51

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Signaling the Path Calculated by CSPF

Internet Protocol: Source: 10.10.10.1 Dest. : 10.10.10.6 Options: Router Alert RSVP PATH Message: ............

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

52

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 52

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Explicit Route Object (ERO)

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

53

All rights reserved © 2011 Alcatel-Lucent

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 LSP’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 53

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

54

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 54

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

55

All rights reserved © 2011 Alcatel-Lucent

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 Revertıve behavior, an LSP’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 55

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

56

All rights reserved © 2011 Alcatel-Lucent

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 56

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ Operation of the CSPF algorithm

Module 5 — MPLS Traffic Engineering

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 2 — Configuring Traffic Engineering in a Flat (Single Area) Network

Alcatel-Lucent Multiprotocol Label Switching v2.1

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

58

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 58

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

59

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 59

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

y Defining additional attributes for the links:

A:R1>config>router>mpls# -------------------------------admin-group “GREEN" 4

A:R4>config>router>mpls# -------------------------------admin-group “GREEN" 4 interface "toR6" admin-group “GREEN" exit

ƒ The Administrative Group name-to-value associations should be consistent on all the routers. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

60

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 60

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Administrative Group Definitions

A:R1>config>router>mpls# -------------------------------interface "toR3“ te-metric 400 exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

A:R4>config>router>mpls# -------------------------------interface "toR6" te-metric 500 exit

Module 5 |

61

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 61

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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”.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

62

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 62

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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 Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

63

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 63

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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

A:R1>config>router>mpls# -------------------------------path "empty_list"

A:R1>config>router>mpls# -------------------------------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 . Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

64

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 64

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

65

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 65

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Fully Loose LSP path Establishment

CSPF Calculated Loose Path — CLI View *A:R1# show router mpls lsp "to_R6" path detail ------------------------------------------------------------------------------LSP to_R6 Path empty_list ------------------------------------------------------------------------------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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

66

All rights reserved © 2011 Alcatel-Lucent

The show router mpls lsp path [] 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 66

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ExplicitHops: No Hops Specified

Fully Strict Path Configuration

A:R1>config>router>mpls# -------------------------------path “fully_strict_A"

A:R1>config>router>mpls# -------------------------------path “fully_strict_B"

hop 10 10.1.3.3 strict

hop 10 10.10.10.3 strict

hop 20 10.3.5.5 strict

hop 20 10.10.10.5 strict

hop 30 10.5.6.6 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

67

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 67

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

exit

path “fully_strict_A" hop 10 10.1.3.3 strict hop 20 10.3.5.5 strict hop 30 10.5.6.6 strict 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“

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

68

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 68

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Fully Strict LSP path Establishment

Fully Strict LSP path with CSPF disabled — CLI View *A:R1# show router mpls lsp "to_R6" path detail ------------------------------------------------------------------------------LSP to_R6 Path empty_list ------------------------------------------------------------------------------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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

69

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 69

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ExplicitHops: 10.1.3.3

Mix of Loose and Strict Hops Path Configuration A:R1>config>router>mpls# -------------------------------path “mixed-1"

A:R1>config>router>mpls# -------------------------------path “mixed-2"

hop 10 10.1.2.2 strict

hop 10 10.10.10.5 loose

hop 20 10.2.4.4 strict

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

70

All rights reserved © 2011 Alcatel-Lucent

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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 70

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

lsp "to_R6“

Mixed Hop LSP path Establishment

hop 10 10.1.2.2 strict hop 20 10.2.4.4 strict 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”

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

71

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 71

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

path “mixed-1"

Using TE-Metric in CSPF calculation

A:R1>config>router>mpls# -------------------------------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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

72

All rights reserved © 2011 Alcatel-Lucent

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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 72

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

73

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 73

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

74

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 74

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ Router R5 cannot be a strict hop for router R1. ƒ No PATH message is sent from router R1.

Module 5 |

75

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 75

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Failure Case–1 ― Invalid Strict First Hop

path “wrong-2" hop 10 10.1.3.3 strict hop 20 10.3.5.3 strict hop 30 10.5.6.5 strict no shutdown exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ 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

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 76

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Failure Case–2A ― Incorrect Hop (CSPF NOT Enabled)

Failure Case–2A ― 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 Up Time: 0d 00:00:00 Path Dn Time: 0d 00:02:11 . . . . . . . . . . . . . . . . . . . . . . . . . . Path Trans : 2 CSPF Queries: 0 Failure Code: badNode Failure Node: 10.1.3.3 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) Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

77

All rights reserved © 2011 Alcatel-Lucent

The path failure information is visible in the show router mpls lsp path [] 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 77

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

*A:R1# show router mpls lsp "to_R6" path detail

path “wrong-2" hop 10 10.1.3.3 strict hop 20 10.3.5.3 strict hop 30 10.5.6.5 strict no shutdown exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ CSPF detects the error on router R1. ƒ No PATH message is sent.

Module 5 |

78

All rights reserved © 2011 Alcatel-Lucent

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”.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 78

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Failure Case–2B ― Incorrect Hop (CSPF Enabled)

Failure Case–2B — 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 Up Time: 0d 00:00:00 Path Dn Time: 0d 00:02:11 . . . . . . . . . . . . . . . . . . . . . . . . . . Path Trans : 2 CSPF Queries: 1 Failure Code: noCspfRouteToDestination Failure Node: 10.10.10.1 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). Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

79

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 79

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

*A:R1# show router mpls lsp "to_R6" path detail

path “fully_strict_A" hop 10 10.1.3.3 strict hop 20 10.3.5.5 strict hop 30 10.5.6.6 strict no shutdown exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ 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

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 80

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Failure Case–3A ― Strict Hop Link Failure (CSPF NOT Enabled)

path “fully_strict_A" hop 10 10.1.3.3 strict hop 20 10.3.5.5 strict hop 30 10.5.6.6 strict no shutdown exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ CSPF detects the problem. ƒ No PATH message is sent. ƒ LSP cannot be established as long as the link is down. Module 5 |

81

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 81

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Failure Case–3B ― 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

82

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 82

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Failure Case–4A ― 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

83

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 83

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Failure Case–4A — CSPF View

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Failure Case–4B : 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

84

All rights reserved © 2011 Alcatel-Lucent

Module 5 - Page 84

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Failure Case–4B — 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

85

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

86

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 86

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

-> Ingr: -> Ingr: -> Ingr:

10.1.3.3 10.3.5.5 10.5.6.6

(met 100) (met 100) (met 100)

Module 5 |

87

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 87

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

CSPF Path Check Example–1 ― 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

-> -> -> ->

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

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 88

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

CSPF Path Check Example–2 ― Using “Exclude-Bitmap”

*A:R1# tools perform router mpls cspf to 10.10.10.6 include-bitmap 16

Admin Group Sub TLV: 00000010 (16)

MINOR: CLI No CSPF path to "10.10.10.6" with specified constraints.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

89

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 89

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Admin Group Sub TLV: 00000010 (16)

-> -> -> ->

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

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 90

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

CSPF Path Check Example–4 ― Different Source Router

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

91

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

LAB 5 Section 5.1 Link Coloring for Constraint-Based LSP Tunnels

All rights reserved © 2011 Alcatel-Lucent

Module 5 - Page 91

Section Summary

In this section we covered: ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

92

All rights reserved © 2011 Alcatel-Lucent

ƒ 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 path [] 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 92

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ Specifying constraints in LSP path configuration

Module 5 ― MPLS Traffic Engineering

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 3 — Working with Bandwidth Reservations

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 93

Section Objectives

In this section we will discuss: ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

94

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 94

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

95

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 95

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

96

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 96

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

97

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 97

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

98

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 98

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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 (config>router>rsvp# -------------------------------interface “toR6” subscription 40

lsp "to_R6“ to 10.10.10.6 primary “fully_loose“ bandwidth 600 exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ 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

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 101

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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 Up Time: 0d 00:00:00 Path Dn Time: 0d 00:00:23 . . . . . . . . . . . . . . . . . . . . . . . . . . Path Trans : 0 CSPF Queries: 0 Failure Code: admissionControlError Failure Node: 10.2.4.4

ƒ 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 Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

102

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 102

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

*A:R1# show router mpls lsp "to_R6" path detail

lsp "to_R6“ to 10.10.10.6 cspf primary “fully_loose“ bandwidth 600 exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ CSPF finds an available path for the LSP. ƒ LSP is signaled. Module 5 |

103

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 103

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

104

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 104

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

105

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 105

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

106

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 106

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

107

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 107

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

108

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 108

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

109

* *

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 109

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

110

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 110

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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). Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

111

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 111

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

112

All rights reserved © 2011 Alcatel-Lucent

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 112

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

113

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 113

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ LSP is established with 600M of reservation. ƒ Only 100M is available on the upper links due to other reservations.

Module 5 |

114

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 114

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

MBB Example — Initial Condition

lsp "to_R6“ to 10.10.10.6 cspf primary “fully_loose“ bandwidth 800 exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ Change configured bandwidth while LSP in service ƒ CSPF looks for an available path with the new bandwidth constraint. Module 5 |

115

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 115

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

116

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 116

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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 Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

117

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 117

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

118

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 118

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

119

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 119

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

120

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 120

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

121

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 121

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

122

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 122

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Example ― Initial Condition

lsp “3“ to 10.10.10.6 cspf primary “fully_loose“ bandwidth

300

exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ CSPF randomly chooses one of the available paths for LSP 3. ƒ Unbalanced bandwidth reservation on the links. Module 5 |

123

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 123

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Example ― LSP 3 Without Least-Fill

lsp “3“ to 10.10.10.6 cspf least-fill primary “fully_loose“ bandwidth

300

exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ CSPF chooses the least occupied path when least-fill is enabled. ƒ Leads to more balanced bandwidth distribution. Module 5 |

124

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 124

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

125

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 125

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

126

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 126

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

127

All rights reserved © 2011 Alcatel-Lucent

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 link’s 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 link’s 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 link’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 127

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

128

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 128

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

129

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 129

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

priorities per LSP

Preemption Example — Second LSP Set-up

* Assume equal setup and hold

ƒ LSP 2 is also setup on the shortest IGP path, reserving 300M at priority level 5.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

130

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 130

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

priorities per LSP

Preemption Example — Third LSP Set-up

* Assume equal setup and hold

ƒ The shortest path does not have the 500M at P7 level that LSP 3 requests, so the LSP is established on the other path. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

131

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 131

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

priorities per LSP

Example — Fourth LSP Setup Attempt Without Priorities

* Assume equal setup and hold

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

132

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 132

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

priorities per LSP

ƒ Both paths have the required bandwidth at P3 level. ƒ CSPF chooses the lowest cost path. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

133

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 133

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

134

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 134

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

135

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 135

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

. . . . . . . . . . . . . . . . . . . . . . . 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

All rights reserved © 2011 Alcatel-Lucent

The Make-Before-Break state of an LSP is displayed in the show router mpls lsp path [] 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 136

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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

ƒ The default retry-timer is 30 seconds. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

137

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 137

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

configure router rsvp preemption-timer

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

138

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 138

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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

7

Network Control

NC

Intended for network control traffic.

6

High-1

H1

Intended for network control traffic or delay/jitter sensitive traffic.

5

Expedited

EF

4

High-2

H2

3

Low-1

L1

Intended for assured traffic. Also the default priority for network management traffic.

2

Assured

AF

Intended for assured traffic.

1

Low-2

L2

0

Best Effort

BE

Alcatel-Lucent Multiprotocol Label Switching v2.1

Intended for delay/jitter sensitive traffic.

Intended for best effort traffic.

Module 5 |

139

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 139

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

140

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 140

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

141

All rights reserved © 2011 Alcatel-Lucent

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 LSP’s based on the packet’s 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 141

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

142

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 142

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

143

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 143

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

144

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 144

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

145

All rights reserved © 2011 Alcatel-Lucent

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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 145

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

146

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 146

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Maximum Allocation Model (MAM)

ƒ ƒ ƒ ƒ

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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

147

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 147

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

148

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 148

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

149

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 149

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

150

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 150

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

151

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 151

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

152

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 152

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

153

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 153

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

DiffServ-TE Example ― Bandwidth Allocation Using RDM

ƒ The first data LSP gets established reserving 200M that is allocated for CT0.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

154

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 154

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

155

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 155

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

156

All rights reserved © 2011 Alcatel-Lucent

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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 156

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ ƒ ƒ ƒ

Allows sharing between CTs More complex More efficient bandwidth allocation Different preemption priorities required between LSPs from different CTs Module 5 |

157

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 157

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

- Configure bandwidth percent for class type - Configure TE Class

Module 5 |

158

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 158

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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) Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

159

All rights reserved © 2011 Alcatel-Lucent

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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 159

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. A:R1# show router ospf opaque-database adv-router 10.10.10.1 detail

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

160

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 160

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

161

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 161

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

162

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 162

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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 Path Up Time: 0d 00:00:00 Path Dn Time: 0d 00:00:49 SetupPriori*: 6 Hold Priori*: 6 Preference : n/a Bandwidth : 100 Mbps Oper Bw : 0 Mbps Hop Limit : 255 Class Type : 1 ................................... ........................ Failure Code: invCtAndSetupAndHoldPri Failure Node: 10.10.10.1

(Invalid Class-Type and Setup and Hold Priority) Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

163

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 163

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

164

All rights reserved © 2011 Alcatel-Lucent

The reserved and unreserved bandwidth values for each TE class can be observed in the show router rsvp interface 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 164

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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)

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

165

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 165

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:R1# show router ospf opaque-database adv-router 10.10.10.1 detail

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

166

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

LAB 5 Section 5.2 and 5.3 DiffServ TE LSP ― MAM and RDM

All rights reserved © 2011 Alcatel-Lucent

Module 5 - Page 166

Section Summary

In this section we covered: ƒ 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 Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

167

All rights reserved © 2011 Alcatel-Lucent

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 167

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ IGP TE Bandwidth Update Trigger using: y “Up” and “Down” Thresholds y “On-CAC-Failure” y Periodic Update Timer

Section Summary

In this section we covered: ƒ 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: — Maximum Allocation Model (MAM) — Russian Dolls Model (RDM)

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

168

All rights reserved © 2011 Alcatel-Lucent

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 168

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ Diffserv Aware Traffic Engineering (Diffserv-TE) using:

Module 5 — MPLS Traffic Engineering

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 4 — Traffic Engineering in a Hierarchical Network

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 169

Section Objectives

In this section we will discuss:

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

170

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 170

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

171

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 171

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

172

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 172

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

173

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 173

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

`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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

174

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 174

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

`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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

175

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 175

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

`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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

176

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 176

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

`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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

177

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 177

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

`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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

178

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 178

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

179

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 179

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

`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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

180

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 180

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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 PE—ABR y ABR—ABR Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

181

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 181

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

`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 PE—ABR y ABR—ABR

ƒ 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 tunneling exit exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

182

All rights reserved © 2011 Alcatel-Lucent

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 182

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

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

All rights reserved © 2011 Alcatel-Lucent

An overall view of configuring T-LDP sessions in the example LDP-over-RSVP deployment is seen in the figure above.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 183

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

`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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

184

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 184

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

185

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 185

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

========================================================================== Prefix Op IngLbl EgrLbl EgrIntf/LspId EgrNextHop -------------------------------------------------------------------------. . . . . . . 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). Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

186

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 186

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

187

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 187

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

LDP-over-RSVP Resiliency ― Multiple ABRs

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

188

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

LAB 5 Section 5.4 Configuring LDP over RSVP across OSPF Areas

All rights reserved © 2011 Alcatel-Lucent

Module 5 - Page 188

Section Summary

In this section we covered: ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

189

All rights reserved © 2011 Alcatel-Lucent

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 189

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ The Traffic Engineering limitations in Hierarchical IGP deployments.

Module 5 ― MPLS Traffic Engineering

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 5 — MPLS for IP Routing (MPLS shortcuts)

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 190

Section Objectives

In this section we will discuss: ƒ LDP-Shortcut for BGP next-hops ƒ RSVP-TE Shortcut for BGP next-hops ƒ LDP-Shortcut for IP forwarding ƒ 6PE – IPv6 tunnels over MPLS

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

191

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 191

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

A:R6# show router fib 1 ================================= Prefix Protocol NextHop --------------------------------192.168.1.0/24 BGP 10.6.7.7 (toR7)

192.168.10.0/24 10.6.7.7 (toR7)

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

192

BGP

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 192

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ 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

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 193

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Propagating Information Through Internal BGP

A:R6# show router fib 1 ================================= 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)

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

194

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 194

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

195

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 195

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

196

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 196

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

197

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 197

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ If only one of the shortcut options (LDP or RSVP-TE) is set, the router can only use the specified type of tunnel.

A:R6# show router tunnel-table ====================================================================== Destination Owner Encap TunnelId Pref 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

198

All rights reserved © 2011 Alcatel-Lucent

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]

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 198

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Tunnel Table Entries

A:R6# show router fib 1 ================================= 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 10.10.10.6 (Transport:RSVP LSP:148)

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

199

All rights reserved © 2011 Alcatel-Lucent

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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 199

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

RSVP-TE LSP Tunneling for BGP Traffic

A:R6# show router fib 1 ================================= Prefix Protocol NextHop --------------------------------192.168.1.0/24 BGP 10.10.10.6 (Transport:LDP)

. .

. .

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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 10.10.10.6 (Transport:LDP)

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

200

All rights reserved © 2011 Alcatel-Lucent

The FIB output above displays the resolution of BGP next-hop addresses via an LDP Transport Tunnel.

Alcatel-Lucent Multiprotocol Label Switching v2.1

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

201

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 201

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

MPLS Shortcuts for IGP Route Resolution

A:R1# show router fib 1 ================================= Prefix Protocol NextHop --------------------------------192.168.1.0/24 OSPF 10.10.10.6 (Transport:RSVP LSP:148)

192.168.10.0/24 OSPF 10.10.10.6 (Transport:RSVP LSP:148)

Alcatel-Lucent Multiprotocol Label Switching v2.1

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

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 202

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

RSVP-TE Shortcuts for IGP Route Resolution

A:R1# show router fib 1 ================================= Prefix Protocol NextHop --------------------------------192.168.1.0/24 OSPF 10.10.10.6 (Transport:RSVP LSP:148) 10.10.10.6 (Transport:RSVP LSP:149) 192.168.10.0/24 OSPF 10.10.10.6 (Transport:RSVP LSP:148) 10.10.10.6 (Transport:RSVP LSP:149)

Alcatel-Lucent Multiprotocol Label Switching v2.1

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

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 203

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

RSVP-TE Shortcuts for IGP Route Resolution

A:R6# show router fib 1 ================================= Prefix Protocol NextHop --------------------------------192.168.1.0/24 OSPF 192.168.1.0 (Transport:LDP)

192.168.10.0/24 OSPF 192.168.10.0 (Transport:LDP)

Alcatel-Lucent Multiprotocol Label Switching v2.1

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

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 204

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

LDP Shortcuts for IGP Route Resolution

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

205

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

LAB 5 Section 5.5 Configure RSVP for IP Routing

All rights reserved © 2011 Alcatel-Lucent

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

206

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 206

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ ƒ ƒ ƒ

ƒ ƒ ƒ ƒ ƒ

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

207

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 207

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

208

All rights reserved © 2011 Alcatel-Lucent

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" interface-type point-to-point exit exit ---------------------------------------------*A:R1>config>router>ospf3# show router policy "bgp_6pe" entry 10 from protocol bgp family ipv6 exit action accept exit exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 208

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

*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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

209

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 209

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

210

All rights reserved © 2011 Alcatel-Lucent

The slide above shows the route for R7’s 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 ===============================================================================

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 210

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

*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 round-trip min = 4.20ms, avg = 4.20ms, max = 4.20ms, stddev = 0.000ms

ƒ IPv6 routes are received from remote network ƒ R8 is able to ping R7 across the provider network

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

211

All rights reserved © 2011 Alcatel-Lucent

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 provider’s 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 provider’s 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

#-------------------------------------------------echo "ISIS Configuration" #-------------------------------------------------isis level-capability level-2 area-id 49 interface "system" interface-type point-to-point exit interface "toR1" interface-type point-to-point exit interface "toR4" interface-type point-to-point exit exit #-------------------------------------------------echo "LDP Configuration" #-------------------------------------------------ldp interface-parameters interface "toR1" exit interface "toR4" exit exit targeted-session exit exit ----------------------------------------------

Module 5 - Page 211

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

*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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

212

All rights reserved © 2011 Alcatel-Lucent

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 212

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

213

All rights reserved © 2011 Alcatel-Lucent

Module 5 - Page 213

Module Summary (cont’d)

ƒ 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.

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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 LSP’s path based on the TED and, if needed, LSDB.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

214

All rights reserved © 2011 Alcatel-Lucent

Module 5 - Page 214

Module Summary (cont’d)

ƒ 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.

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

215

All rights reserved © 2011 Alcatel-Lucent

Module 5 - Page 215

Module Summary (cont’d)

ƒ 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.

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

216

All rights reserved © 2011 Alcatel-Lucent

Module 5 - Page 216

Module Summary (cont’d)

ƒ 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.

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

217

All rights reserved © 2011 Alcatel-Lucent

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? Alcatel-Lucent Multiprotocol Label Switching v2.1

1.

Module 5 |

218

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 218

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

3. What factor determines the extent of propagation for a Link State packet?

Learning Assessment (cont’d)

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). Alcatel-Lucent Multiprotocol Label Switching v2.1

8.

Module 5 |

219

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 219

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

10. ___ TLVs carry bandwidth, admin group membership, TE metric, and other sub-TLVs.

Learning Assessment (cont’d)

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? Alcatel-Lucent Multiprotocol Label Switching v2.1

15.

Module 5 |

220

All rights reserved © 2011 Alcatel-Lucent

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 LSP’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 220

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

18. Administrative constraints may be _______ on a link.

Learning Assessment (cont’d)

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 LSP’s 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 LSP’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 |

221

All rights reserved © 2011 Alcatel-Lucent

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 LSP’s 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 LSP’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 221

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

24. Which reservation style creates a single reservation over a link that is shared by an associated set of LSP paths?

Learning Assessment (cont’d)

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

29.

Module 5 |

222

All rights reserved © 2011 Alcatel-Lucent

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 LSP’s requirements, or if there is another available path toward the tail-end meeting the new LSP’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 5 - Page 222

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

30. _____ sessions between LERs and ABRs and between ABRs and ABRs _____ together individual intra-area RSVP-TE LSPs.

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

www.alcatel-lucent.com

3FL-30635-AAAA-ZZZZA Edition 01

Alcatel-Lucent Multiprotocol Label Switching

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Module 6 — Resiliency

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 1

Module Objectives

Upon successful completion of this module, you should be able to: ƒ Describe the factors that influence MPLS convergence.

ƒ Understand and deploy Fast Reroute. ƒ Describe LSP Re-Optimization techniques.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

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.alcatel-lucent.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 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 2

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ Understand and deploy resiliency, using Standby Secondary and Non-Standby Secondary paths.

Module 6 ― Resiliency

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 1 — MPLS Convergence Overview

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 3

Section Objectives

In this section we will: ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

4

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 4

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

y Secondary LSP-Path protection with RSVP-TE

Network Resiliency Overview

ƒ Network reliability is a major concern. ƒ Failures can happen at any time (Murphy’s Law). ƒ Short reaction and restoration times are highly desirable.

ƒ MPLS can bring superior convergence performance.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

5

All rights reserved © 2011 Alcatel-Lucent

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 provider’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 5

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

6

All rights reserved © 2011 Alcatel-Lucent

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 IGP’s convergence factors limit its resiliency.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 6

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

7

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 7

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

8

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 8

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

9

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 9

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

10

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 10

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

11

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 11

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

12

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 12

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

13

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 13

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

14

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 14

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

15

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 15

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

16

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 16

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

17

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 17

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

18

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 18

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

19

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 19

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

20

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 20

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

LDP Convergence Example: Convergence

Module 6 ― Resiliency

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 2 — LDP-IGP Sync

Alcatel-Lucent Multiprotocol Label Switching v2.1

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

22

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 22

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

23

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 23

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

24

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 24

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

25

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 25

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

26

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 26

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

27

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 27

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:R1>configure router interface “toR2” ldp-sync-timer

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

28

All rights reserved © 2011 Alcatel-Lucent

Use the show router ospf interface 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 28

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

29

All rights reserved © 2011 Alcatel-Lucent

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 29

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

In this section we covered: ƒ Factors that influence total network convergence: y Failure detection y Failure propagation y Service recovery

Module 6 — Resiliency

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 2 — Secondary LSP-Path Protection

Alcatel-Lucent Multiprotocol Label Switching v2.1

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

31

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 31

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

In this section we will discuss: ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

32

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 32

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

33

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 33

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Standby Secondary ― Primary LSP-Path setup

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Standby Secondary ― Secondary LSP-Path setup

lsp "to_R6“ cspf to 10.10.10.6 primary “prim_path” exit secondary “stdby_sec” standby exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ A standby secondary is configured. ƒ It is signaled right after the primary LSPPath. Module 6 |

34

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

35

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 35

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

36

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 36

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

37

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 37

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Non-Standby Secondary ― Primary LSP-Path Setup

lsp "to_R6“ cspf to 10.10.10.6 primary “prim_path” exit secondary “stdby_sec” exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ A non-standby secondary LSP-Path is configured. ƒ As long as the primary LSP-Path is up it is not signaled. Module 6 |

38

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 38

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

39

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 39

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

40

All rights reserved © 2011 Alcatel-Lucent

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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 40

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

41

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 41

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

42

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 42

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

43

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 43

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

— 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 secondary “Secondary-2” standby exit

ƒ Traffic is on the primary LSP-Path. ƒ Two standby secondary LSP-Paths are available.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

44

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 44

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Default Secondary LSP-Path Selection ― Initial Condition

primary “prim_path” exit secondary “Secondary-1” standby exit secondary “Secondary-2” standby exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ Primary goes down. ƒ The standby secondary LSP with the longest uptime is made active. Module 6 |

45

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 45

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Default Secondary LSP-Path Selection ― Primary Down

primary “prim_path” exit secondary “Secondary-1” standby exit secondary “Secondary-2” standby exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ The active secondary goes down. ƒ Router R1 switches the traffic to the other standby secondary. Module 6 |

46

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 46

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Default Secondary LSP-Path Selection ― Standby-1 Down

primary “prim_path” exit secondary “Secondary-1” standby exit secondary “Secondary-2” standby exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ The previously active standby secondary comes back up. ƒ Router R1 does not switch the traffic back to it. Module 6 |

47

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 47

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Default Secondary LSP-Path Selection ― Standby-1 Recovered

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Default Secondary LSP-Path Selection ― Primary Recovered

primary “prim_path” exit secondary “Secondary-1” standby exit secondary “Secondary-2” standby exit

ƒ Primary LSP-Path comes back. ƒ Router R1 switches the traffic back to the primary.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

48

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

49

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 49

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ Default value: 255

primary “prim_path” exit secondary “Secondary-1” standby path-preference 10 exit secondary “Secondary-2” standby path-preference 20 exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ 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

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 50

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Standby Secondary Path Preference ― Initial Condition

Standby Secondary Path Preference ― Primary Down

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

primary “prim_path” exit secondary “Secondary-1” standby path-preference 10 exit secondary “Secondary-2” standby path-preference 20 exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ Primary goes down. ƒ Router R1 selects the standby secondary path with the lower path preference. Module 6 |

51

All rights reserved © 2011 Alcatel-Lucent

The primary LSP-Path experiences link failure between R4-R6. Router R1 activates Secondary-1, which has the lower path-preference value.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 51

primary “prim_path” exit secondary “Secondary-1” standby path-preference 10 exit secondary “Secondary-2” standby path-preference 20 exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ The active secondary goes down. ƒ Router R1 switches the traffic to the other standby secondary. Module 6 |

52

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 52

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Standby Secondary Path Preference ― Standby-1 Down

primary “prim_path” exit secondary “Secondary-1” standby path-preference 10 exit secondary “Secondary-2” standby path-preference 20 exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ The secondary with the lower precedence comes back up. ƒ Router R1 switches the traffic back to it. Module 6 |

53

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 53

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Standby Secondary Path Preference ― Standby-1 Recovered

Standby Secondary Path Preference ― Primary Recovered

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

primary “prim_path” exit secondary “Secondary-1” standby path-preference 10 exit secondary “Secondary-2” standby path-preference 20 exit

ƒ Primary LSP-Path comes back. ƒ Router R1 switches the traffic back to the primary.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

54

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 54

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

55

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

LAB 6 Section 6.1 Enabling Primary and Secondary LSP Tunnels

All rights reserved © 2011 Alcatel-Lucent

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

56

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 56

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ Multiple alternative solutions can exist, depending on the topology, administrative configuration, and so on.

Using Fully Strict Hop Path Definitions for Path Diversity

A:R1>config>router>mpls# --------------------------path “prim_path"

A:R1>config>router>mpls# --------------------------path “sec_path"

hop 1 10.1.2.2 strict

hop 1 10.1.3.3 strict

to 10.10.10.6

hop 2 10.2.4.4 strict

hop 2 10.3.5.5 strict

primary “prim_path“

hop 3 10.4.6.6 strict

hop 3 10.5.6.6 strict

exit

no shutdown exit

no shutdown exit

A:R1>config>router>mpls# --------------------------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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

57

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 57

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

no shutdown exit

A:R1>config>router>mpls# --------------------------path “prim_path"

A:R1>config>router>mpls# --------------------------path “sec_path"

hop 1 10.1.2.2 strict

hop 1 10.1.3.3 strict

hop 2 10.2.4.4 strict

hop 2 10.3.5.5 strict

hop 3 10.4.6.6 strict

hop 3 10.5.6.6 strict

no shutdown exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

no shutdown exit

Module 6 |

58

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 58

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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). Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

59

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 59

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

60

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 60

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Path Diversity Example Using Administrative Groups

Using Administrative Groups for Path Diversity

A:R2>config>router>mpls# -------------------------------admin-group “UPPER” 1 interface "toR4" admin-group “UPPER" exit interface “toR7” admin-group “UPPER” exit

A:R3>config>router>mpls# -------------------------------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.”

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

61

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 61

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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: A:R2>config>router>mpls# -------------------------------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). Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

62

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 62

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:R2>config>router>mpls# -------------------------------admin-group “UPPER” 1 admin-group “LOWER” 2 path “fully_loose-1” no shutdown exit path “fully_loose-2” no shutdown exit

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

63

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

64

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 64

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

65

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 65

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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: A:R3>config>router>mpls# -------------------------------srlg-group “SRLG-L” value 2 interface "toR5" srlg-group “SRLG-L" exit interface “toR8” admin-group “SRLG-L” exit

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:R2>config>router>mpls# -------------------------------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.”

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

66

All rights reserved © 2011 Alcatel-Lucent

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”.

Alcatel-Lucent Multiprotocol Label Switching v2.1

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: A:R1>config>router>mpls# -------------------------------lsp "to_R6“ to 10.10.10.6 cspf primary “fully_loose-1“ exit secondary “fully_loose-2“ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

67

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 67

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

A:R1>config>router>mpls# -------------------------------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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

68

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 68

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

SRLG Example ― Primary with No Constraints

primary “fully_loose-1“ bandwidth 400 least-fill exit secondary “fully_loose-2“ srlg exit

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ 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

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 69

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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 -------------------------------------------------------------------------------

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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 ===============================================================================

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

70

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

71

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 71

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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 Path Up Time: 0d 00:04:46 Path Dn Time: 0d 00:00:00 . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

72

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 72

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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 47624 to_R6::fully_loose-2 Up 10.10.10.1 10.10.10.6 155 47626 to_R6::fully_loose-3 Up ------------------------------------------------------------------------------Sessions : 3 ===============================================================================

ƒ The primary and secondary LSP-Paths share the same Tunnel ID. ƒ The primary and secondary LSP-Paths have different LSP IDs. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

73

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 73

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

*A:R1# show router rsvp session

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

74

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

LAB 6 Section 6.2 Using SRLG for Path Resiliency

All rights reserved © 2011 Alcatel-Lucent

Module 6 – Page 74

Section Summary

In this section we covered:

ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

75

All rights reserved © 2011 Alcatel-Lucent

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 75

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ MPLS resiliency, using: y Standby Secondary Paths y Non-Standby Secondary Paths

Module 6 — Resiliency

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Section 3 — MPLS Fast Reroute

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 76

Section Objectives

In this section we will: ƒ 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 Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

77

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 77

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

78

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 78

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

79

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 79

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

80

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 80

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

81

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 81

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

82

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 82

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

83

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 83

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

84

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 84

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

85

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 85

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

86

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 86

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

87

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 87

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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”

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

88

All rights reserved © 2011 Alcatel-Lucent

“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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 88

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

89

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 89

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ No extra configuration required on the other routers.

Configuring an LSP for Fast Reroute One-to-One

A:R2>config>router>mpls# -------------------------------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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

90

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 90

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

91

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 91

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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)

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

92

All rights reserved © 2011 Alcatel-Lucent

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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 92

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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 Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

93

All rights reserved © 2011 Alcatel-Lucent

The example above illustrates the options signaled in the RSVP PATH message sent from the Head-End to establish the primary LSP-Path.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 93

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

94

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 94

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

95

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 95

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

96

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 96

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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). Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

97

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 97

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

98

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 98

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

99

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 99

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

100

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 100

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

101

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 101

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

102

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 102

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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 ::_detour y For example, “to_R6::fully_loose_detour”

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

103

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 103

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

104

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 104

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

105

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 105

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

106

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 106

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Signaling the Detour Tunnel — PLR : R1

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

107

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 107

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

=============================================================================== 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

108

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 108

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Signaling the Detour Tunnel — PLR : R2

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

109

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 109

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Signaling the Detour Tunnel — PLR : R3

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

110

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 110

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

111

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 111

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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 Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

112

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 112

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

113

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 113

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ If it is able to establish a node protection tunnel, the router also sets the node-protection-available flag.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

114

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 114

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Signaling the Detour Tunnel — PLR : R1

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

115

All rights reserved © 2011 Alcatel-Lucent

The RRO is visible in the Actual Hops field of the show router mpls lsp 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 115

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

116

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 116

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

117

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 117

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Detour Merging Example — First Detour Tunnel Setup

ƒ The detour from router R1 is already established.

Alcatel-Lucent Multiprotocol Label Switching v2.1

ƒ 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

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 118

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

119

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 119

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

120

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 120

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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). Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

121

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 121

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

122

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 122

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Fast Reroute Facility Protection

Configuring an LSP for Fast Reroute Facility

A:R2>config>router>mpls# -------------------------------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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

123

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 123

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

node-protect primary “fully_loose”

CSPF View — Fast Reroute Facility and Node Protection fast-reroute facility

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

124

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 124

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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 PLR’s Next-Hop router (1 hop away) y Node-protect ― MP is the PLR’s Next-Next-Hop router (2 hops away)

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

125

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 125

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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 fast-reroute facility

ƒ Using link-protect, MP is the PLR’s next-hop router. ƒ The protection tunnel is assigned the name bypass-link10.1.2.2 (the interface IP address avoided).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

126

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 126

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

no node-protect

Merge Point Selection with FRR Facility Node-Protect fast-reroute facility

ƒ 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). Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

127

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 127

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

128

All rights reserved © 2011 Alcatel-Lucent

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 128

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

129

All rights reserved © 2011 Alcatel-Lucent

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”.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 129

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ The main objective is to use the same facility bypass tunnel for multiple LSPs.

FRR Facility Example — First LSP Setup

fast-reroute facility

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

130

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 130

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

node-protect

fast-reroute facility node-protect

ƒ Another LSP is set up that goes over the R1-R2-R3-R4 routers. ƒ FRR facility node-protect is requested.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

131

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 131

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

FRR Facility Example — Second LSP Setup

fast-reroute facility node-protect

ƒ The new LSP is associated with the existing bypass-tunnel. ƒ The “protected LSP count” of the bypass-tunnel is updated.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

132

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 132

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

FRR Facility Example — Node-Bypass on router R2

FRR Facility Example — Link-Bypass on router R3

fast-reroute facility

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

133

All rights reserved © 2011 Alcatel-Lucent

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. The “Protected LSP Count” field of the bypass tunnel is set to 1.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 133

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

node-protect

fast-reroute facility node-protect

ƒ A new bypass tunnel that avoids router R4 is established. ƒ The LSP is associated to it. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

134

All rights reserved © 2011 Alcatel-Lucent

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. The “Protected LSP Count” field of the bypass tunnel is set to 1.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 134

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

FRR Facility Example — Node-Bypass on router R3

fast-reroute facility node-protect

ƒ A new link-bypass tunnel is established on router R4. ƒ The LSP is associated to it. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

135

All rights reserved © 2011 Alcatel-Lucent

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 “Protected LSP Count” field of the bypass tunnel is set to 1. The bypass tunnel establishment process is completed for both of the protected LSPs.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 135

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

136

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 136

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

137

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 137

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

138

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 138

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

139

All rights reserved © 2011 Alcatel-Lucent

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 R7 swaps the outer bypass tunnel label with 30. 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 139

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

140

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 140

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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 Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

141

All rights reserved © 2011 Alcatel-Lucent

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 R6 swaps the outer bypass tunnel label with 70. Router R7 swaps the outer bypass tunnel label with 80. Router R7 swaps the outer bypass tunnel label with 40. 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 141

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

142

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 142

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

143

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 143

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

144

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 144

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

145

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 145

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

146

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 146

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

147

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 147

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

148

All rights reserved © 2011 Alcatel-Lucent

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 path detail” command output.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 148

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

149

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 149

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

150

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 150

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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). Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

151

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 151

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

152

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 152

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

153

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 153

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

154

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 154

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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).

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

155

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 155

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

156

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 156

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

157

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 157

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

158

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 158

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

159

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 159

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Global Resignal — MBB Switchover

ƒ The resignal timer is reset. ƒ After 30 minutes, all the active CSPF-enabled LSP-Paths will be re-evaluated. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

160

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 160

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Resetting the Resignal-Timer

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

161

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

LAB 6 Section 6.3 and 6.4 Fast Reroute Facility and One-to-One

All rights reserved © 2011 Alcatel-Lucent

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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

162

All rights reserved © 2011 Alcatel-Lucent

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 162

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

In this section we covered: ƒ Fast Reroute Protection Methods y One-to-One Detour y Facility Bypass

Section Summary (cont’d)

ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

163

All rights reserved © 2011 Alcatel-Lucent

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 163

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ RSVP-TE Fast Reroute Extensions in RFC 4090 y Fast_Reroute Object y Detour Object

Section Summary (cont’d)

ƒ 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

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

164

All rights reserved © 2011 Alcatel-Lucent

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 164

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

165

All rights reserved © 2011 Alcatel-Lucent

Module 6 – Page 165

Module Summary (cont’d)

ƒ 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.

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ SRLG allows the Head-End to choose the optimal path while ensuring the secondary and fast reroute paths don’t 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

166

All rights reserved © 2011 Alcatel-Lucent

Module 6 – Page 166

Module Summary (cont’d)

ƒ 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.

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

167

All rights reserved © 2011 Alcatel-Lucent

Module 6 – Page 167

Module Summary (cont’d)

ƒ 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

168

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

ƒ The resignal-timer, if set, allows the Head-End to reoptimize the primary LSP path.

All rights reserved © 2011 Alcatel-Lucent

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?

Alcatel-Lucent Multiprotocol Label Switching v2.1

1.

Module 6 |

169

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 169

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

8.

Module 6 |

170

All rights reserved © 2011 Alcatel-Lucent

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 LSP’s 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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 170

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

Learning Assessment (cont’d)

Learning Assessment (cont’d)

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 ________ __________. Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 |

171

All rights reserved © 2011 Alcatel-Lucent

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.

Alcatel-Lucent Multiprotocol Label Switching v2.1

Module 6 – Page 171

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

15. The Head-End router needs to know the _____ path of the protected path before signaling the protection tunnel.

Alcatel-Lucent Confidential for Internal Use ONLY - Do Not Distribute

www.alcatel-lucent.com

3FL-30635-AAAA-ZZZZA Edition 01