76 8600 50123f 8600 smart routers MPLS configuration guide

Date Description of Changes 76.8600-50123F 17.06.2015 Added in this revision: • Support of 8665 Smart Router • 3.6 BGP Multipath in S-MPLS Applications • 4.9 BGP Multipath over S-MPLS Co

MPLS Applications Configuration Guide

76.8600-50123F 17.06.2015

Revision History

Document No Date Description of Changes

76.8600-50123F 17.06.2015 Added in this revision:

• Support of 8665 Smart Router

• 3.6 BGP Multipath in S-MPLS Applications

• 4.9 BGP Multipath over S-MPLS Configuration Example

Updates or/and changes applied in:

• 1.9.4 8600 NEs FRRwith addition of LU1 and clarifiedFRR facility backup operation with RSVP-TE loadbalancing

• 5.7 8600 NEs MPLS-TP Functionalitywhere LU1 is added

• 3 Seamless MPLS Applications

Enhancements applied in:

• 2 MPLS Configuration Examples

• 4 Seamless MPLS Configuration Examples

76.8600-50123E 06.11.2014 Added S-MPLS functionality3 Seamless MPLS Applications

Added4 Seamless MPLS Configuration Examples.Added support of 8602 Smart Router and 8615 Smart Router.Update and changes applied to1.9.4 8600 NEs FRR.Updates applied in5.7 8600 NEs MPLS-TP Functionality.76.8600-50123D 04.03.2014 Renewed related documentation table in8600 Smart Routers

Technical Documentation.Added MPLS-TP functionality overview in5 MPLS-TPApplications

Added MPLS-TP configuration examples, status in6 MPLS-TPConfiguration Examples

AddedMPLS-TP Troubleshooting.Updates and additions applied in1.4 MPLS ProtectionSwitching

Added IP load balancing support in 8600 NEs in1.5 RSVP-TETraffic Load Balancing

Changes applied in1.9 Fast Reroute Including:

• Updates in1.9.2 FRR Operation and Applications

• Rework and additions applied in 1.9.3 FRR Provisioningand BFD

The functionality described in this document for 8615 Smart Router is also applicable to 8615 Smart Router stacked, unless otherwise stated.

© 2015 Coriant All rights reserved.

This manual is protected by U.S and international copyright laws, conventions and treaties Your right to use this manual is subject to limitations and restrictions imposed by applicable licenses and copyright laws Unauthorized reproduction, modification,

distribution, display or other use of this manual may result in criminal and civil penalties.

The specifications and information regarding the products in this manual are subject to change without notice All statements, information, and recommendations in this manual are believed to be accurate but are presented without warranty of any kind,

express or implied Users must take full responsibility for their application of any products.

Adobe ® Reader ® are registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.

Terms and Abbreviations Term Explanation

AC sideinterface

Attachment Circuit side interface A physical or virtual interface, which connects a

CE device to PE router and is bound to some network service, e.g IP VPN or PWE3

AN Access Node

AS Autonomous SystemASBR Autonomous System Boundary RouterATM Asynchronous Transfer Mode

BA Behavior Aggregate

BC Bandwidth Constraint

BD Business Data

BE Best EffortBFD Bidirectional Forwarding DetectionBGP Border Gateway Protocol

BN Border NodeCAC Connection Admission ControlCDC Control and DC Power Card There are two types: CDC1 and CDC2

CC Continuity Check

CE Customer EquipmentCLI Command Line Interface

CS Class SelectorCSG Customer Site GatewayCSPF Constrained Shortest Path First

E-LSP EXP-Inferred-PSC LSPs, or Explicitly TC-Encoded-PSC LSPsERO Explicit Route Object

FD Forward Defect

FFD Fast Failure DetectionFIB Forwarding Information Base

FM Fault ManagementFMC Fixed Mobile Convergence

FR Frame RelayFRR Fast RerouteFTN Forwarding equivalence class To Next hop label forwarding entry mapHDLC High-Level Data Link Control

IFC and up to two IFMs There are two types of IFC line cards: IFC1 and IFC2IFM Interface Module

IGP Interior Gateway ProtocolILM Incoming Label Map

IP Internet ProtocolIRB Integrated Routing and BridgingIS-IS Intermediate System to Intermediate SystemLDP Label Distribution Protocol

LER Label Edge RouterL-LSP Label-Only-Inferred-PSC LSP

LM Line module in 8607 Smart Router, 8609 Smart Router and 8611 Smart Router

LM Packet Loss Measurement (OAM)LOC Loss of Continuity

LSP Label Switched PathLSR Label Switch RouterLU1 Line Unit in 8665 Smart RouterMAC Media Access Control

MAM Maximum Allocation Model

MP Merging PointMP-BGP Multiprotocol Border Gateway ProtocolMP-iBGP Multiprotocol iBGP

MPLS Multiprotocol Label SwitchingMPLS-TP Multiprotocol Label Switching Transport Profile

MS-PWE3 Multi-Segment PWE3

NE Network Element

OA Ordered AggregateOAM Operations, Administration and MaintenanceORF Outbound Route Filter

OSPF Open Shortest Path FirstOTN Optical Transport Hierarchy

PD Priority Data

PE Provider EdgePHB Per Hop BehaviorPHP Penultimate Hop PoppingPIC Prefix Independent ConvergencePLR Point of Local Repair

P-LSP Protected LSPPLT Packet Loop TestPOS Packet over SDH/SONETPSC PHB Scheduling ClassPSC Protection State Coordination (MPLS-TP)PSN Packet Switched Network

PTP Precision Time ProtocolPWE3 Pseudowire Emulation Edge to EdgeQinQ IEEE 802.1QinQ

QoS Quality of Service

RD Reverse DefectRDI Remote Defect IndicationRDM Russian Dolls ModelRFC Request For Comments (IETF documents)RIB Routing Information Base

RR Router ReflectorRRO Record Route ObjectRSVP-TE Resource Reservation Protocol with Traffic Engineering Extensions

RT Real TimeSAFI Subsequent Address Family IdentifierSCTP Stream Control Transmission ProtocolSDH Synchronous Digital HierarchyS-MPLS Seamless MPLS

SONET Synchronous Optical Network

SPF Shortest Path FirstSS-PWE3 Single-Segment PWE3TCP Transmission Control ProtocolTDM Time Division Multiplexing

TE Traffic Engineering

TN Transport NodeToS Type of ServiceTrunk side

interface

Interface of a router, which is used on the PSN sideUDP User Datagram Protocol

VC Virtual CircuitVID VLAN IDVoIP Voice over Internet ProtocolVPLS Virtual Private LAN ServiceVPN Virtual Private NetworkVRF Virtual Routing and ForwardingVSI Virtual Switching InstanceWTR Wait to Restore

Table of Contents

About This Manual 13

Objectives 13

Audience 13

8600 Smart Routers Technical Documentation 13

Interface Numbering Conventions 17

Document Conventions 17

Documentation Feedback 17

8600 Smart Routers Discontinued Products 18

1 MPLS Overview 19

1.1 Label Distribution 20

1.1.1 LDP 21

1.1.2 RSVP-TE 21

1.2 MPLS Support of Differentiated Services 21

1.2.1 EXP-Inferred-PSC LSPs, or Explicitly TC-Encoded-PSC LSPs (E-LSP) 21

1.2.2 Label-Only-Inferred-PSC LSPs (L-LSP) 22

1.2.3 DiffServ Tunneling Models over MPLS 22

1.3 LSP Affinity Constraints 26

