idnits 2.17.1 draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1492 has weird spacing: '...for the purpo...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: - When setting up one-to-one protection 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 setting up one-to-one protection 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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 similiarly. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'R4-R5' is mentioned on line 295, but not defined == Missing Reference: 'R8' is mentioned on line 315, but not defined == Missing Reference: 'R6' is mentioned on line 319, but not defined == Missing Reference: 'R7' is mentioned on line 319, but not defined == Missing Reference: 'R9' is mentioned on line 319, but not defined == Missing Reference: 'R3' is mentioned on line 329, but not defined == Missing Reference: 'RSVP- TE' is mentioned on line 1053, but not defined ** Downref: Normative reference to an Experimental RFC: RFC 3029 (ref. 'RSVP-TE') ** Obsolete normative reference: RFC 2434 (ref. 'RFC-IANA') (Obsoleted by RFC 5226) Summary: 6 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Ping Pan, Ed (Ciena Corp) 3 Expires: Dec 2003 Der-Hwa Gan (Juniper Networks) 4 George Swallow (Cisco Systems) 5 Jean Philippe Vasseur (Cisco Systems) 6 Dave Cooper (Global Crossing) 7 Alia Atlas, Ed (Avici Systems) 8 Markus Jork (Avici Systems) 10 Fast Reroute Extensions to RSVP-TE for LSP Tunnels 12 draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document defines extensions to and describes the use of RSVP to 38 establish backup label-switched path (LSP) tunnels for local repair 39 of LSP tunnels. These mechanisms enable the re-direction of traffic 40 onto backup LSP tunnels in 10s of milliseconds in the event of a 41 failure. 43 Two methods are defined here. The one-to-one backup method creates 44 detour LSPs for each protected LSP at each potential point of local 45 repair. The facility backup method creates a bypass tunnel to 46 protect a potential failure point; by taking advantage of MPLS label 47 stacking, this bypass tunnel can protect a set of protected LSPs that 48 have similar backup constraints. Both methods can be used to protect 49 links and nodes during network failure. The described behavior and 50 extensions to RSVP allow nodes to implement either or both methods 51 and to interoperate in a mixed network. 53 0. Background 55 Several years before work began on this draft, operational networks 56 had deployed two independent methods of doing fast reroute, called 57 herein one-to-one backup and facility backup. Vendors trying to 58 support both methods were experiencing incompatiblity problems in 59 attempting to produce a single implementation capable of 60 interoperating with both. There are technical tradeoffs between 61 the methods. However these tradeoffs are so topologically 62 dependent, that the community has not converged on a single 63 approach. 65 This draft rationalizes the RSVP signaling for both methods such 66 that any implementation can recognize all FRR requests and clearly 67 respond, either positively if they are capable of performing the 68 method, or with a clear error such that requester is informed and 69 can seek alternate means of backup. This draft also allows a 70 single implementation to support both methods, thereby providing a 71 range of capabilities. Thus the described behavior and extensions 72 to RSVP allow LERs and LSRs to implement either or both methods. 74 While the two methods could in principle be used in a single 75 network, it is expected that operators will continue to choose to 76 deploy either one or the other. The goal of this draft is to 77 standardize the RSVP signaling such that either a network with LSRs 78 that implement both methods or an network composed of some LSRs 79 that support one method and others that support both, can properly 80 signal among those LSRs to achieve fast restoration through the 81 chosen method. 83 Contents 85 1 Introduction ............................................. 4 86 2 Terminology ............................................... 4 87 3 Local Repair Techniques ................................... 6 88 3.1 One-to-one Backup .................................... 6 89 3.2 Facility Backup ...................................... 7 90 4 RSVP Extensions ........................................... 8 91 4.1 FAST_REROUTE Object .................................... 8 92 4.2 DETOUR Object .......................................... 11 93 4.3 SESSION_ATTRIBUTE Flags ................................ 12 94 4.4 RRO IPv4/IPv6 Sub-Object Flags ......................... 13 95 5 Head-End Behavior ......................................... 14 96 6 Point of Local Repair Behavior ............................ 15 97 6.1 Signaling a Backup Path ................................ 16 98 6.1.1 Backup Path Identification: Sender-Template Specific . 17 99 6.1.2 Backup Path Identification: Path-Specific ........... 18 100 6.2 Procedures for Backup Path Computation ................. 18 101 6.3 Signaling Backups for One-To-One Protection ............ 20 102 6.3.1 Make-Before-Break with Detour LSPs .................. 21 103 6.3.2 Message Handling .................................... 21 104 6.3.3 Local Reroute of Traffic Onto Detour LSP ............ 22 105 6.4 Signaling for Facility Protection ...................... 23 106 6.4.1 Discovering Downstream Labels ....................... 23 107 6.4.2 Procedures for the PLR before Local Repair .......... 23 108 6.4.3 Procedures for the PLR during Local Repair .......... 23 109 6.4.4 Processing backup tunnel's ERO ...................... 24 110 6.5 PLR Procedures During Local Repair ..................... 25 111 6.5.1 Notification of local repair ........................ 25 112 6.5.2 Revertive Behavior .................................. 26 113 7 Merge Node Behavior ....................................... 27 114 7.1 Handling Backup Path Messages Before Failure ........... 27 115 7.1.1 Merging Backup Paths using the Sender-Template 116 Specific Method ..................................... 28 117 7.1.2 Merging Detours using Path-Specific Method .......... 28 118 7.1.2.1 An Example on Path Message Merging ............... 29 119 7.1.3 Message Handling for Merged Detours ................. 30 120 7.2 Handling Failures ...................................... 30 121 8 Behavior of all LSRs ...................................... 31 122 8.1 Merging Detours in Path-Specific Method ................ 31 123 9 Security Considerations ................................... 32 124 10 IANA Guidelines ........................................... 32 125 11 Intellectual Property Considerations ...................... 32 126 12 Full Copyright Statement .................................. 32 127 13 Acknowledgments ........................................... 33 128 14 Normative References ...................................... 33 129 15 Author Information ........................................ 33 131 1. Introduction 133 This document extends RSVP [RSVP] to establish backup LSP tunnels 134 for the local repair of LSP tunnels. This technique is presented 135 to meet the needs of real-time applications, such as voice over IP, 136 for which it is highly desirable to be able to re-direct user 137 traffic onto backup LSP tunnels in 10s of milliseconds. This 138 timing requirement can be satisfied by computing and signaling 139 backup LSP tunnels in advance of failure and by re-directing 140 traffic as close to failure point as possible. In this way, the 141 time for the redirection does not include any path computation or 142 signaling delays, including delays to propagate failure 143 notification between LSRs. The speed of repair made possible by 144 the techniques and extensions described herein is the primary 145 advantage of this method. We use the term local repair when 146 referring to techniques which accomplish this, and refer to an 147 explicitly routed LSP which is provided with such protection as a 148 protected LSP. These techniques are applicable only to explicitly 149 routed LSPs; Application of the techniques discussed herein to LSPs 150 which dynamically change their routes such as those used in unicast 151 IGP routing is beyond the scope of this document. 153 Section 2 covers new terminology used in this document. The two 154 basic strategies for creating backup LSPs are described in Section 155 3. In Section 4, the protocol extensions to RSVP to support local 156 protection are described. In Section 5, the behavior of an LER 157 which wishes to request local protection for an LSP is presented. 158 The behavior of a potential point of local repair (PLR) is given in 159 Section 6; this describes how to determine the appropriate strategy 160 to use for protecting an LSP and how to implement each of the 161 strategies. The behavior of a merge node, the LSR where a 162 protected LSP and its backup LSP rejoin, is described in Section 7. 163 Finally, the required behavior of other nodes in the network is 164 discussed in Section 8. 166 For the techniques discussed in this document to function properly, 167 there are three assumptions which must be made. First, an LSR 168 which is on the path of a protected LSP SHOULD always assume that 169 it is a merge point; this is necessary because the facility backup 170 method does not signal backups through a bypass tunnel before 171 failure. Second, if the one-to-one backup method is used and a 172 DETOUR object is included, the LSRs in the traffic-engineered 173 network should support the DETOUR object; this is necessary so that 174 the Path message containing the DETOUR object is not rejected. 175 Third, understanding of the DETOUR object is required to support 176 the path-specific method which requires that LSRs in the 177 traffic-engineered network be capable of merging detours. 179 2. Terminology 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in RFC2119 [RFC-WORDS]. 185 The reader is assumed to be familiar with the terminology in [RSVP] 186 and [RSVP-TE]. 188 LSR - Label Switch Router 190 LSP - An MPLS Label Switched Path. In this document, an LSP 191 will always refer to an explicitly routed LSP. 193 Local Repair - Techniques used to repair LSP tunnels quickly 194 when a node or link along the LSPs path fails. 196 PLR - Point of Local Repair. The head-end LSR of a backup tunnel 197 or a detour LSP. 199 One-to-one Backup - A local repair technique where a backup LSP 200 is separately created for each protected LSP at a PLR. 202 Facility Backup - A local repair technique where a bypass tunnel 203 is used to protect one or more protected LSPs which 204 traverse the PLR, the resource being protected and the 205 Merge Point in that order. 207 Protected LSP - An LSP is said to be protected at a given hop if 208 it has one or multiple associated backup tunnels originating 209 at that hop. 211 Detour LSP - The LSP that is used to re-route traffic around 212 a failure in one-to-one backup. 214 Bypass Tunnel - An LSP that is used to protect a set of LSPs 215 passing over a common facility. 217 Backup Tunnel - The LSP that is used to backup up one of the many 218 LSPs in many-to-one backup. 220 NHOP Bypass Tunnel - Next-Hop Bypass Tunnel. A backup tunnel 221 which bypasses a single link of the protected LSP. 223 NNHOP Bypass Tunnel - Next-Next-Hop Bypass Tunnel. A backup 224 tunnel which bypasses a single node of the protected LSP. 226 Backup Path - The LSP that is responsible for backing up one 227 protection LSP. A backup path refers to either a detour LSP 228 or a backup tunnel. 230 MP - Merge Point. The LSR where one or more backup tunnels rejoin 231 the path of the protected LSP, downstream of the potential 232 failure. The same LSR may be both an MP and a PLR 233 simultaneously. 235 DMP - Detour Merge Point. In the case of one-to-one backup, 236 this is an LSR where multiple detours converge and only one 237 detour is signaled beyond that LSR. 239 Reroutable LSP - Any LSP for which the head-end LSR requests 240 local protection. See Section 9.1 for more detail. 242 CSPF - Constraint-based Shortest Path First. 244 SRLG Disjoint - A path is considered to be SRLG disjoint from a 245 given link or node if the path does not use any links or 246 nodes which belong to the same SRLG as that given link or 247 node. 249 3. Local Repair Techniques 251 Two different techniques for local protection are presented here. 252 The one-to-one backup technique has a PLR compute a separate backup 253 LSP, called a detour LSP, for each LSP which the PLR protects using 254 this technique. With the facility backup technique, the PLR creates 255 a single bypass tunnel which can be used to protect multiple LSPs. 257 3.1. One-to-one backup 259 In the one-to-one technique, a label switched path is established 260 which intersects the original LSP somewhere downstream of the point 261 of link or node failure. For each LSP which is backed up, a 262 separate backup LSP is established. 264 [R1]---[R2]-----[R3]----[R4]---[R5] 265 \ \ \ / \ / 266 [R6]---[R7]-------[R8]----[R9] 268 Protected LSP: [R1->R2->R3->R4->R5] 269 R1's Backup: [R1->R6->R7->R8->R3] 270 R2's Backup: [R2->R7->R8->R4] 271 R3's Backup: [R3->R8->R9->R5] 272 R4's Backup: [R4->R9->R5] 273 Example 1: One-to-One Backup Technique 275 In the simple topology shown above in Example 1, the protected LSP 276 runs from R1 to R5. R2 can provide user traffic protection by 277 creating a partial backup LSP which merges with the protected LSP 278 at R4. We refer to a partial one-to-one backup LSP 279 [R2->R7->R8->R4] as a detour. 281 To fully protect an LSP that traverses N nodes, there could be as 282 many as (N - 1) detours. The paths for the detours necessary to 283 fully protect the LSP in Example 1 are given there. To minimize 284 the number of LSPs in the network, it is desirable to merge a 285 detour back to its protected LSP when feasible. When a detour LSP 286 intersects its protected LSP at an LSR with the same outgoing 287 interface, it will be merged. 289 When a failure occurs along the protected LSP, the PLR redirects 290 traffic onto the local detour. For instance, if the link [R2->R3] 291 fails in Example 1, R2 will switch traffic received from R1 onto 292 the protected LSP along link [R2->R7] using the label received when 293 R2 created the detour. When R4 receives traffic with the label 294 provided for R2's detour, R4 will switch that traffic onto link 295 [R4-R5] using the label received from R5 for the protected LSP. At 296 no point does the depth of the label stack increase as a result of 297 taking the detour. While R2 is using its detour, traffic will take 298 the path [R1->R2->R7->R8->R4->R5]. 300 3.2. Facility backup 302 The facility backup technique takes advantage of the MPLS label 303 stack. Instead of creating a separate LSP for every backed-up LSP, a 304 single LSP is created which serves to backup up a set of LSPs. We 305 call such an LSP tunnel a bypass tunnel. 307 The bypass tunnel must intersect the path of the original LSP(s) 308 somewhere downstream of the PLR. Naturally, this constrains the 309 set of LSPs being backed-up via that bypass tunnel to those that 310 pass through some common downstream node. All LSPs which pass 311 through the point of local repair and through this common node 312 which do not also use the facilities involved in the bypass tunnel 313 are candidates for this set of LSPs. 315 [R8] 316 \ 317 [R1]---[R2]----[R3]----[R4]---[R5] 318 \ / \ 319 [R6]===[R7] [R9] 321 Protected LSP 1: [R1->R2->R3->R4->R5] 322 Protected LSP 2: [R8->R2->R3->R4] 323 Protected LSP 3: [R2->R3->R4->R9] 324 Bypass LSP Tunnel: [R2->R6->R7->R4] 326 Example 2: Facility Backup Technique 328 In Example 2, R2 has built a bypass tunnel which protects against 329 the failure of link [R2->R3], link [R3->R4] or node [R3]. The 330 doubled lines represent this tunnel. The scalability improvement 331 this technique provides is that the same bypass tunnel can also be 332 used to protect LSPs from any of R1, R2 or R8 to any of R4, R5 or 333 R9. Example 2 describes three different protected LSPs which are 334 using the same bypass tunnel for protection. 336 As with the one-to-one technique, to fully protect an LSP that 337 traverses N nodes, there could be as many as (N-1) bypass tunnels. 338 However, each of those bypass tunnels could protected a set of 339 LSPs. 341 When a failure occurs along a protected LSP, the PLR redirects 342 traffic into the appropriate bypass tunnel. For instance, if link 343 [R2->R3] fails in Example 2, R2 will switch traffic received from 344 R1 on the protected LSP onto link [R2->R6]; the label will be 345 switched for one which will be understood by R4 to indicate the 346 protected LSP and then the bypass tunnel's label will be pushed 347 onto the label-stack of the redirected packets. If 348 penultimate-hop-popping is used, then the merge point in Example 2, 349 R4, will receive the redirected packet with a label indicating the 350 protected LSP that the packet is to follow. If 351 penultimate-hop-popping is not used, then R4 will pop the bypass 352 tunnel's label and examine the label underneath to determine the 353 protected LSP that the packet is to follow. When R2 is using the 354 bypass tunnel for protected LSP 1, the traffic takes the path 355 [R1->R2->R6->R7->R4->R5]; the bypass tunnel is the connection 356 between R2 and R4. 358 4. RSVP Extensions 360 We propose two additional objects, FAST_REROUTE and DETOUR, to 361 extend RSVP-TE for fast-reroute signaling. These new objects are 362 backward compatible with LSRs that do not recognize them (see 363 section 3.10 in [RSVP]). Both objects can only be carried in RSVP 364 Path messages. 366 The SESSION_ATTRIBUTE and RECORD_ROUTE objects are also extended to 367 support bandwidth and node protection features. 369 4.1. FAST_REROUTE Object 371 The FAST-REROUTE object is used to control the backup used for the 372 protected LSP. This specifies the setup and hold priorities, the 373 session attribute filters, and bandwidth to be used for protection. 374 It also allows a specific local protection technique to be requested. 375 This object MUST only be inserted into the PATH message by the 376 head-end LER and MUST NOT be changed by downstream LSRs. The 377 FAST-REROUTE object has the following format: 379 Class = TBD (use form 11bbbbbb for compatibility) 380 C-Type = 1 382 0 1 2 3 383 +-------------+-------------+-------------+-------------+ 384 | Length (bytes) | Class-Num | C-Type | 385 +-------------+-------------+-------------+-------------+ 386 | Setup Prio | Hold Prio | Hop-limit | Flags | 387 +-------------+-------------+-------------+-------------+ 388 | Bandwidth | 389 +-------------+-------------+-------------+-------------+ 390 | Include-any | 391 +-------------+-------------+-------------+-------------+ 392 | Exclude-any | 393 +-------------+-------------+-------------+-------------+ 394 | Include-all | 395 +-------------+-------------+-------------+-------------+ 397 Setup Priority 399 The priority of the backup path with respect to taking 400 resources, in the range of 0 to 7. The value 0 is the highest 401 priority. Setup Priority is used in deciding whether 402 this session can preempt another session. See [RSVP-TE] for 403 the usage on priority. 405 Holding Priority 407 The priority of the backup path with respect to holding 408 resources, in the range of 0 to 7. The value 0 is the highest 409 priority. Holding Priority is used in deciding whether this 410 session can be preempted by another session. See [RSVP-TE] for 411 the usage on priority. 413 Hop-limit 415 The maximum number of extra hops the backup path is allowed 416 to take, from current node (a PLR) to a MP, with PLR and MP 417 excluded in counting. For example, hop-limit of 0 means only 418 direct links between PLR and MP can be considered. 420 Flags 422 0x01 One-to-one Backup Desired 424 Indicates that protection via the one-to-one backup 425 technique is desired. 427 0x02 Facility Backup Desired 429 Indicates that protection via the facility backup 430 technique is desired. 432 Bandwidth 434 Bandwidth estimate (32-bit IEEE floating point integer) in 435 bytes-per-second. 437 Exclude-any 439 A 32-bit vector representing a set of attribute filters 440 associated with a backup path any of which renders a link 441 unacceptable. 443 Include-any 445 A 32-bit vector representing a set of attribute filters 446 associated with a backup path any of which renders a link 447 acceptable (with respect to this test). A null set (all bits 448 set to zero) automatically passes. 450 Include-all 452 A 32-bit vector representing a set of attribute filters 453 associated with a backup path all of which must be present for 454 a link to be acceptable (with respect to this test). A null set 455 (all bits set to zero) automatically passes. 457 The two high-order bits of the Class-Num (11) indicate that nodes 458 that do not understand the object should ignore it and pass if 459 forward unchanged. 461 For informational purposes, a different C-type value and format for 462 the FAST_REROUTE object are specified below. This is used by 463 existing implementations. The meaning of the fields is the same as 464 described for C-Type 1. 466 C-Type = 7 468 0 1 2 3 469 +-------------+-------------+-------------+-------------+ 470 | Length (bytes) | Class-Num | C-Type | 471 +-------------+-------------+-------------+-------------+ 472 | Setup Prio | Hold Prio | Hop-limit | Reserved | 473 +-------------+-------------+-------------+-------------+ 474 | Bandwidth | 475 +-------------+-------------+-------------+-------------+ 476 | Include-any | 477 +-------------+-------------+-------------+-------------+ 478 | Exclude-any | 479 +-------------+-------------+-------------+-------------+ 481 4.2. DETOUR Object 483 The DETOUR object is used in one-to-one backup to identify detour 484 LSPs. It has the following format: 486 Class = TBD (to conform 0bbbbbbb format for compatibility) 487 C-Type = 7 489 0 1 2 3 490 +-------------+-------------+-------------+-------------+ 491 | Length (bytes) | Class-Num | C-Type | 492 +-------------+-------------+-------------+-------------+ 493 | PLR ID 1 | 494 +-------------+-------------+-------------+-------------+ 495 | Avoid Node ID 1 | 496 +-------------+-------------+-------------+-------------+ 497 // .... // 498 +-------------+-------------+-------------+-------------+ 499 | PLR ID n | 500 +-------------+-------------+-------------+-------------+ 501 | Avoid Node ID n | 502 +-------------+-------------+-------------+-------------+ 504 PLR ID (1 - n) 506 IPv4 address identifying the beginning point of detour which 507 is a PLR. Any local address on the PLR can be used. 509 Avoid Node ID (1 - n) 511 IP address identifying the immediate downstream node that 512 the PLR is trying to avoid. Router ID of downstream node 513 is preferred. This field is mandatory, and is used by 514 the MP for merging rules discussed below. 516 There can be more than one pair of (PLR_ID, Avoid_Node_ID) entries in 517 a DETOUR object. If detour merging is desired, after each merging 518 operation, the Detour Merge Point should combine all the merged 519 detours in the subsequent Path messages. 521 The high-order bit of the C-Class is zero; LSRs that do not support 522 the DETOUR objects MUST reject any Path message containing a DETOUR 523 object and send a PathErr to notify the PLR. This PathErr SHOULD 524 be generated as specified in [RSVP] for unknown objects with a 525 class-num of the form "0bbbbbbb". 527 4.3. SESSION_ATTRIBUTE Flags 529 To explicitly request bandwidth and node protection, two new flags 530 are defined in the SESSION_ATTRIBUTE object. 532 For both C-Type 1 and 7, the SESSION_ATTRIBUTE object currently has 533 the following flags defined: 535 Local protection desired: 0x01 537 This flag permits transit routers to use a local repair 538 mechanism which may result in violation of the explicit route 539 object. When a fault is detected on an adjacent downstream link 540 or node, a transit node may reroute traffic for fast service 541 restoration. 543 Label recording desired: 0x02 545 This flag indicates that label information should be included 546 when doing a route record. 548 SE Style desired: 0x04 550 This flag indicates that the tunnel ingress node may choose to 551 reroute this tunnel without tearing it down. A tunnel egress 552 node SHOULD use the SE Style when responding with a Resv 553 message. When requesting fast reroute, the head-end LSR 554 SHOULD set this flag; this is not necessary for the 555 path-specific method of the one-to-one backup technique. 557 The following new flags are defined: 559 Bandwidth protection desired: 0x08 561 This flag indicates to the PLRs along the protected LSP path 562 that a backup path with a bandwidth guarantee is desired. 563 The bandwidth to be guaranteed is that of the protected 564 LSP, if no FAST_REROUTE object is included in the PATH message; 565 if a FAST_REROUTE object is in the PATH message, then the 566 bandwidth specified therein is that to be guaranteed. 568 Node protection desired: 0x10 570 This flag indicates to the PLRs along a protected LSP path 571 that a backup path which bypasses at least the next node of 572 the protected LSP is desired. 574 4.4. RRO IPv4/IPv6 Sub-Object Flags 576 To report whether bandwidth and/or node protection are provided as 577 requested, we define two news flags in the RRO IPv4 sub-object. 579 RRO IPv4 and IPv6 sub-object address: 581 These two sub-objects currently have the following flags defined: 583 Local protection available: 0x01 585 Indicates that the link downstream of this node is protected 586 via a local repair mechanism, which can be either one-to-one 587 or facility backup. 589 Local protection in use: 0x02 591 Indicates that a local repair mechanism is in use to maintain 592 this tunnel (usually in the face of an outage of the link it 593 was previously routed over, or an outage of the neighboring 594 node). 596 Two new flags are defined: 598 Bandwidth protection: 0x04 600 The PLR will set this when the protected LSP has a backup path 601 which is guaranteed to provide the desired bandwidth specified 602 in the FAST_REROUTE object or the bandwidth of the protected 603 LSP, if no FAST_REROUTE object was included. The PLR may set 604 this whenever the desired bandwidth is guaranteed; the PLR 605 MUST set this flag when the desired bandwidth is guaranteed 606 and the "bandwidth protection desired" flag was set in the 607 SESSION_ATTRIBUTE object. If the requested bandwidth is not 608 guaranteed, the PLR MUST NOT set this flag. 610 Node protection: 0x08 612 The PLR will set this when the protected LSP has a backup path 613 which provides protection against a failure of the next LSR 614 along the protected LSP. The PLR may set this whenever node 615 protection is provided by the protected LSP's backup path; the 616 PLR MUST set this flag when the node protection is provided 617 and the "node protection desired" flag was set in the 618 SESSION_ATTRIBUTE object. If node protection is not provided, 619 the PLR MUST NOT set this flag. Thus, if a PLR could only 620 setup a link-protection backup path, the "Local protection 621 available" bit will be set but the "Node protection" bit will 622 be cleared. 624 5. Head-End Behavior 626 The head-end of an LSP determines whether local protection should 627 be requested for that LSP and which local protection technique is 628 desired for the protected LSP. The head-end also determines what 629 constraints should be requested for the backup paths of a protected 630 LSP. 632 To indicate that an LSP should be locally protected, the head-end 633 LSR MUST either set the "Local protection desired" flag in the 634 SESSION_ATTRIBUTE object or include a FAST_REROUTE object in the 635 PATH message or both. It is recommended that the "local protection 636 desired" flag in the SESSION_ATTRIBUTE object always be set. If a 637 head-end LSR signals a FAST_REROUTE object, it MUST be stored for 638 Path refreshes. 640 The head-end LSR of a protected LSP MUST set the "label recording 641 desired" flag in the SESSION_ATTRIBUTE object. This facilitates 642 the use of the facility backup technique. If node protection is 643 desired, the head-end LSR should set the "node protection desired" 644 flag in the SESSION_ATTRIBUTE object; otherwise this flag should be 645 cleared. Similarly, if a guarantee of bandwidth protection is 646 desired, then the "bandwidth protection desired" flag in the 647 SESSION_ATTRIBUTE object should be set; otherwise, this flag should 648 be cleared. 650 If the head-end LSR determines that control of the backup paths for 651 the protected LSP is desired, then the LSR should include the 652 FAST_REROUTE object. The attribute filters, bandwidth, hop-limit 653 and priorities will be used by the PLRs when determining the backup 654 paths. 656 If the head-end LSR desires that the protected LSP be protected via 657 the one-to-one backup technique, then head-end LSR should include a 658 FAST_REROUTE object and set the "one-to-one backup desired" flag. 659 If the head-end LSR desires that the protected LSP be protected via 660 the facility backup technique, then the head-end LSR should include 661 a FAST_REROUTE object and set the "facility backup desired" flag. 662 The lack of a FAST_REROUTE object, or having both these flags 663 clear should be treated by PLRs as a lack of preference. If 664 both flags are set a PLR may use either method or both. 666 The head-end LSR of a protected LSP MUST support the additional 667 flags defined in Section 4.4 being set or clear in the RRO IPv4 and 668 IPv6 sub-objects. The head-end LSR of a protected LSP MUST support 669 the RRO Label sub-object. 671 If the head-end LSR of an LSP determines that local protection is 672 newly desired, this should be signaled via make-before-break. 674 6. Point of Local Repair Behavior 676 Every LSR along a protected LSP (except the egress) MUST follow the 677 PLR behavior described in this document. 679 A PLR SHOULD support the FAST_REROUTE object, the "local protection 680 desired", "label recording desired", "node protection desired" and 681 "bandwidth protection desired" flags in the SESSION_ATTRIBUTE 682 object, and the "local protection available", "local protection in 683 use", "bandwidth protection", and "node protection" flags in the 684 RRO IPv4 and IPv6 sub-objects. A PLR MAY support the DETOUR 685 object. 687 A PLR MUST consider an LSP as having asked for local protection if 688 the "local protection desired" flag is set in the SESSION_ATTRIBUTE 689 object and/or the FAST_REROUTE object is included. If the 690 FAST_REROUTE object is included, a PLR SHOULD consider providing 691 one-to-one protection if the "one-to-one desired" is set and SHOULD 692 consider providing facility backup if the "facility backup desired" 693 flag is set when determining whether to provide local protection 694 and which technique to use to provide that local protection. If 695 the "node protection desired" flag is set, the PLR SHOULD try to 696 provide node protection; if this is not feasible, the PLR SHOULD 697 then try to provide link protection. If the "bandwidth protection 698 guaranteed" flag is set, the PLR SHOULD try to provide a bandwidth 699 guarantee; if this is not feasible, the PLR SHOULD then try to 700 provide a backup without a guarantee of the full bandwidth. 702 The following treatment for the RRO IPv4 or IPv6 sub-object's flags 703 must be followed if an RRO is included in the protected LSP's RESV 704 message. Based on this additional information the head-end may 705 take appropriate actions. 707 - Until a PLR has a backup path available, the PLR MUST clear the 708 relevant four flags in the corresponding RRO IPv4 or IPv6 709 sub-object. 711 - Whenever the PLR has a backup path available, the PLR MUST set 712 the "local protection available" flag. If no established 713 one-to-one backup LSP or bypass tunnel exists, or the one-to-one 714 LSP and the bypass tunnel is in "DOWN" state, the PLR MUST clear 715 the "local protection available" flag in its IPv4 (or IPv6) 716 address subobject of the RRO and SHOULD send the updated RESV. 718 - The PLR MUST clear the "local protection in use" flag unless it 719 is actively redirecting traffic into the backup path instead of 720 along the protected LSP. 722 - The PLR SHOULD also set the "node protection" flag if the backup 723 path protects against the failure of the immediate downstream 724 node and, if not, the PLR SHOULD clear the "node protection" 725 flag. This MUST be done if the "node protection desired" flag 726 was set in the SESSION_ATTRIBUTE object. 728 - The PLR SHOULD set the "bandwidth protection" if the backup path 729 offers a bandwidth guarantee and, if not, SHOULD clear the 730 "bandwidth protection" flag. This MUST be done if the "bandwidth 731 protection desired" flag was set in the SESSION_ATTRIBUTE 732 object. 734 6.1 Signaling a Backup Path 736 A number of objectives must be met to obtain a satisfactory signaling 737 solution. These are summarized as follows: 739 1. Unambiguously and uniquely identify backup paths 740 2. Unambiguously associate protected LSPs with their backup paths 741 3. Work with both global and non-global label spaces 742 4. Allow for merging of backup paths 743 5. Maintain RSVP state during and after fail-over. 745 LSP tunnels are identified by a combination of the SESSION and 746 SENDER_TEMPLATE objects. The relevant fields are as follows. 748 IPv4 (or IPv6) tunnel end point address 750 IPv4 (or IPv6) address of the egress node for the tunnel. 752 Tunnel ID 754 A 16-bit identifier used in the SESSION that remains constant 755 over the life of the tunnel. 757 Extended Tunnel ID 759 A 32-bit (IPv4) or 128-bit (IPv6) identifier used in the SESSION 760 that remains constant over the life of the tunnel. Normally set 761 to all zeros. Ingress nodes that wish to narrow the scope of a 762 SESSION to the ingress-egress pair may place their IP address 763 here as a globally unique identifier. 765 IPv4 (or IPv6) tunnel sender address 767 IPv4 (or IPv6) address for a sender node 769 LSP ID 771 A 16-bit identifier used in the SENDER_TEMPLATE and the 772 FILTER_SPEC that can be changed to allow a sender to share 773 resources with itself. 775 The first three of these are in the SESSION object and are the basic 776 identification of the tunnel. Setting the "Extended Tunnel ID" to 777 an IP address of the head-end LSR allows the scope of the SESSION 778 to be narrowed to only LSPs sent by that LSR. A backup LSP is 779 considered to be part of the same session as its protected LSP; 780 therefore these three cannot be varied. 782 The last two are in the SENDER_TEMPLATE. Multiple LSPs in the same 783 SESSION may be protected and take different routes; this is common 784 when rerouting a tunnel using make-before-break. It is necessary 785 that a backup path be clearly identified with its protected LSP, so 786 that correct merging and state treatment can be done. Therefore, a 787 backup path must inherit its LSP ID from the associated protected 788 LSP. Thus, the only field in the SESSION and SENDER_TEMPLATE 789 objects which could be varied between a backup path and a protected 790 LSP is the "IPv4 (or IPv6) tunnel sender address" in the 791 SENDER_TEMPLATE. 793 There are two different methods to uniquely identify a backup 794 path. These are described below. 796 6.1.1. Backup Path Identification: Sender-Template-Specific 798 In this approach, the SESSION object and the LSP_ID are copied from 799 the protected LSP. The "IPv4 tunnel sender address" is set to an 800 address of the PLR. If the head-end of a tunnel is also acting as 801 the PLR, it MUST choose an IP address different from the one used 802 in the SENDER_TEMPLATE of the original LSP tunnel. 804 When using the sender-template-specific approach, the protected 805 LSPs and the backup paths SHOULD use the Shared Explicit (SE) 806 style. This allows bandwidth sharing between multiple backup 807 paths. The backup paths and the protected LSP MAY be merged by the 808 Detour Merge Points, when the ERO from the MP to the egress is the 809 same on each LSP to be merged, as specified in [RSVP-TE]. 811 6.1.2. Backup Path Identification: Path-Specific 813 In this approach, rather than varying the SESSION or 814 SENDER_TEMPLATE objects, a new object, the DETOUR object, is used 815 to distinguish between PATH messages for a backup path and the 816 protected LSP. 818 Thus, the backup paths use the same SESSION and SENDER_TEMPLATE 819 objects as the ones used in the protected LSP. The presence of 820 DETOUR object in Path messages signifies a backup path; the 821 presence of FAST_REROUTE object and/or the "local protection 822 requested" flag in the SESSION_ATTRIBUTE object indicates a 823 protected LSP. 825 In the path-message-specific approach, when an LSR receives 826 multiple Path messages which have the same SESSION and 827 SENDER_TEMPLATE objects and also have the same next-hop, that LSR 828 MUST merge the Path messages. Without this behavior, the multiple 829 RESV messages received back would not be distinguishable as to 830 which backup path each belongs to. This merging behavior does 831 reduce the total number of RSVP states inside the network at the 832 expense of merging LSPs with different EROs. 834 6.2 Procedures for Backup Path Computation 836 Before a PLR can create a detour or a bypass tunnel, the desired 837 explicit route must be determined. This can be done using a CSPF. 839 Before CSPF computation, the following information should be 840 collected at a PLR: 842 - The list of downstream nodes that the protected LSP passes 843 through. This information is readily available from the 844 RECORD_ROUTE objects during LSP setup. This information is also 845 available from the ERO. However, if the ERO contains loose 846 sub-objects, the ERO may not provide adequate information. 848 - The downstream links/nodes that we want to protect against. Once 849 again, this information is learned from the RECORD_ROUTE 850 objects. Whether node protection is desired is determined by 851 the "node protection" flag in the SESSION_ATTRIBUTE object and 852 local policy. 854 - The upstream uni-directional links that the protected LSP 855 passes through. This information is learned from the 856 RECORD_ROUTE objects; it is only needed for setting up 857 one-to-one protection. In the path-specific method, it is 858 necessary to avoid the detour and the protected LSP sharing 859 a common next-hop upstream of the failure. In the 860 sender-template-specific mode, this same restriction is 861 necessary to avoid sharing bandwidth between the detour and 862 its protected LSP, where that bandwidth has only been reserved 863 once. 865 - The link attribute filters to be applied. These are derived 866 from the FAST_REROUTE object, if included in the PATH message, 867 and the SESSION_ATTRIBUTE object otherwise. 869 - The bandwidth to be used is found in the FAST_REROUTE object, 870 if included in the PATH message, and in the SESSION_ATTRIBUTE 871 object otherwise. Local policy may modify the bandwidth to be 872 reserved. 874 - The hop-limit, if a FAST_REROUTE object was included in the 875 PATH message. 877 When applying a CSPF algorithm to compute the backup route, the 878 following constraints should be satisfied: 880 - For detour LSPs, the destination MUST be the tail-end of the 881 protected LSP; for bypass tunnels (Section 6), the destination 882 MUST be the address of the MP. 884 - When setting up one-to-one protection using the path-specific 885 method, a detour MUST not traverse the upstream links of the 886 protected LSP in the same direction. This prevents the 887 possibility of early merging of the detour into the protected 888 LSP. When setting up one-to-one protection using the 889 sender-template-specific method, a detour should not traverse 890 the upstream links of the protected LSP in the same direction; 891 this prevents sharing the bandwidth between a protected LSP 892 and its backup upstream of the failure where the bandwidth 893 would be used twice in the event of a failure. 895 - The backup LSP cannot traverse the downstream node and/or link 896 whose failure is being protected against. Note that if the 897 PLR is the penultimate hop, node protection is not possible 898 and only the downstream link can be avoided. The backup path 899 may be computed to be SRLG disjoint from the downstream node 900 and/or link being avoided. 902 - The backup path must satisfy the resource requirements of the 903 protected LSP. This includes the link attribute filters, 904 bandwidth, and hop limits determined from the FAST_REROUTE 905 object and SESSION_ATTRIBUTE object. 907 If such computation succeeds, the PLR should attempt to establish a 908 backup path. The PLR may schedule a re-computation at a later time 909 to discover better paths that may have emerged. If for any reason, 910 the PLR is unable to bring up a backup path, it must schedule a 911 retry at a later time. 913 6.3 Signaling Backups for One-To-One Protection 915 Once a PLR has decided to locally protect an LSP with one-to-one 916 backup, and has identified the desired path, it takes the following 917 steps to signal the detour. 919 The following describes the transformation to be performed upon the 920 protected LSP's PATH message to create the detour LSP's PATH 921 message. 923 - If the sender-template specific method is to be used, then the 924 PLR MUST change the "IPv4 (or IPv6) tunnel sender address" of the 925 SENDER_TEMPLATE to an address belonging to the PLR that is not 926 the same as was used for the protected LSP. Additionally, the 927 DETOUR object MAY be added to the PATH message. 929 - If the path-specific method is to be used, then the PLR MUST add 930 a DETOUR object to the PATH message. 932 - The SESSION_ATTRIBUTE flags "Local protection desired", 933 "Bandwidth protection desired" and "Node protection desired" MUST 934 be cleared. The "Label recording desired" flag MAY be modified. 935 If the Path Message contained a FAST_REROUTE object, and the ERO 936 is not completely strict, the Include-any, Exclude-any, and 937 Include-all fields of the FAST_REROUTE object SHOULD be copied to 938 the corresponding fields of the SESSION_ATTRIBUTE object. 940 - If the protected LSP's Path message contained a FAST_REROUTE 941 object, this MUST be removed from the detour LSP's PATH message. 943 - The PLR MUST generate an EXPLICIT_ROUTE object toward the egress. 944 First, the PLR must remove all sub-objects preceding the first 945 address belonging to the Merge Point. Then the PLR SHOULD add 946 sub-objects corresponding to the desired backup path between the 947 PLR and the MP. 949 - The SENDER_TSPEC object SHOULD contain the bandwidth information 950 from the received FAST_REROUTE object, if included in the 951 protected LSP's PATH message. 953 - The RSVP_HOP object containing one of the PLR's IP address. 955 - The detour LSPs MUST use the same reservation style as the 956 protected LSP. This must be correctly reflected in the 957 SESSION_ATTRIBUTE object. 959 Detour LSPs are regular LSPs in operation. Once a detour path is 960 successfully computed and the detour LSP is established, the PLR 961 need not compute detour routes again, unless (1) the contents of 962 FAST_REROUTE have changed, or (2) the downstream interface and/or 963 the nexthop router for a protected LSP have changed. The PLR may 964 recompute detour routes at any time. 966 6.3.1 Make-Before-Break with Detour LSPs 968 If the sender-template specific method is used, it is possible to 969 do make-before-break with detour LSPs. This is done by using two 970 different IP addresses belonging to the PLR (which were not used in 971 the SENDER_TEMPLATE of the protected LSP). If the current detour 972 LSP uses the first IP address in its SENDER_TEMPLATE, then the new 973 detour LSP should be signaled using the second IP address in its 974 SENDER_TEMPLATE. Once the new detour LSP has been created, the 975 current detour LSP can be torn down. By alternating the use of 976 these IP addresses, the current and new detour LSPs will have 977 different SENDER_TEMPLATES and, thus, different state in the 978 downstream LSRs. 980 This make-before-break mechanism, changing the PLR IP address in 981 the DETOUR object instead, is not feasible with the path-specific 982 method because the PATH messages for new and current detour LSPs 983 may be merged if they share a common next-hop. 985 6.3.2 Message Handling 987 LSRs must process the detour LSPs independent of the protected LSPs 988 to avoid triggering the LSP loop detection procedure described in 989 [RSVP-TE]. 991 The PLR MUST not mix the messages for the protected and the detour 992 LSPs. When a PLR receives Resv, ResvTear and PathErr messages from 993 the downstream detour destination, the messages MUST not be forwarded 994 upstream. Similarly, when a PLR receives ResvErr and ResvConf 995 messages from a protected LSP, it MUST not propagate them onto the 996 associated detour LSP. 998 A session tear-down request is normally originated by the sender via 999 PathTear messages. When a PLR node receives a PathTear message from 1000 upstream, it MUST delete both the protected and the detour LSPs. The 1001 PathTear messages MUST propagate to both protected and detour LSPs. 1003 During error conditions, the LSRs may send ResvTear messages to fix 1004 problems on the failing path. When a PLR node receives the ResvTear 1005 messages from downstream for a protected LSP, as long as a detour is 1006 up, the ResvTear messages MUST not be sent further upstream. 1007 PathErrs should be treated similiarly. 1009 6.3.3 Local Reroute of Traffic onto Detour LSP 1011 When the PLR detects a failure on the protected LSP, the PLR MUST 1012 rapidly switch packets to the protected LSP's backup LSP instead of 1013 the protected LSP's normal out-segment. The goal of this technique 1014 is to effect the redirection within 10s of milliseconds. 1016 L32 L33 L34 L35 1017 R1-------R2-------R3-------R4-------R5 1018 | | 1019 L46 | L47 | L44 1020 R6---------------R7 1022 Protected LSP: [R1->R2->R3->R4->R5] 1023 Detour LSP: [R2->R6->R7->R4] 1025 Example 3: Redirect to Detour 1027 In Example 3 above, if the link [R2->R3] fails, then R2 would do 1028 the following. Any traffic received on link [R1->R2] with label 1029 L32 would be sent out link [R2->R6] with label L46 (along the 1030 detour LSP) instead of out link [R3->R4] with lable L34 (along the 1031 protected LSP). The Merge Point, R4, would recognize that packets 1032 received on link [R7->R4] with label L44 should be sent out link 1033 [R4->R5] with label L35, and thus merged with the protected LSP. 1035 6.4 Signaling for Facility Protection 1037 A PLR may use one or more bypass tunnels to protect against the 1038 failure of a link and/or a node. These bypass tunnels may be 1039 setup in advance or may be dynamically created as new protected 1040 LSPs are signaled. 1042 6.4.1. Discovering Downstream Labels 1044 To support facility backup, it is necessary for the PLR to 1045 determine a label which will indicate to the MP that packets 1046 received with that label should be switched along the protected 1047 LSP. This can be done without explicitly signaling the backup path 1048 if the MP uses a label space global to that LSR. 1050 As described in Section 5, the head-end LSR MUST set the "label 1051 recording requested" flag in the SESSION_ATTRIBUTE object for LSPs 1052 requesting local protection. This will cause (as specified in 1053 [RSVP- TE]) all LSRs to record their INBOUND labels and to note via 1054 a flag if the label is global to the LSR. Thus, when a protected 1055 LSP is first signaled through a PLR, the PLR can examine the RRO in 1056 the Resv message and learn about the incoming labels that are used 1057 by all downstream nodes for this LSP. 1059 When MPs use per-interface-label spaces, the PLR must send Path 1060 messages (for each protected LSP using a bypass tunnel) via that 1061 bypass tunnel prior to the failure in order to discover the 1062 appropriate MP label. The signaling procedures for this are in 1063 Section 6.4.3 below. 1065 6.4.2. Procedures for the PLR before Local Repair 1067 A PLR which determines to use facility-backup to protect a given 1068 LSP should select a bypass tunnel to use taking into account 1069 whether node protection is to be provided, what bandwidth was 1070 requested and whether a bandwidth guarantee is desired, and what 1071 link attribute filters were specified in the FAST_REROUTE object. 1073 The selection of a bypass tunnel for a protected LSP is performed 1074 by the PLR when the LSP is first setup. 1076 6.4.3. Procedures for the PLR during Local Repair 1078 When the PLR detects a link or/and node failure condition, it needs 1079 to reroute the data traffic onto the bypass tunnel and to start 1080 sending the control traffic for the protected LSP onto the bypass 1081 tunnel. 1083 The backup tunnel is identified using the sender-template-specific 1084 method. The procedures to follow are similar to those described in 1085 Section 6.3. 1087 - The SESSION is unchanged. 1089 - The SESSION_ATTRIBUTE is unchanged except as follows: 1090 The "Local protection desired", "Bandwidth protection desired", 1091 and "Node protection desired" flags SHOULD be cleared. 1092 The "Label recording desired" MAY be modified. 1094 - The IPv4 (or IPv6) tunnel sender address of the SENDER_TEMPLATE 1095 is set to an address belonging to the PLR. 1097 - The RSVP_HOP object MUST contain an IP source address 1098 belonging to the PLR. Consequently, the MP will send messages 1099 back to the PLR using as a destination that IP address. 1101 - The PLR MUST generate an EXPLICIT_ROUTE object toward the 1102 egress. Detailed ERO processing is described below. 1104 - The RRO object may need to be updated, as described in Section 1105 6.5. 1107 The PLR sends Path, PathTear, and ResvConf messages via the backup 1108 tunnel. The MP sends Resv, ResvTear, and PathErr messages by 1109 directly addressing them to the address in the RSVP_HOP object 1110 contents as specified in [RSVP]. 1112 If it is necessary to signal the backup prior to failure to 1113 determine the MP label to use, then the same Path message is sent. 1114 In this case, the PLR SHOULD continue to send Path messages for the 1115 protected LSP along the normal route. PathTear messages should be 1116 duplicated, with one sent along the normal route and one sent thru 1117 the bypass tunnel. The MP should duplicate the Resv and ResvTear 1118 messages and sent them to both the PLR and the LSR indicated by the 1119 protected LSP's RSVP_HOP object. 1121 6.4.4. Processing backup tunnel's ERO 1123 Procedures for ERO processing are described in [RSVP-TE]. This 1124 section describes additional ERO update procedures for Path messages 1125 which are sent over bypass tunnels. If normal ERO processing rules 1126 were followed, the Merge Point would examine the first sub-object and 1127 likely reject it (Bad initial sub-object). This is because the 1128 unmodified ERO might contain the IP address of a bypassed node (in 1129 the case of a NNHOP Backup Tunnel), or of an interface which is 1130 currently down (in the case of a NHOP Backup Tunnel). For this 1131 reason, the PLR invoke the following ERO procedures before sending a 1132 Path message via a bypass tunnel. 1134 Sub-objects belonging to abstract nodes which precede the Merge Point 1135 are removed, along with the first sub-object belonging to the MP. A 1136 sub-object identifying the Backup Tunnel destination is then added. 1138 More specifically, the PLR MUST: 1140 - remove all the sub-objects proceeding the first address belonging 1141 to the MP. 1143 - replace this first MP address with an IP address of the MP. 1144 (Note that this could be same address that was just removed.) 1146 6.5. PLR Procedures During Local Repair 1148 In addition to the technique specific signaling and packet 1149 treatment, there is common signaling which should be followed. 1151 During fast reroute, for each protected LSP containing an RRO 1152 object, the PLR obtains the RRO from the protected LSP's stored 1153 RESV. The PLR MUST update the IPv4 or IPv6 sub-object it inserted 1154 into the RRO by setting the "Local protection in use" and "Local 1155 Protection Available" flags. 1157 6.5.1. Notification of local repair 1159 In many situations, the route used during a Local Repair will be less 1160 than optimal. The purpose of Local Repair is to keep high priority 1161 and loss sensitive traffic flowing while a more optimal re-routing of 1162 the tunnel can be effected by the head-end of the tunnel. Thus the 1163 head-end needs to know of the failure so it may re-signal an LSP 1164 which is optimal. 1166 To provide this notification, the PLR SHOULD send a Path Error 1167 message with error code of "Notify" (Error code =25) and an error 1168 value field of ss00 cccc cccc cccc where ss=00 and the sub-code = 3 1169 ("Tunnel locally repaired") (see [RSVP-TE]) 1171 Additionally a head-end may also detect that an LSP needs to be moved 1172 to a more optimal path by noticing failures reported via the IGP. 1173 Note that in the case of inter-area TE LSP (TE LSP spanning areas), 1174 the head-end LSR will need to rely exclusively on Path Error messages 1175 to be informed of failures in another area. 1177 6.5.2 Revertive Behavior 1179 Upon a failure event, a protected TE LSP is locally repaired by the 1180 PLR. There are two basic strategies for restoring the TE LSP to a 1181 full working path. 1183 - Global revertive mode: The head-end LSR of each tunnel is 1184 responsible for reoptimizing the TE LSPs that used the failed 1185 resource. There are several potential reoptimization triggers - 1186 RSVP error messages, inspection of OSPF LSAs or ISIS LSPs, and 1187 timers. Note that this re-optimization process may proceed as 1188 soon as the failure is detected. It is not tied to the 1189 restoration of the failed resource. 1191 - Local revertive mode: Upon detecting that the resource is 1192 restored, the PLR re-signals each of TE LSPs that used to be 1193 routed over the restored resource. Every TE LSP successfully 1194 resignaled along the restored resource is switched back. 1196 There are several circumstances where a local revertive mode might 1197 not be desirable. In the case of resource flapping (not an uncommon 1198 failure type), this could generate multiple traffic disruptions. 1199 Therefore, in the local revertive mode, the PLR should implement a 1200 means to dampen the re-signaling process in order to limit 1201 potential disruptions due to flapping. 1203 In the local revertive mode, any TE LSP will be switched back, 1204 without any distinction, as opposed to the global revertive mode 1205 where the decision to reuse the restored resource is taken by the 1206 head-end LSR based on the TE LSP attributes. When the head-end 1207 learns of the failure, it may reoptimize the protected LSP tunnel 1208 along a different and more optimal path, because it has a more 1209 complete view of the resources and TE LSP constraints; this means 1210 that the old LSP which has been reverted to may not be optimal any 1211 longer. Note that in the case of inter-area LSP, where the TE LSP 1212 path computation might be done on some Path Computation Server, the 1213 reoptimization process can still be triggered on the Head-End 1214 LSP. The local revertive mode is optional. 1216 However, there are circumstances where the Head-end does not have 1217 the ability to reroute the TE LSP (e.g if the protected LSP is 1218 pinned down, as may be desirable if the paths are determined using 1219 an off-line optimization tool) or if Head-end does not have the 1220 complete TE topology information (depending on the path computation 1221 scenario). In those cases, the local revertive might be a 1222 interesting option. 1224 It is recommended that one always use the globally revertive mode. 1225 Note that a link or node "failure" may be due to the facility being 1226 permanently taken out of service. Local revertive mode is 1227 optional. When used in combination, the global mode may rely 1228 solely on timers to do the reoptimization. When local revertive 1229 mode is not used, head-end LSRs SHOULD react to RSVP error messages 1230 and/or IGP indications in order to make a timely response. 1232 Interoperability: If a PLR is configured with the local revertive 1233 mode but the MP is not, any attempt from the PLR to resignal the TE 1234 LSP over the restored resource would fail as the MP will not send 1235 any Resv message. The PLR will still refresh the TE LSP over the 1236 backup tunnel. The TE LSP will not revert to the restored resource; 1237 instead it will continue to use the backup until it is 1238 re-optimized. 1240 7. Merge Node Behavior 1242 An LSR is a Merge Point if it receives the Path message for a 1243 protected LSP and one or more messages for a backup LSP which is 1244 merged into that protected LSP. In the one-to-one backup 1245 technique, the LSR is aware that it is a merge node prior to 1246 failure. In the facility backup technique, the LSR may not know 1247 that it is a Merge Point until a failure occurs and it receives a 1248 backup LSP's Path message. Therefore, an LSR which is on the path 1249 of a protected LSP SHOULD always assume that it is a merge point. 1251 When a MP receives a backup LSP's Path message thru a bypass 1252 tunnel, the Send_TTL in the Common Header may not match the TTL of 1253 the IP packet within which the Path message was transported. This 1254 is expected behavior. 1256 7.1. Handling Backup Path Messages Before Failure 1258 There are two circumstances where a Merge Point will receive Path 1259 messages for a backup path prior to failure. In the first case, if 1260 a PLR is providing local protection via the one-to-one backup 1261 technique, the detour will be signaled and must be properly handled 1262 by the MP. In this case, the backup LSP may be signaled via the 1263 sender-template-specific method or via the path-specific method. 1265 In the second case, if the Merge Point does not provide labels 1266 global to the MP and record them in a Label sub-object of the RRO 1267 or if the PLR does not use such recorded information, the PLR may 1268 signal the backup path, as described above in Section 6.4.1, to 1269 determine the label to use if the PLR is providing protection 1270 according to the facility backup technique. In this case, the 1271 backup LSP is signaled via the sender-template-specific method. 1273 The reception of a backup LSP's path message does not indicate that 1274 a failure has occured and the incoming protected LSP will no longer 1275 be used. 1277 7.1.1. Merginging Backup Paths using the Sender-Template Specific Method 1279 An LSR may receive multiple Path messages for one or more backup 1280 LSPs and, possibly, the protected LSP. Each of these Path messages 1281 will have a different SENDER_TEMPLATE. The protected LSP can be 1282 recognized because it will either include the FAST_REROUTE object, 1283 have the "local protection desired" flag set in the 1284 SESSION_ATTRIBUTE object or both. 1286 If the outgoing interface and next-hop LSR are the same, then the 1287 Path messages are eligible for merging. Similar to that specified 1288 in [RSVP-TE] for merging of RESV messages, only those Path messages 1289 whose ERO from that LSR to the egress is the same can be merged. 1290 If merging occurs and one of the Path messages merged was for the 1291 protected LSP, then the final Path message to be sent MUST be that 1292 of the protected LSP. This merges the backup LSPs into the 1293 protected LSP at that LSR. Once the final Path message has been 1294 identified, the MP MUST start to refresh it downstream 1295 periodically. 1297 If merging occurs and all the Path messages were for backup LSPs, 1298 then the DETOUR object, if any, should be altered as specified in 1299 Section 8.1 1301 7.1.2. Merging Detours using the Path-Specific Method 1303 An LSR (that is, an MP) may receive multiple Path messages from 1304 different interfaces with identical SESSION and SENDER_TEMPLATE 1305 objects. In this case, Path state merging is REQUIRED. 1307 The merging rule is the following: 1309 For all Path messages that do not have either a FAST_REROUTE or a 1310 DETOUR object, or the MP is the egress of the LSP, no merging is 1311 required. The messages are processed according to [RSVP-TE]. 1313 Otherwise, the MP MUST record the Path state as well as their 1314 incoming interface. If the Path messages do not share outgoing 1315 interface and next-hop LSR, the MP MUST consider them as independent 1316 LSPs, and MUST NOT merge them. 1318 For all the Path messages that share the same outgoing interface and 1319 next-hop LSR, the MP runs the following procedure to select one of 1320 them as the Path message to forward downstream. 1322 1. Eliminate from consideration those that traverse nodes that 1323 other Path messages want to avoid. 1325 2. If one LSP is originated from this node, this must be 1326 the final LSP. Quit. 1328 3. If only one Path message contains FAST_REROUTE object, this 1329 becomes the chosen Path message. Quit. 1331 4. If there are several LSPs, and not all of them have a DETOUR 1332 object, then eliminate those with DETOUR from consideration. 1334 5. If several candidates remain (that is, there are both detour 1335 and protected LSPs), prefer the ones with FAST_REROUTE object. 1337 6. If none found, prefer the ones without DETOUR object. If none 1338 found, prefer the ones with DETOUR object. 1340 7. If several candidate Path message still remain, it is a local 1341 decision to choose which one will be the final LSP. The decision 1342 can be based on the number of IP hops in ERO, bandwidth 1343 requirements, or others. 1345 Once the final Path message has been identified, the MP MUST start to 1346 refresh it downstream periodically. Other LSPs are considered merged 1347 at this node. For bandwidth reservation on the outgoing link, any 1348 merging should be considered to have occured before bandwidth is 1349 reserved. Thus, even though Fixed Filter is specified, multiple 1350 detours and/or their protected LSP which are to be merged due to 1351 sharing an outgoing interface and next-hop LSR will reserve only 1352 the bandwidth of the final Path message on that outgoing 1353 interface. 1355 7.1.2.1. An Example on Path Message Merging 1357 R7---R8---R9-\ 1358 | | | \ 1359 R1---R2---R3---R4---R5---R6 1361 Protected LSP: [R1->R2->R3->R4->R5->R6] 1362 R2's Detour: [R2->R7->R8->R9->R4->R5->R6] 1363 R3's Detour: [R3->R8->R9->R5->R6] 1365 Example 4: Path Message Merging 1367 In Example 4 above, R8 will receive Path messages that have the 1368 same SESSION and SENDER_TEMPLATE from detours for R2 and R3. 1369 During merging at R8 since detour R3 has a shorter ERO path length 1370 (that is, ERO is [R9->R5->R6], and path length is 3), R8 will 1371 select it as the final LSP, and only propagate its Path messages 1372 downstream. Upon receiving a Resv (or a ResvTear) message, R8 must 1373 relay on the messages toward both R2 and R3. 1375 R5 needs to merge as well, and will select the main LSP, since it 1376 has the FAST_REROUTE object. Thus, the detour LSP terminates at 1377 R5. 1379 7.1.3. Message Handling for Merged Detours 1381 When an LSR receives a ResvTear for an LSP, the LSR must determine 1382 whether it has an alternate associated LSP. For instance, if the 1383 ResvTear was received for a protected LSP, but an associated backup 1384 LSP has not received a ResvTear, then the LSR has an alternate 1385 associated LSP. If the LSR does not have an alternate associated 1386 LSP, then the MP MUST propogate the ResvTear toward the LSP's 1387 ingress and, for each backup LSP merged into that LSP at this LSR, 1388 the ResvTear SHOULD also be propogated along the backup LSP. 1390 The MP may receive PathTear messages for some of the merging LSPs. 1391 PathTear messages SHOULD NOT be propagated downstream until the MP 1392 has received PathTear messages for each of the merged LSPs. 1393 However, the fact that one or more of the merged LSPs has been torn 1394 down should be reflected in the downstream message, such as by 1395 changing the DETOUR object, if any. 1397 7.2. Handling Failures 1399 When a downstream LSR detects a local link failure, for any 1400 protected LSPs routed over the failed link, Path and Resv state 1401 MUST NOT be cleared and PathTear and ResvErr messages MUST NOT be 1402 sent immediately; if this is not the case, then the facility backup 1403 technique will not work. Further a downstream LSR SHOULD reset the 1404 refresh timers for these LSPs as if they had just been refreshed. 1405 This is to allow time for the PLR to begin refreshing state via the 1406 bypass tunnel. State MUST be removed if it has not been refreshed 1407 before the refresh timer expires. This allows the facility backup 1408 technique to work without requiring that it signal backup paths 1409 thru the bypass tunnel before failure. 1411 After a failure has occured, the MP must still send Resv messages 1412 for the backup LSPs associated with the protected LSPs which have 1413 failed. If the backup LSP was sent through a bypass tunnel, then 1414 the PHOP object in its Path message will have the IP address of the 1415 associated PLR. This will ensure that Resv state is refreshed. 1417 Once the local link has recovered, the MP may or may not accept 1418 Path messages for existing protected LSPs which had failed over to 1419 their backup. 1421 8. Behavior of all LSRs 1423 The objects defined and the techniques defined in this document 1424 require behavior from all LSRs in the traffic-engineered network, 1425 even if that LSR is not along the path of a protected LSP. 1427 First, if a DETOUR object is included in the backup LSP's path 1428 message for the sender-template-specific method, the LSRs in the 1429 traffic-engineered network should support the DETOUR object. 1431 Second, if the Path-Specific Method is to be supported for 1432 the one-to-one backup technique, it is necessary that the LSRs in 1433 the traffic-engineered network be capable of merging detours as 1434 specified below in Section 8.1. 1436 It is possible to avoid specific LSRs which do not support this 1437 behavior by assigning an link attribute to all the links of those 1438 LSPs and then requesting that backup paths exclude that link 1439 attribute. 1441 8.1. Merging Detours in Path-Specific Method 1443 If multiple Path Messages for different detours are received with 1444 the same SESSION, SENDER_TEMPLATE, outgoing interface and next-hop 1445 LSR, then the LSR must function as a Detour Merge Point and merge 1446 the detour Path Messages. This merging should occur as specified 1447 in Section 7.1.2 and shown in Example 4. 1449 In addition, it is necessary to update the DETOUR object to reflect 1450 the merging which has taken place. This is done using the 1451 following algorithm to format the outgoing DETOUR object for the 1452 final LSP: 1454 - Combine all the (PLR_ID, Avoid_Node_ID) pairs from all the 1455 DETOUR objects of all merged LSPs, and create a new object with 1456 all listed. Ordering is insignificant. 1458 9. Security Considerations 1460 This document does not introduce new security issues. The security 1461 considerations pertaining to the original RSVP protocol [RSVP] remain 1462 relevant. 1464 It should be noted that the facility backup technique requires that 1465 a PLR and its selected Merge Point will trust RSVP messages 1466 received from each other. 1468 10. IANA Guidelines 1470 IANA [RFC-IANA] will assign RSVP C-class numbers for FAST_ROUTE and 1471 DETOUR objects. Currently, in production networks, FAST_REROUTE uses 1472 C-class 205, and DETOUR uses C-class 63. 1474 11. Intellectual Property Considerations 1476 Cisco Systems and Juniper Networks may have intellectual property 1477 rights claimed in regard to some of the specification contained in 1478 this document 1480 12. Full Copyright Statement 1482 Copyright (C) The Internet Society (2002). All Rights Reserved. 1484 This document and translations of it may be copied and furnished to 1485 others, and derivative works that comment on or otherwise explain it 1486 or assist in its implementation may be prepared, copied, published 1487 and distributed, in whole or in part, without restriction of any 1488 kind, provided that the above copyright notice and this paragraph are 1489 included on all such copies and derivative works. However, this 1490 document itself may not be modified in any way, such as by removing 1491 the copyright notice or references to the Internet Society or other 1492 Internet organizations, except as needed for the purpose of 1493 developing Internet standards in which case the procedures for 1494 copyrights defined in the Internet Standards process must be 1495 followed, or as required to translate it into languages other than 1496 English. 1498 The limited permissions granted above are perpetual and will not be 1499 revoked by the Internet Society or its successors or assigns. 1501 This document and the information contained herein is provided on an 1502 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1503 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1504 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1505 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1506 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1508 13. Acknowledgments 1510 We would like to acknowledge input and helpful comments from Rob 1511 Goguen, Tony Li, Yakov Rekhter and Curtis Villamizar. Especially, 1512 we thank those, who have been involved in interoperability testing 1513 and field trails, and provided invaluable ideas and suggestions. 1514 They are Rob Goguen, Carol Iturralde, Brook Bailey, Safaa Hasan, 1515 Richard Southern, and Bijan Jabbari. 1517 14. Normative References 1519 [RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP) 1520 -- version 1 functional specification," RFC2205, September 1997. 1522 [RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP 1523 tunnels", RFC3029, December 2001. 1525 [RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate 1526 Requirement Levels", RFC 2119, March 1997. 1528 [RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an 1529 IANA Considerations Section in RFCs", RFC 2434. 1531 15. Author Information 1533 Ping Pan 1534 CIENA Corp. 1535 10480 Ridgeview Court 1536 Cupertino, CA 95014 1537 e-mail: ppan@ciena.net 1538 phone: +1 408 366 4991 1540 Der-Hwa Gan 1541 Juniper Networks 1542 1194 N.Mathilda Ave 1543 Sunnyvale, CA 94089 1544 e-mail: dhg@juniper.net 1545 phone: +1 408 745 2074 1547 George Swallow 1548 Cisco Systems, Inc. 1549 250 Apollo Drive 1550 Chelmsford, MA 01824 1551 email: swallow@cisco.com 1552 phone: +1 978 244 8143 1554 Jean Philippe Vasseur 1555 Cisco Systems, Inc. 1556 300 Apollo Drive 1557 Chelmsford, MA 01824 1558 email: jpv@cisco.com 1559 phone: +1 978 497 6238 1561 Dave Cooper 1562 Global Crossing 1563 960 Hamlin Court 1564 Sunnyvale, CA 94089 1565 email: dcooper@gblx.net 1566 phone: +1 916 415 0437 1568 Alia Atlas 1569 Avici Systems 1570 101 Billerica Avenue 1571 N. Billerica, MA 01862 1572 email: aatlas@avici.com 1573 phone: +1 978 964 2070 1575 Markus Jork 1576 Avici Systems 1577 101 Billerica Avenue 1578 N. Billerica, MA 01862 1579 email: mjork@avici.com 1580 phone: +1 978 964 2142