idnits 2.17.1 draft-ietf-pce-vendor-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 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) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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: March 1, 2010 A. Farrel 6 Expires: September 1, 2010 Old Dog Consulting 8 Conveying Vendor-Specific Constraints in the Path 9 Computation Element Protocol 11 draft-ietf-pce-vendor-constraints-01.txt 13 Abstract 15 The Path Computation Element Protocol (PCEP) is used to convey path 16 computation requests and responses between Path Computation Clients 17 (PCCs) and Path Computation Elements (PCEs), and also between 18 cooperating PCEs. In PCEP the path computation requests carry details 19 of the constraints and objective functions that the PCC wishes the 20 PCE to apply in its computation. 22 The mechanisms defined for indicating objective functions include 23 the capability to convey vendor-specific objective functions. This 24 document defines a facility to carry vendor-specific constraints in 25 PCEP. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on August 19, 2010. 50 Copyright Notice 52 Copyright (c) 2010 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 (http://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 Conventions used in this document 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 68 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 69 "OPTIONAL" in this document are to be interpreted as described in 70 RFC-2119 [RFC2119]. 72 1. Introduction 74 A Path Computation Element (PCE) is an entity (component, application 75 or network node) that is capable of computing a network path or route 76 based on a network graph and applying computational constraints. An 77 architecture for the use of PCEs is defined in [RFC4655]. 79 The Path Computation Element Protocol (PCEP) is defined in [RFC5440] 80 to exchange path computation requests and responses between Path 81 Computation Clients (PCCs) and PCEs. It is also used between 82 cooperating PCEs. 84 Path computations performed by a PCE depend on a set of constraints 85 indicated by the PCC. These constraints include the end points of the 86 path to compute (source and destination), and may include other 87 simple constraints such as bandwidth requirements and metric maxima 88 (for example, a maximum threshold for the hop count or the TE metric 89 of the computed path). 91 The PCE also needs to use some objective function to qualify the path 92 it selects as meeting the requirements of the PCC. The PCE may have a 93 default objective function, but the PCC can also indicate which 94 objective function it wants applied by placing an Objective Function 95 object in the path computation request message [RFC5541]. A core set 96 of objective functions to be supported in PCEP messages is defined in 97 the base PCEP requirements [RFC4657], and [RFC5541] defines each of 98 these functions as an abstract formula. 100 The registry of codepoints used to indicate objective functions is 101 managed by IANA and can be extended in future documents. PCE 102 implementations may choose to offer proprietary, vendor-specific 103 objective functions, and there is scope for this within the codepoint 104 registry created by [RFC5541]. That is, in the "PCE Objective 105 Function" code point registry managed by IANA, the rules for the 106 assignment of objective function code point values are as follows 107 (using terms defined in [RFC5226]) 109 o Function code values 1 through 1023 are assigned by IANA using 110 the "IETF Review" policy. 112 o Function code values 1024 through 32767 are assigned by IANA, 113 using the "First Come First Served" policy. 115 o Function code values in the range 32768-65535 are for "Private 116 Use". 118 Proprietary objective functions may operate on non-standard 119 constraints or metrics. The PCEP Metric Object defined in [RFC5440] 120 has scope for the definition of new, standardized metrics, but no 121 facility for the definition of vendor-specific metrics. At the same 122 time, there is no mechanism in PCEP for carrying other, more complex, 123 vendor-specific constraints. 125 This document defines a new PCEP object, the Vendor Constraints 126 object that can be used to carry arbitrary constraint information. 128 2. Procedures 130 A PCC that wants to convey proprietary or vendor-specific constraints 131 or metrics to a PCE does so by including a Vendor Constraints object 132 in the PCReq message. The contents and format of the object are 133 described in Section 3, but it is important to note that the object 134 includes an Enterprise Number that is a unique identifier of an 135 organization responsible for the definition of the content and 136 meaning of the object. 138 A PCE that receives a PCReq message containing a Vendor Constraints 139 object MUST act according to the P-bit in the object header. That is, 140 if the P-bit is set, the object MUST be treated as mandatory and the 141 request must either be processed using the contents of the object or 142 rejected as defined in [RFC5440]. If the P-bit is clear, the object 143 MAY be used by the PCE or MAY be ignored. The PCC sets the P-bit 144 according to how it wishes the request to be processed. 146 The PCE determines how to interpret the Vendor Constraints object by 147 examining the Enterprise Number it contains. 149 The Vendor Constraints object is optional in a PCReq message. 150 Multiple instances of the object MAY be used on a single PCReq 151 message and each MUST be treated according to its P-bit setting. The 152 object can be present in two places within the PCReq message to 153 enable it to apply to a single path computation request or to a set 154 of synchronized requests. This usage mirrors the usage of the 155 Objective Function object [RFC5541]. Thus, the PCReq message is 156 encoded as follows using the syntax described in [RFC5511]. 158 ::= 159 [ [] [] 160 [] ] 161 163 where: 165 ::= 166 [] 168 ::= 169 [] 171 ::= 172 [] 174 ::= 175 [] 177 ::= 178 179 [] 180 [] 181 [] 182 [] 183 [] 184 [] 185 [] 186 [] 188 The Vendor Constraints object is included in a PCRep message in 189 exactly the same way as any other object as defined in [RFC5440]. 191 3. Protocol Elements 193 The Vendor Constraints object conforms to the format for PCEP objects 194 defined in [RFC5440]. 196 VENDOR-CONSTRAINT Object-Class is to be assigned by IANA (recommended 197 value=23). 199 VENDOR-CONSTRAINT Object-Type is to be assigned by IANA (recommended 200 value=1) 202 The format of the VENDOR-CONSTRAINT object body is as follows: 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Enterprise Number | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 ~ Enterprise-Specific Information ~ 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Enterprise Number 214 A unique identifier of an organization encoded as a 32-bit integer. 215 Enterprise Numbers are assigned by IANA and managed through an IANA 216 registry [RFC2578]. 218 Enterprise-Specific Information 220 The detailed enterprise-specific constraint information carried by 221 the object. The format and interpretation of this information is a 222 matter for the enterprise identified by the Enterprise Number. Such 223 formats and interpretation MAY be published by the enterprise 224 (possibly through an informational RFC or through commercial 225 documentation) so that PCCs or PCEs that are not part of the 226 organization can use the information. 228 4. IANA Considerations 230 IANA maintains a registry of PCEP parameters. This includes a sub- 231 registry for PCEP Objects. 233 IANA is requested to make an allocation from the sub-registry as 234 follows. The values here are suggested for use by IANA. 236 Object Name Reference 237 Class 239 23 VENDOR-CONSTRAINT [This.I-D] 240 Object-Type 241 1: Vendor-Specific Constraints [This.I-D] 243 5. Management Considerations 245 This section follows the guidance of [MANAGE]. 247 5.1. Control of Function and Policy 249 A PCEP implementation SHUOLD allow configuring of various parameters 250 as described in [RFC5440]. A PCC implementation that uses vendor- 251 specific constraints MAY make the use of these constraints 252 configurable either across the whole PCC, per PCE that the PCC uses, 253 or per path computation request. A PCE that supports vendor-specific 254 constraints MAY make the support of these constraints configurable, 255 and MAY allow configuration of policies for the use of the 256 constraints. 258 5.2. Information and Data Models 260 A PCEP MIB module is defined in [PCE-MIB] that describes managed 261 objects for modeling of PCEP communications. 263 It is NOT RECOMMENDED that standard MIB modules are extended to 264 include detailed information about the content of the Vendor 265 Constaints object. However, the standard MIB module MAY be extended 266 to report the use of the Vendor Specific object and the Enterprise 267 Numbers that the objects contain. 269 5.3. Liveness Detection and Monitoring 271 This document makes no change to the basic operation of PCEP and so 272 there are no changes to the requirements for liveness detection and 273 monitoring set out in [RFC4657] and [RFC5440]. 275 5.4. Verifying Correct Operation 277 This document makes no change to the basic operation of PCEP and so 278 there are no changes to the requirements or techniques for monitoring 279 the correct operation of the protocol out in [RFC4657] and [RFC5440]. 281 Note that "correct operation" in this context referes to the 282 operation of the protocol itself, and not to the operation of the 283 computation algorithms which are out of scope for all PCEP work. 284 Mechanisms for verifying the correct operation of computation 285 algorithms might involve comparing the results returned by more than 286 one PCE. Scope for this might be limited by the use of vendor 287 constraints unless multiple PCEs support the same set of constraints. 289 5.5. Requirements on Other Protocols and Functional Components 291 This document does not place any new requirements on other network 292 components or protocols. However, it may be beneficial to consider 293 whether a PCE should advertise the enterprise numbers and vendor 294 constraints it supports. This advertisement could be within PCE 295 Discovery ([RFC5088], [RFC5089]) or through extensions to PCEP 296 [RFC5440]. 298 Extensions for discovery and advertisement are outside the scope of 299 this document. 301 5.6. Impact on Network Operation 303 The availability of vendor constraints in PCEP messages may 304 facilitate more complex and detailed path computations that may 305 enhance the way in which the network is operated. 307 On the other hand, the presence of additional vendor-specific 308 information in PCEP messages may congest the operation of the 309 protocol especially if the PCE does not support the constraints 310 supplied by the PCC. Thus, a PCC SHOULD monitor the capabilities of a 311 PCE either by discovery mechanisms as described in Section 5.5, or 312 through the receipt of negative responses. A PCC SHOULD NOT include 313 vendor constraints in a PCReq message to a PCE that it believes does 314 not support the constraints and that will not forward the request to 315 some other PCE that does support the constraints. 317 6. Security Considerations 319 The protocol extensions defined in this document do not substantially 320 change the nature of PCEP. Therefore, the security considerations set 321 out in [RFC5440] apply unchanged. 323 Operators should note that an attack on PCEP may involve making PCEP 324 messages as large as possible in order to consume bandwidth and 325 processing power. The Vendor Constraints object may provide a 326 mechanism for this type of attack. It may be protected against by 327 using the authentication and integrity procedures described in 328 [RFC5440]. 330 7. References 332 7.1. Normative References 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, March 1997. 337 [RFC5440] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E., 338 Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation 339 Element (PCE) communication Protocol (PCEP)", RFC 5440, 340 March 2009. 342 [RFC5511] Farrel, A., "Reduced Backus-Naur Form (RBNF): A Syntax to 343 Form Encoding Rules in Various Routing Protocol 344 Specifications", RFC 5511, April 2007. 346 7.2. Informative References 348 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 349 "Structure of Management Information Version 2 (SMIv2)", 350 STD 58, RFC 2578, April 1999. 352 [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 353 Element (PCE) Architecture", RFC 4655, August 2006. 355 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 356 Communication Protocol Generic Requirements", RFC 4657, 357 September 2006. 359 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 360 "OSPF Protocol Extensions for Path Computation Element 361 (PCE) Discovery", RFC 5088, January 2008. 363 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 364 "IS-IS Protocol Extensions for Path Computation Element 365 (PCE) Discovery", RFC 5089, January 2008. 367 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 368 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 369 May 2008. 371 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Objective Function 372 Encoding in Path Computation Element Communication and 373 Discovery protocols", RFC 5541, June 2009. 375 [MANAGE] Farrel, A., "Inclusion of Manageability Sections in PCE 376 Working Group Drafts", draft-ietf-pce-manageability- 377 requirements, work in progress. 379 [PCE-MIB] Stephan, E. and K. Koushik, "PCE Communication Protocol 380 (PCEP) Management Information Base", draft-ietf-pce-pcep- 381 mib, work in progress. 383 8. Acknowledgements 385 Thanks to Meral Shirazipour for review and comments. 387 9. Authors' Addresses 389 Adrian Farrel 390 Old Dog Consulting 391 EMail: adrian@olddog.co.uk 393 Greg Bernstein 394 Grotto Networking 395 EMail: gregb@grotto-networking.com