1.4 MPLS Protection Switching 28

1.4.1 MPLS Local Protection 29

1.4.2 RSVP-TE based 1:1 Protection Switching 29

1.5 RSVP-TE Traffic Load Balancing 29

1.6 MPLS Traffic Engineering 30

1.7 DiffServ-Aware MPLS Traffic Engineering 31

1.7.1 Maximum Allocation Model 31

1.7.2 Russian Dolls Model 32

1.8 MPLS MTU Concept 32

1.9 Fast Reroute 33

1.9.1 Overview 33

1.9.2 FRR Operation and Applications 33

1.9.3 FRR Provisioning and BFD 39

1.9.4 8600 NEs FRR 40

1.9.5 Fault Management 40

1.10 MPLS References 41

2 MPLS Configuration Examples 42

2.1 LDP Configuration 42

2.2 Explicitly Routed RSVP-TE LSPs 42

2.2.1 RSVP-TE Configuration 43

2.2.2 E-LSP Configuration 44

2.2.3 L-LSP Configuration 46

2.2.4 RSVP-TE Path Protection Configuration 47

2.2.5 RSVP-TE Traffic Load Balancing Configuration 48

2.2.6 Controlled RSVP-TE Tunnel Selection 48

2.2.7 DiffServ Tunnelling Model Configuration 50

2.3 DS-TE Network Example 50

2.4 FRR CLI Configuration Examples 65

2.4.1 FRR One-to-One 66

2.4.2 Facility Backup 72

3 Seamless MPLS Applications 74

3.1 Overview 74

3.2 S-MPLS Networking 75

3.2.1 Transport Layer 76

3.2.2 End-to-End Service Layer 77

3.2.3 BGP Labeled Unicast Scalability 77

3.3 8600 Implementation of S-MPLS 77

3.3.1 S-MPLS Limitations and Restrictions 79

3.4 Operation 79

3.4.1 Transport Layer 82

3.4.2 Service Layer 83

3.5 Protection and Services Restorations 83

3.6 BGP Multipath in S-MPLS Applications 83

3.6.1 Operation 84

3.6.2 BGP Multipath Limitations and Restrictions 87

3.7 S-MPLS References 88

4 Seamless MPLS Configuration Examples 89

4.1 Configuration Summary 90

4.2 Node CSG1 Configuration 91

4.2.1 Configuration Prerequisites 92

4.2.2 S-MPLS Transport and BGP Configuration 93

4.2.3 End-to-End Services Configuration at the Local AS 94

4.3 Node R31 Configuration 95

4.3.1 Configuration Prerequisites 95

4.3.2 S-MPLS Transport and BGP Configuration 98

4.4 Node R32 Configuration 99

4.4.1 Configuration Prerequisites 99

4.4.2 S-MPLS Transport and BGP Configuration 101

4.5 Node R11/ASBR Configuration 102

4.5.1 Configuration Prerequisites 102

4.5.2 S-MPLS Transport and BGP Configuration 104

4.6 Node R12/ASBR Configuration 105

4.6.1 Configuration Prerequisites 105

4.6.2 S-MPLS Transport and BGP Configuration 107

4.7 Node PE Configuration 108

4.7.1 End-to-End Services Configuration at Remote AS 109

4.8 Configuration Check and Diagnostics 111

4.8.1 Node CSG1 112

4.8.2 Node R31 115

4.8.3 Node R11 116

4.8.4 Node ASBR11 117

4.8.5 Node PE 118

4.9 BGP Multipath over S-MPLS Configuration Example 119

4.9.1 Configuration Summary 120

4.9.2 Node CSG1 Configuration 120

4.9.3 Node R31 Configuration 121

4.9.4 Node R32 Configuration 121

4.9.5 Node R11/ASBR Configuration 121

4.9.6 R12/ASBR Configuration 121

4.9.7 Configuration Check and Diagnostics 122

4.10 BGP Multipath LSP Traceroute 131

5 MPLS-TP Applications 133

5.1 Overview 133

5.2 MPLS-TP Tunnel Types 134

5.2.1 MPLS-TP Tunnel LSP Types 135

5.3 MPLS-TP Identifiers 135

5.4 MPLS-TP Operation, Administration and Maintenance 137

5.4.1 MPLS-TP Proactive Monitoring 137

5.5 MPLS-TP Linear Protection 140

5.5.1 Operation 140

5.5.2 PSC Protocol 142

5.5.3 Protection Group Alarms 147

5.6 MPLS-TP Network Connectivity and Services 147

5.6.1 Map-Route 148

5.6.2 Connectivity and Signalling Management 149

5.6.3 Interworking with IP/MPLS 149

5.7 8600 NEs MPLS-TP Functionality 151

5.8 MPLS-TP Provisioning 152

5.8.1 Global and Node IDs 152

5.8.2 Tunnels 153

5.8.3 Point to Point Interface 154

5.8.4 Label Allocation 154

5.8.5 MPLS-TP Provisioning Considerations 157

5.8.6 MPLS-TP Protection 157

5.9 Limitations and Restrictions 158

5.10 MPLS-TP References 158

6 MPLS-TP Configuration Examples 159

6.1 Node P1 Configuration 160

6.1.1 Interface Configuration 160

6.1.2 Global and Node IDs 161

6.1.3 Primary Tunnels Configuration 161

6.1.4 Backup Tunnels Configuration 162

6.1.5 Protection Configuration 163

6.2 Node P3 Configuration 163

6.2.1 Interfaces Configuration 163

6.2.2 Tunnels Configuration 164

6.3 Node P4 Configuration 164

6.3.1 Interface Configuration 165

6.3.2 Tunnels Configuration 165

6.4 Node P2 Configuration 166

6.4.1 Interfaces Configuration 166

6.4.2 Tunnels Configuration 166

6.5 Node P5 Configuration 167

6.5.1 Interface Configuration 167

6.5.2 Tunnels Configuration 167

6.6 Node P6 Configuration 168

6.6.1 Interface Configuration 168

6.6.2 Global and Node IDs 168

6.6.3 Primary Tunnel Configuration 169

6.6.4 Backup Tunnel Configuration 169

6.6.5 P6 Protection Configuration 170

6.7 Node P7 Configuration 170

6.7.1 Interface Configuration 170

6.7.2 Global and Node IDs 170

6.7.3 Primary Tunnel Configuration 170

6.7.4 Backup Tunnel Configuration 171

6.7.5 P7 Protection Configuration 171

6.8 Provisioning Services 172

6.8.1 Static PWE3 Configuration 172

6.8.2 Dynamic PWE3 Configuration 173

6.9 MPLS-TP Configuration Status 175

6.9.1 MPLS-TP Tunnels 175

6.9.2 MPLS-TP Protection Groups 179

6.9.3 Services 180

6.10 Operation Status in Fault Conditions 182

6.10.1 Link Failure 182

6.10.2 Mis-Connectivity 184

6.10.3 Primary Tunnel Failure 187

6.10.4 Backup Tunnel Failure 189

6.10.5 Failure on Both Paths 189

6.11 Manual/Forced Switchover 190

MPLS-TP Troubleshooting 193

MPLS-TP Tunnel Failure 193

Loss of Data Traffic 195

MPLS-TP Protection and PSC Failure 195

About This Manual

This chapter discusses the objectives and intended audience of this manual, 8600 Smart Routers

MPLS Applications Configuration Guide and consists of the following sections:

This manual provides an overview of the 8600 Smart Routers MPLS applications and instructions

