idnits 2.17.1 draft-ietf-pce-vendor-constraints-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group Greg Bernstein (Ed.) 3 Internet-Draft Grotto Networking 4 Intended Status: Standards Track 5 Created: July 27, 2009 A. Farrel 6 Expires: January 27, 2009 Old Dog Consulting 8 Conveying Vendor-Specific Constraints in the Path 9 Computation Element Protocol 11 draft-ietf-pce-vendor-constraints-00.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 36 The Path Computation Element Protocol (PCEP) is used to convey path 37 computation requests and responses between Path Computation Clients 38 (PCCs) and Path Computation Elements (PCEs), and also between 39 cooperating PCEs. In PCEP the path computation requests carry details 40 of the constraints and objective functions that the PCC wishes the 41 PCE to apply in its computation. 43 The mechanisms defined for indicating objective functions include 44 the capability to convey vendor-specific objective functions. This 45 document defines a facility to carry vendor-specific constraints in 46 PCEP. 48 Conventions used in this document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 51 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 52 "OPTIONAL" in this document are to be interpreted as described in 53 RFC-2119 [RFC2119]. 55 1. Introduction 57 A Path Computation Element (PCE) is an entity (component, application 58 or network node) that is capable of computing a network path or route 59 based on a network graph and applying computational constraints. An 60 architecture for the use of PCEs is defined in [RFC4655]. 62 The Path Computation Element Protocol (PCEP) is defined in [RFC5440] 63 to exchange path computation requests and responses between Path 64 Computation Clients (PCCs) and PCEs. It is also used between 65 cooperating PCEs. 67 Path computations performed by a PCE depend on a set of constraints 68 indicated by the PCC. These constraints include the end points of the 69 path to compute (source and destination), and may include other 70 simple constraints such as bandwidth requirements and metric maxima 71 (for example, a maximum threshold for the hop count or the TE metric 72 of the computed path). 74 The PCE also needs to use some objective function to qualify the path 75 it selects as meeting the requirements of the PCC. The PCE may have a 76 default objective function, but the PCC can also indicate which 77 objective function it wants applied by placing an Objective Function 78 object in the path computation request message [RFC5541]. A core set 79 of objective functions to be supported in PCEP messages is defined in 80 the base PCEP requirements [RFC4657], and [RFC5541] defines each of 81 these functions as an abstract formula. 83 The registry of codepoints used to indicate objective functions is 84 managed by IANA and can be extended in future documents. PCE 85 implementations may choose to offer proprietary, vendor-specific 86 objective functions, and there is scope for this within the codepoint 87 registry created by [RFC5541]. 89 Proprietary objective functions may operate on non-standard 90 constraints or metrics. The PCEP Metric Object defined in [RFC5440] 91 has scope for the definition of new, standardized metrics, but no 92 facility for the definition of vendor-specific metrics. At the same 93 time, there is no mechanism in PCEP for carrying other, more complex, 94 vendor-specific constraints. 96 This document defines a new PCEP object, the Vendor Constraints 97 object that can be used to carry arbitrary constraint information. 99 2. Procedures 101 A PCC that wants to convey proprietary or vendor-specific constraints 102 or metrics to a PCE does so by including a Vendor Constraints object 103 in the PCReq message. The contents and format of the object are 104 described in Section 3, but it is important to note that the object 105 includes an Enterprise Number that is a unique identifier of an 106 organization responsible for the definition of the content and 107 meaning of the object. 109 A PCE that receives a PCReq message containing a Vendor Constraints 110 object MUST act according to the P-bit in the object header. That is, 111 if the P-bit is set, the object MUST be treated as mandatory and the 112 request must either be processed using the contents of the object or 113 rejected as defined in [RFC5440]. If the P-bit is clear, the object 114 MAY be used by the PCE or MAY be ignored. The PCC sets the P-bit 115 according to how it wishes the request to be processed. 117 The PCE determines how to interpret the Vendor Constraints object by 118 examining the Enterprise Number it contains. 120 The Vendor Constraints object is optional in a PCReq message. 121 Multiple instances of the object MAY be used on a single PCReq 122 message and each MUST be treated according to its P-bit setting. The 123 object can be present in two places within the PCReq message to 124 enable it to apply to a single path computation request or to a set 125 of synchronized requests. This usage mirrors the usage of the 126 Objective Function object [RFC5541]. Thus, the PCReq message is 127 encoded as follows using the syntax described in [RFC5511]. 129 ::= 130 [ [] [] 131 [] ] 132 134 where: 136 ::= 137 [] 139 ::= 140 [] 142 ::= 143 [] 145 ::= 146 [] 148 ::= 149 150 [] 151 [] 152 [] 153 [] 154 [] 155 [] 156 [] 157 [] 159 The Vendor Constraints object is included in a PCRep message in 160 exactly the same way as any other object as defined in [RFC5440]. 162 3. Protocol Elements 164 The Vendor Constraints object conforms to the format for PCEP objects 165 defined in [RFC5440]. 167 VENDOR-CONSTRAINT Object-Class is to be assigned by IANA (recommended 168 value=23). 170 VENDOR-CONSTRAINT Object-Type is to be assigned by IANA (recommended 171 value=1) 173 The format of the VENDOR-CONSTRAINT object body is as follows: 175 0 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Enterprise Number | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 ~ Enterprise-Specific Information ~ 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 Enterprise Number 185 A unique identifier of an organization encoded as a 32-bit integer. 186 Enterprise Numbers are assigned by IANA and managed through an IANA 187 registry [RFC2578]. 189 Enterprise-Specific Information 191 The detailed enterprise-specific constraint information carried by 192 the object. The format and interpretation of this information is a 193 matter for the enterprise identified by the Enterprise Number. Such 194 formats and interpretation MAY be published by the enterprise 195 (possibly through an informational RFC or through commercial 196 documentation) so that PCCs or PCEs that are not part of the 197 organization can use the information. 199 4. IANA Considerations 201 IANA maintains a registry of PCEP parameters. This includes a sub- 202 registry for PCEP Objects. 204 IANA is requested to make an allocation from the sub-registry as 205 follows. The values here are suggested for use by IANA. 207 Object Name Reference 208 Class 210 23 VENDOR-CONSTRAINT [This.I-D] 211 Object-Type 212 1: Vendor-Specific Constraints [This.I-D] 214 5. Management Considerations 216 This section follows the guidance of [MANAGE]. 218 5.1. Control of Function and Policy 220 A PCEP implementation SHUOLD allow configuring of various parameters 221 as described in [RFC5440]. A PCC implementation that uses vendor- 222 specific constraints MAY make the use of these constraints 223 configurable either across the whole PCC, per PCE that the PCC uses, 224 or per path computation request. A PCE that supports vendor-specific 225 constraints MAY make the support of these constraints configurable, 226 and MAY allow configuration of policies for the use of the 227 constraints. 229 5.2. Information and Data Models 231 A PCEP MIB module is defined in [PCE-MIB] that describes managed 232 objects for modeling of PCEP communications. 234 It is NOT RECOMMENDED that standard MIB modules are extended to 235 include detailed information about the content of the Vendor 236 Constaints object. However, the standard MIB module MAY be extended 237 to report the use of the Vendor Specific object and the Enterprise 238 Numbers that the objects contain. 240 5.3. Liveness Detection and Monitoring 242 This document makes no change to the basic operation of PCEP and so 243 there are no changes to the requirements for liveness detection and 244 monitoring set out in [RFC4657] and [RFC5440]. 246 5.4. Verifying Correct Operation 248 This document makes no change to the basic operation of PCEP and so 249 there are no changes to the requirements or techniques for monitoring 250 the correct operation of the protocol out in [RFC4657] and [RFC5440]. 252 Note that "correct operation" in this context referes to the 253 operation of the protocol itself, and not to the operation of the 254 computation algorithms which are out of scope for all PCEP work. 255 Mechanisms for verifying the correct operation of computation 256 algorithms might involve comparing the results returned by more than 257 one PCE. Scope for this might be limited by the use of vendor 258 constraints unless multiple PCEs support the same set of constraints. 260 5.5. Requirements on Other Protocols and Functional Components 262 This document does not place any new requirements on other network 263 components or protocols. However, it may be beneficial to consider 264 whether a PCE should advertise the enterprise numbers and vendor 265 constraints it supports. This advertisement could be within PCE 266 Discovery ([RFC5088], [RFC5089]) or through extensions to PCEP 267 [RFC5440]. 269 Extensions for discovery and advertisement are outside the scope of 270 this document. 272 5.6. Impact on Network Operation 274 The availability of vendor constraints in PCEP messages may 275 facilitate more complex and detailed path computations that may 276 enhance the way in which the network is operated. 278 On the other hand, the presence of additional vendor-specific 279 information in PCEP messages may congest the operation of the 280 protocol especially if the PCE does not support the constraints 281 supplied by the PCC. Thus, a PCC SHOULD monitor the capabilities of a 282 PCE either by discovery mechanisms as described in Section 5.5, or 283 through the receipt of negative responses. A PCC SHOULD NOT include 284 vendor constraints in a PCReq message to a PCE that it believes does 285 not support the constraints and that will not forward the request to 286 some other PCE that does support the constraints. 288 6. Security Considerations 290 The protocol extensions defined in this document do not substantially 291 change the nature of PCEP. Therefore, the security considerations set 292 out in [RFC5440] apply unchanged. 294 Operators should note that an attack on PCEP may involve making PCEP 295 messages as large as possible in order to consume bandwidth and 296 processing power. The Vendor Constraints object may provide a 297 mechanism for this type of attack. It may be protected against by 298 using the authentication and integrity procedures described in 299 [RFC5440]. 301 7. References 303 7.1. Normative References 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, March 1997. 308 [RFC5440] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E., 309 Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation 310 Element (PCE) communication Protocol (PCEP)", RFC 5440, 311 March 2009. 313 [RFC5511] Farrel, A., "Reduced Backus-Naur Form (RBNF): A Syntax to 314 Form Encoding Rules in Various Routing Protocol 315 Specifications", RFC 5511, April 2007. 317 7.2. Informative References 319 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 320 "Structure of Management Information Version 2 (SMIv2)", 321 STD 58, RFC 2578, April 1999. 323 [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 324 Element (PCE) Architecture", RFC 4655, August 2006. 326 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 327 Communication Protocol Generic Requirements", RFC 4657, 328 September 2006. 330 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 331 "OSPF Protocol Extensions for Path Computation Element 332 (PCE) Discovery", RFC 5088, January 2008. 334 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 335 "IS-IS Protocol Extensions for Path Computation Element 336 (PCE) Discovery", RFC 5089, January 2008. 338 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Objective Function 339 Encoding in Path Computation Element Communication and 340 Discovery protocols", RFC 5541, June 2009. 342 [MANAGE] Farrel, A., "Inclusion of Manageability Sections in PCE 343 Working Group Drafts", draft-ietf-pce-manageability- 344 requirements, work in progress. 346 [PCE-MIB] Stephan, E. and K. Koushik, "PCE Communication Protocol 347 (PCEP) Management Information Base", draft-ietf-pce-pcep- 348 mib, work in progress. 350 8. Acknowledgements 352 Thanks to Meral Shirazipour for review and comments. 354 9. Authors' Addresses 356 Adrian Farrel 357 Old Dog Consulting 358 EMail: adrian@olddog.co.uk 360 Greg Bernstein 361 Grotto Networking 362 EMail: gregb@grotto-networking.com 364 Copyright Notice 366 Copyright (c) 2009 IETF Trust and the persons identified as the 367 document authors. All rights reserved. 369 This document is subject to BCP 78 and the IETF Trust's Legal 370 Provisions Relating to IETF Documents in effect on the date of 371 publication of this document (http://trustee.ietf.org/license-info). 372 Please review these documents carefully, as they describe your rights 373 and restrictions with respect to this document. 375 Intellectual Property Statement 377 The IETF Trust takes no position regarding the validity or scope of 378 any Intellectual Property Rights or other rights that might be 379 claimed to pertain to the implementation or use of the technology 380 described in any IETF Document or the extent to which any license 381 under such rights might or might not be available; nor does it 382 represent that it has made any independent effort to identify any 383 such rights. 385 Copies of Intellectual Property disclosures made to the IETF 386 Secretariat and any assurances of licenses to be made available, or 387 the result of an attempt made to obtain a general license or 388 permission for the use of such proprietary rights by implementers or 389 users of this specification can be obtained from the IETF on-line IPR 390 repository at http://www.ietf.org/ipr 392 The IETF invites any interested party to bring to its attention any 393 copyrights, patents or patent applications, or other proprietary 394 rights that may cover technology that may be required to implement 395 any standard or specification contained in an IETF Document. Please 396 address the information to the IETF at ietf-ipr@ietf.org. 398 Disclaimer of Validity 400 All IETF Documents and the information contained therein are provided 401 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 402 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 403 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 404 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 405 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 406 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 407 FOR A PARTICULAR PURPOSE.