draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt   draft-ietf-mpls-rsvp-lsp-fastreroute-04.txt 
Internet Draft Ping Pan, Ed (Ciena Corp) Internet Draft Ping Pan, Ed (Ciena Corp)
Expires: Dec 2003 Der-Hwa Gan (Juniper Networks) Expires: August 2004 George Swallow, Ed (Cisco Systems)
George Swallow (Cisco Systems)
Jean Philippe Vasseur (Cisco Systems)
Dave Cooper (Global Crossing)
Alia Atlas, Ed (Avici Systems) Alia Atlas, Ed (Avici Systems)
Markus Jork (Avici Systems)
Fast Reroute Extensions to RSVP-TE for LSP Tunnels Fast Reroute Extensions to RSVP-TE for LSP Tunnels
draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt draft-ietf-mpls-rsvp-lsp-fastreroute-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 9 skipping to change at page 2, line 5
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 protected LSPs that
have similar backup constraints. Both methods can be used to protect have 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 or both methods
and to interoperate in a mixed network. and to interoperate in a mixed network.
0. Background Contents
Several years before work began on this draft, operational networks 1 Authors .................................................. 3
had deployed two independent methods of doing fast reroute, called 2 Introduction ............................................. 3
herein one-to-one backup and facility backup. Vendors trying to 2.1 Background ........................................... 4
support both methods were experiencing incompatiblity problems in 3 Terminology ............................................... 5
attempting to produce a single implementation capable of 4 Local Repair Techniques ................................... 7
interoperating with both. There are technical tradeoffs between 4.1 One-to-one Backup ..................................... 7
the methods. However these tradeoffs are so topologically 4.2 Facility Backup ....................................... 8
dependent, that the community has not converged on a single 5 RSVP Extensions ........................................... 9
approach. 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 ...................................... 35
16 Editor Information ........................................ 36
This draft rationalizes the RSVP signaling for both methods such 1. Authors
that any implementation can recognize all FRR requests and clearly
respond, either positively if they are capable of performing the
method, or with a clear error such that requester is informed and
can seek alternate means of backup. This draft also allows a
single implementation to support both methods, thereby providing a
range of capabilities. Thus the described behavior and extensions
to RSVP allow LERs and LSRs to implement either or both methods.
While the two methods could in principle be used in a single This document was written by George Swallow, Ping Pan, Alia Atlas,
network, it is expected that operators will continue to choose to Jean Philippe Vasseur, Markus Jork, Der-Hwa Gan, and Dave Cooper.
deploy either one or the other. The goal of this draft is to
standardize the RSVP signaling such that either a network with LSRs
that implement both methods or an network composed of some LSRs
that support one method and others that support both, can properly
signal among those LSRs to achieve fast restoration through the
chosen method.
Contents Jean Philippe Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA
email: jpv@cisco.com
phone: +1 978 497 6238
1 Introduction ............................................. 4 Markus Jork
2 Terminology ............................................... 4 Avici Systems
3 Local Repair Techniques ................................... 6 101 Billerica Avenue
3.1 One-to-one Backup .................................... 6 N. Billerica, MA 01862
3.2 Facility Backup ...................................... 7 USA
4 RSVP Extensions ........................................... 8 email: mjork@avici.com
4.1 FAST_REROUTE Object .................................... 8 phone: +1 978 964 2142
4.2 DETOUR Object .......................................... 11
4.3 SESSION_ATTRIBUTE Flags ................................ 12
4.4 RRO IPv4/IPv6 Sub-Object Flags ......................... 13
5 Head-End Behavior ......................................... 14
6 Point of Local Repair Behavior ............................ 15
6.1 Signaling a Backup Path ................................ 16
6.1.1 Backup Path Identification: Sender-Template Specific . 17
6.1.2 Backup Path Identification: Path-Specific ........... 18
6.2 Procedures for Backup Path Computation ................. 18
6.3 Signaling Backups for One-To-One Protection ............ 20
6.3.1 Make-Before-Break with Detour LSPs .................. 21
6.3.2 Message Handling .................................... 21
6.3.3 Local Reroute of Traffic Onto Detour LSP ............ 22
6.4 Signaling for Facility Protection ...................... 23
6.4.1 Discovering Downstream Labels ....................... 23
6.4.2 Procedures for the PLR before Local Repair .......... 23
6.4.3 Procedures for the PLR during Local Repair .......... 23
6.4.4 Processing backup tunnel's ERO ...................... 24
6.5 PLR Procedures During Local Repair ..................... 25
6.5.1 Notification of local repair ........................ 25
6.5.2 Revertive Behavior .................................. 26
7 Merge Node Behavior ....................................... 27
7.1 Handling Backup Path Messages Before Failure ........... 27
7.1.1 Merging Backup Paths using the Sender-Template
Specific Method ..................................... 28
7.1.2 Merging Detours using Path-Specific Method .......... 28
7.1.2.1 An Example on Path Message Merging ............... 29
7.1.3 Message Handling for Merged Detours ................. 30
7.2 Handling Failures ...................................... 30
8 Behavior of all LSRs ...................................... 31
8.1 Merging Detours in Path-Specific Method ................ 31
9 Security Considerations ................................... 32
10 IANA Guidelines ........................................... 32
11 Intellectual Property Considerations ...................... 32
12 Full Copyright Statement .................................. 32
13 Acknowledgments ........................................... 33
14 Normative References ...................................... 33
15 Author Information ........................................ 33
1. Introduction Der-Hwa Gan
Juniper Networks
1194 N.Mathilda Ave
Sunnyvale, CA 94089
USA
e-mail: dhg@juniper.net
phone: +1 408 745 2074
Dave Cooper
Global Crossing
960 Hamlin Court
Sunnyvale, CA 94089
USA
email: dcooper@gblx.net
phone: +1 916 415 0437
2. Introduction
This document extends RSVP [RSVP] to establish backup LSP tunnels This document extends RSVP [RSVP] to establish backup LSP tunnels
for the local repair of LSP tunnels. This technique is presented for the local repair of LSP tunnels. This technique is presented
to meet the needs of real-time applications, such as voice over IP, to meet the needs of real-time applications, such as voice over IP,
for which it is highly desirable to be able to re-direct user for which it is highly desirable to be able to re-direct user
traffic onto backup LSP tunnels in 10s of milliseconds. This traffic onto backup LSP tunnels in 10s of milliseconds. This
timing requirement can be satisfied by computing and signaling timing requirement can be satisfied by computing and signaling
backup LSP tunnels in advance of failure and by re-directing backup LSP tunnels in advance of failure and by re-directing
traffic as close to failure point as possible. In this way, the traffic as close to failure point as possible. In this way, the
time for the redirection does not include any path computation or time for the redirection does not include any path computation or
skipping to change at page 4, line 27 skipping to change at page 4, line 20
notification between LSRs. The speed of repair made possible by notification between LSRs. The speed of repair made possible by
the techniques and extensions described herein is the primary the techniques and extensions described herein is the primary
advantage of this method. We use the term local repair when advantage of this method. We use the term local repair when
referring to techniques which accomplish this, and refer to an referring to techniques which accomplish this, and refer to an
explicitly routed LSP which is provided with such protection as a explicitly routed LSP which is provided with such protection as a
protected LSP. These techniques are applicable only to explicitly protected LSP. These techniques are applicable only to explicitly
routed LSPs; Application of the techniques discussed herein to LSPs routed LSPs; Application of the techniques discussed herein to LSPs
which dynamically change their routes such as those used in unicast which dynamically change their routes such as those used in unicast
IGP routing is beyond the scope of this document. IGP routing is beyond the scope of this document.
Section 2 covers new terminology used in this document. The two Section 3 covers new terminology used in this document. The two
basic strategies for creating backup LSPs are described in Section basic strategies for creating backup LSPs are described in Section
3. In Section 4, the protocol extensions to RSVP to support local 4. In Section 5, the protocol extensions to RSVP to support local
protection are described. In Section 5, the behavior of an LER protection are described. In Section 6, the behavior of an LER
which wishes to request local protection for an LSP is presented. which wishes to request local protection for an LSP is presented.
The behavior of a potential point of local repair (PLR) is given in The behavior of a potential point of local repair (PLR) is given in
Section 6; this describes how to determine the appropriate strategy Section 7; this describes how to determine the appropriate strategy
to use for protecting an LSP and how to implement each of the to use for protecting an LSP and how to implement each of the
strategies. The behavior of a merge node, the LSR where a strategies. The behavior of a merge node, the LSR where a
protected LSP and its backup LSP rejoin, is described in Section 7. protected LSP and its backup LSP rejoin, is described in Section 8.
Finally, the required behavior of other nodes in the network is Finally, the required behavior of other nodes in the network is
discussed in Section 8. discussed in Section 9.
For the techniques discussed in this document to function properly, For the techniques discussed in this document to function properly,
there are three assumptions which must be made. First, an LSR there are three assumptions which must be made. First, an LSR
which is on the path of a protected LSP SHOULD always assume that 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 it is a merge point; this is necessary because the facility backup
method does not signal backups through a bypass tunnel before method does not signal backups through a bypass tunnel before
failure. Second, if the one-to-one backup method is used and a failure. Second, if the one-to-one backup method is used and a
DETOUR object is included, the LSRs in the traffic-engineered DETOUR object is included, the LSRs in the traffic-engineered
network should support the DETOUR object; this is necessary so that network should support the DETOUR object; this is necessary so that
the Path message containing the DETOUR object is not rejected. the Path message containing the DETOUR object is not rejected.
Third, understanding of the DETOUR object is required to support Third, understanding of the DETOUR object is required to support
the path-specific method which requires that LSRs in the 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. Terminology 2.1 Background
Several years before work began on this draft, operational networks
had deployed two independent methods of doing fast reroute, called
herein one-to-one backup and facility backup. Vendors trying to
support both methods were experiencing incompatiblity problems in
attempting to produce a single implementation capable of
interoperating with both. There are technical tradeoffs between
the methods. However these tradeoffs are so topologically
dependent, that the community has not converged on a single
approach.
This draft rationalizes the RSVP signaling for both methods such
that any implementation can recognize all FRR requests and clearly
respond, either positively if they are capable of performing the
method, or with a clear error such that requester is informed and
can seek alternate means of backup. This draft also allows a
single implementation to support both methods, thereby providing a
range of capabilities. Thus the described behavior and extensions
to RSVP allow LERs and LSRs to implement either or both methods.
While the two methods could in principle be used in a single
network, it is expected that operators will continue to choose to
deploy either one or the other. The goal of this draft is to
standardize the RSVP signaling such that either a network with LSRs
that implement both methods or an network composed of some LSRs
that support one method and others that support both, can properly
signal among those LSRs to achieve fast restoration through the
chosen method.
3. 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
skipping to change at page 6, line 17 skipping to change at page 6, line 43
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 is an LSR where multiple detours converge and only one this is an LSR where multiple detours converge and only one
detour is signaled beyond that LSR. detour 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 protection. See Section 9.1 for more detail. local protection. See Section 10.1 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.
3. Local Repair Techniques 4. Local Repair Techniques
Two different techniques for local protection are presented here. Two different techniques for local protection are presented here.
The one-to-one backup technique has a PLR compute a separate backup The one-to-one backup technique has a PLR compute a separate backup
LSP, called a detour LSP, for each LSP which the PLR protects using LSP, called a detour LSP, for each LSP which the PLR protects using
this technique. With the facility backup technique, the PLR creates this technique. With the facility backup technique, the PLR creates
a single bypass tunnel which can be used to protect multiple LSPs. a single bypass tunnel which can be used to protect multiple LSPs.
3.1. One-to-one backup 4.1. One-to-one backup
In the one-to-one technique, a label switched path is established In the one-to-one technique, a label switched path is established
which intersects the original LSP somewhere downstream of the point which intersects the original LSP somewhere downstream of the point
of link or node failure. For each LSP which is backed up, a of link or node failure. For each LSP which is backed up, a
separate backup LSP is established. separate backup LSP is established.
[R1]---[R2]-----[R3]----[R4]---[R5] [R1]---[R2]-----[R3]----[R4]---[R5]
\ \ \ / \ / \ \ \ / \ /
[R6]---[R7]-------[R8]----[R9] [R6]---[R7]-------[R8]----[R9]
skipping to change at page 7, line 31 skipping to change at page 8, line 9
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 protected LSP along link [R2->R7] using the label received when the protected LSP along link [R2->R7] using the label received when
R2 created the detour. When R4 receives traffic with the label R2 created the detour. When R4 receives traffic with the label
provided for R2's detour, R4 will switch that traffic onto link provided for R2's detour, R4 will switch that traffic onto link
[R4-R5] using the label received from R5 for the protected LSP. At [R4-R5] using the label received from R5 for the protected LSP. At
no point does the depth of the label stack increase as a result of no point does the depth of the label stack increase as a result of
taking the detour. While R2 is using its detour, traffic will take taking the detour. While R2 is using its detour, traffic will take
the path [R1->R2->R7->R8->R4->R5]. the path [R1->R2->R7->R8->R4->R5].
3.2. Facility backup 4.2. Facility backup
The facility backup technique takes advantage of the MPLS label The facility backup technique takes advantage of the MPLS label
stack. Instead of creating a separate LSP for every backed-up LSP, a stack. Instead of creating a separate LSP for every backed-up LSP, a
single LSP is created which serves to backup up a set of LSPs. We single LSP is created which serves to backup up a set of LSPs. We
call such an LSP tunnel a bypass tunnel. call such an 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 of LSPs being backed-up via that bypass tunnel to those that set of LSPs being backed-up via that bypass tunnel to those that
pass through some common downstream node. All LSPs which pass pass through some common downstream node. All LSPs which pass
skipping to change at page 8, line 4 skipping to change at page 8, line 29
pass through some common downstream node. All LSPs which pass pass through some common downstream node. All LSPs which pass
through the point of local repair and through this common node through the point of local repair and through this common node
which do not also use the facilities involved in the bypass tunnel which do not also use the facilities involved in the bypass tunnel
are candidates for this set of LSPs. are candidates for 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 In Example 2, R2 has built a bypass tunnel which protects against the
the failure of link [R2->R3], link [R3->R4] or node [R3]. The failure of link [R2->R3] and node [R3]. The doubled lines represent
doubled lines represent this tunnel. The scalability improvement this tunnel. The scalability improvement this technique provides is
this technique provides is that the same bypass tunnel can also be that the same bypass tunnel can also be used to protect LSPs from any
used to protect LSPs from any of R1, R2 or R8 to any of R4, R5 or of R1, R2 or R8 to any of R4, R5 or R9. Example 2 describes three
R9. Example 2 describes three different protected LSPs which are different protected LSPs which are using the same bypass tunnel for
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 technique, to fully protect an LSP that
traverses N nodes, there could be as many as (N-1) bypass tunnels. traverses N nodes, there could be as many as (N-1) bypass tunnels.
However, each of those bypass tunnels could protected a set of However, each of those bypass tunnels could protected 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 on the protected LSP onto link [R2->R6]; the label will be R1 on the protected LSP onto link [R2->R6]; the label will be
skipping to change at page 8, line 41 skipping to change at page 9, line 20
penultimate-hop-popping is used, then the merge point in Example 2, penultimate-hop-popping is used, then the merge point in Example 2,
R4, will receive the redirected packet with a label indicating the R4, will receive the redirected packet with a label indicating the
protected LSP that the packet is to follow. If protected LSP that the packet is to follow. If
penultimate-hop-popping is not used, then R4 will pop the bypass penultimate-hop-popping is not used, then R4 will pop the bypass
tunnel's label and examine the label underneath to determine the tunnel's label and examine the label underneath to determine 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 R2 and R4. between R2 and R4.
4. RSVP Extensions 5. RSVP Extensions
We propose two additional objects, FAST_REROUTE and DETOUR, to We propose two additional objects, FAST_REROUTE and DETOUR, to
extend RSVP-TE for fast-reroute signaling. These new objects are extend RSVP-TE for fast-reroute signaling. These new objects are
backward compatible with LSRs that do not recognize them (see backward compatible with LSRs that do not recognize them (see
section 3.10 in [RSVP]). Both objects can only be carried in RSVP section 3.10 in [RSVP]). Both objects can only be carried in RSVP
Path messages. 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.
4.1. FAST_REROUTE Object 5.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, the
session attribute filters, and bandwidth to be used for protection. session attribute filters, and bandwidth to be used for protection.
It also allows a specific local protection technique to be requested. It also allows a specific local protection technique to be requested.
This object MUST only be inserted into the PATH message by the This object MUST only be inserted into the PATH message by the
head-end LER and MUST NOT be changed by downstream LSRs. The head-end LER and MUST NOT be changed by downstream LSRs. The
FAST-REROUTE object has the following format: FAST-REROUTE object has the following format:
Class = TBD (use form 11bbbbbb for compatibility) 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 |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Bandwidth | | Bandwidth |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 11, line 4 skipping to change at page 11, line 41
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 set
(all bits set to zero) automatically passes. (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) indicate that nodes
that do not understand the object should ignore it and pass if that do not understand the object should ignore it and pass if
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
existing implementations. The meaning of the fields is the same as legacy implementations. The meaning of the fields is the same as
described for C-Type 1. described for C-Type 1.
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 |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
4.2. DETOUR Object 5.2. DETOUR Object
The DETOUR object is used in one-to-one backup to identify detour The DETOUR object is used in one-to-one backup to identify detour
LSPs. It has the following format: LSPs. It has the following format:
Class = TBD (to conform 0bbbbbbb format for compatibility) Class-Num = 63
5.2.1 DETOUR object for IPv4 address
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 IPv4 address identifying the beginning point of detour which is
is a PLR. Any local address on the PLR can be used. a PLR. Any local address on the PLR can be used.
Avoid Node ID (1 - n) Avoid Node ID (1 - n)
IP address identifying the immediate downstream node that IP address identifying the immediate downstream node that
the PLR is trying to avoid. Router ID of downstream node the PLR is trying to avoid. Router ID of downstream node
is preferred. This field is mandatory, and is used by is preferred. This field is mandatory, and is used by
the MP for merging rules discussed below. the MP for merging rules discussed below.
5.2.2 DETOUR object for IPv6 address
C-Type = 8
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| PLR ID 1 |
+-------------+-------------+-------------+-------------+
| PLR ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| PLR ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| PLR ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| Avoid Node ID 1 |
+-------------+-------------+-------------+-------------+
| Avoid Node ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| Avoid Node ID 1 (continued) |
+-------------+-------------+-------------+-------------+
| Avoid Node ID 1 (continued) |
+-------------+-------------+-------------+-------------+
// .... //
+-------------+-------------+-------------+-------------+
PLR ID (1 - n)
A 128-bit unicast host 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)
A 128-bit unicast host address identifying the immediate
downstream node that the PLR is trying to avoid. Router ID of
downstream node is preferred. This field is mandatory, and is
used by the MP for merging rules discussed 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 the subsequent Path messages.
The high-order bit of the C-Class is zero; LSRs that do not support The high-order bit of the C-Class 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 generated as specified in [RSVP] for unknown objects with a be generated as specified in [RSVP] for unknown objects with a
class-num of the form "0bbbbbbb". class-num of the form "0bbbbbbb".
4.3. SESSION_ATTRIBUTE Flags 5.3. SESSION_ATTRIBUTE Flags
To explicitly request bandwidth and node protection, two new flags To explicitly request bandwidth and node protection, 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:
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
skipping to change at page 13, line 22 skipping to change at page 15, line 16
LSP, if no FAST_REROUTE object is included in the PATH message; LSP, if no FAST_REROUTE object is included in the PATH message;
if a FAST_REROUTE object is in the PATH message, then the if a FAST_REROUTE object is in the PATH message, then the
bandwidth specified therein is that to be guaranteed. bandwidth specified therein is that 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 a backup path which bypasses at least the next node of that a backup path which bypasses at least the next node of
the protected LSP is desired. the protected LSP is desired.
4.4. RRO IPv4/IPv6 Sub-Object Flags 5.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 news flags in the RRO IPv4 sub-object.
RRO IPv4 and IPv6 sub-object address: RRO IPv4 and IPv6 sub-object address:
These two sub-objects currently have the following flags defined: These two sub-objects currently have the following flags defined:
Local protection available: 0x01 Local protection available: 0x01
skipping to change at page 14, line 25 skipping to change at page 16, line 19
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 the "node protection desired" flag was set in the and 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
setup a link-protection backup path, the "Local protection setup 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.
5. Head-End Behavior 6. 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 requested for that LSP and which local protection technique is be requested for that LSP and which local protection technique is
desired for the protected LSP. The head-end also determines what desired for the protected LSP. The head-end also determines what
constraints should be requested for the backup paths of a protected constraints 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 MUST either set the "Local protection desired" flag in the LSR 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
skipping to change at page 15, line 22 skipping to change at page 17, line 14
the one-to-one backup technique, then head-end LSR should include a the one-to-one backup technique, then 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 the head-end LSR desires that the protected LSP be protected via If the head-end LSR desires that the protected LSP be protected via
the facility backup technique, then the head-end LSR should include the facility backup technique, then the head-end LSR should include
a FAST_REROUTE object and set the "facility backup desired" flag. a FAST_REROUTE object and set the "facility backup desired" flag.
The lack of a FAST_REROUTE object, or having both these flags The lack of a FAST_REROUTE object, or having both these flags
clear should be treated by PLRs as a lack of preference. If clear should be treated by PLRs as a lack of preference. If
both flags are set a PLR may use either method or both. both flags are 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 defined in Section 4.4 being set or clear in the RRO IPv4 and flags defined in Section 5.4 being set or clear in the RRO IPv4 and
IPv6 sub-objects. The head-end LSR of a protected LSP MUST support IPv6 sub-objects. The head-end LSR of a protected LSP MUST support
the RRO Label sub-object. the 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.
6. Point of Local Repair Behavior 7. Point of Local Repair 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, and the "local protection available", "local protection in object, and the "local protection available", "local protection in
use", "bandwidth protection", and "node protection" flags in the use", "bandwidth protection", and "node protection" flags in the
RRO IPv4 and IPv6 sub-objects. A PLR MAY support the DETOUR RRO IPv4 and IPv6 sub-objects. A PLR MAY support the DETOUR
skipping to change at page 16, line 41 skipping to change at page 18, line 34
node and, if not, the PLR SHOULD clear the "node protection" node and, if not, the PLR SHOULD clear the "node protection"
flag. This MUST be done if the "node protection desired" flag flag. This MUST be done if the "node protection desired" flag
was set in the SESSION_ATTRIBUTE object. 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" if the backup path
offers a bandwidth guarantee and, if not, SHOULD clear the offers a bandwidth guarantee and, if not, SHOULD clear the
"bandwidth protection" flag. This MUST be done if the "bandwidth "bandwidth protection" flag. This MUST be done if the "bandwidth
protection desired" flag was set in the SESSION_ATTRIBUTE protection desired" flag was set in the SESSION_ATTRIBUTE
object. object.
6.1 Signaling a Backup Path 7.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 identify backup paths
2. Unambiguously associate protected LSPs with their backup paths 2. Unambiguously associate protected LSPs with their backup paths
3. Work with both global and non-global label spaces 3. Work with both global and non-global label spaces
4. Allow for merging of backup paths 4. Allow for merging of backup paths
5. Maintain RSVP state during and after fail-over. 5. Maintain RSVP state during and after fail-over.
skipping to change at page 18, line 8 skipping to change at page 19, line 49
that correct merging and state treatment can be done. Therefore, a that correct merging and state treatment can be done. Therefore, a
backup path must inherit its LSP ID from the associated protected backup path must inherit its LSP ID from the associated protected
LSP. Thus, the only field in the SESSION and SENDER_TEMPLATE LSP. Thus, the only field in the SESSION and SENDER_TEMPLATE
objects which could be varied between a backup path and a protected objects which could be varied between a backup path and a protected
LSP is the "IPv4 (or IPv6) tunnel sender address" in the LSP is the "IPv4 (or IPv6) 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. These are described below. path. These are described below.
6.1.1. Backup Path Identification: Sender-Template-Specific 7.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 the SENDER_TEMPLATE of the original LSP tunnel. in the SENDER_TEMPLATE of the original LSP tunnel.
When using the sender-template-specific approach, the protected When using the sender-template-specific approach, 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. This allows bandwidth sharing between multiple backup style. This allows bandwidth sharing between multiple backup
paths. The backup paths and the protected LSP MAY be merged by the paths. The backup paths and the protected LSP MAY be merged by the
Detour Merge Points, when the ERO from the MP to the egress is the Detour Merge Points, when the ERO from the MP to the egress is the
same on each LSP to be merged, as specified in [RSVP-TE]. same on each LSP to be merged, as specified in [RSVP-TE].
6.1.2. Backup Path Identification: Path-Specific 7.1.2. Backup Path Identification: Path-Specific
In this approach, rather than varying the SESSION or In this approach, rather than varying the SESSION or
SENDER_TEMPLATE objects, a new object, the DETOUR object, is used SENDER_TEMPLATE objects, a new object, the DETOUR object, is used
to distinguish between PATH messages for a backup path and the to distinguish between PATH messages for a backup path and the
protected LSP. protected 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
DETOUR object in Path messages signifies a backup path; the DETOUR object in Path messages signifies a backup path; the
presence of FAST_REROUTE object and/or the "local protection presence of FAST_REROUTE object and/or the "local protection
skipping to change at page 18, line 46 skipping to change at page 20, line 39
In the path-message-specific approach, when an LSR receives In the path-message-specific approach, when an LSR receives
multiple Path messages which have the same SESSION and multiple Path messages which have the same SESSION and
SENDER_TEMPLATE objects and also have the same next-hop, that LSR SENDER_TEMPLATE objects and also have the same next-hop, that LSR
MUST merge the Path messages. Without this behavior, the multiple MUST merge the Path messages. Without this behavior, the multiple
RESV messages received back would not be distinguishable as to RESV messages received back would not be distinguishable as to
which backup path each belongs to. This merging behavior does which backup path each belongs to. This merging behavior does
reduce the total number of RSVP states inside the network at the reduce the total number of RSVP states inside the network at the
expense of merging LSPs with different EROs. expense of merging LSPs with different EROs.
6.2 Procedures for Backup Path Computation 7.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.
Before CSPF computation, the following information should be Before CSPF computation, the following information should 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
skipping to change at page 19, line 47 skipping to change at page 21, line 40
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 message. PATH message.
When applying a CSPF algorithm to compute the backup route, the When applying a CSPF algorithm to compute the backup route, the
following constraints should be satisfied: following constraints should 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 6), 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 setting up one-to-one protection 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 setting up one-to-one protection using the
sender-template-specific method, a detour should not traverse sender-template-specific method, a detour should not traverse
the upstream links of the protected LSP in the same direction; the upstream links of the protected LSP in the same direction;
this prevents sharing the bandwidth between a protected LSP this prevents sharing the bandwidth between a protected LSP
skipping to change at page 20, line 30 skipping to change at page 22, line 24
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 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 may 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 at a later time. retry at a later time.
6.3 Signaling Backups for One-To-One Protection 7.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 locally protect an LSP with one-to-one
backup, and has identified the desired path, it takes the following backup, and has identified the desired path, it takes the following
steps to signal the detour. steps to signal the 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
skipping to change at page 21, line 36 skipping to change at page 23, line 31
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 are regular LSPs in operation. 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 have changed. The PLR may
recompute detour routes at any time. recompute detour routes at any time.
6.3.1 Make-Before-Break with Detour LSPs 7.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 make-before-break with detour LSPs. This is done by using two do make-before-break with detour LSPs. This is done by using two
different IP addresses belonging to the PLR (which were not used in different IP addresses belonging to the PLR (which were not used in
the SENDER_TEMPLATE of the protected LSP). If the current detour the SENDER_TEMPLATE of the protected LSP). If the current detour
LSP uses the first IP address in its SENDER_TEMPLATE, then the new LSP uses the first IP address in its SENDER_TEMPLATE, then the new
detour LSP should be signaled using the second IP address in its detour LSP should be signaled 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 IP addresses, the current and new detour LSPs will have these IP addresses, the current and new detour LSPs will have
different SENDER_TEMPLATES and, thus, different state in the different 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, changing 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 because the PATH messages for new and current detour LSPs
may be merged if they share a common next-hop. may be merged if they share a common next-hop.
6.3.2 Message Handling 7.3.2 Message Handling
LSRs must process the detour LSPs independent of the protected LSPs LSRs must process the detour LSPs independent 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.
skipping to change at page 22, line 32 skipping to change at page 24, line 26
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 similiarly.
6.3.3 Local Reroute of Traffic onto Detour LSP 7.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 the protected LSP's normal out-segment. The goal of this technique
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 | L47 | L44
skipping to change at page 23, line 4 skipping to change at page 24, line 43
L32 L33 L34 L35 L32 L33 L34 L35
R1-------R2-------R3-------R4-------R5 R1-------R2-------R3-------R4-------R5
| | | |
L46 | L47 | L44 L46 | L47 | L44
R6---------------R7 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 above, if the link [R2->R3] fails, then R2 would do
the following. Any traffic received on link [R1->R2] with label the following. Any traffic received on link [R1->R2] with label
L32 would be sent out link [R2->R6] with label L46 (along the L32 would be sent out link [R2->R6] with label L46 (along the
detour LSP) instead of out link [R3->R4] with lable L34 (along the detour LSP) instead of out link [R3->R4] with lable L34 (along the
protected LSP). The Merge Point, R4, would recognize that packets protected LSP). The Merge Point, R4, would recognize that packets
received on link [R7->R4] with label L44 should be sent out link received on link [R7->R4] with label L44 should be sent out link
[R4->R5] with label L35, and thus merged with the protected LSP. [R4->R5] with label L35, and thus merged with the protected LSP.
6.4 Signaling for Facility Protection 7.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
setup in advance or may be dynamically created as new protected setup in advance or may be dynamically created as new protected
LSPs are signaled. LSPs are signaled.
6.4.1. Discovering Downstream Labels 7.4.1. Discovering Downstream Labels
To support facility backup, it is necessary for the PLR to To support facility backup, it is necessary for the PLR to
determine a label which will indicate to the MP that packets determine a label which will indicate to the MP that packets
received with that label should be switched along the protected received with that label should be switched along the protected
LSP. This can be done without explicitly signaling the backup path LSP. This can be done without explicitly signaling the backup path
if the MP uses a label space global to that LSR. if the MP uses a label space global to that LSR.
As described in Section 5, 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 flag if the label is global to the LSR. Thus, when a protected a flag if 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 all downstream nodes for this LSP. by 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 6.4.3 below. Section 7.4.3 below.
6.4.2. Procedures for the PLR before Local Repair 7.4.2. Procedures for the PLR before Local Repair
A PLR which determines to use facility-backup to protect a given A PLR which determines to use facility-backup to protect a given
LSP should select a bypass tunnel to use taking into account LSP should select a bypass tunnel to use taking into account
whether node protection is to be provided, what bandwidth was whether node protection is to be provided, what bandwidth was
requested and whether a bandwidth guarantee is desired, and what requested and whether a bandwidth guarantee is desired, and what
link attribute filters were specified in the FAST_REROUTE object. link attribute filters were specified in the FAST_REROUTE object.
The selection of a bypass tunnel for a protected LSP is performed The selection of a bypass tunnel for a protected LSP is performed
by the PLR when the LSP is first setup. by the PLR when the LSP is first setup.
6.4.3. Procedures for the PLR during Local Repair 7.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 needs
to reroute the data traffic onto the bypass tunnel and to start to reroute the data traffic onto the bypass tunnel and to start
sending the control traffic for the protected LSP onto the bypass sending 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 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 6.3. Section 7.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 "Local protection desired", "Bandwidth protection desired", The "Local protection desired", "Bandwidth protection desired",
and "Node protection desired" flags SHOULD be cleared. and "Node protection desired" flags SHOULD be cleared.
The "Label recording desired" MAY be modified. The "Label 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 to the PLR. Consequently, the MP will send messages belonging to the PLR. Consequently, the MP will send messages
back to the PLR using as a destination that IP address. back to the PLR using as a destination that IP address.
- 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 need to be updated, as described in Section
6.5. 7.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
directly addressing them to the address in the RSVP_HOP object directly addressing them to the address in the RSVP_HOP object
contents as specified in [RSVP]. contents as specified in [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 the MP label to use, then the same Path message is sent. determine the MP label to use, then the same Path message is sent.
In this case, the PLR SHOULD continue to send Path messages for the In this case, the PLR SHOULD continue to send Path messages for the
protected LSP along the normal route. PathTear messages should be protected LSP along the normal route. PathTear messages should be
duplicated, with one sent along the normal route and one sent thru duplicated, with one sent along the normal route and one sent thru
the bypass tunnel. The MP should duplicate the Resv and ResvTear the bypass tunnel. The MP should duplicate the Resv and ResvTear
messages and sent them to both the PLR and the LSR indicated by the messages and sent them to both the PLR and the LSR indicated by the
protected LSP's RSVP_HOP object. protected LSP's RSVP_HOP object.
6.4.4. Processing backup tunnel's ERO 7.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 which 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 Backup Tunnel), or of an interface which 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 invoke the following ERO procedures before sending a
skipping to change at page 25, line 30 skipping to change at page 27, line 22
sub-object identifying the Backup Tunnel destination is then added. 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 belonging
to the MP. to the MP.
- 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.)
6.5. PLR Procedures During Local Repair 7.5. PLR Procedures During Local Repair
In addition to the technique specific signaling and packet In addition to the technique specific signaling and packet
treatment, there is common signaling which should be followed. treatment, there is common signaling which should be followed.
During fast reroute, for each protected LSP containing an RRO During fast reroute, for each protected LSP containing an RRO
object, the PLR obtains the RRO from the protected LSP's stored object, the PLR obtains the RRO from the protected LSP's stored
RESV. The PLR MUST update the IPv4 or IPv6 sub-object it inserted RESV. The PLR MUST update the IPv4 or IPv6 sub-object it inserted
into the RRO by setting the "Local protection in use" and "Local into the RRO by setting the "Local protection in use" and "Local
Protection Available" flags. Protection Available" flags.
6.5.1. Notification of local repair 7.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 a 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 needs to know of the failure so it may re-signal an LSP
which is optimal. which is optimal.
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 also detect that an LSP needs to be moved
to a more optimal path by noticing failures reported via the IGP. to a more optimal path by noticing failures reported via the IGP.
Note that in the case of inter-area TE LSP (TE LSP spanning areas), Note that in the case of inter-area TE LSP (TE LSP spanning areas),
the head-end LSR will need to rely exclusively on Path Error messages the head-end LSR will need to rely exclusively on Path Error messages
to be informed of failures in another area. to be informed of failures in another area.
6.5.2 Revertive Behavior 7.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
skipping to change at page 27, line 30 skipping to change at page 29, line 23
and/or IGP indications in order to make a timely response. and/or IGP indications in order 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 would fail as the MP will not send
any Resv message. The PLR will still refresh the TE LSP over the any Resv message. The PLR will still refresh the TE LSP over the
backup tunnel. The TE LSP will not revert to the restored resource; backup 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.
7. Merge Node Behavior 8. 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 which is
merged into that protected LSP. In the one-to-one backup merged into that protected LSP. In the one-to-one backup
technique, the LSR is aware that it is a merge node prior to technique, the LSR is aware that it is a merge node prior to
failure. In the facility backup technique, the LSR may not know failure. In the facility backup technique, the LSR may not know
that it is a Merge Point until a failure occurs and it receives a that it is a Merge Point until a failure occurs and it receives a
backup LSP's Path message. Therefore, an LSR which is on the path backup LSP's Path message. Therefore, an LSR which is on the path
of a protected LSP SHOULD always assume that it is a merge point. of a protected LSP SHOULD 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 thru 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 expected behavior. is expected behavior.
7.1. Handling Backup Path Messages Before Failure 8.1. Handling Backup Path Messages Before Failure
There are two circumstances where a Merge Point will receive Path There are two circumstances where 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 PLR is providing local protection via the one-to-one backup a PLR is providing local protection via the one-to-one backup
technique, the detour will be signaled and must be properly handled technique, the detour will be signaled and must be properly handled
by the MP. In this case, the backup LSP may be signaled via the by the MP. In this case, the backup LSP may be signaled via the
sender-template-specific method or via the path-specific method. sender-template-specific method or via the path-specific method.
In the second case, if the Merge Point does not provide labels In the second case, if the Merge Point does not provide labels
global to the MP and record them in a Label sub-object of the RRO global to the MP and record them in a Label sub-object of the RRO
or if the PLR does not use such recorded information, the PLR may or if the PLR does not use such recorded information, the PLR may
signal the backup path, as described above in Section 6.4.1, to signal the backup path, as described above in Section 7.4.1, to
determine the label to use if the PLR is providing protection determine the label to use if the PLR is providing protection
according to the facility backup technique. In this case, the according to the facility backup technique. In this case, the
backup LSP is signaled via the sender-template-specific method. backup LSP is signaled via the sender-template-specific method.
The reception of a backup LSP's path message does not indicate that The reception of a backup LSP's path message does not indicate that
a failure has occured and the incoming protected LSP will no longer a failure has occured and the incoming protected LSP will no longer
be used. be used.
7.1.1. Merginging Backup Paths using the Sender-Template Specific Method 8.1.1. Merginging Backup Paths using the Sender-Template Specific Method
An LSR may receive multiple Path messages for one or more backup An LSR may receive multiple Path messages for one or more backup
LSPs and, possibly, the protected LSP. Each of these Path messages LSPs and, possibly, 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 either include the FAST_REROUTE object,
have the "local protection desired" flag set in the have the "local protection desired" flag set in the
SESSION_ATTRIBUTE object or both. SESSION_ATTRIBUTE 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. Similar to that specified
skipping to change at page 28, line 42 skipping to change at page 30, line 35
whose ERO from that LSR to the egress is the same can be merged. whose ERO from that LSR to the egress is the same can be merged.
If merging occurs and one of the Path messages merged was for the If merging occurs and one of the Path messages merged was for the
protected LSP, then the final Path message to be sent MUST be that protected LSP, then the final Path message to be sent MUST be that
of the protected LSP. This merges the backup LSPs into the 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 8.1 Section 9.1
7.1.2. Merging Detours using the Path-Specific Method 8.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 the following: The merging rule is the following:
For all Path messages that do not have either a FAST_REROUTE or a For all Path messages that do not have either a FAST_REROUTE or a
DETOUR object, or the MP is the egress of the LSP, no merging is DETOUR object, or the MP is the egress of the LSP, no merging is
required. The messages are processed according to [RSVP-TE]. required. The messages are processed according to [RSVP-TE].
skipping to change at page 30, line 5 skipping to change at page 31, line 45
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 reservation on the outgoing link, any
merging should be considered to have occured before bandwidth is merging should be considered to have occured before bandwidth is
reserved. Thus, even though Fixed Filter is specified, multiple reserved. Thus, even though Fixed Filter is specified, multiple
detours and/or their protected LSP which are to be merged due to detours and/or their protected LSP which are to be merged due to
sharing an outgoing interface and next-hop LSR will reserve only sharing an outgoing interface and next-hop LSR will reserve only
the bandwidth of the final Path message on that outgoing the bandwidth of the final Path message on that outgoing
interface. interface.
7.1.2.1. An Example on Path Message Merging 8.1.2.1. An Example on 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 above, R8 will receive Path messages that have the
same SESSION and SENDER_TEMPLATE from detours for R2 and R3. same SESSION and SENDER_TEMPLATE from detours for R2 and R3.
During merging at R8 since detour R3 has a shorter ERO path length During merging at R8 since detour R3 has a shorter ERO path length
(that is, ERO is [R9->R5->R6], and path length is 3), R8 will (that is, ERO is [R9->R5->R6], and path length is 3), R8 will
skipping to change at page 30, line 29 skipping to change at page 32, line 22
During merging at R8 since detour R3 has a shorter ERO path length During merging at R8 since detour R3 has a shorter ERO path length
(that is, ERO is [R9->R5->R6], and path length is 3), R8 will (that is, ERO is [R9->R5->R6], and path length is 3), R8 will
select it as the final LSP, and only propagate its Path messages select it as the final LSP, and only propagate its Path messages
downstream. Upon receiving a Resv (or a ResvTear) message, R8 must downstream. Upon receiving a Resv (or a ResvTear) message, R8 must
relay on the messages toward both R2 and R3. relay on the messages toward both R2 and R3.
R5 needs to merge as well, and will select the main LSP, since it R5 needs to merge as well, and 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.
7.1.3. Message Handling for Merged Detours 8.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 propogate 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 propogated 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, the fact that one or more of the merged LSPs has been torn However, the fact that one or more of the merged LSPs has been torn
down should be reflected in the downstream message, such as by down should be reflected in the downstream message, such as by
changing the DETOUR object, if any. changing the DETOUR object, if any.
7.2. Handling Failures 8.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 LSPs routed over the failed link, Path and Resv state protected LSPs routed over the failed link, Path and Resv state
MUST NOT be cleared and PathTear and ResvErr messages MUST NOT be MUST NOT be cleared and PathTear and ResvErr messages MUST NOT be
sent immediately; if this is not the case, then the facility backup sent immediately; if this is not the case, then the facility backup
technique will not work. Further a downstream LSR SHOULD reset the technique will not work. Further 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
skipping to change at page 31, line 24 skipping to change at page 33, line 18
After a failure has occured, the MP must still send Resv messages After a failure has occured, 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 which 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 PHOP object in its Path message will have the IP address of the 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 messages for existing protected LSPs which had failed over to Path messages for existing protected LSPs which had failed over to
their backup. their backup.
8. Behavior of all LSRs 9. Behavior of all LSRs
The objects defined and the techniques defined in this document The objects defined and the techniques defined in this document
require behavior from all LSRs in the traffic-engineered network, require behavior from all LSRs in the traffic-engineered network,
even if that LSR is not along the path of a protected LSP. even if that LSR is 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-to-one backup technique, it is necessary that the LSRs in the one-to-one backup technique, it is necessary that the LSRs in
the traffic-engineered network be capable of merging detours as the traffic-engineered network be capable of merging detours as
specified below in Section 8.1. specified below in Section 9.1.
It is possible to avoid specific LSRs which do not support this It is possible to avoid specific LSRs which do not support this
behavior by assigning an link attribute to all the links of those behavior by assigning an link attribute to all the links of those
LSPs and then requesting that backup paths exclude that link LSPs and then requesting that backup paths exclude that link
attribute. attribute.
8.1. Merging Detours in Path-Specific Method 9.1. Merging Detours in Path-Specific Method
If multiple Path Messages for different detours are received with If multiple Path Messages for different detours are received with
the same SESSION, SENDER_TEMPLATE, outgoing interface and next-hop the same SESSION, SENDER_TEMPLATE, outgoing interface and next-hop
LSR, then the LSR must function as a Detour Merge Point and merge LSR, then the LSR must function as a Detour Merge Point and merge
the detour Path Messages. This merging should occur as specified the detour Path Messages. This merging should occur as specified
in Section 7.1.2 and shown in Example 4. in Section 8.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 which has taken place. This is done using the
following algorithm to format the outgoing DETOUR object for the following 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 objects of all merged LSPs, and create a new object with DETOUR objects of all merged LSPs, and create a new object with
all listed. Ordering is insignificant. all listed. Ordering is insignificant.
9. Security Considerations 10. 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 It should be noted that the facility backup technique requires that
a PLR and its selected Merge Point will trust RSVP messages a PLR and its selected Merge Point will trust RSVP messages
received from each other. received from each other.
10. IANA Guidelines 11. IANA Section
IANA [RFC-IANA] will assign RSVP C-class numbers for FAST_ROUTE and IANA [RFC-IANA] will assign RSVP Class-Num 205 for the
DETOUR objects. Currently, in production networks, FAST_REROUTE uses FAST_REROUTE and RSVP Class-Num 63 for the DETOUR object. This
C-class 205, and DETOUR uses C-class 63. matches the current usage in production networks.
11. Intellectual Property Considerations IANA will assign C-Type 1 for the standard FAST_REROUTE object
format defined in section 5.1 and list C-Type 7 as reserved as it
is still used by pre-standard implementations.
Cisco Systems and Juniper Networks may have intellectual property IANA will assign C-Types 7 and 8 to the IPv4 and IPv6 DETOUR
rights claimed in regard to some of the specification contained in object formats as defined in section 5.2.
this document
12. Full Copyright Statement 12. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any
intellectual property 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; 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
claimed in regard to some or all of the specification contained
in this document. For more information consult the online list
of claimed rights.
13. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
skipping to change at page 33, line 21 skipping to change at page 35, line 34
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
13. Acknowledgments 14. 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 thank those, who have been involved in interoperability testing we thank those, who have been involved in interoperability testing
and field trails, and provided invaluable ideas and suggestions. and field trails, and provided invaluable ideas and suggestions.
They are Rob Goguen, Carol Iturralde, Brook Bailey, Safaa Hasan, They are Rob Goguen, Carol Iturralde, Brook Bailey, Safaa Hasan,
Richard Southern, and Bijan Jabbari. Richard Southern, and Bijan Jabbari.
14. Normative References 15. Normative References
[RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP) [RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP)
-- version 1 functional specification," RFC2205, September 1997. -- version 1 functional specification," RFC2205, September 1997.
[RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP [RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP
tunnels", RFC3029, December 2001. tunnels", RFC3029, 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", RFC 2119, March 1997.
[RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an [RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434. IANA Considerations Section in RFCs", RFC 2434.
15. Author Information 16. Editor Information
Ping Pan
CIENA Corp.
10480 Ridgeview Court
Cupertino, CA 95014
e-mail: ppan@ciena.net
phone: +1 408 366 4991
Der-Hwa Gan
Juniper Networks
1194 N.Mathilda Ave
Sunnyvale, CA 94089
e-mail: dhg@juniper.net
phone: +1 408 745 2074
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
250 Apollo Drive 300 Beaver Brook Road
Chelmsford, MA 01824 Boxborough, MA 01719
USA
email: swallow@cisco.com email: swallow@cisco.com
phone: +1 978 244 8143 phone: +1 978 244 8143
Jean Philippe Vasseur Ping Pan
Cisco Systems, Inc. CIENA Corp.
300 Apollo Drive 5965 Silver Creek Valley Road
Chelmsford, MA 01824 San Jose, CA 95138
email: jpv@cisco.com USA
phone: +1 978 497 6238 e-mail: ppan@ciena.net
phone: +1 408 965 2707
Dave Cooper
Global Crossing
960 Hamlin Court
Sunnyvale, CA 94089
email: dcooper@gblx.net
phone: +1 916 415 0437
Alia Atlas Alia Atlas
Avici Systems Avici Systems
101 Billerica Avenue 101 Billerica Avenue
N. Billerica, MA 01862 N. Billerica, MA 01862
USA
email: aatlas@avici.com email: aatlas@avici.com
phone: +1 978 964 2070 phone: +1 978 964 2070
Markus Jork
Avici Systems
101 Billerica Avenue
N. Billerica, MA 01862
email: mjork@avici.com
phone: +1 978 964 2142
 End of changes. 

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