idnits 2.17.1 draft-ietf-pce-lsp-setup-type-08.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 (January 15, 2018) is 2293 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group S. Sivabalan 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track J. Tantsura 5 Expires: July 19, 2018 Individual 6 I. Minei 7 Google, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 J. Hardwick 11 Metaswitch Networks 12 January 15, 2018 14 Conveying path setup type in PCEP messages 15 draft-ietf-pce-lsp-setup-type-08 17 Abstract 19 A Path Computation Element can compute Traffic Engineering (TE) paths 20 through a network that are subject to various constraints. 21 Currently, TE paths are Label Switched Paths (LSPs) which are set up 22 using the RSVP-TE signaling protocol. However, other TE path setup 23 methods are possible within the PCE architecture. This document 24 proposes an extension to PCEP to allow support for different path 25 setup methods over a given PCEP session. 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). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on July 19, 2018. 44 Copyright Notice 46 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Path Setup Type Capability TLV . . . . . . . . . . . . . . . 4 65 4. Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . . 5 66 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 7 70 7.2. New Path Setup Type Registry . . . . . . . . . . . . . . 8 71 7.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 8 72 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 76 10.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 [RFC5440] describes the Path Computation Element communication 82 Protocol (PCEP) for communication between a Path Computation Client 83 (PCC) and a Path Computation Element (PCE), or between a PCE and a 84 PCE. A PCC requests a path subject to various constraints and 85 optimization criteria from a PCE. The PCE responds to the PCC with a 86 hop-by-hop path in an Explicit Route Object (ERO). The PCC uses the 87 ERO to set up the path in the network. 89 [RFC8231] specifies extensions to PCEP that allow a PCC to delegate 90 its LSPs to a PCE. The PCE can then update the state of LSPs 91 delegated to it. In particular, the PCE may modify the path of an 92 LSP by sending a new ERO. The PCC uses this ERO to re-route the LSP 93 in a make-before-break fashion. [RFC8281] specifies a mechanism 94 allowing a PCE to dynamically instantiate an LSP on a PCC by sending 95 the ERO and the characteristics of the LSP. The PCC creates the LSP 96 using the ERO and other attributes sent by the PCE. 98 So far, PCEP and its extensions have assumed that the TE paths are 99 label switched and are established via the RSVP-TE protocol. 100 However, other methods of LSP setup are possible in the PCE 101 architecture (see [RFC4655] and [RFC4657]). This document 102 generalizes PCEP to allow other LSP setup methods to be used. It 103 defines two new TLVs and specifies the base procedures to facilitate 104 this, as follows. 106 o The PATH-SETUP-TYPE-CAPABILITY TLV, which allows a PCEP speaker to 107 announce which LSP setup methods it supports when the PCEP session 108 is established. 110 o The PATH-SETUP-TYPE TLV, which allows a PCEP speaker to specify 111 which setup method should be used for a given LSP. When multiple 112 path setup types are deployed in a network, a given PCEP session 113 may have to simultaneously support more than one path setup type. 114 A PCEP speaker uses the PATH-SETUP-TYPE TLV to explicitly indicate 115 the intended path setup type in the appropriate PCEP messages, 116 unless the path setup type is RSVP-TE (which is assumed to be the 117 path setup type if no other setup type is indicated). This is so 118 that both the PCC and the PCE can take the necessary steps to set 119 up the path. 121 This document defines a path setup type code for RSVP-TE. When a new 122 path setup type (other than RSVP-TE) is introduced for setting up a 123 path, a path setup type code and, optionally, a sub-TLV pertaining to 124 the new path setup type will be defined by the document that 125 specifies the new path setup type. 127 1.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 2. Terminology 135 The following terminologies are used in this document: 137 ERO: Explicit Route Object. 139 LSR: Label Switching Router. 141 PCC: Path Computation Client. 143 PCE: Path Computation Element. 145 PCEP: Path Computation Element Protocol. 147 PST: Path Setup Type. 149 TLV: Type, Length, and Value. 151 3. Path Setup Type Capability TLV 153 A PCEP speaker indicates which PSTs it supports during the PCEP 154 initialization phase, as follows. When the PCEP session is created, 155 it sends an Open message with an OPEN object containing the PATH- 156 SETUP-TYPE-CAPABILITY TLV. The format of this TLV is as follows. 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Type (TBD1) | Length | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Reserved | Num of PSTs | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | PST#1 | ... | PST#N | Padding | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | | 168 // Optional sub-TLVs (variable) // 169 | | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 Figure 1: PATH-SETUP-TYPE-CAPABILITY TLV 174 The TLV type is TBD1 (to be assigned by IANA). Its reserved field 175 MUST be set to zero. The other fields in the TLV are as follows. 177 Length: The total length of the remainder of the TLV, that is, 178 excluding the Type and Length fields. 180 Number of PSTs: The number of PSTs in the following list, excluding 181 padding. 183 List of PSTs: A list of the PSTs that the PCEP speaker supports. 184 Each PST is a single byte in length. Duplicate entries in this 185 list MUST be ignored. The PCEP speaker MUST pad the list with 186 zeros so that it is a muliple of four bytes in length. This 187 document defines the following PST value: 189 * PST = 0: Path is setup using the RSVP-TE signaling protocol. 191 Optional sub-TLVs: A list of sub-TLVs associated with the supported 192 PSTs. Each sub-TLV MUST obey the rules for TLV formatting defined 193 in ([RFC5440]). That is, each sub-TLV MUST be padded to a four 194 byte alignment, and the length field of each sub-TLV MUST NOT 195 include the padding bytes. This document does not define any sub- 196 TLVs. 198 A PCEP speaker MUST check that this TLV is correctly formatted, as 199 follows. The TLV Length field MUST be equal to the size of the 200 appended sub-TLVs plus the size of the PST list (rounded up to the 201 nearest multiple of four) plus four bytes. The Number of PSTs field 202 MUST be greater than zero. If a PCEP speaker receives a PATH-SETUP- 203 TYPE-CAPABILITY TLV which violates these rules, then the PCEP speaker 204 MUST send a PCErr message with Error-Type = 10 (Reception of an 205 invalid object) and Error-Value = 11 (Malformed object) and MUST 206 close the PCEP session. The PCEP speaker MAY include the malformed 207 OPEN object in the PCErr message as well. 209 If a PCEP speaker receives an OPEN object with more than one PATH- 210 SETUP-TYPE-CAPABILITY TLV then it MUST ignore all but the first 211 instance of this TLV. 213 The absence of the PATH-SETUP-TYPE-CAPABILITY TLV from the OPEN 214 object is equivalent to a PATH-SETUP-TYPE-CAPABILITY TLV containing a 215 single PST of 0 (RSVP-TE signaling protocol) and no sub-TLVs. A PCEP 216 speaker MAY omit the PATH-SETUP-TYPE-CAPABILITY TLV if the only PST 217 it supports is RSVP-TE. If a PCEP speaker supports other PSTs 218 besides RSVP-TE, then it SHOULD include the PATH-SETUP-TYPE- 219 CAPABILITY TLV in its OPEN object. 221 If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY 222 TLV, it MUST ignore the TLV in accordance with ([RFC5440]). 224 4. Path Setup Type TLV 226 When a PCEP session is used to set up TE paths using different 227 methods, the corresponding PCE and PCC must be aware of the path 228 setup method used. That means, a PCE must be able to specify paths 229 in the correct format and a PCC must be able take control plane and 230 forwarding plane actions appropriate to the PST. 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Type (28) | Length (4) | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Reserved | PST | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Figure 2: PATH-SETUP-TYPE TLV 242 PATH-SETUP-TYPE TLV is an optional TLV associated with the RP 243 ([RFC5440]) and the SRP ([RFC8231]) objects. Its format is shown in 244 the above figure. The TLV type is 28. Its reserved field MUST be 245 set to zero. The one byte value contains the PST as defined for the 246 PATH-SETUP-TYPE-CAPABILITY TLV. 248 The absence of the PATH-SETUP-TYPE TLV is equivalent to a PATH-SETUP- 249 TYPE TLV with a PST value of 0 (RSVP-TE). A PCEP speaker MAY omit 250 the TLV if the PST is RSVP-TE. If the RP or SRP object contains more 251 than one PATH-SETUP-TYPE TLV, only the first TLV MUST be processed 252 and the rest MUST be ignored. 254 If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it MUST 255 ignore the TLV in accordance with ([RFC5440]). 257 5. Operation 259 During the PCEP initialization phase, if a PCEP speaker receives a 260 PATH-SETUP-TYPE-CAPABILITY TLV from its peer, it MUST consider that 261 the peer suports only the PSTs listed in the TLV. If the PCEP 262 speaker and its peer have no PSTs in common, then the PCEP speaker 263 MUST send a PCErr message with Error-Type = 21 (Invalid traffic 264 engineering path setup type) and Error-Value = 2 (Mismatched path 265 setup type) and close the PCEP session. 267 If the peer has sent no PATH-SETUP-TYPE-CAPABILITY TLV, then the PCEP 268 speaker MUST infer that the peer supports path setup using at least 269 RSVP-TE. The PCEP speaker MAY also infer that the peer supports 270 other path setup types, but the means of inference are outside the 271 scope of this document. 273 When a PCC sends a PCReq message to a PCE ([RFC5440]), it MUST 274 include the PATH-SETUP-TYPE TLV in the RP object, unless the intended 275 PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. 276 If the PCE is capable of expressing the path in a format appropriate 277 to the intended PST, it MUST use the appropriate ERO format in the 278 PCRep message. 280 When a PCE sends a PCRep message to a PCC ([RFC5440]), it MUST 281 include the PATH-SETUP-TYPE TLV in the RP object, unless the PST is 282 RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. If the 283 PCE does not support the intended PST, it MUST send a PCErr message 284 with Error-Type = 21 (Invalid traffic engineering path setup type) 285 and Error-Value = 1 (Unsupported path setup type) and close the PCEP 286 session. If the PSTs corresponding to the PCReq and PCRep messages 287 do not match, the PCC MUST send a PCErr message with Error-Type = 21 288 (Invalid traffic engineering path setup type) and Error-Value = 2 289 (Mismatched path setup type) and close the PCEP session. 291 When a stateful PCE sends a PCUpd message ([RFC8231]) or a PCInitiate 292 message ([RFC8281]) to a PCC, it MUST include the PATH-SETUP-TYPE TLV 293 in the SRP object, unless the intended PST is RSVP-TE, in which case 294 it MAY omit the PATH-SETUP-TYPE TLV. If the PCC does not support the 295 PST associated with the PCUpd or PCInitiate message, it MUST send a 296 PCErr message with Error-Type = 21 (Invalid traffic engineering path 297 setup type) and Error-Value = 1 (Unsupported path setup type) and 298 close the PCEP session. 300 When a PCC sends a PCRpt message to a stateful PCE ([RFC8231]), it 301 MUST include the PATH-SETUP-TYPE TLV in the SRP object, unless the 302 PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. 303 The PCC MUST include the SRP object in the PCRpt message if the PST 304 is not RSVP-TE, even when the SRP-ID-number is the reserved value of 305 0x00000000. If the PCRpt message is triggered by a PCUpd or 306 PCInitiate message, then the PST that the PCC indicates in the PCRpt 307 MUST match the PST that the stateful PCE intended in the PCUpd or 308 PCInitiate. If it does not, then the PCE MUST send a PCErr message 309 with Error-Type = 21 (Invalid traffic engineering path setup type) 310 and Error-Value = 2 (Mismatched path setup type) and close the PCEP 311 session. 313 6. Security Considerations 315 The security considerations described in [RFC5440] and [RFC8281] are 316 applicable to this specification. No additional security measure is 317 required. 319 7. IANA Considerations 321 7.1. PCEP TLV Type Indicators 323 IANA is requested to confirm the early allocation of the following 324 code point in the PCEP TLV Type Indicators registry. 326 Value Description Reference 328 28 PATH-SETUP-TYPE This document 330 IANA is requested to allocate a new code point for the following TLV 331 in the PCEP TLV Type Indicators registry. 333 Value Description Reference 335 TBD1 PATH-SETUP-TYPE-CAPABILITY This document 337 Note to IANA: The above TLV type was not part of the early code point 338 allocation that was done for this draft. It was added to the draft 339 after the early code point allocation had taken place. Please assign 340 a code point from the indicated registry and replace each instance of 341 "TBD1" in this document with the allocated code point. 343 7.2. New Path Setup Type Registry 345 IANA is requested to create a new sub-registry within the "Path 346 Computation Element Protocol (PCEP) Numbers" registry called "PCEP 347 Path Setup Types". The allocation policy for this new registry 348 should be by IETF Consensus. The new registry should contain the 349 following value: 351 Value Description Reference 353 0 Path is setup using the RSVP- This document 354 TE signaling protocol. 356 7.3. PCEP-Error Object 358 IANA is requested to confirm the early allocation of the following 359 code-points in the PCEP-ERROR Object Error Types and Values registry. 361 Error-Type Meaning 362 10 Reception of an invalid object 364 Error-value=11: Malformed object 366 Error-Type Meaning 367 21 Invalid traffic engineering path setup type 369 Error-value=0: Unassigned 370 Error-value=1: Unsupported path setup type 371 Error-value=2: Mismatched path setup type 373 Note to IANA: the early allocation for Error-Type=10, Error-value=11 374 was originally done by draft-ietf-pce-segment-routing. However, we 375 have since moved its definition into this document. Therefore, 376 please update the reference for this Error-value in the indicated 377 registry to point to RFC.ietf-pce-lsp-setup-type. 379 8. Contributors 381 The following people contributed to this document: 383 - Jan Medved 384 - Edward Crabbe 386 9. Acknowledgements 388 We like to thank Marek Zavodsky for valuable comments. 390 10. References 392 10.1. Normative References 394 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 395 Requirement Levels", BCP 14, RFC 2119, 396 DOI 10.17487/RFC2119, March 1997, 397 . 399 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 400 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 401 DOI 10.17487/RFC5440, March 2009, 402 . 404 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 405 Computation Element Communication Protocol (PCEP) 406 Extensions for Stateful PCE", RFC 8231, 407 DOI 10.17487/RFC8231, September 2017, 408 . 410 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 411 Computation Element Communication Protocol (PCEP) 412 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 413 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 414 . 416 10.2. Informative References 418 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 419 Element (PCE)-Based Architecture", RFC 4655, 420 DOI 10.17487/RFC4655, August 2006, 421 . 423 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 424 Element (PCE) Communication Protocol Generic 425 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 426 2006, . 428 Authors' Addresses 429 Siva Sivabalan 430 Cisco Systems, Inc. 431 2000 Innovation Drive 432 Kanata, Ontario K2K 3E8 433 Canada 435 Email: msiva@cisco.com 437 Jeff Tantsura 438 Individual 440 Email: jefftant.ietf@gmail.com 442 Ina Minei 443 Google, Inc. 444 1600 Amphitheatre Parkway 445 Mountain View, CA 94043 446 USA 448 Email: inaminei@google.com 450 Robert Varga 451 Pantheon Technologies SRO 452 Mlynske Nivy 56 453 Bratislava, 821 05 454 Slovakia 456 Email: nite@hq.sk 458 Jon Hardwick 459 Metaswitch Networks 460 100 Church Street 461 Enfield, Middlesex 462 UK 464 Email: jonathan.hardwick@metaswitch.com