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