idnits 2.17.1 draft-ietf-ccamp-assoc-info-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 25, 2011) is 4566 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Lou Berger (LabN) 2 Category: Informational 3 Expiration Date: April 25, 2012 5 October 25, 2011 7 Usage of The RSVP Association Object 9 draft-ietf-ccamp-assoc-info-03.txt 11 Abstract 13 The RSVP ASSOCIATION object was defined in the context of GMPLS 14 (Generalized Multi-Protocol Label Switching) controlled label 15 switched paths (LSPs). In this context, the object is used to 16 associate recovery LSPs with the LSP they are protecting. This 17 document reviews how association is to be provided in the context 18 of GMPLS recovery. No new procedures or mechanisms are 19 defined by this document and it is strictly informative in nature. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 This Internet-Draft will expire on April 25, 2012 44 Copyright and License Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1 Introduction ........................................... 3 62 2 Background ............................................. 3 63 2.1 LSP Association ........................................ 3 64 2.2 End-to-End Recovery LSP Association .................... 5 65 2.3 Segment Recovery LSP Association ....................... 8 66 2.4 Resource Sharing LSP Association ....................... 8 67 3 Association of GMPLS Recovery LSPs ..................... 9 68 4 Security Considerations ................................ 10 69 5 IANA Considerations .................................... 10 70 6 Acknowledgments ........................................ 10 71 7 References ............................................. 10 72 7.1 Normative References ................................... 10 73 7.2 Informative References ................................. 11 74 8 Author's Addresses ..................................... 11 76 1. Introduction 78 End-to-end and segment recovery are defined for GMPLS (Generalized 79 Multi-Protocol Label Switching) controlled label switched paths 80 (LSPs) in [RFC4872] and [RFC4873] respectively. Both definitions use 81 the ASSOCIATION object to associate recovery LSPs with the LSP they 82 are protecting. This document provides additional narrative on how 83 such associations are to be identified. This document does not 84 define any new procedures or mechanisms and is strictly informative 85 in nature. 87 It may not be immediately obvious to the informed reader why this 88 document is necessary, however questions were repeatedly raised in 89 the Common Control and Measurement Plane (CCAMP) working group on the 90 proper interpretation of the ASSOCIATION object in the context of 91 end-to-end and segment recovery, and the working group agreed that 92 this document should be produced in order to close the matter. This 93 document formalizes the explanation provided in an e-mail to the 94 working group authored by Adrian Farrel, see [AF-EMAIL]. This 95 document in no way modifies the normative definitions of end-to-end 96 and segment recovery, see [RFC4872] or [RFC4873]. 98 2. Background 100 This section reviews the definition of LSP association in the 101 contexts of end-to-end and segment recovery as defined in [RFC4872] 102 and [RFC4873]. This section merely reiterates what has been defined, 103 if differences exist between this text and [RFC4872] or [RFC4873], 104 the earlier RFCs provide the authoritative text. 106 2.1. LSP Association 108 [RFC4872] introduces the concept and mechanisms to support the 109 association of one LSP to another LSP across different RSVP-TE 110 sessions. Such association is enabled via the introduction of the 111 ASSOCIATION object. The ASSOCIATION object is defined in Section 16 112 of [RFC4872]. It is explicitly defined as having both general 113 application and specific use within the context of recovery. End-to- 114 end recovery usage is defined in [RFC4872] and is covered in Section 115 2.2. Segment recovery usage is defined in [RFC4873] and is covered 116 in Section 2.3. Resource sharing LSP association is also defined in 117 [RFC4873], while strictly speaking such association is beyond the 118 scope of this document, for completeness it is covered in Section 119 2.4. The remainder of this section covers generic usage of the 120 ASSOCIATION object. 122 In general, LSP association using the ASSOCIATION object can take 123 place based on the values carried in the ASSOCIATION object. This 124 means that association between LSPs can take place independent from 125 and across different sessions. This is a significant enhancement 126 from the association of LSPs that is possible in base MPLS [RFC3209] 127 and GMPLS [RFC3473]. 129 When using ASSOCIATION object, LSP association is always initiated by 130 an upstream node that inserts appropriate ASSOCIATION objects in the 131 Path message of LSPs that are to be associated. Downstream nodes 132 then correlate LSPs based on received ASSOCIATION objects. Multiple 133 types of LSP association is supported by the ASSOCIATION object, and 134 downstream correlation is made based on the type. 136 [RFC4872] defines C-Types 1 and 2 of the ASSOCIATION object. Both 137 objects have essentially the same semantics, only differing in the 138 type of address carried (IPv4 and IPv6). The defined objects carry 139 multiple fields. The fields, taken together, enable the 140 identification of which LSPs are association with one another. The 141 [RFC4872] defined fields are: 143 o Association Type: 144 This field identifies the usage, or application, of the 145 association object. The currently defined values are Recovery 146 [RFC4872] and Resource Sharing [RFC4873]. This field also scopes 147 the interpretation of the object. In other words, the type field 148 is included when matching LSPs (i.e., the type fields must 149 match), and the way associations are identified may be type 150 dependent. 152 o Association Source: 153 This field is used to provide global scope (within the address 154 space) to the identified association. There are no specific 155 rules in the general case for which address should be used by a 156 node creating an ASSOCIATION object beyond that the address is 157 "associated to the node that originated the association", see 158 [RFC4872]. 160 o Association ID: 161 This field provides an "identifier" that further scopes an 162 association. Again, this field is combined with the other 163 ASSOCIATION object fields to support identification of associated 164 LSPs. The generic definition does not provide any specific rules 165 on how matching is to be done, so such rules are governed by the 166 Association Type. Note that the definition permits the 167 association of an arbitrary number of LSPs. 169 As defined, the ASSOCIATION object may only be carried in a Path 170 message, so LSP association takes place based on Path state. The 171 definition permits one or more objects to be present. The support 172 for multiple objects enables an LSP to be associated with other LSPs 173 in more than one way at a time. For example, an LSP may carry one 174 ASSOCIATION object to associate the LSP with another LSP for end-to- 175 end recovery, and at the same time carry a second ASSOCIATION object 176 to associate the LSP with another LSP for segment recovery, and at 177 the same time carry a third ASSOCIATION object to associate the LSP 178 with yet another LSP for resource sharing. 180 2.2. End-to-End Recovery LSP Association 182 The association of LSPs in support of end-to-end LSP recovery is 183 defined in Section 16.2 of [RFC4872]. There are also several 184 additional related conformance statements (i.e., use of [RFC2119] 185 defined key words) in Sections 7.3, 8.3, 9.3, 11.1. When analyzing 186 the definition, as with any Standards Track RFC, it is critical to 187 note and differentiate which statements are made using [RFC2119] 188 defined key words, which relate to conformance, and which statements 189 are made without such key words, which are only informative in 190 nature. 192 As defined in Section 16.2, end-to-end recovery related LSP 193 association may take place in two distinct forms: 195 a. Between multiple (one or more) working LSPs and a single shared 196 (associated) recovery LSP. This form essentially matches the 197 shared 1:N (N >= 1) recovery type described in the other 198 sections of [RFC4872]. 200 b. Between a single working LSP and multiple (one or more) 201 recovery LSPs. This form essentially matches all other 202 recovery types described in [RFC4872]. 204 Both forms share the same Association Type (Recovery) and the same 205 Association Source (the working LSP's tunnel sender address). They 206 also share the same definition of the Association ID, which is 207 (quoting [RFC4872]): 209 "The Association ID MUST be set to the LSP ID of the LSP being 210 protected by this LSP or the LSP protecting this LSP. If unknown, 211 this value is set to its own signaled LSP ID value (default). 212 Also, the value of the Association ID MAY change during the 213 lifetime of the LSP." 215 The interpretation of the above is fairly straightforward. The 216 Association ID carries one of 3 values: 217 - The LSP ID of the LSP being protected. 218 - The LSP ID of the LSP protecting an LSP. 219 - In the case where the matching LSP is not yet known (i.e., 220 initiated), the LSP ID value of the LSP itself. 222 The text also explicitly allows for changing the Association ID 223 during the lifetime of an LSP. But this is only an option, and is 224 neither required (i.e., "MUST") nor recommended (i.e., "SHOULD"). It 225 should be noted that the document does not describe when such a 226 change should be initiated, or the procedures for such a change. 227 Clearly care needs to be taken when changing the Association ID to 228 ensure that the old association is not lost during the transition to 229 a new association. 231 The text does not preclude, and it is therefore assumed, that one or 232 more ASSOCIATION objects may also be added to an LSP that was 233 originated without any ASSOCIATION objects. Again this is a case 234 that is not explicitly discussed in [RFC4872]. 236 From the above, this means that the following combinations may occur: 238 Case 1. When the ASSOCIATION object of the LSP being protected is 239 initialized before the ASSOCIATION objects of any recovery 240 LSPs are initialized, the Association ID in the LSP being 241 protected and any recovery LSPs will carry the same value 242 and this value will be the LSP ID value of the LSP being 243 protected. 245 Case 2. When the ASSOCIATION object of a recovery LSP is 246 initialized before the ASSOCIATION object of any protected 247 LSP is initialized, the Association ID in the recovery LSP 248 and any LSPs being protected by that LSP will carry the 249 same value and this value will be the LSP ID value of the 250 recovery LSP. 252 Case 3. When the ASSOCIATION objects of both the LSP being 253 protected and the recovery LSP are concurrently 254 initialized, the value of the Association ID carried in 255 the LSP being protected is the LSP ID value of the 256 recovery LSP, and the value of the Association ID carried 257 in the recovery LSP is the LSP ID value of the LSP being 258 protected. As this case can only be applied to LSPs with 259 matching tunnel sender addresses, the scope of this case 260 is limited to end-to-end recovery. Note that this is 261 implicit in [RFC4872] as its scope is limited to end-to- 262 end recovery. 264 In practical terms, case 2 will only occur when using the shared 1:N 265 (N >= 1) end-to-end recovery type and case 1 will occur with all 266 other end-to-end recovery types. Case 3 is allowed, and it is 267 subject to interpretation how often it will occur. Some believe that 268 this case is the common case and, furthermore, that working and 269 recovery LSPs will often first be initiated without any ASSOCIATION 270 objects and then case 3 objects will be added once the LSPs are 271 established. Others believe that case 3 will rarely if ever occur. 272 Such perspectives have little impact on interoperability as a 273 [RFC4872] compliant implementation needs to properly handle (identify 274 associations for) all three cases. 276 It is important to note that Section 16.2 of [RFC4872] provides no 277 further requirements on how or when the Association ID value is to be 278 selected. The other sections of the document do provide further 279 narrative and 3 additional requirements. In general, the narrative 280 highlights case 3 identified above but does not preclude the other 281 cases. The 3 additional requirements are, by [RFC4872] Section 282 number: 284 o Section 7.3 -- "The Association ID MUST be set by default to the 285 LSP ID of the protected LSP corresponding to N = 1." 287 When considering this statement together with the 3 cases 288 enumerated above, it can be seen that this statement clarifies 289 which LSP ID value should be used when a single shared protection 290 LSP is established simultaneously with (case 3), or after (case 291 2), and more than one LSP to be protected. 293 o Section 8.3 -- "Secondary protecting LSPs are signaled by setting 294 in the new PROTECTION object the S bit and the P bit to 1, and in 295 the ASSOCIATION object, the Association ID to the associated 296 primary working LSP ID, which MUST be known before signaling of 297 the secondary LSP." 299 This requirement clarifies that when using the Rerouting without 300 Extra-Traffic type of recovery it is required to follow either 301 case 1 or 3, but not 2, as enumerated above. 303 o Section 9.3 -- "Secondary protecting LSPs are signaled by setting 304 in the new PROTECTION object the S bit and the P bit to 1, and in 305 the ASSOCIATION object, the Association ID to the associated 306 primary working LSP ID, which MUST be known before signaling of 307 the secondary LSP." 309 This requirement clarifies that when using the Shared-Mesh 310 Restoration type of recovery it is required to follow either case 311 1 or 3, but not 2, as enumerated above. 313 o Section 11.1 -- "In both cases, the Association ID of the 314 ASSOCIATION object MUST be set to the LSP ID value of the 315 signaled LSP." 317 This requirement clarifies that when using the LSP Rerouting type 318 of recovery it is required to follow either case 1 or 3, but not 319 2, as enumerated above. 321 2.3. Segment Recovery LSP Association 323 GMPLS segment recovery is defined in [RFC4873]. Segment recovery 324 reuses the LSP association mechanisms, including the Association Type 325 field value, defined in [RFC4872]. The primary text to this effect 326 in [RFC4873] is: 328 3.2.1. Recovery Type Processing 330 Recovery type processing procedures are the same as those 331 defined in [RFC4872], but processing and identification occur 332 with respect to segment recovery LSPs. Note that this means 333 that multiple ASSOCIATION objects of type recovery may be 334 present on an LSP. 336 This statement means that case 2 as enumerated above is to be 337 followed and furthermore that Association Source is set to the tunnel 338 sender address of the segment recovery LSPs. The explicit exclusion 339 of case 3 is not listed as its non-applicability was considered 340 obvious to the informed reader. (Perhaps having this exclusion 341 explicitly identified would have obviated the need for this 342 document.) 344 2.4. Resource Sharing LSP Association 346 Section 3.2.2 of [RFC4873] defines an additional type of LSP 347 association which is used for "Resource Sharing". Resource sharing 348 enables the sharing of resources across LSPs with different SESSION 349 objects. Without this object only sharing across LSPs with a shared 350 SESSION object was possible, see [RFC3209]. 352 Resource sharing is indicated using a new Association Type value. As 353 the Association Type field value is not the same as is used in 354 Recovery LSP association, the semantics used for the association of 355 LSPs using an ASSOCIATION object containing the new type differs from 356 Recovery LSP association. 358 Section 3.2.2 of [RFC4873] states the following rules for the 359 construction of an ASSOCIATION object in support of resource sharing 360 LSP association: 362 o The Association Type value is set to "Resource Sharing". 364 o Association Source is set to the originating node's router 365 address. 367 o The Association ID is set to a value that uniquely identifies the 368 set of LSPs to be associated. 370 The setting of the Association ID value to the working LSP's LSP 371 ID value is mentioned, but using the "MAY" key word. Per 372 [RFC2119], this translates to the use of LSP ID value as being 373 completely optional and that the choice of Association ID is 374 truly up to the originating node. 376 Additionally, the identical ASSOCIATION object is used for all LSPs 377 that should be associated using Resource Sharing. This differs from 378 recovery LSP association where it is possible for the LSPs to carry 379 different Association ID fields and still be associated (see case 3 380 in Section 2.2). 382 3. Association of GMPLS Recovery LSPs 384 The previous section reviews the construction of an ASSOCIATION 385 object, including the selection of the value used in the Association 386 ID field, as defined in [RFC4872] and [RFC4873]. This section reviews 387 how a downstream receiver identifies that one LSP is associated 388 within another LSP based on ASSOCIATION objects. Note that this 389 section in no way modifies the normative definitions of end-to-end 390 and segment recovery, see [RFC4872] or [RFC4873]. 392 As the ASSOCIATION object is only carried in Path messages, such 393 identification only takes place based on Path state. In order to 394 support the identification of the recovery type association between 395 LSPs, a downstream receiver needs to be able to handle all three 396 cases identified in Section 2.2. Cases 1 and 2 are simple as the 397 associated LSPs will carry the identical ASSOCIATION object. This is 398 also always true for resource sharing type LSP association, see 399 Section 2.4. Case 3 is more complicated as it is possible for the 400 LSPs to carry different Association ID fields and still be 401 associated. The receiver also needs to allow for changes in the set 402 of ASSOCIATION objects included in an LSP. 404 Based on the [RFC4872] and [RFC4873] definitions related to the 405 ASSOCIATION object, the following behavior can be followed to ensure 406 that a receiver always properly identifies the association between 407 LSPs: 409 o Covering cases 1 and 2 and resource sharing type LSP association: 411 For ASSOCIATION objects with the Association Type field values of 412 "Recovery" (1) and "Resource Sharing" (2), the association 413 between LSPs is identified by comparing all fields of each of the 414 ASSOCIATION objects carried in the Path messages associated with 415 each LSP. An association is deemed to exist when the same values 416 are carried in all fields of an ASSOCIATION object carried in 417 each LSP's Path message. As more than one association may exist 418 (e.g., in support of different association types or end-to-end 419 and segment recovery), all carried ASSOCIATION objects need to be 420 examined. 422 o Covering case 3: 424 Any ASSOCIATION object with the Association Type field value of 425 "Recovery" (1) that does not yield an association in the prior 426 comparison needs to be checked to see if a case 3 association is 427 indicated. As this case only applies to end-to-end recovery, the 428 first step is to locate any other LSPs with the identical SESSION 429 object fields and the identical tunnel sender address fields as 430 the LSP carrying the ASSOCIATION object. If such LSPs exist, a 431 case 3 association is identified by comparing the value of the 432 Association ID field with the LSP ID field of the other LSP. If 433 the values are identical, then an end-to-end recovery association 434 exists. As this behavior only applies to end-to-end recovery, 435 this check need only be performed at the egress. 437 No additional behavior is needed in order to support changes in the 438 set of ASSOCIATION objects included in an LSP, as long as the change 439 represents either a new association or a change in identifiers made 440 as described in Section 2.2. 442 4. Security Considerations 444 This document reviews procedures defined in [RFC4872] and [RFC4873] 445 and does not define any new procedures. As such, no new security 446 considerations are introduced in this document. 448 5. IANA Considerations 450 There are no new IANA considerations introduced by this document. 452 6. Acknowledgments 454 This document formalizes the explanation provided in an e-mail to the 455 working group authored by Adrian Farrel, see [AF-EMAIL]. This 456 document was written in response to questions raised in the CCAMP 457 working group by Nic Neate . Valuable 458 comments and input was also received from Dimitri Papadimitriou, 459 Francois Le Faucheur and Ashok Narayanan. 461 7. References 463 7.1. Normative References 465 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 466 Requirement Levels", BCP 14, RFC 2119, March 1997. 468 [RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE 469 Extensions in Support of End-to-End Generalized Multi- 470 Protocol Label Switching (GMPLS) Recovery", RFC 4872, 471 May 2007. 473 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A., 474 "GMPLS Segment Recovery", RFC 4873, May 2007. 476 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 477 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 478 Tunnels", RFC 3209, December 2001. 480 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 481 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 482 Engineering (RSVP-TE) Extensions", RFC 3473, January 483 2003. 485 7.2. Informative References 487 [AF-EMAIL] Farrel, A. "Re: Clearing up your misunderstanding of 488 the Association ID", CCAMP working group mailing list, 489 http://www.ietf.org/mail-archive/web/ccamp/current/msg00644.html, 490 November 18, 2008. 492 8. Author's Addresses 494 Lou Berger 495 LabN Consulting, L.L.C. 496 Phone: +1-301-468-9228 497 Email: lberger@labn.net 499 Generated on: Tue, Oct 25, 2011 4:01:38 PM