7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide7210 SAS M, T, X, R6, R12, Mxp,
Sx MPLS Configuration Guide
7210 SERVICE ACCESS SWITCH
7210 SAS OS 7210 SAS-K 2F4T6C MPLS
Guide
Release 9.0.R8
3HE12059AAAETQZZA
Issue: 01
September 2017
Nokia — Proprietary and confidential.
Use pursuant to applicable agreements.
7210 SAS OS 7210 SAS-K 2F4T6C MPLS
Guide
Nokia is a registered trademark of Nokia Corporation. Other products and company
names mentioned herein may be trademarks or trade names of their respective
owners.
The information presented is subject to change without notice. No responsibility is
assumed for inaccuracies contained herein.
© 2017 Nokia.
Contains proprietary/trade secret information which is the property of Nokia and must
not be made available to, or copied or used by anyone outside Nokia without its
written authorization. Not to be used or disclosed except in accordance with
applicable agreements.
2
3HE12059AAAETQZZA Issue: 01
TABLE OF CONTENTS
Preface
About This Guide 11
Audience 11
List of Technical Publications 12
Getting Started
In This Chapter 15
Nokia 7210 SAS-K 2F4T6C Router Configuration Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
MPLS and RSVP
In This Chapter 17
MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
MPLS Label Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
Label Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
Label Switching Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
LSP Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
MPLS Facility Bypass Method of MPLS Fast Re-Route (FRR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
Manual Bypass LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
Using RSVP for MPLS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
RSVP Traffic Engineering Extensions for MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
Reservation Styles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
RSVP Message Pacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
RSVP Overhead Refresh Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
Configuring Implicit Null . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
MPLS Traffic Engineering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
TE Metric (IS-IS and OSPF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Advanced MPLS/RSVP Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
LSP Path Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
Manual LSP Path Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
Make-Before-Break (MBB) Procedures for LSP/Path Parameter Configuration Change . . . . . . . . . . .37
Shared Risk Link Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
Enabling Disjoint Backup Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Static Configurations of SRLG Memberships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
TE Graceful Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
MPLS/RSVP Configuration Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Configuration Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Configuring MPLS and RSVP with CLI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
MPLS Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
Router Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
Choosing the Signaling Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
Basic MPLS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide Page 3
Table of Contents
Common Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
Configuring MPLS Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
Configuring Global MPLS Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
Configuring an MPLS Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
Configuring MPLS Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
Configuring an MPLS LSP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Configuring a Static LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
Configuring Manual Bypass Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
Configuring RSVP Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
Configuring RSVP Message Pacing Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
Configuring Graceful Shutdown. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
MPLS Configuration Management Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
Modifying MPLS Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
Modifying an MPLS LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Modifying MPLS Path Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
Modifying MPLS Static LSP Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
Deleting an MPLS Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
RSVP Configuration Management Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
Modifying RSVP Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
Modifying RSVP Message Pacing Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
Deleting an Interface from RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
MPLS/RSVP Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
Command Hierarchies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
MPLS Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68
MPLS LSP Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68
MPLS Path Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
RSVP Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
Show Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
Tools Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
Clear Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
Debug Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
Label Distribution Protocol
In This Chapter 153
Label Distribution Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154
LDP and MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154
LDP Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155
Subsystem Interrelationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156
Memory Manager and LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157
Label Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157
LDP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157
Logger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157
Service Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157
Execution Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158
Initialization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158
Session Lifetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158
Label Exchange. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160
Page 4 7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide
Table of Contents
Other Reasons for Label Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160
Cleanup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160
Configuring Implicit Null Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160
LDP Fast-Reroute for IS-IS and OSPF Prefixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
LDP FRR Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
LDP FRR Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164
IS-IS and OSPF Support for Loop-Free Alternate Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . .166
Multi-Area and Multi-Instance Extensions to LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172
LDP Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173
Configuring LDP with CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175
LDP Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176
Basic LDP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177
Common Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178
Enabling LDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178
Configuring Graceful-Restart Helper Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179
Applying Export and Import Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .180
Targeted Session Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181
Interface Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182
Session Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183
LDP Signaling and Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .184
LDP Configuration Management Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185
Disabling LDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185
Modifying Targeted Session Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .186
Modifying Interface Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .187
LDP Command Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189
Command Hierarchies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189
LDP Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189
Show Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190
Clear Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191
Debug Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192
7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide Page 5
Table of Contents
Page 6 7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide
LIST OF TABLES
Preface
Table 1: Configuration Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
MPLS and RSVP
Table 2: Packet/Label Field Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
Label Distribution Protocol
Table 3: FEC Originate Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221
7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide Page 7
List of Tables
Page 8 7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide
LIST OF FIGURES
MPLS and RSVP
Figure 1: Label Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
Figure 2: Label Packet Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
Figure 3: Bypass Tunnel Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Figure 4: FRR Node-Protection Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Figure 5: Establishing LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
Figure 6: LSP Using RSVP Path Set Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
Figure 7: Shared Risk Link Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Figure 8: MPLS and RSVP Configuration and Implementation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Label Distribution Protocol
Figure 9: Subsystem Interrelationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156
Figure 10: Topology with Primary and LFA Routes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167
Figure 11: Example Topology with Broadcast Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168
Figure 12: LDP Configuration and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .174
7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide Page 9
List of Figures
Page 10 7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide
About This Guide
This guide describes the services and protocol support provided by the 7210 SAS-K2F4T6C
Series and presents examples to configure and implement MPLS, RSVP, and LDP protocols. This
document is organized into functional chapters and provides concepts and descriptions of the
implementation flow, as well as Command Line Interface (CLI) syntax and command usage.
NOTES:
• 7210 SAS-K5 stands for 7210 SAS-K 2F2T1C and 7210 SAS-K12 stands for 7210 SASK 2F4T6C platforms.
• 7210 SAS-E, 7210 SAS-D, and 7210 SAS-K 2F2T1C operate in access-uplink mode by
default. There is no need of an explicit user configuration needed for this.
7210 SAS-K 2F4T6C operates in Access-uplink mode and Network mode. There is no
explicit BOF configuration required for it.
Preface
Audience
This manual is intended for network administrators responsible for configuring the 7210 SAS
Series routers. It is assumed that the network administrators have an understanding of networking
principles and configurations. Protocols and concepts described in this manual include the
following:
• Multi protocol Label Switching (MPLS)
• Resource Reservation Protocol (RSVP)
7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide Page 11
Preface
List of Technical Publications
The 7210- D, 7210 SAS-E, 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C documentation set is
composed of the following books:
• 7210- D, 7210 SAS-E, 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C Basic System
Configuration Guide
This guide describes basic system configurations and operations.
• 7210- D, 7210 SAS-E, 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C System
Management Guide
This guide describes system security and access configurations as well as event
logging and accounting logs.
• 7210- D, 7210 SAS-E, 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C Interface
Configuration Guide
This guide describes card, Media Dependent Adapter (MDA), and port provisioning.
• 7210- D, 7210 SAS-E, 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS Router
Configuration Guide
This guide describes logical IP routing interfaces and associated attributes such as an
IP address, port, link aggregation group (LAG) as well as IP and MAC-based filtering.
• 7210- D and 7210 SAS-E OS Services Guide
This guide describes how to configure service parameters such as customer
information and user services.
• 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS Services Guide
This guide describes how to configure service parameters such as customer
information and user services.
• 7210- D, 7210 SAS-E, 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OAM and
Diagnostic Guide
This guide describes how to configure features such as service mirroring and
Operations, Administration and Management (OAM) tools.
• 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C Quality of Service Guide
This guide describes how to configure Quality of Service (QoS) policy management.
• 7210 SAS-K 2F4T6C OS MPLS Guide
This guide describes how to configure Multiprotocol Label Switching (MPLS) and Label
Distribution Protocol (LDP).
• 7210 SAS-K 2F2T1C and 7210 SAS-K 2F4T6C OS Routing Protocols Guide
This guide provides an overview of routing concepts and provides configuration examples
for OSPF, IS-IS and route policies.
Page 12 7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide
GETTING STARTED
In This Chapter
This chapter provides process flow information to configure MPLS, RSVP, and LDP protocols.
Nokia 7210 SAS-K 2F4T6C Router Configuration Process
Table 1 lists the tasks necessary to configure MPLS applications functions.
This guide is presented in an overall logical configuration flow. Each section describes a software
area and provides CLI syntax and command usage to configure parameters for a functional area.
Table 1: Configuration Process
Area Task Chapter
Protocol configuration Configure MPLS protocols:
• MPLS MPLS on page 18
• RSVP RSVP on page 28
• LDP Label Distribution Protocol on page 153
Reference List of IEEE, IETF, and other
proprietary entities.
Standards and Protocol Support on page 239
7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide Page 15
Getting Started
Page 16 7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide
In This Chapter
This chapter provides information to configure MPLS and RSVP.
• MPLS on page 18
→ MPLS Label Stack on page 18
→ Label Switching Routers on page 21
→ Using RSVP for MPLS on page 29
→ Reservation Styles on page 31
MPLS and RSVP
• MPLS Traffic Engineering on page 34
• Advanced MPLS/RSVP Features on page 36
→ Shared Risk Link Groups on page 37
→ TE Graceful Shutdown on page 41
• MPLS/RSVP Configuration Process Overview on page 42
• MPLS/RSVP Configuration Process Overview on page 42
• Configuration Notes on page 43
7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide Page 17
MPLS Label Stack
MPLS
Multiprotocol Label Switching (MPLS) is a label switching technology that provides the ability to
set up connection-oriented paths over a connection less IP network. MPLS facilitates network
traffic flow and provides a mechanism to engineer network traffic patterns independently from
routing tables. MPLS sets up a specific path for a sequence of packets. The packets are identified
by a label inserted into each packet. MPLS is not enabled by default and must be explicitly
enabled.
MPLS is independent of any routing protocol but is considered multiprotocol because it works
with the Internet Protocol (IP) and frame relay network protocols.
The 7210 SAS routers enable service providers to deliver virtual private networks (VPNs) and
Internet access using MPLS tunnels, with Ethernet interfaces.
On the 7210 SAS-K 2F4T6C, is designed to fit into a network using the principles of seamless
MPLS architecture which enable access devices with smaller IP routing scale (both control-plane
RIB and FIB) and smaller MPLS scale (both control-plane and FIB) to be used to deploy MPLS
end-to-end and benefit from the traffic engineering and resiliency mechanism that MPLS provides.
The MPLS features and capabilities available on 7210 SAS-K2F4T6C is described in this user
guide.
MPLS Label Stack
MPLS requires a set of procedures to enhance network layer packets with label stacks which
thereby turns them into labeled packets. Routers that support MPLS are known as Label Switching
Routers (LSRs). In order to transmit a labeled packet on a particular data link, an LSR must
support the encoding technique which, when given a label stack and a network layer packet,
produces a labeled packet.
In MPLS, packets can carry not just one label, but a set of labels in a stack. An LSR can swap the
label at the top of the stack, pop the stack, or swap the label and push one or more labels into the
stack. The processing of a labeled packet is completely independent of the level of hierarchy. The
processing is always based on the top label, without regard for the possibility that some number of
other labels may have been above it in the past, or that some number of other labels may be below
it at present.
As described in RFC 3032, MPLS Label Stack Encoding, the label stack is represented as a
sequence of label stack entries. Each label stack entry is represented by 4 octets. Figure 1 displays
the label placement in a packet.
Page 18 7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide
MPLS and RSVP
Figure 1: Label Placement
Table 2: Packet/Label Field Description
Field Description
Label This 20-bit field carries the actual value (unstructured) of the label.
Exp This 3-bit field is reserved for experimental use. It is currently used for Class of
Service (CoS).
S This bit is set to 1 for the last entry (bottom) in the label stack, and 0 for all
other label stack entries.
TTL This 8-bit field is used to encode a TTL value.
A stack can carry several labels, organized in a last in/first out order. The top of the label stack
appears first in the packet and the bottom of the stack appears last (Figure 2).
Layer 2 Header Top Label … Bottom Label Data Packet
OSSG014
Figure 2: Label Packet Placement
The label value at the top of the stack is looked up when a labeled packet is received. A successful
lookup reveals:
• The next hop where the packet is to be forwarded.
• The operation to be performed on the label stack before forwarding.
In addition, the lookup may reveal outgoing data link encapsulation and other information needed
to properly forward the packet.
An empty label stack can be thought of as an unlabeled packet. An empty label stack has zero (0)
depth. The label at the bottom of the stack is referred to as the Level 1 label. The label above it (if
it exists) is the Level 2 label, and so on. The label at the top of the stack is referred to as the Level
m label.
7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide Page 19
MPLS Label Stack
Labeled packet processing is independent of the level of hierarchy. Processing is always based on
the top label in the stack which includes information about the operations to perform on the
packet's label stack.
Label Values
Packets travelling along an LSP (see Label Switching Routers on page 21) are identified by its
label, the 20-bit, unsigned integer. The range is 0 through 1,048,575. Label values 0-15 are
reserved and are defined below as follows:
• A value of 0 represents the IPv4 Explicit NULL Label. This Label value is legal only at
the bottom of the Label stack. It indicates that the Label stack must be popped, and the
packet forwarding must be based on the IPv4 header.
• A value of 1 represents the router alert Label. This Label value is legal anywhere in the
Label stack except at the bottom. When a received packet contains this Label value at the
top of the Label stack, it is delivered to a local software module for processing. The actual
packet forwarding is determined by the Label beneath it in the stack. However, if the
packet is further forwarded, the router alert Label should be pushed back onto the Label
stack before forwarding. The use of this Label is analogous to the use of the router alert
option in IP packets. Since this Label cannot occur at the bottom of the stack, it is not
associated with a particular network layer protocol.
• A value of 3 represents the Implicit NULL Label. This is a Label that a Label Switching
Router (LSR) can assign and distribute, but which never actually appears in the
encapsulation. When an LSR would otherwise replace the Label at the top of the stack
with a new Label, but the new Label is Implicit NULL, the LSR pops the stack instead of
doing the replacement. Although this value may never appear in the encapsulation, it
needs to be specified in the RSVP, so a value is reserved.
• Values 4-15 are reserved for future use.
7210 SAS devices uses labels for MPLS, RSVP-TE, and LDP, as well as packet-based services
such as VLL and VPLS.
Label values 16 through 1,048,575 are defined as follows:
• Label values 16 through 31 are reserved for future use.
• Label values 32 through 1,023 are available for static assignment.
• Label values 1,024 through 2,047 are reserved for future use.
• Label values 2,048 through 18,431 are statically assigned for services.
• Label values 32768through 131,071 are dynamically assigned for both MPLS and
services.
• Label values 131,072 through 1,048,575 are reserved for future use.
Page 20 7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide
Label Switching Routers
LSRs perform the label switching function. LSRs perform different functions based on it’s
position in an LSP. Routers in an LSP do one of the following:
• The router at the beginning of an LSP is the ingress label edge router (ILER). The ingress
router can encapsulate packets with an MPLS header and forward it to the next router
along the path. An LSP can only have one ingress router.
• A Label Switching Router (LSR) can be any intermediate router in the LSP between the
ingress and egress routers. An LSR swaps the incoming label with the outgoing MPLS
label and forwards the MPLS packets it receives to the next router in the MPLS path
(LSP). An LSP can have 0-253 transit routers.
• The router at the end of an LSP is the egress label edge router (ELER). The egress router
strips the MPLS encapsulation which changes it from an MPLS packet to a data packet,
and then forwards the packet to its final destination using information in the forwarding
table. Each LSP can have only one egress router. The ingress and egress routers in an LSP
cannot be the same router.
MPLS and RSVP
LSP Types
A router in your network can act as an ingress, egress, or transit router for one or more LSPs,
depending on your network design.
An LSP is confined to one IGP area for LSPs using constrained-path. They cannot cross an
autonomous system (AS) boundary.
Static LSPs can cross AS boundaries. The intermediate hops are manually configured so the LSP
has no dependence on the IGP topology or a local forwarding table.
The following are LSP types:
• Static LSPs — A static LSP specifies a static path. All routers that the LSP traverses must
be configured manually with labels. No signaling such as RSVP or LDP is required.
• Signaled LSP — LSPs are set up using a signaling protocol such as RSVP-TE or LDP.
The signaling protocol allows labels to be assigned from an ingress router to the egress
router. Signaling is triggered by the ingress routers. Configuration is required only on the
ingress router and is not required on intermediate routers. Signaling also facilitates path
selection.
There are two signaled LSP types:
→ Explicit-path LSPs — MPLS uses RSVP-TE to set up explicit path LSPs. The hops
within the LSP are configured manually. The intermediate hops must be configured as
either strict or loose meaning that the LSP must take either a direct path from the
7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide Page 21
Label Switching Routers
→ Constrained-path LSPs — The intermediate hops of the LSP are dynamically
If fast reroute is configured, the ingress router signals the routers downstream. Each downstream
router sets up a detour for the LSP. If a downstream router does not support fast reroute, the
request is ignored and the router continues to support the LSP. This can cause some of the detours
to fail, but otherwise the LSP is not impacted.
No bandwidth is reserved for the rerouted path. If the user enters a value in the bandwidth
parameter in the config>router>mpls>lsp>fast-reroute context, it will have no effect on the LSP
backup LSP establishment.
previous hop router to this router (strict) or can traverse through other routers (loose).
You can control how the path is set up. They are similar to static LSPs but require less
configuration. See RSVP on page 28.
assigned. A constrained path LSP relies on the Constrained Shortest Path First (CSPF)
routing algorithm to find a path which satisfies the constraints for the LSP. In turn,
CSPF relies on the topology database provided by the extended IGP such as OSPF or
IS-IS.
Once the path is found by CSPF, RSVP uses the path to request the LSP set up. CSPF
calculates the shortest path based on the constraints provided such as bandwidth, class
of service, and specified hops.
Hop-limit parameters specifies the maximum number of hops that an LSP can traverse, including
the ingress and egress routers. An LSP is not set up if the hop limit is exceeded. The hop count is
set to 255 by default for the primary and secondary paths. It is set to 16 by default for a bypass or
detour LSP path.
7210 SAS-K2F4T6C supports the following functionality:
• MPLS LSR functionality.
• MPLS LER functionality with the following support:
→ Static LSPs.
→ RSVP signaled LSPs with support for both explicit-path LSP and constrained-path
LSPs.
→ LDP signaled LSPs are not supported.
• Support for FRR one-to-one and FRR facility bypass for RSVP signaled LSPs.
Page 22 7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide
MPLS and RSVP
MPLS Facility Bypass Method of MPLS Fast Re-Route (FRR)
The MPLS facility bypass method of MPLS Fast Re-Route (FRR) functionality is extended to the
ingress node.
The behavior of an LSP at an ingress LER with both fast reroute and a standby LSP path
configured is as follows:
• When a down stream detour becomes active at a point of local repair (PLR):
The ingress LER switches to the standby LSP path. If the primary LSP path is repaired
subsequently at the PLR, the LSP will switch back to the primary path. If the standby goes
down, the LSP is switched back to the primary, even though it is still on the detour at the
PLR. If the primary goes down at the ingress while the LSP is on the standby, the detour at
the ingress is cleaned up and for one-to-one detours a “path tear” is sent for the detour
path. In other words, the detour at the ingress does not protect the standby. If and when the
primary LSP is again successfully re-signaled, the ingress detour state machine will be
restarted.
• When the primary fails at the ingress:
The LSP switches to the detour path. If a standby is available then LSP would switch to
standby on expiration of hold-timer. If hold-timer is disabled then switchover to standby
would happen immediately. On successful global revert of primary path, the LSP would
switch back to the primary path.
• Admin groups are not taken into account when creating detours for LSPs.
Manual Bypass LSP
The 7210 SAS supports Manual bypass tunnels, on implementation of the Manual bypass feature a
LSP can be pre-configured from a PLR which is used exclusively for bypass protection. If a path
message for a new LSP requests for bypass protection, the node checks if a manual bypass tunnel
satisfying the path constraints exists. If a tunnel is found, it is selected. If no such tunnel exists by
default, the 7210 SAS dynamically signals a bypass LSP.
Users can disable the dynamic bypass creation on a per node basis using the CLI.
A maximum of 1000 associations of primary LSP paths can be made with a single manual bypass
at the PLR node. If dynamic bypass creation is disabled on the node, it is recommended to
configure additional manual bypass LSPs to handle the required number of associations.
7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide Page 23
Label Switching Routers
ABEC
F
D
PLR Bypass LSP Selection Rules
Figure 3: Bypass Tunnel Nodes
The PLR uses the following rules to select a bypass LSP among multiple manual and dynamic
bypass LSP’s at the time of establishment of the primary LSP path or when searching for a bypass
for a protected LSP which does not have an association with a bypass tunnel:
1. The MPLS/RSVP task in the PLR node checks if an existing manual bypass satisfies the
constraints. If the path message for the primary LSP path indicated node protection
desired, which is the default LSP FRR setting at the head end node, MPLS/RSVP task
searches for a node-protect’ bypass LSP. If the path message for the primary LSP path
indicated link protection desired, then it searches for a link-protect bypass LSP.
2. If multiple manual bypass LSPs satisfying the path constraints exist, it will prefer a
manual-bypass terminating closer to the PLR over a manual bypass terminating further
away. If multiple manual bypass LSPs satisfying the path constraints terminate on the
same downstream node, it selects one with the lowest IGP path cost or if in a tie, picks the
first one available.
3. If none satisfies the constraints and dynamic bypass tunnels have not been disabled on
PLR node, then the MPLS/RSVP task in the PLR will check if any of the already
established dynamic bypasses of the requested type satisfies the constraints.
4. If none do, then the MPLS/RSVP task will ask CSPF to check if a new dynamic bypass of
the requested type, node-protect or link-protect, can be established.
5. If the path message for the primary LSP path indicated node protection desired, and no
manual bypass was found after Step 1, and/or no dynamic bypass LSP was found after 3
attempts of performing Step 3, the MPLS/RSVP task will repeat Steps 1-3 looking for a
suitable link-protect bypass LSP. If none are found, the primary LSP will have no
protection and the PLR node must clear the “local protection available” flag in the IPv4
address sub-object of the RRO starting in the next Resv refresh message it sends upstream.
6. If the path message for the primary LSP path indicated link protection desired, and no
manual bypass was found after step 1, and/or no dynamic bypass LSP was found after
performing Step 3, the primary LSP will have no protection and the PLR node must clear
the “local protection available” flag in the IPv4 address sub-object of the RRO starting in
the next RESV refresh message it sends upstream. The PLR will not search for a nodeprotect’ bypass LSP in this case.
Page 24 7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide
MPLS and RSVP
7. If the PLR node successfully makes an association, it must set the “local protection
available” flag in the IPv4 address sub-object of the RRO starting in the next RESV
refresh message it sends upstream.
8. For all primary LSP that requested FRR protection but are not currently associated with a
bypass tunnel, the PLR node on reception of RESV refresh on the primary LSP path
repeats Steps 1-7.
If the user disables dynamic-bypass tunnels on a node while dynamic bypass tunnels were
activated and were passing traffic, traffic loss will occur on the protected LSP. Furthermore, if no
manual bypass exist that satisfy the constraints of the protected LSP, the LSP will remain without
protection.
If the user configures a bypass tunnel on node B and dynamic bypass tunnels have been disabled,
LSPs which have been previously signaled and which were not associated with any manual bypass
tunnel, for example, none existed, will be associated with the manual bypass tunnel if suitable.
The node checks for the availability of a suitable bypass tunnel for each of the outstanding LSPs
every time a RESV message is received for these LSPs.
If the user configures a bypass tunnel on node B and dynamic bypass tunnels have not been
disabled, LSPs which have been previously signaled over dynamic bypass tunnels will not
automatically be switched into the manual bypass tunnel even if the manual bypass is a more
optimized path. The user will have to perform a make before break at the head end of these LSPs.
If the manual bypass goes into the down state in node B and dynamic bypass tunnels have been
disabled, node B (PLR) will clear the “protection available” flag in the RRO IPv4 sub-object in
the next RESV refresh message for each affected LSP. It will then try to associate each of these
LSPs with one of the manual bypass tunnels that are still up. If it finds one, it will make the
association and set again the “protection available” flag in the next RESV refresh message for
each of these LSPs. If it could not find one, it will keep checking for one every time a RESV
message is received for each of the remaining LSPs. When the manual bypass tunnel is back UP,
the LSPs which did not find a match will be associated back to this tunnel and the protection
available flag is set starting in the next RESV refresh message.
If the manual bypass goes into the down state in node B and dynamic bypass tunnels have not
been disabled, node B will automatically signal a dynamic bypass to protect the LSPs if a suitable
one does not exist. Similarly, if an LSP is signaled while the manual bypass is in the down state,
the node will only signal a dynamic bypass tunnel if the user has not disabled dynamic tunnels.
When the manual bypass tunnel is back into the UP state, the node will not switch the protected
LSPs from the dynamic bypass tunnel into the manual bypass tunnel.
7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide Page 25
Label Switching Routers
P_5
PE_1
PE_3
P_1
P_3
P_2
P_4
PE_2
PE_4
FRR Node-Protection (Facility)
The MPLS Fast Re-Route (FRR) functionality enables PLRs to be aware of the missing node
protection and lets them regularly probe for a node-bypass. The following describes an LSP
scenario:
Figure 4: FRR Node-Protection Example
Where:
• LSP 1: between PE_1 to PE_2, with CSPF, FRR facility node-protect enabled.
• P_1 protects P_2 with bypass-nodes P_1 -P_3 - P_4 - PE_4 -PE_2.
• If P_4 fails, P_1 tries to establish the bypass-node three times.
• When the bypass-node creation fails, P_1 will protect link P_1-P_2.
• P_1 protects the link to P_2 through P_1 - P_5 - P_2.
• P_4 returns online.
Since LSP 1 had requested node protection, but due to lack of any available path, it could only
obtain link protection. Therefore, every 60 seconds the PLR for LSP 1 will search for a new path
that might be able to provide node protection. Once P_4 is back online and such a path is available,
A new bypass tunnel will be signaled and LSP 1 will get associated with this new bypass tunnel.
Uniform FRR Failover Time
The failover time during FRR consists of a detection time and a switchover time. The detection
time corresponds to the time it takes for the RSVP control plane protocol to detect that a network
IP interface is down or that a neighbor/next-hop over a network IP interface is down. The control
plane can be informed of an interface down event when event is due to a failure in a lower layer
such in the physical layer. The control plane can also detect the failure of a neighbor/next-hop on
its own by running a protocol such as Hello, Keep-Alive, or BFD.
Page 26 7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide
MPLS and RSVP
The switchover time is measured from the time the control plane detected the failure of the
interface or neighbor/next-hop to the time the IOM completed the reprogramming of all the
impacted ILM or service records in the data path. This includes the time it takes for the control
plane to send a down notification to all IOMs to request a switch to the backup NHLFE.
Uniform Fast-Reroute (FRR) failover enables the switchover of MPLS and service packets from
the outgoing interface of the primary LSP path to that of the FRR backup LSP within the same
amount of time regardless of the number of LSPs or service records. This is achieved by updating
Ingress Label Map (ILM) records and service records to point to the backup Next-Hop Label to
Forwarding Entry (NHLFE) in a single operation.
7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide Page 27
Label Switching Routers
OSSG015
ILER
1
LSR
2
LSR
3
ELER
4
PATH
RESV
LSP
PATH PATH
RESV RESV
RSVP
The Resource Reservation Protocol (RSVP) is a network control protocol used by a host to request
specific qualities of service from the network for particular application data streams or flows.
RSVP is also used by routers to deliver quality of service (QoS) requests to all nodes along the
path(s) of the flows and to establish and maintain state to provide the requested service. RSVP
requests generally result in resources reserved in each node along the data path. MPLS leverages
this RSVP mechanism to set up traffic engineered LSPs. RSVP is not enabled by default and must
be explicitly enabled.
RSVP requests resources for simplex flows. It requests resources 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. RSVP operates with unicast and multicast routing protocols.
Routing protocols determine where packets are forwarded. RSVP consults local routing tables to
relay RSVP messages.
RSVP uses two message types to set up LSPs, PATH and RESV. Figure 5 depicts the process to
establish an LSP.
• The sender (the ingress LER (ILER)), sends PATH messages toward the receiver, (the
egress LER (ELER)) to indicate the FEC for which label bindings are desired. PATH
messages are used to signal and request label bindings required to establish the LSP from
ingress to egress. Each router along the path observes the traffic type.
PATH messages facilitate the routers along the path to make the necessary bandwidth
reservations and distribute the label binding to the router upstream.
• The ELER sends label binding information in the RESV messages in response to PATH
messages received.
• The LSP is considered operational when the ILER receives the label binding information.
Figure 5: Establishing LSPs
Page 28 7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide
MPLS and RSVP
SFO
10.10.10.1
SFO
10.10.10.1
PATH:30.30.30.1
1
RESV:10.10.10.1 RESV:10.10.10.1 RESV:10.10.10.1 RESV:10.10.10.1
label
100|push
1342
100 200 300
100|200|swap
PATH:30.30.30.1
label
200|300|swap
PATH:30.30.30.1
3
label
42
label
300|pop
NYC
30.30.30.1
NYC
30.30.30.1
OSSG016
Figure 6: LSP Using RSVP Path Set Up
Figure 6 displays an example of an LSP path set up using RSVP. The ingress label edge router
(ILER 1) transmits an RSVP path message (path: 30.30.30.1) downstream to the egress label edge
router (ELER 4). The path message contains a label request object that requests intermediate LSRs
and the ELER to provide a label binding for this path.
In addition to the label request object, an RSVP PATH message can also contain a number of
optional objects:
• Explicit route object (ERO) — When the ERO is present, the RSVP path message is
forced to follow the path specified by the ERO (independent of the IGP shortest path).
• Record route object (RRO) — Allows the ILER to receive a listing of the LSRs that the
LSP tunnel actually traverses.
• A session attribute object controls the path set up priority, holding priority, and localrerouting features.
Upon receiving a path message containing a label request object, the ELER transmits a RESV
message that contains a label object. The label object contains the label binding that the
downstream LSR communicates to its upstream neighbor. The RESV message is sent upstream
towards the ILER, in a direction opposite to that followed by the path message. Each LSR that
processes the RESV message carrying a label object uses the received label for outgoing traffic
associated with the specific LSP. When the RESV message arrives at the ingress LSR, the LSP is
established.
Using RSVP for MPLS
Hosts and routers that support both MPLS and RSVP can associate labels with RSVP flows. When
MPLS and RSVP are combined, the definition of a flow can be made more flexible. Once an LSP
is established, the traffic through the path is defined by the label applied at the ingress node of the
LSP. The mapping of label to traffic can be accomplished using a variety of criteria. The set of
7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide Page 29
Using RSVP for MPLS
packets that are assigned the same label value by a specific node are considered to belong to the
same FEC which defines the RSVP flow.
For use with MPLS, RSVP already has the resource reservation component built-in which makes it
ideal to reserve resources for LSPs.
RSVP Traffic Engineering Extensions for MPLS
RSVP has been extended for MPLS to support automatic signaling of LSPs. To enhance the
scalability, latency, and reliability of RSVP signaling, several extensions have been defined.
Refresh messages are still transmitted but the volume of traffic, the amount of CPU utilization, and
response latency are reduced while reliability is supported. None of these extensions result in
backward compatibility problems with traditional RSVP implementations.
• Hello Protocol on page 30
• MD5 Authentication of RSVP Interface on page 30
Hello Protocol
The Hello protocol detects the loss of a neighbor node or the reset of a neighbor’s RSVP state
information. In standard RSVP, neighbor monitoring occurs as part of RSVP’s soft-state model.
The reservation state is maintained as cached information that is first installed and then
periodically refreshed by the ingress and egress LSRs. If the state is not refreshed within a
specified time interval, the LSR discards the state because it assumes that either the neighbor node
has been lost or its RSVP state information has been reset.
The Hello protocol extension is composed of a hello message, a hello request object and a hello
ACK object. Hello processing between two neighbors supports independent selection of failure
detection intervals. Each neighbor can automatically issue hello request objects. Each hello
request object is answered by a hello ACK object.
MD5 Authentication of RSVP Interface
When enabled on an RSVP interface, authentication of RSVP messages operates in both directions
of the interface.
A node maintains a security association with its neighbors for each authentication key. The
following items are stored in the context of this security association:
• The HMAC-MD5 authentication algorithm.
• Key used with the authentication algorithm.
Page 30 7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide
MPLS and RSVP
• Lifetime of the key. A key is user-generated key using a third party software/hardware and
enters the value as static string into CLI configuration of the RSVP interface. The key will
continue to be valid until it is removed from that RSVP interface.
• Source Address of the sending system.
• Latest sending sequence number used with this key identifier.
The RSVP sender transmits an authenticating digest of the RSVP message, computed using the
shared authentication key and a keyed-hash algorithm. The message digest is included in an
Integrity object which also contains a Flags field, a Key Identifier field, and a Sequence Number
field. The RSVP sender complies to the procedures for RSVP message generation in RFC 2747,
RSVP Cryptographic Authentication.
An RSVP receiver uses the key together with the authentication algorithm to process received
RSVP messages.
When a PLR node switches the path of the LSP to a bypass LSP, it does not send the Integrity
object in the RSVP messages over the bypass tunnel. If an integrity object is received from the MP
node, then the message is discarded since there is no security association with the next-next-hop
MP node.
The MD5 implementation does not support the authentication challenge procedures in RFC 2747.
Reservation Styles
LSPs can be signaled with explicit reservation styles. A reservation style is a set of control options
that specify a number of supported parameters. The style information is part of the LSP
configuration. SR OS supports two reservation styles:
Note that if FRR option is enabled for the LSP and selects the facility FRR method at the head-end
node, only the SE reservation style is allowed. Furthermore, if a PLR node receives a path
message with fast-reroute requested with facility method and the FF reservation style, it will reject
the reservation. The one-to-one detour method supports both FF and SE styles.
RSVP Message Pacing
When a flood of signaling messages arrive because of topology changes in the network, signaling
messages can be dropped which results in longer set up times for LSPs. RSVP message pacing
controls the transmission rate for RSVP messages, allowing the messages to be sent in timed
intervals. Pacing reduces the number of dropped messages that can occur from bursts of signaling
messages in large networks.
7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide Page 31
RSVP Overhead Refresh Reduction
RSVP Overhead Refresh Reduction
The RSVP refresh reduction feature consists of the following capabilities implemented in
accordance to RFC 2961, RSVP Refresh Overhead Reduction Extensions:
• RSVP message bundling — This capability is intended to reduce overall message
handling load. The supports receipt and processing of bundled message only, but no
transmission of bundled messages.
• Reliable message delivery: — This capability consists of sending a message-id and
returning a message-ack for each RSVP message. It can be used to detect message loss
and support reliable RSVP message delivery on a per hop basis. It also helps reduce the
refresh rate since the delivery becomes more reliable.
• Summary refresh — This capability consists of refreshing multiples states with a single
message-id list and sending negative ACKs (NACKs) for a message_id which could not
be matched. The summary refresh capability reduce the amount of messaging exchanged
and the corresponding message processing between peers. It does not however reduce the
amount of soft state to be stored in the node.
These capabilities can be enabled on a per-RSVP-interface basis are referred to collectively as
“refresh overhead reduction extensions”. When the refresh-reduction is enabled on a RSVP
interface, the node indicates this to its peer by setting a refresh-reduction- capable bit in the flags
field of the common RSVP header. If both peers of an RSVP interface set this bit, all the above
three capabilities can be used. Furthermore, the node monitors the settings of this bit in received
RSVP messages from the peer on the interface. As soon as this bit is cleared, the node stops
sending summary refresh messages. If a peer did not set the “refresh-reduction-capable” bit, a
node does not attempt to send summary refresh messages.
Configuring Implicit Null
The implicit null label option allows a router egress LER to receive MPLS packets from the
previous hop without the outer LSP label. The operation of the previous hop is referred to as
penultimate hop popping (PHP).
This option is signaled by the egress LER to the previous hop during the LSP signaling with RSVP
control protocol. In addition, the egress LER can be configured to receive MPLS packet with the
implicit null label on a static LSP.
The user can configure your router to signal the implicit null label value over all RSVP interfaces
and for all RSVP LSPs for which this node is the egress LER using the implicit-null-label
command in the config>router>rsvp context. The user must shutdown RSVP before being able to
change the implicit null configuration option.
Page 32 7210 SAS OS 7210 SAS-K 2F4T6C MPLS Guide
Loading...