idnits 2.17.1 draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2252. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2229. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2236. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2242. ** 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 42 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 6365 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 1022, but not defined == Missing Reference: 'B' is mentioned on line 1020, but not defined == Missing Reference: 'C' is mentioned on line 1020, but not defined == Missing Reference: 'D' is mentioned on line 1022, but not defined == Missing Reference: 'E' is mentioned on line 1023, but not defined == Missing Reference: 'F' is mentioned on line 1023, but not defined == Missing Reference: 'G' is mentioned on line 1023, but not defined == Missing Reference: 'H' is mentioned on line 1023, but not defined == Missing Reference: 'I' is mentioned on line 1020, but not defined == Missing Reference: 'J' is mentioned on line 1020, but not defined == Missing Reference: 'K' is mentioned on line 1023, but not defined -- Looks like a reference, but probably isn't: '1' on line 1739 -- Looks like a reference, but probably isn't: '0' on line 2035 -- Looks like a reference, but probably isn't: '26' on line 2038 -- Looks like a reference, but probably isn't: '27' on line 2039 -- Looks like a reference, but probably isn't: '28' on line 2040 -- Looks like a reference, but probably isn't: '29' on line 2042 -- Looks like a reference, but probably isn't: '30' on line 2043 -- Looks like a reference, but probably isn't: '31' on line 2045 == Unused Reference: 'RFC2026' is defined on line 2065, but no explicit reference was found in the text == Unused Reference: 'RFC4202' is defined on line 2103, but no explicit reference was found in the text == Unused Reference: 'RFC4204' is defined on line 2107, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-crankback-05 == Outdated reference: A later version (-04) exists of draft-ietf-ccamp-gmpls-rsvp-te-call-01 == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-rsvp-te-exclude-route-05 Summary: 3 errors (**), 0 flaws (~~), 21 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J.P. Lang (Editor) 3 Internet Draft Y. Rekhter (Editor) 4 Expiration Date: February 2007 D. Papadimitriou (Editor) 5 Updates RFC 3471 6 October 2006 8 RSVP-TE Extensions in support of End-to-End 9 Generalized Multi-Protocol Label Switching (GMPLS) Recovery 11 draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document describes protocol specific procedures and extensions 43 for Generalized Multi-Protocol Label Switching (GMPLS) Resource 44 ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling to 45 support end-to-end Label Switched Path (LSP) recovery that denotes 46 protection and restoration. A generic functional description of 47 GMPLS recovery can be found in a companion document, RFC 4426. 49 J.P.Lang et al. Standards Track 1 50 Table of Contents 52 Status of this Memo ............................................. 1 53 Abstract ........................................................ 1 54 Table of Content ................................................ 2 55 1. Conventions .................................................. 3 56 2. Introduction ................................................. 4 57 3. Relationship to Fast Reroute (FRR) ........................... 4 58 4. Definitions .................................................. 6 59 4.1 LSP Identification .......................................... 6 60 4.2 Recovery Attributes ......................................... 7 61 4.2.1 LSP Status ................................................ 7 62 4.2.2 LSP Recovery .............................................. 8 63 4.3 LSP Association ............................................. 9 64 5. 1+1 Unidirectional Protection ................................ 9 65 5.1. Identifiers ............................................... 10 66 6. 1+1 Bi-directional Protection ............................... 10 67 6.1. Identifiers ............................................... 11 68 6.2. End-to-End Switchover Request/Response .................... 11 69 7. 1:1 Protection with Extra-Traffic ........................... 13 70 7.1 Identifiers ................................................ 14 71 7.2 End-to-End Switchover Request/Response ..................... 14 72 7.3 1:N (N > 1) Protection with Extra-Traffic .................. 16 73 8. Re-routing without Extra-Traffic ............................ 16 74 8.1 Identifiers ................................................ 18 75 8.2 Signaling Primary LSPs ..................................... 18 76 8.3 Signaling Secondary LSPs ................................... 18 77 9. Shared-Mesh Restoration ..................................... 19 78 9.1. Identifiers ............................................... 21 79 9.2 Signaling Primary LSPs ..................................... 21 80 9.3 Signaling Secondary LSPs ................................... 21 81 10. LSP Preemption ............................................. 22 82 11. (Full) LSP Re-routing ...................................... 23 83 11.1 Identifiers ............................................... 24 84 11.2 Signaling Re-routable LSPs ................................ 24 85 12. Reversion .................................................. 25 86 13. External Commands .......................................... 28 87 14. PROTECTION Object .......................................... 29 88 14.1 Format .................................................... 29 89 14.2 Processing ................................................ 31 90 15. PRIMARY PATH ROUTE Object .................................. 31 91 15.1 Format .................................................... 31 92 15.2 Subobjects ................................................ 32 93 15.3 Applicability ............................................. 33 94 15.4 Processing ................................................ 33 95 16. ASSOCIATION Object ......................................... 34 96 16.1 Format .................................................... 34 97 16.2 Processing ................................................ 36 98 17. Updated RSVP Message Formats ............................... 36 99 18. Security Considerations .................................... 37 100 19. IANA Considerations ........................................ 38 101 20. Acknowledgments ............................................ 39 103 J.P.Lang et al. Expires February 2007 2 104 21. References ................................................. 40 105 21.1 Normative References ...................................... 40 106 21.2 Informative References .................................... 41 107 22. Editor's Addresses ......................................... 41 108 23. Contributors ............................................... 41 110 1. Conventions used in this document: 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 In addition, the reader is assumed to be familiar with the 117 terminology used in [RFC3945], [RFC3471], [RFC3473] and referenced 118 as well as in [RFC4427] and [RFC4426]. 120 2. Introduction 122 Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to 123 include support for Layer-2 (L2SC), Time-Division Multiplex (TDM), 124 Lambda Switch Capable (LSC), and Fiber Switch Capable (FSC) 125 interfaces. GMPLS recovery uses control plane mechanisms (i.e., 126 signaling, routing, link management mechanisms) to support data 127 plane fault recovery. Note that the analogous (data plane) fault 128 detection mechanisms are required to be present in support of the 129 control plane mechanisms. In this document, the term "recovery" is 130 generically used to denote both protection and restoration; the 131 specific terms "protection" and "restoration" are only used when 132 differentiation is required. The subtle distinction between 133 protection and restoration is made based on the resource allocation 134 done during the recovery phase (see [RFC4427]). 136 A functional description of GMPLS recovery is provided in [RFC4426] 137 and should be considered as a companion document. The present 138 document describes the protocol specific procedures for GMPLS RSVP- 139 TE (Resource ReSerVation Protocol - Traffic Engineering) signaling 140 (see [RFC3473]) to support end-to-end recovery. End-to-end recovery 141 refers to the recovery of an entire LSP from its head-end (ingress 142 node end-point) to its tail-end (egress node end-point). 143 With end-to-end recovery, working LSPs are assumed to be resource 144 (link/node/SRLG) disjoint in the network so that they do not share 145 any failure probability, but this is not mandatory. With respect to 146 a given set of network resources, a pair of working/protecting LSPs 147 SHOULD be resource disjoint in case of dedicated recovery type (see 148 below). On the other hand, in case of shared recovery (see below), a 149 group of working LSPs SHOULD be mutually resource-disjoint in order 150 to allow for a (single and commonly) shared protecting LSP itself 151 resource-disjoint from each of the working LSPs. Note that resource 152 disjointness is a necessary (but not a sufficient) condition to 153 ensure LSP recoverability. 155 J.P.Lang et al. Expires February 2007 3 156 The present document addresses four types of end-to-end LSP 157 recovery: 1) 1+1 (unidirectional/bi-directional) protection, 2) 1:N 158 (N >= 1) LSP protection with extra-traffic, 3) pre-planned LSP re- 159 routing without extra-traffic (including shared mesh), and 4) full 160 LSP re-routing. 162 1) The simplest notion of end-to-end LSP protection is 1+1 163 unidirectional protection. Using this type of protection, a 164 protecting LSP is signaled over a dedicated resource-disjoint 165 alternate path to protect an associated working LSP. Normal 166 traffic is simultaneously sent on both LSPs and a selector is 167 used at the egress node to receive traffic from one of the LSPs. 168 If a failure occurs along one of the LSPs, the egress node 169 selects the traffic from the valid LSP. No coordination is 170 required between the end nodes when a failure/switchover occurs. 172 In 1+1 bi-directional protection, a protecting LSP is signaled 173 over a dedicated resource-disjoint alternate path to protect the 174 working LSP. Normal traffic is simultaneously sent on both LSPs 175 (in both directions) and a selector is used at both 176 ingress/egress nodes to receive traffic from the same LSP. This 177 requires co-ordination between the end-nodes when switching to 178 the protecting LSP. 180 2) In 1:N (N >= 1) protection with extra-traffic, the protecting LSP 181 is a fully provisioned and resource-disjoint LSP from the N 182 working LSPs, that allows for carrying extra-traffic. The N 183 working LSPs MAY be mutually resource-disjoint. Coordination 184 between end-nodes is required when switching from one of the 185 working to the protecting LSP. As the protecting LSP is fully 186 provisioned, default operations during protection switching are 187 specified for a protecting LSP carrying extra-traffic, but this 188 is not mandatory. Note that M:N protection is out of scope of 189 this document (though mechanisms it defines may be extended to 190 cover it). 192 3) Pre-planned LSP re-routing (or restoration) relies on the 193 establishment between the same pair of end-nodes of a working LSP 194 and a protecting LSP that is link/node/SRLG disjoint from the 195 working one. Here, the recovery resources for the protecting LSP 196 are pre-reserved but explicit action is required to activate 197 (i.e. commit resource allocation at the data plane) a specific 198 protecting LSP instantiated during the (pre-)provisioning phase. 199 Since the protecting LSP is not "active" (i.e. fully 200 instantiated), it can not carry any extra-traffic. This does not 201 mean that the corresponding resources can not used by other LSPs. 202 Therefore, this mechanism protects against working LSP(s) 203 failure(s) but requires activation of the protecting LSP after 204 working LSP failure occurrence. This requires restoration 205 signaling along the protecting path. "Shared-mesh" restoration 206 can be seen as a particular case of pre-planned LSP re-routing 207 that reduces the recovery resource requirements by allowing 209 J.P.Lang et al. Expires February 2007 4 210 multiple protecting LSPs to share common link and node resources. 211 The recovery resources are pre-reserved but explicit action is 212 required to activate (i.e. commit resource allocation at the data 213 plane) a specific protecting LSP instantiated during the (pre-) 214 provisioning phase. This procedure requires restoration 215 signaling along the protecting path. 217 Note that in both cases, bandwidth pre-reserved for a protecting 218 (but not activated) LSP, can be made available for carrying extra 219 traffic. LSPs for extra traffic (with lower holding priority than 220 the protecting LSP) can then be established using the bandwidth 221 pre-reserved for the protecting LSP. Also, any lower priority LSP 222 that use the pre-reserved resources for the protecting LSP(s) 223 must be preempted during the activation of the protecting LSP. 225 4) Full LSP re-routing (or restoration) switches normal traffic to 226 an alternate LSP that is not even partially established until 227 after the working LSP failure occurs. The new alternate route is 228 selected at the LSP head-end node, it may reuse resources of the 229 failed LSP at intermediate nodes and may include additional 230 intermediate nodes and/or links. 232 Crankback signaling (see [CRANK]) and LSP segment recovery (see 233 [SEGREC]) are further detailed in dedicated companion documents. 235 3. Relationship to Fast Reroute (FRR) 237 There is no impact to RSVP-TE Fast Reroute (FRR) [RFC4090] 238 introduced by end-to-end GMPLS recovery i.e. it is possible to use 239 either method defined in FRR with end-to-end GMPLS recovery. 241 The objects used and/or newly introduced by end-to-end recovery will 242 be ignored by [RFC4090] conformant implementations, and FRR can 243 operate on a per LSP basis as defined in [RFC4090]. 245 4. Definitions 247 4.1 LSP Identification 249 This section reviews terms previously defined in [RFC2205], 250 [RFC3209], and [RFC3473]. LSP tunnels are identified by a 251 combination of the SESSION and SENDER_TEMPLATE objects (see also 252 [RFC3209]). The relevant fields are as follows: 254 IPv4 (or IPv6) tunnel end point address 256 IPv4 (or IPv6) address of the egress node for the tunnel. 258 Tunnel ID 260 A 16-bit identifier used in the SESSION that remains constant 261 over the life of the tunnel. 263 J.P.Lang et al. Expires February 2007 5 264 Extended Tunnel ID 266 A 32-bit (or 16-byte) identifier used in the SESSION that 267 remains constant over the life of the tunnel. Normally set to 268 all zeros. Ingress nodes that wish to narrow the scope of a 269 SESSION to the ingress-egress pair MAY place their IPv4 (or 270 IPv6) address here as a globally unique identifier. 272 IPv4 (or IPv6) tunnel sender address 274 IPv4 (or IPv6) address for a sender node. 276 LSP ID 278 A 16-bit identifier used in the SENDER_TEMPLATE and FILTER_SPEC 279 that can be changed to allow a sender to share resources with 280 itself. 282 The first three fields are carried in the SESSION object (Path and 283 Resv message) and constitute the basic identification of the LSP 284 tunnel. 286 The last two fields are carried in the SENDER_TEMPLATE (Path 287 message) and FILTER_SPEC objects (Resv message). The LSP ID is used 288 to differentiate LSPs that belong to the same LSP Tunnel (as 289 identified by its Tunnel ID). 291 4.2 Recovery Attributes 293 The recovery attributes include all the parameters that determine 294 the status of a LSP within the recovery scheme to which it is 295 associated. These attributes are part of the PROTECTION object 296 introduced in Section 14. 298 4.2.1 LSP Status 300 The following bits are used in determining resource allocation and 301 status of the LSP within the group of LSPs forming the protected 302 entity: 304 - S (Secondary) bit: enables distinction between primary and 305 secondary LSPs. A primary LSP is a fully established LSP for 306 which the resource allocation has been committed at the data plane 307 (i.e. full cross-connection has been performed). Both working and 308 protecting LSPs can be primary LSPs. A secondary LSP is an LSP 309 that has been provisioned in the control plane only and for which 310 resource selection MAY have been done but for which the resource 311 allocation has not been committed at the data plane (for instance, 312 no cross-connection has been performed). Therefore, a secondary 313 LSP is not immediately available to carry any traffic (requiring 314 thus additional signaling to be available). A secondary LSP can 316 J.P.Lang et al. Expires February 2007 6 317 only be a protecting LSP. The (data plane) resources allocated for 318 a secondary LSP MAY be used by other LSPs until the primary LSP 319 fails over to the secondary LSP. 321 - P (Protecting) bit: enables distinction between working and 322 protecting LSPs. A working LSP must be a primary LSP whilst a 323 protecting LSP can be either a primary or a secondary LSP. When 324 protecting LSP(s) are associated with working LSP(s), one also 325 refers to the latter as protected LSPs. 327 Note: The combination "secondary working" is not valid (only 328 protecting LSPs can be secondary LSPs). Working LSPs are always 329 primary LSPs (i.e. fully established) whilst primary LSPs can be 330 either working or protecting LSPs. 332 - O (Operational) bit: this bit is set when a protecting LSP is 333 carrying the normal traffic after protection switching (i.e. 334 applies only in case of dedicated LSP protection or LSP protection 335 with extra-traffic, see Section 4.2.2). 337 In this document, the PROTECTION object uses as a basis the 338 PROTECTION object defined in [RFC3471] and [RFC3473] and defines 339 additional fields within it. The fields defined in [RFC3471] and 340 [RFC3473] are unchanged by this document. 342 4.2.2 LSP Recovery 344 The following classification is used to distinguish the LSP 345 Protection Type with which LSPs can be associated at end-nodes (a 346 distinct value is associated with each Protection Type in the 347 PROTECTION object, see Section 14): 349 - Full LSP Re-routing: set if a primary working LSP is dynamically 350 recoverable using (non pre-planned) head-end re-routing. 352 - Pre-planned LSP Re-routing without Extra-traffic: set if a 353 protecting LSP is a secondary LSP that allows sharing of the 354 pre-reserved recovery resources between one or more than one 355 pair. When the secondary LSPs resources are not 356 pre-reserved for a single pair, this type is 357 referred to as "shared mesh" recovery. 359 - LSP Protection with Extra-traffic: set if a protecting LSP is a 360 dedicated primary LSP that allows for extra-traffic transport 361 and thus precludes any sharing of the recovery resources between 362 more than one pair. This type includes 1:N LSP 363 protection with extra-traffic. 364 - Dedicated LSP Protection: set if a protecting LSP does not allow 365 sharing of the recovery resources nor the transport of extra- 366 traffic (implying in the present context, duplication of the 367 signal over both working and protecting LSPs as in 1+1 dedicated 368 protection). Note also that this document makes a distinction 370 J.P.Lang et al. Expires February 2007 7 371 between 1+1 unidirectional and bi-directional dedicated LSP 372 protection. 374 For LSP protection, in particular when the data plane provides 375 automated protection switching capability (see for instance ITU-T 376 [G.841] Recommendation), a Notification (N) bit is defined in the 377 PROTECTION object. It allows for distinction between protection 378 switching signaling via the control plane or via the data plane. 380 Note: this document assumes that Protection Type values have end-to- 381 end significance and that the same value is sent over the protected 382 and the protecting path. In this context, shared-mesh for instance, 383 appears from the end-nodes perspective as being simply an LSP re- 384 routing without extra-traffic services. The net result of this is 385 that a single bit (the S bit alone) does not allow determining 386 whether resource allocation should be performed and this *with 387 respect to* the status of the LSP within the protected entity. The 388 introduction of the P bit solves this problem unambiguously. These 389 bits MUST be processed on a hop-by-hop basis (independently of the 390 LSP Protection Type context). This allows for an easier 391 implementation of reversion signaling (see Section 12) but also 392 facilitates the transparent delivery of protected services since any 393 intermediate node is not required to know the semantic associated 394 with the incoming LSP Protection Type value. 396 4.3 LSP Association 398 The ASSOCIATION object, introduced in Section 16, is used to 399 associate the working and protecting LSPs. 401 When used for signaling the working LSP, the Association ID of the 402 ASSOCIATION object (see Section 16) identifies the protecting LSP. 403 When used for signaling the protecting LSP, this field identifies 404 the LSP protected by the protecting LSP. 406 5. 1+1 Unidirectional Protection 408 One of the simplest notions of end-to-end LSP protection is 1+1 409 unidirectional protection. 411 Consider the following network topology: 413 A---B---C---D 414 \ / 415 E---F---G 417 The paths [A,B,C,D] and [A,E,F,G,D] are node and link disjoint, 418 ignoring the ingress/egress nodes A and D. A 1+1 protected path is 419 established from A to D over [A,B,C,D] and [A,E,F,G,D] and traffic 420 is transmitted simultaneously over both component paths (i.e. LSPs). 422 J.P.Lang et al. Expires February 2007 8 423 During the provisioning phase, both LSPs are fully instantiated (and 424 thus activated) so that no resource sharing can be done along the 425 protecting LSP (nor can any extra-traffic be transported). It is 426 also RECOMMENDED to set the N bit since no protection switching 427 signaling is assumed in this case. 429 When a failure occurs (say at node B) and is detected at end-node D, 430 the receiver at D selects the normal traffic from the other LSP. 431 From this perspective, 1+1 unidirectional protection can be seen as 432 an uncoordinated protection switching mechanism acting independently 433 at both end-points. Also, for the LSP under failure condition, it is 434 RECOMMENDED to not set the Path_State_Removed Flag of the ERROR_SPEC 435 object (see [RFC3473]) upon PathErr message generation. 437 Note: it is necessary that both paths are SRLG disjoint to ensure 438 recoverability otherwise a single failure may impact both working 439 and protecting LSPs. 441 5.1. Identifiers 443 To simplify association operations, both LSPs belong to the same 444 session. Thus, the SESSION object MUST be the same for both LSPs. 445 The LSP ID, however, MUST be different to distinguish between the 446 two LSPs. 448 A new PROTECTION object (see Section 14) is included in the Path 449 message. This object carries the desired end-to-end LSP Protection 450 Type, in this case, "1+1 Unidirectional". This LSP Protection Type 451 value is applicable to both uni- and bi-directional LSPs. 453 To allow distinguishing the working LSP (from which the signal is 454 taken) from the protecting LSP, the working LSP is signaled by 455 setting in the PROTECTION object the S bit to 0, the P bit to 0, and 456 in the ASSOCIATION object, the Association ID to the protecting 457 LSP_ID. The protecting LSP is signaled by setting in the PROTECTION 458 object the S bit to 0, the P bit to 1, and in the ASSOCIATION 459 object, the Association ID to the associated protected LSP_ID. 461 After protection switching completes, and after reception of the 462 PathErr message, to keep track of the LSP from which the signal is 463 taken, the protecting LSP SHOULD be signaled with the O-bit set. The 464 formerly working LSP MAY be signaled with the A bit set in the 465 ADMIN_STATUS object (see [RFC3473]). This process assumes the tail- 466 end node has notified the head-end node that traffic selection 467 switchover has occurred. 469 6. 1+1 Bi-directional Protection 471 1+1 bi-directional protection is a scheme that provides end-to-end 472 protection for bi-directional LSPs. 474 J.P.Lang et al. Expires February 2007 9 475 Consider the following network topology: 477 A---B---C---D 478 \ / 479 E---F---G 481 The LSPs [A,B,C,D] and [A,E,F,G,D] are node and link disjoint, 482 ignoring the ingress/egress nodes A and D. A bi-directional LSP is 483 established from A to D over each path and traffic is transmitted 484 simultaneously over both LSPs. In this scheme, both end-points must 485 receive traffic over the same LSP. Note also that both LSPs are 486 fully instantiated (and thus activated) so that no resource sharing 487 can be done along the protection path (nor can any extra-traffic be 488 transported). 490 When a failure is detected by one or both end-points of the LSP, 491 both end-points must select traffic from the other LSP. This action 492 must be coordinated between node A and D. From this perspective, 1+1 493 bi-directional protection can be seen as a coordinated protection 494 switching mechanism between both end-points. 496 Note: it is necessary that both paths are SRLG disjoint to ensure 497 recoverability, otherwise a single failure may impact both working 498 and protecting LSPs. 500 6.1. Identifiers 502 To simplify association operations, both LSPs belong to the same 503 session. Thus, the SESSION object MUST be the same for both LSPs. 504 The LSP ID, however, MUST be different to distinguish between the 505 two LSPs. 507 A new PROTECTION object (see Section 14) is included in the Path 508 message. This object carries the desired end-to-end LSP Protection 509 Type, in this case, "1+1 Bi-directional". This LSP Protection Type 510 value is only applicable to bi-directional LSPs. 512 It is also desirable to allow distinguishing the working (LSP from 513 which the signal is taken) from the protecting LSP. This is achieved 514 for the working LSP by setting in the PROTECTION object the S bit to 515 0, the P bit to 0, and in the ASSOCIATION object, the Association ID 516 to the protecting LSP_ID. The protecting LSP is signaled by setting 517 in the PROTECTION object the S bit to 0, the P bit to 1 and in the 518 ASSOCIATION object the Association ID to the associated protected 519 LSP_ID. 521 6.2. End-to-End Switchover Request/Response 523 To co-ordinate the switchover between end-points, an end-to-end 524 switchover request/response exchange is needed since a failure 525 affecting one the LSPs results in both end-points switching to the 527 J.P.Lang et al. Expires February 2007 10 528 other LSP (resulting in receiving traffic from the other LSP) in 529 their respective directions. 531 The procedure is as follows: 533 1. If an end-node (A or D) detects the failure of the working 534 LSP (or a degradation of signal quality over the working 535 LSP) or receives a Notify message including its SESSION 536 object within the (see 537 [RFC3473]), and the new error code/sub-code "Notify Error/ 538 LSP Locally Failed" in the (IF_ID)_ERROR_SPEC object, it 539 MUST begin receiving on the protecting LSP. Note that the 540 or is also present in 541 the Notify message that resolves any ambiguity and race 542 condition since identifying (together with the SESSION 543 object) the LSP under failure condition. 545 This node MUST reliably send a Notify message including the 546 MESSAGE_ID object to the other end-node (D or A, 547 respectively) with the new error code/sub-code "Notify 548 Error/LSP Failure" (Switchover Request) indicating the 549 failure of the working LSP. This Notify message MUST be sent 550 with the ACK_Desired flag set in the MESSAGE_ID object to 551 request the receiver to send an acknowledgment for the 552 message (see [RFC2961]). 554 This (switchover request) Notify message MAY indicate the 555 identity of the failed link or any other relevant 556 information using the IF_ID ERROR_SPEC object (see 557 [RFC3473]). In this case, the IF_ID ERROR_SPEC object 558 replaces the ERROR_SPEC object in the Notify message, 559 otherwise the corresponding (data plane) information SHOULD 560 be received in the PathErr/ResvErr message. 562 2. Upon receipt of the (switchover request) Notify message, the 563 end-node (D or A, respectively) MUST begin receiving from 564 the protecting LSP. 566 This node MUST reliably send a Notify message including the 567 MESSAGE_ID object to the other end-node (A or D, 568 respectively). This (switchover response) Notify message 569 MUST also include a MESSAGE_ID_ACK object to acknowledge 570 reception of the (switchover request) Notify message. 572 This (switchover response) Notify message MAY indicate the 573 identity of the failed link or any other relevant 574 information using the IF_ID ERROR_SPEC object (see 575 [RFC3473]). 577 Note: upon receipt of the (switchover response) Notify 578 message, the end-node (A or D, respectively) MUST send an 579 Ack message to the other end-node to acknowledge its 581 J.P.Lang et al. Expires February 2007 11 582 reception. 584 Since the intermediate nodes (B,C,E,F and G) are assumed to be GMPLS 585 RSVP-TE signaling capable, each node adjacent to the failure MAY 586 generate a Notify message directed either to the LSP head-end 587 (upstream direction) or the LSP tail-end (downstream direction) or 588 even both. Therefore, it is expected that these LSP terminating 589 nodes (that MAY also detect the failure of the LSP from the data 590 plane) provide either the right correlation mechanism to avoid 591 repetition of the above procedure or just discard subsequent Notify 592 messages corresponding to the same Session. In addition, for the LSP 593 under failure condition, it is RECOMMENDED to not set the 594 Path_State_ Removed Flag of the ERROR_SPEC object (see [RFC3473]) 595 upon PathErr message generation. 597 After protection switching completes (step 2), and after reception 598 of the PathErr message, to keep track of the LSP from which the 599 signal is taken, the protecting LSP SHOULD be signaled with the O- 600 bit set. The formerly working LSP MAY be signaled with the A bit set 601 in the ADMIN_STATUS object (see [RFC3473]). 603 Note: when the N bit is set, the end-to-end switchover request/ 604 response exchange described above only provides control plane 605 coordination (no actions are triggered at the data plane level). 607 7. 1:1 Protection with Extra-Traffic 609 The most common case of end-to-end 1:N protection is to establish, 610 between the same end-points, an end-to-end working LSP (thus, N = 1) 611 and a dedicated end-to-end protecting LSP that are mutually link/ 612 node/SRLG disjoint. This protects against working LSP failure(s). 614 The protecting LSP is used for switchover when the working LSP 615 fails. GMPLS RSVP-TE signaling allows for the pre-provisioning of 616 protecting LSPs by indicating in the Path message (in the PROTECTION 617 object, see Section 14) that the LSPs are of type protecting. Here, 618 working and protecting LSPs are signaled as primary LSPs; both are 619 fully instantiated during the provisioning phase. 621 Although the resources for the protecting LSP are pre-allocated, 622 preemptable traffic may be carried end-to-end using this LSP. Thus, 623 the protecting LSP is capable of carrying extra-traffic with the 624 caveat that this traffic will be preempted if the working LSP fails. 626 The setup of the working LSP SHOULD indicate that the LSP head-end 627 and tail-end node wish to receive Notify messages using the NOTIFY 628 REQUEST object. The node upstream to the failure (upstream in terms 629 of the direction an Path message traverses) SHOULD send a Notify 630 message to the LSP head-end node, and the node downstream to the 631 failure SHOULD send an Notify message to the LSP tail-end node. Upon 632 receipt of the Notify messages, both the end-nodes MUST switch the 633 (normal) traffic from the working LSP to the pre-configured 635 J.P.Lang et al. Expires February 2007 12 636 protecting LSP (see Section 7.2). Moreover some coordination is 637 required if extra-traffic is carried over the end-to-end protecting 638 LSP. Note that if the working and the protecting LSP are established 639 between the same end-nodes no further notification is required to 640 indicate that the working LSPs are no longer protected. 642 Consider the following topology: 644 A---B---C---D 645 \ / 646 E---F---G 648 The working LSP [A,B,C,D] could be protected by the protecting LSP 649 [A,E,F,G,D]. Both LSPs are fully instantiated (resources are 650 allocated for both working and protecting LSPs) and no resource 651 sharing can be done along the protection path since the primary 652 protecting LSP can carry extra-traffic. 654 Note: it is necessary that both paths are SRLG disjoint to ensure 655 recoverability otherwise a single failure may impact both working 656 and protecting LSPs. 658 7.1 Identifiers 660 To simplify association operations, both LSPs belong to the same 661 session. Thus, the SESSION object MUST be the same for both LSPs. 662 The LSP ID, however, MUST be different to distinguish between the 663 protected LSP carrying working traffic and the protecting LSP that 664 can carry extra-traffic. 666 A new PROTECTION object (see Section 14) is included in the Path 667 message used to setup the two LSPs. This object carries the desired 668 end-to-end LSP Protection Type, in this case, "1:N Protection with 669 Extra-Traffic". This LSP Protection Type value is applicable to both 670 uni- and bi-directional LSPs. 672 The working LSP is signaled by setting in the new PROTECTION object 673 the S bit to 0, the P bit to 0 and in the ASSOCIATION object the 674 Association ID to the protecting LSP_ID. 676 The protecting LSP is signaled by setting in the new PROTECTION 677 object the S bit to 0, the P bit to 1, and in the ASSOCIATION object 678 the Association ID to the associated protected LSP_ID. 680 7.2 End-to-End Switchover Request/Response 682 To co-ordinate the switchover between end-points, an end-to-end 683 switchover request/response is needed such that the affected LSP is 684 moved to the protecting LSP. Protection switching from the working 685 to the protecting LSP (implying preemption of extra-traffic carried 686 over the protecting LSP) must be initiated by one of the end-nodes 687 (A or D). 689 J.P.Lang et al. Expires February 2007 13 690 The procedure is as follows: 692 1. If an end-node (A or D) detects the failure of the working 693 LSP (or a degradation of signal quality over the working 694 LSP) or receives a Notify message including its SESSION 695 object within the (see 696 [RFC3473]), and the new error code/sub-code "Notify 697 Error/LSP Locally Failed" in the (IF_ID)_ERROR_SPEC object, 698 it disconnects the extra-traffic from the protecting LSP. 699 Note that the or is 700 also present in the Notify message that resolves any 701 ambiguity and race condition since identifying (together 702 with the SESSION object) the LSP under failure condition. 704 This node MUST reliably send a Notify message including the 705 MESSAGE_ID object to the other end-node (D or A, 706 respectively) with the new error code/sub-code "Notify 707 Error/LSP Failure" (Switchover Request) indicating the 708 failure of the working LSP. This Notify message MUST be sent 709 with the ACK_Desired flag set in the MESSAGE_ID object to 710 request the receiver to send an acknowledgment for the 711 message (see [RFC2961]). 713 This (switchover request) Notify message MAY indicate the 714 identity of the failed link or any other relevant 715 information using the IF_ID ERROR_SPEC object (see 716 [RFC3473]). In this case, the IF_ID ERROR_SPEC object 717 replaces the ERROR_SPEC object in the Notify message, 718 otherwise the corresponding (data plane) information SHOULD 719 be received in the PathErr/ResvErr message. 721 2. Upon receipt of the (switchover request) Notify message, the 722 end-node (D or A, respectively) MUST disconnect the extra- 723 traffic from the protecting LSP and begin sending/receiving 724 normal traffic out/from the protecting LSP. 726 This node MUST reliably send a Notify message including the 727 MESSAGE_ID object to the other end-node (A or D, 728 respectively). This (switchover response) Notify message 729 MUST also include a MESSAGE_ID_ACK object to acknowledge 730 reception of the (switchover request) Notify message. 732 This (switchover response) Notify message MAY indicate the 733 identity of the failed link or any other relevant 734 information using the IF_ID ERROR_SPEC object (see 735 [RFC3473]). 737 Note: since the Notify message generated by the other end- 738 node (A or D, respectively) is distinguishable from the one 739 generated by an intermediate node, there is no possibility 740 of connecting the extra traffic to the working LSP due to 742 J.P.Lang et al. Expires February 2007 14 743 the receipt of Notify message from an intermediate node. 745 3. Upon receipt of the (switchover response) Notify message, 746 the end-node (A or D, respectively) MUST begin 747 receiving/sending normal traffic from/out the protecting 748 LSP. 750 This node MUST also send an Ack message to the other end- 751 node (D or A, respectively) to acknowledge the reception of 752 the (switchover response) Notify message. 754 Note 1: a 2-phase protection switching signaling is used in the 755 present context, a 3-phase signaling (see [RFC4426]) that would 756 imply a notification message, a switchover request, and a switchover 757 response messages is not considered here. Also, when the protecting 758 LSPs do not carry extra-traffic, protection switching signaling as 759 defined in Section 6.2 MAY be used instead of the procedure 760 described in this section. 762 Note 2: when the N bit is set, the above end-to-end switchover 763 request/response exchange does only provide control plane 764 coordination (no actions are triggered at the data plane level). 766 After protection switching completes (step 3), and after reception 767 of the PathErr message, to keep track of the LSP from which the 768 normal traffic is taken, the protecting LSP SHOULD be signaled with 769 the O-bit set. In addition, the formerly working LSP MAY be signaled 770 with the A bit set in the ADMIN_STATUS object (see [RFC3473]). 772 7.3 1:N (N > 1) Protection with Extra-Traffic 774 1:N (N > 1) protection with extra-traffic assumes that the fully 775 provisioned protecting LSP is resource-disjoint from the N working 776 LSPs. This protecting LSP allows thus for carrying extra-traffic. 777 Note that the N working LSPs and the protecting LSP are all between 778 the same pair of end-points. In addition, the N working LSPs 779 (considered as identical in terms of traffic parameters) MAY be 780 mutually resource-disjoint. Coordination between end-nodes is 781 required when switching from one of the working to the protecting 782 LSP. 784 Each working LSP is signaled with both S bit and P bit set to 0. The 785 LSP Protection Type is set to 0x04 (1:N Protection with Extra- 786 Traffic) during LSP setup. Each Association ID points to the 787 protecting LSP ID. 789 The protecting LSP (carrying extra-traffic) is signaled with the S 790 bit set to 0 and the P bit set to 1. The LSP Protection Type is set 791 to 0x04 (1:N Protection with Extra-Traffic) during LSP setup. The 792 Association ID MUST be set by default to the LSP ID of the protected 793 LSP corresponding to N = 1. 795 J.P.Lang et al. Expires February 2007 15 796 Any signaling procedure applicable to 1:1 protection with extra- 797 traffic equally applies to 1:N protection with extra-traffic. 799 8. Re-routing without Extra-Traffic 801 End-to-end (pre-planned) re-routing without extra-traffic relies on 802 the establishment between the same pair of end-nodes of a working 803 LSP and a protecting LSP that is link/node/SRLG disjoint from the 804 working LSP. However, in this case the protecting LSP is not fully 805 instantiated, thus, it can not carry any extra-traffic (note that 806 this does not mean that the corresponding resources can not be used 807 by other LSPs). Therefore, this mechanism protects against working 808 LSP failure(s) but requires activation of the protecting LSP after 809 failure occurrence. 811 Signaling is performed by indicating in the Path message (in the 812 PROTECTION object, see Section 14) that the LSPs are of type working 813 and protecting, respectively. Protecting LSPs are used for fast 814 switchover when working LSPs fail. In this case, working and 815 protecting LSPs are signaled as primary LSP and secondary LSP, 816 respectively. Thus, only the working LSP is fully instantiated 817 during the provisioning phase and for the protecting LSPs, no 818 resources are committed at the data plane level (they are pre- 819 reserved at the control plane level only). The setup of the working 820 LSP SHOULD indicate (using the NOTIFY REQUEST object as specified in 821 Section 4 of [RFC3473]) that the LSP head-end node (and possibly the 822 tail-end node) wish to receive a Notify message upon LSP failure 823 occurrence. Upon receipt of the Notify message, the head-end node 824 MUST switch the (normal) traffic from the working LSP to the 825 protecting LSP after its activation. Note that since the working and 826 the protecting LSP are established between the same end-nodes no 827 further notification is required to indicate that the working LSPs 828 are no longer protected. 830 To make bandwidth pre-reserved for a protecting (but not activated) 831 LSP, available for extra traffic this bandwidth could be included in 832 the advertised Unreserved Bandwidth at priority lower (means 833 numerically higher) than the Holding Priority of the protecting LSP. 834 In addition, the Max LSP Bandwidth field in the Interface Switching 835 Capability Descriptor sub-TLV should reflect the fact that the 836 bandwidth pre-reserved for the protecting LSP is available for extra 837 traffic. LSPs for extra traffic then can be established using the 838 bandwidth pre-reserved for the protecting LSP by setting (in the 839 Path message) the Setup Priority field of the SESSION_ATTRIBUTE 840 object to X (where X is the Setup Priority of the protecting LSP) 841 and the Holding Priority field at least to X+1. Also, if the 842 resources pre-reserved for the protecting LSP are used by lower 843 priority LSPs, these LSPs MUST be preempted when the protecting LSP 844 is activated (see Section 10). 846 Consider the following topology: 848 J.P.Lang et al. Expires February 2007 16 849 A---B---C---D 850 \ / 851 E---F---G 853 The working LSP [A,B,C,D] could be protected by the protecting LSP 854 [A,E,F,G,D]. Only the protected LSP is fully instantiated (resources 855 are only allocated for the working LSP). Therefore, the protecting 856 LSP can not carry any extra-traffic. When a failure is detected on 857 the working LSP (say at B), the error is propagated and/or notified 858 (using a Notify message with the new error code/sub-code "Notify 859 Error/LSP Locally Failed" in the (IF_ID)_ERROR_SPEC object) to the 860 ingress node (A). Upon reception, the latter activates the secondary 861 protecting LSP instantiated during the (pre-)provisioning phase. 862 This requires: 863 (1) the ability to identify a "secondary protecting LSP" (hereby 864 called the "secondary LSP") used to recover another primary 865 working LSP (hereby called the "protected LSP") 866 (2) the ability to associate the secondary LSP with the protected 867 LSP 868 (3) the capability to activate a secondary LSP after failure 869 occurrence. 871 In the following subsections, these features are described in more 872 detail. 874 8.1 Identifiers 876 To simplify association operations, both LSPs (i.e. the protected 877 and the secondary LSPs) belong to the same session. Thus, the 878 SESSION object MUST be the same for both LSPs. The LSP ID, however, 879 MUST be different to distinguish between the protected LSP carrying 880 working traffic and the secondary LSP that can not carry extra- 881 traffic. 883 A new PROTECTION object (see Section 14) is used to setup the two 884 LSPs. This object carries the desired end-to-end LSP Protection Type 885 (in this case, "Re-routing without Extra-Traffic"). This LSP 886 Protection Type value is applicable to both uni- and bi-directional 887 LSPs. 889 8.2 Signaling Primary LSPs 891 The new PROTECTION object is included in the Path message during 892 signaling of the primary working LSP, with the end-to-end LSP 893 Protection Type value set to "Re-routing without Extra-Traffic". 895 Primary working LSPs are signaled by setting in the new PROTECTION 896 object the S bit to 0, the P bit to 0 and in the ASSOCIATION object 897 the Association ID to the associated secondary protecting LSP_ID. 899 8.3 Signaling Secondary LSPs 901 J.P.Lang et al. Expires February 2007 17 902 The new PROTECTION object is included in the Path message during 903 signaling of secondary protecting LSPs, with the end-to-end LSP 904 Protection Type value set to "Re-routing without Extra-Traffic". 906 Secondary protecting LSPs are signaled by setting in the new 907 PROTECTION object the S bit and the P bit to 1 and in the 908 ASSOCIATION object the Association ID to the associated primary 909 working LSP_ID, which MUST be known before signaling of the 910 secondary LSP. 912 With this setting, the resources for the secondary LSP SHOULD be 913 pre-reserved, but not committed at the data plane level meaning that 914 the internals of the switch need not be established until explicit 915 action is taken to activate this secondary LSP. Activation of a 916 secondary LSP is done using a modified Path message with the S bit 917 set to 0 in the PROTECTION object. At this point, the link and node 918 resources must be allocated for this LSP that becomes a primary LSP 919 (ready to carry normal traffic). 921 From [RFC3945], the secondary LSP is setup with resource pre- 922 reservation but with or without label pre-selection (both allowing 923 sharing of the recovery resources). In the former case (defined as 924 the default), label allocation during secondary LSP signaling does 925 not require any specific procedure compared to [RFC3473]. However, 926 in the latter case, label (and thus resource) re-allocation MAY 927 occur during the secondary LSP activation. This means that during 928 the LSP activation phase, labels MAY be re-assigned (with higher 929 precedence over existing label assignment, see also [RFC3471]). 931 Note: under certain circumstances (e.g. when pre-reserved protecting 932 resources are used by lower priority LSPs), it MAY be desirable to 933 perform the activation of the secondary LSP in the upstream 934 direction (Resv trigger message) instead of using the default 935 downstream activation. In this case, any mis-ordering and any mis- 936 interpretation between a refresh Resv (along the lower priority LSP) 937 and a trigger Resv message (along the secondary LSP) MUST be avoided 938 at any intermediate node. For this purpose, upon reception of the 939 Path message, the egress node MAY include the PROTECTION object in 940 the Resv message. The latter is then processed on a hop by hop basis 941 to activate the secondary LSP until reaching the ingress node. The 942 PROTECTION object included in the Path message MUST be set as 943 specified in this Section. In this case, the PROTECTION object with 944 the S bit MUST be set to 0 and included in the Resv message sent in 945 the upstream direction. The upstream activation behavior SHOULD be 946 configurable on a local basis. Details concerning lower priority LSP 947 preemption upon secondary LSP activation are provided in Section 10. 949 9. Shared-Mesh Restoration 951 An approach to reduce recovery resource requirements is to have 952 protection LSPs sharing network resources when the working LSPs that 953 they protect are physically (i.e., link, node, SRLG, etc.) disjoint. 955 J.P.Lang et al. Expires February 2007 18 956 This mechanism is referred to as shared mesh restoration and is 957 described in [RFC4426]. Shared-mesh restoration can be seen as a 958 particular case of pre-planned LSP re-routing (see Section 8) that 959 reduces the recovery resource requirements by allowing multiple 960 protecting LSPs to share common link and node resources. Here also, 961 the recovery resources for the protecting LSPs are pre-reserved 962 during the provisioning phase, thus an explicit signaling action is 963 required to activate (i.e. commit resource allocation at the data 964 plane) a specific protecting LSP instantiated during the (pre-) 965 provisioning phase. This requires restoration signaling along the 966 protecting LSP. 968 To make bandwidth pre-reserved for a protecting (but not activated) 969 LSP, available for extra traffic this bandwidth could be included in 970 the advertised Unreserved Bandwidth at priority lower (means 971 numerically higher) than the Holding Priority of the protecting LSP. 972 In addition, the Max LSP Bandwidth field in the Interface Switching 973 Capability Descriptor sub-TLV should reflect the fact that the 974 bandwidth pre-reserved for the protecting LSP is available for extra 975 traffic. LSPs for extra traffic then can be established using the 976 bandwidth pre-reserved for the protecting LSP by setting (in the 977 Path message) the Setup Priority field of the SESSION_ATTRIBUTE 978 object to X (where X is the Setup Priority of the protecting LSP) 979 and the Holding Priority field at least to X+1. Also, if the 980 resources pre-reserved for the protecting LSP are used by lower 981 priority LSPs, these LSPs MUST be preempted when the protecting LSP 982 is activated (see Section 10). Further, if the recovery resources 983 are shared between multiple protecting LSPs, the corresponding 984 working LSPs head-end nodes must be informed that they are no longer 985 protected when the protecting LSP is activated to recover the normal 986 traffic for the working LSP under failure. 988 Consider the following topology: 990 A---B---C---D 991 \ / 992 E---F---G 993 / \ 994 H---I---J---K 996 The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by 997 [A,E,F,G,D] and [H,E,F,G,K], respectively. Per [RFC3209], in order 998 to achieve resource sharing during the signaling of these protecting 999 LSPs, they must have the same Tunnel Endpoint Address (as part of 1000 their SESSION object). However, these addresses are not the same in 1001 this example. Resource sharing along E, F, G can only be achieved if 1002 the nodes E, F and G recognize that the LSP Protection Type of the 1003 secondary LSPs is set to "Re-routing without Extra-Traffic" (see 1004 PROTECTION object, Section 14) and acts accordingly. In this case, 1006 J.P.Lang et al. Expires February 2007 19 1007 the protecting LSPs are not merged (which is useful since the paths 1008 diverge at G), but the resources along E, F, G can be shared. 1010 When a failure is detected on one of the working LSPs (say at B), 1011 the error is propagated and/or notified (using a Notify message with 1012 the new error code/sub-code "Notify Error/LSP Locally Failed" in the 1013 (IF_ID)_ERROR_SPEC object) to the ingress node (A). Upon reception, 1014 the latter activates the secondary protecting LSP (see Section 8). 1015 At this point, it is important that a failure on the other LSP (say 1016 at J) does not cause the other ingress (H) to send the data down the 1017 protecting LSP since the resources are already in use. This can be 1018 achieved by node E using the following procedure. When the capacity 1019 is first reserved for the protecting LSP, E should verify that the 1020 LSPs being protected ([A,B,C,D] and [H,I,J,K], respectively) do not 1021 share any common resources. Then, when a failure occurs (say at B) 1022 and the protecting LSP [A,E,F,G,D] is activated, E should notify H 1023 that the resources for the protecting LSP [H,E,F,G,K] are no longer 1024 available. 1026 The following sub-sections details how shared mesh restoration can 1027 be implemented in an interoperable fashion using GMPLS RSVP-TE 1028 extensions (see [RFC3473]). This includes: 1029 (1) the ability to identify a "secondary protecting LSP" (hereby 1030 called the "secondary LSP") used to recover another primary 1031 working LSP (hereby called the "protected LSP") 1032 (2) the ability to associate the secondary LSP with the protected 1033 LSP 1034 (3) the capability to include information about the resources used 1035 by the protected LSP while instantiating the secondary LSP. 1036 (4) the capability to instantiate during the provisioning phase 1037 several secondary LSPs in an efficient manner. 1038 (5) the capability to activate a secondary LSP after failure 1039 occurrence. 1041 In the following subsections, these features are described in 1042 detail. 1044 9.1. Identifiers 1046 To simplify association operations, both LSPs (i.e. the protected 1047 and the secondary LSPs) belong to the same session. Thus, the 1048 SESSION object MUST be the same for both LSPs. The LSP ID, however, 1049 MUST be different to distinguish between the protected LSP carrying 1050 working traffic and the secondary LSP that can not carry extra- 1051 traffic. 1053 A new PROTECTION object (see Section 14) is used to setup the two 1054 LSPs. This object carries the desired end-to-end LSP Protection 1055 Type, in this case, "Re-routing without Extra-Traffic". This LSP 1056 Protection Type value is applicable to both uni- and bi-directional 1057 LSPs. 1059 J.P.Lang et al. Expires February 2007 20 1060 9.2 Signaling Primary LSPs 1062 The new PROTECTION object is included in the Path message during 1063 signaling of the primary working LSPs, with the end-to-end LSP 1064 Protection Type value set to "Re-routing without Extra-Traffic". 1066 Primary working LSPs are signaled by setting in the new PROTECTION 1067 object the S bit to 0, the P bit to 0 and in the ASSOCIATION object 1068 the Association ID to the associated secondary protecting LSP_ID. 1070 9.3 Signaling Secondary LSPs 1072 The new PROTECTION object is included in the Path message during 1073 signaling of the secondary protecting LSPs, with the end-to-end LSP 1074 Protection Type value set to "Re-routing without Extra-Traffic". 1076 Secondary protecting LSPs are signaled by setting in the new 1077 PROTECTION object the S bit and the P bit to 1 and in the 1078 ASSOCIATION object the Association ID to the associated primary 1079 working LSP_ID, which MUST be known before signaling of the 1080 secondary LSP. Moreover, the Path message used to instantiate the 1081 secondary LSP SHOULD include at least one PRIMARY PATH ROUTE object 1082 (see Section 15) that further allows for recovery resource sharing 1083 at each intermediate node along the secondary path. 1085 With this setting, the resources for the secondary LSP SHOULD be 1086 pre-reserved, but not committed at the data plane level meaning that 1087 the internals of the switch need not be established until explicit 1088 action is taken to activate this LSP. Activation of a secondary LSP 1089 is done using a modified Path message with the S bit set to 0 in the 1090 PROTECTION object. At this point, the link and node resources must 1091 be allocated for this LSP that becomes a primary LSP (ready to carry 1092 normal traffic). 1094 From [RFC3945], the secondary LSP is setup with resource pre- 1095 reservation but with or without label pre-selection (both allowing 1096 sharing of the recovery resources). In the former case (defined as 1097 the default), label allocation during secondary LSP signaling does 1098 not require any specific procedure compared to [RFC3473]. However, 1099 in the latter case, label (and thus resource) re-allocation MAY 1100 occur during the secondary LSP activation. This means that during 1101 the LSP activation phase, labels MAY be re-assigned (with higher 1102 precedence over existing label assignment, see also [RFC3471]). 1104 10. LSP Preemption 1106 When protecting resources are only pre-reserved for the secondary 1107 LSPs, they MAY be used to setup lower priority LSPs. In this case, 1108 these resources MUST be preempted when the protecting LSP is 1109 activated. An additional condition raises from mis-connection 1110 avoidance between the secondary protecting LSP being activated and 1111 the low priority LSP(s) being preempted. Procedure to be applied 1113 J.P.Lang et al. Expires February 2007 21 1114 when the secondary protecting LSP (i.e. the pre-empting LSP) Path 1115 message reaches a node using the resources for lower priority LSP(s) 1116 (i.e. pre-empted LSP(s)) is as follows: 1118 1. Deallocate resources to be used by the pre-empting LSP and 1119 release the cross-connection. Note that if the pre-empting LSP is 1120 bi-directional, these resources may come from one or two lower 1121 priority LSPs, and if from two LSPs, they may be uni- or bi- 1122 directional. The pre-empting node SHOULD NOT send the Path message 1123 before the deallocation of resources has completed since this may 1124 lead to the downstream path becoming misconnected if the downstream 1125 node is able to re-assign the resources more quickly. 1127 2. Send PathTear and PathErr messages with the new error code/sub- 1128 code "Policy Control failure/Hard Pre-empted" and the Path_State_ 1129 Removed flag set for the pre-empted LSP(s). 1131 3. Reserve the pre-empted resources for the protecting LSP. The pre- 1132 empting node MUST NOT cross-connect the upstream resources of a bi- 1133 directional pre-empting LSP. 1135 4. Send the Path message. 1137 5. Upon reception of a trigger Resv message from the downstream 1138 node, cross-connect the downstream path resources and if the pre- 1139 empting LSP is bi-directional, perform cross-connection for the 1140 upstream path resources. 1142 Note that step 1 may cause alarms to be raised for the pre-empted 1143 LSP. If alarm suppression is desired the pre-empting node MAY insert 1144 the following steps before step 1. 1146 1a. Before deallocating resources send a Resv message including an 1147 ADMIN_STATUS object to disable alarms for the pre-empted LSP. 1148 1b. Receive a Path message indicating that alarms are disabled. 1150 At the downstream node (with respect to the pre-empting LSP) the 1151 processing is RECOMMENDED to be as follows: 1153 1. Receive PathTear (and/or PathErr) message for the pre-empted 1154 LSP(s). 1156 2a.Release the resources associated with the LSP on the interface 1157 to the pre-empting LSP, remove any cross-connection and release 1158 all other resources associated with the pre-empted LSP. 1159 2b.Forward the PathTear (and/or PathErr) message per [RFC3473]. 1161 3. Receive the Path message for the pre-empting LSP and process as 1162 normal, forwarding it to the downstream node. 1164 4. Receive the Resv message for the pre-empting LSP and process as 1165 normal, forwarding it to the upstream node. 1167 J.P.Lang et al. Expires February 2007 22 1168 11. (Full) LSP Re-routing 1170 LSP re-routing, on the other hand, switches normal traffic to an 1171 alternate LSP that is fully established only after failure 1172 occurrence. The new (alternate) route is selected at the LSP head- 1173 end and may reuse intermediate nodes included in the original route; 1174 it may also include additional intermediate nodes. For strict-hop 1175 routing, TE requirements can be directly applied to the route 1176 computation, and the failed node or link can be avoided. However, if 1177 the failure occurred within a loose-routed hop, the head-end node 1178 may not have enough information to reroute the LSP around the 1179 failure. Crankback signaling (see [CRANK]) and route exclusion 1180 techniques (see [XRO]) MAY be used in this case. 1182 The alternate route MAY be either computed on demand (that is, when 1183 the failure occurs; this is referred to as full LSP re-routing) or 1184 pre-computed and stored for use when the failure is reported. The 1185 latter offers faster restoration time. There is, however, a risk 1186 that the alternate route will become out of date through other 1187 changes in the network - this can be mitigated to some extent by 1188 periodic recalculation of idle alternate routes. 1190 (Full) LSP re-routing will be initiated by the head-end node that 1191 has either detected the LSP failure or received a Notify message 1192 and/or a PathErr message with the new error code/sub-code "Notify 1193 Error/LSP Locally Failed" for this LSP. The new LSP resources can be 1194 established using the make-before-break mechanism, where the new LSP 1195 is setup before the old LSP is torn down. This is done by using the 1196 mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit 1197 (SE) reservation style (see [RFC3209]). Both the new and old LSPs 1198 can share resources at common nodes. 1200 Note that the make-before-break mechanism is not used to avoid 1201 disruption to the normal traffic flow (the latter has already been 1202 broken by the failure that is being repaired). However, it is 1203 valuable to retain the resources allocated on the original LSP that 1204 will be re-used by the new alternate LSP. 1206 11.1 Identifiers 1208 The Tunnel End Point Address, Tunnel ID, Extended Tunnel ID, Tunnel 1209 Sender Address uniquely identify both the old and new LSPs. Only the 1210 LSP_ID value differentiates the old from the new alternate LSP. The 1211 new alternate LSP is setup before the old LSP is torn down using 1212 Shared-Explicit (SE) reservation style. This ensures that the new 1213 (alternate) LSP is established without double counting resource 1214 requirements along common segments. 1216 The alternate LSP MAY be setup before any failure occurrence with SE 1217 style resource reservation, the latter shares the same Tunnel End 1218 Point Address, Tunnel ID, Extended Tunnel ID, and Tunnel Sender 1220 J.P.Lang et al. Expires February 2007 23 1221 Address with the original LSP (i.e. only the LSP ID value MUST be 1222 different). 1224 In both cases, the Association ID of the ASSOCIATION object MUST be 1225 set to the LSP ID value of the signaled LSP. 1227 11.2 Signaling Re-routable LSPs 1229 A new PROTECTION object is included in the Path message during 1230 signaling of dynamically re-routable LSPs, with the end-to-end LSP 1231 Protection Type value set to "Full Re-routing". These LSPs that can 1232 be either uni- or bi-directional are signaled by setting in the 1233 PROTECTION object the S bit to 0, the P bit to 0 and the Association 1234 ID value to the LSP_ID value of the signaled LSP. Any specific 1235 action to be taken during the provisioning phase is up to the end- 1236 node local policy. 1238 Note: when the end-to-end LSP Protection Type is set to 1239 "Unprotected", both S and P bit MUST be set to 0 and the LSP SHOULD 1240 NOT be re-routed at the head-end node after failure occurrence. The 1241 Association_ID value MUST be set to the LSP_ID value of the signaled 1242 LSP. This does not mean that the Unprotected LSP can not be re- 1243 established for other reasons such as path re-optimization and 1244 bandwidth adjustment driven by policy conditions. 1246 12. Reversion 1248 Reversion refers to a recovery switching operation, where the normal 1249 traffic returns to (or remains on) the working LSP when it has 1250 recovered from the failure. Reversion implies that resources remain 1251 allocated to the LSP that was originally routed over them even after 1252 a failure. It is important to have mechanisms that allow reversion 1253 to be performed with minimal service disruption and reconfiguration. 1255 For "1+1 bi-directional Protection", reversion to the recovered LSP 1256 occurs by using the following sequence: 1258 1. Clear the A bit of the ADMIN_STATUS object if set for the 1259 recovered LSP. 1261 2. Then, apply the method described here below to switch normal 1262 traffic back from the protecting to the recovered LSP. This is 1263 performed by using the new error code/sub-code "Notify Error/LSP 1264 Recovered" (Switchback Request). 1266 The procedure is as follows: 1268 1. The initiating (source) node sends the normal traffic onto 1269 both the working and the protecting LSPs. Once completed, the 1270 source node sends reliably a Notify message to the destination 1271 with the new error code/sub-code "Notify Error/LSP Recovered" 1272 (Switchback Request). This Notify message includes the 1274 J.P.Lang et al. Expires February 2007 24 1275 MESSAGE_ID object. The ACK_Desired flag MUST be set in this 1276 object to request the receiver to send an acknowledgment for 1277 the message (see [RFC2961]). 1279 2. Upon receipt of this message, the destination selects the 1280 traffic from the working LSP. At the same time, it transmits 1281 the traffic onto both the working and protecting LSP. 1283 The destination then sends reliably a Notify message to the 1284 source confirming the completion of the operation. This 1285 message includes the MESSAGE_ID_ACK object to acknowledge 1286 reception of the received Notify message. This Notify message 1287 also includes the MESSAGE_ID object. The ACK_Desired flag MUST 1288 be set in this object to request the receiver to send an 1289 acknowledgment for the message (see [RFC2961]). 1291 3. When the source node receives this Notify message, it switches 1292 to receive traffic from the working LSP. 1294 The source node then sends an Ack message to the destination 1295 node confirming that the LSP has been reverted. 1297 3. Finally, clear the O bit of the PROTECTION object sent over the 1298 protecting LSP. 1300 For "1:N Protection with Extra-traffic", reversion to the recovered 1301 LSP occurs by using the following sequence: 1303 1. Clear the A bit of the ADMIN_STATUS object if set for the 1304 recovered LSP. 1306 2. Then, apply the method described here below to switch normal 1307 traffic back from the protecting to the recovered LSP. This is 1308 performed by using the new error code/sub-code "Notify Error/LSP 1309 Recovered" (Switchback Request). 1311 The procedure is as follows: 1313 1. The initiating (source) node sends the normal traffic onto 1314 both the working and the protecting LSPs. Once completed, the 1315 source node sends reliably a Notify message to the destination 1316 with the new error code/sub-code "Notify Error/LSP Recovered" 1317 (Switchback Request). This Notify message includes the 1318 MESSAGE_ID object. The ACK_Desired flag MUST be set in this 1319 object to request the receiver to send an acknowledgment for 1320 the message (see [RFC2961]). 1322 2. Upon receipt of this message, the destination selects the 1323 traffic from the working LSP. At the same time, it transmits 1324 the traffic onto both the working and protecting LSP. 1326 The destination then sends reliably a Notify message to the 1328 J.P.Lang et al. Expires February 2007 25 1329 source confirming the completion of the operation. This 1330 message includes the MESSAGE_ID_ACK object to acknowledge 1331 reception of the received Notify message. This Notify message 1332 also includes the MESSAGE_ID object. The ACK_Desired flag MUST 1333 be set in this object to request the receiver to send an 1334 acknowledgment for the message (see [RFC2961]). 1336 3. When the source node receives this Notify message, it switches 1337 to receive traffic from the working LSP, and stops 1338 transmitting traffic on the protecting LSP. 1340 The source node then sends an Ack message to the destination 1341 node confirming that the LSP has been reverted. 1343 4. Upon receipt of this message, the destination node stops 1344 transmitting traffic along the protecting LSP. 1346 3. Finally, clear the O bit of the PROTECTION object sent over the 1347 protecting LSP. 1349 For "Re-routing without Extra-traffic" (including the shared 1350 recovery case), reversion implies that the formerly working LSP has 1351 not been torn down by the head-end node upon PathErr message 1352 reception i.e. the head-end node kept refreshing the working LSP 1353 under failure condition. This ensures that the exact same resources 1354 are retrieved after reversion switching (except if the working LSP 1355 required re-signaling). Re-activation is performed using the 1356 following sequence: 1358 1. Clear the A bit of the ADMIN_STATUS object if set for the 1359 recovered LSP. 1361 2. Then, apply the method described here below to switch normal 1362 traffic back from the protecting to the recovered LSP. This is 1363 performed by using the new error code/sub-code "Notify Error/LSP 1364 Recovered" (Switchback Request). 1366 The procedure is as follows: 1368 1. The initiating (source) node sends the normal traffic onto 1369 both the working and the protecting LSPs. Once completed, the 1370 source node sends reliably a Notify message to the destination 1371 with the new error code/sub-code "Notify Error/LSP Recovered" 1372 (Switchback Request). This Notify message includes the 1373 MESSAGE_ID object. The ACK_Desired flag MUST be set in this 1374 object to request the receiver to send an acknowledgment for 1375 the message (see [RFC2961]). 1377 2. Upon receipt of this message, the destination selects the 1378 traffic from the working LSP. At the same time, it transmits 1379 the traffic onto both the working and protecting LSP. 1381 J.P.Lang et al. Expires February 2007 26 1382 The destination then sends reliably a Notify message to the 1383 source confirming the completion of the operation. This 1384 message includes the MESSAGE_ID_ACK object to acknowledge 1385 reception of the received Notify message. This Notify message 1386 also includes the MESSAGE_ID object. The ACK_Desired flag MUST 1387 be set in this object to request the receiver to send an 1388 acknowledgment for the message (see [RFC2961]). 1390 3. When the source node receives this Notify message, it switches 1391 to receive traffic from the working LSP, and stops 1392 transmitting traffic on the protecting LSP. 1394 The source node then sends an Ack message to the destination 1395 node confirming that the LSP has been reverted. 1397 4. Upon receipt of this message, the destination node stops 1398 transmitting traffic along the protecting LSP. 1400 3. Finally, de-activate the protecting LSP by setting the S bit to 1 1401 in the PROTECTION object sent over the protecting LSP. 1403 13. Recovery Commands 1405 This section specifies the control plane behavior when using several 1406 commands (see [RFC4427]) that can be used to influence the recovery 1407 operations. 1409 A. Lockout of recovery LSP: 1411 The Lockout bit (L bit) of the ADMIN_STATUS object is used following 1412 the rules defined in Section 8 of [RFC3471] and Section 7 of 1413 [RFC3473]. The L bit must be set together with the Reflect (R) bit 1414 in the ADMIN_STATUS object sent in the Path message. Upon reception 1415 of the Resv message with the L bit set, this forces the recovery LSP 1416 to be temporarily unavailable to transport traffic (either normal or 1417 extra traffic). Unlock is performed by clearing the L bit, following 1418 the rules defined in Section 7 of [RFC3473]. This procedure is only 1419 applicable when the LSP Protection Type Flag is set to either 0x04 1420 (1:N Protection with Extra-Traffic), or 0x08 (1+1 Unidirectional 1421 Protection) or 0x10 (1+1 Bi-directional Protection). 1423 The updated format of the ADMIN_STATUS object to include the L bit 1424 is as follows: 1426 0 1 2 3 1427 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 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 | Length | Class-Num(196)| C-Type (1) | 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 |R| Reserved |L|I|C|T|A|D| 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 J.P.Lang et al. Expires February 2007 27 1435 Lockout (L): 1 bit 1437 When set, indicates forces the recovery LSP to be temporarily 1438 unavailable to transport traffic (either normal or extra 1439 traffic). 1441 The R (Reflect), T (Testing), A (Administratively down) and D 1442 (Deletion in progress) bits are defined in [RFC3471]. The C (Call 1443 control) bit is defined in [GMPLS-CALL], and the I (Inhibit alarm 1444 communication) bit in [ALARM]. 1446 B. Lockout of normal traffic: 1448 The O bit of the PROTECTION object is set to 1 to force the recovery 1449 LSP to be temporarily unavailable to transport normal traffic. This 1450 operation MUST NOT occur unless the working LSP is carrying the 1451 normal traffic. Unlock is performed by clearing the O bit over the 1452 protecting LSP. This procedure is only applicable when the LSP 1453 Protection Type Flag is set to either 0x04 (1:N Protection with 1454 Extra-Traffic), or 0x08 (1+1 Unidirectional Protection) or 0x10 (1+1 1455 Bi-directional Protection). 1457 C. Forced switch for normal traffic: 1459 Recovery signaling is initiated that switches normal traffic to the 1460 recovery LSP following the procedures defined in Section 6, 7, 8 and 1461 9. 1463 D. Requested switch for normal traffic: 1465 Recovery signaling is initiated that switches normal traffic to the 1466 recovery LSP following the procedures defined in Section 6, 7, 8 and 1467 9. This, except if a fault condition exists on other LSPs/spans 1468 (including the recovery LSP) or an equal or higher priority switch 1469 command is in effect. 1471 E. Requested switch for recovery LSP: 1473 Recovery signaling is initiated that switches normal traffic to the 1474 working LSP following the procedure defined in Section 12. This, 1475 except if a fault condition exists on the working LSP or an equal or 1476 higher priority switch command is in effect. 1478 14. PROTECTION Object 1480 This section describes the extensions to the PROTECTION object to 1481 broaden its applicability to end-to-end LSP recovery. 1483 14.1 Format 1485 The format of the PROTECTION Object (Class-Num = 37, C-Type = 2, 1486 suggested value, TBA by IANA) is as follows: 1488 J.P.Lang et al. Expires February 2007 28 1489 0 1 2 3 1490 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 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 | Length | Class-Num(37) | C-Type (TBA) | 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 |S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags| 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 | Reserved | 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 Secondary (S): 1 bit 1501 When set to 1, this bit indicates that the requested LSP is a 1502 secondary LSP. When set to 0 (default), it indicates that the 1503 requested LSP is a primary LSP. 1505 Protecting (P): 1 bit 1507 When set to 1, this bit indicates that the requested LSP is a 1508 protecting LSP. When set to 0 (default), it indicates that the 1509 requested LSP is a working LSP. The combination, S set to 1 1510 with P set to 0 is not valid. 1512 Notification (N): 1 bit 1514 When set to 1, this bit indicates that the control plane 1515 message exchange is only used for notification during 1516 protection switching. When set to 0 (default), it indicates 1517 that the control plane message exchanges are used for 1518 protection switching purposes. The N bit is only applicable 1519 when the LSP Protection Type Flag is set to either 0x04 (1:N 1520 Protection with Extra-Traffic), or 0x08 (1+1 Unidirectional 1521 Protection) or 0x10 (1+1 Bi-directional Protection). The N bit 1522 MUST be set to 0 in any other case. 1524 Operational (O): 1 bit 1526 When set to 1, this bit indicates that the protecting LSP is 1527 carrying the normal traffic after protection switching. The O 1528 bit is only applicable when the P bit is set to 1 and the LSP 1529 Protection Type Flag is set to either 0x04 (1:N Protection 1530 with Extra-Traffic), or 0x08 (1+1 Unidirectional Protection) 1531 or 0x10 (1+1 Bi-directional Protection). The O bit MUST be set 1532 to 0 in any other case. 1534 Reserved: 5 bits 1536 This field is reserved. It MUST be set to zero on transmission 1537 and MUST be ignored on receipt. These bits SHOULD be passed 1538 through unmodified by transit nodes. 1540 J.P.Lang et al. Expires February 2007 29 1541 LSP (Protection Type) Flags: 6 bits 1543 Indicates the desired end-to-end LSP recovery type. A value of 1544 0 implies that the LSP is "Unprotected". Only one value SHOULD 1545 be set at a time. The following values are defined. All other 1546 values are reserved. 1548 0x00 Unprotected 1549 0x01 (Full) Re-routing 1550 0x02 Re-routing without Extra-Traffic 1551 0x04 1:N Protection with Extra-Traffic 1552 0x08 1+1 Unidirectional Protection 1553 0x10 1+1 Bi-directional Protection 1555 Reserved: 10 bits 1557 This field is reserved. It MUST be set to zero on transmission 1558 and MUST be ignored on receipt. These bits SHOULD be passed 1559 through unmodified by transit nodes. 1561 Link Flags: 6 bits 1563 Indicates the desired link protection type (see [RFC3471]). 1565 Reserved field: 32 bits 1567 Encoding of this field is detailed in [SEGREC]. 1569 14.2 Processing 1571 Intermediate and egress nodes processing a Path message containing a 1572 PROTECTION object MUST verify that the requested LSP Protection Type 1573 can be satisfied by the incoming interface. If it can not, the node 1574 MUST generate a PathErr message, with the new error code/sub-code 1575 "Routing problem/Unsupported LSP Protection". 1577 Intermediate nodes processing a Path message containing a PROTECTION 1578 object with the LSP Protection Type 0x02 (Re-routing without Extra- 1579 Traffic) value set and a PRIMARY PATH ROUTE object (see Section 15) 1580 MUST verify that the requested LSP Protection Type can be supported 1581 by the outgoing interface. If it can not, the node MUST generate a 1582 PathErr message with the new error code/sub-code "Routing 1583 problem/Unsupported LSP Protection". 1585 15. PRIMARY PATH ROUTE Object 1587 The PRIMARY PATH ROUTE object (PPRO) is defined to inform nodes 1588 along the path of a secondary protecting LSP about which resources 1589 (link/nodes) are being used by the associated primary protected LSP 1590 (as specified by the Association ID field). If the LSP Protection 1591 Type value is set to 0x02 (Re-routing without Extra-Traffic), this 1592 object SHOULD be present in the Path message for the pre- 1594 J.P.Lang et al. Expires February 2007 30 1595 provisioning of the secondary protecting LSP to enable recovery 1596 resource sharing between one or more secondary protecting LSPs (see 1597 Section 9). This document does not assume or preclude any other 1598 usage for this object. 1600 PRIMARY PATH ROUTE objects carry information extracted from the 1601 EXPLICIT ROUTE object and/or the RECORD ROUTE object of the primary 1602 working LSPs they protect. Selection of the PPRO content is up to 1603 local policy of the head-end node that initiates the request. 1604 Therefore, the information included in these objects can be used as 1605 policy-based admission control to ensure that recovery resources are 1606 only shared between secondary protecting LSPs whose associated 1607 primary LSPs have link/node/SRLG disjoint paths. 1609 15.1 Format 1611 The primary path route is specified via the PRIMARY_PATH_ROUTE 1612 object (PPRO). The Primary Path Route Class Number (Class-Num) of 1613 form 0bbbbbbb is TBA by IANA. 1615 Currently one C-Type (Class-Type) is defined, Type 1, Primary Path 1616 Route. The PRIMARY_PATH_ROUTE object has the following format: 1618 Class-Num = TBA by IANA (of form 0bbbbbbb), C-Type = 1 (suggested) 1620 0 1 2 3 1621 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 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1623 | | 1624 // (Subobjects) // 1625 | | 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1628 The contents of a PRIMARY_PATH_ROUTE object are a series of 1629 variable-length data items called subobjects (see Section 15.3). 1631 To signal a secondary protecting LSP, the Path message MAY include 1632 one or multiple PRIMARY_PATH_ROUTE objects, where each object is 1633 meaningful. The latter is useful when a given secondary protecting 1634 LSP must be link/node/SRLG disjoint from more than one primary LSP 1635 (i.e. is protecting more than one primary LSP). 1637 15.2 Subobjects 1639 The PRIMAY_PATH_ROUTE object is defined as a list of variable-length 1640 data items called subobjects. These subobjects are derived from the 1641 subobjects of the EXPLICIT ROUTE and/or RECORD ROUTE object of the 1642 primary working LSP(s). 1644 Each subobject has its own length field. The length contains the 1645 total length of the subobject in bytes, including the Type and 1647 J.P.Lang et al. Expires February 2007 31 1648 Length fields. The length MUST always be a multiple of 4, and at 1649 least 4. 1651 The following subobjects are currently defined for the PRIMARY PATH 1652 ROUTE object: 1654 - Sub-Type 1: IPv4 Address (see [RFC3209]) 1655 - Sub-Type 2: IPv6 Address (see [RFC3209]) 1656 - Sub-Type 3: Label (see [RFC3473]) 1657 - Sub-Type 4: Unnumbered Interface (see [RFC3477]) 1659 An empty PPRO with no subobjects is considered as illegal. If there 1660 is no first subobject, the corresponding Path message is also in 1661 error and the receiving node SHOULD return a PathErr message with 1662 the new error code/sub-code "Routing Problem/Bad PRIMARY PATH_ROUTE 1663 object". 1665 Note: an intermediate node processing a PPRO can derive SRLG 1666 identifiers from the local IGP-TE database using its Type 1, 2 or 4 1667 subobject values as pointers to the corresponding TE Links (assuming 1668 each of them has an associated SRLG TE attribute). 1670 15.3 Applicability 1672 The PRIMARY_PATH_ROUTE object MAY only be used when all GMPLS nodes 1673 along the path support the PRIMARY_PATH_ROUTE object and a secondary 1674 protecting LSP is being requested. The PRIMARY_PATH_ROUTE object is 1675 assigned a class value of the form 0bbbbbbb. Receiving GMPLS nodes 1676 along the path that do not support this object MUST return a PathErr 1677 message with the "Unknown Object Class" error code (see [RFC2205]). 1679 Also, the following restrictions MUST be applied with respect to the 1680 PPRO usage: 1682 - PPROs MAY only be included in Path messages when signaling 1683 secondary protecting LSPs (S bit = 1 and P bit = 1) and when the 1684 LSP Protection Type value is set to 0x02 (Re-routing without 1685 Extra-Traffic) in the PROTECTION object (see Section 14.). 1687 - PRROs SHOULD be present in the Path message for the pre- 1688 provisioning of the secondary protecting LSP to enable recovery 1689 resource sharing between one or more secondary protecting LSPs 1690 (see Section 15.4). 1692 - PPROs MUST NOT be used in any other conditions. In particular, if 1693 a PPRO is received when the S bit is set to 0 in the PROTECTION 1694 object, the receiving node MUST return a PathErr message with the 1695 new error code/sub-code "Routing Problem/PRIMARY PATH_ROUTE object 1696 not applicable". 1698 - Crossed exchanges of PPROs over primary LSPs are forbidden (i.e. 1699 their usage is restricted to a single set of protected LSPs). 1701 J.P.Lang et al. Expires February 2007 32 1702 - The PPRO's content MUST NOT include subobjects coming from other 1703 PPROs. In particular, received PPROs MUST NOT be re-used to 1704 establish other working or protecting LSPs. 1706 15.4 Processing 1708 The PPRO enables sharing recovery resources between a given 1709 secondary protecting LSP and one or more secondary protecting LSPs 1710 if their corresponding primary working LSPs have mutually 1711 (link/node/SRLG) disjoint paths. Consider a node N through which n 1712 secondary protecting LSPs (say P[1],...,P[n]) have already been 1713 established and protecting n primary working LSPs (say 1714 P'[1],...,P'[n]). Suppose also that these n secondary working LSPs 1715 share a given outgoing link resource (say r). 1717 Now, suppose that node N receives a Path message for an additional 1718 secondary protecting LSP (say Q, protecting Q'). The PPRO carried by 1719 this Path messages is processed as follows: 1721 - N checks whether the primary working LSPs P'[1],...,P'[n] 1722 associated with the LSPs P[1],...,P[n] respectively have any link, 1723 node and SLRG in common with the primary working Q' (associated 1724 with Q) by comparing the stored PPRO subobjects associated with 1725 P'[1],...,P'[n] with the PPRO subobjects associated with Q' 1726 received in the Path message. 1728 - If this is the case, N SHOULD NOT attempt to share the outgoing 1729 link resource r between P[1],...,P[n] and Q. However, upon local 1730 policy decision, N MAY allocate another available (shared) link 1731 other than r for use by Q. If this is not the case (upon the local 1732 policy decision that no other link is allowed to be allocated for 1733 Q) or if no other link is available for Q, N SHOULD return a 1734 PathErr message with the new error code/sub-code "Admission 1735 Control Failure/LSP Admission Failure". 1737 - Otherwise (if P'[1],...,P'[n] and Q' are fully disjoint), the link 1738 r selected by N for the LSP Q MAY be exactly the same as the one 1739 selected for the LSPs P[1],...,P[n]. This, after verifying (also 1740 from its local policy) that the selected link r can be shared 1741 between these LSPs. If this is not the case (for instance, the 1742 sharing ratio has reached its maximum for that link) and upon 1743 local policy decision no other link is allowed to be allocated for 1744 Q, N SHOULD return a PathErr message with the error code/sub-code 1745 "Admission Control Failure/Requested Bandwidth Unavailable" (see 1746 [RFC2205]). Otherwise (if no other link is available), N SHOULD 1747 return a PathErr message with the new error code/sub-code 1748 "Admission Control Failure/LSP Admission Failure". 1750 Note that the process, through which m out of the n (m =< n) 1751 secondary protecting LSPs PPROs may be selected on a local basis to 1753 J.P.Lang et al. Expires February 2007 33 1754 perform the above comparison and subsequent link selection, is out 1755 of scope of this document. 1757 16. ASSOCIATION Object 1759 The ASSOCIATION object is used to associate LSPs with each other. In 1760 the context of end-to-end LSP recovery, the association MUST only 1761 identify LSPs that support the same Tunnel ID as well as the same 1762 tunnel sender address and tunnel end point address. The Association 1763 Type, Association Source and Association ID fields of the object 1764 together uniquely identify an association. The object uses an object 1765 class number of the form 11bbbbbb to ensure compatibility with non- 1766 supporting nodes. 1768 The ASSOCIATION object is used to associate LSPs with each other. 1770 16.1 Format 1772 The IPv4 ASSOCIATION object (Class-Num of form 11bbbbbb with value = 1773 198, C-Type = 1, suggested values, TBA by IANA) has the format: 1775 0 1 2 3 1776 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 1777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1778 | Length | Class-Num(TBD)| C-Type (1) | 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 | Association Type | Association ID | 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 | IPv4 Association Source | 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1785 The IPv6 ASSOCIATION object (Class-Num of form 11bbbbbb with value = 1786 198, C-Type = 2, suggested values, TBA by IANA) has the format: 1788 0 1 2 3 1789 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 1790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1791 | Length | Class-Num(TBD)| C-Type (2) | 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 | Association Type | Association ID | 1794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1795 | | 1796 | IPv6 Association Source | 1797 | | 1798 | | 1799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 Association Type: 16 bits 1803 Indicates the type of association being identified. Note that 1804 this value is considered when determining association. The 1805 following are values defined in this document. 1807 J.P.Lang et al. Expires February 2007 34 1808 Value Type 1809 ----- ---- 1810 0 Reserved 1811 1 Recovery (R) 1813 Association ID: 16 bits 1815 A value assigned by the LSP head-end. When combined with the 1816 Association Type and Association Source, this value uniquely 1817 identifies an association. 1819 Association Source: 4 or 16 bytes 1821 An IPv4 or IPv6 address, respectively, that is associated to 1822 the node that originated the association. 1824 16.2. Processing 1826 In the end-to-end LSP recovery context, the ASSOCIATION object is 1827 used to associate a recovery LSP with the LSP(s) it is protecting or 1828 a protected LSP(s) with its recovery LSP. The object is carried in 1829 Path messages. More than one object MAY be carried in a single Path 1830 message. 1832 Transit nodes MUST transmit, without modification, any received 1833 ASSOCIATION object in the corresponding outgoing Path message. 1835 An ASSOCIATION object with an Association Type set to the value 1836 "Recovery" is used to identify an LSP Recovery related association. 1837 Any node associating a recovery LSP MUST insert an ASSOCIATION 1838 object with the following setting: 1839 - the Association Type MUST be set to the value "Recovery" in the 1840 Path message of the recovery LSP 1841 - the (IPv4/IPv6) Association Source MUST be set to the tunnel 1842 sender address of the LSP being protected 1843 - the Association ID MUST be set to the LSP ID of the LSP being 1844 protected by this LSP or the LSP protecting this LSP. If unknown, 1845 this value is set to its own signaled LSP_ID value (default). 1846 Also, the value of the Association ID MAY change during the 1847 lifetime of the LSP. 1849 Terminating nodes use received ASSOCIATION object(s) with the 1850 Association Type set to the value "Recovery" to associate a recovery 1851 LSP with its matching working LSP. This information is used to bind 1852 the appropriate working and recovery LSPs together. Such nodes MUST 1853 ensure that the received Path messages including ASSOCIATION 1854 object(s) are processed with the appropriate PROTECTION object 1855 settings, if present (see Section 14 for PROTECTION object 1856 processing). Otherwise, this node MUST return a PathErr message with 1857 the new error code/sub-code "LSP Admission Failure/Bad Association 1858 Type". Similarly, terminating nodes receiving a Path message with a 1860 J.P.Lang et al. Expires February 2007 35 1861 PROTECTION object requiring association between working and recovery 1862 LSPs MUST include an ASSOCIATION object. Otherwise, such nodes MUST 1863 return a PathErr message with the new error code/sub-code "Routing 1864 Problem/PROTECTION object not Applicable". 1866 17. Updated RSVP Message Formats 1868 This section presents the RSVP message related formats as modified 1869 by this document. Unmodified RSVP message formats are not listed. 1871 The format of a Path message is as follows: 1873 ::= [ ] 1874 [ [ | ] ... ] 1875 [ ] 1876 1877 1878 [ ] 1879 1880 [ ] 1881 [ ... ] 1882 [ ] 1883 [ ... ] 1884 [ ] 1885 [ ... ] 1886 [ ... ] 1887 [ ... ] 1888 1890 The format of the for unidirectional and 1891 bidirectional LSPs is not modified by the present document. 1893 The format of a Resv message is as follows: 1895 ::= [ ] 1896 [ [ | ] ... ] 1897 [ ] 1898 1899 1900 [ ] [ ] 1901 [ ] 1902 [ ] 1903 [ ] 1904 [ ... ] 1905