on how to configure them with a Command-line Interface (CLI) using a router’s console or remoteterminal (telnet)

Audience

This manual is designed for administration personnel for configuring 8600 Smart Routers functionswith CLI On the other hand, 8000 Intelligent Network Manager provides access to equal

functionality for administration personnel with a graphical user interface

It is assumed that the readers have a basic understanding of Ethernet, POS, IP, MPLS, IP VPNconcepts This manual also assumes that the readers are familiar with the following protocols:

• IP routing

• UDP

• TCP

• Differentiated Services

8600 Smart Routers Technical Documentation

The document numbering scheme consists of the document ID, indicated by numbers, and thedocument revision, indicated by a letter The references in the Related Documentation table beloware generic and include only the document ID To make sure the references point to the latestavailable document versions, please refer to the relevant product document program on the Tellabsand Coriant Portal by navigating towww.portal.tellabs.com> Product Documentation & Software

> Data Networking > 8600 Smart Routers > Technical Documentation

Document Title Description

8600 Smart RoutersATM and TDM Configuration Guide(76.8600-50110)

Provides an overview of 8600 NEs PWE3 applications,including types, Single-Segment and Multi-Segment; PWE3Redundancy; ATM applications, including PWE3 tunnelling,Traffic Management, Fault Management OAM, protection andTDM applications as well as instructions on how to configurethem with CLI

8600 Smart RoutersBoot and Mini-ApplicationsEmbedded Software Release Notes(76.8600-50108)

Provides information related to the boot and mini-applicationssoftware of 8605 Smart Router, 8607 Smart Router, 8609Smart Router, 8611 Smart Router, 8620 Smart Router, 8630Smart Router and 8660 Smart Router as well as the installationinstructions

8600 Smart RoutersCLI Commands Manual(76.8600-50117)

Provides commands available to configure, monitor and maintain

8600 system with CLI

8600 Smart RoutersEmbedded Software Release Notes

8600 Smart Routers SR7.0 Embedded Software Release Notes(76.8670-50177) for the following products:

Provides an overview of 8600 system HW inventory, softwaremanagement, equipment protection 1+1 (CDC and SCM) as well

as instructions on how to configure them with CLI

8600 Smart RoutersEthernet Configuration Guide (76

8600-50133)

Provides an overview of 8600 system Ethernet applications,including interfaces; Ethernet forwarding (MAC Switching,Ethernet PWE3, IRB, VLAN, VPLS); Ethernet OAM; LAG;ELP as well as instructions on how to configure them with CLI

8600 Smart Routers Smart RoutersFault Management ConfigurationGuide (76.8600-50115)

Provides an overview of 8600 system fault management,including fault source, types and status as well as instructions onhow to configure it with CLI

8600 Smart RoutersFrame Relay Configuration Guide(76.8600-50120)

Provides an overview of 8600 system Frame Relay applications,including interfaces; Performance Monitoring; protection; TrafficManagement as well as instructions on how to configure themwith CLI

8600 Smart RoutersHardware Installation Guide(76.8600-40039)

Provides guidance on mechanical installation, cooling,grounding, powering, cabling, maintenance, commissioning andESW downloading

Document Title Description

8600 Smart RoutersInterface Configuration Guides The Interface Configuration Guides provides an overview of the8600 NEs interface functions, including NE supported interface

types and equipping; interface features; configuration options andoperating modes; fault management; performance monitoring;interface configuration layers and port protocols as well asinstructions on how to configure them with CLI The followinginterface configuration guides are available:

• 8600 Smart Routers Network Interfaces ConfigurationGuide (76.8600-50161) (for 8602 Smart Router, 8615 SmartRouter and 8665 Smart Router)

• 8609 Smart Router and 8611 Smart Router FP7.0 InterfaceConfiguration Guide (76.8670-50179)

• 8600 Smart Routers FP7.0 Interface Configuration Guide(76.8670-50180) (for 8630 Smart Router and 8660 SmartRouter)

8600 Smart Routers

IP Forwarding and TrafficManagement Configuration Guide(76.8600-50122)

Provides an overview of 8600 NEs IP, forwarding and trafficmanagement functionality, including: IP addressing; IP hosting(ARP, DHCP); IP routing (static); ACL; Differentiated Services(Policing, Queue Management, Shaping) as well as instructions

on how to configure them with CLI

8600 Smart RoutersManagement CommunicationsConfiguration Guide

(76.8600-50125)

Provides an overview of 8600 system managementcommunications functions, including communication protocols:BMP; FTP; RADIUS; SNMP; SSH; TELNET as well asinstructions for configuring them with CLI

8600 Smart RoutersMobile Optimization ConfigurationGuide (76.8600-50100)

Provides an overview of 8600 system Mobile Optimizationapplications as well as instructions on how to configure themwith CLI

8600 Smart RoutersMPLS Applications ConfigurationGuide (76.8600-50123)

Provides an overview of 8600 NEs MPLS applications (includingFRR (one-to-one and facility backup); LDP; protection andTraffic Engineering), MPLS-TP applications (including OAM,linear protection), S-MPLS applications as well as instructions

on how to configure them with CLI

8600 Smart RoutersPerformance Counters ReferenceGuide (76.8600-50143)

Provides an overview of 8600 system supported performancecounters

Document Title Description

8600 Smart RoutersReference Manuals The reference manuals describe the 8600 network elementfeatures including:

• NE enclosure, baseboard, power supply modules, andinterfaces in 8602 Smart Router FP7.0 Reference Manual(76.8670-40130)

• NE enclosure, baseboard, power supply modules, interfacesand physical LM types in 8609 Smart Router FP7.0 Refer-ence Manual

• NE enclosure, baseboard, power supply modules, SCMs, HMand LM types in 8611 Smart Router FP7.0 Reference Manual

• NE enclosure, baseboard, power supply modules, and terfaces in 8615 Smart Router FP7.0 Reference Manual(76.8670-40132)

in-• NE subrack, fan modules, CDCs, line cards and IFMs in 8630Smart Router FP7.0 Reference Manual

• NE subrack, fan modules, CDCs, line cards and IFMs in 8660Smart Router FP7.0 Reference Manual

• NE subrack, fan modules, line unit and switch unit in 8665Smart Router FP7.0 Reference Manual (76.8670-40128)

8600 Smart RoutersRouting Protocols ConfigurationGuide (76.8600-50121)

Provides an overview of 8600 NEs routing protocols, includingBFD; BGP; BGP MP; ECMP; IS-IS; OSPF and VRRP as well asinstructions on how to configure them with CLI

8600 Smart RoutersScalability Reference Manual(76.8600-50160)

Provide a summary of tested scalability limits of the 8600 SmartRouters

8600 Smart RoutersSNMP MIB Support(76.8600-50116)

Describes SNMP MIB support by the 8600 NEs and providesinformation on the supported objects and traps For furtherinformation on SNMP MIBs, see the related RFCs

8600 Smart RoutersStatistic Counters Reference Guide(76.8600-50142)

Provides an overview of 8600 system supported statistic counters

8600 Smart RoutersSynchronization ConfigurationGuide (76.8600-50114)

Provides an overview of 8600 NEs synchronization functionality,including physical layer Frequency Synchronization (SEC, EEC);PTP Frequency Synchronization; Phase-Time Synchronization(L2 and L3 applications) as well as instructions on how toconfigure them with CLI

8600 Smart RoutersTest and Measurement ConfigurationGuide (76.8600-50124)

