idnits 2.17.1 draft-berger-ccamp-gmpls-segment-recovery-00.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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 5 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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.) -- The document date (February 2004) is 7376 days in the past. Is this intentional? 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: 'A' is mentioned on line 136, but not defined == Missing Reference: 'B' is mentioned on line 136, but not defined == Missing Reference: 'C' is mentioned on line 137, but not defined == Missing Reference: 'D' is mentioned on line 136, but not defined == Missing Reference: 'E' is mentioned on line 137, but not defined == Missing Reference: 'F' is mentioned on line 136, but not defined == Missing Reference: 'G' is mentioned on line 137, but not defined == Missing Reference: 'I' is mentioned on line 137, but not defined == Missing Reference: 'RFC2205' is mentioned on line 488, but not defined == Missing Reference: 'RFC2026' is mentioned on line 832, but not defined -- Possible downref: Normative reference to a draft: ref. 'E2E-RECOVERY' == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-lsp-fastreroute-03 == Outdated reference: A later version (-04) exists of draft-ietf-ccamp-gmpls-recovery-functional-01 == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-gmpls-recovery-terminology-02 Summary: 6 errors (**), 0 flaws (~~), 17 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Louis Berger (Movaz Networks) 2 Internet Draft Igor Bryskin (Movaz Networks) 3 Expiration Date: August 2004 Dimitri Papadimitriou (Alcatel) 4 Adrian Farrel (Old Dog Consulting) 6 February 2004 8 GMPLS Based Segment Recovery 10 draft-berger-ccamp-gmpls-segment-recovery-00.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-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 To view the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow 27 Directory, see http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes protocol specific procedures for GMPLS 32 (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource 33 ReserVation Protocol - Traffic Engineering) signaling extensions to 34 support LSP segment protection and restoration. These extensions are 35 intended to be compliment and be consistent with the Extensions for 36 End-to-End GMPLS-based Recovery. Implications and interactions with 37 Fast Reroute are also addressed. 39 Contents 41 1 Introduction .............................................. 3 42 2 Segment Recovery .......................................... 4 43 2.1 Segment Protection ........................................ 6 44 2.2 Segment Re-routing and Restoration ........................ 6 45 3 Association Object ........................................ 6 46 3.1 Format .................................................... 7 47 3.2 Procedures ................................................ 7 48 3.2.1 Resource Sharing Association Type Processing .............. 7 49 4 Explicit Control of LSP Segment Recovery .................. 8 50 4.1 Secondary Explicit Route Object Format .................... 8 51 4.1.1 Protection Subobject ...................................... 8 52 4.2 Explicit Control Procedures ............................... 9 53 4.2.1 Resv Message Processing ................................... 10 54 4.2.2 Branch Failure Handling ................................... 11 55 4.2.3 Admin Status Change ....................................... 11 56 4.2.4 Recovery LSP Tear Down .................................... 12 57 4.3 Tear Down From Non-Ingress Nodes .......................... 12 58 4.3.1 Modified Notify Request Object Processing ................. 13 59 4.3.2 Modified Notify and Error Message Processing .............. 13 60 5 Secondary Record Route Objects ............................ 14 61 5.1 Format .................................................... 14 62 5.2 Path Processing ........................................... 14 63 5.3 Resv Processing ........................................... 14 64 6 Dynamic Control of LSP Segment Recovery ................... 15 65 6.1 Modified Protection Object Format ......................... 15 66 6.2 Dynamic Control Procedures ................................ 16 67 7 Additional Fast Reroute Considerations .................... 17 68 8 Updated RSVP Message Formats .............................. 17 69 9 Security Considerations ................................... 19 70 10 IANA Considerations ....................................... 20 71 11 Intellectual Property Considerations ...................... 20 72 12 References ................................................ 21 73 12.1 Normative References ...................................... 21 74 12.2 Informative References .................................... 21 75 13 Contributors .............................................. 22 76 14 Full Copyright Statement .................................. 22 77 Conventions used in this document 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC 2119 [RFC2119]. 83 In addition, the reader is assumed to be familiar with the 84 terminology used in [RFC3209], [RFC3471], [RFC3473] as well as 85 [TERM], [FUNCT], [E2E-RECOVERY] and [FRR]. 87 1. Introduction 89 [TERM] covers multiple types of protection, including end-to-end and 90 segment based approaches. [E2E-RECOVERY], RSVP-TE Extensions in 91 support of End-to-End GMPLS-based Recovery, defines a set of 92 extensions to support multiple types of recovery. The supported 93 types include 1+1 unidirectional/ 1+1 bi-directional protection, LSP 94 protection with extra-traffic (including 1:N protection with extra- 95 traffic), pre-planned LSP re- routing without extra-traffic 96 (including shared mesh), and full LSP re-routing. In all cases, the 97 recovery is provided on an end-to-end basis, i.e., the ingress and 98 egress nodes of both the protected and the protecting LSP are the 99 same. 101 [FRR] provides a form of segment recovery for packet MPLS-TE 102 networks. Two methods of Fast Reroute are defined in [FRR]. The 103 one-to-one backup method creates detour LSPs for each protected LSP 104 at each potential point of local repair. The facility backup method 105 creates a bypass tunnel to protect a potential failure point which is 106 shared by multiple LSPs and uses label stacking. Neither approach 107 supports the full set of recovery types supported by [E2E-RECOVERY]. 108 Additionally, the facility backup method is not applicable to most 109 non-PSC (packet) switching technologies. 111 The extensions defined in this document allow for support of the full 112 set of recovery types supported by [E2E-RECOVERY] on a segment, or 113 portion of the LSP, basis. The extensions allow (a) the signaling of 114 desired LSP segment protection type, (b) upstream nodes to optionally 115 identify where segment protection starts and stops, and (c) to also 116 optionally identify hops used on protection segments. These 117 extensions are intended to be compatible with, and in some cases used 118 with Fast Reroute. 120 2. Segment Recovery 122 Segment recovery is used to provide protection and restoration over a 123 portion of an end-to-end LSP. Such segment protection and 124 restoration is useful to protect against a span failure, a node 125 failure, or failure over a particularly portion of a network used by 126 an LSP. 128 Consider the following topology: 129 A---B---C---D---E---F 130 \ / 131 G---I 133 In this topology, end-to-end protection and recovery is not possible 134 for an LSP going between node A and node F, but it is possible to 135 protect/recover a portion of the LSP. Specifically, if the LSP uses 136 a working path of [A,B,C,D,E,F] then a protection or restoration LSP 137 can be established along the path [C,G,I,E]. This LSP protects 138 against failures on spans {C,D} and {D,E} as well as a failure of 139 node D. This form of protection/restoration is referred to as 140 Segment Protection and Segment Restoration, or Segment Recovery 141 collectively. The LSP providing the protection or restoration is 142 referred to as a segment protection LSP or a segment restoration LSP. 143 The term segment recovery LSP is used to cover either a segment 144 protection LSP or a segment restoration LSP. The term branch node is 145 used to refer to a node that initiates a recovery LSP, e.g., node C 146 in the figure shown above. This is equivalent to the point of local 147 repair (PLR) used in [FRR]. As with [FRR], the term merge node is 148 used to refer to a node that terminates a recovery LSP, e.g., node E 149 in the figure shown above. 151 Segment protection or restoration is signaled using a working LSP and 152 one or more segment recovery LSPs. Each segment recovery LSP is 153 signaled as an independent LSP. Specifically, the Sender_Template 154 object uses the IP address of the node originating the recovery path, 155 e.g., node C in the topology shown above, and the Session object 156 contains the IP address of the node terminating the recovery path, 157 e.g., node E shown above. There is no specific requirement on LSP ID 158 value, Tunnel ID and Extended Tunnel ID. Values for these fields are 159 selected normally, including consideration for make-before-break. 160 Intermediate nodes follow standard signaling procedures when 161 processing segment recovery LSPs. A segment recovery LSP may be 162 protected itself using segment or end-to-end protection/restoration. 163 Note, in PSC environments it may be desirable to construct the 164 Sender_Template and Session objects per [FRR]. 166 When [FRR] isn't being used, the association between segment recovery 167 LSPs with other LSPs is indicated using the Association object 168 defined in [E2E-RECOVERY]. The Association object is used to 169 associate recovery LSPs with the LSP they are protecting. Working 170 and protecting LSPs, as well as primary and secondary LSPs, are 171 identified using LSP Status as described in [E2E-RECOVERY]. The 172 0-bit in the segment flags portion of the Protection object is used 173 to identify when a recovery LSP is carrying the normal (active) 174 traffic. 176 An upstream node can permit downstream nodes to dynamically identify 177 branch and merge points by setting the desired LSP segment protection 178 bits in the Protection object. These bits are defined below. 180 Optionally, an upstream node, usually the ingress node, can identify 181 the endpoints of a segment recovery LSP. This is accomplished using 182 a new object. This object uses the same format as an ERO and is 183 referred to as a Secondary Explicit Route object or SERO, see section 184 4.1. SEROs also support a new subobject to indicate the type of 185 protection or restoration to be provided. At a minimum an SERO will 186 indicate a recovery LSP's initiator, protection/restoration type and 187 terminator. Standard ERO semantics, see [RFC3209], can optionally be 188 used within and SERO to explicitly control the recovery LSP. A 189 Secondary Record Route object or SRRO is defined for recording the 190 path of a segment recovery LSP, see section 5. 192 SEROs are carried between the node creating the SERO, typically the 193 ingress, and the node initiating a recovery LSP. The node initiating 194 a recovery LSP uses the SERO to create the ERO for the recovery LSP. 195 At this (branch) node, all local objects are removed, and the new 196 protection subobject is used to create the Protection object for the 197 recovery LSP. SRROs are carried in Path messages between the node 198 terminating a recovery LSP, the merge node, and the egress. SRROs 199 are used in Resv messages between a branch node and the ingress. The 200 merge node of a recovery LSP creates an SRRO by copying the RRO from 201 the Path message of the associated recovery LSP into a new SRRO 202 object. Any SRROs present in the recovery LSP's Path message are 203 also copied. The branch node of a recovery LSP creates an SRRO by 204 copying the RRO from the Resv message of associated recovery LSP into 205 a new SRRO object. Any SRROs present in the recovery LSP's Resv 206 message are also copied. 208 Notify request processing is also impacted by LSP segment recovery. 209 Per [RFC3473], only one Notify Request object is meaningful and 210 should be propagated. Additional Notify Request objects are used to 211 identify recovery LSP branch nodes. 213 2.1. Segment Protection 215 Three approaches of end-to-end protection are defined in [E2E- 216 RECOVERY]: 1+1 Unidirectional Protection, see Section 5; 1+1 Bi- 217 directional Protection, see Section 6: and 1:1 Protection With Extra 218 Traffic, see Section 7. The segment protection forms of these 219 protection approaches all operate much like their end-to-end 220 counterparts. Each behaves just like there end-to-end counterparts, 221 with the exception that the protection LSP protects only a portion of 222 the working LSP. The type of protection to be used on a segment 223 protection LSP is indicated, to the protection LSP's ingress, using 224 the protection SERO subobject defined in Section 4.1. 226 The switch-over processing for segment 1+1 Bi-directional protection 227 and 1:1 Protection With Extra Traffic follows the same procedures as 228 end-to-end protection forms, see Section 6.2 and Section 7.2 for 229 details. 231 2.2. Segment Re-routing and Restoration 233 Three re-routing and restoration approaches are defined [E2E- 234 RECOVERY]: Re-routing without Extra-Traffic, see Section 8; Shared- 235 Mesh Restoration, see Section 9; (Full) LSP Re-routing, see Section 236 11. As with protection, these approaches are supported on a segment 237 basis. The segment forms of re-routing and restoration operate 238 exactly like their end-to-end counterparts, with the exception that 239 the restoration LSP recovers only a portion of the working LSP. The 240 type of re-routing or restoration to be used on a segment restoration 241 LSP is indicated, to the restoration LSP's ingress, using the new 242 protection SERO subobject. 244 3. Association Object 246 The Association object is used association of segment protection LSPs 247 when [FRR] isn't being used. The Association object is defined in 248 [E2E-RECOVERY]. In this document we define a new type to support 249 make before break, formats and procedures defined in [E2E-RECOVERY] 250 are not otherwise modified. 252 3.1. Format 254 Association Type: 16 bits 256 Value Type 257 ----- ---- 258 2 Resource Sharing (R) 260 See [E2E-RECOVERY] for the definition of other fields and other 261 values. 263 3.2. Procedures 265 The Association object is used to associate different LSPs with each 266 other. In the protection and restoration context, the object is used 267 to associate a recovery LSP with the LSP it is protecting. It is 268 also used to support resource sharing during make-before-break. This 269 object MUST NOT be used when association is made according to the 270 methods defined in [FRR]. 272 3.2.1. Resource Sharing Association Type Processing 274 The Association object with an Association Type with the value 275 Resource Sharing is used to enable resource sharing during make- 276 before-break. Resource sharing during make-before-break is defined 277 in [RFC3209]. The defined support only works with LSPs that share 278 the same LSP egress. With the introduction of segment recovery LSPs, 279 it is now possible for an LSP end-point to change during make-before- 280 break. 282 A node includes an Association object with a Resource Sharing 283 Association Type in outgoing an Path message when it wishes to 284 indicate resource sharing across an associated set of LSPs. The 285 Association Source is set to the branch node's router address. The 286 Association ID MUST be set to a value that uniquely identifies the 287 association of LSPs. This MAY be set to the upstream LSP's LSP ID. 288 Once included, an Association object with a Resource Sharing 289 Association Type SHOULD NOT be removed from the Path messages 290 associated with an LSP. 292 When a node is branching an LSP and the associated upstream Path 293 messages is received with an Association object with a Resource 294 Sharing type, the branch node inserts a new Association object with a 295 Resource Sharing type in the Path message of the new LSP. The 296 Association Source is set to the branch node's router address. The 297 Association ID MUST be set to a value that uniquely identifies the 298 association of LSPs. This MAY be set to the recovery LSP's LSP ID. 300 Any node processing a Path message for which it does not have 301 matching state, and which contains a Association object with a 302 Resource Sharing type, examines existing LSPs for matching 303 Association Type, Association Source and Association ID values. If 304 any match is found, then [RFC3209] style resource sharing SHOULD be 305 provided between the new and old LSPs. See [RFC3209] for additional 306 details. 308 4. Explicit Control of LSP Segment Recovery 310 Secondary Explicit Route objects, or SEROs, may be used to indicate 311 the branch and merge nodes of recovery LSPs. They may also provide 312 additional information that is to be carried in a recovery LSP's ERO. 313 When upstream control of branch and merge nodes are not desired, 314 SEROs are not used. 316 4.1. Secondary Explicit Route Object Format 318 The format of a SECONDARY_EXPLICIT_ROUTE object is the same as an 319 EXPLICIT_ROUTE object. This includes the definition of subobjects 320 defined for EXPLICIT_ROUTE object. The class of the 321 SECONDARY_EXPLICIT_ROUTE object is TBA (of form 11bbbbbb). 323 4.1.1. Protection Subobject 325 The protection subobject is not valid for use with the Explicit and 326 Record Route objects and MUST NOT be included in those objects. 328 The format of the Protection Subobject is defined as follows: 330 0 1 2 3 331 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 |L| Type | Length | Reserved | C-Type | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | PROTECTION Object Contents | 336 | ... | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 L-bit 340 This is defined in [RFC3209] and MUST be set to zero for 341 protection subobjects. 343 Type 345 37 Protection 347 C-Type 349 The C-Type of the included Protection object. 351 PROTECTION Object Contents 353 The contents of the Protection object with the format matching 354 the indicated C-Type, excluding the object header. 356 4.2. Explicit Control Procedures 358 SEROs are carried in Path messages and indicate at which node a 359 recovery LSP is to be initiated relative to the LSP carrying the 360 SERO. More than one SERO MAY be present in a Path message. 362 To indicate the branch and merge nodes of a recovery LSPs, an SERO is 363 created and added to the Path message of the LSP being recovered. 364 The decision to create and insert an SERO is a local matter and 365 outside the scope of this document. 367 An SERO SHOULD contain at least three subobjects. The first 368 subobject MUST indicate the node that is to originate the recovery 369 LSP, i.e. the segment branch node. The address used SHOULD also be 370 listed in the ERO or another SERO. This ensures that the branch node 371 is along the LSP path. The second subobject SHOULD be a protection 372 subobject and should indicate the protection or restoration to be 373 provided by the recovery LSP. When the protection subobject is 374 present, the LSP Segment Recovery Flags in the Protection subobject 375 MUST be ignored. The final subobject in the SERO MUST be the merge 376 node of the recovery LSP, and MAY have the L-bit set. Standard ERO 377 subobjects MAY be inserted between the protection subobject and the 378 final subobject. These subobjects MAY be loose or strict. 380 A node receiving a Path message containing one or more SEROs SHOULD 381 examine each SERO to see if it indicates a local branch point. This 382 determination is made by examining the first object of each SERO and 383 seeing if the address indicated in the subobject can be associated 384 with the local node. If any of indicated addresses are associated 385 with the local node, then the local node is a branch node. If the 386 local node is not a branch node, all received SEROs MUST be 387 transmitted, without modification, in the corresponding outgoing Path 388 message. 390 At a branch node, the SERO together with the Path message of LSP 391 being recovered provides the information to create the recovery LSP. 392 If the processing node is unable to support the requested branch, a 393 PathErr message SHOULD sent for the LSP being being protected, and 394 normal processing of the LSP continues. The PathErr message SHOULD 395 indicate an error of "TBD" and the Path_State_Removed flag MUST NOT 396 be set. If no error is generated then a recovery LSP is created. 398 The Path message for the recovery LSP is created at the branch node 399 by cloning the objects carried in the incoming Path message of the 400 LSP being protected. Certain objects are replaced or modified in the 401 recovery LSP's outgoing Path message. The Sender_template MUST be 402 updated to use an address on the local node, and the LSP ID MUST be 403 updated to ensure uniqueness. The Session object MUST be updated to 404 use the address indicated in the final subobject of the SERO as the 405 tunnel endpoint, the tunnel ID MAY be updated, and the extended 406 tunnel ID MUST be set to the local node. The Protection object is 407 replaced with the contents of the matching SERO subobject, when 408 present. Any RROs and EROs present in the incoming Path message MUST 409 NOT be included in the recovery LSP. A new ERO MUST be included, 410 with the contents of the SERO that indicated a local branch. As with 411 all EROs, no local information (local address and any protection 412 subobjects) is carried in the ERO carried in the recovery LSP's 413 outgoing Path message. The SERO that indicated a local branch MUST 414 be omitted from the recovery LSP's outgoing Path message. Note, by 415 default all other received SEROs are passed in the recovery LSP's 416 outgoing Path message. SEROs MAY be omitted, from the recovery LSP's 417 outgoing Path message as well as the outgoing Path message for the 418 LSP being protected when the SERO does not relate to the outgoing 419 path message. 421 The resulting Path message is used to create the recovery LSP. From 422 this point on, Standard Path message processing is used in processing 423 the resulting Path message. 425 4.2.1. Resv Message Processing 427 Branch nodes will process Resv messages for both recovery LSPs and 428 LSPs being protected. Resv messages are propagated upstream of branch 429 nodes only after a Resv message is received for the protected LSP. 430 Resv messages on recovery LSPs will typically not trigger 431 transmission of upstream Resv messages (for the LSP being protected). 433 Exceptions to this include when RROs/SRROs are being collected and 434 during certain Admin Status object processing. See below for more 435 information on related processing. 437 4.2.2. Branch Failure Handling 439 During setup and during normal operation, PathErr messages may be 440 received at a branch node. In all cases, a received PathErr message 441 is first processed per standard processing rules. When the PathErr 442 messages is not on a recovery LSP and the Path_State_Removed flag is 443 set, then any recovery LSPs associated with the LSP MUST also be torn 444 down. 446 If the PathErr messages is on a recovery LSP, receipt of the PathErr 447 message SHOULD trigger the generation of a PathErr message upstream 448 on the associated LSP. This outgoing (upstream) PathErr message 449 SHOULD be sent with the Path_State_Removed flag cleared (0) as only 450 the recovery LSP is impacted. However, if a branch node sends a 451 PathErr message with the Path_State_Removed flag set (1), which is 452 not recommended, the node MUST send a PathTear message downstream on 453 all other branches. 455 Additionally, an outgoing PathErr message MUST include any SEROs 456 carried in a received PathErr message. If no SERO is present in a 457 received PathErr message, then an SERO that matches the errored LSP 458 MUST be added to the outgoing PathErr message. 460 4.2.3. Admin Status Change 462 In general, objects in a recovery LSP are created based on the 463 corresponding objects in the LSP being protected. The Admin Status 464 object is created the same way, but it also requires some special 465 coordination at branch nodes. Specifically, in addition to normal 466 processing, a branch node that receives an Admin Status object in a 467 Path message also MUST relay the Admin Status object in a Path on 468 every recovery LSP. All Path messages MAY be concurrently sent 469 downstream. 471 Downstream nodes process the change in the Admin Status object per 472 [RFC3473], including generation of Resv messages. When the most 473 recently received upstream Admin Status object had the R bit set, 474 branch nodes wait for a Resv message with a matching Admin Status 475 object to be received on all branches before relaying a corresponding 476 Resv message upstream. 478 4.2.4. Recovery LSP Tear Down 480 Recovery LSP removal is follows standard the standard procedures 481 defined in [RFC3209] and [RFC3473]. This includes without and with 482 setting the administrative status. 484 4.2.4.1. Tear Down Without Admin Status Change 486 The node initiating the tear down originates a PathTear message. 487 Each node that receives a PathTear message process the PathTear 488 message per standard processing, see [RFC3209] and [RFC2205], and 489 also relays a PathTear on every recovery LSP. All PathTear messages 490 (received from upstream and locally originated) may be concurrently 491 sent downstream. 493 4.2.4.2. Tear Down With Admin Status Change 495 Per [RFC3473], the ingress node originates a Path message with the D 496 and R bits set in the Admin Status object. The admin status change 497 procedure defined above, see Section 4.2.3, MUST then be followed. 498 Once the ingress receives all expected Resv messages MUST follow the 499 tear down procedure described in the Section 4.2.4. 501 4.3. Tear Down From Non-Ingress Nodes 503 As with any LSP, any node along a recovery LSP may initiate removal 504 of the recovery LSP. To do this, the node initiating the tear down 505 sends a PathErr message with the appropriate Error Code and the 506 Path_State_Removed flag cleared (0) toward the LSP ingress. As 507 described above, the recovery LSP ingress will propagate the error to 508 the LSP ingress which can then signal the removal of the recovery 509 LSP. 511 It is also possible for the node initiating the tear down to remove a 512 Recovery LSP in a non-graceful manner. In this case, the initiator 513 sends a PathTear message downstream and a PathErr message with Error 514 Code TBD and the Path_State_Removed flag set (1) toward the LSP 515 ingress node. This manner of non-ingress node tear down is NOT 516 RECOMMENDED as it can result in the removal of the LSP being 517 protected in some case. 519 4.3.1. Modified Notify Request Object Processing 521 When a node is branching a recovery LSP, it SHOULD include a single 522 Notify Request object on the recovery LSP. The notify node address 523 MUST be set to the router address of the branch node. Normal 524 notification procedures are then followed for the recovery LSP. 525 Under local policy control, a node issuing a Notify message MAY also 526 send a Notify message to the Notify Node Address indicated in the 527 last, or any other, Notify_Request object received. 529 A branch node SHOULD also add a Notify Request object to the LSP 530 being protected. The notify node address is set to the address used 531 in the sender template of the recovery LSP. A locally added Notify 532 Request object MUST be listed first in the outgoing message, any 533 received Notify Request object MUST then be listed in the message in 534 the order that they were received. 536 Recovery LSP merge nodes remove the object added by the recovery 537 branch node from outgoing Path messages for the LSP being protected. 538 This is done by removing the Notify Request object that matches the 539 source address of the recovery LSP. Note, to cover certain backwards 540 compatibility scenarios the Notify Request object SHOULD NOT be 541 removed if it is the sole Notify Request object. 543 Note this requires the following change to [RFC3473], Section 4.2.1: 544 - old text: 545 If a message contains multiple Notify_Request objects, only the first 546 object is meaningful. Subsequent Notify_Request objects MAY be 547 ignored and SHOULD NOT be propagated. 549 - new text: 550 If a message contains multiple Notify_Request objects, only the first 551 object used is in notification. Subsequent Notify_Request objects 552 MUST be propagated in the order received. 554 4.3.2. Modified Notify and Error Message Processing 556 Branch nodes MUST support the following modification to Notify 557 message processing. When a branch node receives notification of an 558 LSP failure and it is unable to recover from that failure, it MUST 559 notify the node indicated in the first Notify_Request object received 560 in the Path message associated with the LSP. 562 5. Secondary Record Route Objects 564 Secondary Record Route objects, or SRROs, are used to record the path 565 used by recovery LSPs. 567 5.1. Format 569 The format of a SECONDARY_RECORD_ROUTE object is the same as an 570 RECORD_ROUTE object, Class number 21. This includes the definition 571 of subobjects defined for RECORD_ROUTE object. The class of the 572 SECONDARY_RECORD_ROUTE object is TBA (of form 11bbbbbb). 574 The protection subobject defined in [E2E-RECOVERY] can also be used 575 in SECONDARY_RECORD_ROUTE objects. 577 5.2. Path Processing 579 SRROs may be carried in Path messages and indicate the presence of 580 upstream recovery LSPs. More than one SRRO MAY be add and present in 581 a Path message. 583 Any received SRRO, MUST be transmitted by transit nodes, without 584 modification, in the corresponding outgoing Path message. 586 SRROs are inserted in Path messages by recovery LSP merge nodes. The 587 SRRO is created by copying the contents of an RRO received the 588 recovery LSP into a new SRRO object. This SRRO is added to the 589 outgoing Path message of the recovered LSP. Note multiple SRROs may 590 be present. The collection of SRROs is controlled via the segment- 591 recording-desired flag in the SESSION_ATTRIBUTE object. This flag MAY 592 be set even when SEROs are not used. 594 5.3. Resv Processing 596 SRROs may be carried in Resv messages and indicate the presence of 597 downstream recovery LSPs. More than one SRRO MAY be add and present 598 in a Resv message. 600 Any received SRRO, MUST be transmitted by transit nodes, without 601 modification, in the corresponding outgoing Resv message. When Resv 602 messages are merged, the resulting merged Resv should contain all 603 SRROs received in downstream Resv messages. 605 SRROs are inserted in Resv messages by branch nodes of recovery LSPs. 606 The SRRO is created with the first two objects being the local node 607 address followed by a protection subobject with the contents of the 608 recovery LSP's Protection object. The remainder of the SRRO is 609 created by copying the contents of the RRO received the recovery LSP. 610 This SRRO is added to the outgoing Resv message of the recovered LSP. 611 Again, multiple SRROs may be present. 613 6. Dynamic Control of LSP Segment Recovery 615 Dynamic identification of branch and merge nodes is supported via the 616 LSP Segment Recovery Flags carried in the Protection object. The LSP 617 Segment Recovery Flags are carried within one of Reserved fields 618 defined in the Protection object defined in [E2E-RECOVERY]. LSP 619 Segment Recovery Flags are used to indicate when LSP segment recovery 620 is desired. When these bits are set branch and merge nodes are 621 dynamically identified. 623 Note, the procedures defined in this section parallel the explicit 624 control procedures defined above in Section 4.2. The primary 625 difference is in creation of a recovery LSP's ERO. 627 6.1. Modified Protection Object Format 629 LSP Segment Recovery Flags are carried in the Protection object C- 630 Type defined in [E2E-RECOVERY]. The format of the flags are: 632 0 1 2 3 633 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Length | Class-Num(37) | C-Type (TBA) | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 |S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags| 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 |I| Reserved | Seg.Flags | Reserved | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 In-Place (I): 1 bit 644 When set (1) indicates that the desired segment recovery type 645 indicated in the LSP Segment Recovery Flag is already in place 646 for the associated LSP. 648 (LSP) Segment (Recovery) Flags: 6 bits 650 This field is used to indicate when an upstream node desires 651 LSP Segment recovery to be dynamically initiated where 652 possible. The values used in this field are identical to the 653 values defined for LSP Flags, see [E2E-RECOVERY]. 655 See [E2E-RECOVERY] for the definition of other fields. 657 6.2. Dynamic Control Procedures 659 LSP Segment Recovery Flags are set to indicate that LSP segment 660 recovery is desired for the LSP being signaled. The type of recovery 661 desired is indicated by the flags. The decision to set the LSP 662 Segment Recovery Flags is a local matter and outside the scope of 663 this document. A value of zero (0) means that no dynamic 664 identification of segment recovery branch nodes are needed for the 665 associated LSP. When the In-Place bit is set, it means that the 666 desired type of recovery is already in place for that particular LSP. 668 A transit node receiving a Path message containing a Protection 669 object with a non-zero LSP Segment Recovery Flags value and the In- 670 Place bit clear (0) SHOULD consider if it can support the indicated 671 recovery type and if it can identify an appropriate merge node for a 672 recovery LSP. Dynamic identification MUST NOT be done when the 673 processing node is identified as a branch node in an SERO. If a node 674 is unable to provide the indicated recovery type or identify a merge 675 node, the Path message MUST be processed normally and the LSP Segment 676 Recovery Flags MUST NOT be modified. 678 When a node dynamically identifies itself as a branch node and 679 identifies the merge node for the type of recovery indicated in the 680 LSP Segment Recovery Flags, it attempts to setup a recovery LSP. The 681 dynamically identified information, together with the Path message of 682 LSP being recovered provides the information to create the recovery 683 LSP. 685 The Path message for the recovery LSP is created at the branch node 686 by cloning the objects carried in the incoming Path message of the 687 LSP being protected. Certain objects are replaced or modified in the 688 recovery LSP's outgoing Path message. The Sender_template MUST be 689 updated to use an address on the local node, and the LSP ID MUST be 690 updated to ensure uniqueness. The Session object MUST be updated to 691 use the address of the dynamically identified merge node as the 692 tunnel endpoint, the tunnel ID MAY be updated, and the extended 693 tunnel ID MUST be set to the local node. The Protection object is 694 updated with the In-Place bit set (1). Any RROs and EROs present in 695 the incoming Path message MUST NOT be included in the recovery LSP. A 696 new ERO MAY be created based on any path information dynamically 697 computed by the local node. 699 The resulting Path message is used to create the recovery LSP. While 700 the recovery LSP exists, the Protection object in the original Path 701 message MUST also be updated with the In-Place bit set (1). From 702 this point on, Standard Path message processing is used in processing 703 the resulting and original Path messages. 705 The merge node of a dynamically controlled recovery LSP SHOULD reset 706 (0) the In-Place bit in the Protection object of the outgoing Path 707 message associated with the terminated recovery LSP. 709 Unlike with explicit control, if the creation of a dynamically 710 identified recovery LSP fails for any reason, the recovery LSP is 711 removed and no error message or indication is sent upstream. With 712 this exception, all the other procedures for explicitly controlled 713 recovery LSPs apply to dynamically controlled recovery LSPs. These 714 other procedures are defined above in defined in Sections 4.2.1 715 through 4.2.4. 717 7. Additional Fast Reroute Considerations 719 This section is under construction. 721 8. Updated RSVP Message Formats 723 This section presents the RSVP message related formats as modified by 724 this document. Where they differ, formats for unidirectional LSPs 725 are presented separately from bidirectional LSPs. 727 The format of a Path message is as follows: 729 ::= [ ] 730 [ [ | ] ... ] 731 [ ] 732 733 734 [ ] 735 736 [ ] 737 [ ... ] 738 [ ] 739 [ ... ] 740 [ ] 741 [ ... ] 742 [ ... ] 743 [ ... ] 744 746 The format of the sender description for unidirectional LSPs is: 748 ::= 749 [ ] 750 [ ] 751 [ ] 752 [ ] 753 [ ... ] 755 The format of the sender description for bidirectional LSPs is: 757 ::= 758 [ ] 759 [ ] 760 [ ] 761 [ ] 762 763 [ ... ] 764 The format of a PathErr message is as follows: 766 ::= [ ] 767 [ [ | ] ... ] 768 [ ] 769 770 [ ... ] 771 [ ... ] 772 [ ... ] 773 775 The format of a Resv message is as follows: 777 ::= [ ] 778 [ [ | ] ... ] 779 [ ] 780 781 782 [ ] [ ] 783 [ ... ] 784 [ ] 785 [ ... ] 786