idnits 2.17.1 draft-ietf-pce-lsp-setup-type-07.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 (December 19, 2017) is 2319 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: June 22, 2018 Individual 6 I. Minei 7 Google, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 J. Hardwick 11 Metaswitch Networks 12 December 19, 2017 14 Conveying path setup type in PCEP messages 15 draft-ietf-pce-lsp-setup-type-07 17 Abstract 19 A Path Computation Element can compute Traffic Engineering paths (TE 20 paths) 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 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on June 22, 2018. 50 Copyright Notice 52 Copyright (c) 2017 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 (https://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. Path Setup Type Capability TLV . . . . . . . . . . . . . . . 4 70 4. Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . . 5 71 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 7 75 7.2. New Path Setup Type Registry . . . . . . . . . . . . . . 8 76 7.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 8 77 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 10.2. Informative References . . . . . . . . . . . . . . . . . 9 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 84 1. Introduction 86 [RFC5440] describes the Path Computation Element communication 87 Protocol (PCEP) for communication between a Path Computation Client 88 (PCC) and a Path Computation Element (PCE), or between a PCE and a 89 PCE. A PCC requests a path subject to various constraints and 90 optimization criteria from a PCE. The PCE responds to the PCC with a 91 hop-by-hop path in an Explicit Route Object (ERO). The PCC uses the 92 ERO to set up the path in the network. 94 [RFC8231] specifies extensions to PCEP that allow a PCC to delegate 95 its LSPs to a PCE. The PCE can then update the state of LSPs 96 delegated to it. In particular, the PCE may modify the path of an 97 LSP by sending a new ERO. The PCC uses this ERO to re-route the LSP 98 in a make-before-break fashion. [I-D.ietf-pce-pce-initiated-lsp] 99 specifies a mechanism allowing a PCE to dynamically instantiate an 100 LSP on a PCC by sending the ERO and characteristics of the LSP. The 101 PCC creates the LSP using the ERO and other attributes sent by the 102 PCE. 104 So far, PCEP and its extensions have assumed that the TE paths are 105 label switched and are established via the RSVP-TE protocol. 106 However, other methods of LSP setup are possible in the PCE 107 architecture (see [RFC4655] and [RFC4657]). This document introduces 108 a TLV called "PATH-SETUP-TYPE-CAPABILITY" which allows a PCEP speaker 109 to announce the path setup types it supports when the PCEP session is 110 established. When a new path setup type (other than RSVP-TE) is 111 introduced for setting up a path, a path setup type code and, 112 optionally, a sub-TLV pertaining to the new path setup type will be 113 defined by the document that specifies the new path setup type. 115 When multiple path setup types are deployed in a network, a given 116 PCEP session may have to simultaneously support more than one path 117 setup type. In this case, the intended path setup type needs to be 118 explicitly indicated in the appropriate PCEP messages, unless the 119 path setup type is RSVP-TE (which is assumed to be the path setup 120 type if no other setup type is indicated). This is so that both the 121 PCC and the PCE can take the necessary steps to set up the path. 122 This document introduces a generic TLV called "PATH-SETUP-TYPE TLV" 123 and specifies the base procedures to facilitate this operational 124 model. 126 2. Terminology 128 The following terminologies are used in this document: 130 ERO: Explicit Route Object. 132 LSR: Label Switching Router. 134 PCC: Path Computation Client. 136 PCE: Path Computation Element. 138 PCEP: Path Computation Element Protocol. 140 PST: Path Setup Type. 142 TLV: Type, Length, and Value. 144 3. Path Setup Type Capability TLV 146 A PCEP speaker indicates which PSTs it supports during the PCEP 147 initialization phase, as follows. When the PCEP session is created, 148 it sends an Open message with an OPEN object containing the PATH- 149 SETUP-TYPE-CAPABILITY TLV. The format of this TLV is as follows. 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Type (TBD1) | Length | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Reserved | PST length | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | | 159 // List of PSTs padded to 4-byte alignment (variable) // 160 | | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | | 163 // Optional sub-TLVs (variable) // 164 | | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Figure 1: PATH-SETUP-TYPE-CAPABILITY TLV 169 The TLV type is TBD1 (to be assigned by IANA). Its reserved field 170 MUST be set to zero. The other fields in the TLV are as follows. 172 PST length: The length of the list of supported PSTs, in bytes, 173 excluding padding. 175 List of PSTs: A list of the PSTs that the PCEP speaker supports. 176 Each PST is a single byte in length. Duplicate entries in this 177 list MUST be ignored. The PCEP speaker MUST pad the list with 178 zeros so that it is a muliple of four bytes in length. 180 Optional sub-TLVs: A list of sub-TLVs associated with the supported 181 PSTs. Each sub-TLV MUST obey the rules for TLV formatting defined 182 in ([RFC5440]). That is, each sub-TLV MUST be padded to a four 183 byte alignment, and the length field of each sub-TLV MUST NOT 184 include the padding bytes. This document does not define any sub- 185 TLVs. 187 This document defines the following PST value: 189 o PST = 0: Path is setup using the RSVP-TE signaling protocol. 191 The overall TLV length MUST be equal to the size of the appended sub- 192 TLVs plus the PST length (rounded up to the nearest multiple of four) 193 plus four bytes for the reserved field and PST length field. The PST 194 length field MUST be greater than zero. If a PCEP speaker receives a 195 PATH-SETUP-TYPE-CAPABILITY TLV which violates these rules, then the 196 PCEP speaker MUST send a PCErr message with Error-Type = 10 197 (Reception of an invalid object) and Error-Value = 11 (Malformed 198 object) and MUST close the PCEP session. The PCEP speaker MAY 199 include the malformed OPEN object in the PCErr message as well. 201 If a PCEP speaker receives an OPEN object with more than one PATH- 202 SETUP-TYPE-CAPABILITY TLV then it MUST ignore all but the first 203 instance of this TLV. 205 The absence of the PATH-SETUP-TYPE-CAPABILITY TLV from the OPEN 206 object is equivalent to a PATH-SETUP-TYPE-CAPABILITY TLV containing a 207 single PST of 0 (RSVP-TE signaling protocol) and no sub-TLVs. A PCEP 208 speaker MAY omit the PATH-SETUP-TYPE-CAPABILITY TLV if the only PST 209 it supports is RSVP-TE. If a PCEP speaker supports other PSTs 210 besides RSVP-TE, then it SHOULD include the PATH-SETUP-TYPE- 211 CAPABILITY TLV in its OPEN object. 213 If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY 214 TLV, it MUST ignore the TLV in accordance with ([RFC5440]). 216 4. Path Setup Type TLV 218 When a PCEP session is used to set up TE paths using different 219 methods, the corresponding PCE and PCC must be aware of the path 220 setup method used. That means, a PCE must be able to specify paths 221 in the correct format and a PCC must be able take control plane and 222 forwarding plane actions appropriate to the PST. 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Type (28) | Length (4) | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Reserved | PST | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Figure 2: PATH-SETUP-TYPE TLV 234 PATH-SETUP-TYPE TLV is an optional TLV associated with the RP 235 ([RFC5440]) and the SRP ([RFC8231]) objects. Its format is shown in 236 the above figure. The TLV type is 28. Its reserved field MUST be 237 set to zero. The one byte value contains the PST as defined for the 238 PATH-SETUP-TYPE-CAPABILITY TLV. 240 The absence of the PATH-SETUP-TYPE TLV is equivalent to a PATH-SETUP- 241 TYPE TLV with a PST value of 0 (RSVP-TE). A PCEP speaker MAY omit 242 the TLV if the PST is RSVP-TE. If the RP or SRP object contains more 243 than one PATH-SETUP-TYPE TLV, only the first TLV MUST be processed 244 and the rest MUST be ignored. 246 If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it MUST 247 ignore the TLV in accordance with ([RFC5440]). 249 5. Operation 251 During the PCEP initialization phase, if a PCEP speaker receives a 252 PATH-SETUP-TYPE-CAPABILITY TLV from its peer, it MUST consider that 253 the peer suports only the PSTs listed in the TLV. If the PCEP 254 speaker and its peer have no PSTs in common, then the PCEP speaker 255 MUST send a PCErr message with Error-Type = 21 (Invalid traffic 256 engineering path setup type) and Error-Value = 2 (Mismatched path 257 setup type) and close the PCEP session. 259 If the peer has sent no PATH-SETUP-TYPE-CAPABILITY TLV, then the PCEP 260 speaker MUST infer that the peer supports path setup using at least 261 RSVP-TE. The PCEP speaker MAY also infer that the peer supports 262 other path setup types, but the means of inference are outside the 263 scope of this document. 265 When a PCC sends a PCReq message to a PCE ([RFC5440]), it MUST 266 include the PATH-SETUP-TYPE TLV in the RP object, unless the intended 267 PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. 268 If the PCE is capable of expressing the path in a format appropriate 269 to the intended PST, it MUST use the appropriate ERO format in the 270 PCRep message. 272 When a PCE sends a PCRep message to a PCC ([RFC5440]), it MUST 273 include the PATH-SETUP-TYPE TLV in the RP object, unless the PST is 274 RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. If the 275 PCE does not support the intended PST, it MUST send a PCErr message 276 with Error-Type = 21 (Invalid traffic engineering path setup type) 277 and Error-Value = 1 (Unsupported path setup type) and close the PCEP 278 session. If the PSTs corresponding to the PCReq and PCRep messages 279 do not match, the PCC MUST send a PCErr message with Error-Type = 21 280 (Invalid traffic engineering path setup type) and Error-Value = 2 281 (Mismatched path setup type) and close the PCEP session. 283 When a stateful PCE sends a PCUpd message ([RFC8231]) or a PCInitiate 284 message ([I-D.ietf-pce-pce-initiated-lsp]) to a PCC, it MUST include 285 the PATH-SETUP-TYPE TLV in the SRP object, unless the intended PST is 286 RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. If the 287 PCC does not support the PST associated with the PCUpd or PCInitiate 288 message, it MUST send a PCErr message with Error-Type = 21 (Invalid 289 traffic engineering path setup type) and Error-Value = 1 (Unsupported 290 path setup type) and close the PCEP session. 292 When a PCC sends a PCRpt message to a stateful PCE ([RFC8231]), it 293 MUST include the PATH-SETUP-TYPE TLV in the SRP object, unless the 294 PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. 295 The PCC MUST include the SRP object in the PCRpt message if the PST 296 is not RSVP-TE, even when the SRP-ID-number is the reserved value of 297 0x00000000. If the PCRpt message is triggered by a PCUpd or 298 PCInitiate message, then the PST that the PCC indicates in the PCRpt 299 MUST match the PST that the stateful PCE intended in the PCUpd or 300 PCInitiate. If it does not, then the PCE MUST send a PCErr message 301 with Error-Type = 21 (Invalid traffic engineering path setup type) 302 and Error-Value = 2 (Mismatched path setup type) and close the PCEP 303 session. 305 6. Security Considerations 307 The security considerations described in [RFC5440] and 308 [I-D.ietf-pce-pce-initiated-lsp] are applicable to this 309 specification. No additional security measure is required. 311 7. IANA Considerations 313 7.1. PCEP TLV Type Indicators 315 IANA is requested to confirm the early allocation of the following 316 code point in the PCEP TLV Type Indicators registry. 318 Value Description Reference 320 28 PATH-SETUP-TYPE This document 322 IANA is requested to allocate a new code point for the following TLV 323 in the PCEP TLV Type Indicators registry. 325 Value Description Reference 327 TBD1 PATH-SETUP-TYPE-CAPABILITY This document 329 Note to IANA: The above TLV type was not part of the early code point 330 allocation that was done for this draft. It was added to the draft 331 after the early code point allocation had taken place. Please assign 332 a code point from the indicated registry and replace each instance of 333 "TBD1" in this document with the allocated code point. 335 7.2. New Path Setup Type Registry 337 IANA is requested to create a new sub-registry within the "Path 338 Computation Element Protocol (PCEP) Numbers" registry called "PCEP 339 Path Setup Types". The allocation policy for this new registry 340 should be by IETF Consensus. The new registry should contain the 341 following value: 343 Value Description Reference 345 0 Path is setup using the RSVP- This document 346 TE signaling protocol. 348 7.3. PCEP-Error Object 350 IANA is requested to confirm the early allocation of the following 351 code-points in the PCEP-ERROR Object Error Types and Values registry. 353 Error-Type Meaning 354 10 Reception of an invalid object 356 Error-value=11: Malformed object 358 Error-Type Meaning 359 21 Invalid traffic engineering path setup type 361 Error-value=0: Unassigned 362 Error-value=1: Unsupported path setup type 363 Error-value=2: Mismatched path setup type 365 Note to IANA: the early allocation for Error-Type=10, Error-value=11 366 was originally done by draft-ietf-pce-segment-routing. However, we 367 have since moved its definition into this document. Therefore, 368 please update the reference for this Error-value in the indicated 369 registry to point to RFC.ietf-pce-lsp-setup-type. 371 8. Contributors 373 The following people contributed to this document: 375 - Jan Medved 376 - Edward Crabbe 378 9. Acknowledgements 380 We like to thank Marek Zavodsky for valuable comments. 382 10. References 384 10.1. Normative References 386 [I-D.ietf-pce-pce-initiated-lsp] 387 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 388 Extensions for PCE-initiated LSP Setup in a Stateful PCE 389 Model", draft-ietf-pce-pce-initiated-lsp-11 (work in 390 progress), October 2017. 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, 394 DOI 10.17487/RFC2119, March 1997, 395 . 397 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 398 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 399 DOI 10.17487/RFC5440, March 2009, 400 . 402 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 403 Computation Element Communication Protocol (PCEP) 404 Extensions for Stateful PCE", RFC 8231, 405 DOI 10.17487/RFC8231, September 2017, 406 . 408 10.2. Informative References 410 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 411 Element (PCE)-Based Architecture", RFC 4655, 412 DOI 10.17487/RFC4655, August 2006, 413 . 415 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 416 Element (PCE) Communication Protocol Generic 417 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 418 2006, . 420 Authors' Addresses 421 Siva Sivabalan 422 Cisco Systems, Inc. 423 2000 Innovation Drive 424 Kanata, Ontario K2K 3E8 425 Canada 427 Email: msiva@cisco.com 429 Jeff Tantsura 430 Individual 432 Email: jefftant.ietf@gmail.com 434 Ina Minei 435 Google, Inc. 436 1600 Amphitheatre Parkway 437 Mountain View, CA 94043 438 USA 440 Email: inaminei@google.com 442 Robert Varga 443 Pantheon Technologies SRO 444 Mlynske Nivy 56 445 Bratislava, 821 05 446 Slovakia 448 Email: nite@hq.sk 450 Jon Hardwick 451 Metaswitch Networks 452 100 Church Street 453 Enfield, Middlesex 454 UK 456 Email: jonathan.hardwick@metaswitch.com