Provides an overview of 8600 NEs measurement and connectivityverification tools, including Ethernet loopback; IP ping andtraceroute; MAC swap loopback; MPLS ping and traceroute;PLT; PWE3 loopback; VCCV (BFD, LSP ping) as well asinstructions on how to configure them with CLI

8600 Smart RoutersVPNs Configuration Guide(76.8600-50128)

Provides an overview of 8600 system virtual private network(VPN) layer 3 applications as well as instructions on how toconfigure them with CLI

8000 Intelligent Network ManagerOnline Help Provides instructions on how different operations are performedwith the 8000 Intelligent Network Manager Describes also

different parameters and controls of the 8000 Intelligent NetworkManager dialogs and windows

Note that the Online Help is not available on the Portal but it isincorporated in the 8000 Intelligent Network Manager

Interface Numbering Conventions

To be able to follow more easily the feature descriptions and configuration examples given in this

document, see also the 8600 system interface numbering and related figures described in 8600

Smart Routers CLI Commands Manual.

Document Conventions

This is a note symbol It emphasizes or supplements information in the document.

This is a caution symbol It indicates that damage to equipment is possible if the instructions are not followed.

This is a warning symbol It indicates that bodily injury is possible if the instructions are not followed.

Documentation Feedback

Please contact us to suggest improvements or to report errors in our documentation:

Email: fi-documentation@tellabs.com

8600 Smart Routers Discontinued Products

8600 Smart Routers Manufacture Discontinued (MD) notifications are available on the Tellabsand Coriant Portal,www.portal.tellabs.com > Product Documentation & Software > Data Networking > [8600 Smart Router product name] > Product Notifications.

In addition to aiding many network engineering tasks in operational Internet Protocol (IP) routinginfrastructure of the service provider, LSPs are also extremely useful on the network servicelayer, where they can be used as Virtual Private Network (VPN) tunnels through shared networkinfrastructure The MPLS-based VPN applications supported by the 8600 Network Elements (NE)

are described in 8600 Smart Routers VPNs Configuration Guide.

The following topology depicts a general overview of an MPLS network along with basic conceptsused

Fig 1 MPLS Network

MPLS Basic Concepts

Label Edge Router (LER) A router that is located at the edge of an MPLS network and it is

responsible of handling unlabeled packets, inserting/removing MPLSlabels Typically a LER can act simultaneous as ingress and egressLER for different LSPs

Label Switch Router (LSR) A router that is located in the middle of an MPLS network and

forwards packets based on MPLS labels without any IP lookup

Label-Switched Path (LSP) A connection path that is signalled end-to-end in MPLS networks

between the LER nodes

Ingress LER The headend of an LSP that is responsible of forwarding packets from

L2/IP network to MPLS network

Egress LER The LSP tail end node that is responsible of forwarding packets from

MPLS network to a L2/IP network

MPLS Label Also known as shim header, it is a stackable 4 bytes header typically

inserted between L2 and L3 header fields It is used to identifyLSPs or service instances, contains also traffic class (EXP) and TTLinformation

Push An operation of inserting a label to a packet

Pop An operation of removing an incoming label from a packet

Swap An operation of replacing the incoming label with an outgoing label

In the 8600 system, the supported LSP signaling protocols are the following:

• Label Distribution Protocol (LDP) [RFC3036]

• Resource Reservation Protocol with Traffic Engineering extensions (RSVP-TE)

In the [RFC4364] VPN application, also Multiprotocol Border Gateway Protocol (MP-BGP) is usedfor carrying labels between the ingress and egress Provider Edge (PE) nodes This topic is covered

in the 8600 Smart Routers VPNs Configuration Guide.

1.1.1 LDP

LDP is a session protocol that uses Transmission Control Protocol (TCP) as a transport layer Adiscovery mechanism based on the User Datagram Protocol (UDP) automatically builds LDPsessions between directly connected LSRs Once an LDP session is established, it distributeslabel information between the LSRs This may be done either in Downstream on Demand mode,

in which an LSR explicitly requests label information from its peer, or Downstream Unsolicitedmode, in which label information is sent without waiting for a request Only one of these modes isused at a time

RSVP-TE is a signaling protocol used for reserving labels and bandwidth across an explicitlyrouted network path For accommodating LSP construction, MPLS traffic engineering extensionshave been added to the traditional RSVP protocol used in conjunction with the IntServ Quality ofService (QoS) model These traffic engineering extensions are defined in [RFC3209] To envision

an RSVP-TE LSP tunnel, remember that it is a virtual trunk that makes one 8600 NE appear to bedirectly connected to another 8600 NE As with all LSPs, an RSVP-TE LSP is unidirectional Inorder to get bidirectional data flow between two nodes A and B, an LSP must be built first from A

to B, and then from B to A

In case the RSVP-TE tunnel LSPs are signalled with bandwidth reservations, each 8600 NE on thesignaling path performs Connection Admission Control (CAC), in order to determine whether theLSP path request can be accommodated or not If bandwidth reservations are not made, the endresult will be just an explicitly routed, point-to-point LSP tunnel between two 8600 NEs (typicallythe ones acting as edge LSRs at the edge of the MPLS network domain)

[RFC3270] defines a solution for supporting DiffServ over MPLS networks It defines two differenttypes of LSPs, which differ in the way the carried DiffServ Per Hop Behavior (PHB) SchedulingClass(es) (PSCs) are inferred:

• EXP-Inferred-PSC LSPs, or Explicitly TC-encoded-PSC LSPs (E-LSP)

• Label-Only-Inferred-PSC LSPs (L-LSP)

1.2.1 EXP-Inferred-PSC LSPs, or Explicitly TC-Encoded-PSC LSPs (E-LSP)

E-LSPs support up to eight Behavior Aggregates (BAs), i.e packets of up to 8 different PHBs The3-bit EXP field (Renamed to Traffic Class field [RFC5462]) of the MPLS shim header conveys tothe LSRs the appropriate PHB (both drop precedence and scheduling class) to be applied to thepacket The mappings between the EXP field/Traffic Class field values and the PHBs are eitherexplicitly signalled, or rely on the pre-configured mapping tables

1.2.2 Label-Only-Inferred-PSC LSPs (L-LSP)

L-LSPs transport only a single Ordered Aggregate (OA), i.e a set of BAs sharing the same orderingconstraint These include e.g packets belonging to the AF11, AF12, and AF13 PHBs This isimplemented so that the scheduling treatment of the packet (PSC) is determined from its label value,and the drop precedence is carried in the EXP bits/Traffic Class field of the MPLS shim header Theused PSC is explicitly signalled at the time of establishing an L-LSP

1.2.3 DiffServ Tunneling Models over MPLS

When traversing a label switched path, each labelled IP packet can carry at least two separateinstances of DiffServ PHB information, i.e the DiffServ Code Point (DSCP) marking on the carrieddatagram itself, and the PHB information inferred from the MPLS shim header fields In the case ofthe [RFC4364] VPN applications, there are two MPLS shim headers, and thus each VPN datagramcan carry even three different PHB markings This inherent property of MPLS LSPs allows theinner PHB information to be transparently carried over the MPLS network, which can be very usefulwhen the MPLS network domain belongs to a different QoS policy domain than the one whose IPpackets the LSP is carrying

Some MPLS networks may also make use of Penultimate Hop Popping (PHP), which means that theoutermost label is popped out already at the last hop before the egress LSR If the outermost MPLSshim header does not contain any useful label switching or DiffServ information from the point ofview of the egress LSR, it may request the penultimate LSR to perform PHP This can be done e.g.with LDP by advertising the implicit NULL label value to the penultimate LSR

