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