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