Exactly how the PHB markings on the different layers can be used and interpreted at each hop ofthe traversed LSP, depends on the chosen DiffServ Tunneling Model The three models defined in[RFC3270] and supported by the 8600 system are called the Pipe Model, Short Pipe Model, and theUniform Model, of which the Pipe Model is the 8600 system default model

Example Networking Scenario

Some enterprise networks may still mark VoIP packets with the Class Selector 5 (CS5) codepoint,where only the 3 most significant bits of the DSCP field are used for selecting the forwardingtreatment The reason for not using the standardized EF codepoint for VoIP is that some legacyVoIP terminals and/or networking equipment may not even support processing of the whole 6-bitsDSCP field, but can instead only process the 3 precedence bits specified in the original IP Type ofService (ToS) octet definition

Thus, if the network of the service provider uses only the EF PHB and its standardized codepointfor VoIP, and therefore does not have any specific configurations for the Class Selector codepoints

in each and every network node, the VoIP packets may end up in the Best Effort (BE) queue (i.e.receive the Default Forwarding treatment)

In order to avoid this, the ingress LSR can, of course, use e.g QoS mapping tables or DiffServmulti-field classifiers for reclassifying the VoIP packets to the EF PHB However, if the VoIP trafficwill re-enter the network of the enterprise after the LSP is terminated, the DSCP field of the VoIPpacket should preferably not be overwritten, but the chosen MPLS domain PHB should instead beindicated only in the MPLS shim header fields

In this way, the LSRs can use the outermost, service provider controlled DiffServ informationfor their queuing decisions, while the innermost, enterprise-controlled DiffServ information getstransparently carried over the whole MPLS network domain Thus, when the LSP is terminated

in the egress LSR and the VoIP packets are delivered back into the QoS policy domain of theenterprise, the delivered packets will still be marked with the original CS5 codepoints

The following tunneling model specific examples deal only with the basic case of encapsulating

IP packets inside single level label stacks However, the very same techniques can also be applied

to multilevel label stacks, i.e the DiffServ tunneling actions are always applied to each label inthe stack at the ingress and egress points of the LSPs, i.e the points of pushing and popping thelabel in question

Pipe Model

The Pipe Model is the only mandatory tunneling model in [RFC3270] and is also the 8600 systemdefault model Since the egress LSR makes use of both the inner and the outer DiffServ information,

it can only be used without PHP, as illustrated below

Fig 2 Pipe Model [RFC3270]

In the above example with one level label stack, (M) denotes the outer MPLS shim header DiffServinformation and (D) the inner IP header DSCP field DiffServ information All LSRs on the labelswitched path, including the egress LSR, use the outer MPLS header DiffServ information forselecting the appropriate PHB (e.g the EF forwarding treatment typically used for VoIP) The innerDiffServ information (e.g the CS5 codepoint markings still found on some enterprise VoIP packets)has simply been tunnelled through the MPLS network untouched

Short Pipe Model

The short pipe model is a slight variation of the pipe model The only difference is that with theshort pipe model the DiffServ forwarding treatment at the egress LSR is chosen based on the innerDiffServ information

The short pipe model can be used with or without PHP, as illustrated below

Fig 3 Short Pipe Model [RFC3270]

Fig 4 Short Pipe with PHP [RFC3270]

Uniform Model

In the uniform model, each packet carries only one piece of DiffServ information, which is alwaysencoded in the outer most label entry Thus, in spite of being categorized as a DiffServ tunnelingmodel, the uniform model effectively does not tunnel any DiffServ information through the MPLSnetwork

The uniform model can be used with or without PHP, as illustrated below

Fig 5 Uniform Model [RFC3270]

Fig 6 Uniform Model with PHP [RFC3270]

This section describes how affinity constraints of MPLS LSPs are related to "include" and

"exclude" attributes of IP VPN routes and pseudowires.

Although LSP affinity constraint bits are logically similar in function to MPLS administrative groups (aka link colors, aka link affinities), they are not related and are completely

independent of each other For example “include-any” given for link color for RSVP trunk has

no effect on PWE3 association for RSVP trunk.

By default any inner LSP (L3 IP VPN, PWE3) can use any outer LSP (LDP, RSVP, static) that isgoing to a desired destination The constraints are constructed from two parts:

• Affinities and protocol limits on outer LSP

• Include or exclude constraints on inner LSPs

It is important to understand that if outer LSP has no constraints, the inner LSP can use it even if

the inner LSP has some include or exclude constraints This rule makes LDP more flexible and

easy to use Affinities and protocol limits on outer LSP take form "[IP] [MPLS 0xnnnnnnnn]" If [IP] is present, the LSP can be used for pure IP routed traffic If [MPLS 0xnnnnnnnn] is present,

the PWE3 can be used by inner LSPs that match the outer LSPs affinities The outer LSP canhence have the following configuration options:

• Both IP routed traffic and unlimited MPLS (PWE3, L3 IP VPN) traffic can use the LSP, i.e noconstraints

• Both IP routed traffic and selected MPLS (PWE3, L3 IP VPN) traffic can use the LSP

• Only IP routed traffic can use the LSP, but no inner labels are associated with the LSP

• Selected MPLS (PWE3, L3 IP VPN) traffic can use the LSP No IP traffic is directed to the LSP(it should be noted that L3 IP VPN traffic is MPLS, as it has inner-label)

The outer label affinities can be applied in:

• RSVP by using the "map-route" command

• LDP by using “receive-labels route-map” command FTN constraints can be set here based on

many criteria, such as prefix and the neighbor who advertised the label

• Static by using the "mpls static-ftn push" command

Affinity constraints are characterized by a mask value The mask is usual expressed in hexadecimalformat, but it is interpreted as a string of a 32 bits For example a mask "0x308" is interpreted asfollowing:

• Fourth bit is set to one, if the tunnel uses low-delay path, zero if high-delay path

• Ninth bit is set to one, if the tunnel can be used for "premium" customers, zero if otherwise

• Tenth bit is set to one if the tunnel goes through at least one compressed link, zero otherwiseThe inner label constraints can be expressed using the following three rules:

• include-any, at least one of the specified bit must match the outer LSP affinity

• include-all, all of the specified bits must match the outer LSP affinity

• exclude-any, none of the specified bits may be present in outer LSP affinity

One rule of each type can be specified:

• For any LDP PWE3 circuit in the "pwe3 circuit" command

• For static PWE3 circuits in the "mpls static-ftn push-and-lookup-for-vc" command

• For PWE3 circuits under "ip vrf NAME" mode

If no constraint is present, the inner label can use any outer label (to the suitable destinationwith suitable QoS class) that does not have IP only constraints On the other hand, traffic thatuses LSPs, like VPN traffic or pseudowire traffic, can be configured so that affinity is taken intoaccount when deciding which traffic uses a given LSP For VPN traffic, this is done with commands

"exclude-any", "include-all" and "include-any" For other traffic types, e.g pseudowires, this

is done with attributes exclude-any, include-all and include-any in the commands like "mpls

static-ftn".

Example:

mpls static-ftn push-and-lookup-for-vc abc 313 1.2.3.4 include-any 0x1f0 include-all 0x8 exclude-any 0x1

This example is very complex, however is presented here to illustrate how the constraints work inmost general cases When deciding which tunnel traffic can use (in the example above, VC named

"abc"), the decision procedure is based on a bit-by-bit comparison of all three bits

The tunnel affinity is configured as:

