draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt   rfc4090.txt 
Internet Draft Ping Pan, Ed (Ciena Corp) Network Working Group P. Pan, Ed.
Expires: February 2005 George Swallow, Ed (Cisco Systems) Request for Comments: 4090 Hammerhead Systems
Alia Atlas, Ed (Avici Systems) Category: Standards Track G. Swallow, Ed.
Cisco Systems
A. Atlas, Ed.
Avici Systems
May 2005
Fast Reroute Extensions to RSVP-TE for LSP Tunnels Fast Reroute Extensions to RSVP-TE for LSP Tunnels
draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt Status of This Memo
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet-Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as ``work in progress.'' Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2005).
http://www.ietf.org/shadow.html.
Abstract Abstract
This document defines extensions to and describes the use of RSVP to This document defines RSVP-TE extensions to establish backup label-
establish backup label-switched path (LSP) tunnels for local repair switched path (LSP) tunnels for local repair of LSP tunnels. These
of LSP tunnels. These mechanisms enable the re-direction of traffic mechanisms enable the re-direction of traffic onto backup LSP tunnels
onto backup LSP tunnels in 10s of milliseconds in the event of a in 10s of milliseconds, in the event of a failure.
failure.
Two methods are defined here. The one-to-one backup method creates Two methods are defined here. The one-to-one backup method creates
detour LSPs for each protected LSP at each potential point of local detour LSPs for each protected LSP at each potential point of local
repair. The facility backup method creates a bypass tunnel to repair. The facility backup method creates a bypass tunnel to
protect a potential failure point; by taking advantage of MPLS label protect a potential failure point; by taking advantage of MPLS label
stacking, this bypass tunnel can protect a set of protected LSPs that stacking, this bypass tunnel can protect a set of LSPs that have
have similar backup constraints. Both methods can be used to protect similar backup constraints. Both methods can be used to protect
links and nodes during network failure. The described behavior and links and nodes during network failure. The described behavior and
extensions to RSVP allow nodes to implement either or both methods extensions to RSVP allow nodes to implement either method or both and
and to interoperate in a mixed network. to interoperate in a mixed network.
Contents
1 Authors .................................................. 3
2 Introduction ............................................. 3
2.1 Background ........................................... 4
3 Terminology ............................................... 5
4 Local Repair Techniques ................................... 7
4.1 One-to-one Backup ..................................... 7
4.2 Facility Backup ....................................... 8
5 RSVP Extensions ........................................... 9
5.1 FAST_REROUTE Object ................................... 9
5.2 DETOUR Object ......................................... 12
5.2.1 DETOUR object for IPv4 address .................... 12
5.2.2 DETOUR object for IPv6 address .................... 13
5.3 SESSION_ATTRIBUTE Flags ............................... 14
5.4 RRO IPv4/IPv6 Sub-Object Flags ........................ 15
6 Head-End Behavior ......................................... 16
7 Point of Local Repair Behavior ............................ 17
7.1 Signaling a Backup Path ............................... 18
7.1.1 Backup Path Identification: Sender-Template Specific 19
7.1.2 Backup Path Identification: Path-Specific ......... 20
7.2 Procedures for Backup Path Computation ................ 20
7.3 Signaling Backups for One-To-One Protection ........... 22
7.3.1 Make-Before-Break with Detour LSPs ................ 23
7.3.2 Message Handling .................................. 23
7.3.3 Local Reroute of Traffic Onto Detour LSP ........... 24
7.4 Signaling for Facility Protection ..................... 25
7.4.1 Discovering Downstream Labels ..................... 25
7.4.2 Procedures for the PLR before Local Repair ........ 25
7.4.3 Procedures for the PLR during Local Repair ........ 25
7.4.4 Processing backup tunnel's ERO .................... 26
7.5 PLR Procedures During Local Repair ..................... 27
7.5.1 Notification of local repair ...................... 27
7.5.2 Revertive Behavior ................................ 28
8 Merge Node Behavior ....................................... 29
8.1 Handling Backup Path Messages Before Failure .......... 29
8.1.1 Merging Backup Paths using the Sender-Template
Specific Method ................................... 30
8.1.2 Merging Detours using Path-Specific Method ........ 30
8.1.2.1 An Example on Path Message Merging ............ 31
8.1.3 Message Handling for Merged Detours ............... 32
8.2 Handling Failures ..................................... 32
9 Behavior of all LSRs ...................................... 33
9.1 Merging Detours in Path-Specific Method ............... 33
10 Security Considerations ................................... 34
11 IANA Guidelines ........................................... 34
12 Intellectual Property Considerations ...................... 34
13 Full Copyright Statement .................................. 35
14 Acknowledgments ........................................... 35
15 Normative References ...................................... 36
16 Editor Information ........................................ 36
1. Authors Table of Contents
This document was written by George Swallow, Ping Pan, Alia Atlas, 1. Introduction ...................................................3
Jean Philippe Vasseur, Markus Jork, Der-Hwa Gan, and Dave Cooper. 1.1. Background ...............................................4
2. Terminology ....................................................4
3. Local Repair Techniques ........................................6
3.1. One-to-One Backup ........................................6
3.2. Facility Backup ..........................................7
4. RSVP Extensions ................................................8
4.1. FAST_REROUTE Object ......................................8
4.2. DETOUR Object ...........................................11
4.2.1. DETOUR Object for IPv4 Address ...................11
4.2.2. DETOUR Object for IPv6 Address ...................12
4.3. SESSION_ATTRIBUTE Flags .................................13
4.4. RRO IPv4/IPv6 Sub-object Flags ..........................14
5. Head-End Behavior .............................................15
6. Point of Local Repair (PLR) Behavior ..........................16
6.1. Signaling a Backup Path .................................17
6.1.1. Backup Path Identification: Sender
Template-Specific ................................19
6.1.2. Backup Path Identification: Path-Specific ........19
6.2. Procedures for Backup Path Computation ..................20
6.3. Signaling Backups for One-to-One Protection .............21
6.3.1. Make-before-Break with Detour LSPs ...............22
6.3.2. Message Handling .................................23
6.3.3. Local Reroute of Traffic onto Detour LSP .........23
6.4. Signaling for Facility Protection .......................24
6.4.1. Discovering Downstream Labels ....................24
6.4.2. Procedures for the PLR before Local Repair .......24
6.4.3. Procedures for the PLR during Local Repair .......25
6.4.4. Processing Backup Tunnel's ERO ...................26
6.5. PLR Procedures during Local Repair ......................26
6.5.1. Notification of Local Repair .....................26
6.5.2. Revertive Behavior ...............................27
7. Merge Node Behavior ...........................................28
7.1. Handling Backup Path Messages before Failure ............28
7.1.1. Merging Backup Paths using the Sender
Template-Specific Method .........................29
7.1.2. Merging Detours using the Path-Specific Method ...29
7.1.3. Message Handling for Merged Detours ..............31
7.2. Handling Failures .......................................31
8. Behavior of All LSRs ..........................................32
8.1. Merging Detours in the Path-Specific Method .............32
9. Security Considerations .......................................33
10. IANA Considerations ...........................................33
11. Contributors ..................................................35
12. Acknowledgments ...............................................36
13. Normative References ..........................................36
Jean Philippe Vasseur 1. Introduction
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA
email: jpv@cisco.com
phone: +1 978 497 6238
Markus Jork This document extends RSVP [RSVP] to establish backup label-switched
Avici Systems path (LSP) tunnels for the local repair of LSP tunnels. This
101 Billerica Avenue extension will meet the needs of real-time applications such as voice
N. Billerica, MA 01862 over IP, for which user traffic should be redirected onto backup LSP
USA tunnels in 10s of milliseconds. This timing requirement can be
email: mjork@avici.com satisfied by computing and signaling backup LSP tunnels in advance of
phone: +1 978 964 2142 failure and by re-directing traffic as close to the failure point as
possible. In this way, the time for redirection includes no path
computation and no signaling delays, including delays to propagate
failure notification between label-switched routers (LSRs). Speed of
repair is the primary advantage of the methods and extensions
described here. The term local repair is used when referring to
techniques that re-direct traffic to a backup LSP tunnel in response
to a local failure.
Der-Hwa Gan A protected LSP is an explicitly-routed LSP that is provided with
Juniper Networks protection. The repair methods described here are applicable only to
1194 N.Mathilda Ave explicitly-routed LSPs. Application of these methods to LSPs that
Sunnyvale, CA 94089 dynamically change their routes, such as LSPs used in unicast IGP
USA routing, is beyond the scope of this document.
e-mail: dhg@juniper.net
phone: +1 408 745 2074
Dave Cooper Section 2 covers new terminology used in this document. Section 3
Global Crossing describes two basic methods for creating backup LSPs. Section 4
960 Hamlin Court describes the RSVP protocol extensions to support local protection.
Sunnyvale, CA 94089 Section 5 presents the behavior of an LSR that seeks to request local
USA protection for an LSP. The behavior of a potential point of local
email: dcooper@gblx.net repair (PLR) is given in Section 6, which describes how to determine
phone: +1 916 415 0437 the appropriate strategy for protecting an LSP and how to implement
each of the strategies. Section 7 describes the behavior of a merge
node, the LSR where a protected LSP and its backup LSP rejoin.
Finally, Section 8 discusses the required behavior of other nodes in
the network.
2. Introduction The methods discussed in this document depend upon three assumptions:
This document extends RSVP [RSVP] to establish backup LSP tunnels o An LSR that is on the path of a protected LSP should always
for the local repair of LSP tunnels. This technique is presented assume that it is a merge point. This is necessary because
to meet the needs of real-time applications, such as voice over IP, the facility backup method does not signal backups through a
for which it is highly desirable to be able to re-direct user bypass tunnel before failure.
traffic onto backup LSP tunnels in 10s of milliseconds. This
timing requirement can be satisfied by computing and signaling
backup LSP tunnels in advance of failure and by re-directing
traffic as close to failure point as possible. In this way, the
time for the redirection does not include any path computation or
signaling delays, including delays to propagate failure
notification between LSRs. The speed of repair made possible by
the techniques and extensions described herein is the primary
advantage of this method. We use the term local repair when
referring to techniques which accomplish this, and refer to an
explicitly routed LSP which is provided with such protection as a
protected LSP. These techniques are applicable only to explicitly
routed LSPs; Application of the techniques discussed herein to LSPs
which dynamically change their routes such as those used in unicast
IGP routing is beyond the scope of this document.
Section 3 covers new terminology used in this document. The two o If the one-to-one backup method is used and a DETOUR object
basic strategies for creating backup LSPs are described in Section is included, the LSRs in the traffic-engineered network
4. In Section 5, the protocol extensions to RSVP to support local should support the DETOUR object. This is necessary so that
protection are described. In Section 6, the behavior of an LER the Path message containing the DETOUR object is not
which wishes to request local protection for an LSP is presented. rejected.
The behavior of a potential point of local repair (PLR) is given in
Section 7; this describes how to determine the appropriate strategy
to use for protecting an LSP and how to implement each of the
strategies. The behavior of a merge node, the LSR where a
protected LSP and its backup LSP rejoin, is described in Section 8.
Finally, the required behavior of other nodes in the network is
discussed in Section 9.
For the techniques discussed in this document to function properly, o Understanding the DETOUR object is required to support the
there are three assumptions which must be made. First, an LSR path-specific method, which requires that LSRs in the
which is on the path of a protected LSP SHOULD always assume that
it is a merge point; this is necessary because the facility backup
method does not signal backups through a bypass tunnel before
failure. Second, if the one-to-one backup method is used and a
DETOUR object is included, the LSRs in the traffic-engineered
network should support the DETOUR object; this is necessary so that
the Path message containing the DETOUR object is not rejected.
Third, understanding of the DETOUR object is required to support
the path-specific method which requires that LSRs in the
traffic-engineered network be capable of merging detours. traffic-engineered network be capable of merging detours.
2.1 Background 1.1. Background
Several years before work began on this draft, operational networks Several years before work began on this document, operational
had deployed two independent methods of doing fast reroute, called networks had deployed two independent methods of doing fast reroute;
herein one-to-one backup and facility backup. Vendors trying to these methods are called here one-to-one backup and facility backup.
support both methods were experiencing incompatiblity problems in Vendors trying to support both methods experienced compatibility
attempting to produce a single implementation capable of problems in attempting to produce a single implementation capable of
interoperating with both. There are technical tradeoffs between interoperating with both methods. There are technical tradeoffs
the methods. However these tradeoffs are so topologically between the methods. These tradeoffs are so topologically dependent
dependent, that the community has not converged on a single that the community has not converged on a single approach.
approach.
This draft rationalizes the RSVP signaling for both methods such This document rationalizes the RSVP signaling for both methods so
that any implementation can recognize all FRR requests and clearly that any implementation can recognize all fast reroute requests and
respond, either positively if they are capable of performing the clearly respond. The response may be positive if the method can be
method, or with a clear error such that requester is informed and performed, or it may be a clear error to inform the requester to seek
can seek alternate means of backup. This draft also allows a alternate backup means. This document also allows a single
single implementation to support both methods, thereby providing a implementation to support both methods, thereby providing a range of
range of capabilities. Thus the described behavior and extensions capabilities. The described behavior and extensions to RSVP allow
to RSVP allow LERs and LSRs to implement either or both methods. LERs and LSRs to implement either method or both.
While the two methods could in principle be used in a single While the two methods could in principle be used in a single network,
network, it is expected that operators will continue to choose to it is expected that operators will continue to deploy either one or
deploy either one or the other. The goal of this draft is to the other. The goal of this document is to standardize the RSVP
standardize the RSVP signaling such that either a network with LSRs signaling so that a network composed of LSRs that implement both
that implement both methods or an network composed of some LSRs methods or a network composed of some LSRs that support one method
that support one method and others that support both, can properly and others that support both can properly signal among those LSRs to
signal among those LSRs to achieve fast restoration through the achieve fast restoration.
chosen method.
3. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC-WORDS]. document are to be interpreted as described in RFC2119 [RFC-WORDS].
The reader is assumed to be familiar with the terminology in [RSVP] The reader is assumed to be familiar with the terminology in [RSVP]
and [RSVP-TE]. and [RSVP-TE].
LSR - Label Switch Router LSR: Label-Switch Router.
LSP - An MPLS Label Switched Path. In this document, an LSP LSP: An MPLS Label-Switched Path. In this document, an LSP will
will always refer to an explicitly routed LSP. always be explicitly routed.
Local Repair - Techniques used to repair LSP tunnels quickly Local Repair: Techniques used to repair LSP tunnels quickly when a
when a node or link along the LSPs path fails. node or link along the LSP's path fails.
PLR - Point of Local Repair. The head-end LSR of a backup tunnel PLR: Point of Local Repair. The head-end LSR of a backup tunnel
or a detour LSP. or a detour LSP.
One-to-one Backup - A local repair technique where a backup LSP One-to-One Backup: A local repair method in which a backup LSP is
is separately created for each protected LSP at a PLR. separately created for each protected LSP at a PLR.
Facility Backup - A local repair technique where a bypass tunnel Facility Backup: A local repair method in which a bypass tunnel is
is used to protect one or more protected LSPs which used to protect one or more protected LSPs that traverse the
traverse the PLR, the resource being protected and the PLR, the resource being protected, and the Merge Point in
Merge Point in that order. that order.
Protected LSP - An LSP is said to be protected at a given hop if Protected LSP: An LSP is said to be protected at a given hop if it
it has one or multiple associated backup tunnels originating has one or multiple associated backup tunnels originating at
at that hop. that hop.
Detour LSP - The LSP that is used to re-route traffic around Detour LSP: The LSP that is used to re-route traffic around a
a failure in one-to-one backup. failure in one-to-one backup.
Bypass Tunnel - An LSP that is used to protect a set of LSPs Bypass Tunnel: An LSP that is used to protect a set of LSPs
passing over a common facility. passing over a common facility.
Backup Tunnel - The LSP that is used to backup up one of the many Backup Tunnel: The LSP that is used to backup up one of the many
LSPs in many-to-one backup. LSPs in many-to-one backup.
NHOP Bypass Tunnel - Next-Hop Bypass Tunnel. A backup tunnel NHOP Bypass Tunnel: Next-Hop Bypass Tunnel. A backup tunnel that
which bypasses a single link of the protected LSP. bypasses a single link of the protected LSP.
NNHOP Bypass Tunnel - Next-Next-Hop Bypass Tunnel. A backup NNHOP Bypass Tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel
tunnel which bypasses a single node of the protected LSP. that bypasses a single node of the protected LSP.
Backup Path - The LSP that is responsible for backing up one Backup Path: The LSP that is responsible for backing up one
protection LSP. A backup path refers to either a detour LSP protected LSP. A backup path refers to either a detour LSP
or a backup tunnel. or a backup tunnel.
MP - Merge Point. The LSR where one or more backup tunnels rejoin MP: Merge Point. The LSR where one or more backup tunnels rejoin
the path of the protected LSP, downstream of the potential the path of the protected LSP downstream of the potential
failure. The same LSR may be both an MP and a PLR failure. The same LSR may be both an MP and a PLR
simultaneously. simultaneously.
DMP - Detour Merge Point. In the case of one-to-one backup, DMP: Detour Merge Point. In the case of one-to-one backup, this
this is an LSR where multiple detours converge and only one is an LSR where multiple detours converge. Only one detour
detour is signaled beyond that LSR. is signaled beyond that LSR.
Reroutable LSP - Any LSP for which the head-end LSR requests Reroutable LSP: Any LSP for which the head-end LSR requests local
local protection. See Section 10.1 for more detail. protection. See Section 5 for more detail.
CSPF - Constraint-based Shortest Path First. CSPF: Constraint-based Shortest Path First.
SRLG Disjoint - A path is considered to be SRLG disjoint from a SRLG Disjoint: A path is considered to be SRLG disjoint from a
given link or node if the path does not use any links or given link or node if the path does not use any links or
nodes which belong to the same SRLG as that given link or nodes which belong to the same SRLG as that given link or
node. node.
4. Local Repair Techniques 3. Local Repair Techniques
Two different techniques for local protection are presented here. Two different methods for local protection are described. In the
The one-to-one backup technique has a PLR compute a separate backup one-to-one backup method, a PLR computes a separate backup LSP,
LSP, called a detour LSP, for each LSP which the PLR protects using called a detour LSP, for each LSP that the PLR protects. In the
this technique. With the facility backup technique, the PLR creates facility backup method, the PLR creates a single bypass tunnel that
a single bypass tunnel which can be used to protect multiple LSPs. can be used to protect multiple LSPs.
4.1. One-to-one backup 3.1. One-to-One Backup
In the one-to-one technique, a label switched path is established In the one-to-one backup method, a label-switched path is established
which intersects the original LSP somewhere downstream of the point that intersects the original LSP somewhere downstream of the point of
of link or node failure. For each LSP which is backed up, a link or node failure. A separate backup LSP is established for each
separate backup LSP is established. LSP that is backed up.
[R1]---[R2]-----[R3]----[R4]---[R5] [R1]----[R2]----[R3]------[R4]------[R5]
\ \ \ / \ / \ \ \ / \ /
[R6]---[R7]-------[R8]----[R9] [R6]----[R7]----[R8]------[R9]
Protected LSP: [R1->R2->R3->R4->R5] Protected LSP: [R1->R2->R3->R4->R5]
R1's Backup: [R1->R6->R7->R8->R3] R1's Backup: [R1->R6->R7->R8->R3]
R2's Backup: [R2->R7->R8->R4] R2's Backup: [R2->R7->R8->R4]
R3's Backup: [R3->R8->R9->R5] R3's Backup: [R3->R8->R9->R5]
R4's Backup: [R4->R9->R5] R4's Backup: [R4->R9->R5]
Example 1: One-to-One Backup Technique Example 1. One-to-One Backup Technique
In the simple topology shown above in Example 1, the protected LSP In the simple topology shown in Example 1, the protected LSP runs
runs from R1 to R5. R2 can provide user traffic protection by from R1 to R5. R2 can provide user traffic protection by creating a
creating a partial backup LSP which merges with the protected LSP partial backup LSP that merges with the protected LSP at R4. We
at R4. We refer to a partial one-to-one backup LSP refer to a partial one-to-one backup LSP [R2->R7->R8->R4] as a
[R2->R7->R8->R4] as a detour. detour.
To fully protect an LSP that traverses N nodes, there could be as To protect an LSP that traverses N nodes fully, there could be as
many as (N - 1) detours. The paths for the detours necessary to many as (N - 1) detours. Example 1 shows the paths for the detours
fully protect the LSP in Example 1 are given there. To minimize necessary to protect fully the LSP in the example. To minimize the
the number of LSPs in the network, it is desirable to merge a number of LSPs in the network, it is desirable to merge a detour back
detour back to its protected LSP when feasible. When a detour LSP to its protected LSP, when feasible. When a detour LSP intersects
intersects its protected LSP at an LSR with the same outgoing its protected LSP at an LSR with the same outgoing interface, it will
interface, it will be merged. be merged.
When a failure occurs along the protected LSP, the PLR redirects When a failure occurs along the protected LSP, the PLR redirects
traffic onto the local detour. For instance, if the link [R2->R3] traffic onto the local detour. For instance, if the link [R2->R3]
fails in Example 1, R2 will switch traffic received from R1 onto fails in Example 1, R2 will switch traffic received from R1 onto the
the protected LSP along link [R2->R7] using the label received when protected LSP along link [R2->R7], using the label received when R2
R2 created the detour. When R4 receives traffic with the label created the detour. When R4 receives traffic with the label provided
provided for R2's detour, R4 will switch that traffic onto link for R2's detour, R4 will switch that traffic onto link [R4-R5], using
[R4-R5] using the label received from R5 for the protected LSP. At the label received from R5 for the protected LSP. At no point does
no point does the depth of the label stack increase as a result of the depth of the label stack increase as a result of the detour.
taking the detour. While R2 is using its detour, traffic will take While R2 is using its detour, traffic will take the path
the path [R1->R2->R7->R8->R4->R5]. [R1->R2->R7->R8->R4->R5].
4.2. Facility backup 3.2. Facility Backup
The facility backup technique takes advantage of the MPLS label The facility backup method takes advantage of the MPLS label stack.
stack. Instead of creating a separate LSP for every backed-up LSP, a Instead of creating a separate LSP for every backed-up LSP, a single
single LSP is created which serves to backup up a set of LSPs. We LSP is created that serves to back up a set of LSPs. We call such an
call such an LSP tunnel a bypass tunnel. LSP tunnel a bypass tunnel.
The bypass tunnel must intersect the path of the original LSP(s) The bypass tunnel must intersect the path of the original LSP(s)
somewhere downstream of the PLR. Naturally, this constrains the somewhere downstream of the PLR. Naturally, this constrains the set
set of LSPs being backed-up via that bypass tunnel to those that of LSPs being backed up via that bypass tunnel to those that pass
pass through some common downstream node. All LSPs which pass through some common downstream node. All LSPs that pass through the
through the point of local repair and through this common node point of local repair and through this common node that do not also
which do not also use the facilities involved in the bypass tunnel use the facilities involved in the bypass tunnel are candidates for
are candidates for this set of LSPs. this set of LSPs.
[R8] [R8]
\ \
[R1]---[R2]----[R3]----[R4]---[R5] [R1]---[R2]----[R3]-----[R4]---[R5]
\ / \ \ / \
[R6]===[R7] [R9] [R6]===[R7] [R9]
Protected LSP 1: [R1->R2->R3->R4->R5] Protected LSP 1: [R1->R2->R3->R4->R5]
Protected LSP 2: [R8->R2->R3->R4] Protected LSP 2: [R8->R2->R3->R4]
Protected LSP 3: [R2->R3->R4->R9] Protected LSP 3: [R2->R3->R4->R9]
Bypass LSP Tunnel: [R2->R6->R7->R4] Bypass LSP Tunnel: [R2->R6->R7->R4]
Example 2: Facility Backup Technique Example 2. Facility Backup Technique
In Example 2, R2 has built a bypass tunnel which protects against the In Example 2, R2 has built a bypass tunnel that protects against the
failure of link [R2->R3] and node [R3]. The doubled lines represent failure of link [R2->R3] and node [R3]. The doubled lines represent
this tunnel. The scalability improvement this technique provides is this tunnel. This technique provides a scalability improvement, in
that the same bypass tunnel can also be used to protect LSPs from any that the same bypass tunnel can also be used to protect LSPs from any
of R1, R2 or R8 to any of R4, R5 or R9. Example 2 describes three of R1, R2, or R8 to any of R4, R5, or R9. Example 2 describes three
different protected LSPs which are using the same bypass tunnel for different protected LSPs that are using the same bypass tunnel for
protection. protection.
As with the one-to-one technique, to fully protect an LSP that As with the one-to-one method, there could be as many as (N-1) bypass
traverses N nodes, there could be as many as (N-1) bypass tunnels. tunnels to fully protect an LSP that traverses N nodes. However,
However, each of those bypass tunnels could protected a set of each of those bypass tunnels could protect a set of LSPs.
LSPs.
When a failure occurs along a protected LSP, the PLR redirects When a failure occurs along a protected LSP, the PLR redirects
traffic into the appropriate bypass tunnel. For instance, if link traffic into the appropriate bypass tunnel. For instance, if link
[R2->R3] fails in Example 2, R2 will switch traffic received from [R2->R3] fails in Example 2, R2 will switch traffic received from R1
R1 on the protected LSP onto link [R2->R6]; the label will be on the protected LSP onto link [R2->R6]. The label will be switched
switched for one which will be understood by R4 to indicate the for one which will be understood by R4 to indicate the protected LSP,
protected LSP and then the bypass tunnel's label will be pushed and the bypass tunnel's label will then be pushed onto the label-
onto the label-stack of the redirected packets. If stack of the redirected packets. If penultimate-hop-popping is used,
penultimate-hop-popping is used, then the merge point in Example 2, the merge point in Example 2, R4, will receive the redirected packet
R4, will receive the redirected packet with a label indicating the with a label indicating the protected LSP that the packet is to
protected LSP that the packet is to follow. If follow. If penultimate-hop-popping is not used, R4 will pop the
penultimate-hop-popping is not used, then R4 will pop the bypass bypass tunnel's label and examine the label underneath to determine
tunnel's label and examine the label underneath to determine the the protected LSP that the packet is to follow. When R2 is using the
protected LSP that the packet is to follow. When R2 is using the
bypass tunnel for protected LSP 1, the traffic takes the path bypass tunnel for protected LSP 1, the traffic takes the path
[R1->R2->R6->R7->R4->R5]; the bypass tunnel is the connection [R1->R2->R6->R7->R4->R5]; the bypass tunnel is the connection between
between R2 and R4. R2 and R4.
5. RSVP Extensions 4. RSVP Extensions
We propose two additional objects, FAST_REROUTE and DETOUR, to This specification defines two additional objects, FAST_REROUTE and
extend RSVP-TE for fast-reroute signaling. These new objects are DETOUR, to extend RSVP-TE for fast-reroute signaling. These new
backward compatible with LSRs that do not recognize them (see objects are backward compatible with LSRs that do not recognize them
section 3.10 in [RSVP]). Both objects can only be carried in RSVP (see section 3.10 in [RSVP]). Both objects can only be carried in
Path messages. RSVP Path messages.
The SESSION_ATTRIBUTE and RECORD_ROUTE objects are also extended to The SESSION_ATTRIBUTE and RECORD_ROUTE objects are also extended to
support bandwidth and node protection features. support bandwidth and node protection features.
5.1. FAST_REROUTE Object 4.1. FAST_REROUTE Object
The FAST-REROUTE object is used to control the backup used for the The FAST_REROUTE object is used to control the backup used for the
protected LSP. This specifies the setup and hold priorities, the protected LSP. This specifies the setup and hold priorities, session
session attribute filters, and bandwidth to be used for protection. attribute filters, and bandwidth to be used for protection. It also
It also allows a specific local protection technique to be requested. allows a specific local protection method to be requested. This
This object MUST only be inserted into the PATH message by the object MUST only be inserted into the PATH message by the head-end
head-end LER and MUST NOT be changed by downstream LSRs. The LER and MUST NOT be changed by downstream LSRs. The FAST_REROUTE
FAST-REROUTE object has the following format: object has the following format:
Class-Num = 205 Class-Num = 205
C-Type = 1 C-Type = 1
0 1 2 3 0 1 2 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type | | Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Setup Prio | Hold Prio | Hop-limit | Flags | | Setup Prio | Hold Prio | Hop-limit | Flags |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 10, line 26 skipping to change at page 9, line 26
| Include-any | | Include-any |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Exclude-any | | Exclude-any |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Include-all | | Include-all |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
Setup Priority Setup Priority
The priority of the backup path with respect to taking The priority of the backup path with respect to taking
resources, in the range of 0 to 7. The value 0 is the highest resources, in the range 0 to 7. The value 0 is the highest
priority. Setup Priority is used in deciding whether priority. Setup Priority is used in deciding whether this
this session can preempt another session. See [RSVP-TE] for session can preempt another session. See [RSVP-TE] for the
the usage on priority. usage on priority.
Holding Priority Holding Priority
The priority of the backup path with respect to holding The priority of the backup path with respect to holding
resources, in the range of 0 to 7. The value 0 is the highest resources, in the range 0 to 7. The value 0 is the highest
priority. Holding Priority is used in deciding whether this priority. Holding Priority is used in deciding whether this
session can be preempted by another session. See [RSVP-TE] for session can be preempted by another session. See [RSVP-TE] for
the usage on priority. the usage on priority.
Hop-limit Hop-limit
The maximum number of extra hops the backup path is allowed The maximum number of extra hops the backup path is allowed to
to take, from current node (a PLR) to a MP, with PLR and MP take, from current node (a PLR) to an MP, with PLR and MP
excluded in counting. For example, hop-limit of 0 means only excluded from the count. For example, hop-limit of 0 means
direct links between PLR and MP can be considered. that only direct links between PLR and MP can be considered.
Flags Flags
0x01 One-to-one Backup Desired 0x01 One-to-One Backup Desired
Indicates that protection via the one-to-one backup Requests protection via the one-to-one backup method.
technique is desired.
0x02 Facility Backup Desired 0x02 Facility Backup Desired
Indicates that protection via the facility backup Requests protection via the facility backup method.
technique is desired.
Bandwidth Bandwidth
Bandwidth estimate (32-bit IEEE floating point integer) in Bandwidth estimate; 32-bit IEEE floating point integer, in
bytes-per-second. bytes per second.
Exclude-any Exclude-any
A 32-bit vector representing a set of attribute filters A 32-bit vector representing a set of attribute filters
associated with a backup path any of which renders a link associated with a backup path, any of which renders a link
unacceptable. unacceptable.
Include-any Include-any
A 32-bit vector representing a set of attribute filters A 32-bit vector representing a set of attribute filters
associated with a backup path any of which renders a link associated with a backup path, any of which renders a link
acceptable (with respect to this test). A null set (all bits acceptable (with respect to this test). A null set (all bits
set to zero) automatically passes. set to zero) automatically passes.
Include-all Include-all
A 32-bit vector representing a set of attribute filters A 32-bit vector representing a set of attribute filters
associated with a backup path all of which must be present for associated with a backup path, all of which must be present for
a link to be acceptable (with respect to this test). A null set a link to be acceptable (with respect to this test). A null
(all bits set to zero) automatically passes. set (all bits set to zero) automatically passes.
The two high-order bits of the Class-Num (11) indicate that nodes The two high-order bits of the Class-Num (11) cause nodes that do not
that do not understand the object should ignore it and pass if understand the object to ignore it and pass it forward unchanged.
forward unchanged.
For informational purposes, a different C-type value and format for For informational purposes, a different C-Type value and format for
the FAST_REROUTE object are specified below. This is used by the FAST_REROUTE object are specified below. This is used by legacy
legacy implementations. The meaning of the fields is the same as implementations. The meaning of the fields is the same as that
described for C-Type 1. described for C-Type 1.
Class-Num = 205
C-Type = 7 C-Type = 7
0 1 2 3 0 1 2 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type | | Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Setup Prio | Hold Prio | Hop-limit | Reserved | | Setup Prio | Hold Prio | Hop-limit | Reserved |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Bandwidth | | Bandwidth |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Include-any | | Include-any |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Exclude-any | | Exclude-any |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
Unknown C-types should be treated as specified in [RSVP] Section Unknown C-Types should be treated as specified in [RSVP] Section
3.10. 3.10.
5.2. DETOUR Object 4.2. DETOUR Object
The DETOUR object is used in one-to-one backup to identify detour
LSPs. It has the following format:
Class-Num = 63 The DETOUR object is used in the one-to-one backup method to identify
detour LSPs.
5.2.1 DETOUR object for IPv4 address 4.2.1. DETOUR Object for IPv4 Address
Class-Num = 63
C-Type = 7 C-Type = 7
0 1 2 3 0 1 2 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type | | Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| PLR ID 1 | | PLR_ID 1 |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Avoid Node ID 1 | | Avoid_Node_ID 1 |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
// .... // // .... //
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| PLR ID n | | PLR_ID n |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Avoid Node ID n | | Avoid_Node_ID n |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
PLR ID (1 - n) PLR_ID (1 - n)
IPv4 address identifying the beginning point of detour which is
a PLR. Any local address on the PLR can be used.
Avoid Node ID (1 - n) IPv4 address identifying the PLR that is the beginning point of
the detour. Any local address on the PLR can be used.
IPv4 address identifying the immediate downstream node that Avoid_Node_ID (1 - n)
the PLR is trying to avoid. Any local address of the downstream
node can be used. This field is mandatory, and is used by
the MP for merging rules discussed below.
5.2.2 DETOUR object for IPv6 address IPv4 address identifying the immediate downstream node that the
PLR is trying to avoid. Any local address of the downstream
node can be used. This field is mandatory and is used by the
MP for the merging rules discussed below.
4.2.2. DETOUR Object for IPv6 Address
Class-Num = 63
C-Type = 8 C-Type = 8
0 1 2 3 0 1 2 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type | | Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| PLR ID 1 | | PLR_ID 1 |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| PLR ID 1 (continued) | | PLR_ID 1 (continued) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| PLR ID 1 (continued) | | PLR_ID 1 (continued) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| PLR ID 1 (continued) | | PLR_ID 1 (continued) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Avoid Node ID 1 | | Avoid_Node_ID 1 |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Avoid Node ID 1 (continued) | | Avoid_Node_ID 1 (continued) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Avoid Node ID 1 (continued) | | Avoid_Node_ID 1 (continued) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Avoid Node ID 1 (continued) | | Avoid_Node_ID 1 (continued) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
// .... // // .... //
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
PLR ID (1 - n) PLR_ID (1 - n)
An IPv6 128-bit unicast host address identifying the beginning An IPv6 128-bit unicast host address identifying the PLR that
point of detour which is a PLR. Any local address on the PLR is the beginning point of the detour. Any local address on the
can be used. PLR can be used.
Avoid Node ID (1 - n) Avoid_Node_ID (1 - n)
An IPv6 128-bit unicast host address identifying the immediate An IPv6 128-bit unicast host address identifying the immediate
downstream node that the PLR is trying to avoid. Any local downstream node that the PLR is trying to avoid. Any local
address on the downstream node can be used. This field is address on the downstream node can be used. This field is
mandatory, and is used by the MP for merging rules discussed mandatory and is used by the MP for the merging rules discussed
below. below.
There can be more than one pair of (PLR_ID, Avoid_Node_ID) entries in There can be more than one pair of (PLR_ID, Avoid_Node_ID) entries in
a DETOUR object. If detour merging is desired, after each merging a DETOUR object. If detour merging is desired, after each merging
operation, the Detour Merge Point should combine all the merged operation, the Detour Merge Point should combine all the merged
detours in the subsequent Path messages. detours in subsequent Path messages.
The high-order bit of the C-Class is zero; LSRs that do not support The high-order bit of the Class-Num is zero; LSRs that do not support
the DETOUR objects MUST reject any Path message containing a DETOUR the DETOUR objects MUST reject any Path message containing a DETOUR
object and send a PathErr to notify the PLR. This PathErr SHOULD object and send a PathErr to notify the PLR. This PathErr SHOULD be
be generated as specified in [RSVP] for unknown objects with a generated as specified in [RSVP] for unknown objects with a Class-Num
class-num of the form "0bbbbbbb". of the form "0bbbbbbb".
Unknown C-types should be treated as specified in [RSVP] Section Unknown C-Types should be treated as specified in [RSVP] Section
3.10. 3.10.
5.3. SESSION_ATTRIBUTE Flags 4.3. SESSION_ATTRIBUTE Flags
To explicitly request bandwidth and node protection, two new flags To request bandwidth and node protection explicitly, two new flags
are defined in the SESSION_ATTRIBUTE object. are defined in the SESSION_ATTRIBUTE object.
For both C-Type 1 and 7, the SESSION_ATTRIBUTE object currently has For both C-Type 1 and 7, the SESSION_ATTRIBUTE object currently has
the following flags defined: the following flags defined [RSVP-TE]:
Local protection desired: 0x01 Local protection desired: 0x01
This flag permits transit routers to use a local repair This flag permits transit routers to use a local repair
mechanism which may result in violation of the explicit route mechanism that may result in violation of the explicit route
object. When a fault is detected on an adjacent downstream link object. When a fault is detected on an adjacent downstream
or node, a transit node may reroute traffic for fast service link or node, a transit node may reroute traffic for fast
restoration. service restoration.
Label recording desired: 0x02 Label recording desired: 0x02
This flag indicates that label information should be included This flag indicates that label information should be included
when doing a route record. when doing a route record.
SE Style desired: 0x04 SE Style desired: 0x04
This flag indicates that the tunnel ingress node may choose to This flag indicates that the tunnel ingress node may choose to
reroute this tunnel without tearing it down. A tunnel egress reroute this tunnel without tearing it down. A tunnel egress
node SHOULD use the SE Style when responding with a Resv node SHOULD use the SE Style when responding with a Resv
message. When requesting fast reroute, the head-end LSR message. When requesting fast reroute, the head-end LSR SHOULD
SHOULD set this flag; this is not necessary for the set this flag; this is not necessary for the path-specific
path-specific method of the one-to-one backup technique. method of the one-to-one backup method.
The following new flags are defined: The following new flags are defined:
Bandwidth protection desired: 0x08 Bandwidth protection desired: 0x08
This flag indicates to the PLRs along the protected LSP path This flag indicates to the PLRs along the protected LSP path
that a backup path with a bandwidth guarantee is desired. that a backup path with a bandwidth guarantee is desired. The
The bandwidth to be guaranteed is that of the protected bandwidth to be guaranteed is that of the protected LSP, if no
LSP, if no FAST_REROUTE object is included in the PATH message; FAST_REROUTE object is included in the PATH message; if a
if a FAST_REROUTE object is in the PATH message, then the FAST_REROUTE object is in the PATH message, then the bandwidth
bandwidth specified therein is that to be guaranteed. specified therein is to be guaranteed.
Node protection desired: 0x10 Node protection desired: 0x10
This flag indicates to the PLRs along a protected LSP path This flag indicates to the PLRs along a protected LSP path that
that a backup path which bypasses at least the next node of a backup path that bypasses at least the next node of the
the protected LSP is desired. protected LSP is desired.
5.4. RRO IPv4/IPv6 Sub-Object Flags 4.4. RRO IPv4/IPv6 Sub-object Flags
To report whether bandwidth and/or node protection are provided as To report whether bandwidth and/or node protection are provided as
requested, we define two news flags in the RRO IPv4 sub-object. requested, we define two new flags in the RRO IPv4 sub-object.
RRO IPv4 and IPv6 sub-object address:
These two sub-objects currently have the following flags defined: The RRO IPv4 and IPv6 address sub-objects currently have the
following flags defined [RSVP-TE]:
Local protection available: 0x01 Local protection available: 0x01
Indicates that the link downstream of this node is protected Indicates that the link downstream of this node is protected
via a local repair mechanism, which can be either one-to-one via a local repair mechanism, which can be either one-to-one or
or facility backup. facility backup.
Local protection in use: 0x02 Local protection in use: 0x02
Indicates that a local repair mechanism is in use to maintain Indicates that a local repair mechanism is in use to maintain
this tunnel (usually in the face of an outage of the link it this tunnel (usually in the face of an outage of the link it
was previously routed over, or an outage of the neighboring was previously routed over, or an outage of the neighboring
node). node).
Two new flags are defined: Two new flags are defined:
Bandwidth protection: 0x04 Bandwidth protection: 0x04
The PLR will set this when the protected LSP has a backup path The PLR will set this bit when the protected LSP has a backup
which is guaranteed to provide the desired bandwidth specified path that is guaranteed to provide the desired bandwidth that
in the FAST_REROUTE object or the bandwidth of the protected is specified in the FAST_REROUTE object or the bandwidth of the
LSP, if no FAST_REROUTE object was included. The PLR may set protected LSP, if no FAST_REROUTE object was included. The PLR
this whenever the desired bandwidth is guaranteed; the PLR may set this whenever the desired bandwidth is guaranteed; the
MUST set this flag when the desired bandwidth is guaranteed PLR MUST set this flag when the desired bandwidth is guaranteed
and the "bandwidth protection desired" flag was set in the and the "bandwidth protection desired" flag was set in the
SESSION_ATTRIBUTE object. If the requested bandwidth is not SESSION_ATTRIBUTE object. If the requested bandwidth is not
guaranteed, the PLR MUST NOT set this flag. guaranteed, the PLR MUST NOT set this flag.
Node protection: 0x08 Node protection: 0x08
The PLR will set this when the protected LSP has a backup path The PLR will set this bit when the protected LSP has a backup
which provides protection against a failure of the next LSR path that provides protection against a failure of the next LSR
along the protected LSP. The PLR may set this whenever node along the protected LSP. The PLR may set this whenever node
protection is provided by the protected LSP's backup path; the protection is provided by the protected LSP's backup path; the
PLR MUST set this flag when the node protection is provided PLR MUST set this flag when the node protection is provided and
and the "node protection desired" flag was set in the the "node protection desired" flag was set in the
SESSION_ATTRIBUTE object. If node protection is not provided, SESSION_ATTRIBUTE object. If node protection is not provided,
the PLR MUST NOT set this flag. Thus, if a PLR could only the PLR MUST NOT set this flag. Thus, if a PLR could only set
setup a link-protection backup path, the "Local protection up a link-protection backup path, the "Local protection
available" bit will be set but the "Node protection" bit will available" bit will be set, but the "Node protection" bit will
be cleared. be cleared.
6. Head-End Behavior 5. Head-End Behavior
The head-end of an LSP determines whether local protection should The head-end of an LSP determines whether local protection should be
be requested for that LSP and which local protection technique is requested for that LSP and which local protection method is desired
desired for the protected LSP. The head-end also determines what for the protected LSP. The head-end also determines what constraints
constraints should be requested for the backup paths of a protected should be requested for the backup paths of a protected LSP.
LSP.
To indicate that an LSP should be locally protected, the head-end To indicate that an LSP should be locally protected, the head-end LSR
LSR MUST either set the "Local protection desired" flag in the MUST either set the "local protection desired" flag in the
SESSION_ATTRIBUTE object or include a FAST_REROUTE object in the SESSION_ATTRIBUTE object or include a FAST_REROUTE object in the PATH
PATH message or both. It is recommended that the "local protection message, or both. The "local protection desired" flag in the
desired" flag in the SESSION_ATTRIBUTE object always be set. If a SESSION_ATTRIBUTE object SHOULD always be set. If a head-end LSR
head-end LSR signals a FAST_REROUTE object, it MUST be stored for signals a FAST_REROUTE object, it MUST be stored for Path refreshes.
Path refreshes.
The head-end LSR of a protected LSP MUST set the "label recording The head-end LSR of a protected LSP MUST set the "label recording
desired" flag in the SESSION_ATTRIBUTE object. This facilitates desired" flag in the SESSION_ATTRIBUTE object. This facilitates the
the use of the facility backup technique. If node protection is use of the facility backup method. If node protection is desired,
desired, the head-end LSR should set the "node protection desired" the head-end LSR should set the "node protection desired" flag in the
flag in the SESSION_ATTRIBUTE object; otherwise this flag should be SESSION_ATTRIBUTE object; otherwise, this flag should be cleared.
cleared. Similarly, if a guarantee of bandwidth protection is Similarly, if a guarantee of bandwidth protection is desired, then
desired, then the "bandwidth protection desired" flag in the the "bandwidth protection desired" flag in the SESSION_ATTRIBUTE
SESSION_ATTRIBUTE object should be set; otherwise, this flag should object should be set; otherwise, this flag should be cleared. If the
be cleared. head-end LSR determines that control of the backup paths for the
protected LSP is desired, then the LSR should include the
If the head-end LSR determines that control of the backup paths for FAST_REROUTE object. The PLRs will use the attribute filters,
the protected LSP is desired, then the LSR should include the bandwidth, hop-limit, and priorities to determine the backup paths.
FAST_REROUTE object. The attribute filters, bandwidth, hop-limit
and priorities will be used by the PLRs when determining the backup
paths.
If the head-end LSR desires that the protected LSP be protected via If the head-end LSR desires that the one-to-one backup method be used
the one-to-one backup technique, then head-end LSR should include a for the protected LSP, then the head-end LSR should include a
FAST_REROUTE object and set the "one-to-one backup desired" flag. FAST_REROUTE object and set the "one-to-one backup desired" flag. If
If the head-end LSR desires that the protected LSP be protected via the head-end LSR desires that the protected LSP be protected via the
the facility backup technique, then the head-end LSR should include facility backup method, then the head-end LSR should include a
a FAST_REROUTE object and set the "facility backup desired" flag. FAST_REROUTE object and set the "facility backup desired" flag. The
The lack of a FAST_REROUTE object, or having both these flags lack of a FAST_REROUTE object, or having both these flags clear,
clear should be treated by PLRs as a lack of preference. If should be treated by PLRs as a lack of preference. If both flags are
both flags are set a PLR may use either method or both. set, a PLR may use either method or both.
The head-end LSR of a protected LSP MUST support the additional The head-end LSR of a protected LSP MUST support the additional flags
flags defined in Section 5.4 being set or clear in the RRO IPv4 and defined in Section 4.4 being set or clear in the RRO IPv4 and IPv6
IPv6 sub-objects. The head-end LSR of a protected LSP MUST support sub-objects. The head-end LSR of a protected LSP MUST support the
the RRO Label sub-object. RRO Label sub-object.
If the head-end LSR of an LSP determines that local protection is If the head-end LSR of an LSP determines that local protection is
newly desired, this should be signaled via make-before-break. newly desired, this SHOULD be signaled via make-before-break.
7. Point of Local Repair Behavior 6. Point of Local Repair (PLR) Behavior
Every LSR along a protected LSP (except the egress) MUST follow the Every LSR along a protected LSP (except the egress) MUST follow the
PLR behavior described in this document. PLR behavior described in this document.
A PLR SHOULD support the FAST_REROUTE object, the "local protection A PLR SHOULD support the FAST_REROUTE object, the "local protection
desired", "label recording desired", "node protection desired" and desired", "label recording desired", "node protection desired", and
"bandwidth protection desired" flags in the SESSION_ATTRIBUTE "bandwidth protection desired" flags in the SESSION_ATTRIBUTE object,
object, and the "local protection available", "local protection in and the "local protection available", "local protection in use",
use", "bandwidth protection", and "node protection" flags in the "bandwidth protection", and "node protection" flags in the RRO IPv4
RRO IPv4 and IPv6 sub-objects. A PLR MAY support the DETOUR and IPv6 sub-objects. A PLR MAY support the DETOUR object.
object.
A PLR MUST consider an LSP as having asked for local protection if A PLR MUST consider an LSP to have asked for local protection if the
the "local protection desired" flag is set in the SESSION_ATTRIBUTE "local protection desired" flag is set in the SESSION_ATTRIBUTE
object and/or the FAST_REROUTE object is included. If the object and/or the FAST_REROUTE object is included. If the
FAST_REROUTE object is included, a PLR SHOULD consider providing FAST_REROUTE object is included, a PLR SHOULD consider providing
one-to-one protection if the "one-to-one desired" is set and SHOULD one-to-one protection if the "one-to-one desired" is set, and it
consider providing facility backup if the "facility backup desired" SHOULD consider providing facility backup if the "facility backup
flag is set when determining whether to provide local protection desired" flag is set. If the "node protection desired" flag is set,
and which technique to use to provide that local protection. If the PLR SHOULD try to provide node protection; if this is not
the "node protection desired" flag is set, the PLR SHOULD try to feasible, the PLR SHOULD then try to provide link protection. If the
provide node protection; if this is not feasible, the PLR SHOULD "bandwidth protection guaranteed" flag is set, the PLR SHOULD try to
then try to provide link protection. If the "bandwidth protection provide a bandwidth guarantee; if this is not feasible, the PLR
guaranteed" flag is set, the PLR SHOULD try to provide a bandwidth SHOULD then try to provide a backup without a guarantee of the full
guarantee; if this is not feasible, the PLR SHOULD then try to bandwidth.
provide a backup without a guarantee of the full bandwidth.
The following treatment for the RRO IPv4 or IPv6 sub-object's flags The following treatment for the RRO IPv4 or IPv6 sub-object's flags
must be followed if an RRO is included in the protected LSP's RESV must be followed if an RRO is included in the protected LSP's RESV
message. Based on this additional information the head-end may message. Based on this additional information, the head-end may take
take appropriate actions. appropriate actions.
- Until a PLR has a backup path available, the PLR MUST clear the - Until a PLR has a backup path available, the PLR MUST clear the
relevant four flags in the corresponding RRO IPv4 or IPv6 relevant four flags in the corresponding RRO IPv4 or IPv6 sub-
sub-object. object.
- Whenever the PLR has a backup path available, the PLR MUST set - Whenever the PLR has a backup path available, the PLR MUST set the
the "local protection available" flag. If no established "local protection available" flag. If no established one-to-one
one-to-one backup LSP or bypass tunnel exists, or the one-to-one backup LSP or bypass tunnel exists, or if the one-to-one LSP and
LSP and the bypass tunnel is in "DOWN" state, the PLR MUST clear the bypass tunnel is in "DOWN" state, the PLR MUST clear the
the "local protection available" flag in its IPv4 (or IPv6) "local protection available" flag in its IPv4 (or IPv6) address
address subobject of the RRO and SHOULD send the updated RESV. sub-object of the RRO and SHOULD send the updated RESV.
- The PLR MUST clear the "local protection in use" flag unless it - The PLR MUST clear the "local protection in use" flag unless it is
is actively redirecting traffic into the backup path instead of actively redirecting traffic into the backup path instead of along
along the protected LSP. the protected LSP.
- The PLR SHOULD also set the "node protection" flag if the backup - The PLR SHOULD also set the "node protection" flag if the backup
path protects against the failure of the immediate downstream path protects against the failure of the immediate downstream
node and, if not, the PLR SHOULD clear the "node protection" node, and, if the path does not, the PLR SHOULD clear the "node
flag. This MUST be done if the "node protection desired" flag protection" flag. This MUST be done if the "node protection
was set in the SESSION_ATTRIBUTE object. desired" flag was set in the SESSION_ATTRIBUTE object.
- The PLR SHOULD set the "bandwidth protection" if the backup path - The PLR SHOULD set the "bandwidth protection" flag if the backup
offers a bandwidth guarantee and, if not, SHOULD clear the path offers a bandwidth guarantee, and, if the path does not, the
"bandwidth protection" flag. This MUST be done if the "bandwidth PLR SHOULD clear the "bandwidth protection" flag. This MUST be
protection desired" flag was set in the SESSION_ATTRIBUTE done if the "bandwidth protection desired" flag was set in the
object. SESSION_ATTRIBUTE object.
7.1 Signaling a Backup Path 6.1. Signaling a Backup Path
A number of objectives must be met to obtain a satisfactory signaling A number of objectives must be met to obtain a satisfactory signaling
solution. These are summarized as follows: solution. These are summarized as follows:
1. Unambiguously and uniquely identify backup paths 1. Unambiguously and uniquely identifying backup paths.
2. Unambiguously associate protected LSPs with their backup paths
3. Work with both global and non-global label spaces 2. Unambiguously associating protected LSPs with their backup
4. Allow for merging of backup paths paths.
5. Maintain RSVP state during and after fail-over.
3. Working with both global and non-global label spaces.
4. Allowing merging of backup paths.
5. Maintaining RSVP state during and after fail-over.
LSP tunnels are identified by a combination of the SESSION and LSP tunnels are identified by a combination of the SESSION and
SENDER_TEMPLATE objects. The relevant fields are as follows. SENDER_TEMPLATE objects [RSVP-TE]. The relevant fields are as
follows.
IPv4 (or IPv6) tunnel end point address IPv4 (or IPv6) tunnel end point address
IPv4 (or IPv6) address of the egress node for the tunnel. IPv4 (or IPv6) address of the egress node for the tunnel.
Tunnel ID Tunnel ID
A 16-bit identifier used in the SESSION that remains constant A 16-bit identifier used in the SESSION that remains constant
over the life of the tunnel. over the life of the tunnel.
Extended Tunnel ID Extended Tunnel ID
A 32-bit (IPv4) or 128-bit (IPv6) identifier used in the SESSION A 32-bit (IPv4) or 128-bit (IPv6) identifier used in the
that remains constant over the life of the tunnel. Normally set SESSION that remains constant over the life of the tunnel.
to all zeros. Ingress nodes that wish to narrow the scope of a Normally it is set to all zero. Ingress nodes that wish to
SESSION to the ingress-egress pair may place their IP address narrow the scope of a SESSION to the ingress-egress pair may
here as a globally unique identifier. place their IP address here as a globally unique identifier.
IPv4 (or IPv6) tunnel sender address IPv4 (or IPv6) tunnel sender address
IPv4 (or IPv6) address for a sender node IPv4 (or IPv6) address for a sender node.
LSP ID LSP ID
A 16-bit identifier used in the SENDER_TEMPLATE and the A 16-bit identifier used in the SENDER_TEMPLATE and the
FILTER_SPEC that can be changed to allow a sender to share FILTER_SPEC, which can be changed to allow a sender to share
resources with itself. resources with itself.
The first three of these are in the SESSION object and are the basic The first three of these are in the SESSION object and are the basic
identification of the tunnel. Setting the "Extended Tunnel ID" to identification for the tunnel. Setting the "Extended Tunnel ID" to
an IP address of the head-end LSR allows the scope of the SESSION an IP address of the head-end LSR allows the scope of the SESSION to
to be narrowed to only LSPs sent by that LSR. A backup LSP is be narrowed to only LSPs sent by that LSR. A backup LSP is
considered to be part of the same session as its protected LSP; considered part of the same session as its protected LSP; therefore
therefore these three cannot be varied. these three cannot be varied.
The last two are in the SENDER_TEMPLATE. Multiple LSPs in the same The last two are in the SENDER_TEMPLATE. Multiple LSPs in the same
SESSION may be protected and take different routes; this is common SESSION may be protected and may take different routes; this is
when rerouting a tunnel using make-before-break. It is necessary common when a tunnel is rerouted using make-before-break. A backup
that a backup path be clearly identified with its protected LSP, so path must be clearly identified with its protected LSP to allow
that correct merging and state treatment can be done. Therefore, a correct merging and state treatment. Therefore, a backup path must
backup path must inherit its LSP ID from the associated protected inherit its LSP ID from the associated protected LSP. Thus, the only
LSP. Thus, the only field in the SESSION and SENDER_TEMPLATE field in the SESSION and SENDER_TEMPLATE objects that could be varied
objects which could be varied between a backup path and a protected between a backup path and a protected LSP is the "IPv4 (or IPv6)
LSP is the "IPv4 (or IPv6) tunnel sender address" in the tunnel sender address" in the SENDER_TEMPLATE.
SENDER_TEMPLATE.
There are two different methods to uniquely identify a backup There are two different methods to uniquely identify a backup path,
path. These are described below. described below.
7.1.1. Backup Path Identification: Sender-Template-Specific 6.1.1. Backup Path Identification: Sender Template-Specific
In this approach, the SESSION object and the LSP_ID are copied from In this approach, the SESSION object and the LSP_ID are copied from
the protected LSP. The "IPv4 tunnel sender address" is set to an the protected LSP. The "IPv4 tunnel sender address" is set to an
address of the PLR. If the head-end of a tunnel is also acting as address of the PLR. If the head-end of a tunnel is also acting as
the PLR, it MUST choose an IP address different from the one used the PLR, it MUST choose an IP address different from the one used in
in the SENDER_TEMPLATE of the original LSP tunnel. the SENDER_TEMPLATE of the original LSP tunnel.
When using the sender-template-specific approach, the protected When the sender template-specific approach is used, the protected
LSPs and the backup paths SHOULD use the Shared Explicit (SE) LSPs and the backup paths SHOULD use the Shared Explicit (SE) style.
style. This allows bandwidth sharing between multiple backup This allows bandwidth sharing between multiple backup paths. The
paths. The backup paths and the protected LSP MAY be merged by the backup paths and the protected LSP MAY be merged by the Detour Merge
Detour Merge Points, when the ERO from the MP to the egress is the Points, when the ERO from the MP to the egress is the same on each
same on each LSP to be merged, as specified in [RSVP-TE]. LSP to be merged, as specified in [RSVP-TE].
7.1.2. Backup Path Identification: Path-Specific 6.1.2. Backup Path Identification: Path-Specific
In this approach, rather than varying the SESSION or In this approach, rather than vary the SESSION or SENDER_TEMPLATE
SENDER_TEMPLATE objects, a new object, the DETOUR object, is used objects, an implementation uses a new object, the DETOUR object, to
to distinguish between PATH messages for a backup path and the distinguish between PATH messages for a backup path and the protected
protected LSP. LSP.
Thus, the backup paths use the same SESSION and SENDER_TEMPLATE Thus, the backup paths use the same SESSION and SENDER_TEMPLATE
objects as the ones used in the protected LSP. The presence of objects as the ones used in the protected LSP. The presence of a
DETOUR object in Path messages signifies a backup path; the DETOUR object in Path messages signifies a backup path; the presence
presence of FAST_REROUTE object and/or the "local protection of a FAST_REROUTE object and/or the "local protection requested" flag
requested" flag in the SESSION_ATTRIBUTE object indicates a in the SESSION_ATTRIBUTE object indicates a protected LSP.
protected LSP.
In the path-message-specific approach, when an LSR receives In the path message-specific approach, an LSR merges Path messages
multiple Path messages which have the same SESSION and that are received with the same SESSION and SENDER_TEMPLATE objects
SENDER_TEMPLATE objects and also have the same next-hop, that LSR and that also have the same next-hop object. Without this behavior,
MUST merge the Path messages. Without this behavior, the multiple it would be impossible to associate the multiple RESV messages with
RESV messages received back would not be distinguishable as to the backup paths. However, this merging behavior reduces the total
which backup path each belongs to. This merging behavior does number of RSVP states inside the network at the expense of merging
reduce the total number of RSVP states inside the network at the LSPs with different EROs.
expense of merging LSPs with different EROs.
7.2 Procedures for Backup Path Computation 6.2. Procedures for Backup Path Computation
Before a PLR can create a detour or a bypass tunnel, the desired Before a PLR can create a detour or a bypass tunnel, the desired
explicit route must be determined. This can be done using a CSPF. explicit route must be determined. This can be done using a CSPF
(Constraint-based Shortest Path First) computation. Before this CSPF
Before CSPF computation, the following information should be computation, the following information must be collected at a PLR:
collected at a PLR:
- The list of downstream nodes that the protected LSP passes - The list of downstream nodes that the protected LSP passes
through. This information is readily available from the through. This information is readily available from the
RECORD_ROUTE objects during LSP setup. This information is also RECORD_ROUTE objects during LSP setup. This information is also
available from the ERO. However, if the ERO contains loose available from the ERO. However, if the ERO contains loose
sub-objects, the ERO may not provide adequate information. sub-objects, the ERO may not provide adequate information.
- The downstream links/nodes that we want to protect against. Once - The downstream links/nodes that we want to protect against.
again, this information is learned from the RECORD_ROUTE Once again, this information is learned from the RECORD_ROUTE
objects. Whether node protection is desired is determined by objects. Whether node protection is desired is determined by
the "node protection" flag in the SESSION_ATTRIBUTE object and the "node protection" flag in the SESSION_ATTRIBUTE object and
local policy. local policy.
- The upstream uni-directional links that the protected LSP - The upstream uni-directional links that the protected LSP passes
passes through. This information is learned from the through. This information is learned from the RECORD_ROUTE
RECORD_ROUTE objects; it is only needed for setting up objects; it is only needed for setting up one-to-one protection.
one-to-one protection. In the path-specific method, it is In the path-specific method, it is necessary to avoid the detour
necessary to avoid the detour and the protected LSP sharing and the protected LSP sharing a common next-hop upstream of the
a common next-hop upstream of the failure. In the failure. In the sender template-specific mode, this same
sender-template-specific mode, this same restriction is restriction is necessary to avoid sharing bandwidth between the
necessary to avoid sharing bandwidth between the detour and detour and its protected LSP, where that bandwidth has been
its protected LSP, where that bandwidth has only been reserved reserved only once.
once.
- The link attribute filters to be applied. These are derived - The link attribute filters to be applied. These are derived
from the FAST_REROUTE object, if included in the PATH message, from the FAST_REROUTE object, if it is included in the PATH
and the SESSION_ATTRIBUTE object otherwise. message, or from the SESSION_ATTRIBUTE object otherwise.
- The bandwidth to be used is found in the FAST_REROUTE object, - The bandwidth to be used is found in the FAST_REROUTE object, if
if included in the PATH message, and in the SESSION_ATTRIBUTE it is included in the PATH message, or in the SESSION_ATTRIBUTE
object otherwise. Local policy may modify the bandwidth to be object otherwise. Local policy may modify the bandwidth to be
reserved. reserved.
- The hop-limit, if a FAST_REROUTE object was included in the - The hop-limit, if a FAST_REROUTE object was included in the PATH
PATH message. message.
When applying a CSPF algorithm to compute the backup route, the When a CSPF algorithm is used to compute the backup route, the
following constraints should be satisfied: following constraints must be satisfied:
- For detour LSPs, the destination MUST be the tail-end of the - For detour LSPs, the destination MUST be the tail-end of the
protected LSP; for bypass tunnels (Section 7), the destination protected LSP. For bypass tunnels (Section 7), the destination
MUST be the address of the MP. MUST be the address of the MP.
- When setting up one-to-one protection using the path-specific - When one-to-one protection is set up by using the path-specific
method, a detour MUST not traverse the upstream links of the method, a detour MUST not traverse the upstream links of the
protected LSP in the same direction. This prevents the protected LSP in the same direction. This prevents the
possibility of early merging of the detour into the protected possibility of early merging of the detour into the protected
LSP. When setting up one-to-one protection using the LSP. When one-to-one protection is set up using the sender-
sender-template-specific method, a detour should not traverse template-specific method, a detour should not traverse the
the upstream links of the protected LSP in the same direction; upstream links of the protected LSP in the same direction. This
this prevents sharing the bandwidth between a protected LSP prevents sharing the bandwidth between a protected LSP and its
and its backup upstream of the failure where the bandwidth backup upstream of the failure where the bandwidth would be used
would be used twice in the event of a failure. twice in the event of a failure.
- The backup LSP cannot traverse the downstream node and/or link - The backup LSP cannot traverse the downstream node and/or link
whose failure is being protected against. Note that if the whose failure is being protected against. Note that if the PLR
PLR is the penultimate hop, node protection is not possible is the penultimate hop, node protection is not possible, and
and only the downstream link can be avoided. The backup path only the downstream link can be avoided. The backup path may be
may be computed to be SRLG disjoint from the downstream node computed to be SRLG disjoint from the downstream node and/or
and/or link being avoided. link being avoided.
- The backup path must satisfy the resource requirements of the - The backup path must satisfy the resource requirements of the
protected LSP. This includes the link attribute filters, protected LSP. This includes the link attribute filters,
bandwidth, and hop limits determined from the FAST_REROUTE bandwidth, and hop limits determined from the FAST_REROUTE
object and SESSION_ATTRIBUTE object. object and the SESSION_ATTRIBUTE object.
If such computation succeeds, the PLR should attempt to establish a If such computation succeeds, the PLR should attempt to establish a
backup path. The PLR may schedule a re-computation at a later time backup path. The PLR may schedule a re-computation at a later time
to discover better paths that may have emerged. If for any reason, to discover better paths that might have emerged. If for any reason,
the PLR is unable to bring up a backup path, it must schedule a the PLR is unable to bring up a backup path, it must schedule a retry
retry at a later time. at a later time.
7.3 Signaling Backups for One-To-One Protection 6.3. Signaling Backups for One-to-One Protection
Once a PLR has decided to locally protect an LSP with one-to-one Once a PLR has decided to protect an LSP locally with one-to-one
backup, and has identified the desired path, it takes the following backup and has identified the desired path, it signals for the
steps to signal the detour. detour.
The following describes the transformation to be performed upon the The following describes the transformation to be performed upon the
protected LSP's PATH message to create the detour LSP's PATH protected LSP's PATH message to create the detour LSP's PATH message.
message.
- If the sender-template specific method is to be used, then the - If the sender template-specific method is to be used, then the
PLR MUST change the "IPv4 (or IPv6) tunnel sender address" of the PLR MUST change the "IPv4 (or IPv6) tunnel sender address" of
SENDER_TEMPLATE to an address belonging to the PLR that is not the SENDER_TEMPLATE to an address belonging to the PLR that is
the same as was used for the protected LSP. Additionally, the not the same as that used for the protected LSP. Additionally,
DETOUR object MAY be added to the PATH message. the DETOUR object MAY be added to the PATH message.
- If the path-specific method is to be used, then the PLR MUST add - If the path-specific method is to be used, then the PLR MUST add
a DETOUR object to the PATH message. a DETOUR object to the PATH message.
- The SESSION_ATTRIBUTE flags "Local protection desired", - The SESSION_ATTRIBUTE flags "Local protection desired",
"Bandwidth protection desired" and "Node protection desired" MUST "Bandwidth protection desired", and "Node protection desired"
be cleared. The "Label recording desired" flag MAY be modified. MUST be cleared. The "Label recording desired" flag MAY be
If the Path Message contained a FAST_REROUTE object, and the ERO modified. If the Path Message contained a FAST_REROUTE object
is not completely strict, the Include-any, Exclude-any, and and the ERO is not completely strict, the Include-any, Exclude-
Include-all fields of the FAST_REROUTE object SHOULD be copied to any, and Include-all fields of the FAST_REROUTE object SHOULD be
the corresponding fields of the SESSION_ATTRIBUTE object. copied to the corresponding fields of the SESSION_ATTRIBUTE
object.
- If the protected LSP's Path message contained a FAST_REROUTE - If the protected LSP's Path message contained a FAST_REROUTE
object, this MUST be removed from the detour LSP's PATH message. object, this object MUST be removed from the detour LSP's PATH
message.
- The PLR MUST generate an EXPLICIT_ROUTE object toward the egress. - The PLR MUST generate an EXPLICIT_ROUTE object toward the
First, the PLR must remove all sub-objects preceding the first egress. First, the PLR must remove all sub-objects preceding
address belonging to the Merge Point. Then the PLR SHOULD add the first address belonging to the Merge Point. Then the PLR
sub-objects corresponding to the desired backup path between the SHOULD add sub-objects corresponding to the desired backup path
PLR and the MP. between the PLR and the MP.
- The SENDER_TSPEC object SHOULD contain the bandwidth information - The SENDER_TSPEC object SHOULD contain the bandwidth information
from the received FAST_REROUTE object, if included in the from the received FAST_REROUTE object, if included in the
protected LSP's PATH message. protected LSP's PATH message.
- The RSVP_HOP object containing one of the PLR's IP address. - The RSVP_HOP object containing one of the PLR's IP address.
- The detour LSPs MUST use the same reservation style as the - The detour LSPs MUST use the same reservation style as the
protected LSP. This must be correctly reflected in the protected LSP. This must be correctly reflected in the
SESSION_ATTRIBUTE object. SESSION_ATTRIBUTE object.
Detour LSPs are regular LSPs in operation. Once a detour path is Detour LSPs operate like regular LSPs. Once a detour path is
successfully computed and the detour LSP is established, the PLR successfully computed and the detour LSP is established, the PLR
need not compute detour routes again, unless (1) the contents of need not compute detour routes again, unless (1) the contents of
FAST_REROUTE have changed, or (2) the downstream interface and/or FAST_REROUTE have changed or (2) the downstream interface and/or
the nexthop router for a protected LSP have changed. The PLR may the nexthop router for a protected LSP has changed. The PLR may
recompute detour routes at any time. recompute detour routes at any time.
7.3.1 Make-Before-Break with Detour LSPs 6.3.1. Make-before-Break with Detour LSPs
If the sender-template specific method is used, it is possible to If the sender template-specific method is used, it is possible to do
do make-before-break with detour LSPs. This is done by using two make-before-break with detour LSPs. This is done using two different
different IP addresses belonging to the PLR (which were not used in IP addresses belonging to the PLR (which were not used in the
the SENDER_TEMPLATE of the protected LSP). If the current detour SENDER_TEMPLATE of the protected LSP). If the current detour LSP
LSP uses the first IP address in its SENDER_TEMPLATE, then the new uses the first IP address in its SENDER_TEMPLATE, then the new detour
detour LSP should be signaled using the second IP address in its LSP should be signaled by using the second IP address in its
SENDER_TEMPLATE. Once the new detour LSP has been created, the SENDER_TEMPLATE. Once the new detour LSP has been created, the
current detour LSP can be torn down. By alternating the use of current detour LSP can be torn down. By alternating the use of these
these IP addresses, the current and new detour LSPs will have IP addresses, the current and new detour LSPs will have different
different SENDER_TEMPLATES and, thus, different state in the SENDER_TEMPLATES and, thus, different state in the downstream LSRs.
downstream LSRs.
This make-before-break mechanism, changing the PLR IP address in This make-before-break mechanism, which changes the PLR IP address in
the DETOUR object instead, is not feasible with the path-specific the DETOUR object instead, is not feasible with the path-specific
method because the PATH messages for new and current detour LSPs method, as the PATH messages for new and current detour LSPs may be
may be merged if they share a common next-hop. merged if they share a common next-hop.
7.3.2 Message Handling 6.3.2. Message Handling
LSRs must process the detour LSPs independent of the protected LSPs LSRs must process the detour LSPs independently of the protected LSPs
to avoid triggering the LSP loop detection procedure described in to avoid triggering the LSP loop detection procedure described in
[RSVP-TE]. [RSVP-TE].
The PLR MUST not mix the messages for the protected and the detour The PLR MUST not mix the messages for the protected and the detour
LSPs. When a PLR receives Resv, ResvTear and PathErr messages from LSPs. When a PLR receives Resv, ResvTear, and PathErr messages from
the downstream detour destination, the messages MUST not be forwarded the downstream detour destination, the messages MUST not be forwarded
upstream. Similarly, when a PLR receives ResvErr and ResvConf upstream. Similarly, when a PLR receives ResvErr and ResvConf
messages from a protected LSP, it MUST not propagate them onto the messages from a protected LSP, it MUST not propagate them onto the
associated detour LSP. associated detour LSP.
A session tear-down request is normally originated by the sender via A session tear-down request is normally originated by the sender via
PathTear messages. When a PLR node receives a PathTear message from PathTear messages. When a PLR node receives a PathTear message from
upstream, it MUST delete both the protected and the detour LSPs. The upstream, it MUST delete both the protected and the detour LSPs. The
PathTear messages MUST propagate to both protected and detour LSPs. PathTear messages MUST propagate to both protected and detour LSPs.
During error conditions, the LSRs may send ResvTear messages to fix During error conditions, the LSRs may send ResvTear messages to fix
problems on the failing path. When a PLR node receives the ResvTear problems on the failing path. When a PLR node receives the ResvTear
messages from downstream for a protected LSP, as long as a detour is messages from downstream for a protected LSP, as long as a detour is
up, the ResvTear messages MUST not be sent further upstream. up, the ResvTear messages MUST not be sent further upstream.
PathErrs should be treated similiarly. PathErrs should be treated similarly.
7.3.3 Local Reroute of Traffic onto Detour LSP 6.3.3. Local Reroute of Traffic onto Detour LSP
When the PLR detects a failure on the protected LSP, the PLR MUST When the PLR detects a failure on the protected LSP, the PLR MUST
rapidly switch packets to the protected LSP's backup LSP instead of rapidly switch packets to the protected LSP's backup LSP instead of
the protected LSP's normal out-segment. The goal of this technique to the protected LSP's normal out-segment. The goal of this method
is to effect the redirection within 10s of milliseconds. is to effect the redirection within 10s of milliseconds.
L32 L33 L34 L35 L32 L33 L34 L35
R1-------R2-------R3-------R4-------R5 R1-------R2-------R3-------R4-------R5
| | | |
L46 | L47 | L44 L46 | | L44
R6---------------R7 | L47 |
R6----------------R7
Protected LSP: [R1->R2->R3->R4->R5] Protected LSP: [R1->R2->R3->R4->R5]
Detour LSP: [R2->R6->R7->R4] Detour LSP: [R2->R6->R7->R4]
Example 3: Redirect to Detour Example 3. Redirect to Detour
In Example 3 above, if the link [R2->R3] fails, then R2 would do In Example 3, if the link [R2->R3] fails, R2 would do the following.
the following. Any traffic received on link [R1->R2] with label Any traffic received on link [R1->R2] with label L32 would be sent on
L32 would be sent out link [R2->R6] with label L46 (along the link [R2->R6] with label L46 (along the detour LSP) instead of on
detour LSP) instead of out link [R3->R4] with lable L34 (along the link [R3->R4] with label L34 (along the protected LSP). The merge
protected LSP). The Merge Point, R4, would recognize that packets point R4 would recognize that packets received on link [R7->R4] with
received on link [R7->R4] with label L44 should be sent out link label L44 should be sent on link [R4->R5] with label L35 and that
[R4->R5] with label L35, and thus merged with the protected LSP. they should be merged with the protected LSP.
7.4 Signaling for Facility Protection 6.4. Signaling for Facility Protection
A PLR may use one or more bypass tunnels to protect against the A PLR may use one or more bypass tunnels to protect against the
failure of a link and/or a node. These bypass tunnels may be failure of a link and/or a node. These bypass tunnels may be set up
setup in advance or may be dynamically created as new protected in advance or may be dynamically created as new protected LSPs are
LSPs are signaled. signaled.
7.4.1. Discovering Downstream Labels 6.4.1. Discovering Downstream Labels
To support facility backup, it is necessary for the PLR to To support facility backup, the PLR must determine a label that will
determine a label which will indicate to the MP that packets indicate to the MP that packets received with that label should be
received with that label should be switched along the protected switched along the protected LSP. This can be done without
LSP. This can be done without explicitly signaling the backup path explicitly signaling the backup path if the MP uses a label space
if the MP uses a label space global to that LSR. global to that LSR.
As described in Section 6, the head-end LSR MUST set the "label As described in Section 6, the head-end LSR MUST set the "label
recording requested" flag in the SESSION_ATTRIBUTE object for LSPs recording requested" flag in the SESSION_ATTRIBUTE object for LSPs
requesting local protection. This will cause (as specified in requesting local protection. This will cause (as specified in
[RSVP- TE]) all LSRs to record their INBOUND labels and to note via [RSVP-TE]) all LSRs to record their INBOUND labels and to note via a
a flag if the label is global to the LSR. Thus, when a protected flag whether the label is global to the LSR. Thus, when a protected
LSP is first signaled through a PLR, the PLR can examine the RRO in LSP is first signaled through a PLR, the PLR can examine the RRO in
the Resv message and learn about the incoming labels that are used the Resv message and learn about the incoming labels that are used by
by all downstream nodes for this LSP. all downstream nodes for this LSP
When MPs use per-interface-label spaces, the PLR must send Path When MPs use per-interface label spaces, the PLR must send Path
messages (for each protected LSP using a bypass tunnel) via that messages (for each protected LSP using a bypass tunnel) via that
bypass tunnel prior to the failure in order to discover the bypass tunnel prior to the failure in order to discover the
appropriate MP label. The signaling procedures for this are in appropriate MP label. The signaling procedures for this are in
Section 7.4.3 below. Section 6.4.3 below.
7.4.2. Procedures for the PLR before Local Repair
A PLR which determines to use facility-backup to protect a given 6.4.2. Procedures for the PLR before Local Repair
LSP should select a bypass tunnel to use taking into account
whether node protection is to be provided, what bandwidth was
requested and whether a bandwidth guarantee is desired, and what
link attribute filters were specified in the FAST_REROUTE object.
The selection of a bypass tunnel for a protected LSP is performed A PLR that determines to use facility-backup to protect a given LSP
by the PLR when the LSP is first setup. should select a bypass tunnel to use, taking into account whether
node protection is to be provided, what bandwidth was requested,
whether a bandwidth guarantee is desired, and what link attribute
filters were specified in the FAST_REROUTE object. The selection of
a bypass tunnel for a protected LSP is performed by the PLR when the
LSP is first set up.
7.4.3. Procedures for the PLR during Local Repair 6.4.3. Procedures for the PLR during Local Repair
When the PLR detects a link or/and node failure condition, it needs When the PLR detects a link or/and node failure condition, it has to
to reroute the data traffic onto the bypass tunnel and to start reroute the data traffic onto the bypass tunnel and to start sending
sending the control traffic for the protected LSP onto the bypass the control traffic for the protected LSP onto the bypass tunnel.
tunnel.
The backup tunnel is identified using the sender-template-specific The backup tunnel is identified by using the sender template-specific
method. The procedures to follow are similar to those described in method. The procedures to follow are similar to those described in
Section 7.3. Section 6.3.
- The SESSION is unchanged. - The SESSION is unchanged.
- The SESSION_ATTRIBUTE is unchanged except as follows: - The SESSION_ATTRIBUTE is unchanged except as follows: The
The "Local protection desired", "Bandwidth protection desired", "Local protection desired", "Bandwidth protection desired", and
and "Node protection desired" flags SHOULD be cleared. "Node protection desired" flags SHOULD be cleared. The "Label
The "Label recording desired" MAY be modified. recording desired" MAY be modified.
- The IPv4 (or IPv6) tunnel sender address of the SENDER_TEMPLATE - The IPv4 (or IPv6) tunnel sender address of the SENDER_TEMPLATE
is set to an address belonging to the PLR. is set to an address belonging to the PLR.
- The RSVP_HOP object MUST contain an IP source address - The RSVP_HOP object MUST contain an IP source address belonging
belonging to the PLR. Consequently, the MP will send messages to the PLR. Consequently, the MP will send messages back to the
back to the PLR using as a destination that IP address. PLR with that IP address as the destination.
- The PLR MUST generate an EXPLICIT_ROUTE object toward the - The PLR MUST generate an EXPLICIT_ROUTE object toward the
egress. Detailed ERO processing is described below. egress. Detailed ERO processing is described below.
- The RRO object may need to be updated, as described in Section - The RRO object may have to be updated as described in Section
7.5. 6.5.
The PLR sends Path, PathTear, and ResvConf messages via the backup The PLR sends Path, PathTear, and ResvConf messages via the backup
tunnel. The MP sends Resv, ResvTear, and PathErr messages by tunnel. The MP sends Resv, ResvTear, and PathErr messages by sending
directly addressing them to the address in the RSVP_HOP object them directly to the address in the RSVP_HOP object, as specified in
contents as specified in [RSVP]. [RSVP].
If it is necessary to signal the backup prior to failure to If it is necessary to signal the backup prior to failure to determine
determine the MP label to use, then the same Path message is sent. the MP label to use, then the same Path message is sent. In this
In this case, the PLR SHOULD continue to send Path messages for the case, the PLR SHOULD continue to send Path messages for the protected
protected LSP along the normal route. PathTear messages should be LSP along the normal route. PathTear messages should be duplicated,
duplicated, with one sent along the normal route and one sent thru with one sent along the normal route and one sent through the bypass
the bypass tunnel. The MP should duplicate the Resv and ResvTear tunnel. The MP should duplicate the Resv and ResvTear messages and
messages and sent them to both the PLR and the LSR indicated by the send them to both the PLR and the LSR indicated by the protected
protected LSP's RSVP_HOP object. LSP's RSVP_HOP object.
7.4.4. Processing backup tunnel's ERO 6.4.4. Processing Backup Tunnel's ERO
Procedures for ERO processing are described in [RSVP-TE]. This Procedures for ERO processing are described in [RSVP-TE]. This
section describes additional ERO update procedures for Path messages section describes additional ERO update procedures for Path messages
which are sent over bypass tunnels. If normal ERO processing rules that are sent over bypass tunnels. If normal ERO processing rules
were followed, the Merge Point would examine the first sub-object and were followed, the Merge Point would examine the first sub-object and
likely reject it (Bad initial sub-object). This is because the likely reject it (Bad initial sub-object). This is because the
unmodified ERO might contain the IP address of a bypassed node (in unmodified ERO might contain the IP address of a bypassed node (in
the case of a NNHOP Backup Tunnel), or of an interface which is the case of a NNHOP Bypass Tunnel) or of an interface that is
currently down (in the case of a NHOP Backup Tunnel). For this currently down (in the case of a NHOP Backup Tunnel). For this
reason, the PLR invoke the following ERO procedures before sending a reason, the PLR invokes the following ERO procedures before sending a
Path message via a bypass tunnel. Path message via a bypass tunnel.
Sub-objects belonging to abstract nodes which precede the Merge Point Sub-objects belonging to abstract nodes that precede the Merge
are removed, along with the first sub-object belonging to the MP. A Point are removed, along with the first sub-object belonging to
sub-object identifying the Backup Tunnel destination is then added. the MP. A sub-object identifying the Backup Tunnel destination is
then added.
More specifically, the PLR MUST: More specifically, the PLR MUST:
- remove all the sub-objects proceeding the first address belonging - remove all the sub-objects proceeding the first address
to the MP. belonging to the MP, and
- replace this first MP address with an IP address of the MP. - replace this first MP address with an IP address of the MP.
(Note that this could be same address that was just removed.) (Note that this could be same address that was just removed.)
7.5. PLR Procedures During Local Repair 6.5. PLR Procedures during Local Repair
In addition to the technique specific signaling and packet In addition to the method-specific signaling and packet treatment,
treatment, there is common signaling which should be followed. there is common signaling that should be followed.
During fast reroute, for each protected LSP containing an RRO During fast reroute, for each protected LSP containing an RRO object,
object, the PLR obtains the RRO from the protected LSP's stored the PLR obtains the RRO from the protected LSP's stored RESV. The
RESV. The PLR MUST update the IPv4 or IPv6 sub-object it inserted PLR MUST update the IPv4 or IPv6 sub-object it inserted into the RRO
into the RRO by setting the "Local protection in use" and "Local by setting the "Local protection in use" and "Local Protection
Protection Available" flags. Available" flags.
7.5.1. Notification of local repair 6.5.1. Notification of Local Repair
In many situations, the route used during a Local Repair will be less In many situations, the route used during local repair will be less
than optimal. The purpose of Local Repair is to keep high priority than optimal. The purpose of local repair is to keep high priority
and loss sensitive traffic flowing while a more optimal re-routing of and loss-sensitive traffic flowing while a more optimal re-routing of
the tunnel can be effected by the head-end of the tunnel. Thus the the tunnel can be effected by the head-end of the tunnel. Thus, the
head-end needs to know of the failure so it may re-signal an LSP head-end has to know of the failure so that it may re-signal an
which is optimal. optimal LSP.
To provide this notification, the PLR SHOULD send a Path Error To provide this notification, the PLR SHOULD send a Path Error
message with error code of "Notify" (Error code =25) and an error message with error code of "Notify" (Error code =25) and an error
value field of ss00 cccc cccc cccc where ss=00 and the sub-code = 3 value field of ss00 cccc cccc cccc, where ss=00 and the sub-code = 3
("Tunnel locally repaired") (see [RSVP-TE]) ("Tunnel locally repaired") (see [RSVP-TE]).
Additionally a head-end may also detect that an LSP needs to be moved Additionally, a head-end may detect that an LSP has to be moved to a
to a more optimal path by noticing failures reported via the IGP. more optimal path by noticing failures reported via the IGP. Note
Note that in the case of inter-area TE LSP (TE LSP spanning areas), that in the case of inter-area TE LSP (TE LSP spanning areas), the
the head-end LSR will need to rely exclusively on Path Error messages head-end LSR will have to rely exclusively on Path Error messages to
to be informed of failures in another area. be informed of failures in another area.
7.5.2 Revertive Behavior 6.5.2. Revertive Behavior
Upon a failure event, a protected TE LSP is locally repaired by the Upon a failure event, a protected TE LSP is locally repaired by the
PLR. There are two basic strategies for restoring the TE LSP to a PLR. There are two basic strategies for restoring the TE LSP to a
full working path. full working path.
- Global revertive mode: The head-end LSR of each tunnel is - Global revertive mode: The head-end LSR of each tunnel is
responsible for reoptimizing the TE LSPs that used the failed responsible for reoptimizing the TE LSPs that used the failed
resource. There are several potential reoptimization triggers - resource. There are several potential reoptimization triggers:
RSVP error messages, inspection of OSPF LSAs or ISIS LSPs, and RSVP error messages, inspection of OSPF LSAs or ISIS LSPs, and
timers. Note that this re-optimization process may proceed as timers. Note that this re-optimization process may proceed as
soon as the failure is detected. It is not tied to the soon as the failure is detected. It is not tied to the
restoration of the failed resource. restoration of the failed resource.
- Local revertive mode: Upon detecting that the resource is - Local revertive mode: Upon detecting that the resource is
restored, the PLR re-signals each of TE LSPs that used to be restored, the PLR re-signals each of the TE LSPs that used to be
routed over the restored resource. Every TE LSP successfully routed over the restored resource. Every TE LSP successfully
resignaled along the restored resource is switched back. re-signaled along the restored resource is switched back.
There are several circumstances where a local revertive mode might There are several circumstances in which a local revertive mode might
not be desirable. In the case of resource flapping (not an uncommon not be desirable. In the case of resource flapping (not an uncommon
failure type), this could generate multiple traffic disruptions. failure type), this could generate multiple traffic disruptions.
Therefore, in the local revertive mode, the PLR should implement a Therefore, in the local revertive mode, the PLR should implement a
means to dampen the re-signaling process in order to limit means to dampen the re-signaling process in order to limit potential
potential disruptions due to flapping. disruptions due to flapping.
In the local revertive mode, any TE LSP will be switched back, In the local revertive mode, any TE LSP will be switched back,
without any distinction, as opposed to the global revertive mode without any distinction, whereas in the global revertive mode, the
where the decision to reuse the restored resource is taken by the decision to reuse the restored resource is made by the head-end LSR
head-end LSR based on the TE LSP attributes. When the head-end based on the TE LSP attributes. When the head-end learns of the
learns of the failure, it may reoptimize the protected LSP tunnel failure, it may reoptimize the protected LSP tunnel along a different
along a different and more optimal path, because it has a more and more optimal path, as it has a more complete view of the
complete view of the resources and TE LSP constraints; this means resources and TE LSP constraints. This means that the old LSP that
that the old LSP which has been reverted to may not be optimal any has been reverted to may no longer be optimal. Note that in the case
longer. Note that in the case of inter-area LSP, where the TE LSP of inter-area LSP, where the TE LSP path computation might be done on
path computation might be done on some Path Computation Server, the some Path Computation Element, the reoptimization process can
reoptimization process can still be triggered on the Head-End still be triggered on the Head-End LSP. The local revertive mode
LSP. The local revertive mode is optional. is optional.
However, there are circumstances where the Head-end does not have However, there are circumstances in which the head-end does not have
the ability to reroute the TE LSP (e.g if the protected LSP is the ability to reroute the TE LSP (e.g., if the protected LSP is
pinned down, as may be desirable if the paths are determined using pinned down, as may be desirable if the paths are determined by using
an off-line optimization tool) or if Head-end does not have the an off-line optimization tool), or if the head-end does not have the
complete TE topology information (depending on the path computation complete TE topology information (depending on the path computation
scenario). In those cases, the local revertive might be a scenario). In those cases, the local revertive mode might be an
interesting option. interesting option.
It is recommended that one always use the globally revertive mode. The globally revertive mode SHOULD always be used. Note that a link
Note that a link or node "failure" may be due to the facility being or node "failure" may be due to the facility being permanently taken
permanently taken out of service. Local revertive mode is out of service. Local revertive mode is optional. When used in
optional. When used in combination, the global mode may rely combination, the global mode may rely solely on timers to do the
solely on timers to do the reoptimization. When local revertive reoptimization. When local revertive mode is not used, head-end LSRs
mode is not used, head-end LSRs SHOULD react to RSVP error messages SHOULD react to RSVP error messages and/or IGP indications in order
and/or IGP indications in order to make a timely response. to make a timely response.
Interoperability: If a PLR is configured with the local revertive Interoperability: If a PLR is configured with the local revertive
mode but the MP is not, any attempt from the PLR to resignal the TE mode but the MP is not, any attempt from the PLR to resignal the TE
LSP over the restored resource would fail as the MP will not send LSP over the restored resource will fail, as the MP will not send any
any Resv message. The PLR will still refresh the TE LSP over the Resv message. The PLR will still refresh the TE LSP over the backup
backup tunnel. The TE LSP will not revert to the restored resource; tunnel. The TE LSP will not revert to the restored resource;
instead it will continue to use the backup until it is instead, it will continue to use the backup until it is re-optimized.
re-optimized.
8. Merge Node Behavior 7. Merge Node Behavior
An LSR is a Merge Point if it receives the Path message for a An LSR is a Merge Point if it receives the Path message for a
protected LSP and one or more messages for a backup LSP which is protected LSP and one or more messages for a backup LSP that is
merged into that protected LSP. In the one-to-one backup merged into that protected LSP. In the one-to-one backup method, the
technique, the LSR is aware that it is a merge node prior to LSR is aware that it is a merge node prior to failure. In the
failure. In the facility backup technique, the LSR may not know facility backup method, the LSR may not know that it is a Merge Point
that it is a Merge Point until a failure occurs and it receives a until a failure occurs and it receives a backup LSP's Path message.
backup LSP's Path message. Therefore, an LSR which is on the path Therefore, an LSR that is on the path of a protected LSP SHOULD
of a protected LSP SHOULD always assume that it is a merge point. always assume that it is a merge point.
When a MP receives a backup LSP's Path message thru a bypass When a MP receives a backup LSP's Path message through a bypass
tunnel, the Send_TTL in the Common Header may not match the TTL of tunnel, the Send_TTL in the Common Header may not match the TTL of
the IP packet within which the Path message was transported. This the IP packet within which the Path message was transported. This is
is expected behavior. expected behavior.
8.1. Handling Backup Path Messages Before Failure 7.1. Handling Backup Path Messages before Failure
There are two circumstances where a Merge Point will receive Path There are two circumstances in which a Merge Point will receive Path
messages for a backup path prior to failure. In the first case, if messages for a backup path prior to failure. In the first case, if a
a PLR is providing local protection via the one-to-one backup PLR is providing local protection via the one-to-one backup method,
technique, the detour will be signaled and must be properly handled the detour will be signaled and must be properly handled by the MP.
by the MP. In this case, the backup LSP may be signaled via the
sender-template-specific method or via the path-specific method.
In the second case, if the Merge Point does not provide labels In this case, the backup LSP may be signaled via the sender
global to the MP and record them in a Label sub-object of the RRO template-specific method or via the path-specific method.
or if the PLR does not use such recorded information, the PLR may
signal the backup path, as described above in Section 7.4.1, to
determine the label to use if the PLR is providing protection
according to the facility backup technique. In this case, the
backup LSP is signaled via the sender-template-specific method.
The reception of a backup LSP's path message does not indicate that In the second case, if the Merge Point does not provide labels global
a failure has occured and the incoming protected LSP will no longer to the MP and record them in a Label sub-object of the RRO, or if the
be used. PLR does not use such recorded information, the PLR may signal the
backup path as described in Section 6.4.1. This will determine the
label to use if the PLR is providing protection according to the
facility backup method. In this case, the backup LSP is signaled via
the sender template-specific method.
8.1.1. Merginging Backup Paths using the Sender-Template Specific Method The reception of a backup LSP's path message does not indicate that a
failure has occurred or that the incoming protected LSP will no
longer be used.
An LSR may receive multiple Path messages for one or more backup 7.1.1. Merging Backup Paths using the Sender Template-Specific Method
LSPs and, possibly, the protected LSP. Each of these Path messages
An LSR may receive multiple Path messages for one or more backup LSPs
and, possibly, for the protected LSP. Each of these Path messages
will have a different SENDER_TEMPLATE. The protected LSP can be will have a different SENDER_TEMPLATE. The protected LSP can be
recognized because it will either include the FAST_REROUTE object, recognized because it will include the FAST_REROUTE object or have
have the "local protection desired" flag set in the the "local protection desired" flag set in the SESSION_ATTRIBUTE
SESSION_ATTRIBUTE object or both. object, or both.
If the outgoing interface and next-hop LSR are the same, then the If the outgoing interface and next-hop LSR are the same, then the
Path messages are eligible for merging. Similar to that specified Path messages are eligible for merging. Similarly to the
in [RSVP-TE] for merging of RESV messages, only those Path messages specification in [RSVP-TE] for merging of RESV messages, only Path
whose ERO from that LSR to the egress is the same can be merged. messages whose ERO from that LSR to the egress is the same can be
If merging occurs and one of the Path messages merged was for the merged. If merging occurs and one of the Path messages merged was
protected LSP, then the final Path message to be sent MUST be that for the protected LSP, then the final Path message to be sent MUST be
of the protected LSP. This merges the backup LSPs into the that of the protected LSP. This merges the backup LSPs into the
protected LSP at that LSR. Once the final Path message has been protected LSP at that LSR. Once the final Path message has been
identified, the MP MUST start to refresh it downstream identified, the MP MUST start to refresh it downstream periodically.
periodically.
If merging occurs and all the Path messages were for backup LSPs, If merging occurs and all the Path messages were for backup LSPs,
then the DETOUR object, if any, should be altered as specified in then the DETOUR object, if any, should be altered as specified in
Section 9.1 Section 8.1
8.1.2. Merging Detours using the Path-Specific Method 7.1.2. Merging Detours using the Path-Specific Method
An LSR (that is, an MP) may receive multiple Path messages from An LSR (that is, an MP) may receive multiple Path messages from
different interfaces with identical SESSION and SENDER_TEMPLATE different interfaces with identical SESSION and SENDER_TEMPLATE
objects. In this case, Path state merging is REQUIRED. objects. In this case, Path state merging is REQUIRED. The merging
rule is as follows:
The merging rule is the following:
For all Path messages that do not have either a FAST_REROUTE or a If all Path messages have neither a FAST_REROUTE nor a DETOUR object,
DETOUR object, or the MP is the egress of the LSP, no merging is or if the MP is the egress of the LSP, no merging is required. The
required. The messages are processed according to [RSVP-TE]. messages are processed according to [RSVP-TE].
Otherwise, the MP MUST record the Path state as well as their Otherwise, the MP MUST record the Path state and the incoming
incoming interface. If the Path messages do not share outgoing interface. If the Path messages do not share an outgoing interface
interface and next-hop LSR, the MP MUST consider them as independent and a next-hop LSR, the MP MUST consider them to be independent LSPs
LSPs, and MUST NOT merge them. and MUST NOT merge them.
For all the Path messages that share the same outgoing interface and For all the Path messages that share the same outgoing interface and
next-hop LSR, the MP runs the following procedure to a Path message next-hop LSR, the MP runs the following procedure to create a Path
to forward downstream. message to forward downstream.
1. If one or more of the Path messages is for the protected LSP 1. If one or more of the Path messages is for the protected LSP (a
(a protected LSP is one originated from this node, or with protected LSP is one originated from this node, or with the
the FAST_REROUTE object, or without the DETOUR object), FAST_REROUTE object, or without the DETOUR object), one of these
one of these must become the chosen Path message. There could must become the chosen Path message. There could be more than
be more than one; in that case, it is a local decision to choose one; in that case, which one to forward is a local decision.
which one to forward. Quit. Quit.
2. From the remaining set of Detour Path messages, eliminate from 2. From the remaining set of Detour Path messages, eliminate from
consideration, those that traverse nodes which others want to consideration those that traverse nodes that others want to
avoid. avoid.
3. If several still remain, it is a local decision to choose which 3. If several still remain, which one to forward is a local
one to forward. If none remain, then the MP may try and find a decision. If none remain, then the MP MAY try to find a new
new route that does avoid all nodes that all merging Detour route that avoids all nodes that merging Detour Paths want to
Paths want to avoid and forward a Path message with that ERO. avoid; it will forward a Path message with that ERO.
Once the final Path message has been identified, the MP MUST start to Once the final Path message has been identified, the MP MUST start to
refresh it downstream periodically. Other LSPs are considered merged refresh it downstream periodically. Other LSPs are considered merged
at this node. For bandwidth reservation on the outgoing link, any at this node. For bandwidth reservations on the outgoing link, any
merging should be considered to have occured before bandwidth is merging should be considered to have occurred before bandwidth is
reserved. Thus, even though Fixed Filter is specified, multiple reserved. Thus, even though Fixed Filter style is specified,
detours and/or their protected LSP which are to be merged due to multiple detours and/or their protected LSP (which are to be merged
sharing an outgoing interface and next-hop LSR will reserve only due to sharing an outgoing interface and next-hop LSR) will reserve
the bandwidth of the final Path message on that outgoing only the bandwidth of the final Path message on that outgoing
interface. interface.
If no merged Path message can be constructed then the MP SHOULD send If no merged Path message can be constructed, the MP SHOULD send a
a PathErr in response to the most recently received detour Path PathErr in response to the most recently received detour Path
message. If a protected Path is chosen to be forwarded, but it message. If a protected Path is chosen to be forwarded but it
traverses nodes that some detours want to avoid, PathErrs should be traverses nodes that some detours want to avoid, PathErrs SHOULD be
sent in response to those detour Paths which cannot merge. sent in response to those detour Paths which cannot merge.
8.1.2.1. An Example on Path Message Merging 7.1.2.1. An Example of Path Message Merging
R7---R8---R9-\ R7---R8---R9-\
| | | \ | | | \
R1---R2---R3---R4---R5---R6 R1---R2---R3---R4---R5---R6
Protected LSP: [R1->R2->R3->R4->R5->R6] Protected LSP: [R1->R2->R3->R4->R5->R6]
R2's Detour: [R2->R7->R8->R9->R4->R5->R6] R2's Detour: [R2->R7->R8->R9->R4->R5->R6]
R3's Detour: [R3->R8->R9->R5->R6] R3's Detour: [R3->R8->R9->R5->R6]
Example 4: Path Message Merging Example 4. Path Message Merging
In Example 4 above, R8 will receive Path messages that have the In Example 4, R8 will receive Path messages that have the same
same SESSION and SENDER_TEMPLATE from detours for R2 and R3. SESSION and SENDER_TEMPLATE from detours for R2 and R3. During
During merging at R8 since detour R3 has a shorter ERO path length merging at R8, because detour R3 has a shorter ERO path length (that
(that is, ERO is [R9->R5->R6], and path length is 3), R8 will is, ERO is [R9->R5->R6], and path length is 3), R8 will select it as
select it as the final LSP, and only propagate its Path messages the final LSP and will only propagate its Path messages downstream.
downstream. Upon receiving a Resv (or a ResvTear) message, R8 must Upon receiving a Resv (or a ResvTear) message, R8 must relay the
relay on the messages toward both R2 and R3. messages toward both R2 and R3.
R5 needs to merge as well, and will select the main LSP, since it R5 has to merge as well, and it will select the main LSP, since it
has the FAST_REROUTE object. Thus, the detour LSP terminates at has the FAST_REROUTE object. Thus, the detour LSP terminates at R5.
R5.
8.1.3. Message Handling for Merged Detours 7.1.3. Message Handling for Merged Detours
When an LSR receives a ResvTear for an LSP, the LSR must determine When an LSR receives a ResvTear for an LSP, the LSR must determine
whether it has an alternate associated LSP. For instance, if the whether it has an alternate associated LSP. For instance, if the
ResvTear was received for a protected LSP, but an associated backup ResvTear was received for a protected LSP but an associated backup
LSP has not received a ResvTear, then the LSR has an alternate LSP has not received a ResvTear, then the LSR has an alternate
associated LSP. If the LSR does not have an alternate associated associated LSP. If the LSR does not have an alternate associated
LSP, then the MP MUST propogate the ResvTear toward the LSP's LSP, then the MP MUST propagate the ResvTear toward the LSP's
ingress and, for each backup LSP merged into that LSP at this LSR, ingress, and, for each backup LSP merged into that LSP at this LSR,
the ResvTear SHOULD also be propogated along the backup LSP. the ResvTear SHOULD also be propagated along the backup LSP.
The MP may receive PathTear messages for some of the merging LSPs. The MP may receive PathTear messages for some of the merging LSPs.
PathTear messages SHOULD NOT be propagated downstream until the MP PathTear messages SHOULD NOT be propagated downstream until the MP
has received PathTear messages for each of the merged LSPs. has received PathTear messages for each of the merged LSPs. However,
However, the fact that one or more of the merged LSPs has been torn the fact that one or more of the merged LSPs has been torn down
down should be reflected in the downstream message, such as by should be reflected in the downstream message, such as by changing
changing the DETOUR object, if any. the DETOUR object, if there is one.
8.2. Handling Failures 7.2. Handling Failures
When a downstream LSR detects a local link failure, for any When a downstream LSR detects a local link failure, for any protected
protected LSPs routed over the failed link, Path and Resv state LSPs routed over the failed link, Path and Resv state MUST NOT be
MUST NOT be cleared and PathTear and ResvErr messages MUST NOT be cleared, and PathTear and ResvErr messages MUST NOT be sent
sent immediately; if this is not the case, then the facility backup immediately. If this is not the case, then the facility backup
technique will not work. Further a downstream LSR SHOULD reset the method will not work. Furthermore, a downstream LSR SHOULD reset the
refresh timers for these LSPs as if they had just been refreshed. refresh timers for these LSPs as if they had just been refreshed.
This is to allow time for the PLR to begin refreshing state via the This is to allow time for the PLR to begin refreshing state via the
bypass tunnel. State MUST be removed if it has not been refreshed bypass tunnel. State MUST be removed if it has not been refreshed
before the refresh timer expires. This allows the facility backup before the refresh timer expires. This allows the facility backup
technique to work without requiring that it signal backup paths method to work without requiring that it signal backup paths through
thru the bypass tunnel before failure. the bypass tunnel before failure.
After a failure has occured, the MP must still send Resv messages After a failure has occurred, the MP must still send Resv messages
for the backup LSPs associated with the protected LSPs which have for the backup LSPs associated with the protected LSPs that have
failed. If the backup LSP was sent through a bypass tunnel, then failed. If the backup LSP was sent through a bypass tunnel, then the
the PHOP object in its Path message will have the IP address of the PHOP object in its Path message will have the IP address of the
associated PLR. This will ensure that Resv state is refreshed. associated PLR. This will ensure that Resv state is refreshed.
Once the local link has recovered, the MP may or may not accept Once the local link has recovered, the MP may or may not accept Path
Path messages for existing protected LSPs which had failed over to messages for existing protected LSPs that had failed over to their
their backup. backup.
9. Behavior of all LSRs 8. Behavior of All LSRs
The objects defined and the techniques defined in this document The objects and methods defined in this document require behavior
require behavior from all LSRs in the traffic-engineered network, from all LSRs in the traffic-engineered network, even if an LSR is
even if that LSR is not along the path of a protected LSP. not along the path of a protected LSP.
First, if a DETOUR object is included in the backup LSP's path First, if a DETOUR object is included in the backup LSP's path
message for the sender-template-specific method, the LSRs in the message for the sender template-specific method, the LSRs in the
traffic-engineered network should support the DETOUR object. traffic-engineered network should support the DETOUR object.
Second, if the Path-Specific Method is to be supported for Second, if the path-specific method is to be supported for the one-
the one-to-one backup technique, it is necessary that the LSRs in to-one backup method, it is necessary that the LSRs in the traffic-
the traffic-engineered network be capable of merging detours as engineered network be capable of merging detours as specified in
specified below in Section 9.1. Section 8.1.
It is possible to avoid specific LSRs which do not support this It is possible to avoid specific LSRs that do not support this
behavior by assigning an link attribute to all the links of those behavior by assigning a link attribute to all the links of those LSPs
LSPs and then requesting that backup paths exclude that link and then requesting that backup paths exclude this link attribute.
attribute.
9.1. Merging Detours in Path-Specific Method 8.1. Merging Detours in the Path-Specific Method
If multiple Path Messages for different detours are received with If multiple Path Messages for different detours are received with the
the same SESSION, SENDER_TEMPLATE, outgoing interface and next-hop same SESSION, SENDER_TEMPLATE, outgoing interface, and next-hop LSR,
LSR, then the LSR must function as a Detour Merge Point and merge then the LSR must function as a Detour Merge Point and merge the
the detour Path Messages. This merging should occur as specified detour Path Messages. This merging should occur as specified in
in Section 8.1.2 and shown in Example 4. Section 7.1.2 and shown in Example 4.
In addition, it is necessary to update the DETOUR object to reflect In addition, it is necessary to update the DETOUR object to reflect
the merging which has taken place. This is done using the the merging that has taken place. This is done using the following
following algorithm to format the outgoing DETOUR object for the algorithm to format the outgoing DETOUR object for the final LSP:
final LSP:
- Combine all the (PLR_ID, Avoid_Node_ID) pairs from all the - Combine all the (PLR_ID, Avoid_Node_ID) pairs from all the DETOUR
DETOUR objects of all merged LSPs, and create a new object with objects of all merged LSPs into a new object. Ordering is
all listed. Ordering is insignificant. insignificant.
10. Security Considerations 9. Security Considerations
This document does not introduce new security issues. The security This document does not introduce new security issues. The security
considerations pertaining to the original RSVP protocol [RSVP] remain considerations pertaining to the original RSVP protocol [RSVP] remain
relevant. relevant.
It should be noted that the facility backup technique requires that Note that the facility backup method requires that a PLR and its
a PLR and its selected Merge Point will trust RSVP messages selected merge point trust RSVP messages received from each other.
received from each other.
11. IANA Section 10. IANA Considerations
IANA [RFC-IANA] will assign RSVP Class Number 205 for the IANA [RFC-IANA] has assigned the following RSVP Class Numbers for
FAST_REROUTE and RSVP Class Number 63 for the DETOUR object. This objects defined in this document.
matches the current usage in production networks.
IANA will assign C-Type 1 for the standard FAST_REROUTE object 10.1. DETOUR Object
format defined in section 5.1 and list C-Type 7 as reserved as it
is still used by pre-standard implementations. Future C-Types IANA has assigned:
will be assigned using the following guidelines:
63 DETOUR
Class Types or C-Types:
7 IPv4
8 IPv6
Future C-Types will be assigned using the following guidelines:
C-Types 0 through 127 are assigned by Standards Action. C-Types 0 through 127 are assigned by Standards Action.
C-Types 128 through 191 are assigned by Expert Review. C-Types 128 through 191 are assigned by Expert Review.
C-Types 192 through 255 are reserved for Vendor Private Use. C-Types 192 through 255 are reserved for Vendor Private Use.
For C-Types in the range 192 through 255, the first four octets of For C-Types in the range 192 through 255, the first four octets of
the FAST_REROUTE object after the C-Type MUST be the Vendor's SMI the DETOUR object after the C-Type must be the Vendor's SMI Network
Network Management Private Enterprise Code (see [ENT]) in network Management Private Enterprise Code (see [ENT]) in network byte order.
byte order.
IANA will assign C-Types 7 and 8 to the IPv4 and IPv6 DETOUR object 10.2. FAST_REROUTE Object
formats as defined in section 5.2. Future C-Types will be
assigned using the following guidelines: IANA has assigned:
205 FAST_REROUTE
Class Types or C-Types:
1 FAST_REROUTE Type 1
7 RESERVED
In the FAST_REROUTE object, C-Type 7 is reserved as it is still used
by pre-standard implementations. Future C-Types will be assigned
using the following guidelines:
C-Types 0 through 127 are assigned by Standards Action. C-Types 0 through 127 are assigned by Standards Action.
C-Types 128 through 191 are assigned by Expert Review. C-Types 128 through 191 are assigned by Expert Review.
C-Types 192 through 255 are reserved for Vendor Private Use. C-Types 192 through 255 are reserved for Vendor Private Use.
For C-Types in the range 192 through 255, the first four octets of For C-Types in the range 192 through 255, the first four octets of
the DETOUR object after the C-Type MUST be the Vendor's SMI Network the FAST_REROUTE object after the C-Type must be the Vendor's SMI
Management Private Enterprise Code (see [ENT]) in network byte order. Network Management Private Enterprise Code (see [ENT]) in network
byte order.
12. Intellectual Property Considerations 11. Contributors
The IETF takes no position regarding the validity or scope of any This document was written by George Swallow, Ping Pan, Alia Atlas,
intellectual property or other rights that might be claimed to Jean Philippe Vasseur, Markus Jork, Der-Hwa Gan, and Dave Cooper.
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF has been notified of intellectual property rights Jean Philippe Vasseur
claimed in regard to some or all of the specification contained Cisco Systems, Inc.
in this document. For more information consult the online list 300 Beaver Brook Road
of claimed rights. Boxborough, MA 01719
USA
13. Full Copyright Statement Phone: +1 978 497 6238
EMail: jpv@cisco.com
Copyright (C) The Internet Society (2002). All Rights Reserved. Markus Jork
Quarry Technologies
8 New England Executive Park
Burlington, MA 01803
USA
This document and translations of it may be copied and furnished to Phone: +1 781 359 5071
others, and derivative works that comment on or otherwise explain it EMail: mjork@quarrytech.com
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Der-Hwa Gan
revoked by the Internet Society or its successors or assigns. Juniper Networks
1194 N.Mathilda Ave
Sunnyvale, CA 94089
USA
This document and the information contained herein is provided on an Phone: +1 408 745 2074
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING EMail: dhg@juniper.net
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
14. Acknowledgments Dave Cooper
Global Crossing
960 Hamlin Court
Sunnyvale, CA 94089
USA
Phone: +1 916 415 0437
EMail: dcooper@gblx.net
12. Acknowledgments
We would like to acknowledge input and helpful comments from Rob We would like to acknowledge input and helpful comments from Rob
Goguen, Tony Li, Yakov Rekhter and Curtis Villamizar. Especially, Goguen, Tony Li, Yakov Rekhter and Curtis Villamizar. Especially, we
we thank those, who have been involved in interoperability testing thank those, who have been involved in interoperability testing and
and field trails, and provided invaluable ideas and suggestions. field trails, and provided invaluable ideas and suggestions. They
They are Rob Goguen, Carol Iturralde, Brook Bailey, Safaa Hasan, are Rob Goguen, Carol Iturralde, Brook Bailey, Safaa Hasan, Richard
Richard Southern, and Bijan Jabbari. Southern, and Bijan Jabbari.
15. Normative References 13. Normative References
[RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP) [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
-- version 1 functional specification," RFC2205, September 1997. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
1 Functional Specification", RFC 2205, September 1997.
[RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP [RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
tunnels", RFC3029, December 2001. V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate [RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an [RFC-IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434. IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[ENT] IANA PRIVATE ENTERPRISE NUMBERS, [ENT] IANA PRIVATE ENTERPRISE NUMBERS,
http://www.iana.org/assignments/enterprise-numbers http://www.iana.org/assignments/enterprise-numbers
16. Editor Information Authors' Addresses
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
email: swallow@cisco.com
phone: +1 978 244 8143 Phone: +1 978 244 8143
EMail: swallow@cisco.com
Ping Pan Ping Pan
Hammerhead Systems
640 Clyde Court 640 Clyde Court
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
e-mail: ppan@hammerheadsystems.com
EMail: ppan@hammerheadsystems.com
Alia Atlas Alia Atlas
Avici Systems Avici Systems
101 Billerica Avenue 101 Billerica Avenue
N. Billerica, MA 01862 N. Billerica, MA 01862
USA USA
email: aatlas@avici.com
phone: +1 978 964 2070 Phone: +1 978 964 2070
EMail: aatlas@avici.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/