idnits 2.17.1 draft-ietf-ccamp-gmpls-segment-recovery-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1054. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1065. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1072. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1078. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. -- The draft header indicates that this document updates RFC3473, but the abstract doesn't seem to mention this, which it should. 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. (Using the creation date from RFC3473, updated by this document, for RFC5378 checks: 2000-11-22) -- 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 (October 2006) is 6402 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 152, but not defined == Missing Reference: 'B' is mentioned on line 152, but not defined == Missing Reference: 'C' is mentioned on line 153, but not defined == Missing Reference: 'D' is mentioned on line 152, but not defined == Missing Reference: 'E' is mentioned on line 153, but not defined == Missing Reference: 'F' is mentioned on line 152, but not defined == Missing Reference: 'G' is mentioned on line 153, but not defined == Missing Reference: 'I' is mentioned on line 153, but not defined == Missing Reference: 'RFC-ccamp-gmpls-segment-recovery' is mentioned on line 966, but not defined -- Possible downref: Normative reference to a draft: ref. 'E2E-RECOVERY' Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Lou Berger (LabN) 2 Updates: 3473, [E2E-RECOVERY] Igor Bryskin (Movaz Networks) 3 Category: Standards Track Dimitri Papadimitriou (Alcatel) 4 Expiration Date: April 2007 Adrian Farrel (Old Dog Consulting) 6 October 2006 8 GMPLS Based Segment Recovery 10 draft-ietf-ccamp-gmpls-segment-recovery-03.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Abstract 37 This document describes protocol specific procedures for GMPLS 38 (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource 39 ReserVation Protocol - Traffic Engineering) signaling extensions to 40 support label switched path (LSP) segment protection and restoration. 41 These extensions are intended to complement and be consistent with 42 the Extensions for End-to-End GMPLS-based Recovery. Implications and 43 interactions with Fast Reroute are also addressed. This document 44 also updates the handling of Notify_Request objects. 46 Contents 48 1 Introduction .............................................. 3 49 2 Segment Recovery .......................................... 4 50 2.1 Segment Protection ........................................ 6 51 2.2 Segment Re-routing and Restoration ........................ 6 52 3 Association Object ........................................ 6 53 3.1 Format .................................................... 7 54 3.2 Procedures ................................................ 7 55 3.2.1 Recovery Type Processing .................................. 7 56 3.2.2 Resource Sharing Association Type Processing .............. 7 57 4 Explicit Control of LSP Segment Recovery .................. 8 58 4.1 Secondary Explicit Route Object Format .................... 8 59 4.1.1 Protection Subobject ...................................... 8 60 4.2 Explicit Control Procedures ............................... 9 61 4.2.1 Branch Failure Handling ................................... 11 62 4.2.2 Resv Message Processing ................................... 12 63 4.2.3 Admin Status Change ....................................... 12 64 4.2.4 Recovery LSP Tear Down .................................... 12 65 4.3 Tear Down From Non-Ingress Nodes .......................... 13 66 4.3.1 Modified Notify Request Object Processing ................. 13 67 4.3.2 Modified Notify and Error Message Processing .............. 14 68 5 Secondary Record Route Objects ............................ 15 69 5.1 Format .................................................... 15 70 5.2 Path Processing ........................................... 15 71 5.3 Resv Processing ........................................... 15 72 6 Dynamic Control of LSP Segment Recovery ................... 16 73 6.1 Modified Protection Object Format ......................... 16 74 6.2 Dynamic Control Procedures ................................ 17 75 7 Updated RSVP Message Formats .............................. 18 76 8 Security Considerations ................................... 20 77 9 IANA Considerations ....................................... 21 78 9.1 New Association Type Assignment ........................... 21 79 9.2 Definition of Protection Object Reserved Bits ............. 21 80 9.3 Secondary Explicit Route Object ........................... 21 81 9.4 Secondary Record Route Object ............................. 22 82 9.5 New Error Code ............................................ 22 83 9.6 Use of Not Yet Assigned Protection Object C-type .......... 22 84 10 References ................................................ 23 85 10.1 Normative References ...................................... 23 86 10.2 Informative References .................................... 23 87 11 Authors' Addresses ........................................ 24 88 12 Full Copyright Statement .................................. 24 89 13 Intellectual Property ..................................... 25 90 Conventions used in this document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 In addition, the reader is assumed to be familiar with the 97 terminology used in [RFC3209], [RFC3471], [RFC3473] as well as 98 [RFC4427], [RFC4426], [E2E-RECOVERY] and [RFC4090]. 100 1. Introduction 102 [RFC4427] covers multiple types of protection, including end-to-end 103 and segment based approaches. [E2E-RECOVERY], RSVP-TE Extensions in 104 support of End-to-End GMPLS-based Recovery, defines a set of 105 extensions to support multiple types of recovery. The supported 106 types include 1+1 unidirectional/ 1+1 bi-directional protection, LSP 107 protection with extra-traffic (including 1:N protection with extra- 108 traffic), pre-planned LSP re-routing without extra-traffic (including 109 shared mesh), and full LSP re-routing. In all cases, the recovery is 110 provided on an end-to-end basis, i.e., the ingress and egress nodes 111 of both the protected and the protecting LSP are the same. 113 [RFC4090] provides a form of segment recovery for packet MPLS-TE 114 networks. Two methods of Fast Reroute are defined in [RFC4090]. The 115 one-to-one backup method creates detour LSPs for each protected LSP 116 at each potential point of local repair. The facility backup method 117 creates a bypass tunnel to protect a potential failure point which is 118 shared by multiple LSPs and uses label stacking. Neither approach 119 supports the full set of recovery types supported by [E2E-RECOVERY]. 120 Additionally, the facility backup method is not applicable to most 121 non-PSC (packet) switching technologies. 123 The extensions defined in this document allow for support of the full 124 set of recovery types supported by [E2E-RECOVERY], but on a segment, 125 or portion of the LSP, basis. The extensions allow (a) the signaling 126 of desired LSP segment protection type, (b) upstream nodes to 127 optionally identify where segment protection starts and stops, (c) 128 the optional identification of hops used on protection segments, and 129 (d) the reporting of paths used to protect an LSP. The extensions 130 also widen the topological scope over which protection can be 131 supported. They allow recovery segments that protect against an 132 arbitrary number of nodes and links. They enable overlapping 133 protection and nested protection. These extensions are intended to 134 be compatible with, and in some cases used with Fast Reroute. 136 2. Segment Recovery 138 Segment recovery is used to provide protection and restoration over a 139 portion of an end-to-end LSP. Such segment protection and 140 restoration is useful to protect against a span failure, a node 141 failure, or failure over a particular portion of a network used by an 142 LSP. 144 Consider the following topology: 145 A---B---C---D---E---F 146 \ / 147 G---I 149 In this topology, end-to-end protection and recovery is not possible 150 for an LSP going between node A and node F, but it is possible to 151 protect/recover a portion of the LSP. Specifically, if the LSP uses 152 a working path of [A,B,C,D,E,F] then a protection or restoration LSP 153 can be established along the path [C,G,I,E]. This LSP protects 154 against failures on spans {C,D} and {D,E} as well as a failure of 155 node D. This form of protection/restoration is referred to as 156 Segment Protection and Segment Restoration, or Segment Recovery 157 collectively. The LSP providing the protection or restoration is 158 referred to as a segment protection LSP or a segment restoration LSP. 159 The term segment recovery LSP is used to cover either a segment 160 protection LSP or a segment restoration LSP. The term branch node is 161 used to refer to a node that initiates a recovery LSP, e.g., node C 162 in the figure shown above. This is equivalent to the point of local 163 repair (PLR) used in [RFC4090]. As with [RFC4090], the term merge 164 node is used to refer to a node that terminates a recovery LSP, e.g., 165 node E in the figure shown above. 167 Segment protection or restoration is signaled using a working LSP and 168 one or more segment recovery LSPs. Each segment recovery LSP is 169 signaled as an independent LSP. Specifically, the Sender_Template 170 object uses the IP address of the node originating the recovery path, 171 e.g., node C in the topology shown above, and the Session object 172 contains the IP address of the node terminating the recovery path, 173 e.g., node E shown above. There is no specific requirement on LSP ID 174 value, Tunnel ID and Extended Tunnel ID. Values for these fields are 175 selected normally, including consideration for make-before-break. 176 Intermediate nodes follow standard signaling procedures when 177 processing segment recovery LSPs. A segment recovery LSP may be 178 protected itself using segment or end-to-end protection/restoration. 179 Note, in PSC environments it may be desirable to construct the 180 Sender_Template and Session objects per [RFC4090]. 182 When [RFC4090] isn't being used, the association between segment 183 recovery LSPs with other LSPs is indicated using the Association 184 object defined in [E2E-RECOVERY]. The Association object is used to 185 associate recovery LSPs with the LSP they are protecting. Working 186 and protecting LSPs, as well as primary and secondary LSPs, are 187 identified using LSP Status as described in [E2E-RECOVERY]. The O- 188 bit in the segment flags portion of the Protection object is used to 189 identify when a recovery LSP is carrying the normal (active) traffic. 191 An upstream node can permit downstream nodes to dynamically identify 192 branch and merge points by setting the desired LSP segment protection 193 bits in the Protection object. These bits are defined below. 195 Optionally, an upstream node, usually the ingress node, can identify 196 the endpoints of a segment recovery LSP. This is accomplished using 197 a new object. This object uses the same format as an ERO and is 198 referred to as a Secondary Explicit Route object or SERO, see section 199 4.1. SEROs also support a new subobject to indicate the type of 200 protection or restoration to be provided. At a minimum an SERO will 201 indicate a recovery LSP's initiator, protection/restoration type and 202 terminator. Standard ERO semantics, see [RFC3209], can optionally be 203 used within and SERO to explicitly control the recovery LSP. A 204 Secondary Record Route object or SRRO is defined for recording the 205 path of a segment recovery LSP, see section 5. 207 SEROs are carried between the node creating the SERO, typically the 208 ingress, and the node initiating a recovery LSP. The node initiating 209 a recovery LSP uses the SERO to create the ERO for the recovery LSP. 210 At this (branch) node, all local objects are removed, and the new 211 protection subobject is used to create the Protection object for the 212 recovery LSP. It is also possible to control the handling of a 213 failure to establish a recovery LSP. 215 SRROs are carried in Path messages between the node terminating a 216 recovery LSP, the merge node, and the egress. SRROs are used in Resv 217 messages between a branch node and the ingress. The merge node of a 218 recovery LSP creates an SRRO by copying the RRO from the Path message 219 of the associated recovery LSP into a new SRRO object. Any SRROs 220 present in the recovery LSP's Path message are also copied. The 221 branch node of a recovery LSP creates an SRRO by copying the RRO from 222 the Resv message of associated recovery LSP into a new SRRO object. 223 Any SRROs present in the recovery LSP's Resv message are also copied. 225 Notify request processing is also impacted by LSP segment recovery. 226 Per [RFC3473], only one Notify Request object is meaningful and 227 should be propagated. Additional Notify Request objects are used to 228 identify recovery LSP branch nodes. 230 2.1. Segment Protection 232 Three approaches for end-to-end protection are defined in [E2E- 233 RECOVERY]: 1+1 Unidirectional Protection, see Section 5; 1+1 Bi- 234 directional Protection, see Section 6: and 1:1 Protection With Extra 235 Traffic, see Section 7. The segment protection forms of these 236 protection approaches all operate much like their end-to-end 237 counterparts. Each behaves just like its end-to-end counterpart, 238 with the exception that the protection LSP protects only a portion of 239 the working LSP. The type of protection to be used on a segment 240 protection LSP is indicated, to the protection LSP's ingress, using 241 the protection SERO subobject defined in Section 4.1. 243 The switch-over processing for segment 1+1 Bi-directional protection 244 and 1:1 Protection With Extra Traffic follows the same procedures as 245 end-to-end protection forms, see Section 6.2 and Section 7.2 for 246 details. 248 2.2. Segment Re-routing and Restoration 250 Three re-routing and restoration approaches are defined [E2E- 251 RECOVERY]: Re-routing without Extra-Traffic, see Section 8; Shared- 252 Mesh Restoration, see Section 9; (Full) LSP Re-routing, see Section 253 11. As with protection, these approaches are supported on a segment 254 basis. The segment forms of re-routing and restoration operate 255 exactly like their end-to-end counterparts, with the exception that 256 the restoration LSP recovers only a portion of the working LSP. The 257 type of re-routing or restoration to be used on a segment restoration 258 LSP is indicated, to the restoration LSP's ingress, using the new 259 protection SERO subobject. 261 3. Association Object 263 The Association object is used association of segment protection LSPs 264 when [RFC4090] isn't being used. The Association object is defined 265 in [E2E-RECOVERY]. In this document we define a new Association Type 266 field value to support make before break, formats and procedures 267 defined in [E2E-RECOVERY] are not otherwise modified. 269 3.1. Format 271 Association Type: 16 bits 273 Value Type 274 ----- ---- 275 2 Resource Sharing (R) 277 See [E2E-RECOVERY] for the definition of other fields and other 278 values. 280 3.2. Procedures 282 The Association object is used to associate different LSPs with each 283 other. In the protection and restoration context, the object is used 284 to associate a recovery LSP with the LSP it is protecting. The 285 Association object is also used to support resource sharing during 286 make-before-break. This object MUST NOT be used when association is 287 made according to the methods defined in [RFC4090]. 289 3.2.1. Recovery Type Processing 291 Recovery type processing procedures are the same as those defined in 292 [E2E-RECOVERY], but processing and identification occurs with respect 293 to segment recovery LSPs. Note that this means that multiple 294 Association objects of type recovery may be present on an LSP. 296 3.2.2. Resource Sharing Association Type Processing 298 The Association object with an Association Type with the value 299 Resource Sharing is used to enable resource sharing during make- 300 before-break. Resource sharing during make-before-break is defined 301 in [RFC3209]. The defined support only works with LSPs that share 302 the same LSP egress. With the introduction of segment recovery LSPs, 303 it is now possible for an LSP end-point to change during make-before- 304 break. 306 A node includes an Association object with a Resource Sharing 307 Association Type in outgoing an Path message when it wishes to 308 indicate resource sharing across an associated set of LSPs. The 309 Association Source is set to the originating node's router address. 310 The Association ID MUST be set to a value that uniquely identifies 311 the association of LSPs. This MAY be set to the working LSP's LSP 312 ID. Once included, an Association object with a Resource Sharing 313 Association Type SHOULD NOT be removed from the Path messages 314 associated with an LSP. 316 Any node processing a Path message for which it does not have 317 matching state, and which contains a Association object with a 318 Resource Sharing type, examines existing LSPs for matching 319 Association Type, Association Source and Association ID values. If 320 any match is found, then [RFC3209] style resource sharing SHOULD be 321 provided between the new and old LSPs. See [RFC3209] for additional 322 details. 324 4. Explicit Control of LSP Segment Recovery 326 Secondary Explicit Route objects, or SEROs, are defined in this 327 document. They may be used to indicate the branch and merge nodes of 328 recovery LSPs. They may also provide additional information that is 329 to be carried in a recovery LSP's ERO. When upstream control of 330 branch and merge nodes is not desired, SEROs are not used. 332 4.1. Secondary Explicit Route Object Format 334 The format of a SECONDARY_EXPLICIT_ROUTE object is the same as an 335 EXPLICIT_ROUTE object. This includes the definition of subobjects 336 defined for EXPLICIT_ROUTE object. The class of the 337 SECONDARY_EXPLICIT_ROUTE object is TBA by IANA (of form 11bbbbbb). 339 4.1.1. Protection Subobject 341 A new subobject, called the protection subobject, is defined for use 342 in the SECONDARY_EXPLICIT_ROUTE object. As mentioned above, the new 343 protection subobject is used to create the Protection object for the 344 recovery LSP. Specific procedures related to the protection 345 subobject are provided in Section 4.2. The protection subobject is 346 not valid for use with the Explicit and Record Route objects and MUST 347 NOT be included in those objects. 349 The format of the Protection Subobject is defined as follows: 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 |L| Type | Length | Reserved | C-Type | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | PROTECTION Object Contents | 357 | ... | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 L-bit 362 This is defined in [RFC3209] and MUST be set to zero for 363 protection subobjects. 365 Type 367 37 Protection 369 Length 371 As defined in [RFC3209], Section 4.3.3. 373 Reserved 375 This field is reserved. It MUST be set to zero on transmission 376 and MUST be ignored on receipt. 378 C-Type 380 The C-Type of the included Protection object. 382 PROTECTION Object Contents 384 The contents of the Protection object, with the format matching 385 the indicated C-Type, excluding the object header. 387 4.2. Explicit Control Procedures 389 SEROs are carried in Path messages and indicate at which node a 390 recovery LSP is to be initiated relative to the LSP carrying the 391 SERO. More than one SERO MAY be present in a Path message. 393 To indicate the branch and merge nodes of a recovery LSPs, an SERO is 394 created and added to the Path message of the LSP being recovered. 395 The decision to create and insert an SERO is a local matter and 396 outside the scope of this document. 398 An SERO SHOULD contain at least three subobjects. The first 399 subobject MUST indicate the node that is to originate the recovery 400 LSP, i.e. the segment branch node. The address used SHOULD also be 401 listed in the ERO or another SERO. This ensures that the branch node 402 is along the LSP path. The second subobject SHOULD be a protection 403 subobject and should indicate the protection or restoration to be 404 provided by the recovery LSP. When the protection subobject is 405 present, the LSP Segment Recovery Flags in the Protection subobject 406 MUST be ignored. The final subobject in the SERO MUST be the merge 407 node of the recovery LSP, and MAY have the L-bit set. Standard ERO 408 subobjects MAY be inserted between the protection subobject and the 409 final subobject. These subobjects MAY be loose or strict. 411 A node receiving a Path message containing one or more SEROs SHOULD 412 examine each SERO to see if it indicates a local branch point. This 413 determination is made by examining the first object of each SERO and 414 seeing if the address indicated in the subobject can be associated 415 with the local node. If any of indicated addresses are associated 416 with the local node, then the local node is a branch node. If the 417 local node is not a branch node, all received SEROs MUST be 418 transmitted, without modification, in the corresponding outgoing Path 419 message. 421 At a branch node, the SERO together with the Path message of LSP 422 being recovered provides the information to create the recovery LSP. 423 The Path message for the recovery LSP is created at the branch node 424 by cloning the objects carried in the incoming Path message of the 425 LSP being protected. Certain objects are replaced or modified in the 426 recovery LSP's outgoing Path message. The Sender_template MUST be 427 updated to use an address on the local node, and the LSP ID MUST be 428 updated to ensure uniqueness. The Session object MUST be updated to 429 use the address indicated in the final subobject of the SERO as the 430 tunnel endpoint, the tunnel ID MAY be updated, and the extended 431 tunnel ID MUST be set to the local node. The Protection object is 432 replaced with the contents of the matching SERO protection subobject, 433 when present. In all cases, the R-bit of a new Protection object is 434 reset (0). Any RROs and EROs present in the incoming Path message 435 MUST NOT be included in the recovery LSP. A new ERO MUST be 436 included, with the contents of the SERO that indicated a local 437 branch. As with all EROs, no local information (local address and 438 any protection subobjects) is carried in the ERO carried in the 439 recovery LSP's outgoing Path message. The SERO that indicated a 440 local branch MUST be omitted from the recovery LSP's outgoing Path 441 message. Note, by default all other received SEROs are passed in the 442 recovery LSP's outgoing Path message. SEROs MAY be omitted, from the 443 recovery LSP's outgoing Path message as well as the outgoing Path 444 message for the LSP being protected when the SERO does not relate to 445 the outgoing path message. 447 The resulting Path message is used to create the recovery LSP. From 448 this point on, Standard Path message processing is used in processing 449 the resulting Path message. 451 4.2.1. Branch Failure Handling 453 During setup, it is possible that a processing node will be unable to 454 support a requested branch. Additionally, during setup and during 455 normal operation, PathErr messages may be received at a branch node. 456 The processing of these events depend on a number of factors. 458 When a failure or received PathErr message is associated with the LSP 459 being protected, the event is first processed per standard processing 460 rules. This includes generation of a standard PathErr message. When 461 LSP state is removed due to a local failure or the a PathErr message 462 with the Path_State_Removed flag set (1), the node MUST send a 463 PathTear message downstream on all other branches. 465 When a failure or received PathErr message is associated with a 466 recovery LSP, processing is based on the R-bit in addition to the 467 Path_State_Removed flag. In all cases, a received PathErr message is 468 first processed per standard processing rules and the the failure or 469 received PathErr message SHOULD trigger the generation of a PathErr 470 message upstream for the LSP being protected. The outgoing PathErr 471 message SHOULD indicate an error of "Routing Problem/LSP Segment 472 Protection Failed". The outgoing PathErr message MUST include any 473 SEROs carried in a received PathErr message. If no SERO is present 474 in a received PathErr message or when the failure is local, then an 475 SERO that matches the errored LSP or failed branch MUST be added to 476 the outgoing PathErr message. 478 When a PathErr message with the Path_State_Removed flag cleared (0) 479 is received, the outgoing (upstream) PathErr message SHOULD be sent 480 with the Path_State_Removed flag cleared (0). 482 When a PathErr message for a recover LSP with the Path_State_Removed 483 flag set (1) is received, the processing node MUST examine the R-bit 484 (as defined below) of the LSP being protected. The R-bit is carried 485 in the protection object that triggered the initiation of the 486 recovery LSP. When the R-bit is not set (0), the outgoing (upstream) 487 PathErr message SHOULD be sent with the Path_State_Removed flag 488 cleared (0). When the R-bit is set (1), the outgoing (upstream) 489 PathErr message MUST be sent with the Path_State_Removed flag set 490 (1). 492 In all cases where an outgoing (upstream) PathErr message is sent 493 with the Path_State_Removed flag set (1), all path state for the LSP 494 being protected MUST be removed and the node MUST send a PathTear 495 message downstream on all active branches. 497 4.2.2. Resv Message Processing 499 Branch nodes will process Resv messages for both recovery LSPs and 500 LSPs being protected. Resv messages are propagated upstream of branch 501 nodes only after a Resv message is received for the protected LSP. 502 Resv messages on recovery LSPs will typically not trigger 503 transmission of upstream Resv messages (for the LSP being protected). 504 Exceptions to this include when RROs/SRROs are being collected and 505 during certain Admin Status object processing. See below for more 506 information on related processing. 508 4.2.3. Admin Status Change 510 In general, objects in a recovery LSP are created based on the 511 corresponding objects in the LSP being protected. The Admin Status 512 object is created the same way, but it also requires some special 513 coordination at branch nodes. Specifically, in addition to normal 514 processing, a branch node that receives an Admin Status object in a 515 Path message also MUST relay the Admin Status object in a Path on 516 every recovery LSP. All Path messages MAY be concurrently sent 517 downstream. 519 Downstream nodes process the change in the Admin Status object per 520 [RFC3473], including generation of Resv messages. When the most 521 recently received upstream Admin Status object had the R bit set, 522 branch nodes wait for a Resv message with a matching Admin Status 523 object to be received on all branches before relaying a corresponding 524 Resv message upstream. 526 4.2.4. Recovery LSP Tear Down 528 Recovery LSP removal is follows standard the standard procedures 529 defined in [RFC3209] and [RFC3473]. This includes without and with 530 setting the administrative status. 532 4.2.4.1. Tear Down Without Admin Status Change 534 The node initiating the tear down originates a PathTear message. 535 Each node that receives a PathTear message process the PathTear 536 message per standard processing, see [RFC3209] and [RFC2205], and 537 MUST also relay a PathTear on every recovery LSP. All PathTear 538 messages (received from upstream and locally originated) may be 539 concurrently sent downstream. 541 4.2.4.2. Tear Down With Admin Status Change 543 Per [RFC3473], the ingress node originates a Path message with the D 544 and R bits set in the Admin Status object. The admin status change 545 procedure defined above, see Section 4.2.3, MUST then be followed. 546 Once the ingress receives all expected Resv messages, it MUST follow 547 the tear down procedure described in Section 4.2.4.1. 549 4.3. Tear Down From Non-Ingress Nodes 551 As with any LSP, any node along a recovery LSP may initiate removal 552 of the recovery LSP. To do this, the node initiating the tear down 553 sends a PathErr message with the appropriate Error Code and the 554 Path_State_Removed flag cleared (0) toward the LSP ingress. As 555 described above, the recovery LSP ingress will propagate the error to 556 the LSP ingress which can then signal the removal of the recovery 557 LSP. 559 It is also possible for the node initiating the tear down to remove a 560 Recovery LSP in a non-graceful manner. In this case, the initiator 561 sends a PathTear message downstream and a PathErr message with a 562 "Confirmation" indication (error code and value set to zero) and the 563 Path_State_Removed flag set (1) toward the LSP ingress node. This 564 manner of non-ingress node tear down is NOT RECOMMENDED as it can 565 result in the removal of the LSP being protected in some case. 567 4.3.1. Modified Notify Request Object Processing 569 When a node is branching a recovery LSP, it SHOULD include a single 570 Notify Request object in the Path message of the recovery LSP. The 571 notify node address MUST be set to the router address of the branch 572 node. 574 A branch node SHOULD also add a Notify Request object to the LSP 575 being protected. The notify node address is set to the address used 576 in the sender template of the recovery LSP. A locally added Notify 577 Request object MUST be listed first in the outgoing message, any 578 received Notify Request objects MUST then be listed in the message in 579 the order that they were received. Note that this can result in a 580 stack of (or ordered list) of objects. 582 Normal notification procedures are then followed for the LSP being 583 protected. That is, the notifying node MUST issue a Notify message to 584 the recipient indicated by the notify address of the first listed 585 Notify Request object. Under local policy control, a node issuing a 586 Notify message MAY also send a Notify message to the Notify Node 587 Address indicated in the last, or any other, Notify Request object 588 carried in the Path message. 590 Recovery LSP merge nodes remove the object added by the recovery 591 branch node from outgoing Path messages for the LSP being protected. 592 This is done by removing the Notify Request object that matches the 593 source address of the recovery LSP. This will normally be the first 594 of the listed Notify Request objects. Note, to cover certain 595 backwards compatibility scenarios the Notify Request object SHOULD 596 NOT be removed if it is the sole Notify Request object. 598 A similar set of rules are applied to the processing of Resv message 599 objects to enable merge nodes adding a Notify Request to the Resv 600 message for the protected LSP, arranging the objects as an ordered 601 list or stack. 603 Note this requires the following change to [RFC3473], Section 4.2.1: 604 o old text: 605 If a message contains multiple Notify_Request objects, only the 606 first object is meaningful. Subsequent Notify_Request objects 607 MAY be ignored and SHOULD NOT be propagated. 609 o new text: 610 If a message contains multiple Notify_Request objects, only the 611 first object used is in notification. Subsequent Notify_Request 612 objects MUST be propagated in the order received. 614 4.3.2. Modified Notify and Error Message Processing 616 Branch nodes MUST support the following modification to Notify 617 message processing. When a branch node receives notification of an 618 LSP failure and it is unable to recover from that failure, it MUST 619 notify the node indicated in the first Notify_Request object received 620 in the Path message associated with the LSP. 622 5. Secondary Record Route Objects 624 Secondary Record Route objects, or SRROs, are used to record the path 625 used by recovery LSPs. 627 5.1. Format 629 The format of a SECONDARY_RECORD_ROUTE object is the same as a 630 RECORD_ROUTE object, Class number 21. This includes the definition 631 of subobjects defined for RECORD_ROUTE object. The class of the 632 SECONDARY_RECORD_ROUTE object is TBA by IANA (of form 11bbbbbb). 634 The protection subobject defined above can also be used in 635 SECONDARY_RECORD_ROUTE objects. 637 5.2. Path Processing 639 SRROs may be carried in Path messages and indicate the presence of 640 upstream recovery LSPs. More than one SRRO MAY be add and present in 641 a Path message. 643 Any received SRRO, MUST be transmitted by transit nodes, without 644 modification, in the corresponding outgoing Path message. 646 SRROs are inserted in Path messages by recovery LSP merge nodes. The 647 SRRO is created by copying the contents of an RRO received the 648 recovery LSP into a new SRRO object. This SRRO is added to the 649 outgoing Path message of the recovered LSP. Note multiple SRROs may 650 be present. The collection of SRROs is controlled via the segment- 651 recording-desired flag in the SESSION_ATTRIBUTE object. This flag MAY 652 be set even when SEROs are not used. 654 5.3. Resv Processing 656 SRROs may be carried in Resv messages and indicate the presence of 657 downstream recovery LSPs. More than one SRRO MAY be add and present 658 in a Resv message. 660 Any received SRRO, MUST be transmitted by transit nodes, without 661 modification, in the corresponding outgoing Resv message. When Resv 662 messages are merged, the resulting merged Resv SHOULD contain all 663 SRROs received in downstream Resv messages. 665 SRROs are inserted in Resv messages by branch nodes of recovery LSPs. 666 The SRRO SHOULD be created with the first two objects being the local 667 node address followed by a protection subobject with the contents of 668 the recovery LSP's Protection object. The remainder of the SRRO 669 SHOULD be created by copying the contents of the RRO received the 670 recovery LSP. This SRRO SHOULD be added to the outgoing Resv message 671 of the recovered LSP. Again, multiple SRROs may be present. 673 If the newly added SRRO causes the message to be too big to fit in a 674 Resv message, SRRO subobjects SHOULD be removed from any present 675 SRROs. When removing subobjects, the first two subobjects and the 676 last subobject in an SRRO MUST NOT be removed. Note that the sub- 677 object that followed a removed sub-object MUST be updated with the L- 678 bit set (1). If after removing all but the first and last subobjects 679 in all SRROs the resulting message is still too large to fit, then 680 whole SRROs SHOULD be removed until the message does fit. 682 6. Dynamic Control of LSP Segment Recovery 684 Dynamic identification of branch and merge nodes is supported via the 685 LSP Segment Recovery Flags carried in the Protection object. The LSP 686 Segment Recovery Flags are carried within one of Reserved fields 687 defined in the Protection object defined in [E2E-RECOVERY]. LSP 688 Segment Recovery Flags are used to indicate when LSP segment recovery 689 is desired. When these bits are set branch and merge nodes are 690 dynamically identified. 692 Note, the procedures defined in this section parallel the explicit 693 control procedures defined above in Section 4.2. The primary 694 difference is in creation of a recovery LSP's ERO. 696 6.1. Modified Protection Object Format 698 LSP Segment Recovery Flags are carried in the Protection object of 699 the same C-Type defined in [E2E-RECOVERY]. The format of the flags 700 are: 702 0 1 2 3 703 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 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Length | Class-Num(37) | C-Type (TBA) | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 |S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags| 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 |I|R| Reserved | Seg.Flags | Reserved | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 In-Place (I): 1 bit 713 When set (1) indicates that the desired segment recovery type 714 indicated in the LSP Segment Recovery Flag is already in place 715 for the associated LSP. 717 Required (R): 1 bit 719 When set (1) indicates that failure to establish the indicated 720 protection should result in a failure of the LSP being 721 protected. 723 Segment Recovery Flags (Seg.Flags): 6 bits 725 This field is used to indicate when an upstream node desires 726 LSP Segment recovery to be dynamically initiated where 727 possible. The values used in this field are identical to the 728 values defined for LSP Flags, see [E2E-RECOVERY]. 730 See [E2E-RECOVERY] for the definition of other fields. 732 6.2. Dynamic Control Procedures 734 LSP Segment Recovery Flags are set to indicate that LSP segment 735 recovery is desired for the LSP being signaled. The type of recovery 736 desired is indicated by the flags. The decision to set the LSP 737 Segment Recovery Flags is a local matter and outside the scope of 738 this document. A value of zero (0) means that no dynamic 739 identification of segment recovery branch nodes are needed for the 740 associated LSP. When the In-Place bit is set, it means that the 741 desired type of recovery is already in place for that particular LSP. 743 A transit node receiving a Path message containing a Protection 744 object with a non-zero LSP Segment Recovery Flags value and the In- 745 Place bit clear (0) SHOULD consider if it can support the indicated 746 recovery type and if it can identify an appropriate merge node for a 747 recovery LSP. Dynamic identification MUST NOT be done when the 748 processing node is identified as a branch node in an SERO. If a node 749 is unable to provide the indicated recovery type or identify a merge 750 node, the Path message MUST be processed normally and the LSP Segment 751 Recovery Flags MUST NOT be modified. 753 When a node dynamically identifies itself as a branch node and 754 identifies the merge node for the type of recovery indicated in the 755 LSP Segment Recovery Flags, it attempts to setup a recovery LSP. The 756 dynamically identified information, together with the Path message of 757 LSP being recovered provides the information to create the recovery 758 LSP. 760 The Path message for the recovery LSP is created at the branch node 761 by cloning the objects carried in the incoming Path message of the 762 LSP being protected. Certain objects are replaced or modified in the 763 recovery LSP's outgoing Path message. The Sender_template MUST be 764 updated to use an address on the local node, and the LSP ID MUST be 765 updated to ensure uniqueness. The Session object MUST be updated to 766 use the address of the dynamically identified merge node as the 767 tunnel endpoint, the tunnel ID MAY be updated, and the extended 768 tunnel ID MUST be set to the local node. The Protection object is 769 updated with the In-Place bit set (1). Any RROs and EROs present in 770 the incoming Path message MUST NOT be included in the recovery LSP. A 771 new ERO MAY be created based on any path information dynamically 772 computed by the local node. 774 The resulting Path message is used to create the recovery LSP. While 775 the recovery LSP exists and unless overridden by local policy, the 776 Protection object in the original Path message MUST also be updated 777 with the In-Place bit set (1). From this point on, Standard Path 778 message processing is used in processing the resulting and original 779 Path messages. 781 The merge node of a dynamically controlled recovery LSP SHOULD reset 782 (0) the In-Place bit in the Protection object of the outgoing Path 783 message associated with the terminated recovery LSP. 785 Unlike with explicit control, if the creation of a dynamically 786 identified recovery LSP fails for any reason, the recovery LSP is 787 removed and no error message or indication is sent upstream. With 788 this exception, all the other procedures for explicitly controlled 789 recovery LSPs apply to dynamically controlled recovery LSPs. These 790 other procedures are defined above in defined in Sections 4.2.1 791 through 4.2.4. 793 7. Updated RSVP Message Formats 795 This section presents the RSVP message related formats as modified by 796 this document. Where they differ, formats for unidirectional LSPs 797 are presented separately from bidirectional LSPs. 799 The format of a Path message is as follows: 801 ::= [ ] 802 [ [ | ] ... ] 803 [ ] 804 805 806 [ ] 807 808 [ ] 809 [ ... ] 810 [ ] 811 [ ... ] 812 [ ] 813 [ ... ] 814 [ ... ] 815 [ ... ] 816 818 The format of the sender description for unidirectional LSPs is: 820 ::= 821 [ ] 822 [ ] 823 [ ] 824 [ ] 825 [ ... ] 827 The format of the sender description for bidirectional LSPs is: 829 ::= 830 [ ] 831 [ ] 832 [ ] 833 [ ] 834 835 [ ... ] 836 The format of a PathErr message is as follows: 838 ::= [ ] 839 [ [ | ] ... ] 840 [ ] 841 842 [ ... ] 843 [ ... ] 844 [ ... ] 845 847 The format of a Resv message is as follows: 849 ::= [ ] 850 [ [ | ] ... ] 851 [ ] 852 853 854 [ ] [ ] 855 [ ... ] 856 [ ] 857 [ ... ] 858