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).
AbstractThis 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.
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
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.
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. 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.
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.
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.
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].
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. 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.
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.
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.
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.
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.
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. 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.
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. 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
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.
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.
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.
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.
There are two different methods to uniquely identify a backup path, described below. RSVP-TE].
Section 7), the destination MUST be the address of the MP.
- 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.
- 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.
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. 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.
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. 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.
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.
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.)
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.
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.
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. 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 RSVP-TE].
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.
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. 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. 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:
- 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. 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. RFC-IANA] has assigned the following RSVP Class Numbers for objects defined in this document. ENT]) in network byte order.
ENT]) in network byte order.
[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
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- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.