idnits 2.17.1 draft-ietf-mpls-rsvp-lsp-fastreroute-04.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? == 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1594 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 334, but not defined == Missing Reference: 'R8' is mentioned on line 354, but not defined == Missing Reference: 'R6' is mentioned on line 358, but not defined == Missing Reference: 'R7' is mentioned on line 358, but not defined == Missing Reference: 'R9' is mentioned on line 358, but not defined == Missing Reference: 'R3' is mentioned on line 368, but not defined == Missing Reference: 'RSVP- TE' is mentioned on line 1135, 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: 5 errors (**), 0 flaws (~~), 13 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: August 2004 George Swallow, Ed (Cisco Systems) 4 Alia Atlas, Ed (Avici Systems) 6 Fast Reroute Extensions to RSVP-TE for LSP Tunnels 8 draft-ietf-mpls-rsvp-lsp-fastreroute-04.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document defines extensions to and describes the use of RSVP to 34 establish backup label-switched path (LSP) tunnels for local repair 35 of LSP tunnels. These mechanisms enable the re-direction of traffic 36 onto backup LSP tunnels in 10s of milliseconds in the event of a 37 failure. 39 Two methods are defined here. The one-to-one backup method creates 40 detour LSPs for each protected LSP at each potential point of local 41 repair. The facility backup method creates a bypass tunnel to 42 protect a potential failure point; by taking advantage of MPLS label 43 stacking, this bypass tunnel can protect a set of protected LSPs that 44 have similar backup constraints. Both methods can be used to protect 45 links and nodes during network failure. The described behavior and 46 extensions to RSVP allow nodes to implement either or both methods 47 and to interoperate in a mixed network. 49 Contents 51 1 Authors .................................................. 3 52 2 Introduction ............................................. 3 53 2.1 Background ........................................... 4 54 3 Terminology ............................................... 5 55 4 Local Repair Techniques ................................... 7 56 4.1 One-to-one Backup ..................................... 7 57 4.2 Facility Backup ....................................... 8 58 5 RSVP Extensions ........................................... 9 59 5.1 FAST_REROUTE Object ................................... 9 60 5.2 DETOUR Object ......................................... 12 61 5.2.1 DETOUR object for IPv4 address .................... 12 62 5.2.2 DETOUR object for IPv6 address .................... 13 63 5.3 SESSION_ATTRIBUTE Flags ............................... 14 64 5.4 RRO IPv4/IPv6 Sub-Object Flags ........................ 15 65 6 Head-End Behavior ......................................... 16 66 7 Point of Local Repair Behavior ............................ 17 67 7.1 Signaling a Backup Path ............................... 18 68 7.1.1 Backup Path Identification: Sender-Template Specific 19 69 7.1.2 Backup Path Identification: Path-Specific ......... 20 70 7.2 Procedures for Backup Path Computation ................ 20 71 7.3 Signaling Backups for One-To-One Protection ........... 22 72 7.3.1 Make-Before-Break with Detour LSPs ................ 23 73 7.3.2 Message Handling .................................. 23 74 7.3.3 Local Reroute of Traffic Onto Detour LSP ........... 24 75 7.4 Signaling for Facility Protection ..................... 25 76 7.4.1 Discovering Downstream Labels ..................... 25 77 7.4.2 Procedures for the PLR before Local Repair ........ 25 78 7.4.3 Procedures for the PLR during Local Repair ........ 25 79 7.4.4 Processing backup tunnel's ERO .................... 26 80 7.5 PLR Procedures During Local Repair ..................... 27 81 7.5.1 Notification of local repair ...................... 27 82 7.5.2 Revertive Behavior ................................ 28 83 8 Merge Node Behavior ....................................... 29 84 8.1 Handling Backup Path Messages Before Failure .......... 29 85 8.1.1 Merging Backup Paths using the Sender-Template 86 Specific Method ................................... 30 87 8.1.2 Merging Detours using Path-Specific Method ........ 30 88 8.1.2.1 An Example on Path Message Merging ............ 31 89 8.1.3 Message Handling for Merged Detours ............... 32 90 8.2 Handling Failures ..................................... 32 91 9 Behavior of all LSRs ...................................... 33 92 9.1 Merging Detours in Path-Specific Method ............... 33 93 10 Security Considerations ................................... 34 94 11 IANA Guidelines ........................................... 34 95 12 Intellectual Property Considerations ...................... 34 96 13 Full Copyright Statement .................................. 35 97 14 Acknowledgments ........................................... 35 98 15 Normative References ...................................... 35 99 16 Editor Information ........................................ 36 101 1. Authors 103 This document was written by George Swallow, Ping Pan, Alia Atlas, 104 Jean Philippe Vasseur, Markus Jork, Der-Hwa Gan, and Dave Cooper. 106 Jean Philippe Vasseur 107 Cisco Systems, Inc. 108 300 Beaver Brook Road 109 Boxborough, MA 01719 110 USA 111 email: jpv@cisco.com 112 phone: +1 978 497 6238 114 Markus Jork 115 Avici Systems 116 101 Billerica Avenue 117 N. Billerica, MA 01862 118 USA 119 email: mjork@avici.com 120 phone: +1 978 964 2142 122 Der-Hwa Gan 123 Juniper Networks 124 1194 N.Mathilda Ave 125 Sunnyvale, CA 94089 126 USA 127 e-mail: dhg@juniper.net 128 phone: +1 408 745 2074 130 Dave Cooper 131 Global Crossing 132 960 Hamlin Court 133 Sunnyvale, CA 94089 134 USA 135 email: dcooper@gblx.net 136 phone: +1 916 415 0437 138 2. Introduction 140 This document extends RSVP [RSVP] to establish backup LSP tunnels 141 for the local repair of LSP tunnels. This technique is presented 142 to meet the needs of real-time applications, such as voice over IP, 143 for which it is highly desirable to be able to re-direct user 144 traffic onto backup LSP tunnels in 10s of milliseconds. This 145 timing requirement can be satisfied by computing and signaling 146 backup LSP tunnels in advance of failure and by re-directing 147 traffic as close to failure point as possible. In this way, the 148 time for the redirection does not include any path computation or 149 signaling delays, including delays to propagate failure 150 notification between LSRs. The speed of repair made possible by 151 the techniques and extensions described herein is the primary 152 advantage of this method. We use the term local repair when 153 referring to techniques which accomplish this, and refer to an 154 explicitly routed LSP which is provided with such protection as a 155 protected LSP. These techniques are applicable only to explicitly 156 routed LSPs; Application of the techniques discussed herein to LSPs 157 which dynamically change their routes such as those used in unicast 158 IGP routing is beyond the scope of this document. 160 Section 3 covers new terminology used in this document. The two 161 basic strategies for creating backup LSPs are described in Section 162 4. In Section 5, the protocol extensions to RSVP to support local 163 protection are described. In Section 6, the behavior of an LER 164 which wishes to request local protection for an LSP is presented. 165 The behavior of a potential point of local repair (PLR) is given in 166 Section 7; this describes how to determine the appropriate strategy 167 to use for protecting an LSP and how to implement each of the 168 strategies. The behavior of a merge node, the LSR where a 169 protected LSP and its backup LSP rejoin, is described in Section 8. 170 Finally, the required behavior of other nodes in the network is 171 discussed in Section 9. 173 For the techniques discussed in this document to function properly, 174 there are three assumptions which must be made. First, an LSR 175 which is on the path of a protected LSP SHOULD always assume that 176 it is a merge point; this is necessary because the facility backup 177 method does not signal backups through a bypass tunnel before 178 failure. Second, if the one-to-one backup method is used and a 179 DETOUR object is included, the LSRs in the traffic-engineered 180 network should support the DETOUR object; this is necessary so that 181 the Path message containing the DETOUR object is not rejected. 182 Third, understanding of the DETOUR object is required to support 183 the path-specific method which requires that LSRs in the 184 traffic-engineered network be capable of merging detours. 186 2.1 Background 188 Several years before work began on this draft, operational networks 189 had deployed two independent methods of doing fast reroute, called 190 herein one-to-one backup and facility backup. Vendors trying to 191 support both methods were experiencing incompatiblity problems in 192 attempting to produce a single implementation capable of 193 interoperating with both. There are technical tradeoffs between 194 the methods. However these tradeoffs are so topologically 195 dependent, that the community has not converged on a single 196 approach. 198 This draft rationalizes the RSVP signaling for both methods such 199 that any implementation can recognize all FRR requests and clearly 200 respond, either positively if they are capable of performing the 201 method, or with a clear error such that requester is informed and 202 can seek alternate means of backup. This draft also allows a 203 single implementation to support both methods, thereby providing a 204 range of capabilities. Thus the described behavior and extensions 205 to RSVP allow LERs and LSRs to implement either or both methods. 207 While the two methods could in principle be used in a single 208 network, it is expected that operators will continue to choose to 209 deploy either one or the other. The goal of this draft is to 210 standardize the RSVP signaling such that either a network with LSRs 211 that implement both methods or an network composed of some LSRs 212 that support one method and others that support both, can properly 213 signal among those LSRs to achieve fast restoration through the 214 chosen method. 216 3. Terminology 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 220 document are to be interpreted as described in RFC2119 [RFC-WORDS]. 222 The reader is assumed to be familiar with the terminology in [RSVP] 223 and [RSVP-TE]. 225 LSR - Label Switch Router 227 LSP - An MPLS Label Switched Path. In this document, an LSP 228 will always refer to an explicitly routed LSP. 230 Local Repair - Techniques used to repair LSP tunnels quickly 231 when a node or link along the LSPs path fails. 233 PLR - Point of Local Repair. The head-end LSR of a backup tunnel 234 or a detour LSP. 236 One-to-one Backup - A local repair technique where a backup LSP 237 is separately created for each protected LSP at a PLR. 239 Facility Backup - A local repair technique where a bypass tunnel 240 is used to protect one or more protected LSPs which 241 traverse the PLR, the resource being protected and the 242 Merge Point in that order. 244 Protected LSP - An LSP is said to be protected at a given hop if 245 it has one or multiple associated backup tunnels originating 246 at that hop. 248 Detour LSP - The LSP that is used to re-route traffic around 249 a failure in one-to-one backup. 251 Bypass Tunnel - An LSP that is used to protect a set of LSPs 252 passing over a common facility. 254 Backup Tunnel - The LSP that is used to backup up one of the many 255 LSPs in many-to-one backup. 257 NHOP Bypass Tunnel - Next-Hop Bypass Tunnel. A backup tunnel 258 which bypasses a single link of the protected LSP. 260 NNHOP Bypass Tunnel - Next-Next-Hop Bypass Tunnel. A backup 261 tunnel which bypasses a single node of the protected LSP. 263 Backup Path - The LSP that is responsible for backing up one 264 protection LSP. A backup path refers to either a detour LSP 265 or a backup tunnel. 267 MP - Merge Point. The LSR where one or more backup tunnels rejoin 268 the path of the protected LSP, downstream of the potential 269 failure. The same LSR may be both an MP and a PLR 270 simultaneously. 272 DMP - Detour Merge Point. In the case of one-to-one backup, 273 this is an LSR where multiple detours converge and only one 274 detour is signaled beyond that LSR. 276 Reroutable LSP - Any LSP for which the head-end LSR requests 277 local protection. See Section 10.1 for more detail. 279 CSPF - Constraint-based Shortest Path First. 281 SRLG Disjoint - A path is considered to be SRLG disjoint from a 282 given link or node if the path does not use any links or 283 nodes which belong to the same SRLG as that given link or 284 node. 286 4. Local Repair Techniques 288 Two different techniques for local protection are presented here. 289 The one-to-one backup technique has a PLR compute a separate backup 290 LSP, called a detour LSP, for each LSP which the PLR protects using 291 this technique. With the facility backup technique, the PLR creates 292 a single bypass tunnel which can be used to protect multiple LSPs. 294 4.1. One-to-one backup 296 In the one-to-one technique, a label switched path is established 297 which intersects the original LSP somewhere downstream of the point 298 of link or node failure. For each LSP which is backed up, a 299 separate backup LSP is established. 301 [R1]---[R2]-----[R3]----[R4]---[R5] 302 \ \ \ / \ / 303 [R6]---[R7]-------[R8]----[R9] 305 Protected LSP: [R1->R2->R3->R4->R5] 306 R1's Backup: [R1->R6->R7->R8->R3] 307 R2's Backup: [R2->R7->R8->R4] 308 R3's Backup: [R3->R8->R9->R5] 309 R4's Backup: [R4->R9->R5] 311 Example 1: One-to-One Backup Technique 313 In the simple topology shown above in Example 1, the protected LSP 314 runs from R1 to R5. R2 can provide user traffic protection by 315 creating a partial backup LSP which merges with the protected LSP 316 at R4. We refer to a partial one-to-one backup LSP 317 [R2->R7->R8->R4] as a detour. 319 To fully protect an LSP that traverses N nodes, there could be as 320 many as (N - 1) detours. The paths for the detours necessary to 321 fully protect the LSP in Example 1 are given there. To minimize 322 the number of LSPs in the network, it is desirable to merge a 323 detour back to its protected LSP when feasible. When a detour LSP 324 intersects its protected LSP at an LSR with the same outgoing 325 interface, it will be merged. 327 When a failure occurs along the protected LSP, the PLR redirects 328 traffic onto the local detour. For instance, if the link [R2->R3] 329 fails in Example 1, R2 will switch traffic received from R1 onto 330 the protected LSP along link [R2->R7] using the label received when 331 R2 created the detour. When R4 receives traffic with the label 332 provided for R2's detour, R4 will switch that traffic onto link 334 [R4-R5] using the label received from R5 for the protected LSP. At 335 no point does the depth of the label stack increase as a result of 336 taking the detour. While R2 is using its detour, traffic will take 337 the path [R1->R2->R7->R8->R4->R5]. 339 4.2. Facility backup 341 The facility backup technique takes advantage of the MPLS label 342 stack. Instead of creating a separate LSP for every backed-up LSP, a 343 single LSP is created which serves to backup up a set of LSPs. We 344 call such an LSP tunnel a bypass tunnel. 346 The bypass tunnel must intersect the path of the original LSP(s) 347 somewhere downstream of the PLR. Naturally, this constrains the 348 set of LSPs being backed-up via that bypass tunnel to those that 349 pass through some common downstream node. All LSPs which pass 350 through the point of local repair and through this common node 351 which do not also use the facilities involved in the bypass tunnel 352 are candidates for this set of LSPs. 354 [R8] 355 \ 356 [R1]---[R2]----[R3]----[R4]---[R5] 357 \ / \ 358 [R6]===[R7] [R9] 360 Protected LSP 1: [R1->R2->R3->R4->R5] 361 Protected LSP 2: [R8->R2->R3->R4] 362 Protected LSP 3: [R2->R3->R4->R9] 363 Bypass LSP Tunnel: [R2->R6->R7->R4] 365 Example 2: Facility Backup Technique 367 In Example 2, R2 has built a bypass tunnel which protects against the 368 failure of link [R2->R3] and node [R3]. The doubled lines represent 369 this tunnel. The scalability improvement this technique provides is 370 that the same bypass tunnel can also be used to protect LSPs from any 371 of R1, R2 or R8 to any of R4, R5 or R9. Example 2 describes three 372 different protected LSPs which are using the same bypass tunnel for 373 protection. 375 As with the one-to-one technique, to fully protect an LSP that 376 traverses N nodes, there could be as many as (N-1) bypass tunnels. 377 However, each of those bypass tunnels could protected a set of 378 LSPs. 380 When a failure occurs along a protected LSP, the PLR redirects 381 traffic into the appropriate bypass tunnel. For instance, if link 382 [R2->R3] fails in Example 2, R2 will switch traffic received from 383 R1 on the protected LSP onto link [R2->R6]; the label will be 384 switched for one which will be understood by R4 to indicate the 385 protected LSP and then the bypass tunnel's label will be pushed 386 onto the label-stack of the redirected packets. If 387 penultimate-hop-popping is used, then the merge point in Example 2, 388 R4, will receive the redirected packet with a label indicating the 389 protected LSP that the packet is to follow. If 390 penultimate-hop-popping is not used, then R4 will pop the bypass 391 tunnel's label and examine the label underneath to determine the 392 protected LSP that the packet is to follow. When R2 is using the 393 bypass tunnel for protected LSP 1, the traffic takes the path 394 [R1->R2->R6->R7->R4->R5]; the bypass tunnel is the connection 395 between R2 and R4. 397 5. RSVP Extensions 399 We propose two additional objects, FAST_REROUTE and DETOUR, to 400 extend RSVP-TE for fast-reroute signaling. These new objects are 401 backward compatible with LSRs that do not recognize them (see 402 section 3.10 in [RSVP]). Both objects can only be carried in RSVP 403 Path messages. 405 The SESSION_ATTRIBUTE and RECORD_ROUTE objects are also extended to 406 support bandwidth and node protection features. 408 5.1. FAST_REROUTE Object 410 The FAST-REROUTE object is used to control the backup used for the 411 protected LSP. This specifies the setup and hold priorities, the 412 session attribute filters, and bandwidth to be used for protection. 413 It also allows a specific local protection technique to be requested. 414 This object MUST only be inserted into the PATH message by the 415 head-end LER and MUST NOT be changed by downstream LSRs. The 416 FAST-REROUTE object has the following format: 418 Class-Num = 205 419 C-Type = 1 421 0 1 2 3 422 +-------------+-------------+-------------+-------------+ 423 | Length (bytes) | Class-Num | C-Type | 424 +-------------+-------------+-------------+-------------+ 425 | Setup Prio | Hold Prio | Hop-limit | Flags | 426 +-------------+-------------+-------------+-------------+ 427 | Bandwidth | 428 +-------------+-------------+-------------+-------------+ 429 | Include-any | 430 +-------------+-------------+-------------+-------------+ 431 | Exclude-any | 432 +-------------+-------------+-------------+-------------+ 433 | Include-all | 434 +-------------+-------------+-------------+-------------+ 436 Setup Priority 438 The priority of the backup path with respect to taking 439 resources, in the range of 0 to 7. The value 0 is the highest 440 priority. Setup Priority is used in deciding whether 441 this session can preempt another session. See [RSVP-TE] for 442 the usage on priority. 444 Holding Priority 446 The priority of the backup path with respect to holding 447 resources, in the range of 0 to 7. The value 0 is the highest 448 priority. Holding Priority is used in deciding whether this 449 session can be preempted by another session. See [RSVP-TE] for 450 the usage on priority. 452 Hop-limit 454 The maximum number of extra hops the backup path is allowed 455 to take, from current node (a PLR) to a MP, with PLR and MP 456 excluded in counting. For example, hop-limit of 0 means only 457 direct links between PLR and MP can be considered. 459 Flags 461 0x01 One-to-one Backup Desired 463 Indicates that protection via the one-to-one backup 464 technique is desired. 466 0x02 Facility Backup Desired 468 Indicates that protection via the facility backup 469 technique is desired. 471 Bandwidth 473 Bandwidth estimate (32-bit IEEE floating point integer) in 474 bytes-per-second. 476 Exclude-any 478 A 32-bit vector representing a set of attribute filters 479 associated with a backup path any of which renders a link 480 unacceptable. 482 Include-any 484 A 32-bit vector representing a set of attribute filters 485 associated with a backup path any of which renders a link 486 acceptable (with respect to this test). A null set (all bits 487 set to zero) automatically passes. 489 Include-all 491 A 32-bit vector representing a set of attribute filters 492 associated with a backup path all of which must be present for 493 a link to be acceptable (with respect to this test). A null set 494 (all bits set to zero) automatically passes. 496 The two high-order bits of the Class-Num (11) indicate that nodes 497 that do not understand the object should ignore it and pass if 498 forward unchanged. 500 For informational purposes, a different C-type value and format for 501 the FAST_REROUTE object are specified below. This is used by 502 legacy implementations. The meaning of the fields is the same as 503 described for C-Type 1. 505 C-Type = 7 507 0 1 2 3 508 +-------------+-------------+-------------+-------------+ 509 | Length (bytes) | Class-Num | C-Type | 510 +-------------+-------------+-------------+-------------+ 511 | Setup Prio | Hold Prio | Hop-limit | Reserved | 512 +-------------+-------------+-------------+-------------+ 513 | Bandwidth | 514 +-------------+-------------+-------------+-------------+ 515 | Include-any | 516 +-------------+-------------+-------------+-------------+ 517 | Exclude-any | 518 +-------------+-------------+-------------+-------------+ 520 5.2. DETOUR Object 522 The DETOUR object is used in one-to-one backup to identify detour 523 LSPs. It has the following format: 525 Class-Num = 63 527 5.2.1 DETOUR object for IPv4 address 529 C-Type = 7 531 0 1 2 3 532 +-------------+-------------+-------------+-------------+ 533 | Length (bytes) | Class-Num | C-Type | 534 +-------------+-------------+-------------+-------------+ 535 | PLR ID 1 | 536 +-------------+-------------+-------------+-------------+ 537 | Avoid Node ID 1 | 538 +-------------+-------------+-------------+-------------+ 539 // .... // 540 +-------------+-------------+-------------+-------------+ 541 | PLR ID n | 542 +-------------+-------------+-------------+-------------+ 543 | Avoid Node ID n | 544 +-------------+-------------+-------------+-------------+ 546 PLR ID (1 - n) 548 IPv4 address identifying the beginning point of detour which is 549 a PLR. Any local address on the PLR can be used. 551 Avoid Node ID (1 - n) 553 IP address identifying the immediate downstream node that 554 the PLR is trying to avoid. Router ID of downstream node 555 is preferred. This field is mandatory, and is used by 556 the MP for merging rules discussed below. 558 5.2.2 DETOUR object for IPv6 address 560 C-Type = 8 562 0 1 2 3 563 +-------------+-------------+-------------+-------------+ 564 | Length (bytes) | Class-Num | C-Type | 565 +-------------+-------------+-------------+-------------+ 566 | PLR ID 1 | 567 +-------------+-------------+-------------+-------------+ 568 | PLR ID 1 (continued) | 569 +-------------+-------------+-------------+-------------+ 570 | PLR ID 1 (continued) | 571 +-------------+-------------+-------------+-------------+ 572 | PLR ID 1 (continued) | 573 +-------------+-------------+-------------+-------------+ 574 | Avoid Node ID 1 | 575 +-------------+-------------+-------------+-------------+ 576 | Avoid Node ID 1 (continued) | 577 +-------------+-------------+-------------+-------------+ 578 | Avoid Node ID 1 (continued) | 579 +-------------+-------------+-------------+-------------+ 580 | Avoid Node ID 1 (continued) | 581 +-------------+-------------+-------------+-------------+ 582 // .... // 583 +-------------+-------------+-------------+-------------+ 585 PLR ID (1 - n) 587 A 128-bit unicast host address identifying the beginning point 588 of detour which is a PLR. Any local address on the PLR can be 589 used. 591 Avoid Node ID (1 - n) 593 A 128-bit unicast host address identifying the immediate 594 downstream node that the PLR is trying to avoid. Router ID of 595 downstream node is preferred. This field is mandatory, and is 596 used by the MP for merging rules discussed below. 598 There can be more than one pair of (PLR_ID, Avoid_Node_ID) entries in 599 a DETOUR object. If detour merging is desired, after each merging 600 operation, the Detour Merge Point should combine all the merged 601 detours in the subsequent Path messages. 603 The high-order bit of the C-Class is zero; LSRs that do not support 604 the DETOUR objects MUST reject any Path message containing a DETOUR 605 object and send a PathErr to notify the PLR. This PathErr SHOULD 606 be generated as specified in [RSVP] for unknown objects with a 607 class-num of the form "0bbbbbbb". 609 5.3. SESSION_ATTRIBUTE Flags 611 To explicitly request bandwidth and node protection, two new flags 612 are defined in the SESSION_ATTRIBUTE object. 614 For both C-Type 1 and 7, the SESSION_ATTRIBUTE object currently has 615 the following flags defined: 617 Local protection desired: 0x01 619 This flag permits transit routers to use a local repair 620 mechanism which may result in violation of the explicit route 621 object. When a fault is detected on an adjacent downstream link 622 or node, a transit node may reroute traffic for fast service 623 restoration. 625 Label recording desired: 0x02 627 This flag indicates that label information should be included 628 when doing a route record. 630 SE Style desired: 0x04 632 This flag indicates that the tunnel ingress node may choose to 633 reroute this tunnel without tearing it down. A tunnel egress 634 node SHOULD use the SE Style when responding with a Resv 635 message. When requesting fast reroute, the head-end LSR 636 SHOULD set this flag; this is not necessary for the 637 path-specific method of the one-to-one backup technique. 639 The following new flags are defined: 641 Bandwidth protection desired: 0x08 643 This flag indicates to the PLRs along the protected LSP path 644 that a backup path with a bandwidth guarantee is desired. 646 The bandwidth to be guaranteed is that of the protected 647 LSP, if no FAST_REROUTE object is included in the PATH message; 648 if a FAST_REROUTE object is in the PATH message, then the 649 bandwidth specified therein is that to be guaranteed. 651 Node protection desired: 0x10 653 This flag indicates to the PLRs along a protected LSP path 654 that a backup path which bypasses at least the next node of 655 the protected LSP is desired. 657 5.4. RRO IPv4/IPv6 Sub-Object Flags 659 To report whether bandwidth and/or node protection are provided as 660 requested, we define two news flags in the RRO IPv4 sub-object. 662 RRO IPv4 and IPv6 sub-object address: 664 These two sub-objects currently have the following flags defined: 666 Local protection available: 0x01 668 Indicates that the link downstream of this node is protected 669 via a local repair mechanism, which can be either one-to-one 670 or facility backup. 672 Local protection in use: 0x02 674 Indicates that a local repair mechanism is in use to maintain 675 this tunnel (usually in the face of an outage of the link it 676 was previously routed over, or an outage of the neighboring 677 node). 679 Two new flags are defined: 681 Bandwidth protection: 0x04 683 The PLR will set this when the protected LSP has a backup path 684 which is guaranteed to provide the desired bandwidth specified 685 in the FAST_REROUTE object or the bandwidth of the protected 686 LSP, if no FAST_REROUTE object was included. The PLR may set 687 this whenever the desired bandwidth is guaranteed; the PLR 688 MUST set this flag when the desired bandwidth is guaranteed 689 and the "bandwidth protection desired" flag was set in the 690 SESSION_ATTRIBUTE object. If the requested bandwidth is not 691 guaranteed, the PLR MUST NOT set this flag. 693 Node protection: 0x08 695 The PLR will set this when the protected LSP has a backup path 696 which provides protection against a failure of the next LSR 697 along the protected LSP. The PLR may set this whenever node 698 protection is provided by the protected LSP's backup path; the 699 PLR MUST set this flag when the node protection is provided 700 and the "node protection desired" flag was set in the 701 SESSION_ATTRIBUTE object. If node protection is not provided, 702 the PLR MUST NOT set this flag. Thus, if a PLR could only 703 setup a link-protection backup path, the "Local protection 704 available" bit will be set but the "Node protection" bit will 705 be cleared. 707 6. Head-End Behavior 709 The head-end of an LSP determines whether local protection should 710 be requested for that LSP and which local protection technique is 711 desired for the protected LSP. The head-end also determines what 712 constraints should be requested for the backup paths of a protected 713 LSP. 715 To indicate that an LSP should be locally protected, the head-end 716 LSR MUST either set the "Local protection desired" flag in the 717 SESSION_ATTRIBUTE object or include a FAST_REROUTE object in the 718 PATH message or both. It is recommended that the "local protection 719 desired" flag in the SESSION_ATTRIBUTE object always be set. If a 720 head-end LSR signals a FAST_REROUTE object, it MUST be stored for 721 Path refreshes. 723 The head-end LSR of a protected LSP MUST set the "label recording 724 desired" flag in the SESSION_ATTRIBUTE object. This facilitates 725 the use of the facility backup technique. If node protection is 726 desired, the head-end LSR should set the "node protection desired" 727 flag in the SESSION_ATTRIBUTE object; otherwise this flag should be 728 cleared. Similarly, if a guarantee of bandwidth protection is 729 desired, then the "bandwidth protection desired" flag in the 730 SESSION_ATTRIBUTE object should be set; otherwise, this flag should 731 be cleared. 733 If the head-end LSR determines that control of the backup paths for 734 the protected LSP is desired, then the LSR should include the 735 FAST_REROUTE object. The attribute filters, bandwidth, hop-limit 736 and priorities will be used by the PLRs when determining the backup 737 paths. 739 If the head-end LSR desires that the protected LSP be protected via 740 the one-to-one backup technique, then head-end LSR should include a 741 FAST_REROUTE object and set the "one-to-one backup desired" flag. 742 If the head-end LSR desires that the protected LSP be protected via 743 the facility backup technique, then the head-end LSR should include 744 a FAST_REROUTE object and set the "facility backup desired" flag. 745 The lack of a FAST_REROUTE object, or having both these flags 746 clear should be treated by PLRs as a lack of preference. If 747 both flags are set a PLR may use either method or both. 749 The head-end LSR of a protected LSP MUST support the additional 750 flags defined in Section 5.4 being set or clear in the RRO IPv4 and 751 IPv6 sub-objects. The head-end LSR of a protected LSP MUST support 752 the RRO Label sub-object. 754 If the head-end LSR of an LSP determines that local protection is 755 newly desired, this should be signaled via make-before-break. 757 7. Point of Local Repair Behavior 759 Every LSR along a protected LSP (except the egress) MUST follow the 760 PLR behavior described in this document. 762 A PLR SHOULD support the FAST_REROUTE object, the "local protection 763 desired", "label recording desired", "node protection desired" and 764 "bandwidth protection desired" flags in the SESSION_ATTRIBUTE 765 object, and the "local protection available", "local protection in 766 use", "bandwidth protection", and "node protection" flags in the 767 RRO IPv4 and IPv6 sub-objects. A PLR MAY support the DETOUR 768 object. 770 A PLR MUST consider an LSP as having asked for local protection if 771 the "local protection desired" flag is set in the SESSION_ATTRIBUTE 772 object and/or the FAST_REROUTE object is included. If the 773 FAST_REROUTE object is included, a PLR SHOULD consider providing 774 one-to-one protection if the "one-to-one desired" is set and SHOULD 775 consider providing facility backup if the "facility backup desired" 776 flag is set when determining whether to provide local protection 777 and which technique to use to provide that local protection. If 778 the "node protection desired" flag is set, the PLR SHOULD try to 779 provide node protection; if this is not feasible, the PLR SHOULD 780 then try to provide link protection. If the "bandwidth protection 781 guaranteed" flag is set, the PLR SHOULD try to provide a bandwidth 782 guarantee; if this is not feasible, the PLR SHOULD then try to 783 provide a backup without a guarantee of the full bandwidth. 785 The following treatment for the RRO IPv4 or IPv6 sub-object's flags 786 must be followed if an RRO is included in the protected LSP's RESV 787 message. Based on this additional information the head-end may 788 take appropriate actions. 790 - Until a PLR has a backup path available, the PLR MUST clear the 791 relevant four flags in the corresponding RRO IPv4 or IPv6 792 sub-object. 794 - Whenever the PLR has a backup path available, the PLR MUST set 795 the "local protection available" flag. If no established 796 one-to-one backup LSP or bypass tunnel exists, or the one-to-one 797 LSP and the bypass tunnel is in "DOWN" state, the PLR MUST clear 798 the "local protection available" flag in its IPv4 (or IPv6) 799 address subobject of the RRO and SHOULD send the updated RESV. 801 - The PLR MUST clear the "local protection in use" flag unless it 802 is actively redirecting traffic into the backup path instead of 803 along the protected LSP. 805 - The PLR SHOULD also set the "node protection" flag if the backup 806 path protects against the failure of the immediate downstream 807 node and, if not, the PLR SHOULD clear the "node protection" 808 flag. This MUST be done if the "node protection desired" flag 809 was set in the SESSION_ATTRIBUTE object. 811 - The PLR SHOULD set the "bandwidth protection" if the backup path 812 offers a bandwidth guarantee and, if not, SHOULD clear the 813 "bandwidth protection" flag. This MUST be done if the "bandwidth 814 protection desired" flag was set in the SESSION_ATTRIBUTE 815 object. 817 7.1 Signaling a Backup Path 819 A number of objectives must be met to obtain a satisfactory signaling 820 solution. These are summarized as follows: 822 1. Unambiguously and uniquely identify backup paths 823 2. Unambiguously associate protected LSPs with their backup paths 824 3. Work with both global and non-global label spaces 825 4. Allow for merging of backup paths 826 5. Maintain RSVP state during and after fail-over. 828 LSP tunnels are identified by a combination of the SESSION and 829 SENDER_TEMPLATE objects. The relevant fields are as follows. 831 IPv4 (or IPv6) tunnel end point address 833 IPv4 (or IPv6) address of the egress node for the tunnel. 835 Tunnel ID 837 A 16-bit identifier used in the SESSION that remains constant 838 over the life of the tunnel. 840 Extended Tunnel ID 842 A 32-bit (IPv4) or 128-bit (IPv6) identifier used in the SESSION 843 that remains constant over the life of the tunnel. Normally set 844 to all zeros. Ingress nodes that wish to narrow the scope of a 845 SESSION to the ingress-egress pair may place their IP address 846 here as a globally unique identifier. 848 IPv4 (or IPv6) tunnel sender address 850 IPv4 (or IPv6) address for a sender node 852 LSP ID 854 A 16-bit identifier used in the SENDER_TEMPLATE and the 855 FILTER_SPEC that can be changed to allow a sender to share 856 resources with itself. 858 The first three of these are in the SESSION object and are the basic 859 identification of the tunnel. Setting the "Extended Tunnel ID" to 860 an IP address of the head-end LSR allows the scope of the SESSION 861 to be narrowed to only LSPs sent by that LSR. A backup LSP is 862 considered to be part of the same session as its protected LSP; 863 therefore these three cannot be varied. 865 The last two are in the SENDER_TEMPLATE. Multiple LSPs in the same 866 SESSION may be protected and take different routes; this is common 867 when rerouting a tunnel using make-before-break. It is necessary 868 that a backup path be clearly identified with its protected LSP, so 869 that correct merging and state treatment can be done. Therefore, a 870 backup path must inherit its LSP ID from the associated protected 871 LSP. Thus, the only field in the SESSION and SENDER_TEMPLATE 872 objects which could be varied between a backup path and a protected 873 LSP is the "IPv4 (or IPv6) tunnel sender address" in the 874 SENDER_TEMPLATE. 876 There are two different methods to uniquely identify a backup 877 path. These are described below. 879 7.1.1. Backup Path Identification: Sender-Template-Specific 881 In this approach, the SESSION object and the LSP_ID are copied from 882 the protected LSP. The "IPv4 tunnel sender address" is set to an 883 address of the PLR. If the head-end of a tunnel is also acting as 884 the PLR, it MUST choose an IP address different from the one used 885 in the SENDER_TEMPLATE of the original LSP tunnel. 887 When using the sender-template-specific approach, the protected 888 LSPs and the backup paths SHOULD use the Shared Explicit (SE) 889 style. This allows bandwidth sharing between multiple backup 890 paths. The backup paths and the protected LSP MAY be merged by the 891 Detour Merge Points, when the ERO from the MP to the egress is the 892 same on each LSP to be merged, as specified in [RSVP-TE]. 894 7.1.2. Backup Path Identification: Path-Specific 896 In this approach, rather than varying the SESSION or 897 SENDER_TEMPLATE objects, a new object, the DETOUR object, is used 898 to distinguish between PATH messages for a backup path and the 899 protected LSP. 901 Thus, the backup paths use the same SESSION and SENDER_TEMPLATE 902 objects as the ones used in the protected LSP. The presence of 903 DETOUR object in Path messages signifies a backup path; the 904 presence of FAST_REROUTE object and/or the "local protection 905 requested" flag in the SESSION_ATTRIBUTE object indicates a 906 protected LSP. 908 In the path-message-specific approach, when an LSR receives 909 multiple Path messages which have the same SESSION and 910 SENDER_TEMPLATE objects and also have the same next-hop, that LSR 911 MUST merge the Path messages. Without this behavior, the multiple 912 RESV messages received back would not be distinguishable as to 913 which backup path each belongs to. This merging behavior does 914 reduce the total number of RSVP states inside the network at the 915 expense of merging LSPs with different EROs. 917 7.2 Procedures for Backup Path Computation 919 Before a PLR can create a detour or a bypass tunnel, the desired 920 explicit route must be determined. This can be done using a CSPF. 922 Before CSPF computation, the following information should be 923 collected at a PLR: 925 - The list of downstream nodes that the protected LSP passes 926 through. This information is readily available from the 927 RECORD_ROUTE objects during LSP setup. This information is also 928 available from the ERO. However, if the ERO contains loose 929 sub-objects, the ERO may not provide adequate information. 931 - The downstream links/nodes that we want to protect against. Once 932 again, this information is learned from the RECORD_ROUTE 933 objects. Whether node protection is desired is determined by 934 the "node protection" flag in the SESSION_ATTRIBUTE object and 935 local policy. 937 - The upstream uni-directional links that the protected LSP 938 passes through. This information is learned from the 939 RECORD_ROUTE objects; it is only needed for setting up 940 one-to-one protection. In the path-specific method, it is 941 necessary to avoid the detour and the protected LSP sharing 942 a common next-hop upstream of the failure. In the 943 sender-template-specific mode, this same restriction is 944 necessary to avoid sharing bandwidth between the detour and 945 its protected LSP, where that bandwidth has only been reserved 946 once. 948 - The link attribute filters to be applied. These are derived 949 from the FAST_REROUTE object, if included in the PATH message, 950 and the SESSION_ATTRIBUTE object otherwise. 952 - The bandwidth to be used is found in the FAST_REROUTE object, 953 if included in the PATH message, and in the SESSION_ATTRIBUTE 954 object otherwise. Local policy may modify the bandwidth to be 955 reserved. 957 - The hop-limit, if a FAST_REROUTE object was included in the 958 PATH message. 960 When applying a CSPF algorithm to compute the backup route, the 961 following constraints should be satisfied: 963 - For detour LSPs, the destination MUST be the tail-end of the 964 protected LSP; for bypass tunnels (Section 7), the destination 965 MUST be the address of the MP. 967 - When setting up one-to-one protection using the path-specific 968 method, a detour MUST not traverse the upstream links of the 969 protected LSP in the same direction. This prevents the 970 possibility of early merging of the detour into the protected 971 LSP. When setting up one-to-one protection using the 972 sender-template-specific method, a detour should not traverse 973 the upstream links of the protected LSP in the same direction; 974 this prevents sharing the bandwidth between a protected LSP 975 and its backup upstream of the failure where the bandwidth 976 would be used twice in the event of a failure. 978 - The backup LSP cannot traverse the downstream node and/or link 979 whose failure is being protected against. Note that if the 980 PLR is the penultimate hop, node protection is not possible 981 and only the downstream link can be avoided. The backup path 982 may be computed to be SRLG disjoint from the downstream node 983 and/or link being avoided. 985 - The backup path must satisfy the resource requirements of the 986 protected LSP. This includes the link attribute filters, 987 bandwidth, and hop limits determined from the FAST_REROUTE 988 object and SESSION_ATTRIBUTE object. 990 If such computation succeeds, the PLR should attempt to establish a 991 backup path. The PLR may schedule a re-computation at a later time 992 to discover better paths that may have emerged. If for any reason, 993 the PLR is unable to bring up a backup path, it must schedule a 994 retry at a later time. 996 7.3 Signaling Backups for One-To-One Protection 998 Once a PLR has decided to locally protect an LSP with one-to-one 999 backup, and has identified the desired path, it takes the following 1000 steps to signal the detour. 1002 The following describes the transformation to be performed upon the 1003 protected LSP's PATH message to create the detour LSP's PATH 1004 message. 1006 - If the sender-template specific method is to be used, then the 1007 PLR MUST change the "IPv4 (or IPv6) tunnel sender address" of the 1008 SENDER_TEMPLATE to an address belonging to the PLR that is not 1009 the same as was used for the protected LSP. Additionally, the 1010 DETOUR object MAY be added to the PATH message. 1012 - If the path-specific method is to be used, then the PLR MUST add 1013 a DETOUR object to the PATH message. 1015 - The SESSION_ATTRIBUTE flags "Local protection desired", 1016 "Bandwidth protection desired" and "Node protection desired" MUST 1017 be cleared. The "Label recording desired" flag MAY be modified. 1018 If the Path Message contained a FAST_REROUTE object, and the ERO 1019 is not completely strict, the Include-any, Exclude-any, and 1020 Include-all fields of the FAST_REROUTE object SHOULD be copied to 1021 the corresponding fields of the SESSION_ATTRIBUTE object. 1023 - If the protected LSP's Path message contained a FAST_REROUTE 1024 object, this MUST be removed from the detour LSP's PATH message. 1026 - The PLR MUST generate an EXPLICIT_ROUTE object toward the egress. 1027 First, the PLR must remove all sub-objects preceding the first 1028 address belonging to the Merge Point. Then the PLR SHOULD add 1029 sub-objects corresponding to the desired backup path between the 1030 PLR and the MP. 1032 - The SENDER_TSPEC object SHOULD contain the bandwidth information 1033 from the received FAST_REROUTE object, if included in the 1034 protected LSP's PATH message. 1036 - The RSVP_HOP object containing one of the PLR's IP address. 1038 - The detour LSPs MUST use the same reservation style as the 1039 protected LSP. This must be correctly reflected in the 1040 SESSION_ATTRIBUTE object. 1042 Detour LSPs are regular LSPs in operation. Once a detour path is 1043 successfully computed and the detour LSP is established, the PLR 1044 need not compute detour routes again, unless (1) the contents of 1045 FAST_REROUTE have changed, or (2) the downstream interface and/or 1046 the nexthop router for a protected LSP have changed. The PLR may 1047 recompute detour routes at any time. 1049 7.3.1 Make-Before-Break with Detour LSPs 1051 If the sender-template specific method is used, it is possible to 1052 do make-before-break with detour LSPs. This is done by using two 1053 different IP addresses belonging to the PLR (which were not used in 1054 the SENDER_TEMPLATE of the protected LSP). If the current detour 1055 LSP uses the first IP address in its SENDER_TEMPLATE, then the new 1056 detour LSP should be signaled using the second IP address in its 1057 SENDER_TEMPLATE. Once the new detour LSP has been created, the 1058 current detour LSP can be torn down. By alternating the use of 1059 these IP addresses, the current and new detour LSPs will have 1060 different SENDER_TEMPLATES and, thus, different state in the 1061 downstream LSRs. 1063 This make-before-break mechanism, changing the PLR IP address in 1064 the DETOUR object instead, is not feasible with the path-specific 1065 method because the PATH messages for new and current detour LSPs 1066 may be merged if they share a common next-hop. 1068 7.3.2 Message Handling 1069 LSRs must process the detour LSPs independent of the protected LSPs 1070 to avoid triggering the LSP loop detection procedure described in 1071 [RSVP-TE]. 1073 The PLR MUST not mix the messages for the protected and the detour 1074 LSPs. When a PLR receives Resv, ResvTear and PathErr messages from 1075 the downstream detour destination, the messages MUST not be forwarded 1076 upstream. Similarly, when a PLR receives ResvErr and ResvConf 1077 messages from a protected LSP, it MUST not propagate them onto the 1078 associated detour LSP. 1080 A session tear-down request is normally originated by the sender via 1081 PathTear messages. When a PLR node receives a PathTear message from 1082 upstream, it MUST delete both the protected and the detour LSPs. The 1083 PathTear messages MUST propagate to both protected and detour LSPs. 1085 During error conditions, the LSRs may send ResvTear messages to fix 1086 problems on the failing path. When a PLR node receives the ResvTear 1087 messages from downstream for a protected LSP, as long as a detour is 1088 up, the ResvTear messages MUST not be sent further upstream. 1089 PathErrs should be treated similiarly. 1091 7.3.3 Local Reroute of Traffic onto Detour LSP 1093 When the PLR detects a failure on the protected LSP, the PLR MUST 1094 rapidly switch packets to the protected LSP's backup LSP instead of 1095 the protected LSP's normal out-segment. The goal of this technique 1096 is to effect the redirection within 10s of milliseconds. 1098 L32 L33 L34 L35 1099 R1-------R2-------R3-------R4-------R5 1100 | | 1101 L46 | L47 | L44 1102 R6---------------R7 1104 Protected LSP: [R1->R2->R3->R4->R5] 1105 Detour LSP: [R2->R6->R7->R4] 1107 Example 3: Redirect to Detour 1109 In Example 3 above, if the link [R2->R3] fails, then R2 would do 1110 the following. Any traffic received on link [R1->R2] with label 1111 L32 would be sent out link [R2->R6] with label L46 (along the 1112 detour LSP) instead of out link [R3->R4] with lable L34 (along the 1113 protected LSP). The Merge Point, R4, would recognize that packets 1114 received on link [R7->R4] with label L44 should be sent out link 1115 [R4->R5] with label L35, and thus merged with the protected LSP. 1117 7.4 Signaling for Facility Protection 1119 A PLR may use one or more bypass tunnels to protect against the 1120 failure of a link and/or a node. These bypass tunnels may be 1121 setup in advance or may be dynamically created as new protected 1122 LSPs are signaled. 1124 7.4.1. Discovering Downstream Labels 1126 To support facility backup, it is necessary for the PLR to 1127 determine a label which will indicate to the MP that packets 1128 received with that label should be switched along the protected 1129 LSP. This can be done without explicitly signaling the backup path 1130 if the MP uses a label space global to that LSR. 1132 As described in Section 6, the head-end LSR MUST set the "label 1133 recording requested" flag in the SESSION_ATTRIBUTE object for LSPs 1134 requesting local protection. This will cause (as specified in 1135 [RSVP- TE]) all LSRs to record their INBOUND labels and to note via 1136 a flag if the label is global to the LSR. Thus, when a protected 1137 LSP is first signaled through a PLR, the PLR can examine the RRO in 1138 the Resv message and learn about the incoming labels that are used 1139 by all downstream nodes for this LSP. 1141 When MPs use per-interface-label spaces, the PLR must send Path 1142 messages (for each protected LSP using a bypass tunnel) via that 1143 bypass tunnel prior to the failure in order to discover the 1144 appropriate MP label. The signaling procedures for this are in 1145 Section 7.4.3 below. 1147 7.4.2. Procedures for the PLR before Local Repair 1149 A PLR which determines to use facility-backup to protect a given 1150 LSP should select a bypass tunnel to use taking into account 1151 whether node protection is to be provided, what bandwidth was 1152 requested and whether a bandwidth guarantee is desired, and what 1153 link attribute filters were specified in the FAST_REROUTE object. 1154 The selection of a bypass tunnel for a protected LSP is performed 1155 by the PLR when the LSP is first setup. 1157 7.4.3. Procedures for the PLR during Local Repair 1159 When the PLR detects a link or/and node failure condition, it needs 1160 to reroute the data traffic onto the bypass tunnel and to start 1161 sending the control traffic for the protected LSP onto the bypass 1162 tunnel. 1164 The backup tunnel is identified using the sender-template-specific 1165 method. The procedures to follow are similar to those described in 1166 Section 7.3. 1168 - The SESSION is unchanged. 1170 - The SESSION_ATTRIBUTE is unchanged except as follows: 1171 The "Local protection desired", "Bandwidth protection desired", 1172 and "Node protection desired" flags SHOULD be cleared. 1173 The "Label recording desired" MAY be modified. 1175 - The IPv4 (or IPv6) tunnel sender address of the SENDER_TEMPLATE 1176 is set to an address belonging to the PLR. 1178 - The RSVP_HOP object MUST contain an IP source address 1179 belonging to the PLR. Consequently, the MP will send messages 1180 back to the PLR using as a destination that IP address. 1182 - The PLR MUST generate an EXPLICIT_ROUTE object toward the 1183 egress. Detailed ERO processing is described below. 1185 - The RRO object may need to be updated, as described in Section 1186 7.5. 1188 The PLR sends Path, PathTear, and ResvConf messages via the backup 1189 tunnel. The MP sends Resv, ResvTear, and PathErr messages by 1190 directly addressing them to the address in the RSVP_HOP object 1191 contents as specified in [RSVP]. 1193 If it is necessary to signal the backup prior to failure to 1194 determine the MP label to use, then the same Path message is sent. 1195 In this case, the PLR SHOULD continue to send Path messages for the 1196 protected LSP along the normal route. PathTear messages should be 1197 duplicated, with one sent along the normal route and one sent thru 1198 the bypass tunnel. The MP should duplicate the Resv and ResvTear 1199 messages and sent them to both the PLR and the LSR indicated by the 1200 protected LSP's RSVP_HOP object. 1202 7.4.4. Processing backup tunnel's ERO 1204 Procedures for ERO processing are described in [RSVP-TE]. This 1205 section describes additional ERO update procedures for Path messages 1206 which are sent over bypass tunnels. If normal ERO processing rules 1207 were followed, the Merge Point would examine the first sub-object and 1208 likely reject it (Bad initial sub-object). This is because the 1209 unmodified ERO might contain the IP address of a bypassed node (in 1210 the case of a NNHOP Backup Tunnel), or of an interface which is 1211 currently down (in the case of a NHOP Backup Tunnel). For this 1212 reason, the PLR invoke the following ERO procedures before sending a 1213 Path message via a bypass tunnel. 1215 Sub-objects belonging to abstract nodes which precede the Merge Point 1216 are removed, along with the first sub-object belonging to the MP. A 1217 sub-object identifying the Backup Tunnel destination is then added. 1219 More specifically, the PLR MUST: 1221 - remove all the sub-objects proceeding the first address belonging 1222 to the MP. 1224 - replace this first MP address with an IP address of the MP. 1225 (Note that this could be same address that was just removed.) 1227 7.5. PLR Procedures During Local Repair 1229 In addition to the technique specific signaling and packet 1230 treatment, there is common signaling which should be followed. 1232 During fast reroute, for each protected LSP containing an RRO 1233 object, the PLR obtains the RRO from the protected LSP's stored 1234 RESV. The PLR MUST update the IPv4 or IPv6 sub-object it inserted 1235 into the RRO by setting the "Local protection in use" and "Local 1236 Protection Available" flags. 1238 7.5.1. Notification of local repair 1240 In many situations, the route used during a Local Repair will be less 1241 than optimal. The purpose of Local Repair is to keep high priority 1242 and loss sensitive traffic flowing while a more optimal re-routing of 1243 the tunnel can be effected by the head-end of the tunnel. Thus the 1244 head-end needs to know of the failure so it may re-signal an LSP 1245 which is optimal. 1247 To provide this notification, the PLR SHOULD send a Path Error 1248 message with error code of "Notify" (Error code =25) and an error 1249 value field of ss00 cccc cccc cccc where ss=00 and the sub-code = 3 1250 ("Tunnel locally repaired") (see [RSVP-TE]) 1252 Additionally a head-end may also detect that an LSP needs to be moved 1253 to a more optimal path by noticing failures reported via the IGP. 1254 Note that in the case of inter-area TE LSP (TE LSP spanning areas), 1255 the head-end LSR will need to rely exclusively on Path Error messages 1256 to be informed of failures in another area. 1258 7.5.2 Revertive Behavior 1260 Upon a failure event, a protected TE LSP is locally repaired by the 1261 PLR. There are two basic strategies for restoring the TE LSP to a 1262 full working path. 1264 - Global revertive mode: The head-end LSR of each tunnel is 1265 responsible for reoptimizing the TE LSPs that used the failed 1266 resource. There are several potential reoptimization triggers - 1267 RSVP error messages, inspection of OSPF LSAs or ISIS LSPs, and 1268 timers. Note that this re-optimization process may proceed as 1269 soon as the failure is detected. It is not tied to the 1270 restoration of the failed resource. 1272 - Local revertive mode: Upon detecting that the resource is 1273 restored, the PLR re-signals each of TE LSPs that used to be 1274 routed over the restored resource. Every TE LSP successfully 1275 resignaled along the restored resource is switched back. 1277 There are several circumstances where a local revertive mode might 1278 not be desirable. In the case of resource flapping (not an uncommon 1279 failure type), this could generate multiple traffic disruptions. 1280 Therefore, in the local revertive mode, the PLR should implement a 1281 means to dampen the re-signaling process in order to limit 1282 potential disruptions due to flapping. 1284 In the local revertive mode, any TE LSP will be switched back, 1285 without any distinction, as opposed to the global revertive mode 1286 where the decision to reuse the restored resource is taken by the 1287 head-end LSR based on the TE LSP attributes. When the head-end 1288 learns of the failure, it may reoptimize the protected LSP tunnel 1289 along a different and more optimal path, because it has a more 1290 complete view of the resources and TE LSP constraints; this means 1291 that the old LSP which has been reverted to may not be optimal any 1292 longer. Note that in the case of inter-area LSP, where the TE LSP 1293 path computation might be done on some Path Computation Server, the 1294 reoptimization process can still be triggered on the Head-End 1295 LSP. The local revertive mode is optional. 1297 However, there are circumstances where the Head-end does not have 1298 the ability to reroute the TE LSP (e.g if the protected LSP is 1299 pinned down, as may be desirable if the paths are determined using 1300 an off-line optimization tool) or if Head-end does not have the 1301 complete TE topology information (depending on the path computation 1302 scenario). In those cases, the local revertive might be a 1303 interesting option. 1305 It is recommended that one always use the globally revertive mode. 1306 Note that a link or node "failure" may be due to the facility being 1307 permanently taken out of service. Local revertive mode is 1308 optional. When used in combination, the global mode may rely 1309 solely on timers to do the reoptimization. When local revertive 1310 mode is not used, head-end LSRs SHOULD react to RSVP error messages 1311 and/or IGP indications in order to make a timely response. 1313 Interoperability: If a PLR is configured with the local revertive 1314 mode but the MP is not, any attempt from the PLR to resignal the TE 1315 LSP over the restored resource would fail as the MP will not send 1316 any Resv message. The PLR will still refresh the TE LSP over the 1317 backup tunnel. The TE LSP will not revert to the restored resource; 1318 instead it will continue to use the backup until it is 1319 re-optimized. 1321 8. Merge Node Behavior 1323 An LSR is a Merge Point if it receives the Path message for a 1324 protected LSP and one or more messages for a backup LSP which is 1325 merged into that protected LSP. In the one-to-one backup 1326 technique, the LSR is aware that it is a merge node prior to 1327 failure. In the facility backup technique, the LSR may not know 1328 that it is a Merge Point until a failure occurs and it receives a 1329 backup LSP's Path message. Therefore, an LSR which is on the path 1330 of a protected LSP SHOULD always assume that it is a merge point. 1332 When a MP receives a backup LSP's Path message thru a bypass 1333 tunnel, the Send_TTL in the Common Header may not match the TTL of 1334 the IP packet within which the Path message was transported. This 1335 is expected behavior. 1337 8.1. Handling Backup Path Messages Before Failure 1339 There are two circumstances where a Merge Point will receive Path 1340 messages for a backup path prior to failure. In the first case, if 1341 a PLR is providing local protection via the one-to-one backup 1342 technique, the detour will be signaled and must be properly handled 1343 by the MP. In this case, the backup LSP may be signaled via the 1344 sender-template-specific method or via the path-specific method. 1346 In the second case, if the Merge Point does not provide labels 1347 global to the MP and record them in a Label sub-object of the RRO 1348 or if the PLR does not use such recorded information, the PLR may 1349 signal the backup path, as described above in Section 7.4.1, to 1350 determine the label to use if the PLR is providing protection 1351 according to the facility backup technique. In this case, the 1352 backup LSP is signaled via the sender-template-specific method. 1354 The reception of a backup LSP's path message does not indicate that 1355 a failure has occured and the incoming protected LSP will no longer 1356 be used. 1358 8.1.1. Merginging Backup Paths using the Sender-Template Specific Method 1360 An LSR may receive multiple Path messages for one or more backup 1361 LSPs and, possibly, the protected LSP. Each of these Path messages 1362 will have a different SENDER_TEMPLATE. The protected LSP can be 1363 recognized because it will either include the FAST_REROUTE object, 1364 have the "local protection desired" flag set in the 1365 SESSION_ATTRIBUTE object or both. 1367 If the outgoing interface and next-hop LSR are the same, then the 1368 Path messages are eligible for merging. Similar to that specified 1369 in [RSVP-TE] for merging of RESV messages, only those Path messages 1370 whose ERO from that LSR to the egress is the same can be merged. 1371 If merging occurs and one of the Path messages merged was for the 1372 protected LSP, then the final Path message to be sent MUST be that 1373 of the protected LSP. This merges the backup LSPs into the 1374 protected LSP at that LSR. Once the final Path message has been 1375 identified, the MP MUST start to refresh it downstream 1376 periodically. 1378 If merging occurs and all the Path messages were for backup LSPs, 1379 then the DETOUR object, if any, should be altered as specified in 1380 Section 9.1 1382 8.1.2. Merging Detours using the Path-Specific Method 1384 An LSR (that is, an MP) may receive multiple Path messages from 1385 different interfaces with identical SESSION and SENDER_TEMPLATE 1386 objects. In this case, Path state merging is REQUIRED. 1388 The merging rule is the following: 1390 For all Path messages that do not have either a FAST_REROUTE or a 1391 DETOUR object, or the MP is the egress of the LSP, no merging is 1392 required. The messages are processed according to [RSVP-TE]. 1394 Otherwise, the MP MUST record the Path state as well as their 1395 incoming interface. If the Path messages do not share outgoing 1396 interface and next-hop LSR, the MP MUST consider them as independent 1397 LSPs, and MUST NOT merge them. 1399 For all the Path messages that share the same outgoing interface and 1400 next-hop LSR, the MP runs the following procedure to select one of 1401 them as the Path message to forward downstream. 1403 1. Eliminate from consideration those that traverse nodes that 1404 other Path messages want to avoid. 1406 2. If one LSP is originated from this node, this must be 1407 the final LSP. Quit. 1409 3. If only one Path message contains FAST_REROUTE object, this 1410 becomes the chosen Path message. Quit. 1412 4. If there are several LSPs, and not all of them have a DETOUR 1413 object, then eliminate those with DETOUR from consideration. 1415 5. If several candidates remain (that is, there are both detour 1416 and protected LSPs), prefer the ones with FAST_REROUTE object. 1418 6. If none found, prefer the ones without DETOUR object. If none 1419 found, prefer the ones with DETOUR object. 1421 7. If several candidate Path message still remain, it is a local 1422 decision to choose which one will be the final LSP. The decision 1423 can be based on the number of IP hops in ERO, bandwidth 1424 requirements, or others. 1426 Once the final Path message has been identified, the MP MUST start to 1427 refresh it downstream periodically. Other LSPs are considered merged 1428 at this node. For bandwidth reservation on the outgoing link, any 1429 merging should be considered to have occured before bandwidth is 1430 reserved. Thus, even though Fixed Filter is specified, multiple 1431 detours and/or their protected LSP which are to be merged due to 1432 sharing an outgoing interface and next-hop LSR will reserve only 1433 the bandwidth of the final Path message on that outgoing 1434 interface. 1436 8.1.2.1. An Example on Path Message Merging 1438 R7---R8---R9-\ 1439 | | | \ 1440 R1---R2---R3---R4---R5---R6 1441 Protected LSP: [R1->R2->R3->R4->R5->R6] 1442 R2's Detour: [R2->R7->R8->R9->R4->R5->R6] 1443 R3's Detour: [R3->R8->R9->R5->R6] 1445 Example 4: Path Message Merging 1447 In Example 4 above, R8 will receive Path messages that have the 1448 same SESSION and SENDER_TEMPLATE from detours for R2 and R3. 1449 During merging at R8 since detour R3 has a shorter ERO path length 1450 (that is, ERO is [R9->R5->R6], and path length is 3), R8 will 1451 select it as the final LSP, and only propagate its Path messages 1452 downstream. Upon receiving a Resv (or a ResvTear) message, R8 must 1453 relay on the messages toward both R2 and R3. 1455 R5 needs to merge as well, and will select the main LSP, since it 1456 has the FAST_REROUTE object. Thus, the detour LSP terminates at 1457 R5. 1459 8.1.3. Message Handling for Merged Detours 1461 When an LSR receives a ResvTear for an LSP, the LSR must determine 1462 whether it has an alternate associated LSP. For instance, if the 1463 ResvTear was received for a protected LSP, but an associated backup 1464 LSP has not received a ResvTear, then the LSR has an alternate 1465 associated LSP. If the LSR does not have an alternate associated 1466 LSP, then the MP MUST propogate the ResvTear toward the LSP's 1467 ingress and, for each backup LSP merged into that LSP at this LSR, 1468 the ResvTear SHOULD also be propogated along the backup LSP. 1470 The MP may receive PathTear messages for some of the merging LSPs. 1471 PathTear messages SHOULD NOT be propagated downstream until the MP 1472 has received PathTear messages for each of the merged LSPs. 1473 However, the fact that one or more of the merged LSPs has been torn 1474 down should be reflected in the downstream message, such as by 1475 changing the DETOUR object, if any. 1477 8.2. Handling Failures 1479 When a downstream LSR detects a local link failure, for any 1480 protected LSPs routed over the failed link, Path and Resv state 1481 MUST NOT be cleared and PathTear and ResvErr messages MUST NOT be 1482 sent immediately; if this is not the case, then the facility backup 1483 technique will not work. Further a downstream LSR SHOULD reset the 1484 refresh timers for these LSPs as if they had just been refreshed. 1485 This is to allow time for the PLR to begin refreshing state via the 1486 bypass tunnel. State MUST be removed if it has not been refreshed 1487 before the refresh timer expires. This allows the facility backup 1488 technique to work without requiring that it signal backup paths 1489 thru the bypass tunnel before failure. 1491 After a failure has occured, the MP must still send Resv messages 1492 for the backup LSPs associated with the protected LSPs which have 1493 failed. If the backup LSP was sent through a bypass tunnel, then 1494 the PHOP object in its Path message will have the IP address of the 1495 associated PLR. This will ensure that Resv state is refreshed. 1497 Once the local link has recovered, the MP may or may not accept 1498 Path messages for existing protected LSPs which had failed over to 1499 their backup. 1501 9. Behavior of all LSRs 1503 The objects defined and the techniques defined in this document 1504 require behavior from all LSRs in the traffic-engineered network, 1505 even if that LSR is not along the path of a protected LSP. 1507 First, if a DETOUR object is included in the backup LSP's path 1508 message for the sender-template-specific method, the LSRs in the 1509 traffic-engineered network should support the DETOUR object. 1511 Second, if the Path-Specific Method is to be supported for 1512 the one-to-one backup technique, it is necessary that the LSRs in 1513 the traffic-engineered network be capable of merging detours as 1514 specified below in Section 9.1. 1516 It is possible to avoid specific LSRs which do not support this 1517 behavior by assigning an link attribute to all the links of those 1518 LSPs and then requesting that backup paths exclude that link 1519 attribute. 1521 9.1. Merging Detours in Path-Specific Method 1523 If multiple Path Messages for different detours are received with 1524 the same SESSION, SENDER_TEMPLATE, outgoing interface and next-hop 1525 LSR, then the LSR must function as a Detour Merge Point and merge 1526 the detour Path Messages. This merging should occur as specified 1527 in Section 8.1.2 and shown in Example 4. 1529 In addition, it is necessary to update the DETOUR object to reflect 1530 the merging which has taken place. This is done using the 1531 following algorithm to format the outgoing DETOUR object for the 1532 final LSP: 1534 - Combine all the (PLR_ID, Avoid_Node_ID) pairs from all the 1535 DETOUR objects of all merged LSPs, and create a new object with 1536 all listed. Ordering is insignificant. 1538 10. Security Considerations 1540 This document does not introduce new security issues. The security 1541 considerations pertaining to the original RSVP protocol [RSVP] remain 1542 relevant. 1544 It should be noted that the facility backup technique requires that 1545 a PLR and its selected Merge Point will trust RSVP messages 1546 received from each other. 1548 11. IANA Section 1550 IANA [RFC-IANA] will assign RSVP Class-Num 205 for the 1551 FAST_REROUTE and RSVP Class-Num 63 for the DETOUR object. This 1552 matches the current usage in production networks. 1554 IANA will assign C-Type 1 for the standard FAST_REROUTE object 1555 format defined in section 5.1 and list C-Type 7 as reserved as it 1556 is still used by pre-standard implementations. 1558 IANA will assign C-Types 7 and 8 to the IPv4 and IPv6 DETOUR 1559 object formats as defined in section 5.2. 1561 12. Intellectual Property Considerations 1563 The IETF takes no position regarding the validity or scope of any 1564 intellectual property or other rights that might be claimed to 1565 pertain to the implementation or use of the technology described in 1566 this document or the extent to which any license under such rights 1567 might or might not be available; neither does it represent that it 1568 has made any effort to identify any such rights. Information on the 1569 IETF's procedures with respect to rights in standards-track and 1570 standards-related documentation can be found in BCP-11. Copies of 1571 claims of rights made available for publication and any assurances of 1572 licenses to be made available, or the result of an attempt made to 1573 obtain a general license or permission for the use of such 1574 proprietary rights by implementors or users of this specification can 1575 be obtained from the IETF Secretariat. 1577 The IETF has been notified of intellectual property rights 1578 claimed in regard to some or all of the specification contained 1579 in this document. For more information consult the online list 1580 of claimed rights. 1582 13. Full Copyright Statement 1584 Copyright (C) The Internet Society (2002). All Rights Reserved. 1586 This document and translations of it may be copied and furnished to 1587 others, and derivative works that comment on or otherwise explain it 1588 or assist in its implementation may be prepared, copied, published 1589 and distributed, in whole or in part, without restriction of any 1590 kind, provided that the above copyright notice and this paragraph are 1591 included on all such copies and derivative works. However, this 1592 document itself may not be modified in any way, such as by removing 1593 the copyright notice or references to the Internet Society or other 1594 Internet organizations, except as needed for the purpose of 1595 developing Internet standards in which case the procedures for 1596 copyrights defined in the Internet Standards process must be 1597 followed, or as required to translate it into languages other than 1598 English. 1600 The limited permissions granted above are perpetual and will not be 1601 revoked by the Internet Society or its successors or assigns. 1603 This document and the information contained herein is provided on an 1604 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1605 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1606 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1607 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1608 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1610 14. Acknowledgments 1612 We would like to acknowledge input and helpful comments from Rob 1613 Goguen, Tony Li, Yakov Rekhter and Curtis Villamizar. Especially, 1614 we thank those, who have been involved in interoperability testing 1615 and field trails, and provided invaluable ideas and suggestions. 1616 They are Rob Goguen, Carol Iturralde, Brook Bailey, Safaa Hasan, 1617 Richard Southern, and Bijan Jabbari. 1619 15. Normative References 1621 [RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP) 1622 -- version 1 functional specification," RFC2205, September 1997. 1624 [RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP 1625 tunnels", RFC3029, December 2001. 1627 [RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate 1628 Requirement Levels", RFC 2119, March 1997. 1630 [RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an 1631 IANA Considerations Section in RFCs", RFC 2434. 1633 16. Editor Information 1635 George Swallow 1636 Cisco Systems, Inc. 1637 300 Beaver Brook Road 1638 Boxborough, MA 01719 1639 USA 1640 email: swallow@cisco.com 1641 phone: +1 978 244 8143 1643 Ping Pan 1644 CIENA Corp. 1645 5965 Silver Creek Valley Road 1646 San Jose, CA 95138 1647 USA 1648 e-mail: ppan@ciena.net 1649 phone: +1 408 965 2707 1651 Alia Atlas 1652 Avici Systems 1653 101 Billerica Avenue 1654 N. Billerica, MA 01862 1655 USA 1656 email: aatlas@avici.com 1657 phone: +1 978 964 2070