Tunnel affinity: 00000000 00000000 00000011 00001000The following constraint masks are configured for the VC “abc” that is carried across the tunnel.The three values 0x1F0, 0x8 and 0x1 are converted in binary format as shown below:

include-any for abc: 00000000 00000000 00000001 11110000

include-all for abc: 00000000 00000000 00000000 00001000exclude-any for abc: 00000000 00000000 00000000 00000001

Any or all of the three masks, include-any, include-all and exclude-any could have been zero (and

are in fact zero by default) Zero masks logically do not constraint the choice of LSP at all But ifthe user has opted to use nonzero masks, their effect is as follows:

• If include-any mask contains at least one nonzero bit, then the affinity mask must have at least

one corresponding bit set to nonzero In the example above, the ninth bit from right fulfils thiscondition

• Every bit that is set in include-all mask must also be set in affinity mask In the example above,

the fourth bit from right is required, and this requirement is fulfilled

• Every bit that is set in exclude-any mask must be absent in affinity mask In the example above,

the right most bit is required to be absent in the affinity mask, and indeed it is absent

In this example, the affinity mask passes all three tests and VC "abc" can use the tunnel If at leastone test had failed, the tunnel would not have been used for this particular VC

MPLS constraints should only be used when the specified LSP is required for a given inner label Agood reason would for example be to redirect some traffic to protected LSP while leaving the rest to

use LDP In that case one could indicate protected quality with single bit, and do include-any for that bit for the traffic that desires protection, while doing exclude-any for the rest Alternatively

unprotected LSPs could have another bit that is used for the rest of the LSPs Affinities are notrequired for associating QoS of specific pseudowires to suitable L-LSPs (or E-LSPs that carry

only few QoS classes), because "map-route" does contain separate QoS specifier that is used

for that purpose

The inherent connection oriented nature of MPLS LSPs makes them also a very good candidate forimplementing different types of protection schemes As an example, different types of end-to-endpath protection techniques between the ingress and the egress edge LSRs can be accommodated bysignaling two explicitly routed point-to-point LSPs, traversing diverse physical routes Since thetraffic rerouting decisions and protection LSP setup procedures have been done already before anyfailures occur, these techniques enable significantly faster network and traffic restoration times thannormal traffic rerouting functionality, and especially if the rerouting decisions also require initiation

of subsequent signaling procedures for LSP reestablishment

Furthermore, the speed of the protection switching depends on the mechanisms used for propagatingfault information along the LSPs route to the NEs doing the protection switching, which inend-to-end path protection cases are the edge LSRs Typically, such triggering mechanisms thatreside as close as possible to the protected networking layer function are much faster than purelycontrol plane software based mechanisms.

In addition to the protection mechanisms covered in this section, the 8600 system also supports

PWE3 tunnel protection (PWE3 redundancy), details of which are described in 8600 Smart

Routers ATM and TDM Configuration Guide and 8600 Smart Routers Testing and Measurements Configuration Guide.

In 8630 Smart Router and 8660 Smart Router during a graceful restart after CDC switchover, if there are configured alternative LSPs that have the same FEC (for example RSVP primary and LDP), traffic may be temporarily switched to a LSP that has a lower priority However, after the graceful restart traffic will automatically be switched back to the best available path.

1.4.1 MPLS Local Protection

In an MPLS-based network local protection can be achieved by switching traffic onto a presetbackup path with a technique known as Fast Reroute (FRR) The main advantage of FRR as aprotection solution is its capability of using local repair methods to guarantee fast failure responseand recovery as close as possible to the point of failure FRR is detailed covered in1.9 Fast Reroute

1.4.2 RSVP-TE based 1:1 Protection Switching

The 1:1 type of MPLS protection technique supported by the 8600 system is RSVP-TE-basedLSP path protection, where traffic is switched from a primary LSP to a pre-signalled secondaryLSP in case the primary LSP goes down This protection mechanism uses a combination of L1defect, RSVP-TE signaling, and L3 routing information as the possible triggers for determiningthat the primary LSP is down The fastest restoration times are typically achieved if the failurecan be detected locally by the NE doing the actual switching In such cases, the switchover timefor pseudowire traffic is below 50 milliseconds, regardless of the number of connections carried

on the LSP Bidirectional Forwarding Detection (BFD) can be used for quick failure detection

Please refer to 8600 Smart Routers Routing Protocols Configuration Guide BFD section for more

information and for the configuration details

In case there are multiple LSPs that could be used for reaching the same destination, the transportedtraffic load can often be distributed among them The load balancing method currently supported

in the 8600 system is based on the IPv4 5-tuple, where the traffic load is distributed based onperforming a hash calculation over the following L3 and L4 protocol header information:

• IPv4 source address

• IPv4 destination address

• Protocol

• UDP or TCP source port

• UDP or TCP destination port

In 8600 system, IP load balancing can be performed to:

• RSVP-TE tunnels

• RSVP-TE tunnels for IP VPN routes

In load balancing, the sub-flows identified based on the hash calculation can be distributed over

up to eight RSVP-TE tunnels The load distribution among the tunnels can also be controlled

by user-configurable load balancing weights However, the actual spreading of the load on thetunnel LSPs is in practise statistical and is not fine-tuned based on observed traffic statistics Loadbalancing may also be used together with RSVP 1:1 path protection and Fast Reroute (FRR).Load balancing is performed in an opportunistic manner Whenever 8600 router selects IP route,FTN entry or recursive resolution for forwarding entry (e.g PSN tunnel for VPN route) for inclusion

in FIB, the router first selects the absolutely best available alternative If selected forwarding entry

is eligible for load balancing, the FTN table and RIB are inspected to see if there are other entrieswith identical FEC and constraints available for load-sharing If there are, those entries are addedwith the primary entry to form load balancing group Due to this opportunistic nature the algorithmfinds local optimum for load balancing – it does not attempt to seek global optimum where primaryselection would be performed in manner that would allow maximum load sharing

The RSVP-TE tunnels having the same affinity and flags must belong to the same load balancing group.

[RFC2702] specifies the requirements for Traffic Engineering over MPLS Instead of the moretraditional TE methods, explicitly routed point-to-point LSPs offer a more efficient and controlledway to perform traffic engineering In addition to [RFC2702], Internet Engineering Task Force(IETF) has also specified protocol-specific TE extensions for the most common Interior GatewayProtocols (IGPs) and label signaling protocols

In the 8600 system, all explicitly routed LSP tunnels are set up using the RSVP-TE protocol Theycan be signalled either with or without bandwidth reservations, largely depending on the selectedMPLS deployment model and network engineering applications

There are traditional TE methods such as adjusting the IGP metrics on a congested link, or relying

on an L2 overlay network design These include e.g IP over Asynchronous Transfer Mode (ATM)

or IP over Frame Relay (FR) Instead of the more traditional TE methods, manual MPLS TE can beperformed without making any bandwidth reservations in the network This can be accomplishedsimply by diverting some of the traffic on a congested link to an explicitly routed point-to-point LSPthat bypasses it As soon as the link congestion has been detected, a new TE tunnel can be set upbetween a selected pair of LSRs in the network (often a pair of edge LSRs), and simply signalledonto a different route than the shortest path that would be selected by the IP routing protocols.Next, some of the traffic traversing the congested link can be redirected to it, thus relieving thecongestion In practise, these types of manual TE operations rely totally on online monitoring of thelink utilizations in the network, and require reactive deployment of MPLS TE tunnels (or their L2equivalents) only in the event of some link(s) getting congested

