idnits 2.17.1 draft-peng-pce-te-constraints-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 (November 3, 2019) is 1637 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 (-06) exists of draft-barth-pce-segment-routing-policy-cp-04 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-14 == Outdated reference: A later version (-19) exists of draft-ietf-isis-te-app-09 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 ** Downref: Normative reference to an Informational RFC: RFC 4655 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE S. Peng 3 Internet-Draft Q. Xiong 4 Intended status: Standards Track ZTE Corporation 5 Expires: May 6, 2020 F. Qin 6 China Mobile 7 November 3, 2019 9 PCEP Extension for TE Constraints 10 draft-peng-pce-te-constraints-01 12 Abstract 14 This document proposes a set of constraints for PCEP to configure PCE 15 to use specific virtual network topology or application attributes 16 during path computation. A simple COLOR parameter is also introduced 17 to simplify network operations. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 6, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions used in this document . . . . . . . . . . . . . . 3 55 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 3. PCEP Extensions for Constraints . . . . . . . . . . . . . . . 3 58 3.1. Source Protocol Object . . . . . . . . . . . . . . . . . 3 59 3.2. Multi-topology Object . . . . . . . . . . . . . . . . . . 4 60 3.3. The AII Object . . . . . . . . . . . . . . . . . . . . . 5 61 3.4. Application Specific Object . . . . . . . . . . . . . . . 6 62 3.5. The Color Object . . . . . . . . . . . . . . . . . . . . 7 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 [RFC5440] describes the Path Computation Element Protocol (PCEP) 72 which is used between a Path Computation Element (PCE) and a Path 73 Computation Client (PCC) (or other PCE) to enable computation of 74 Multi-protocol Label Switching (MPLS) for Traffic Engineering Label 75 Switched Path (TE LSP). PCEP Extensions for the Stateful PCE Model 76 [RFC8231] describes a set of extensions to PCEP to enable active 77 control of MPLS-TE and Generalized MPLS (GMPLS) tunnels. [RFC8281] 78 describes the setup and teardown of PCE-initiated LSPs under the 79 active stateful PCE model, without the need for local configuration 80 on the PCC, thus allowing for dynamic centralized control of a 81 network. 83 As depicted in [RFC4655], a PCE MUST be able to compute the path of a 84 TE LSP by operating on the TED and considering bandwidth and other 85 constraints applicable to the TE LSP service request. The constraint 86 parameters are provided such as metric, bandwidth, delay, affinity, 87 etc. However these parameters can't meet the virtual network service 88 requirements. A PCE always perform path computation based on the 89 network topology information collected through BGP-LS [RFC7752]. 90 BGP-LS can get multiple link-state data from multiple IGP instance, 91 or multiple virtual topologies from a single IGP instance. It is 92 necessary to restrict the PCE to a small topology scope during path 93 computation for some special purpose. BGP-LS can also get 94 application specific TE attributes for a link, it is also necessary 95 to restrict PCE to use TE attributes of specific application during 96 path computation. 98 This document will extend PCEP to support some new constraint 99 parameters during path computation, e.g, IGP instance, virtual 100 network, specific application, as well as a simple COLOR parameter. 102 2. Conventions used in this document 104 2.1. Terminology 106 The terminology is defined as [RFC5440] and [RFC7752]. 108 2.2. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 3. PCEP Extensions for Constraints 118 3.1. Source Protocol Object 120 The Source Protocol object is optional and can be used for several 121 purposes. 123 In a PCReq message, a PCC MAY insert one Source Protocol object to 124 indicate the source protocol that MUST be considered by the PCE. The 125 PCE will perform path computation based on the sub-topology 126 identified by the specific source protocol. The absence of the 127 Source Protocol object MUST be interpreted by the PCE as a path 128 computation request for which no constraints need be applied to any 129 of the source protocols. 131 In a PCRep/PCInit/PCUpd message, the Source Protocol object MAY be 132 inserted so as to provide the source protocol information for the 133 computed path. 135 Only one Source Protocol Object could be inserted in the above 136 messages, otherwise the first one MUST be considered and others MUST 137 be ignored. 139 Source Protocol Object-Class is TBA. 141 Source Protocol Object-Type is 1. 143 The format of the Source Protocol object is shown as Figure 1: 145 0 1 2 3 146 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 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Protocol-ID | Reserved | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Identifier | 151 | (64 bits) | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 Figure 1: Source Protocol Object 156 The Source Protocol object body has a fixed length of 12 bytes. 158 Protocol-ID (8 bits): defined in [RFC7752] section 3.2. 160 Reserved (24 bits): This field MUST be set to zero on transmission 161 and MUST be ignored on receipt. 163 Identifier (64 bits): defined in [RFC7752] section 3.2. 165 3.2. Multi-topology Object 167 The Multi-topology object is optional and can be used for several 168 purposes. 170 In a PCReq message, a PCC MAY insert one Multi-topology object to 171 indicate the sub-topology of an IGP instance that MUST be considered 172 by the PCE. The PCE will perform path computation based on the sub- 173 topology identified by the specific Multi-Topology ID within a source 174 protocol. The absence of the Multi-topology object MUST be 175 interpreted by the PCE as a path computation request for which no 176 constraints need be applied to any of the multi-topologies. 178 In a PCRep/PCInit/PCUpd message, the Multi-topology object MAY be 179 inserted so as to provide the Multi-topology information for the 180 computed path. 182 Only one Multi-topology Object could be inserted in the above 183 messages, otherwise the first one MUST be considered and others MUST 184 be ignored. It MUST be inserted with a Source Protocol Object, if 185 not it MUST be ignored. 187 Multi-topology Object-Class is TBA. 189 Multi-topology Object-Type is 1. 191 The format of the Multi-topology object is shown as Figure 2: 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 |R R R R| Multi-Topology ID | Reserved | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 2: Multi-topology Object 201 The Multi-topology object body has a fixed length of 4 bytes. 203 Multi-Topology ID (16 bits): Semantics of the IS-IS MT-ID are defined 204 in Section 7.2 of [RFC5120]. Semantics of the OSPF MT-ID are defined 205 in Section 3.7 of [RFC4915]. If the value is derived from OSPF, then 206 the upper 9 bits MUST be set to 0. Bits R are reserved and SHOULD be 207 set to 0 when originated and ignored on receipt. 209 Reserved (16 bits): This field MUST be set to zero on transmission 210 and MUST be ignored on receipt. 212 3.3. The AII Object 214 The AII object is optional and can be used for several purposes. 216 In a PCReq message, a PCC MAY insert one AII object to indicate the 217 global virtual network that MUST be considered by the PCE. The PCE 218 will perform path computation based on the intra or inter-domain sub- 219 topology identified by the specific AII, which is independent of 220 routing protocols such as IGP/BGP. The absence of the AII object 221 MUST be interpreted by the PCE as a path computation request for 222 which no constraints need be applied to any of the virtual network, 223 i.e, a default AII (0) will be applied. 225 In a PCRep/PCInit/PCUpd message, the AII object MAY be inserted so as 226 to provide the network slicing information for the computed path. 228 Only one AII Object could be inserted in the above messages, 229 otherwise the first one MUST be considered and others MUST be 230 ignored. 232 AII Object-Class is TBA. 234 AII Object-Type is 1. 236 The format of the AII object is shown as Figure 3: 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | AII | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 3: AII Object 246 The AII object body has a fixed length of 4 bytes. 248 AII (32 bits): Administrative Instance Identifier defined in 249 [I-D.peng-lsr-network-slicing]. 251 3.4. Application Specific Object 253 The Application Specific object is optional and can be used for 254 several purposes. 256 In a PCReq message, a PCC MAY insert one Application Specific object 257 to indicate the appliaction that MUST be considered by the PCE. The 258 PCE will perform path computation using the specific application 259 attributes. The absence of the Application Specific object MUST be 260 interpreted by the PCE as a path computation request for which no 261 constraints need be applied to any of the Application Specific 262 attributes. 264 In a PCRep/PCInit/PCUpd message, the Application Specific object MAY 265 be inserted so as to provide the Application Specific information for 266 the computed path. 268 Only one Application Specific Object could be inserted in the above 269 messages, otherwise the first one MUST be considered and others MUST 270 be ignored. 272 Application Specific Object-Class is TBA. 274 Application Specific Object-Type is 1. 276 The format of the Application Specific object is shown as Figure 4: 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Standard Application ID | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | User Defined Application ID | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 Figure 4: Application Specific Object 288 The Application Specific object body has a fixed length of 8 bytes. 290 Standard Application ID : Represents a bit-position value for a 291 single STANDARD application that is defined in the IANA "IGP 292 Parameters" registries under the "Link Attribute Applications" 293 registry [I-D.ietf-isis-te-app]. 295 User Defined Application ID : Represents a single user defined 296 application that is implementation specific. 298 3.5. The Color Object 300 The Color object is optional and can be used for several purposes. 302 In a PCReq message, a PCC MAY insert one Color object to indicate the 303 traffic engineering purpose that is recognized by the both PCE and 304 PCC with no conflict meaning. The PCE will perform path computation 305 based on the color template defined in local and extract the detailed 306 constraints from the color template. Note the same color template is 307 also defined in PCC side. At this time, any other traditional 308 constraints (i.e, metric, bandwidth, dealy, etc) that is directly 309 contained in the message MUST be ignored. The absence of the Color 310 object MUST be interpreted by the PCE as a path computation request 311 for which traditional constraints that are contained in message need 312 be applied. 314 In a PCRep/PCInit/PCUpd message, the Color object MAY be inserted so 315 as to provide the TE purpose information for the computed path, the 316 PCC recognize the color value that match a local color-template. 318 Only one Color Object could be inserted in the above messages, 319 otherwise the first one MUST be considered and others MUST be 320 ignored. 322 Color Object-Class is TBA. 324 Color Object-Type is 1. 326 The format of the Color object is shown as Figure 5: 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Color | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 Figure 5: Color Object 336 The Color object body has a fixed length of 4 bytes. 338 Color (32 bits): Represent a TE purpose, 0 is invalid value. It is 339 consistent with the meaning of Color Extended Community that is 340 defined in [I-D.ietf-idr-tunnel-encaps], and color of SR policy that 341 is also defined in [I-D.ietf-spring-segment-routing-policy]. 343 Note that Color Object defined in this document is used to represent 344 a TE purpose, it can be suitable for any TE instance such as RSVP-TE, 345 SR-TE, SR-policy. [I-D.barth-pce-segment-routing-policy-cp] has 346 already been using SR policy KEY (that also includes a color 347 information) as an association group KEY to associate many candidate 348 paths, however it is only for association purpose but not constraint 349 purpose for path computation. 351 A color tempate can be defined to use any constraints such as 352 traditional metric, bandwidth, dealy, affinity parameters, but also 353 any sub-topology parameters above defined in this document. Both PCE 354 and PCC MUST have the same understanding for a same color value. 356 4. Security Considerations 358 TBA 360 5. Acknowledgements 362 TBA 364 6. IANA Considerations 366 IANA is requested to make allocations from the registry, as follows: 368 +--------+------------------------------+------------------+ 369 | Value | Object | Reference | 370 +--------+------------------------------+------------------+ 371 | TBA1 | Source Protocol Object | [this document] | 372 | TBA2 | Multi-topology Object | [this document] | 373 | TBA3 | AII Object | [this document] | 374 | TBA4 | Application Specific Object | [this document] | 375 | TBA5 | Color Object | [this document] | 376 +--------+------------------------------+------------------+ 378 Table 1 380 7. Normative References 382 [I-D.barth-pce-segment-routing-policy-cp] 383 Koldychev, M., Sivabalan, S., Barth, C., Li, C., and H. 384 Bidgoli, "PCEP extension to support Segment Routing Policy 385 Candidate Paths", draft-barth-pce-segment-routing-policy- 386 cp-04 (work in progress), October 2019. 388 [I-D.ietf-idr-tunnel-encaps] 389 Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel 390 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-14 391 (work in progress), September 2019. 393 [I-D.ietf-isis-te-app] 394 Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and 395 J. Drake, "IS-IS TE Attributes per application", draft- 396 ietf-isis-te-app-09 (work in progress), October 2019. 398 [I-D.ietf-spring-segment-routing-policy] 399 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 400 bogdanov@google.com, b., and P. Mattes, "Segment Routing 401 Policy Architecture", draft-ietf-spring-segment-routing- 402 policy-03 (work in progress), May 2019. 404 [I-D.peng-lsr-network-slicing] 405 Peng, S., Chen, R., and G. Mirsky, "Packet Network Slicing 406 using Segment Routing", draft-peng-lsr-network-slicing-00 407 (work in progress), February 2019. 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, 411 DOI 10.17487/RFC2119, March 1997, 412 . 414 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 415 Element (PCE)-Based Architecture", RFC 4655, 416 DOI 10.17487/RFC4655, August 2006, 417 . 419 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 420 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 421 RFC 4915, DOI 10.17487/RFC4915, June 2007, 422 . 424 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 425 Topology (MT) Routing in Intermediate System to 426 Intermediate Systems (IS-ISs)", RFC 5120, 427 DOI 10.17487/RFC5120, February 2008, 428 . 430 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 431 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 432 DOI 10.17487/RFC5440, March 2009, 433 . 435 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 436 S. Ray, "North-Bound Distribution of Link-State and 437 Traffic Engineering (TE) Information Using BGP", RFC 7752, 438 DOI 10.17487/RFC7752, March 2016, 439 . 441 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 442 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 443 May 2017, . 445 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 446 Computation Element Communication Protocol (PCEP) 447 Extensions for Stateful PCE", RFC 8231, 448 DOI 10.17487/RFC8231, September 2017, 449 . 451 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 452 Computation Element Communication Protocol (PCEP) 453 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 454 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 455 . 457 Authors' Addresses 458 Shaofu Peng 459 ZTE Corporation 460 No.50 Software Avenue 461 Nanjing, Jiangsu 210012 462 China 464 Email: peng.shaofu@zte.com.cn 466 Quan Xiong 467 ZTE Corporation 468 No.6 Huashi Park Rd 469 Wuhan, Hubei 430223 470 China 472 Email: xiong.quan@zte.com.cn 474 Fengwei Qin 475 China Mobile 476 Beijing 477 China 479 Email: qinfengwei@chinamobile.com