idnits 2.17.1 draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 35 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 32 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 document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2004) is 7377 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: 'RFC2119' is mentioned on line 92, but not defined == Missing Reference: 'CRANK' is mentioned on line 183, but not defined == Missing Reference: 'RFC2205' is mentioned on line 196, but not defined == Missing Reference: 'RFC3209' is mentioned on line 197, but not defined == Missing Reference: 'RFC3473' is mentioned on line 197, but not defined == Missing Reference: 'A' is mentioned on line 890, but not defined == Missing Reference: 'B' is mentioned on line 888, but not defined == Missing Reference: 'C' is mentioned on line 888, but not defined == Missing Reference: 'D' is mentioned on line 890, but not defined == Missing Reference: 'E' is mentioned on line 893, but not defined == Missing Reference: 'F' is mentioned on line 893, but not defined == Missing Reference: 'G' is mentioned on line 893, but not defined == Missing Reference: 'H' is mentioned on line 893, but not defined == Missing Reference: 'I' is mentioned on line 888, but not defined == Missing Reference: 'J' is mentioned on line 888, but not defined == Missing Reference: 'K' is mentioned on line 893, but not defined == Missing Reference: 'RFC 3209' is mentioned on line 1327, but not defined -- Looks like a reference, but probably isn't: '1' on line 1376 == Missing Reference: 'RFC2026' is mentioned on line 1561, but not defined == Unused Reference: 'GMPLS-RTG' is defined on line 1602, but no explicit reference was found in the text == Unused Reference: 'LMP' is defined on line 1606, but no explicit reference was found in the text == Unused Reference: 'RFC-2026' is defined on line 1610, but no explicit reference was found in the text == Unused Reference: 'RFC-2119' is defined on line 1613, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-lsp-fastreroute-03 == Outdated reference: A later version (-04) exists of draft-ietf-ccamp-gmpls-recovery-functional-01 == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-gmpls-recovery-terminology-03 ** Downref: Normative reference to an Informational draft: draft-ietf-ccamp-gmpls-recovery-terminology (ref. 'TERM') == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-rsvp-te-exclude-route-01 Summary: 4 errors (**), 0 flaws (~~), 29 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group CCAMP GMPLS P&R Design Team 3 Internet Draft 4 Expiration Date: August 2004 J.P. Lang (Editor) 5 Y. Rekhter (Editor) 6 D. Papadimitriou (Editor) 8 February 2004 10 RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery 12 draft-lang-ccamp-gmpls-recovery-e2e-signaling-03.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 For potential updates to the above required-text see: 35 http://www.ietf.org/ietf/1id-guidelines.txt 37 Abstract 39 This document describes protocol specific procedures for GMPLS 40 (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource 41 ReserVation Protocol - Traffic Engineering) signaling extensions to 42 support end-to-end LSP recovery (protection and restoration). A 43 generic functional description of GMPLS recovery can be found in a 44 companion document. 46 J.P.Lang et al. - Internet Draft � Expires August 2004 1 47 1. Contributors 49 This document is the result of the CCAMP Working Group Protection 50 and Restoration design team joint effort. The following are the 51 authors that contributed to the present memo: 53 Deborah Brungard (AT&T) 54 Rm. D1-3C22 - 200 S. Laurel Ave. 55 Middletown, NJ 07748, USA 56 E-mail: dbrungard@att.com 58 Sudheer Dharanikota (Consult) 59 E-mail: sudheer@ieee.org 61 Jonathan Lang (Rincon Networks) 62 E-mail: jplang@ieee.org 64 Guangzhi Li (AT&T) 65 180 Park Avenue, 66 Florham Park, NJ 07932, USA 67 E-mail: gli@research.att.com 69 Eric Mannie (Consult) 70 Email: eric_mannie@hotmail.com 72 Dimitri Papadimitriou (Alcatel) 73 Fr. Wellesplein, 1 74 B-2018, Antwerpen, Belgium 75 Email: dimitri.papadimitriou@alcatel.be 77 Bala Rajagopalan (Tellium) 78 2 Crescent Place - P.O. Box 901 79 Oceanport, NJ 07757-0901, USA 80 E-mail: braja@tellium.com 82 Yakov Rekhter (Juniper) 83 1194 N. Mathilda Avenue 84 Sunnyvale, CA 94089, USA 85 E-mail: yakov@juniper.net 87 2. Conventions used in this document: 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 In addition, the reader is assumed to be familiar with the 94 terminology used in [GMPLS-ARCH], [RFC-3471], [RFC-3473] and 95 referenced as well as [TERM] and [FUNCT]. 97 J.P.Lang et al. - Internet Draft � Expires August 2004 2 98 3. Introduction 100 Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to 101 include support for Layer-2 (L2SC), Time-Division Multiplex (TDM), 102 Lambda Switch Capable (LSC), and Fiber Switch Capable (FSC) 103 interfaces. GMPLS-based recovery uses control plane mechanisms 104 (i.e., signaling, routing, link management mechanisms) to support 105 data plane fault recovery. Note that the analogous (data plane) 106 fault detection mechanisms are required to be present in support of 107 the control plane mechanisms. In this document, the term "recovery" 108 is generically used to denote both protection and restoration; the 109 specific terms "protection" and "restoration" are only used when 110 differentiation is required. The subtle distinction between 111 protection and restoration is made based on the resource allocation 112 done during the recovery phase (see [TERM]). 114 A functional description of GMPLS-based recovery is provided in 115 [FUNCT] and should be considered as a companion document to this 116 memo which describes the protocol specific procedures for GMPLS 117 RSVP-TE (Resource ReSerVation Protocol - Traffic Engineering) 118 signaling (see [RFC-3473]) to support end-to-end recovery of an 119 entire LSP from the head-end to the tail-end. The present memo 120 addresses four types of end-to-end LSP recovery: 1+1 unidirectional/ 121 1+1 bi-directional protection, LSP protection with extra-traffic 122 (including 1:N protection with extra-traffic), pre-planned LSP re- 123 routing without extra-traffic (including shared mesh), and full LSP 124 re-routing. 126 The simplest notion of end-to-end LSP protection is 1+1 127 unidirectional protection. Using this type of protection, a 128 protecting LSP is signaled over a dedicated resource-disjoint 129 alternate path to protect an associated working LSP. Normal traffic 130 is simultaneously sent on both LSPs and a selector is used at the 131 egress node to receive traffic from one of the LSPs. If a failure 132 occurs along one of the LSPs, the egress node selects the traffic 133 from the valid LSP. No coordination is required between the end 134 nodes when a failure/switchover occurs. 136 In 1+1 bi-directional protection, a protecting LSP is signaled over 137 a dedicated resource-disjoint alternate path to protect the working 138 LSP. Normal traffic is simultaneously sent on both LSPs (in both 139 directions) and a selector is used at both ingress/egress nodes to 140 receive traffic from the same LSP. This requires co-ordination 141 between the end-nodes when switching to the protecting LSP. 143 In 1:N (N =< 1) protection with extra-traffic, the protecting LSP is 144 a fully provisioned and resource-disjoint LSP from the N working 145 LSPs, that allows for carrying extra-traffic. The N working LSPs MAY 146 be mutually resource-disjoint. Coordination between end-nodes is 147 required when switching from one of the working to the protecting 148 LSP. Note that M:N protection is out of scope of this document 149 (though mechanisms it defines may be extended to cover it). 151 J.P.Lang et al. - Internet Draft � Expires August 2004 3 152 Pre-planned LSP re-routing (or restoration) relies on the 153 establishment between the same pair of end-nodes of a working LSP 154 and a protecting LSP that is link/node/SRLG disjoint from the 155 working one. Here, the recovery resources for the protecting LSP are 156 pre-reserved and explicit action is required to activate (i.e. 157 commit resource allocation at the data plane) a specific protecting 158 LSP instantiated during the (pre-)provisioning phase. Since the 159 protecting LSP is not "active" (i.e. fully instantiated), it can not 160 carry any extra-traffic (note that this does not mean that the 161 corresponding resources can not used by other LSPs). Therefore, this 162 mechanism protects against working LSP(s) failure(s) but requires 163 activation of the protecting LSP after working LSP failure 164 occurrence. This requires restoration signaling along the protecting 165 path. "Shared-mesh" restoration can be seen as a particular case of 166 pre-planned LSP re-routing that reduces the recovery resource 167 requirements by allowing multiple protecting LSPs to share common 168 link and node resources. The recovery resources are pre-reserved and 169 explicit action is required to activate (i.e. commit resource 170 allocation at the data plane) a specific protecting LSP instantiated 171 during the (pre-)provisioning phase. This procedure requires 172 restoration signaling along the protecting path. Note that in both 173 cases, any lower priority LSP that would use the pre-reserved 174 resources for the protecting LSP(s) MUST be preempted during the 175 activation of the protecting LSP. 177 Full LSP re-routing (or restoration) switches normal traffic to an 178 alternate LSP that is fully established only after working LSP 179 failure occurs. The new alternate route is selected at the LSP head- 180 end node, it may reuse resources of the failed LSP at intermediate 181 nodes and may include additional intermediate nodes and/or links. 183 Note that crankback signaling (see [CRANK]) and LSP segment recovery 184 are further detailed in dedicated companion documents. Also, there 185 is no impact to Fast Reroute [FRR] introduced by end-to-end 186 GMPLS-based recovery i.e. it is possible to use either method 187 defined in FRR with end-to-end GMPLS-based recovery. The objects 188 used and/or newly introduced by end-to-end recovery will be ignored 189 by [FRR] conformant implementations, and FRR can operate on a per 190 LSP basis as defined in [FRR]. 192 4. Overview 194 4.1 LSP Identification 196 This section reviews terms previously defined in [RFC2205], 197 [RFC3209], and [RFC3473]. LSP tunnels are identified by a 198 combination of the SESSION and SENDER_TEMPLATE objects (see also 199 [RFC-3209]). The relevant fields are as follows: 201 IPv4 (or IPv6) tunnel end point address 203 J.P.Lang et al. - Internet Draft � Expires August 2004 4 204 IPv4 (or IPv6) address of the egress node for the tunnel. 206 Tunnel ID 208 A 16-bit identifier used in the SESSION that remains constant 209 over the life of the tunnel. 211 Extended Tunnel ID 213 A 32-bit (or 16-byte) identifier used in the SESSION that 214 remains constant over the life of the tunnel. Normally set to 215 all zeros. Ingress nodes that wish to narrow the scope of a 216 SESSION to the ingress-egress pair MAY place their IPv4 (or 217 IPv6) address here as a globally unique identifier. 219 IPv4 (or IPv6) tunnel sender address 221 IPv4 (or IPv6) address for a sender node. 223 LSP ID 225 A 16-bit identifier used in the SENDER_TEMPLATE and FILTER_SPEC 226 that can be changed to allow a sender to share resources with 227 itself. 229 The first three fields are carried in the SESSION object (Path and 230 Resv message) and constitute the basic identification of the LSP 231 tunnel. 233 The last two fields are carried in the SENDER_TEMPLATE (Path 234 message) and FILTER_SPEC objects (Resv message). The LSP ID is used 235 to differentiate LSP tunnels that belong to the same session. 237 4.2 Recovery Attributes 239 The recovery attributes includes all the parameters that determine 240 the status of a LSP within the recovery scheme to which it is 241 associated. These attributes are part of the PROTECTION object 242 introduced in Section 14. 244 4.2.1 LSP Status 246 The following bits are used in determining resource allocation and 247 status of the LSP within the group of LSPs forming the protected 248 entity: 250 - S (Secondary) bit: enables distinction between primary and 251 secondary LSPs. A primary LSP is a fully established LSP for 252 which the resource allocation has been committed at the data plane 253 (i.e. full cross-connection has been performed). Both working and 254 protecting LSPs can be primary LSPs. A secondary LSP is an LSP 255 that has been provisioned in the control plane only and for which 257 J.P.Lang et al. - Internet Draft � Expires August 2004 5 258 resource selection MAY have been done but for which the resource 259 allocation has not been committed at the data plane (for instance, 260 no cross-connection has been performed). Therefore, a secondary 261 LSP is not immediately available to carry any traffic (requiring 262 thus additional signaling to be available). A secondary LSP can 263 only be a protecting LSP. The (data plane) resources allocated for 264 a secondary LSP MAY be used by other LSPs until the primary LSP 265 fails over to the secondary LSP. 267 - P (Protecting) bit: enables distinction between working and 268 protecting LSPs. A working LSP must be a primary LSP whilst a 269 protecting LSP can be either a primary or a secondary LSP. When 270 protecting LSP(s) are associated with working LSP(s), one also 271 refers to the latter as protected LSPs. 273 Note: The combination "secondary working" is not valid (only 274 protecting LSPs can be secondary LSPs). Working LSPs are always 275 primary LSPs (i.e. fully established) whilst primary LSPs can be 276 either working or protecting LSPs. 278 - O (Operational) bit: this bit is set when a protecting LSP is 279 carrying the normal traffic after protection switching (i.e. 280 applies only in case of dedicated LSP protection or LSP protection 281 with extra-traffic, see Section 4.2.2). 283 In this document, the PROTECTION object uses as a basis the 284 PROTECTION object defined in [RFC-3471] and [RFC-3473] and defines 285 additional fields within it. The fields defined in [RFC-3471] and 286 [RFC-3473] are unchanged by this memo. 288 4.2.2 LSP Recovery 290 The following classification is used to distinguish the LSP 291 Protection Type with which LSPs can be associated at end-nodes (a 292 distinct value is associated with each Protection Type in the 293 PROTECTION object, see Section 14): 295 - Full LSP Re-routing: set if a primary working LSP is dynamically 296 recoverable using (non pre-planned) head-end re-routing. 298 - Pre-planned LSP Re-routing without Extra-traffic: set if a 299 protecting LSP is a secondary LSP that allows sharing of the 300 pre-reserved recovery resources between one or more than one 301 pair. When the secondary LSPs resources are not 302 pre-reserved for a single pair, this type is 303 referred to as "shared mesh" recovery. 305 - LSP Protection with Extra-traffic: set if a protecting LSP is a 306 dedicated primary LSP that allows for extra-traffic transport 307 and thus precludes any sharing of the recovery resources between 308 more than one pair. This type includes 1:N LSP 309 protection with extra-traffic. 311 J.P.Lang et al. - Internet Draft � Expires August 2004 6 312 - Dedicated LSP Protection: set if a protecting LSP does not allow 313 sharing of the recovery resources nor the transport of extra- 314 traffic (implying in the present context, duplication of the 315 signal over both working and protecting LSPs as in 1+1 dedicated 316 protection). Note also that this document makes a distinction 317 between 1+1 unidirectional and bi-directional dedicated LSP 318 protection. 320 For LSP protection, in particular when the data plane provides 321 automated protection switching capability (see for instance ITU-T 322 G.841 Recommendation), a Notification (N) bit is defined in the 323 PROTECTION object. It allows for distinction between protection 324 switching signaling via the control plane or via the data plane. 326 Note: this document assumes that Protection Type values have end-to- 327 end significance and that the same value is sent over the protected 328 and the protecting path. In this context, shared-mesh for instance, 329 appears from the end-nodes perspective as being simply an LSP re- 330 routing without extra-traffic services. The net result of this is 331 that a single bit (the S bit alone) does not allow determining 332 whether resource allocation should be performed and this *with 333 respect to* the status of the LSP within the protected entity. The 334 introduction of the P bit solves this problem unambiguously. These 335 bits MUST be processed on a hop-by-hop basis (independently of the 336 LSP Protection Type context). This allows for an easier 337 implementation of reversion signaling (see Section 12) but also 338 facilitates the transparent delivery of protected services since any 339 intermediate node is not required to know the semantic associated 340 with the incoming LSP Protection Type value. 342 4.3 LSP Association 344 The ASSOCIATION object, introduced in Section 16, is used to 345 associate the working and protecting LSPs. 347 When used for the working LSP signaling, the Association ID of the 348 ASSOCIATION object (see Section 16) identifies the protecting LSP. 349 When used for the protecting LSP signaling, this field identifies 350 the LSP protected by the protecting LSP. 352 5. 1+1 Unidirectional Protection 354 One of the simplest notions of end-to-end LSP protection is 1+1 355 unidirectional protection. 357 Consider the following network topology: 359 A---B---C---D 360 \ / 361 E---F---G 363 J.P.Lang et al. - Internet Draft � Expires August 2004 7 364 The paths [A,B,C,D] and [A,E,F,G,D] are node and link disjoint, 365 ignoring the ingress/egress nodes A and D. A 1+1 protected path is 366 established from A to D over [A,B,C,D] and [A,E,F,G,D] and traffic 367 is transmitted simultaneously over both component paths (i.e. LSPs). 369 When a failure occurs (say at node B) and is detected at end-node D, 370 the receiver at D selects the normal traffic from the other LSP. 371 From this perspective, 1+1 unidirectional protection can be seen as 372 an uncoordinated protection switching mechanism acting independently 373 at both end-points. Note also that both LSPs are fully instantiated 374 (and thus activated) so that no resource sharing can be done along 375 the protecting LSP (nor can any extra-traffic be transported). It is 376 also RECOMMENDED to set the N bit since no protection switching 377 signaling is assumed in this case. Also, for the protected LSP under 378 failure condition, the Path_State_Removed Flag of the ERROR_SPEC 379 object (see [RFC-3473]) SHOULD NOT be set upon PathErr message 380 generation. 382 Note: one should assume that both paths are SRLG disjoint otherwise, 383 a failure would impact both working and protecting LSPs. 385 5.1. Identifiers 387 Since both LSPs belong to the same session, the SESSION object MUST 388 be the same for both LSPs. The LSP ID, however, MUST be different to 389 distinguish between the two LSPs. 391 A new PROTECTION object is included in the Path message. This object 392 carries the desired end-to-end LSP Protection Type (in this case, 393 "1+1 Unidirectional") as well as the LSP ID of the associated LSP 394 referred to as the Association ID. This LSP Protection Type value is 395 applicable to both uni- and bi-directional LSPs. 397 It is also desirable to allow distinguishing the working LSP (from 398 which the signal is taken) from the protecting LSP. This is achieved 399 for the working LSP by setting in the PROTECTION object the S bit to 400 0, the P bit to 0, and the Association ID to the protecting LSP_ID. 401 The protecting LSP is signaled by setting in this object the S bit 402 to 0, the P bit to 1, and the Association ID to the associated 403 protected LSP_ID. 405 After protection switching completes (step 2), and after reception 406 of the PathErr message, to keep track of the LSP from which the 407 signal is taken, the protecting LSP SHOULD be signaled with the O- 408 bit set. The formerly working LSP MAY be signaled with the A bit set 409 in the ADMIN_STATUS object (see [RFC-3473]). This process assumes 410 the tail-end node has notified the head-end node that traffic 411 selection switchover has occurred. 413 J.P.Lang et al. - Internet Draft � Expires August 2004 8 414 6. 1+1 Bi-directional Protection 416 1+1 bi-directional protection is another scheme that provides end- 417 to-end LSP protection. 419 Consider the following network topology: 421 A---B---C---D 422 \ / 423 E---F---G 425 The LSPs [A,B,C,D] and [A,E,F,G,D] are node and link disjoint, 426 ignoring the ingress/egress nodes A and D. A bi-directional LSP is 427 established from A to D over each path and traffic is transmitted 428 simultaneously over both LSPs. In this scheme, both end-points must 429 receive traffic over the same LSP. When a failure is detected by one 430 or both end-points of the LSP, both end-points must select traffic 431 from the other LSP. This action must be coordinated between node A 432 and D. From this perspective, 1+1 bi-directional protection can be 433 seen as a coordinated protection switching mechanism between both 434 end-points. Note also that both LSPs are fully instantiated (and 435 thus activated) so that no resource sharing can be done along the 436 protection path (nor can any extra-traffic be transported). 438 Note: one should assume that both paths are SRLG disjoint otherwise 439 a failure would impact both working and protecting LSPs. 441 6.1. Identifiers 443 Since both LSPs belong to the same session, the SESSION object MUST 444 be the same in both LSPs. The LSP ID, however, MUST be different to 445 distinguish between the two LSPs. 447 A new PROTECTION object (see Section 14) is included in the Path 448 message. This object carries the desired end-to-end LSP Protection 449 Type (in this case, "1+1 Bi-directional") as well as the LSP ID of 450 the associated LSP referred to as Association ID. This LSP 451 Protection Type value is only applicable to bi-directional LSPs. 453 It is also desirable to allow distinguishing the working (LSP from 454 which the signal is taken) from the protecting LSP. This is achieved 455 for the working LSP by setting in the PROTECTION object the S bit to 456 0, the P bit to 0, and the Association ID to the protecting LSP_ID. 457 The protecting LSP is signaled by setting in this object the S bit 458 to 0, the P bit to 1 and the Association ID to the associated 459 protected LSP_ID. 461 6.2. End-to-End Switchover Request/Response 463 To co-ordinate the switchover between end-points, an end-to-end 464 switchover request is needed since a failure affecting one the LSPs 466 J.P.Lang et al. - Internet Draft � Expires August 2004 9 467 results in both end-points switching to the other LSP (resulting in 468 receiving traffic from the other LSP) in their respective 469 directions. This is done using the Notify message with a new Error 470 Code indicating "Working LSP Failure (Switchover Request)". The 471 Notify Ack message MUST be sent to confirm the reception of the 472 Notify message (see [RFC-3473], Section 4.3). 474 The procedure is as follows: 476 1. If an end-node (A or D) detects the failure of the working 477 LSP (or a degradation of signal quality over the working 478 LSP) or receives a Notify message including its SESSION 479 object within the (see 480 [RFC-3473]), it MUST begin receiving on the protecting LSP 481 and send a Notify message reliably to the other end-node (D 482 or A, respectively). This message MAY indicate the identity 483 of the failed working link and other relevant information 484 using the IF_ID ERROR_SPEC (see [RFC-3473]). 486 Note: in this case, the IF_ID ERROR_SPEC replaces the 487 ERROR_SPEC in the Notify message, otherwise the 488 corresponding (data plane) information SHOULD be received 489 in the PathErr/ResvErr message. 491 2. Upon receipt of the switchover message, the end-node 492 (D or A, respectively) MUST begin receiving from the 493 protection LSP and send a (Notify) Ack message to the other 494 end-node (A or D, respectively) using reliable message 495 delivery (see [RFC-2961]). 497 Since the intermediate nodes (B,C,E,F and G) are assumed to be GMPLS 498 signaling capable, each node adjacent to the failure MAY generate a 499 Notify message directed either to the LSP head-end (upstream 500 direction) or the LSP tail-end (downstream direction) or even both. 501 Therefore, it is expected that these LSP terminating nodes (that MAY 502 also detect the failure of the LSP from the data plane) provide 503 either the right correlation mechanism to avoid repetition of the 504 above procedure or just discard subsequent Notify messages 505 corresponding to the same Session. In addition, for the working LSP 506 under failure, the Path_State_Remove Flag of the ERROR_SPEC object 507 (see [RFC-3473]) SHOULD NOT be set upon PathErr message generation. 509 After protection switching completes (step 2), and after reception 510 of the PathErr message, to keep track of the LSP from which the 511 signal is taken, the protecting LSP SHOULD be signaled with the O- 512 bit set. The formerly working LSP MAY be signaled with the A bit set 513 in the ADMIN_STATUS object (see [RFC-3473]). 515 Note: when the N bit is set, the end-to-end switchover request/ 516 response exchange described above only provides control plane 517 coordination (no actions are triggered at the data plane level). 519 J.P.Lang et al. - Internet Draft � Expires August 2004 10 520 7. 1:1 Protection with Extra-Traffic 522 The most common case of end-to-end 1:N protection is to establish, 523 between the same end-points, an end-to-end working LSP (thus, N = 1) 524 and a dedicated end-to-end protecting LSP that are mutually link/ 525 node/SRLG disjoint. This protects against working LSP failure(s). 527 The protecting LSP is used for fast switchover when the working LSP 528 fails. GMPLS signaling allows for the pre-provisioning of protecting 529 LSPs by indicating in the Path message (in the PROTECTION object, 530 see Section 14) that the LSPs are of type protecting. Here, working 531 and protecting LSPs are signaled as primary LSPs; both are fully 532 instantiated during the provisioning phase. 534 Although the resources for the protecting LSP are pre-allocated, 535 preemptable traffic may be carried end-to-end using this LSP (i.e. 536 the protecting LSP is capable of carrying extra-traffic) with the 537 caveat that this traffic will be preempted if the working LSP fails. 538 Also, if extra-traffic is carried over the protecting LSP, the 539 corresponding end-nodes may need to be notified of the failure in 540 order to complete the switchover. 542 The setup of the working LSP SHOULD indicate that the LSP head-end 543 and tail-end node wish to receive Notify messages using the NOTIFY 544 REQUEST object. The node upstream to the failure (upstream in terms 545 of the direction an RSVP Path message traverses) SHOULD send an RSVP 546 Notify message to the LSP head-end node, and the node downstream to 547 the failure SHOULD send an RSVP Notify message to the LSP tail-end 548 node. Upon receipt of the Notify messages, both the end-nodes MUST 549 switch the (normal) traffic from the working LSP to the pre- 550 configured protecting LSP (see Section 7.2). Moreover some 551 coordination is required if extra-traffic is carried over the end- 552 to-end protecting LSP. Note that if the working and the protecting 553 LSP are established between the same end-nodes no further 554 notification is required to indicate that the working LSPs are no 555 longer protected. 557 Consider the following topology: 559 A---B---C---D 560 \ / 561 E---F---G 563 The working LSP [A,B,C,D] could be protected by the protecting LSP 564 [A,E,F,G,D]. Both LSPs are fully instantiated (resources are 565 allocated for both working and protecting LSPs) and no resource 566 sharing can be done along the protection path since the primary 567 protecting LSP can carry extra-traffic. 569 Note: one should assume that both paths are SRLG disjoint otherwise 570 a failure would impact both working and protecting LSPs. 572 J.P.Lang et al. - Internet Draft � Expires August 2004 11 573 7.1 Identifiers 575 Since both LSPs belong to the same session, the SESSION object MUST 576 be the same in both LSPs. The LSP ID, however, MUST be different to 577 distinguish between the protected LSP carrying working traffic and 578 the protecting LSP that can carry extra-traffic. 580 A new PROTECTION object (see Section 14) is included in the Path 581 message used to setup the two LSPs. This object carries the desired 582 end-to-end LSP Protection Type (in this case, "1:N Protection with 583 Extra-Traffic"). This LSP Protection Type value is applicable to 584 both uni- and bi-directional LSPs. 586 The working LSP is signaled by setting in this object the S bit to 587 0, the P bit to 0 and the Association ID to the protecting LSP_ID. 588 The protecting LSP is signaled by setting in this object the S bit 589 to 0, the P bit to 1, and the Association ID to the associated 590 protected LSP_ID. 592 7.2 End-to-End Switchover Request/Response 594 To co-ordinate the switchover between end-points, an end-to-end 595 switchover request is needed such that the affected LSP(s) are moved 596 to the protecting LSP. Protection switching from the working to the 597 protecting LSP (implying preemption of extra-traffic carried over 598 the protecting LSP) must be initiated by one of the end-nodes (A or 599 D). 601 This operation may be done using a Notify message exchange with a 602 new Error Code indicating "(Working) LSP Failure (Switchover 603 Request)". The Notify Ack message MUST be sent to confirm the 604 reception of the Notify message. 606 The procedure is as follows: 608 1. If an end-node (A or D) detects the failure of the working 609 LSP (or a degradation of signal quality over the working 610 LSP) or receives a Notify message including its SESSION 611 object within the (see 612 [RFC-3473]), it disconnects the extra-traffic from the 613 protecting LSP and send a Notify message reliably to the 614 other end-node (D or A, respectively). This message MAY 615 indicate the identity of the failed working link and other 616 relevant information using the IF_ID ERROR_SPEC (see [RFC- 617 3473]). 619 Note: in this case, the IF_ID ERROR_SPEC replaces the 620 ERROR_SPEC in the Notify message, otherwise the corresponding 621 information SHOULD be received in the PathErr/ResvErr message 623 2. Upon receipt of the switchover (i.e. end-to-end Notify) 624 message, the end-node (D or A, respectively) MUST disconnect 626 J.P.Lang et al. - Internet Draft � Expires August 2004 12 627 the extra-traffic from the protecting LSP and begin 628 sending/receiving normal traffic out/from the protecting LSP 629 and send a (Notify) Ack message to the other end-node (A or 630 D, respectively) using reliable message delivery (see [RFC 631 2961]). Also, the Notify message generated by the end-node 632 is distinguishable from the one generated by an intermediate 633 node, there is no possibility of connecting the extra 634 traffic to the working LSP due to the receipt of Notify 635 message from an intermediate node. 637 3. Upon receipt of the switchover (Notify) Ack message, the 638 end-node (A or D, respectively) MUST begin receiving normal 639 traffic from the protecting LSP. 641 Note 1: a 2-phase protection switching signaling is used in the 642 present context, a 3-phase signaling (see [FUNCT]) that would imply 643 a notification message and a switchover request/response messages, 644 is not considered here. Also, when the protecting LSPs do not carry 645 extra-traffic, a 1-Phase protection switching signaling as defined 646 in Section 6.2 MAY be used instead of the 2-Phase described here 647 above. 649 Note 2: when the N bit is set, the above end-to-end switchover 650 request/response exchange does only provide control plane 651 coordination (no actions are triggered at the data plane level). 653 After protection switching completes (step 3), and after reception 654 of the PathErr message, to keep track of the LSP from which the 655 normal traffic is taken, the protecting LSP SHOULD be signaled with 656 the O-bit set. In addition, the formerly working LSP MAY be signaled 657 with the A bit set in the ADMIN_STATUS object (see [RFC-3473]). 659 7.3 1:N (N > 1) Protection with Extra-Traffic 661 1:N (N > 1) protection with extra-traffic assumes that the fully 662 provisioned protecting LSP is resource-disjoint LSP from the N 663 working LSPs. This protecting LSP allows thus for carrying extra- 664 traffic. In addition, the N working LSPs (considered as identical in 665 terms of traffic parameters) MAY be mutually resource-disjoint. 666 Coordination between end-nodes is required when switching from one 667 of the working to the protecting LSP. 669 Each working LSP is signaled with both S bit and P bit set to 0. The 670 LSP Flag is set to 0x04 (during LSP setup). Each Association ID 671 points to the protecting LSP ID. The protecting LSP (carrying extra- 672 traffic) is signaled with S bit set to 0 and P bits set to 1. The 673 LSP Flag is set to 0x04 (during LSP setup). The Association ID is 674 not significant (multiple protected LSPs) and MUST be set by default 675 to the LSP ID of the protected LSP corresponding to N = 1. 677 Any signaling procedure applicable to 1:1 protection with extra- 678 traffic equally applies to 1:N protection with extra-traffic. 680 J.P.Lang et al. - Internet Draft � Expires August 2004 13 681 8. Re-routing without Extra-Traffic 683 End-to-end (pre-planned) re-routing without extra-traffic relies on 684 the establishment between the same pair of end-nodes of a working 685 LSP and a protecting LSP that is link/node/SRLG disjoint from the 686 working one. However, in this case the protecting LSP is not fully 687 instantiated, thus, it can not carry any extra-traffic (note that 688 this does not mean that the corresponding resources can not used by 689 other LSPs). Therefore, this mechanism protects against working LSP 690 failure(s) but requires activation of the protecting LSP after 691 failure occurrence. 693 Signalling is performed by indicating in the Path message (in the 694 PROTECTION object, see Section 14) that the LSPs are of type working 695 and protecting, respectively. Protecting LSPs are used for fast 696 switchover when working LSPs fail. In this case, working and 697 protecting LSPs are signaled as primary LSP and secondary LSP, 698 respectively. Thus, only the working LSP is fully instantiated 699 during the provisioning phase and for the protecting LSPs, no 700 resources are committed at the data plane level (they are pre- 701 reserved at the control plane level only). The setup of the working 702 LSP SHOULD indicate (using the NOTIFY REQUEST object as specified in 703 Section 4 of [RFC-3473]) that the LSP head-end node (and possibly 704 the tail-end node) wish to receive a Notify message upon LSP failure 705 occurrence. Upon receipt of the Notify message, the head-end node 706 MUST switch the (normal) traffic from the working LSP to the 707 protecting LSP after its activation. Note that since the working and 708 the protecting LSP are established between the same end-nodes no 709 further notification is required to indicate that the working LSPs 710 are no longer protected. 712 To make bandwidth pre-reserved for a protecting but not activated 713 LSP, available for extra traffic this bandwidth could be included in 714 the advertised Unreserved Bandwidth at priority lower (means 715 numerically higher) than the Setup Priority of the protecting LSP. 716 In addition, the Max LSP Bandwidth field in the Interface Switching 717 Capability Descriptor sub-TLV should reflect the fact that the 718 bandwidth pre-reserved for the protecting LSP is available for extra 719 traffic. LSPs for extra traffic then can be established using the 720 bandwidth pre-reserved for the protecting LSP by setting (in the 721 Path message) the Setup Priority field of the SESSION_ATTRIBUTE 722 object to X (where X is the Setup Priority of the protecting LSP) 723 and the Holding Priority field at least to X+1. Also, if the 724 resources pre-reserved for the protecting LSP are used by lower 725 priority LSPs, these LSPs MUST be preempted when the protecting LSP 726 is activated. 728 Consider the following topology: 730 A---B---C---D 731 \ / 732 E---F---G 734 J.P.Lang et al. - Internet Draft � Expires August 2004 14 735 The working LSP [A,B,C,D] could be protected by the protecting LSP 736 [A,E,F,G,D]. Only the protected LSP is fully instantiated (resources 737 are only allocated for the working LSP) therefore, the protecting 738 LSP can not carry any extra-traffic. When a failure is detected on 739 the working LSP (say at B), the error is propagated and/or notified 740 to the ingress node (A), which activates the secondary protecting 741 LSP instantiated during the (pre-)provisioning phase. This requires: 742 (1) the ability to identify a "secondary protecting LSP" (hereby 743 called the "secondary LSP") used to recover another primary 744 working LSP (hereby called the "protected LSP") 745 (2) the ability to associate the secondary LSP with the protected 746 LSP 747 (3) the capability to activate a secondary LSP after failure 748 occurrence. 750 In the following subsections, these features are described in more 751 detail. 753 8.1 Identifiers 755 Since both LSPs (i.e. the primary working and the secondary 756 protecting LSPs) belong to the same session, the SESSION object MUST 757 be the same in both LSPs. The LSP ID, however, MUST be different to 758 distinguish between the protected LSP carrying working traffic and 759 the secondary protecting LSP that can not carry extra-traffic. 761 A new PROTECTION object (see Section 14) is used to setup the two 762 LSPs. This object carries the desired end-to-end LSP Protection Type 763 in this case, "Re-routing without Extra-Traffic") as well as the LSP 764 ID of the association LSP. This LSP Protection Type value is 765 applicable to both uni- and bi-directional LSPs. 767 8.2 Signaling Primary LSPs 769 The new PROTECTION object is included in the Path message during 770 signaling of the primary working LSP, with the end-to-end LSP 771 Protection Type value set to "Re-routing without Extra-Traffic". 773 Primary working LSPs are signaled by setting in this object the S 774 bit to 0, the P bit to 0 and the Association ID to the protecting 775 LSP_ID. 777 8.3 Signaling Secondary LSPs 779 The new PROTECTION object carried in the Path message includes the 780 desired end-to-end LSP Protection Type (in this case, "Re-routing 781 without Extra-Traffic") as well as the LSP ID of the associated 782 primary working LSP, which MUST be known before signaling of the 783 secondary LSP. This LSP Protection Type value is applicable to both 784 uni- and bi-directional LSPs. 786 J.P.Lang et al. - Internet Draft � Expires August 2004 15 787 Secondary (protecting) LSPs are signaled by setting in this object 788 the S bit and the P bit to 1. With this setting, the resources for 789 the protecting LSP SHOULD be pre-reserved, but not committed at the 790 data plane level meaning that the internals of the switch need not 791 be established until explicit action is taken to activate this 792 secondary LSP. Activation of a secondary LSP is done using a 793 modified Path message with the S bit set to 0 in the PROTECTION 794 object. At this point, the link and node resources must be allocated 795 for this LSP that becomes a primary LSP (ready to carry normal 796 traffic). 798 Two cases have to be covered here (see also [GMPLS-ARCH]) since 799 secondary protecting LSPs are setup with resource pre-reservation 800 but with or without label pre-selection (both allowing sharing of 801 the recovery resources). In the former case (defined as the 802 default), secondary LSP signaling does not necessitate any specific 803 procedure compared to the one defined in [RFC-3473]. However, in the 804 latter case, label (and thus resource) re-allocation MAY occur 805 during the secondary LSP activation. This means that during the 806 activation phase, labels MAY be re-assigned (with higher precedence 807 over existing label assignment, see also [RFC-3471]). 809 Note: in certain circumstances, it MAY be desirable to perform the 810 activation of the secondary LSP in the upstream direction (Resv 811 trigger message) instead of using the default downstream method. In 812 this case, and in order to avoid any mis-ordering and any mis- 813 interpretation between a refresh Resv and a trigger Resv message at 814 intermediate nodes along the secondary LSP, upon reception of the 815 Path message, the egress node MAY include the PROTECTION object in 816 the Resv message. The latter is then processed on a hop by hop basis 817 to activate the secondary LSP until reaching the ingress node. The 818 PROTECTION object included in the Path message MUST be set as 819 specified in this Section. The upstream activation behavior SHOULD 820 be configurable on a local basis. 822 9. Shared-Mesh Restoration 824 An approach to reduce recovery resource requirements is to have 825 protection LSPs sharing network resources when the working LSPs that 826 they protect are physically (i.e., link, node, SRLG, etc.) disjoint. 827 This mechanism is referred to as shared mesh restoration and is 828 described in [FUNCT]. Shared-mesh restoration can be seen as a 829 particular case of pre-planned LSP re-routing (see Section 8) that 830 reduces the recovery resource requirements by allowing multiple 831 protecting LSPs to share common link and node resources. Here also, 832 the recovery resources for the protecting LSPs are pre-reserved 833 during the provisioning phase, thus an explicit signaling action is 834 required to activate (i.e. commit resource allocation at the data 835 plane) a specific protecting LSP instantiated during the (pre- 836 )provisioning phase. This requires restoration signaling along the 837 protecting LSP. 839 J.P.Lang et al. - Internet Draft � Expires August 2004 16 840 To make bandwidth pre-reserved for a protecting but not activated 841 LSP, available for extra traffic this bandwidth could be included in 842 the advertised Unreserved Bandwidth at priority lower (means 843 numerically higher) than the Setup Priority of the protecting LSP. 844 In addition, the Max LSP Bandwidth field in the Interface Switching 845 Capability Descriptor sub-TLV should reflect the fact that the 846 bandwidth pre-reserved for the protecting LSP is available for extra 847 traffic. LSPs for extra traffic then can be established using the 848 bandwidth pre-reserved for the protecting LSP by setting (in the 849 Path message) the Setup Priority field of the SESSION_ATTRIBUTE 850 object to X (where X is the Setup Priority of the protecting LSP) 851 and the Holding Priority field at least to X+1. Also, if the 852 resources pre-reserved for the protecting LSP are used by lower 853 priority LSPs, these LSPs MUST be preempted when the protecting LSP 854 is activated. Further, if the recovery resources are shared between 855 multiple protecting LSPs, the corresponding working LSPs head-end 856 nodes must be informed that they are no longer protected when the 857 protecting LSP is activated to recover the normal traffic for the 858 working LSP under failure. 860 Consider the following topology: 862 A---B---C---D 863 \ / 864 E---F---G 865 / \ 866 H---I---J---K 868 The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by 869 [A,E,F,G,D] and [H,E,F,G,K], respectively. In order to achieve 870 resource merging during the signaling of these protecting LSPs (i.e. 871 resource sharing), the LSPs must have the same Session Ids, but the 872 Session Id includes the target (egress) IP address. These addresses 873 are not the same in this example. Resource sharing along E, F, G can 874 only be achieved if the nodes E, F and G recognize that the LSP Type 875 setting of the secondary LSPs is for protection (see PROTECTION 876 object, Section 14) and acts accordingly. In this case, the 877 protecting LSPs are not merged (which is useful since the paths 878 diverge at G), but the resources can be shared. 880 When a failure is detected on one of the working LSPs (say at B), 881 the error is propagated and/or notified to the ingress node (A), 882 which activates the protecting LSP (see Section 8). At this point, 883 it is important that a failure on the other LSP (say at J) does not 884 cause the other ingress (H) to send the data down the protecting LSP 885 since the resources are already in use. This can be achieved by node 886 E using the following procedure. When the capacity is first reserved 887 for the protecting LSP, E should verify that the LSPs being 888 protected ([A,B,C,D] and [H,I,J,K], respectively) do not share any 889 common resources. Then, when a failure occurs (say at B) and the 890 protecting LSP [A,E,F,G,D] is activated, E should notify H that the 892 J.P.Lang et al. - Internet Draft � Expires August 2004 17 893 resources for the protecting LSP [H,E,F,G,K] are no longer 894 available. 896 The following sub-sections details how shared mesh restoration can 897 be implemented in an interoperable fashion using GMPLS RSVP-TE 898 extensions (see [RFC-3473]). This includes: 899 (1) the ability to identify a "secondary protecting LSP" (hereby 900 called the "secondary LSP") used to recover another primary 901 working LSP (hereby called the "protected LSP") 902 (2) the ability to associate the secondary LSP with the protected 903 LSP 904 (3) the capability to include information about the resources used 905 by the protected LSP while instantiating the secondary LSP. 906 (4) the capability to instantiate during the provisioning phase 907 several secondary LSPs in an efficient manner. 908 (5) the capability to activate a secondary LSP after failure 909 occurrence. 911 In the following subsections, these features are described in 912 detail. 914 9.1. Identifiers 916 Since both LSPs (i.e. the primary working and the secondary 917 protecting LSPs) belong to the same session, the SESSION object MUST 918 be the same in both LSPs. The LSP ID, however, MUST be different to 919 distinguish between the protected LSP carrying working traffic and 920 the secondary protecting LSP that can not carry extra-traffic. 922 A new PROTECTION object (see Section 14) is used to setup the two 923 LSPs. This object carries the desired end-to-end LSP Protection Type 924 in this case, "Re-routing without Extra-Traffic") as well as the LSP 925 ID of the associated LSP. This LSP Protection Type value is 926 applicable to both uni- and bi-directional LSPs. 928 9.2 Signaling Primary LSPs 930 The new PROTECTION object is included in the Path message during 931 signaling of the primary working LSP, with the end-to-end LSP 932 Protection Type value set to "Re-routing without Extra-Traffic". 934 Primary working LSPs are signaled by setting in this object the S 935 bit to 0, the P bit to 0 and the Association ID to the protecting 936 LSP_ID. 938 9.3 Signaling Secondary LSPs 940 The new PROTECTION object carried in the Path message includes the 941 desired end-to-end LSP Protection Type (in this case, "Re-routing 942 without Extra-Traffic") as well as the LSP ID of the associated 943 primary working LSP, which MUST be known before signaling of the 945 J.P.Lang et al. - Internet Draft � Expires August 2004 18 946 secondary LSP. This LSP Protection Type value is applicable to both 947 uni- and bi-directional LSPs. 949 Secondary (protecting) LSPs are signaled by setting in this object 950 the S bit and the P bit to 1. Moreover, the Path message used to 951 instantiate this LSP MUST include at least one PRIMARY PATH ROUTE 952 object (see Section 15) that further allows for recovery resource 953 sharing at each intermediate node along the secondary path. With 954 this setting, the resources for the protecting LSP SHOULD be pre- 955 reserved, but not committed at the data plane level meaning that the 956 internals of the switch need not be established until explicit 957 action is taken to activate this LSP. Activation of a secondary LSP 958 is done using a modified Path message with the S bit set to 0 in the 959 PROTECTION object. At this point, the link and node resources must 960 be allocated for this LSP that becomes a primary LSP (ready to carry 961 normal traffic). 963 Two cases have to be covered here (see also [GMPLS-ARCH]) since the 964 secondary LSP are setup with resource pre-reservation but with or 965 without label pre-selection (both allowing sharing of the recovery 966 resources). In the former case (defined as the default), secondary 967 LSP signaling does not necessitate any specific procedure compared 968 to the one defined in [RFC-3473]. However, in the latter case, label 969 (and thus resource) re-allocation MAY occur during the secondary LSP 970 activation. This means that during the LSP activation phase, labels 971 MAY be re-assigned (with higher precedence over existing label 972 assignment, see also [RFC-3471]). 974 11. (Full) LSP Re-routing 976 LSP re-routing, on the other hand, switches normal traffic to an 977 alternate LSP that is fully established only after failure 978 occurrence. The new (alternate) route is selected at the LSP head- 979 end and may reuse intermediate nodes included in the original route; 980 it may also include additional intermediate nodes. For strict-hop 981 routing, TE requirements can be directly applied to the route 982 computation, and the filed node or link can be avoided. However, if 983 the failure occurred within a loose-routed hop, the head-end node 984 may not have enough information to reroute the LSP around the 985 failure. Crankback signaling and route exclusion techniques (see 986 [XRO]) MAY be used in this case. 988 The alternate route may be either computed on demand (that is, when 989 the failure occurs; this is referred to as full LSP re-routing) or 990 pre-computed and stored for use when the failure is reported. The 991 latter offers faster restoration time. There is, however, a risk 992 that the alternate route will become out of date through other 993 changes in the network - this can be mitigated to some extent by 994 periodic recalculation of idle alternate routes. 996 (Full) LSP re-routing will be initiated by the head-end node that 997 has either detected the failure or received a Notify message and/or 999 J.P.Lang et al. - Internet Draft � Expires August 2004 19 1000 a PathErr message indicating that a failure has occurred. The new 1001 LSP resources can be established using the make-before-break 1002 mechanism, where the new LSP is setup before the old LSP is torn 1003 down. This is done by using the mechanisms of the SESSION object and 1004 the Shared-Explicit (SE) reservation style (see [RFC-3209]). Both 1005 the new and old LSPs can share resources at common nodes. 1007 Note that the make-before-break mechanism is not used to avoid 1008 disruption to the normal traffic flow (the latter has already been 1009 broken by the failure that is being repaired). However, it is 1010 valuable to retain the resources allocated on the original LSP that 1011 will be re-used by the new alternate LSP. 1013 11.1 Identifiers 1015 The Tunnel End Point Address, Tunnel Id, Extended Tunnel Id, Tunnel 1016 Sender Address and LSP Id are all used to uniquely identify both the 1017 old and new LSPs. The new (alternate) LSP is setup before the old 1018 LSP is torn down using Shared-Explicit (SE) reservation style. This 1019 ensures that the new LSP is established without double counting 1020 resource requirements along common segments. 1022 Note: if the alternate LSP is setup before any failure occurrence 1023 with SE style resource reservation, the latter shares the same 1024 Tunnel End Point Address, Tunnel Id, Extended Tunnel Id, and Tunnel 1025 Sender Address with the original LSP (i.e. only the LSP Id value 1026 MUST be different). 1028 11.2 Signaling Re-routable LSPs 1030 A new PROTECTION object is included in the Path message during 1031 signaling of dynamically re-routable LSPs, with the end-to-end LSP 1032 Protection Type value set to "Full Re-routing". These LSPs that can 1033 be either uni- or bi-directional are signaled by setting in this 1034 object the S bit to 0, the P bit to 0 and the Association ID to 0. 1035 Any specific action to be taken during the provisioning phase is up 1036 the end-node local policy. 1038 Note: when the end-to-end LSP Protection Type is set to 1039 "Unprotected", both S and P bit MUST be set to 0 and the LSP MUST 1040 NOT be re-routed at the head-end node after failure occurrence. The 1041 Association_ID value MUST be set to 0. 1043 12. Reversion 1045 Reversion refers to a recovery switching operation, where the normal 1046 traffic returns to (or remains on) the working LSP when it has 1047 recovered from the failure. Reversion implies that resources remain 1048 allocated to the LSP that was originally routed over it even after a 1049 failure. It is important to have mechanisms that allow reversion to 1050 be performed with minimal service disruption and reconfiguration. 1052 J.P.Lang et al. - Internet Draft � Expires August 2004 20 1053 For "1+1 bi-directional" and "1:N Protection with Extra-traffic" 1054 protection, reversion to the recovered LSP occurs by using the 1055 following sequence: 1056 - first, clear the A bit of the ADMIN_STATUS object if set for the 1057 recovered LSP 1058 - then, apply the reverse 1-phase APS switchover request/response 1059 (or 2-phase APS) described in Section 6.2 (or Section 7.2, 1060 respectively) to switch normal traffic back from the 1061 protecting to the recovered LSP. This is performed by using the 1062 Notify message with a new Error Code indicating "(Working) LSP 1063 Recovered (Switchover Request)". The Notify Ack message MUST be 1064 sent to confirm the reception of the Notify message (see [RFC- 1065 3473], Section 4.3). 1066 - finally, clear the O bit of the PROTECTION object sent over the 1067 protecting LSP. 1069 For "Re-routing without Extra-traffic" reversion (including the 1070 shared recovery case) implies that the formerly working LSP has not 1071 been torn down by the head-end node upon PathErr message reception 1072 (i.e. the head-end node kept refreshing the working LSP under 1073 failure condition). This ensures that the same resources are 1074 retrieved after reversion switching. Re-activation is performed 1075 using the following sequence: 1076 - first, clear the A bit of the ADMIN_STATUS object if set for the 1077 recovered LSP 1078 - then, apply the reverse 1-phase APS switchover request/response 1079 described in Section 6.2, to switch normal traffic back from the 1080 protecting to the recovered LSP. This is performed by using the 1081 Notify message with a new Error Code indicating "(Working) LSP 1082 Recovered (Switchover Request)". The Notify Ack message MUST be 1083 sent to confirm the reception of the Notify message (see [RFC- 1084 3473], Section 4.3). 1085 - finally, de-activate the protecting LSP by setting the S bit to 1 1086 in the PROTECTION object sent over the protecting LSP. 1088 13. External Commands 1090 This section specifies the control plane behavior when using several 1091 external commands (see [TERM]), typically issued by an operator 1092 through the Network Management System (NMS)/Element Management 1093 System (EMS), which can be used to influence or command the recovery 1094 operations. Other specific commands may complete the below list. 1096 A. Lockout of recovery LSP: 1098 The Lockout bit (L bit) of the ADMIN_STATUS object is used following 1099 the rules defined in Section 8 of [RFC-3471] and Section 7 of [RFC- 1100 3473]. The L bit must be set together with the Reflect (R) bit in 1101 the ADMIN_STATUS object sent in the Path message. Upon reception of 1102 the Resv message with the L bit set, this forces the recovery LSP to 1103 be temporarily unavailable to transport traffic (either normal or 1105 J.P.Lang et al. - Internet Draft � Expires August 2004 21 1106 extra traffic). Unlock is performed by clearing the L bit, following 1107 the rules defined in Section 7 of [RFC-3473]. 1109 B. Lockout of normal traffic: 1111 The O bit of the PROTECTION object is set to 1 to force the recovery 1112 LSP to be temporarily unavailable to transport normal traffic. This 1113 operation MUST never occur unless the working LSP is carrying the 1114 normal traffic. Unlock is performed by clearing the O bit over the 1115 protecting LSP. 1117 C. Forced switch for normal traffic: 1119 Recovery signaling is initiated externally that switches normal 1120 traffic to the recovery LSP following the procedures defined in 1121 Section 6, 7, 8 and 9. 1123 D. Manual switch for normal traffic: 1125 Recovery signaling operation is initiated externally that switches 1126 normal traffic to the recovery LSP following the procedures defined 1127 in Section 6, 7, 8 and 9. This, unless a fault condition exists on 1128 other LSPs/spans (including the recovery LSP) or an equal or higher 1129 priority switch command is in effect. 1131 E. Manual switch for recovery LSP: 1133 Recovery signaling operation is initiated externally that switches 1134 normal traffic to the working LSP following the procedure defined in 1135 Section 12. This, unless a fault condition exists on the working LSP 1136 or an equal or higher priority switch command is in effect. 1138 14. PROTECTION Object 1140 In this section, we describe the extensions to the PROTECTION object 1141 to broaden its applicability to end-to-end LSP recovery. In addition 1142 to modifications to the format of the PROTECTION object, we extend 1143 its use so that the object can be included in the Notify message to 1144 act a switchover request for 1+1 bi-directional and 1:1 protection. 1146 The format of the PROTECTION Object (Class-Num = 37, C-Type = TBA by 1147 IANA) is as follows: 1149 0 1 2 3 1150 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 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | Length | Class-Num(37) | C-Type (TBA) | 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 |S|P|N|O| Reserved | LSP Flags | Reserved | Link Flags| 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 | Reserved | 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 J.P.Lang et al. - Internet Draft � Expires August 2004 22 1160 Secondary (S): 1 bit 1162 When set to 1, this bit indicates that the requested LSP is a 1163 secondary LSP. When set to 0 (default), it indicates that the 1164 requested LSP is a primary LSP. 1166 Protecting (P): 1 bit 1168 When set to 1, this bit indicates that the requested LSP is a 1169 protecting LSP. When set to 0 (default), it indicates that the 1170 requested LSP is a working LSP. The combination, S set to 1 1171 with P set to 0 is not valid. 1173 Notification (N): 1 bit 1175 When set to 1, this bit indicates that the control plane 1176 message exchange is only used for notification during 1177 protection switching. When set to 0 (default), it indicates 1178 that the control plane message exchanges are used for 1179 protection switching purposes. The N bit is only applicable 1180 when the LSP Flag is set to either 0x04, or 0x08 or 0x10. The 1181 N bit MUST be set to 0 in any other case. 1183 Operational (O): 1 bit 1185 When set to 1, this bit indicates that the protecting LSP is 1186 carrying the normal traffic after protection switching. The O 1187 bit is only applicable when the P bit is set to 1 and the LSP 1188 Flag is set to either 0x04, or 0x08 or 0x10. The O bit MUST be 1189 set to 0 in any other case. The O bit MUST be set to 0 in any 1190 other case. 1192 Reserved: 5 bits 1194 This field is reserved. It MUST be set to zero on transmission 1195 and MUST be ignored on receipt. These bits SHOULD be passed 1196 through unmodified by transit nodes. 1198 LSP (Protection Type) Flags: 6 bits 1200 Indicates the desired end-to-end LSP recovery type. A value of 1201 0 implies that the LSP is "Unprotected". Only one value SHOULD 1202 be set at a time. The following values are defined. All other 1203 values are reserved. 1205 0x00 Unprotected 1206 0x01 (Full) Re-routing 1207 0x02 Re-routing without Extra-Traffic 1208 0x04 1:N Protection with Extra-Traffic 1209 0x08 1+1 Unidirectional Protection 1210 0x10 1+1 Bi-directional Protection 1212 J.P.Lang et al. - Internet Draft � Expires August 2004 23 1213 Reserved: 10 bits 1215 This field is reserved. It MUST be set to zero on transmission 1216 and MUST be ignored on receipt. These bits SHOULD be passed 1217 through unmodified by transit nodes. 1219 Link Flags: 6 bits 1221 Indicates the desired link protection type (see [RFC-3471]). 1223 Intermediate nodes processing a Path message containing a PROTECTION 1224 object with the LSP Protection Type "0x02" value set and a PRIMARY 1225 PATH ROUTE object (see Section 15) and MUST verify that the 1226 requested LSP Protection Type can be supported by the outgoing 1227 interface. If it can not, the node MUST generate a PathErr message, 1228 with a "Routing problem/Unsupported LSP Protection" indication. 1229 Intermediate and Egress nodes processing a Path message containing 1230 the PROTECTION object MUST verify that the requested LSP Protection 1231 Type can be satisfied by the incoming interface. If it cannot, the 1232 node MUST generate a PathErr message, with the "Routing problem/ 1233 Unsupported LSP Protection" error code. 1235 15. PRIMARY PATH ROUTE Object 1237 The PRIMARY PATH ROUTE object (PPRO) is defined to inform nodes 1238 along the path of a secondary protecting LSP about which resources 1239 (link/nodes) are being used by the associated primary protected LSP 1240 (as specified by the Association ID field). This object MUST be 1241 present in the Path message (for the pre-provisioning of the 1242 secondary protecting LSP) if and only if the LSP Protection Type 1243 value is set to "0x02". This document does not assume or preclude 1244 any other usage for this object. 1246 PRIMARY PATH ROUTE objects carry information extracted from the 1247 EXPLICIT ROUTE object and/or the RECORD ROUTE object of the primary 1248 working LSPs they protect. Selection of the PPRO content is up to 1249 local policy of the head-end LSR that initiates the request. 1250 Therefore, the information included in these objects MAY be used as 1251 policy-based admission control to ensure that recovery resources are 1252 only shared between secondary protecting LSPs whose associated 1253 primary LSPs have link/node/SRLG disjoint paths. 1255 15.1. Definition 1257 The primary path route is specified via the PRIMARY_PATH_ROUTE 1258 object (PPRO). The Primary Path Route Class Number is TBA by IANA. 1260 Currently one C-Type (Class-Type) is defined, Type 1 Primary Path 1261 Route. The PRIMARY_PATH_ROUTE object has the following format: 1263 Class-Num = TBA by IANA (of form 0bbbbbbb), C-Type = 1 (suggested) 1265 J.P.Lang et al. - Internet Draft � Expires August 2004 24 1266 0 1 2 3 1267 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 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 | | 1270 // (Subobjects) // 1271 | | 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 The contents of a PRIMARY_PATH_ROUTE object are a series of 1275 variable-length data items called subobjects. The subobjects are 1276 identical to those that can constitute an EXPLICIT/RECORD ROUTE 1277 object as defined in [RFC-3209], [RFC-3473] and [RFC-3477]. 1279 To signal a secondary protecting LSP, the Path message MUST include 1280 at least one or MAY include multiple PRIMARY_PATH_ROUTE objects, 1281 where each object is meaningful. The latter is useful when a given 1282 secondary protecting LSP must be link/node/SRLG disjoint from more 1283 than one primary LSP (i.e. is protecting more than one primary LSP). 1285 15.2 Applicability 1287 The PRIMARY_PATH_ROUTE object MUST only be used when all GMPLS nodes 1288 along the path support the PRIMARY_PATH_ROUTE object and a secondary 1289 protecting LSP is being requested. The PRIMARY_PATH_ROUTE object is 1290 assigned a class value of the form 0bbbbbbb. Receiving GMPLS nodes 1291 along the path that do not support this object MUST return a PathErr 1292 message with the "Unknown Object Class" error code. 1294 Also, the following restrictions MUST be applied with respect to the 1295 PPRO usage: 1297 - PPROs MUST only be sent over secondary protecting LSPs (S bit = 1 1298 and P bit = 1) and when the LSP Protection Type value is set to 1299 "0x02" in the PROTECTION object (see Section 14.) 1301 - Crossed exchanges of PPROs over primary LSPs are forbidden (i.e. 1302 their usage is restricted to a single set of protected LSPs). If a 1303 PPRO is received with the S bit set to 0 in the PROTECTION object, 1304 the receiving node MUST return a PathErr with the "Routing 1305 Problem/PRIMARY PATH_ROUTE object not applicable" error code. 1307 - The PPRO's content MUST NOT include subobjects coming from other 1308 PPROs. In particular, received PPROs MUST NOT be re-used to 1309 establish other working or protecting LSPs. 1311 15.3 Subobjects 1313 The PRIMAY_PATH_ROUTE object is defined as a list of variable-length 1314 data items called subobjects. PPR subobjects are derived from the 1315 subobjects of the EXPLICIT ROUTE and/or RECORD ROUTE object of the 1317 J.P.Lang et al. - Internet Draft � Expires August 2004 25 1318 primary working LSP(s). Each PPR subobject has its own length field. 1319 The length contains the total length of the subobject in bytes, 1320 including the Type and Length fields. The length MUST always be a 1321 multiple of 4, and at least 4. 1323 The following subobjects are currently defined for the PRIMARY PATH 1324 ROUTE object: 1326 - Sub-Type 1: IPv4 Address (see [RFC 3209]) 1327 - Sub-Type 2: IPv6 Address (see [RFC 3209]) 1328 - Sub-Type 3: Label (see [RFC-3473]) 1329 - Sub-Type 4: Unnumbered Interface (see [RFC-3477]) 1331 An empty PPRO with no subobjects is considered as illegal. If there 1332 is no first subobject, the corresponding Path message is also in 1333 error and the receiving node SHOULD return a PathErr with the 1334 "Routing Problem/Bad PRIMARY PATH_ROUTE object" error code. 1336 Note: an intermediate node processing a PPRO can derive SRLG 1337 identifiers from the local IGP-TE database using its Type 1, 2 or 4 1338 subobject values as pointers to the corresponding TE Links (assuming 1339 each of them has an associated SRLG TE attribute). 1341 15.4 Processing 1343 The PPRO enables of sharing recovery resources between a given 1344 secondary protecting LSP and one or more secondary protecting LSPs 1345 if their corresponding primary working LSPs have mutually 1346 (link/node/SRLG) disjoint paths. Consider a node N through which n 1347 secondary protecting LSPs (say P[1],...,P[n]) have already been 1348 established and protecting n primary working LSPs (say 1349 P'[1],...,P'[n]). Suppose also that these n secondary working LSPs 1350 share a given outgoing link resource (say r). 1352 Now, suppose that node N receives a Path message for an additional 1353 secondary protecting LSP (say Q, protecting Q'). The PPRO carried by 1354 this Path messages is processed as follows: 1356 - N checks whether the primary working LSPs P'[1],...,P'[n] 1357 associated with the LSPs P[1],...,P[n] respectively have any link, 1358 node and SLRG in common with the primary working Q' (associated 1359 with Q) by comparing the stored PPRO subobjects associated with 1360 P'[1],...,P'[n] with the PPRO subobjects associated with Q' 1361 received in the Path message. 1363 - If this is the case, N SHOULD NOT attempt to share the outgoing 1364 link resource r between P[1],...,P[n] and Q. However, upon local 1365 policy decision, N MAY allocate another available (shared) link 1366 other than r for use by Q. If this is not the case (upon the local 1367 policy decision that no other link is allowed to be allocated for 1368 Q) or if no other link is available for Q, N SHOULD return a 1369 PathErr message with the "Admission Control Failure/LSP Admission 1371 J.P.Lang et al. - Internet Draft � Expires August 2004 26 1372 Failure" error code. 1374 - Otherwise (if P'[1],...,P'[n] and Q' are fully disjoint), the link 1375 r selected by N for the LSP Q MAY be exactly the same as the one 1376 selected for the LSPs P[1],...,P[n]. This, after verifying (also 1377 from its local policy) that the selected link r can be shared 1378 between these LSPs. If this is not the case (for instance, the 1379 sharing ratio has reached its maximum for that link) and upon 1380 local policy decision no other link is allowed to be allocated for 1381 Q, N SHOULD return a PathErr with the "Admission Control Failure/ 1382 Requested Bandwidth Unavailable" error code. Otherwise (if no 1383 other link is available), N SHOULD return a PathErr with the 1384 "Admission Control Failure/LSP Admission Failure" error code. 1386 Note that the process, through which m out of the n (m =< n) 1387 secondary protecting LSPs PPROs may be selected on a local basis to 1388 perform the above comparison and subsequent link selection, is out 1389 of scope of this document. 1391 16. ASSOCIATION Object 1393 The ASSOCIATION object is used to associate LSPs with each other. In 1394 the context of end-to-end LSP recovery, the association MUST only 1395 identify LSPs that support the same Tunnel ID. The Association Type, 1396 Association Source and Association ID fields of the object together 1397 uniquely identify an association. The object uses an object class 1398 number of the form 11bbbbbb to ensure compatibility with non- 1399 supporting nodes. 1401 The ASSOCIATION object is used to associate LSPs with each other. 1403 16.1. Format 1405 The IPv4 Association object has the format: 1407 0 1 2 3 1408 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 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 | Length | Class-Num(TBD)| C-Type (1) | 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 | Association Type | Association ID | 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 | IPv4 Association Source | 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 The IPv6 Association object has the format: 1419 0 1 2 3 1420 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 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 | Length | Class-Num(TBD)| C-Type (2) | 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 J.P.Lang et al. - Internet Draft � Expires August 2004 27 1426 | Association Type | Association ID | 1427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 | | 1429 | IPv6 Association Source | 1430 | | 1431 | | 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 Association Type: 16 bits 1436 Indicates the type of association being identified. Note that 1437 this value is considered when determining association. The 1438 following are values defined in this document. 1440 Value Type 1441 ----- ---- 1442 0 Reserved 1443 1 Recovery (R) 1445 Association ID: 16 bits 1447 A value that when combined with Association Type and 1448 Association Source uniquely identifies an association. 1450 Association Source: 4 or 16 bytes 1452 The IP address of the node that originated the association. 1454 16.2. Processing 1456 The ASSOCIATION object is used to associate different LSPs with each 1457 other. In the protection and restoration context, the object is used 1458 to associate a recovery LSP with the LSP it is protecting. The 1459 object is carried in Path messages. More than one object may be 1460 carried in a single Path message. 1462 Transit nodes MUST transmit, without modification, any received 1463 ASSOCIATION object in the corresponding outgoing Path message. 1465 An ASSOCIATION object with an Association Type set to the value 1466 Recovery is used to identify a LSP Recovery related association. Any 1467 node associating a recovery LSP MUST insert an ASSOCIATION object 1468 with a Recovery Association Type set in the Path message of the 1469 recovery LSP. The Association Source MUST be set to the tunnel 1470 sender address of the LSP being protected. The Association ID MUST 1471 be set to the LSP ID of the LSP being protected by this LSP or the 1472 LSP protecting this LSP. If unknown, this value is set to 0 1473 (default). Also, the value of the Association ID MAY change during 1474 the lifetime of the LSP. 1476 Nodes merging recovery LSPs use received ASSOCIATION objects with 1477 the Recovery type to associate a recovery LSP with it's matching 1479 J.P.Lang et al. - Internet Draft � Expires August 2004 28 1480 working LSP. This information is used to bind the appropriate 1481 working and recovery LSPs together. 1483 17. Updated RSVP Message Formats 1485 This section presents the RSVP message related formats as modified 1486 by this document. Unmodified RSVP message formats are not listed. 1488 The format of a Path message is as follows: 1490 ::= [ ] 1491 [ [ | ] ... ] 1492 [ ] 1493 1494 1495 [ ] 1496 1497 [ ] 1498 [ ... ] 1499 [ ] 1500 [ ... ] 1501 [ ] 1502 [ ... ] 1503 [ ... ] 1504 [ ... ] 1505 1507 The format of the for unidirectional and 1508 bidirectional LSPs is not modified by the present document 1510 18. Security Considerations 1512 This document does not introduce or imply any specific security 1513 consideration. 1515 19. Acknowledgments 1517 The authors would like to thank John Drake for its active 1518 collaboration, Adrian Farrel for his contribution to this document 1519 (in particular, to the Section 11) and his thorough review of the 1520 document, Bart Rousseau (for editorial review) and Stefaan 1521 De_Cnodder. 1523 The authors would like also to thank Lou Berger for the time and 1524 effort he spent together with the design team, in contributing to 1525 the present document. 1527 20. IANA Considerations 1529 IANA assigns values to RSVP protocol parameters. Within the current 1530 document a PROTECTION object (new C-Type) and a PRIMARY PATH ROUTE 1531 object are defined. 1533 J.P.Lang et al. - Internet Draft � Expires August 2004 29 1534 One RSVP Class Number (Class-Num) and two Class Types (C-Types) 1535 values have to be defined by IANA in registry: 1537 http://www.iana.org/assignments/rsvp-parameters 1539 - PROTECTION object: Class-Num = 37, C-Type = 2 (suggested) 1541 - PRIMARY PATH ROUTE object: Class-Num = TBA (of form 0bbbbbbb), 1542 C-Type = 1 (suggested) 1544 - ASSOCIATION object: Class-Num = TBA (of form 11bbbbbb), 1545 C-Type = 1 (suggested) 1547 - Error values: 1549 o "Admission Control Failure/LSP Admission Failure" (value = TBA) 1551 o "Routing Problem/Unsupported LSP Protection" (value = TBA) 1552 o "Routing Problem/Bad PRIMARY PATH_ROUTE object" (value = TBA) 1553 o "Routing Problem/PRIMARY PATH_ROUTE object not applicable" 1554 (value = TBA) 1556 o "Notify Error/LSP Failure" (value = TBA) 1557 o "Notify Error/LSP Recovered" (value = TBA) 1559 21. Intellectual Property Considerations 1561 This section is taken from Section 10.4 of [RFC2026]. 1563 The IETF takes no position regarding the validity or scope of any 1564 intellectual property or other rights that might be claimed to 1565 pertain to the implementation or use of the technology described in 1566 this document or the extent to which any license under such rights 1567 might or might not be available; neither does it represent that it 1568 has made any effort to identify any such rights. Information on the 1569 IETF's procedures with respect to rights in standards-track and 1570 standards-related documentation can be found in BCP-11. Copies of 1571 claims of rights made available for publication and any assurances 1572 of licenses to be made available, or the result of an attempt made 1573 to obtain a general license or permission for the use of such 1574 proprietary rights by implementors or users of this specification 1575 can be obtained from the IETF Secretariat. 1577 The IETF invites any interested party to bring to its attention any 1578 copyrights, patents or patent applications, or other proprietary 1579 rights, which may cover technology that may be required to practice 1580 this standard. Please address the information to the IETF Executive 1581 Director. 1583 J.P.Lang et al. - Internet Draft � Expires August 2004 30 1584 22. References 1586 22.1 Normative References 1588 [FRR] P.Pan (Editor), "Fast Reroute Extensions to RSVP-TE for 1589 LSP Tunnels," Internet Draft, Work in progress, draft- 1590 ietf-mpls-rsvp-lsp-fastreroute-03.txt, June 2003. 1592 [FUNCT] J.P.Lang and B.Rajagopalan (Editors), "Generalized MPLS 1593 Recovery Functional Specification," Internet Draft, 1594 Work in Progress, draft-ietf-ccamp-gmpls-recovery- 1595 functional-01.txt, September 2003. 1597 [GMPLS-ARCH] E.Mannie (Editor), "Generalized Multi-Protocol Label 1598 Switching Architecture," Internet Draft, Work in 1599 progress, draft-ietf-ccamp-gmpls-architecture-07.txt, 1600 May 2003. 1602 [GMPLS-RTG] K.Kompella (Editor), "Routing Extensions in Support of 1603 Generalized MPLS," Internet Draft, Work in Progress, 1604 draft-ietf-ccamp-gmpls-routing-09.txt, October 2003. 1606 [LMP] J.Lang (Editor), "Link Management Protocol (LMP) v1.0," 1607 Internet Draft, Work in progress, draft-ietf-ccamp-lmp- 1608 10, October 2003. 1610 [RFC-2026] S.Bradner, "The Internet Standards Process -- Revision 1611 3," BCP 9, RFC 2026, October 1996. 1613 [RFC-2119] S.Bradner, "Key words for use in RFCs to Indicate 1614 Requirement Levels," BCP 14, RFC 2119, March 1997. 1616 [RFC-2961] L.Berger et al., "RSVP Refresh Overhead Reduction 1617 Extensions," RFC 2961, April 2001. 1619 [RFC-3209] D.Awduche et al., "RSVP-TE: Extensions to RSVP for 1620 LSP Tunnels," RFC 3209, December 2001. 1622 [RFC-3471] L.Berger (Editor) et al., "Generalized Multi-Protocol 1623 Label Switching (GMPLS) � Signaling Functional 1624 Description," RFC 3471, January 2003. 1626 [RFC-3473] L.Berger (Editor) et al., "Generalized Multi-Protocol 1627 Label Switching (GMPLS) Signaling � Resource 1628 Reservation Protocol - Traffic Engineering (RSVP-TE) 1629 Extensions," RFC 3473, January 2003. 1631 [RFC-3477] K.Kompella, and Y.Rekhter, "Signalling Unnumbered Links 1632 in Resource Reservation Protocol - Traffic Engineering 1633 (RSVP-TE)," RFC 3477, January 2003. 1635 J.P.Lang et al. - Internet Draft � Expires August 2004 31 1637 [TERM] E.Mannie and D.Papadimitriou (Editors), "Recovery 1638 (Protection and Restoration) Terminology for GMPLS," 1639 Internet Draft, Work in progress, draft-ietf-ccamp- 1640 gmpls-recovery-terminology-03.txt, January 2004. 1642 [XRO] C.Y.Lee et al. "Exclude Routes - Extension to RSVP-TE," 1643 Internet Draft, Work in progress, draft-ietf-ccamp- 1644 rsvp-te-exclude-route-01.txt, November 2003. 1646 23. Author's Addresses 1648 Jonathan Lang (Rincon Networks) 1649 E-mail: jplang@ieee.org 1651 Yakov Rekhter (Juniper) 1652 1194 N. Mathilda Avenue 1653 Sunnyvale, CA 94089, USA 1654 E-mail: yakov@juniper.net 1656 Dimitri Papadimitriou (Alcatel) 1657 Fr. Wellesplein, 1 1658 B-2018, Antwerpen, Belgium 1659 E-mail: dimitri.papadimitriou@alcatel.be 1661 J.P.Lang et al. - Internet Draft � Expires August 2004 32 1662 Full Copyright Statement 1664 "Copyright (C) The Internet Society (date). All Rights Reserved. 1665 This document and translations of it may be copied and furnished to 1666 others, and derivative works that comment on or otherwise explain it 1667 or assist in its implementation may be prepared, copied, published 1668 and distributed, in whole or in part, without restriction of any 1669 kind, provided that the above copyright notice and this paragraph 1670 are included on all such copies and derivative works. However, this 1671 document itself may not be modified in any way, such as by removing 1672 the copyright notice or references to the Internet Society or other 1673 Internet organizations, except as needed for the purpose of 1674 developing Internet standards in which case the procedures for 1675 copyrights defined in the Internet Standards process must be 1676 followed, or as required to translate it into languages other than 1677 English. 1679 The limited permissions granted above are perpetual and will not be 1680 revoked by the Internet Society or its successors or assigns. 1682 This document and the information contained herein is provided on an 1683 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1684 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1685 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1686 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1687 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1689 J.P.Lang et al. - Internet Draft � Expires August 2004 33