In order to proactively prevent the congestion from happening in the first place, bandwidthreservations can be made for the traffic trunks with a controlled load (i.e appropriately policed),traversing the MPLS network In this MPLS deployment model, the RSVP-TE path requests aresubjected to Connection Admission Control (CAC) at each 8600 NE For performing automated TELSP routing, also the IGP TE extensions and the Constrained Shortest Path First (CSPF) algorithmmust be enabled in the 8600 NEs In this case, the LSP routing decisions can be made automatically

by the head-end LSRs, since all nodes in the network use the TE extensions of the selected IGP foradvertising the amount of available bandwidth on the directly attached network links When a newtraffic trunk is to be set up in the network, the head-end LSR uses the CSPF algorithm for calculatingthe shortest possible path through the network that still has enough unreserved bandwidth left toaccommodate the needs of the new tunnel LSP In this deployment model, a full mesh of TE tunnels

is often deployed between all of the edge LSRs in the network, and most of the end user traffic ismapped on the resulting, logical TE topology

Please refer to 8600 Smart Routers Routing Protocols Configuration Guide for more information on

different types of routing protocols, and their configuration details

The requirements for DiffServ-aware MPLS Traffic Engineering (DS-TE) have been specified in[RFC3564] Instead of setting up aggregate LSPs for carrying all traffic classes (as in the basic form

of MPLS TE), the DS-TE approach performs MPLS traffic engineering at a per-class level InDS-TE, the traffic from different DiffServ classes of service is mapped to separate LSPs Also thenetwork resources have been divided among the different traffic classes, and the IGP TE extensionsadvertise the available bandwidth on the attached links on a per-class basis

In DS-TE, a TE class is a combination of a Class Type (CT) and an LSP preemption priority.There are a maximum of eight CTs The network resources are divided into per-CT pools, whichhas prompted the need for different types of Bandwidth Constraint (BC) models The BC modelssupported by the 8600 system are the Maximum Allocation Model (MAM), and the Russian DollsModel (RDM)

1.7.1 Maximum Allocation Model

Maximum Allocation Model (MAM) [RFC4125] is the most intuitive and the most simple BCmodel It provides good isolation between the resources allocated to different CTs, but may in somecases not be the most efficient model in terms of achieved network utilization MAM implements anindividual BC for each CT, and can also limit the aggregate of reserved bandwidth across all CTs,

as illustrated in the following figure

Fig 7 Maximum Allocation Model

1.7.2 Russian Dolls Model

Russian Dolls Model (RDM) [RFC4127] is the default BC model used in the 8600 system.When used together with LSP preemption, RDM can offer good isolation between CTs and alsoefficient utilization of the network resources The CT and BC structure of RDM are illustrated inthe following figure

Fig 8 Russian Dolls Model

Every MPLS interface has parameter called "mpls mtu", which limits the maximum size of

MPLS packets that can be sent over a link It is distinct from the well-known IP MTU, to allow

for more versatile network configuration Please refer to 8600 Smart Routers IP Forwarding and

Traffic Management Configuration Guide for a detailed description of all MTU-related parameters

of an interface

FRR provides fast mechanisms per link or per node protection by switching traffic to the backuppaths around a point of failure When a failure occurs the node immediately upstream of the point offailure will switch traffic to a pre-signalled backup path in response to the failure.

FRR can be utilized as long as the network has enough connectivity for creating backup paths Toprotect downstream links or nodes, each node on the protected path can act as a Point of LocalRepair (PLR)

1.9.2 FRR Operation and Applications

FRR involves the following concepts:

• Backup path – refers to either a detour LSP or a bypass tunnel that is responsible for backing upprotected LSP(s)

• Bypass tunnel – a tunnel that is used to protect a set of LSPs traversing over a common facility

• Detour LSP – the LSP that is used to re-route traffic around a point of failure in one-to-one backupmethod

• Merge Point (MP) – the LSR where one or more backup paths rejoin the path of the protectedLSP downstream of a potential point of failure The same LSR can act as an MP and PLR simul-taneously

• PLR is any node performing a repair, i.e the head-end LSR of detour LSP or bypass tunnel

In the 8600 NEs, FRR is implemented according to [RFC4090] There are two different methods ofFRR:

• One-to-one backup

• Facility backupBoth FRR methods can be used to provide link and/or node protection

• In the case of link protection, a backup path (detour LSP or a bypass tunnel) is created to bypass

a single link of the protected LSP path and is terminated at PLR next-hop downstream When alink failure occurs, the PLR will reroute traffic to the backup path, bypassing the failed link

• In case of node protection, a backup path is created in such way that it bypasses the next-hopnodes along the protected LSP path downstream When a node along the protected LSP pathfails, the node upstream of the point of failure will reroute traffic around the failed node FRRnode protection also can provide protection from link failures, though may not be feasible in alltopologies

One-to-one Backup

In one-to-one method, a backup LSP known as detour is pre-signalled downstream for eachprotected LSP at each PLR Detour LSPs are signalled at each node along the path of the protectedLSP, with the exception of egress node These nodes are known as potential PLR The followingtopology illustrates an example of the one-to-one backup method

Fig 9 FRR One-to-One Backup

The principles employed in one-to-one backup method are illustrated inFig 9, where as an examplefour detour LSPs are created for the protected LSP When a failure occurs along the protected LSP,the PLR detecting a failure switches traffic into the detour LSP For example, if a failure occurs,e.g in node R3 or link R2R3, node R2 will switch traffic sent by node R1 downstream on thedetour R2 B-LSP In this case, R2 B-LSP can be used to protect link R2 R3 and/or node R3.The same is true for R1 B-LSP and R3 B-LSP (node and link protection), while R4 B-LSP canperform only link protection in this example

When a detour LSP intersects its protected LSP within the same outgoing interface at a LSRdownstream from the head-end, the merge will occur at the MP (i.e only the protected LSP will besignalled downstream from the MP in this case)

In one-to-one backup there can be N-1 detour LSPs to fully protect a LSP of N hops, which canturn to a large number of LSPs in the network If there are multiple protected LSPs, merging can

be used to help reducing the amount of LSPs

One-to-one backup application in the network:

• Sufficient degree of connectivity available for backup paths

• CSPF must be enabled in all nodes on the path

• Global parameters are applied for detour LSPs created in transit nodes

• CSPF takes into account detour specific bandwidth and link colors to influence the paths of sible detour LSPs

pos-Facility Backup

A facility backup method is achieved by creating bypass tunnel(s) to protect link(s) or node(s) Abypass tunnel can also protect a set of LSPs, if the following are fulfilled:

• Bypass tunnel must intersect the path of the protected LSP downstream

• Protected LSPs must pass through a PLR and common downstream nodeWhen a failure occurs along the protected path, a PLR will reroute traffic onto the bypass tunnel.This implies that a facility backup provides a scalability improvement compared to one-to-onebackup method, by utilizing the same bypass tunnel to protect multiple LSPs when a failure occurs

in a node or link protected by the bypass tunnel

Fig 10 FRR Facility Backup

The principles employed in facility backup method are illustrated inFig 10, where as an examplethe created bypass tunnel protects node R3 and three LSPs that pass through this node against failure

in node R3, or link R2R3 and R3 R4 If a failure occurs, e.g in node R3, or link R2 R3/R3

R4, node R2 will switch all traffic sent from R1, R8 and R2 itself into the bypass tunnel In thisexample, R4 acts as a MP To protect against failure of the link between R4 and R5, an additionalbypass tunnel can also be set In this example, a detour LSP is used instead

