idnits 2.17.1 draft-ietf-pce-vendor-constraints-05.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 == Line 25 has weird spacing: '... months and ...' == Line 26 has weird spacing: '... at any time...' == Line 27 has weird spacing: '...ference mate...' == Line 509 has weird spacing: '... of these ...' == Line 510 has weird spacing: '...cluding thos...' == (3 more instances...) == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (December 2, 2011) is 4527 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) ** Obsolete normative reference: RFC 6006 (Obsoleted by RFC 8306) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Fatai Zhang 2 Internet-Draft Huawei 3 Intended status: Standards Track A. Farrel 4 Old Dog Consulting 5 G. Bernstein 6 Grotto Networking 7 Expires: June 2, 2012 December 2, 2011 9 Conveying Vendor-Specific Constraints in the Path 10 Computation Element Protocol 12 draft-ietf-pce-vendor-constraints-05.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with 17 the provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as "work in 28 progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on June 2, 2012. 38 Abstract 40 The Path Computation Element Protocol (PCEP) is used to convey path 41 computation requests and responses between Path Computation Clients 42 (PCCs) and Path Computation Elements (PCEs), and also between 43 cooperating PCEs. In PCEP the path computation requests carry 44 details of the constraints and objective functions that the PCC 45 wishes the PCE to apply in its computation. 47 The mechanisms defined for indicating objective functions include 48 the capability to convey vendor-specific objective functions. This 49 document defines a facility to carry vendor-specific constraints in 50 PCEP. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC-2119 [RFC2119]. 58 Table of Contents 60 1. Introduction ................................................ .2 61 2. Procedures .................................................. .4 62 3. Protocol Elements ........................................... .6 63 4. IANA Considerations ......................................... .7 64 5. Management Considerations .................................. .7 65 5.1. Control of Function and Policy ......................... .8 66 5.2. Information and Data Models............................. .8 67 5.3. Liveness Detection and Monitoring ...................... .8 68 5.4. Verifying Correct Operation.............................. 8 69 5.5. Requirements on Other Protocols and Functional Components 8 70 5.6. Impact on Network Operation.............................. 9 71 6. Security Considerations ...................................... 9 72 7. References ................................................... 9 73 7.1. Normative References .................................... 9 74 7.2. Informative References ................................. 10 75 8. Acknowledgements ............................................. 11 76 9. Authors' Addresses ........................................... 11 78 1. Introduction 80 A Path Computation Element (PCE) is an entity (component, 81 application or network node) that is capable of computing a network 82 path or route based on a network graph and applying computational 83 constraints. An architecture for the use of PCEs is defined in 84 [RFC4655]. 86 The Path Computation Element Protocol (PCEP) is defined in [RFC5440] 87 to exchange path computation requests and responses between Path 88 Computation Clients (PCCs) and PCEs. It is also used between 89 cooperating PCEs. 91 Path computations performed by a PCE depend on a set of constraints 92 indicated by the PCC. These constraints include the end points of 93 the path to compute (source and destination), and may include other 94 simple constraints such as bandwidth requirements and metric maxima 95 (for example, a maximum threshold for the hop count or the TE metric 96 of the computed path). 98 The PCE also needs to use some objective function to qualify the 99 path it selects as meeting the requirements of the PCC. The PCE may 100 have a default objective function, but the PCC can also indicate 101 which objective function it wants applied by placing an Objective 102 Function object in the path computation request message [RFC5541]. A 103 core set of objective functions to be supported in PCEP messages is 104 defined in the base PCEP requirements [RFC4657], and [RFC5541] 105 defines each of these functions as an abstract formula. 107 The registry of codepoints used to indicate objective functions is 108 managed by IANA and can be extended in future documents. PCE 109 implementations may choose to offer proprietary, vendor-specific 110 objective functions, and there is scope for this within the 111 codepoint registry created by [RFC5541]. That is, in the "PCE 112 Objective Function" code point registry managed by IANA, the rules 113 for the assignment of objective function code point values are as 114 follows (using terms defined in [RFC5226]) 116 o Function code values 1 through 1023 are assigned by IANA using the 117 "IETF Review" policy. 119 o Function code values 1024 through 32767 are assigned by IANA, 120 using the "First Come First Served" policy. 122 o Function code values in the range 32768-65535 are for "Private 123 Use". 125 Proprietary objective functions may operate on non-standard 126 constraints or metrics. The PCEP Metric Object defined in [RFC5440] 127 has scope for the definition of new, standardized metrics, but no 128 facility for the definition of vendor-specific metrics. At the same 129 time, there is no mechanism in PCEP for carrying other, more complex, 130 vendor-specific constraints. 132 This document defines a new PCEP object, the Vendor Constraints 133 object that can be used to carry arbitrary constraint information. 135 This document also defines a new PCEP TLV, the VENDOR-CONSTRAINT-TLV 136 that can be used to carry arbitrary constraint information within an 137 existing PCEP object. 139 2. Procedures 141 A PCC that wants to convey proprietary or vendor-specific 142 constraints or metrics to a PCE does so by including a Vendor 143 Constraints object in the PCReq message. The contents and format of 144 the object are described in Section 3, but it is important to note 145 that the object includes an Enterprise Number that is a unique 146 identifier of an organization responsible for the definition of the 147 content and meaning of the object. 149 A PCC that wants to convey endpoints-specific vendor specific 150 constraints to a PCE may do so by including a Vendor Constraints TLV 151 in the endpoint-restriction-list of the END-POINTS with object type 152 Generalized Endpoint. 154 This Vendor Constraints TLV MAY also present in PCEP Objects 155 supporting TLVs and using the registry for the PCEP TLVs, to 156 indicate a vendor-specific constraint that applies to the PCEP 157 object. 159 A PCE that receives a PCReq message containing a Vendor Constraints 160 object MUST act according to the P-bit in the object header. That is, 161 if the P-bit is set, the object MUST be treated as mandatory and the 162 request must either be processed using the contents of the object or 163 rejected as defined in [RFC5440]. If the P-bit is clear, the object 164 MAY be used by the PCE or MAY be ignored. The PCC sets the P-bit 165 according to how it wishes the request to be processed. 167 The PCE determines how to interpret the Vendor Constraints object or 168 TLV by examining the Enterprise Number it contains. 170 The Vendor Constraints object is optional in a PCReq message. 171 Multiple instances of the object MAY be used on a single PCReq 172 message and each MUST be treated according to its P-bit setting. The 173 object can be present in two places within the PCReq message to 174 enable it to apply to a single path computation request or to a set 175 of synchronized requests. This usage mirrors the usage of the 176 Objective Function object [RFC5541]. Thus, the PCReq message based 177 on [RFC6006] is encoded as follows using the syntax described in 178 [RFC5511]. 180 ::= 181 [] 182 184 where 186 ::= 187 [] 188 [] 189 [] 190 [] 191 [] 192 [] 194 ::= 195 [] 197 ::= 198 [] 200 ::= 201 [] 203 ::= 204 [] 205 206 [] 207 [] 208 [] 209 [] 210 [] 211 [] 212 [] 213 where 215 ::= 216 217 [] 218 [] 219 [] 220 [] 222 ::=[][] 223 ::=[] 225 The Vendor Constraints object is included in a PCRep message in 226 exactly the same way as any other object as defined in [RFC5440]. 228 The Vendor Constraints TLV is optional in the END-POINTS with object 229 type Generalized Endpoint. The vendor restriction TLV MAY be 230 inserted at any place in the endpoint-restriction-list. 232 The VENDOR-CONSTRAINT-TLV MUST be taken into account. If the P flag 233 of the containing object is set, but the PCE does not understand the 234 TLV and its enterprise number, the entire PCEP message MUST be 235 rejected and the PCE MUST send a PCErr message with Error- 236 Type="Reception of an invalid object" and Error-Value="Unsupported 237 VENDOR-CONSTRAINT-TLV" along with the corresponding object. 239 When present in the END-POINTS with object type Generalized Endpoint 240 the endpoint-restriction-list is encoded as follow: 242 ::= 243 | 244 ]| 245 3. Protocol Elements 247 The Vendor Constraints object and TLV conform to the format for PCEP 248 objects and TLVs defined in [RFC5440]. 250 VENDOR-CONSTRAINT Object-Class is to be assigned by IANA 251 (recommended value=23). 253 VENDOR-CONSTRAINT Object-Type is to be assigned by IANA 254 (recommended value=1) 256 VENDOR-CONSTRAINT-TLV Type is to be assigned by IANA (recommended 257 value=16) 259 The format of the VENDOR-CONSTRAINT object, VENDOR-CONSTRAINT-TLV 260 body is as follows: 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Enterprise Number | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 ~ Enterprise-Specific Information ~ 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Enterprise Number 272 A unique identifier of an organization encoded as a 32-bit integer. 273 Enterprise Numbers are assigned by IANA and managed through an IANA 274 registry [RFC2578]. 276 Enterprise-Specific Information 278 The detailed enterprise-specific constraint information carried by 279 the object. The format and interpretation of this information is a 280 matter for the enterprise identified by the Enterprise Number. Such 281 formats and interpretation MAY be published by the enterprise 282 (possibly through an informational RFC or through commercial 283 documentation) so that PCCs or PCEs that are not part of the 284 organization can use the information. 286 4. IANA Considerations 288 IANA maintains a registry of PCEP parameters. This includes sub- 289 registry for PCEP Objects and PCEP TLV Type Indicators. 291 IANA is requested to make an allocation from the sub-registry PCEP 292 Objects as follows. The values here are suggested for use by IANA. 294 Object Name Reference Class 295 23 VENDOR-CONSTRAINT [This.I-D] 296 Object-Type 297 1: Vendor-Specific Constraints [This.I-D] 299 IANA is requested to do the following allocations in the "PCEP TLV 300 Type Indicators" as follow. The Values are suggested for use by IANA. 302 Value Meaning Reference 303 16 Vendor Constraint TLV [This.I-D] 305 IANA is requested to make an allocation from the sub registry "PCEP- 306 ERROR Object Error Types and Values" as follow. The Values are 307 suggested for use by IANA. 309 Error Name Reference 310 Type 311 10 Reception of an invalid object 312 Error-Value=8 Unsupported VENDOR-CONSTRAINT-TLV [This.I-D] 314 5. Management Considerations 316 This section follows the guidance of [MANAGE]. 318 5.1. Control of Function and Policy 320 A PCEP implementation SHUOLD allow configuring of various parameters 321 as described in [RFC5440]. A PCC implementation that uses vendor- 322 specific constraints MAY make the use of these constraints 323 configurable either across the whole PCC, per PCE that the PCC uses, 324 or per path computation request. A PCE that supports vendor-specific 325 constraints MAY make the support of these constraints configurable, 326 and MAY allow configuration of policies for the use of the 327 constraints. 329 5.2. Information and Data Models 331 A PCEP MIB module is defined in [PCE-MIB] that describes managed 332 objects for modeling of PCEP communications. 334 It is NOT RECOMMENDED that standard MIB modules are extended to 335 include detailed information about the content of the Vendor 336 Constaints object. However, the standard MIB module MAY be extended 337 to report the use of the Vendor Specific object and the Enterprise 338 Numbers that the objects contain. 340 5.3. Liveness Detection and Monitoring 342 This document makes no change to the basic operation of PCEP and so 343 there are no changes to the requirements for liveness detection and 344 monitoring set out in [RFC4657] and [RFC5440]. 346 5.4. Verifying Correct Operation 348 This document makes no change to the basic operation of PCEP and so 349 there are no changes to the requirements or techniques for 350 monitoring the correct operation of the protocol out in [RFC4657] 351 and [RFC5440]. 353 Note that "correct operation" in this context referes to the 354 operation of the protocol itself, and not to the operation of the 355 computation algorithms which are out of scope for all PCEP work. 356 Mechanisms for verifying the correct operation of computation 357 algorithms might involve comparing the results returned by more than 358 one PCE. Scope for this might be limited by the use of vendor 359 constraints unless multiple PCEs support the same set of constraints. 361 5.5. Requirements on Other Protocols and Functional Components 363 This document does not place any new requirements on other network 364 components or protocols. However, it may be beneficial to consider 365 whether a PCE should advertise the enterprise numbers and vendor 366 constraints it supports. This advertisement could be within PCE 367 Discovery ([RFC5088], [RFC5089]) or through extensions to PCEP 368 [RFC5440]. 370 Extensions for discovery and advertisement are outside the scope of 371 this document. 373 5.6. Impact on Network Operation 375 The availability of vendor constraints in PCEP messages may 376 facilitate more complex and detailed path computations that may 377 enhance the way in which the network is operated. 379 On the other hand, the presence of additional vendor-specific 380 information in PCEP messages may congest the operation of the 381 protocol especially if the PCE does not support the constraints 382 supplied by the PCC. Thus, a PCC SHOULD monitor the capabilities of 383 a PCE either by discovery mechanisms as described in Section 5.5, or 384 through the receipt of negative responses. A PCC SHOULD NOT include 385 vendor constraints in a PCReq message to a PCE that it believes does 386 not support the constraints and that will not forward the request to 387 some other PCE that does support the constraints. 389 6. Security Considerations 391 The protocol extensions defined in this document do not 392 substantially change the nature of PCEP. Therefore, the security 393 considerations set out in [RFC5440] apply unchanged. 395 Operators should note that an attack on PCEP may involve making PCEP 396 messages as large as possible in order to consume bandwidth and 397 processing power. The Vendor Constraints object may provide a 398 mechanism for this type of attack. It may be protected against by 399 using the authentication and integrity procedures described in 400 [RFC5440]. 402 7. References 404 7.1. Normative References 406 [RFC2119] S. Bradner, "Key words for use in RFCs to indicate 407 requirements levels", RFC 2119, March 1997. 409 [RFC5440] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E., 410 Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation 411 Element (PCE) communication Protocol (PCEP)", RFC 5440, 412 March 2009. 414 [RFC5511] Farrel, A., "Reduced Backus-Naur Form (RBNF): A Syntax to 415 Form Encoding Rules in Various Routing Protocol 416 Specifications", RFC 5511, April 2007. 418 [RFC6006] Q. Zhao, et al., "Extensions to the Path Computation 419 Element Communication Protocol (PCEP) for Point-to- 420 Multipoint Traffic Engineering Label Switched Paths", RFC 421 6006, September 2009. 423 7.2. Informative References 425 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 426 "Structure of Management Information Version 2 (SMIv2)", 427 STD 58, RFC 2578, April 1999. 429 [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 430 Element (PCE) Architecture", RFC 4655, August 2006. 432 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 433 Communication Protocol Generic Requirements", RFC 4657, 434 September 2006. 436 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 437 "OSPF Protocol Extensions for Path Computation Element 438 (PCE) Discovery", RFC 5088, January 2008. 440 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 441 "IS-IS Protocol Extensions for Path Computation Element 442 (PCE) Discovery", RFC 5089, January 2008. 444 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 445 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 446 May 2008. 448 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Objective 449 Function Encoding in Path Computation Element 450 Communication and Discovery protocols", RFC 5541, June 451 2009. 453 [MANAGE] Farrel, A., "Inclusion of Manageability Sections in PCE 454 Working Group Drafts", draft-ietf-pce-manageability- 455 requirements, work in progress. 457 [PCE-MIB] Stephan, E. and K. Koushik, "PCE Communication Protocol 458 (PCEP) Management Information Base", draft-ietf-pce-pcep- 459 mib, work in progress. 461 8. Acknowledgements 463 Thanks to Meral Shirazipour, Ramon Casellas and Cyril Margaria for 464 review and comments. 466 9. Authors' Addresses 468 Adrian Farrel 469 Old Dog Consulting 470 EMail: adrian@olddog.co.uk 472 Fatai Zhang 473 Huawei Technologies 474 Email: zhangfatai@huawei.com 476 Greg Bernstein 477 Grotto Networking 478 EMail: gregb@grotto-networking.com 480 Intellectual Property 482 The IETF Trust takes no position regarding the validity or scope of 483 any Intellectual Property Rights or other rights that might be 484 claimed to pertain to the implementation or use of the technology 485 described in any IETF Document or the extent to which any license 486 under such rights might or might not be available; nor does it 487 represent that it has made any independent effort to identify any 488 such rights. 490 Copies of Intellectual Property disclosures made to the IETF 491 Secretariat and any assurances of licenses to be made available, or 492 the result of an attempt made to obtain a general license or 493 permission for the use of such proprietary rights by implementers or 494 users of this specification can be obtained from the IETF on-line 495 IPR repository at http://www.ietf.org/ipr 497 The IETF invites any interested party to bring to its attention any 498 copyrights, patents or patent applications, or other proprietary 499 rights that may cover technology that may be required to implement 500 any standard or specification contained in an IETF Document. Please 501 address the information to the IETF at ietf-ipr@ietf.org. 503 The definitive version of an IETF Document is that published by, or 504 under the auspices of, the IETF. Versions of IETF Documents that are 505 published by third parties, including those that are translated into 506 other languages, should not be considered to be definitive versions 507 of IETF Documents. The definitive version of these Legal Provisions 508 is that published by, or under the auspices of, the IETF. Versions 509 of these Legal Provisions that are published by third parties, 510 including those that are translated into other languages, should 511 not be considered to be definitive versions of these Legal 512 Provisions. 514 For the avoidance of doubt, each Contributor to the IETF Standards 515 Process licenses each Contribution that he or she makes as part of 516 the IETF Standards Process to the IETF Trust pursuant to the 517 provisions of RFC 5378. No language to the contrary, or terms, 518 conditions or rights that differ from or are inconsistent with the 519 rights and licenses granted under RFC 5378, shall have any effect 520 and shall be null and void, whether published or posted by such 521 Contributor, or included with or in such Contribution. 523 Disclaimer of Validity 525 All IETF Documents and the information contained therein are 526 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 527 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET 528 SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE 529 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 530 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN 531 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 532 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 534 Full Copyright Statement 536 Copyright (c) 2010 IETF Trust and the persons identified as the 537 document authors. All rights reserved. 539 This document is subject to BCP 78 and the IETF Trust's Legal 540 Provisions Relating to IETF Documents 541 (http://trustee.ietf.org/license-info) in effect on the date of 542 publication of this document. Please review these documents 543 carefully, as they describe your rights and restrictions with 544 respect to this document. Code Components extracted from this 545 document must include Simplified BSD License text as described in 546 Section 4.e of the Trust Legal Provisions and are provided without 547 warranty as described in the Simplified BSD License.