idnits 2.17.1 draft-farrel-pce-vendor-constraints-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 379. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 390. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 397. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 403. 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 Copyright Line does not match the current year == 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group A. Farrel (Ed.) 3 Internet-Draft Old Dog Consulting 4 Intended Status: Standards Track 5 Created: November 2, 2008 Greg Bernstein 6 Expires: May 2, 2008 Grotto Networking 8 Conveying Vendor-Specific Constraints in the Path 9 Computation Element Protocol 11 draft-farrel-pce-vendor-constraints-02.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 The Path Computation Element Protocol (PCEP) is used to convey path 38 computation requests and responses between Path Computation Clients 39 (PCCs) and Path Computation Elements (PCEs), and also between 40 cooperating PCEs. In PCEP the path computation requests carry details 41 of the constraints and objective functions that the PCC wishes the 42 PCE to apply in its computation. 44 The mechanisms defined for indicating objective functions include 45 the capability to convey vendor-specific objective functions. This 46 document defines a facility to carry vendor-specific constraints in 47 PCEP. 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 52 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 53 "OPTIONAL" in this document are to be interpreted as described in 54 RFC-2119 [RFC2119]. 56 1. Introduction 58 A Path Computation Element (PCE) is an entity (component, application 59 or network node) that is capable of computing a network path or route 60 based on a network graph and applying computational constraints. An 61 architecture for the use of PCEs is defined in [RFC4655]. 63 The Path Computation Element Protocol (PCEP) is defined in [PCEP] to 64 exchange path computation requests and responses between Path 65 Computation Clients (PCCs) and PCEs. It is also used between 66 cooperating PCEs. 68 Path computations performed by a PCE depend on a set of constraints 69 indicated by the PCC. These constraints include the end points of the 70 path to compute (source and destination), and may include other 71 simple constraints such as bandwidth requirements and metric maxima 72 (for example, a maximum threshold for the hop count or the TE metric 73 of the computed path). 75 The PCE also needs to use some objective function to qualify the path 76 it selects as meeting the requirements of the PCC. The PCE may have a 77 default objective function, but the PCC can also indicate which 78 objective function it wants applied by placing an Objective Function 79 object in the path computation request message [PCEP-OF]. A core set 80 of objective functions to be supported in PCEP messages is defined in 81 the base PCEP requirements [RFC4657], and [PCEP-OF] defines each of 82 these functions as an abstract formula. 84 The registry of codepoints used to indicate objective functions is 85 managed by IANA and can be extended in future documents. PCE 86 implementations may choose to offer proprietary, vendor-specific 87 objective functions, and there is scope for this within the codepoint 88 registry created by [PCEP-OF]. 90 Proprietary objective functions may operate on non-standard 91 constraints or metrics. The PCEP Metric Object defined in [PCEP] has 92 scope for the definition of new, standardized metrics, but no 93 facility for the definition of vendor-specific metrics. At the same 94 time, there is no mechanism in PCEP for carrying other, more complex, 95 vendor-specific constraints. 97 This document defines a new PCEP object, the Vendor Constraints 98 object that can be used to carry arbitrary constraint information. 100 2. Procedures 102 A PCC that wants to convey proprietary or vendor-specific constraints 103 or metrics to a PCE does so by including a Vendor Constraints object 104 in the PCReq message. The contents and format of the object are 105 described in Section 3, but it is important to note that the object 106 includes an Enterprise Number that is a unique identifier of an 107 organization responsible for the definition of the content and 108 meaning of the object. 110 A PCE that receives a PCReq message containing a Vendor Constraints 111 object MUST act according to the P-bit in the object header. That is, 112 if the P-bit is set, the object MUST be treated as mandatory and the 113 request must either be processed using the contents of the object or 114 rejected as defined in [PCEP]. If the P-bit is clear, the object MAY 115 be used by the PCE or MAY be ignored. The PCC sets the P-bit 116 according to how it wishes the request to be processed. 118 The PCE determines how to interpret the Vendor Constraints object by 119 examining the Enterprise Number it contains. 121 The Vendor Constraints object is optional in a PCReq message. 122 Multiple instances of the object MAY be used on a single PCReq 123 message and each MUST be treated according to its P-bit setting. The 124 object can be present in two places within the PCReq message to 125 enable it to apply to a single path computation request or to a set 126 of synchronized requests. This usage mirrors the usage of the 127 Objective Function object [PCEP-OF]. Thus, the PCReq message is 128 encoded as follows using the syntax described in [RBNF]. 130 ::= 131 [ [] [] 132 [] ] 133 135 where: 137 ::= 138 [] 140 ::= 141 [] 143 ::= 144 [] 146 ::= 147 [] 149 ::= 150 151 [] 152 [] 153 [] 154 [] 155 [] 156 [] 157 [] 158 [] 160 The Vendor Constraints object is included in a PCRep message in 161 exactly the same way as any other object as defined in [PCEP]. 163 3. Protocol Elements 165 The Vendor Constraints object conforms to the format for PCEP objects 166 defined in [PCEP]. 168 VENDOR-CONSTRAINT Object-Class is to be assigned by IANA (recommended 169 value=23). 171 VENDOR-CONSTRAINT Object-Type is to be assigned by IANA (recommended 172 value=1) 174 The format of the VENDOR-CONSTRAINT object body is as follows: 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Enterprise Number | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 ~ Enterprise-Specific Information ~ 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Enterprise Number 186 A unique identifier of an organization encoded as a 32-bit integer. 187 Enterprise Numbers are assigned by IANA and managed through an IANA 188 registry [RFC2578]. 190 Enterprise-Specific Information 192 The detailed enterprise-specific constraint information carried by 193 the object. The format and interpretation of this information is a 194 matter for the enterprise identified by the Enterprise Number. Such 195 formats and interpretation MAY be published by the enterprise 196 (possibly through an informational RFC or through commercial 197 documentation) so that PCCs or PCEs that are not part of the 198 organization can use the information. 200 4. IANA Considerations 202 IANA maintains a registry of PCEP parameters. This includes a sub- 203 registry for PCEP Objects. 205 IANA is requested to make an allocation from the sub-registry as 206 follows. The values here are suggested for use by IANA. 208 Object Name Reference 209 Class 211 23 VENDOR-CONSTRAINT [This.I-D] 212 Object-Type 213 1: Vendor-Specific Constraints [This.I-D] 215 5. Management Considerations 217 This section follows the guidance of [MANAGE]. 219 5.1. Control of Function and Policy 221 A PCEP implementation SHUOLD allow configuring of various parameters 222 as described in [PCEP]. A PCC implementation that uses vendor- 223 specific constraints MAY make the use of these constraints 224 configurable either across the whole PCC, per PCE that the PCC uses, 225 or per path computation request. A PCE that supports vendor-specific 226 constraints MAY make the support of these constraints configurable, 227 and MAY allow configuration of policies for the use of the 228 constraints. 230 5.2. Information and Data Models 232 A PCEP MIB module is defined in [PCE-MIB] that describes managed 233 objects for modeling of PCEP communications. 235 It is NOT RECOMMENDED that standard MIB modules are extended to 236 include detailed information about the content of the Vendor 237 Constaints object. However, the standard MIB module MAY be extended 238 to report the use of the Vendor Specific object and the Enterprise 239 Numbers that the objects contain. 241 5.3. Liveness Detection and Monitoring 243 This document makes no change to the basic operation of PCEP and so 244 there are no changes to the requirements for liveness detection and 245 monitoring set out in [RFC4657] and [PCEP]. 247 5.4. Verifying Correct Operation 249 This document makes no change to the basic operation of PCEP and so 250 there are no changes to the requirements or techniques for monitoring 251 the correct operation of the protocol out in [RFC4657] and [PCEP]. 253 Note that "correct operation" in this context referes to the 254 operation of the protocol itself, and not to the operation of the 255 computation algorithms which are out of scope for all PCEP work. 256 Mechanisms for verifying the correct operation of computation 257 algorithms might involve comparing the results returned by more than 258 one PCE. Scope for this might be limited by the use of vendor 259 constraints unless multiple PCEs support the same set of constraints. 261 5.5. Requirements on Other Protocols and Functional Components 263 This document does not place any new requirements on other network 264 components or protocols. However, it may be beneficial to consider 265 whether a PCE should advertise the enterprise numbers and vendor 266 constraints it supports. This advertisement could be within PCE 267 Discovery ([RFC5088], [RFC5089]) or through extensions to PCEP 268 [PCEP]. 270 Extensions for discovery and advertisement are outside the scope of 271 this document. 273 5.6. Impact on Network Operation 275 The availability of vendor constraints in PCEP messages may 276 facilitate more complex and detailed path computations that may 277 enhance the way in which the network is operated. 279 On the other hand, the presence of additional vendor-specific 280 information in PCEP messages may congest the operation of the 281 protocol especially if the PCE does not support the constraints 282 supplied by the PCC. Thus, a PCC SHOULD monitor the capabilities of a 283 PCE either by discovery mechanisms as described in Section 5.5, or 284 through the receipt of negative responses. A PCC SHOULD NOT include 285 vendor constraints in a PCReq message to a PCE that it believes does 286 not support the constraints and that will not forward the request to 287 some other PCE that does support the constraints. 289 6. Security Considerations 291 The protocol extensions defined in this document do not substantially 292 change the nature of PCEP. Therefore, the security considerations set 293 out in [PCEP] apply unchanged. 295 Operators should note that an attack on PCEP may involve making PCEP 296 messages as large as possible in order to consume bandwidth and 297 processing power. The Vendor Constraints object may provide a 298 mechanism for this type of attack. It may be protected against by 299 using the authentication and integrity procedures described in 300 [PCEP]. 302 7. References 304 7.1. Normative References 306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 307 Requirement Levels", BCP 14, RFC 2119, March 1997. 309 [PCEP] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E., 310 Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation 311 Element (PCE) communication Protocol (PCEP)", draft-ietf- 312 pce-pcep, work in progress. 314 7.2. Informative References 316 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 317 "Structure of Management Information Version 2 (SMIv2)", 318 STD 58, RFC 2578, April 1999. 320 [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 321 Element (PCE) Architecture", RFC 4655, August 2006. 323 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 324 Communication Protocol Generic Requirements", RFC 4657, 325 September 2006. 327 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 328 "OSPF Protocol Extensions for Path Computation Element 329 (PCE) Discovery", RFC 5088, January 2008. 331 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 332 "IS-IS Protocol Extensions for Path Computation Element 333 (PCE) Discovery", RFC 5089, January 2008. 335 [MANAGE] Farrel, A., "Inclusion of Manageability Sections in PCE 336 Working Group Drafts", draft-ietf-pce-manageability- 337 requirements, work in progress. 339 [PCE-MIB] Stephan, E. and K. Koushik, "PCE Communication Protocol 340 (PCEP) Management Information Base", draft-kkoushik-pce- 341 pcep-mib, work in progress. 343 [PCEP-OF] Le Roux, JL., Vasseur, JP., and Y. Lee, "Objective Function 344 Encoding in Path Computation Element Communication and 345 Discovery protocols", draft-ietf-pce-of, work in progress. 347 [RBNF] Farrel, A., "Reduced Backus-Naur Form (RBNF) - A Syntax 348 Used in Various Protocol Specifications", draft-farrel-rtg- 349 common-bnf, work in progress. 351 8. Acknowledgements 353 Thanks to Meral Shirazipour for review and comments. 355 9. Authors' Addresses 357 Adrian Farrel 358 Old Dog Consulting 359 EMail: adrian@olddog.co.uk 361 Greg Bernstein 362 Grotto Networking 363 EMail: gregb@grotto-networking.com 365 Full Copyright Statement 367 Copyright (C) The IETF Trust (2008). 369 This document is subject to the rights, licenses and restrictions 370 contained in BCP 78, and except as set forth therein, the authors 371 retain all their rights. 373 This document and the information contained herein are provided on an 374 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 375 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 376 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 377 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 378 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 379 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 381 Intellectual Property 383 The IETF takes no position regarding the validity or scope of any 384 Intellectual Property Rights or other rights that might be claimed to 385 pertain to the implementation or use of the technology described in 386 this document or the extent to which any license under such rights 387 might or might not be available; nor does it represent that it has 388 made any independent effort to identify any such rights. Information 389 on the procedures with respect to rights in RFC documents can be 390 found in BCP 78 and BCP 79. 392 Copies of IPR disclosures made to the IETF Secretariat and any 393 assurances of licenses to be made available, or the result of an 394 attempt made to obtain a general license or permission for the use of 395 such proprietary rights by implementers or users of this 396 specification can be obtained from the IETF on-line IPR repository at 397 http://www.ietf.org/ipr. 399 The IETF invites any interested party to bring to its attention any 400 copyrights, patents or patent applications, or other proprietary 401 rights that may cover technology that may be required to implement 402 this standard. Please address the information to the IETF at 403 ietf-ipr@ietf.org.