In facility backup method, bypass tunnels are specifically created by configuring the protected link

or node, and the desired MP for the bypass tunnel In 8600 system the PLR node supports LSP pingand traceroute for the bypass tunnel

Facility backup application in the network:

• Desired potential PLR nodes must have bypass paths available for link or node protection

• The protected path configured as strict over the PLR that is either a link or a node protected bythe bypass tunnel

• Each LSR acting as PLR must have a bypass tunnel pre-configured All RSVP-TE trunk optionsare available

• FRR attributes can be taken into account

State Condition Description of Data Flow

No failure If all paths are available, traffic will be carried on the primary protected

LSPFailure in protected LSP If protected LSP is not available (faulted) traffic will be switched to

the primary detour LSP, i.e primary detour LSPs are preferred oversecondary LSPs

Primary detour LSP failure If primary detour LSP is not available traffic is switched to secondary

protected LSPFailure in secondary protected

LSP

If secondary protected LSP is not available and both primary protectedLSP and primary detour too, traffic will be switched to secondarydetour LSP

The above implies that only one active path can exist at time and that a detour is hot-standby path,i.e no traffic flows through it before a switchover

In 8600 system, it is possible to prevent detour creation at head-end when there is more thanone protection path In this case, a detour can be created in the downstream Also a detour isautomatically created in the downstream, whenever there is a path available

When a failure occurs, the head-end employs the global revertive mode to re-optimize the LSPs thatused the failed path

Path Identification

When FRR is enabled, the backup paths are signalled and the following conditions imply:

• Backup paths must be uniquely identified

• Protected paths must be associated with their backup paths

• Global and non-global labels utilization

• Backup paths must be merged downstream

• RSVP-TE status maintenance during and after failure

One-to-One Backup

A detour LSP must be clearly identified with its protected session to allow correct merging and statetreatment This implies that a detour LSP must inherit its LSP ID from the associated protected LSP

To be able to uniquely identify a detour LSP, the following are defined:

• Sender Template-Specific - in this approach every PLR uses a local router address as the ingressaddress of a detour LSP Additionally, a detour LSP object may be added to the path message.Detour LSPs may be merged using this approach A merge will occur, if the outgoing interfaceExplicit Route Object (ERO) and the next-hop LSR are the same

• Path-Specific - in this approach, a detour LSP uses the protected LSP ingress address and a tour LSP object is added to the path message Detour LSPs can be merged using path-specificapproach A merge can only occur, if the path messages share the same outgoing interface andthe next-hop LSR Path-Specific is the default mode used in 8600 NEs

de-If a strict path is used, traffic loss may occur when detour LSPs are merged It is recommended not to use explicit path when FRR is used in global revertive mode.

In some applications depending on the network topology, there might be circumstances (thoughvery unlikely) where merge must be done, but cannot be constructed In this case, a MP will torndown some of the detour LSPs The head-end will see the path as partially protected and a fault will

be raised to indicate this situation

Network Topologies

In the 8600 system FRR supports any network topology with sufficient degree of connectivity Thefollowing is an example of a ring topology using the one-to-one backup

Fig 11 FRR One-to-One Backup in Ring Topology

InFig 11the protected LSP is established and connects via nodes R1, R2, R3, R4 to R5 and trafficflows in the same direction In this example when protected LSP is established, every node in thering creates detour LSP in the reverse direction of the protected path (LSP) These detour LSPs aremerged in the downstream detour path As an example,Fig 11shows detour LSP D2 being merged

in node R1 when protecting against a failure in link R2R3 The same merging mechanism isvalid for the rest of nodes in a ring topology

The following is an example of a ring topology using facility backup method

Fig 12 FRR Facility Backup in Ring Topology

InFig 12let's assume ingress node R1 and egress R5 In a protected ring topology using facilitybackup, bypass tunnel is established depending on the protection type used link or node.

• If a failure occurs e.g in link R2R3, bypass tunnel R2-R1-R6-R5-R4-R3 (node R3 is the MP)

is used as the protecting path of link R2R3

• If a failure occurs e.g in node R3, bypass tunnel (node R4 is the MP) R2-R1-R6-R5-R4 is used

as protecting path of node R3

to avoid the failed link or node

1.9.3 FRR Provisioning and BFD

When enabling FRR in one-to-one backup, the paths used for detour LSPs must meet the following:

• The downstream interface cannot be shared with the protected LSP at the PLR where the detourLSP is created

• A protected LSP and its detour LSP must intersect or alternatively end at the same node stream past the protected resource (link or node)

down-• Detour LSPs might have different attributes than the protected LSP

In facility backup method:

• Protection scenarios are laid out at each PLR for link or node protection

• Only nodes with a bypass tunnel configured will make path computations

• Bypass tunnel can have an ERO object (strict path with predetermined hops)

It is possible to specify how much bandwidth is reserved for detour LSPs, which of course mightaffect detour path selection By default no bandwidth is allocated for detour LSPs in 8600 NEs.However, depending on the operator’s needs and the importance of traffic, the following options areavailable:

• Provision no bandwidth and rely on quick global recovery to reroute traffic quickly;

• Overbook, i.e configure detour LSPs to reserve less bandwidth than the protected LSP;

• Reserve the same amount of bandwidth

Failure Detection

The speed of failure detection depends on many factors, e.g interface type; network (topology andtype); routing protocols When there is a failure, the detection mechanisms are used to identify thefailed link or node and trigger a switchover to avert traffic losses In packet-switched networks thedetection mechanisms may not be reliable, or faster enough In this case, Bidirectional Forwarding

Detection (BFD) can be used to provide fast detection of link or node failures Please refer to 8600

Smart Routers Routing Protocols Configuration Guide BFD section for more information.

With POS (SONET/SDH) interfaces, link failure detection time is almost 1 second, whichsignificantly exceed the FRR requirement of less than 50 ms This requires that timers should

be tuned for SDH/SONET POS interfaces in a such way that any possible link level protectionschemes are faster than the upper layer detection time The 8620 Smart Router, 8630 Smart Routerand 8660 Smart Router provide a way to specifically set a link failure detection time with aid of

the ssf-delay layer2 50 command.

Switched Ethernet networks can aggregate multiple hops, which are transparent to MPLS nodes Inthis case, it is possible to launch a BFD session sending packets at regular intervals If BFD packetsare lost, i.e not received the session will be torn down, thus the RSVP session and underlyingtrunks will be down over this interface

BFD has to be tied to RSVP neighbor

A majority of 8600 NEs provided support of FRR However, FRR is not yet supported by:

• 8615 Smart Router

• ELC1 (8630 Smart Router/8630 Smart Router)

• LU1 (8665 Smart Router)

Limitations and Restrictions

Below is a list of known limitations and restrictions with FRR:

• CAC is not supported in facility backup

• When FRR is used in 8630 Smart Router and 8660 Smart Router, a CDC switchover may causetraffic loss for up to 10 ms

• FRR switchover time depends on the amount of protected RSVP-TE LPSs and performancepower of the NE When the number of protected RSVP-TE LSPs is larger than 50, then a FRRswitchover time that exceeds 50 ms may be observed in 8605 Smart Router and 8607 SmartRouter

• FRR facility backup method is not recommended to be used simultaneously with RSVP-TE loadbalancing in the same RSVP-TE LSP IPv4 load balancing (at head-end NE) will use only a singleRSVP-TE LSP when used together with FRR facility backup method

The 8600 NEs support FRR fault management and the faults reported are summarized in thefollowing table