idnits 2.17.1 draft-ietf-pce-association-group-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 : ---------------------------------------------------------------------------- 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 date (July 7, 2016) is 2842 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) == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-05 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-14 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group I. Minei 3 Internet-Draft Google, Inc. 4 Intended status: Standards Track E. Crabbe 5 Expires: January 8, 2017 6 S. Sivabalan 7 Cisco Systems, Inc. 8 H. Ananthakrishnan 9 Packet Design 10 X. Zhang 11 Huawei Technologies 12 Y. Tanaka 13 NTT Communications Corporation 14 July 7, 2016 16 PCEP Extensions for Establishing Relationships Between Sets of LSPs 17 draft-ietf-pce-association-group-01 19 Abstract 21 This document introduces a generic mechanism to create a grouping of 22 LSPs in the context of a PCE. This grouping can then be used to 23 define associations between sets of LSPs or between a set of LSPs and 24 a set of attributes (such as configuration parameters or behaviors), 25 and is equally applicable to the active and passive modes of a 26 stateful PCE as well as a stateless PCE. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 8, 2017. 50 Copyright Notice 52 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 3 70 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 71 3.2. Operation Overview . . . . . . . . . . . . . . . . . . . 4 72 4. ASSOCIATION Object . . . . . . . . . . . . . . . . . . . . . 4 73 4.1. Object Definition . . . . . . . . . . . . . . . . . . . . 4 74 4.1.1. Global Association Source TLV . . . . . . . . . . . . 6 75 4.1.2. Extended Association ID TLV . . . . . . . . . . . . . 6 76 4.2. Object Encoding in PCEP messages . . . . . . . . . . . . 7 77 4.3. Processing Rules . . . . . . . . . . . . . . . . . . . . 9 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 81 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 84 9.2. Informative References . . . . . . . . . . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 [RFC5440] describes the Path Computation Element Protocol PCEP. PCEP 90 enables the communication between a Path Computation Client (PCC) and 91 a Path Control Element (PCE), or between PCE and PCE, for the purpose 92 of computation of Multiprotocol Label Switching (MPLS) as well as 93 Generalzied MPLS (GMPLS) for Traffic Engineering Label Switched Path 94 (TE LSP) characteristics. 96 Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of 97 extensions to PCEP to enable stateful control of TE LSPs between and 98 across PCEP sessions in compliance with [RFC4657] and focuses on a 99 model where LSPs are configured on the PCC and control over them is 100 delegated to the PCE. The model of operation where LSPs are 101 initiated from the PCE is described in 102 [I-D.ietf-pce-pce-initiated-lsp]. 104 This document introduces a generic mechanism to create a grouping of 105 LSPs. This grouping can then be used to define associations between 106 sets of LSPs or between a set of LSPs and a set of attributes (such 107 as configuration parameters or behaviors), and is equally applicable 108 to the active and passive modes of a stateful PCE and a stateless 109 PCE. 111 2. Terminology 113 This document uses the following terms defined in [RFC5440]: PCC, 114 PCE, PCEP Peer. 116 The following term is defined in this document: 118 Association Timeout Interval: when a PCEP session is terminated, a 119 PCC waits for this time period before deleting associations created 120 by the PCEP peer. 122 3. Architectural Overview 124 3.1. Motivation 126 Stateful PCE provides the ability to update existing LSPs and to 127 instantiate new ones. To enable support for PCE-controlled make- 128 before-break and for protection, there is a need to define 129 associations between LSPs. For example, the association between the 130 original and the re-optimized path in the make-before break scenario, 131 or between the working and protection path in end-to-end protection. 132 Another use for LSP grouping is for applying a common set of 133 configuration parameters or behaviors to a set of LSPs. 135 For a stateless PCE, it might be useful to associate a path 136 computation request to an association group, thus enabling it to 137 associate a common set of configuration parameters or behaviors with 138 the request. 140 Rather than creating separate mechanisms for each use case, this 141 draft defines a generic mechanism that can be reused as needed. 143 3.2. Operation Overview 145 LSPs are associated with other LSPs with which they interact by 146 adding them to a common association group. Association groups as 147 defined in this document can be applied to LSPs originating at the 148 same head end or different head ends. For LSPs originating at the 149 same head end, the association can be initiated by either the PCC 150 (head end) or by a PCE. Only a stateful PCE can initiate an 151 association for LSPs originating at different head ends. For both 152 cases, the association is uniquely identified by the combination of 153 an association identifier and the address of the node that created 154 the association. 156 Multiple types of groups can exist, each with their own identifiers 157 space. The definition of the different association types and their 158 behaviors is outside the scope of this document. The establishment 159 and removal of the association relationship can be done on a per LSP 160 basis. An LSP may join multiple association groups, of different or 161 of the same type. 163 In the case of a stateless PCE, associations are created out of band, 164 and PCEP peers should be aware of the association and its 165 significance outside of the protocol. 167 Association groups can be created by both PCC and PCE. When a PCC's 168 PCEP session with a PCE terminates unexpectedly, the PCC cleans up 169 associations (as per the processing rules in this document). 171 4. ASSOCIATION Object 173 4.1. Object Definition 175 Creation of an association group and modifications to its membership 176 can be initiated by either the PCE or the PCC. Association groups 177 and their memberships are defined using the ASSOCIATION object for 178 stateful PCE. 180 ASSOCIATION Object-Class is to be assigned by IANA (TBD). 182 ASSOCIATION Object-Type is 1 for IPv4 and its format is shown in 183 Figure 1: 185 0 1 2 3 186 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Reserved | Flags |R| 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Association type | Association ID | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | IPv4 Association Source | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 // Optional TLVs // 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Figure 1: The IPv4 ASSOCIATION Object format 199 ASSOCIATION Object-Type is 2 for IPv6 and its format is shown in 200 Figure 2: 202 0 1 2 3 203 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Reserved | Flags |R| 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Association type | Association ID | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | | 210 | IPv6 Association Source | 211 | | 212 | | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 // Optional TLVs // 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Figure 2: The IPv6 ASSOCIATION Object format 219 Reserved: 16 bits - MUST be set to 0 and ignored upon receipt. 221 Flags: 16 bits - The following flags are currently defined: 223 R (Removal - 1 bit): when set, the requesting PCE peer requires the 224 removal of an LSP from the association group. 226 Association type: 16 bits - the association type (for example 227 protection). The association type will be defined in separate 228 documents. 230 Association ID: 16 bits - the identifier of the association group. 231 When combined with Type and Association Source, this value uniquely 232 identifies an association group. The value 0xffff and 0x0 are 233 reserved. The value 0xffff is used to indicate all association 234 groups. 236 Association Source: 4 or 16 bytes - An IPv4 or IPv6 address, which is 237 associated to the node that originated the association. 239 Optional TLVs: The optional TLVs follow the PCEP TLV format of 240 [RFC5440]. This document defines two optional TLVs. 242 4.1.1. Global Association Source TLV 244 The Global Association Source TLV is an optional TLV for use in the 245 Association Object. 247 0 1 2 3 248 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type | Length | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Global Association Source | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 3: The Global Association Source TLV format 257 Type: To be allocated by IANA 259 Length: Fixed value of 4 bytes 261 Global Association Source: as defined in [RFC6780] 263 4.1.2. Extended Association ID TLV 265 The Extended Association ID TLV is an optional TLV for use in the 266 Association Object. 268 0 1 2 3 269 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Type | Length | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 // Extended Association ID // 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Figure 4: The Extended Association ID TLV format 278 Type: To be allocated by IANA 280 Length: variable 282 Extended Association ID: as defined in [RFC6780] 284 4.2. Object Encoding in PCEP messages 286 The ASSOCIATION Object is OPTIONAL and MAY be carried in the Path 287 Computation Update (PCUpd), Path Computation Report (PCRpt) and Path 288 Computation Initiate (PCinit) messages. 290 When carried in PCRpt message, it is used to report the association 291 group membership information pertaining to a LSP to a stateful PCE. 292 It can also be used to remove an LSP from one or more association 293 groups by setting the R flag to 1. Unless, a PCE wants to delete an 294 association from an LSP, it does not need to carry the ASSOCIATION 295 object while updating other LSP attributes using the PCUpd message. 297 The PCRpt message is defined in [I-D.ietf-pce-stateful-pce] and 298 updated as below: 300 ::= 301 302 Where: 304 ::= [] 306 ::= [] 307 308 [] 309 310 Where: 312 ::= [] 313 When an LSP is delegated to a stateful PCE, the stateful PCE can 314 initiate a new association group for this LSP, or associate it with 315 one or more existing association groups. This is done by including 316 the ASSOCIATION Object in a PCUpd message or in a PCInit message. A 317 stateful PCE can also remove a delegated LSP from one or more 318 association groups by setting the R flag to 1. 320 The PCUpd message is defined in [I-D.ietf-pce-stateful-pce] and 321 updated as below: 323 ::= 324 325 Where: 326 ::= [] 328 ::= 329 330 [] 331 333 Where: ::= [] 335 The PCInitiate message is defined in [I-D.ietf-pce-pce-initiated-lsp] 336 and updated as below: 338 ::= 339 340 Where: 342 ::= 343 [] 345 ::= 346 (|) 348 ::= 349 350 351 352 [] 353 [] 355 Where: 356 ::= [] 358 In case of passive stateful or stateless PCE, the ASSOCIATION Object 359 is OPTIONAL and MAY be carried in the Path Computation Request 360 (PCReq) message. 362 When carried in a PCReq message, the ASSOCIATION Object is used to 363 associate the path computation request to an association group, the 364 association might be further informed via PCRpt message in case of 365 passive stateful PCE later or it might be created out of band in case 366 of stateless PCE. 368 The PCReq message is defined in [RFC5440] and updated in [I-D.ietf- 369 pce-stateful-pce], it is further updated below for association: 371 ::= 372 [] 373 375 Where: 376 ::= [] 377 ::= [] 379 ::= 380 381 [] 382 [] 383 [] 384 [] 385 [] 386 [[]] 387 [] 388 [] 390 Where: 391 ::= [] 393 Note that LSP object MAY be present for the passive stateful PCE. 395 4.3. Processing Rules 397 Both a PCC and a PCE can create one or more association groups for an 398 LSP. But a PCE peer cannot add new members for association group 399 created by another peer. If a PCE peer does not recognize the 400 ASSOCIATION object, it MUST return a PCErr message with Error-Type 401 "Unknown Object" as described in [RFC5440]. If a PCE peer is 402 unwilling or unable to process the ASSOCIATION object, it MUST return 403 a PCErr message with the Error-Type "Not supported object" and follow 404 the relevant procedures described in [RFC5440]. 406 The association timeout interval is as a PCC-local value that can be 407 operator-configured or computed by the PCC based on local policy and 408 is used in the context of cleaning up associations on session 409 failure. The association timeout must be set to a value no larger 410 than the state timeout interval (defined in 411 [I-D.ietf-pce-stateful-pce]) and larger than the delegation timeout 412 interval (defined in [I-D.ietf-pce-stateful-pce]. 414 When a PCC's PCEP session wih the PCE terminates unexpectedly, the 415 PCC MUST wait for the association timeout interval before cleaning up 416 the association. If this PCEP session can be re-established before 417 the association timeout interval time expires, no action is taken to 418 clean the association created by this PCE. During the time window of 419 the redelegation timeout interval and the association timeout 420 interval, the PCE, after re-establishing the session, can also ask 421 for redelegation following the procedure defined in 422 [I-D.ietf-pce-stateful-pce] and [I-D.ietf-pce-pce-initiated-lsp]. 423 When the association timeout interval timers expires, the PCC clears 424 all the associations which are not delegated to any PCEs. 426 Upon LSP delegation revocation, the PCC MAY clear the association 427 created by the related PCE, but in order to avoid traffic loss, it 428 can perform this in a make-before-break fashion, which is the same as 429 what is defined in Stateful pce [I-D.ietf-pce-stateful-pce] for 430 handling LSP state cleanup. 432 Error handling for situations for multiple PCE scenarios will be 433 included in future versions of this draft. 435 5. IANA Considerations 437 The "PCEP Parameters" registry contains a subregistry "PCEP Objects". 438 This document request IANA to allocate the values from this registry. 440 Object-Class Value Name Reference 442 TBD Association This document 443 Object-Type 444 1: IPv4 445 2: IPv6 447 This document defines the following new PCEP TLVs: 449 Value Meaning Reference 450 TBD Global Association Source This document 451 TBD Extended Association Id This document 453 This document requests IANA to create a subregistry of the "PCEP 454 Parameters" for the bits carried in the Flags field of the 455 ASSOCIATION object. The subregistry is called "ASSOCIATION Flags 456 Field". 458 The field contains 12 bits numbered from bit 0 as the most 459 significant bit. 461 Bit; Name: Description Reference 463 15 R: Removal This document 465 6. Security Considerations 467 The security considerations described in [I-D.ietf-pce-stateful-pce] 468 apply to the extensions described in this document. Additional 469 considerations related to a malicious PCE are introduced, as the PCE 470 may now create additional state on the PCC through the creation of 471 association groups. 473 7. Acknowledgements 475 We would like to thank Yuji Kamite and Joshua George for their 476 contributions to this document. Also Thank Venugopal Reddy and Cyril 477 Margaria for their useful comments. 479 8. Contributors 481 Dhruv Dhody 482 Huawei Technologies 483 Divyashree Techno Park, Whitefield 484 Bangalore, Karnataka 560037 485 India 486 Email: dhruv.ietf@gmail.com 488 9. References 490 9.1. Normative References 492 [I-D.ietf-pce-pce-initiated-lsp] 493 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 494 Extensions for PCE-initiated LSP Setup in a Stateful PCE 495 Model", draft-ietf-pce-pce-initiated-lsp-05 (work in 496 progress), October 2015. 498 [I-D.ietf-pce-stateful-pce] 499 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 500 Extensions for Stateful PCE", draft-ietf-pce-stateful- 501 pce-14 (work in progress), March 2016. 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, 505 DOI 10.17487/RFC2119, March 1997, 506 . 508 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 509 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 510 DOI 10.17487/RFC5440, March 2009, 511 . 513 [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP 514 ASSOCIATION Object Extensions", RFC 6780, 515 DOI 10.17487/RFC6780, October 2012, 516 . 518 9.2. Informative References 520 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 521 Element (PCE) Communication Protocol Generic 522 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 523 2006, . 525 Authors' Addresses 527 Ina Minei 528 Google, Inc. 529 1600 Amphitheatre Parkway 530 Mountain View, CA 94043 531 US 533 Email: inaminei@google.com 535 Edward Crabbe 537 Email: edward.crabbe@gmail.com 539 Siva Sivabalan 540 Cisco Systems, Inc. 541 170 West Tasman Dr. 542 San Jose, CA 95134 543 US 545 Email: msiva@cisco.com 546 Hariharan Ananthakrishnan 547 Packet Design 549 Email: hari@packetdesign.com 551 Xian Zhang 552 Huawei Technologies 553 F3-5-B R&D Center, Huawei Base Bantian, Longgang District 554 Shenzhen, Guangdong 518129 555 P.R.China 557 Email: zhang.xian@huawei.com 559 Yosuke Tanaka 560 NTT Communications Corporation 561 Granpark Tower 3-4-1 Shibaura, Minato-ku 562 Tokyo 108-8118 563 Japan 565 Email: yosuke.tanaka@ntt.com