idnits 2.17.1 draft-ietf-ccamp-assoc-info-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2205, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3473, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3209, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2205, updated by this document, for RFC5378 checks: 1997-09-01) -- 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 (March 14, 2011) is 4792 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) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Lou Berger (LabN) 2 Updates: 2205, 3209, 3473 Francois Le Faucheur (Cisco) 3 Category: Standards Track Ashok Narayanan (Cisco) 4 Expiration Date: September 14, 2011 6 March 14, 2011 8 Usage of The RSVP Association Object 10 draft-ietf-ccamp-assoc-info-01.txt 12 Abstract 14 The RSVP ASSOCIATION object was defined in the context of GMPLS 15 (Generalized Multi-Protocol Label Switching) controlled label 16 switched paths (LSPs). In this context, the object is used to 17 associate recovery LSPs with the LSP they are protecting. This 18 object also has broader applicability as a mechanism to associate 19 RSVP state, and this document defines how the ASSOCIATION object 20 can be more generally applied. The document also reviews how the 21 association is to be provided in the context of GMPLS recovery. 22 No new new procedures or mechanisms are defined with respect to 23 GMPLS recovery. This document also defines extended ASSOCIATION 24 objects which can be used in the context of Transport Profile of 25 Multiprotocol Label Switching (MPLS-TP). 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 This Internet-Draft will expire on September 14, 2011 50 Copyright and License Notice 52 Copyright (c) 2011 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1 Introduction ........................................... 3 68 1.1 Conventions Used In This Document ...................... 4 69 2 Background ............................................. 4 70 2.1 LSP Association ........................................ 4 71 2.2 End-to-End Recovery LSP Association .................... 6 72 2.3 Segment Recovery LSP Association ....................... 8 73 2.4 Resource Sharing LSP Association ....................... 9 74 3 Association of GMPLS Recovery LSPs ..................... 10 75 4 Non-GMPLS Recovery Usage ............................... 11 76 4.1 Upstream Initiated Association ......................... 11 77 4.1.1 Path Message Format .................................... 12 78 4.1.2 Path Message Processing ................................ 12 79 4.2 Downstream Initiated Association ....................... 13 80 4.2.1 Resv Message Format .................................... 14 81 4.2.2 Resv Message Processing ................................ 14 82 4.3 Association Types ...................................... 15 83 4.3.1 Resource Sharing Association Type ...................... 15 84 5 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 16 85 5.1 IPv4 and IPv6 Extended ASSOCIATION Object Format ....... 17 86 5.2 Processing ............................................. 18 87 6 Security Considerations ................................ 20 88 7 IANA Considerations .................................... 20 89 7.1 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 20 90 7.2 Resource Sharing Association Type ...................... 21 91 8 Acknowledgments ........................................ 21 92 9 References ............................................. 21 93 9.1 Normative References ................................... 21 94 9.2 Informative References ................................. 22 95 10 Authors' Addresses ..................................... 23 97 1. Introduction 99 End-to-end and segment recovery are defined for GMPLS (Generalized 100 Multi-Protocol Label Switching) controlled label switched paths 101 (LSPs) in [RFC4872] and [RFC4873] respectively. Both definitions use 102 the ASSOCIATION object to associate recovery LSPs with the LSP they 103 are protecting. This document provides additional narrative on how 104 such associations are to be identified. In the context of GMPLS 105 recovery, this document does not define any new procedures or 106 mechanisms and is strictly informative in nature. 108 In addition to the narrative, this document also explicitly expands 109 the possible usage of the ASSOCIATION object in other contexts. In 110 Section 4, this document reviews how association should be made in 111 the case where the object is carried in a Path message and defines 112 usage with Resv messages. This section also discusses usage of the 113 ASSOCIATION object outside the context of GMPLS LSPs. 115 Some examples of non-LSP association in order to enable resource 116 sharing are: 118 o Voice Call-Waiting: 119 A bidirectional voice call between two endpoints A and B is 120 signaled using two separate unidirectional RSVP reservations for 121 the flows A->B and B->A. If endpoint A wishes to put the A-B call 122 on hold and join a separate A-C call, it is desirable that 123 network resources on common links be shared between the A-B and 124 A-C calls. The B->A and C->A subflows of the call can share 125 resources using existing RSVP sharing mechanisms, but only if 126 they use the same destination IP addresses and ports. However, 127 there is no way in RSVP today to share the resources between the 128 A->B and A->C subflows of the call since by definition the RSVP 129 reservations for these subflows must have different IP addresses 130 in the SESSION objects. 132 o Voice Shared Line: 133 A single number that rings multiple endpoints (which may be 134 geographically diverse), such as phone lines on a manager's desk 135 and their assistant. A VoIP system that models these calls as 136 multiple P2P unicast pre-ring reservations would result in 137 significantly over-counting bandwidth on shared links, since 138 today unicast reservations to different endpoints cannot share 139 bandwidth. 141 o Symmetric NAT: 142 RSVP permits sharing of resources between multiple flows 143 addressed to the same destination D, even from different senders 144 S1 and S2. However, if D is behind a NAT operating in symmetric 145 mode [RFC5389], it is possible that the destination port of the 146 flows S1->D and S2->D may be different outside the NAT. In this 147 case, these flows cannot share resources using RSVP today, since 148 the SESSION objects for these two flows outside the NAT would 149 have different ports. 151 Section 5 of this document defines the extended ASSOCIATION objects 152 which can be used in the context of Transport Profile of 153 Multiprotocol Label Switching (MPLS-TP). Although, the scope of the 154 extended ASSOCIATION objects is not limited to MPLS-TP. 156 1.1. Conventions Used In This Document 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119]. 162 2. Background 164 This section reviews the definition of LSP association in the 165 contexts of end-to-end and segment recovery as defined in [RFC4872] 166 and [RFC4873]. This section merely reiterates what has been defined, 167 if differences exist between this text and [RFC4872] or [RFC4873], 168 the earlier RFCs provide the authoritative text. 170 2.1. LSP Association 172 [RFC4872] introduces the concept and mechanisms to support the 173 association of one LSP to another LSP across different RSVP-TE 174 sessions. Such association is enabled via the introduction of the 175 ASSOCIATION object. The ASSOCIATION object is defined in Section 16 176 of [RFC4872]. It is explicitly defined as having both general 177 application and specific use within the context of recovery. End-to- 178 end recovery usage is defined in [RFC4872] and is covered in Section 179 2.2. Segment recovery usage is defined in [RFC4873] and is covered 180 in Section 2.3. Resource sharing LSP association is also defined in 181 [RFC4873], while strictly speaking such association is beyond the 182 scope of this document, for completeness it is covered in Section 183 2.4. The remainder of this section covers generic usage of the 184 ASSOCIATION object. 186 In general, LSP association using the ASSOCIATION object can take 187 place based on the values carried in the ASSOCIATION object. This 188 means that association between LSPs can take place independent from 189 and across different sessions. This is a significant enhancement 190 from the association of LSPs that is possible in base MPLS [RFC3209] 191 and GMPLS [RFC3473]. 193 When using ASSOCIATION object, LSP association is always initiated by 194 an upstream node that inserts appropriate ASSOCIATION objects in the 195 Path message of LSPs that are to be associated. Downstream nodes 196 then correlate LSPs based on received ASSOCIATION objects. Multiple 197 types of LSP association is supported by the ASSOCIATION object, and 198 downstream correlation is made based on the type. 200 [RFC4872] defines C-Types 1 and 2 of the ASSOCIATION object. Both 201 objects have essentially the same semantics, only differing in the 202 type of address carried (IPv4 and IPv6). The defined objects carry 203 multiple fields. The fields, taken together, enable the 204 identification of which LSPs are association with one another. The 205 [RFC4872] defined fields are: 207 o Association Type: 208 This field identifies the usage, or application, of the 209 association object. The currently defined values are Recovery 210 [RFC4872] and Resource Sharing [RFC4873]. This field also scopes 211 the interpretation of the object. In other words, the type field 212 is included when matching LSPs (i.e., the type fields must 213 match), and the way associations are identified may be type 214 dependent. 216 o Association Source: 217 This field is used to provide global scope (within the address 218 space) to the identified association. There are no specific 219 rules in the general case for which address should be used by a 220 node creating an ASSOCIATION object beyond that the address is 221 "associated to the node that originated the association", see 222 [RFC4872]. 224 o Association ID: 225 This field provides an "identifier" that further scopes an 226 association. Again, this field is combined with the other 227 ASSOCIATION object fields to support identification of associated 228 LSPs. The generic definition does not provide any specific rules 229 on how matching is to be done, so such rules are governed by the 230 Association Type. Note that the definition permits the 231 association of an arbitrary number of LSPs. 233 As defined, the ASSOCIATION object may only be carried in a Path 234 message, so LSP association takes place based on Path state. The 235 definition permits one or more objects to be present. The support 236 for multiple objects enables an LSP to be associated with other LSPs 237 in more than one way at a time. For example, an LSP may carry one 238 ASSOCIATION object to associate the LSP with another LSP for end-to- 239 end recovery, and at the same time carry a second ASSOCIATION object 240 to associate the LSP with another LSP for segment recovery, and at 241 the same time carry a third ASSOCIATION object to associate the LSP 242 with yet another LSP for resource sharing. 244 2.2. End-to-End Recovery LSP Association 246 The association of LSPs in support of end-to-end LSP recovery is 247 defined in Section 16.2 of [RFC4872]. There are also several 248 additional related conformance statements (i.e., use of [RFC2119] 249 defined key words) in Sections 7.3, 8.3, 9.3, 11.1. When analyzing 250 the definition, as with any Standards Track RFC, it is critical to 251 note and differentiate which statements are made using [RFC2119] 252 defined key words, which relate to conformance, and which statements 253 are made without such key words, which are only informative in 254 nature. 256 As defined in Section 16.2, end-to-end recovery related LSP 257 association may take place in two distinct forms: 259 a. Between multiple (one or more) working LSPs and a single shared 260 (associated) recovery LSP. This form essentially matches the 261 shared 1:N (N >= 1) recovery type described in the other 262 sections of [RFC4872]. 264 b. Between a single working LSP and multiple (one or more) 265 recovery LSPs. This form essentially matches all other 266 recovery types described in [RFC4872]. 268 Both forms share the same Association Type (Recovery) and the same 269 Association Source (the working LSP's tunnel sender address). They 270 also share the same definition of the Association ID, which is 271 (quoting [RFC4872]): 273 "The Association ID MUST be set to the LSP ID of the LSP being 274 protected by this LSP or the LSP protecting this LSP. If unknown, 275 this value is set to its own signaled LSP ID value (default). 276 Also, the value of the Association ID MAY change during the 277 lifetime of the LSP." 279 The interpretation of the above is fairly straightforward. The 280 Association ID carries one of 3 values: 281 - The LSP ID of the LSP being protected. 282 - The LSP ID of the LSP protecting an LSP. 283 - In the case where the matching LSP is not yet known (i.e., 284 initiated), the LSP ID value of the LSP itself. 286 The text also explicitly allows for changing the Association ID 287 during the lifetime of an LSP. But this is only an option, and is 288 neither required (i.e., "MUST") nor recommended (i.e., "SHOULD"). It 289 should be noted that the document does not describe when such a 290 change should be initiated, or the procedures for such a change. 291 Clearly care needs to be taken when changing the Association ID to 292 ensure that the old association is not lost during the transition to 293 a new association. 295 The text does not preclude, and it is therefore assumed, that one or 296 more ASSOCIATION objects may also be added to an LSP that was 297 originated without any ASSOCIATION objects. Again this is a case 298 that is not explicitly discussed in [RFC4872]. 300 From the above, this means that the following combinations may occur: 302 Case 1. When the ASSOCIATION object of the LSP being protected is 303 initialized before the ASSOCIATION objects of any recovery 304 LSPs are initialized, the Association ID in the LSP being 305 protected and any recovery LSPs will carry the same value 306 and this value will be the LSP ID value of the LSP being 307 protected. 309 Case 2. When the ASSOCIATION object of a recovery LSP is 310 initialized before the ASSOCIATION object of any protected 311 LSP is initialized, the Association ID in the recovery LSP 312 and any LSPs being protected by that LSP will carry the 313 same value and this value will be the LSP ID value of the 314 recovery LSP. 316 Case 3. When the ASSOCIATION objects of both the LSP being 317 protected and the recovery LSP are concurrently 318 initialized, the value of the Association ID carried in 319 the LSP being protected is the LSP ID value of the 320 recovery LSP, and the value of the Association ID carried 321 in the recovery LSP is the LSP ID value of the LSP being 322 protected. As this case can only be applied to LSPs with 323 matching tunnel sender addresses, the scope of this case 324 is limited to end-to-end recovery. Note that this is 325 implicit in [RFC4872] as its scope is limited to end-to- 326 end recovery. 328 In practical terms, case 2 will only occur when using the shared 1:N 329 (N >= 1) end-to-end recovery type and case 1 will occur with all 330 other end-to-end recovery types. Case 3 is allowed, and it is 331 subject to interpretation how often it will occur. Some believe that 332 this case is the common case and, furthermore, that working and 333 recovery LSPs will often first be initiated without any ASSOCIATION 334 objects and then case 3 objects will be added once the LSPs are 335 established. Others believe that case 3 will rarely if ever occur. 336 Such perspectives have little impact on interoperability as a 337 [RFC4872] compliant implementation needs to properly handle (identify 338 associations for) all three cases. 340 It is important to note that Section 16.2 of [RFC4872] provides no 341 further requirements on how or when the Association ID value is to be 342 selected. The other sections of the document do provide further 343 narrative and 3 additional requirements. In general, the narrative 344 highlights case 3 identified above but does not preclude the other 345 cases. The 3 additional requirements are, by [RFC4872] Section 346 number: 348 o Section 7.3 -- "The Association ID MUST be set by default to the 349 LSP ID of the protected LSP corresponding to N = 1." 351 When considering this statement together with the 3 cases 352 enumerated above, it can be seen that this statement clarifies 353 which LSP ID value should be used when a single shared protection 354 LSP is established simultaneously with (case 3), or after (case 355 2), more than one LSP to be protected. 357 o Section 8.3 -- "Secondary protecting LSPs are signaled by setting 358 in the new PROTECTION object the S bit and the P bit to 1, and in 359 the ASSOCIATION object, the Association ID to the associated 360 primary working LSP ID, which MUST be known before signaling of 361 the secondary LSP." 363 This requirement clarifies that the Rerouting without Extra- 364 Traffic type of recovery is required to follow either case 1 or 365 3, but not 2, as enumerated above. 367 o Section 9.3 -- "Secondary protecting LSPs are signaled by setting 368 in the new PROTECTION object the S bit and the P bit to 1, and in 369 the ASSOCIATION object, the Association ID to the associated 370 primary working LSP ID, which MUST be known before signaling of 371 the secondary LSP." 373 This requirement clarifies that the Shared-Mesh Restoration type 374 of recovery is required to follow either case 1 or 3, but not 2, 375 as enumerated above. 377 o Section 11.1 -- "In both cases, the Association ID of the 378 ASSOCIATION object MUST be set to the LSP ID value of the 379 signaled LSP." 381 This requirement clarifies that when using the LSP Rerouting type 382 of recovery is required to follow either case 1 or 3, but not 2, 383 as enumerated above. 385 2.3. Segment Recovery LSP Association 387 GMPLS segment recovery is defined in [RFC4873]. Segment recovery 388 reuses the LSP association mechanisms, including the Association Type 389 field value, defined in [RFC4872]. The primary text to this effect 390 in [RFC4873] is: 392 3.2.1. Recovery Type Processing 394 Recovery type processing procedures are the same as those 395 defined in [RFC4872], but processing and identification occur 396 with respect to segment recovery LSPs. Note that this means 397 that multiple ASSOCIATION objects of type recovery may be 398 present on an LSP. 400 This statement means that case 2 as enumerated above is to be 401 followed and furthermore that Association Source is set to the tunnel 402 sender address of the segment recovery LSPs. The explicit exclusion 403 of case 3 is not listed as its non-applicability was considered 404 obvious to the informed reader. (Perhaps having this exclusion 405 explicitly identified would have obviated the need for this 406 document.) 408 2.4. Resource Sharing LSP Association 410 Section 3.2.2 of [RFC4873] defines an additional type of LSP 411 association which is used for "Resource Sharing". Resource sharing 412 enables the sharing of resources across LSPs with different SESSION 413 objects. Without this object only sharing across LSPs with a shared 414 SESSION object was possible, see [RFC3209]. 416 Resource sharing is indicated using a new Association Type value. As 417 the Association Type field value is not the same as is used in 418 Recovery LSP association, the semantics used for the association of 419 LSPs using an ASSOCIATION object containing the new type differs from 420 Recovery LSP association. 422 Section 3.2.2 of [RFC4873] states the following rules for the 423 construction of an ASSOCIATION object in support of resource sharing 424 LSP association: 426 o The Association Type value is set to "Resource Sharing". 428 o Association Source is set to the originating node's router 429 address. 431 o The Association ID is set to a value that uniquely identifies the 432 set of LSPs to be associated. 434 The setting of the Association ID value to the working LSP's LSP 435 ID value is mentioned, but using the "MAY" key word. Per 436 [RFC2119], this translates to the use of LSP ID value as being 437 completely optional and that the choice of Association ID is 438 truly up to the originating node. 440 Additionally, the identical ASSOCIATION object is used for all LSPs 441 that should be associated using Resource Sharing. This differs from 442 recovery LSP association where it is possible for the LSPs to carry 443 different Association ID fields and still be associated (see case 3 444 in Section 2.2). 446 3. Association of GMPLS Recovery LSPs 448 The previous section reviews the construction of an ASSOCIATION 449 object, including the selection of the value used in the Association 450 ID field, as defined in [RFC4872] and [RFC4873]. This section reviews 451 how a downstream receiver identifies that one LSP is associated 452 within another LSP based on ASSOCIATION objects. Note that this 453 section in no way modifies the normative definitions of end-to-end 454 and segment recovery, see [RFC4872] or [RFC4873]. 456 As the ASSOCIATION object is only carried in Path messages, such 457 identification only takes place based on Path state. In order to 458 support the identification of the recovery type association between 459 LSPs, a downstream receiver needs to be able to handle all three 460 cases identified in Section 2.2. Cases 1 and 2 are simple as the 461 associated LSPs will carry the identical ASSOCIATION object. This is 462 also always true for resource sharing type LSP association, see 463 Section 2.4. Case 3 is more complicated as it is possible for the 464 LSPs to carry different Association ID fields and still be 465 associated. The receiver also needs to allow for changes in the set 466 of ASSOCIATION objects included in an LSP. 468 Based on the [RFC4872] and [RFC4873] definitions related to the 469 ASSOCIATION object, the following behavior can be followed to ensure 470 that a receiver always properly identifies the association between 471 LSPs: 473 o Covering cases 1 and 2 and resource sharing type LSP association: 475 For ASSOCIATION objects with the Association Type field values of 476 "Recovery" (1) and "Resource Sharing" (2), the association 477 between LSPs is identified by comparing all fields of each of the 478 ASSOCIATION objects carried in the Path messages associated with 479 each LSP. An association is deemed to exist when the same values 480 are carried in all fields of an ASSOCIATION object carried in 481 each LSP's Path message. As more than one association may exist 482 (e.g., in support of different association types or end-to-end 483 and segment recovery), all carried ASSOCIATION objects need to be 484 examined. 486 o Covering case 3: 488 Any ASSOCIATION object with the Association Type field value of 489 "Recovery" (1) that does not yield an association in the prior 490 comparison needs to be checked to see if a case 3 association is 491 indicated. As this case only applies to end-to-end recovery, the 492 first step is to locate any other LSPs with the identical SESSION 493 object fields and the identical tunnel sender address fields as 494 the LSP carrying the ASSOCIATION object. If such LSPs exist, a 495 case 3 association is identified by comparing the value of the 496 Association ID field with the LSP ID field of the other LSP. If 497 the values are identical, then an end-to-end recovery association 498 exists. As this behavior only applies to end-to-end recovery, 499 this check need only be performed at the egress. 501 No additional behavior is needed in order to support changes in the 502 set of ASSOCIATION objects included in an LSP, as long as the change 503 represents either a new association or a change in identifiers made 504 as described in Section 2.2. 506 4. Non-GMPLS Recovery Usage 508 While the ASSOCIATION object, [RFC4872], is defined in the context of 509 GMPLS Recovery, the object can have wider application. [RFC4872] 510 defines the object to be used to "associate LSPs with each other", 511 and then defines an Association Type field to identify the type of 512 association being identified. It also defines that the Association 513 Type field is to be considered when determining association, i.e., 514 there may be type-specific association rules. As discussed above, 515 this is the case for Recovery type association objects. The text 516 above, notably the text related to resource sharing types, can also 517 be used as the foundation for a generic method for associating LSPs 518 when there is no type-specific association defined. 520 The remainder of this section defines the general rules to be 521 followed when processing ASSOCIATION objects. Object usage in both 522 Path and Resv messages is discussed. The usage applies equally to 523 GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP RSVP sessions 524 [RFC2205], [RFC2207], [RFC3175] and [RFC4860]. As described below, 525 association is always done based on matching either Path state or 526 Resv state, but not Path state to Resv State. This section applies 527 to the ASSOCIATION objects defined in [RFC4872]. 529 4.1. Upstream Initiated Association 531 Upstream initiated association is represented in ASSOCIATION objects 532 carried in Path messages and can be used to associate RSVP Path state 533 across MPLS Tunnels / RSVP sessions. (Note, per [RFC3209] an MPLS 534 tunnel is represented by a RSVP SESSION object, and multiple LSPs may 535 be represented within a single tunnel.) Cross-session association 536 based on Path state is defined in [RFC4872]. This definition is 537 extended by this section, which defined generic association rules and 538 usage for non-LSP uses. This section does not modify processing 539 required to support [RFC4872] and [RFC4873], which is reviewed above 540 in Section 3. 542 4.1.1. Path Message Format 544 This section provides the Backus-Naur Form (BNF), see [RFC5511], for 545 Path messages containing ASSOCIATION objects. BNF is provided for 546 both MPLS and for non-LSP session usage. Unmodified RSVP message 547 formats and some optional objects are not listed. 549 The format for MPLS and GMPLS sessions is unmodified from [RFC4872], 550 and can be represented based on the BNF in [RFC3209] as: 552 ::= [ ] 553 554 555 [ ] 556 557 [ ] 558 [ ... ] 559 [ ... ] 560 562 The format for non-LSP sessions as based on the BNF in [RFC2205] is: 564 ::= [ ] 565 566 567 [ ... ] 568 [ ... ] 569 [ ] 571 In general, relative ordering of ASSOCIATION objects with respect to 572 each other as well as with respect to other objects is not 573 significant. Relative ordering of ASSOCIATION objects of the same 574 type SHOULD be preserved by transit nodes. Association type specific 575 ordering requirements MAY be defined in the future. 577 4.1.2. Path Message Processing 579 This section is based on the processing rules described in [RFC4872] 580 and [RFC4873], which is reviewed above. These procedures apply 581 equally to GMPLS LSPs, MPLS LSPs and non-LSP session state. 583 A node that wishes to allow downstream nodes to associate Path state 584 across RSVP sessions MUST include an ASSOCIATION object in the 585 outgoing Path messages corresponding to the RSVP sessions to be 586 associated. In the absence of Association Type-specific rules for 587 identifying association, the included ASSOCIATION objects MUST be 588 identical. When there is an Association Type-specific definition of 589 association rules, the definition SHOULD allow for association based 590 on identical ASSOCIATION objects. This document does not define any 591 Association Type-specific rules. (See Section 3 for a discussion of 592 an example of Association Type-specific rules which are derived from 593 [RFC4872].) 595 When creating an ASSOCIATION object, the originator MUST format the 596 object as defined in Section 16.1 of [RFC4872]. The originator MUST 597 set the Association Type field based on the type of association being 598 identified. The Association ID field MUST be set to a value that 599 uniquely identifies the sessions to be associated within the context 600 of the Association Source field. The Association Source field MUST 601 be set to a unique address assigned to the node originating the 602 association. 604 A downstream node can identify an upstream initiated association by 605 performing the following checks. When a node receives a Path message 606 it MUST check each ASSOCIATION object received in the Path message to 607 see if it contains an Association Type field value supported by the 608 node. For each ASSOCIATION object containing a supported association 609 type, the node MUST then check to see if the object matches an 610 ASSOCIATION object received in any other Path message. To perform 611 this matching, a node MUST examine the Path state of all other 612 sessions and compare the fields contained in the newly received 613 ASSOCIATION object with the fields contained in the Path state's 614 ASSOCIATION objects. An association is deemed to exist when the same 615 values are carried in all fields of the ASSOCIATION objects being 616 compared. Processing once an association is identified is type 617 specific and is outside the scope of this document. 619 Note that as more than one association may exist, all ASSOCIATION 620 objects carried in a received Path message which have supported 621 association types MUST be compared against all Path state. 623 Unless there are type-specific processing rules, downstream nodes 624 MUST forward all ASSOCIATION objects received in a Path message with 625 any corresponding outgoing Path messages. 627 4.2. Downstream Initiated Association 629 Downstream initiated association is represented in ASSOCIATION 630 objects carried in Resv messages and can be used to associate RSVP 631 Resv state across MPLS Tunnels / RSVP sessions. Cross-session 632 association based on Path state is defined in [RFC4872]. This section 633 defines cross-session association based on Resv state. This section 634 places no additional requirements on implementations supporting 635 [RFC4872] and [RFC4873]. 637 4.2.1. Resv Message Format 639 This section provides the Backus-Naur Form (BNF), see [RFC5511], for 640 Resv messages containing ASSOCIATION objects. BNF is provided for 641 both MPLS and for non-LSP session usage. Unmodified RSVP message 642 formats and some optional objects are not listed. 644 The format for MPLS, GMPLS and non-LSP sessions are identical, and is 645 represented based on the BNF in [RFC2205] and [RFC3209]: 647 ::= [ ] 648 649 650 [ ] [ ] 651 [ ... ] 652 [ ... ] 653