idnits 2.17.1 draft-ietf-pce-vendor-constraints-08.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 (August 31, 2012) is 4257 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 (~~), 2 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 8 Expires: February 31, 2013 August 31, 2012 10 Conveying Vendor-Specific Constraints in the Path 11 Computation Element Protocol 13 draft-ietf-pce-vendor-constraints-08.txt 15 Abstract 17 The Path Computation Element Protocol (PCEP) is used to convey path 18 computation requests and responses between Path Computation Clients 19 (PCCs) and Path Computation Elements (PCEs), and also between 20 cooperating PCEs. In PCEP the path computation requests carry 21 details of the constraints and objective functions that the PCC 22 wishes the PCE to apply in its computation. 24 The mechanisms defined for indicating objective functions include 25 the capability to convey vendor-specific objective functions. This 26 document defines a facility to carry vendor-specific constraints in 27 PCEP. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that other 36 groups may also distribute working documents as Internet-Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Conventions used in this document 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC-2119 [RFC2119]. 70 1. Introduction 72 A Path Computation Element (PCE) is an entity (component, 73 application or network node) that is capable of computing a network 74 path or route based on a network graph and applying computational 75 constraints. An architecture for the use of PCEs is defined in 76 [RFC4655]. 78 The Path Computation Element Protocol (PCEP) is defined in [RFC5440] 79 to exchange path computation requests and responses between Path 80 Computation Clients (PCCs) and PCEs. It is also used between 81 cooperating PCEs. 83 Path computations performed by a PCE depend on a set of constraints 84 indicated by the PCC. These constraints include the end points of 85 the path to compute (source and destination), and may include other 86 simple constraints such as bandwidth requirements and metric maxima 87 (for example, a maximum threshold for the hop count or the TE metric 88 of the computed path). 90 The PCE also needs to use an objective function to qualify the path 91 it selects as meeting the requirements of the PCC. The PCE may have a 92 default objective function, but the PCC can also indicate which 93 objective function it wants applied by placing an Objective Function 94 object in the path computation request message [RFC5541]. A core set 95 of objective functions to be supported in PCEP messages is defined in 96 the base PCEP requirements [RFC4657], and [RFC5541] defines each of 97 these functions as an abstract formula. 99 The registry of codepoints used to indicate objective functions is 100 managed by IANA and new assignments can be made according to "IETF 101 Review" and "First Come First Served" policies [RFC5226]. PCE 102 implementations may also choose to offer proprietary, vendor-specific 103 objective functions, and there is scope for this within the 104 codepoint registry created by [RFC5541] using the codepoints that are 105 flagged as "Reserved for Private Use." 107 Proprietary objective functions may operate on non-standard 108 constraints or metrics. The PCEP Metric Object defined in [RFC5440] 109 has scope for the definition of new, standardized metrics, but no 110 facility for the definition of vendor-specific metrics. At the same 111 time, there is no mechanism in PCEP for carrying other, more complex, 112 vendor-specific constraints. 114 This document defines a new PCEP object, the Vendor Constraints 115 object that can be used to carry arbitrary, proprietary constraint 116 information. 118 This document also defines a new PCEP TLV, the VENDOR-CONSTRAINT-TLV 119 that can be used to carry arbitrary constraint information within any 120 PCEP object that supports TLVs. 122 2. Procedures for The Vendor Constraints Object 124 A PCC that wants to convey proprietary or vendor-specific 125 constraints or metrics to a PCE does so by including a Vendor 126 Constraints object in the PCReq message. The contents and format of 127 the object are described in Section 4, but it is important to note 128 that the object includes an Enterprise Number that is a unique 129 identifier of an organization responsible for the definition of the 130 content and meaning of the object. 132 A PCE that receives a PCReq message containing a Vendor Constraints 133 object MUST act according to the P-bit in the object header. That is, 134 if the P flag is set, the object MUST be treated as mandatory and the 135 request is either processed using the contents of the object or 136 rejected as defined in [RFC5440]. If the P flag is clear, then as 137 defined in [RFC5440], the object MAY be used by the PCE or MAY be 138 ignored. The PCC sets the P flag according to how it wishes the 139 request to be processed. 141 The PCE determines how to interpret the Vendor Constraints object by 142 examining the Enterprise Number it contains. If the Enterprise 143 Number is unknown to the PCE, it MUST treat the Vendor Constraints 144 object as unknown and handle it as described in [RFC5440] according 145 to the setting of the P flag (see also Section 2.1). 147 The Vendor Constraints object is OPTIONAL in a PCReq message. 148 Multiple instances of the object MAY be used on a single PCReq 149 message and each MUST be treated according to its P-bit setting. The 150 object can be present in two places within the PCReq message to 151 enable it to apply to a single path computation request or to a set 152 of synchronized requests. This usage mirrors the usage of the 153 Objective Function object [RFC5541]. Thus, the PCReq message based 154 on [RFC6006] is encoded as follows using the syntax described in 155 [RFC5511]. 157 ::= 158 [] 159 161 where 163 ::= 164 [] 165 [] 166 [] 167 [] 168 [] 169 [] 171 ::= 172 [] 174 ::= 175 [] 177 ::= 178 [] 180 ::= 181 [] 182 183 [] 184 [] 185 [] 186 [] 187 [] 188 [] 189 [] 191 where 193 ::= 194 [] 195 [] 196 [] 197 [] 199 ::= [] [] 201 ::= [] 203 The Vendor Constraints object is included in a PCRep message in 204 exactly the same way as any other object as defined in [RFC5440]. 206 2.1. Backward Compatibility 208 A legacy implementation that does not recognize the Vendor Constraint 209 object will act according to the procedures set out in [RFC5440]. If 210 the P flag is set in the object, the message will be rejected using a 211 PCErr message with an Error Type of 3 ("Unknown Object"). If the P 212 flag is not set, the object can safely be ignored by the recipient. 214 3. Procedures for The Vendor Constraints TLV 216 The Vendor Constraints TLV may be used to indicate a vendor-specific 217 constraint that applies to a specific PCEP object by including it in 218 the object. 220 The PCE determines how to interpret the Vendor Constraints TLV by 221 examining the Enterprise Number it contains. If the Enterprise 222 Number is unknown to the PCE, it MUST treat the Vendor Constraints 223 TLV as unknown and handle it as described in [RFC5440] (see also 224 Section 3.1). 226 Further specifications are needed to define the position and meaning 227 of the Vendor Constraints TLV for specific PCEP objects. 229 3.1. Backward Compatibility 231 A legacy implementation that does not recognize the Vendor Constraint 232 TLV in an object will act according to the procedures set out in 233 [RFC5440]. As described in Section 7.1 of [RFC5440], unrecognized 234 TLVs MUST be ignored. 236 4. Protocol Elements 238 The Vendor Constraints object and TLV conform to the format for PCEP 239 objects and TLVs defined in [RFC5440]. 241 VENDOR-CONSTRAINT Object-Class is to be assigned by IANA. 243 VENDOR-CONSTRAINT Object-Type 1 245 VENDOR-CONSTRAINT-TLV Type is to be assigned by IANA. 247 The format of the VENDOR-CONSTRAINT object and the 248 VENDOR-CONSTRAINT-TLV body is as follows: 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Enterprise Number | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 ~ Enterprise-Specific Information ~ 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Enterprise Number 260 A unique identifier of an organization encoded as a 32-bit integer. 261 Enterprise Numbers are assigned by IANA and managed through an IANA 262 registry [RFC2578]. 264 Enterprise-Specific Information 266 The detailed enterprise-specific constraint information carried by 267 the object. The format and interpretation of this information is a 268 matter for the enterprise identified by the Enterprise Number. Such 269 formats and interpretation may be published by the enterprise 270 (possibly through an informational RFC or through commercial 271 documentation) so that PCCs or PCEs that are not part of the 272 organization can use the information. 274 5. IANA Considerations 276 IANA maintains a registry of PCEP parameters called the "Path 277 Computation Element Protocol (PCEP) Numbers". 279 5.1. New PCEP Object 281 IANA is requested to make an allocation from the "PCEP Objects" 282 sub-registry as follows. The value here is suggested for use by IANA. 284 Object-Class Value Name Reference 285 TBD1 VENDOR-CONSTRAINT [This.I-D] 286 Object-Type 287 0: Unassigned 288 1: Vendor-Specific Constraints [This.I-D] 289 2-255: Unassigned 291 5.2. New PCEP TLV 293 IANA is requested to make an allocation from the "PCEP TLV Type 294 Indicators" sub-registry as follow. 296 Value Description Reference 297 TBD2 VENDOR-CONSTRAINT-TLV [This.I-D] 299 6. Management Considerations 301 This section follows the guidance of [RFC5706] and [RFC6123]. 303 6.1. Control of Function and Policy 305 A PCEP implementation SHUOLD allow configuring of various parameters 306 as described in [RFC5440]. A PCC implementation that uses vendor- 307 specific constraints MAY make the use of these constraints 308 configurable either across the whole PCC, per PCE that the PCC uses, 309 or per path computation request. A PCE that supports vendor-specific 310 constraints MAY make the support of these constraints configurable, 311 and MAY allow configuration of policies for the use of the 312 constraints. 314 6.2. Information and Data Models 316 A PCEP MIB module is defined in [PCE-MIB] that describes managed 317 objects for modeling of PCEP communications. 319 It is NOT RECOMMENDED that standard MIB modules are extended to 320 include detailed information about the content of the Vendor 321 Constaints object. However, the standard MIB module MAY be extended 322 to report the use of the Vendor Specific object and the Enterprise 323 Numbers that the objects contain. 325 6.3. Liveness Detection and Monitoring 327 This document makes no change to the basic operation of PCEP and so 328 there are no changes to the requirements for liveness detection and 329 monitoring set out in [RFC4657] and [RFC5440]. 331 6.4. Verifying Correct Operation 333 This document makes no change to the basic operation of PCEP and so 334 there are no changes to the requirements or techniques for 335 monitoring the correct operation of the protocol out in [RFC4657] 336 and [RFC5440]. 338 Note that "correct operation" in this context referes to the 339 operation of the protocol itself, and not to the operation of the 340 computation algorithms which are out of scope for all PCEP work. 342 Mechanisms for verifying the correct operation of computation 343 algorithms might involve comparing the results returned by more than 344 one PCE. Scope for this might be limited by the use of vendor 345 constraints unless multiple PCEs support the same set of constraints. 347 6.5. Requirements on Other Protocols and Functional Components 349 This document does not place any new requirements on other network 350 components or protocols. However, it may be beneficial to consider 351 whether a PCE should advertise the enterprise numbers and vendor 352 constraints it supports. This advertisement could be within PCE 353 Discovery ([RFC5088], [RFC5089]) or through extensions to PCEP 354 [RFC5440]. 356 Extensions for discovery and advertisement are outside the scope of 357 this document. 359 6.6. Impact on Network Operation 361 The availability of vendor constraints in PCEP messages may 362 facilitate more complex and detailed path computations that may 363 enhance the way in which the network is operated. 365 On the other hand, the presence of additional vendor-specific 366 information in PCEP messages may congest the operation of the 367 protocol especially if the PCE does not support the constraints 368 supplied by the PCC. Thus, a PCC SHOULD monitor the capabilities of 369 a PCE either by discovery mechanisms as described in Section 6.5, or 370 through the receipt of negative responses. A PCC SHOULD NOT include 371 vendor constraints in a PCReq message to a PCE that it believes does 372 not support the constraints and that will not forward the request to 373 some other PCE that does support the constraints. 375 7. Security Considerations 377 The protocol extensions defined in this document do not 378 substantially change the nature of PCEP. Therefore, the security 379 considerations set out in [RFC5440] apply unchanged. 381 Operators should note that an attack on PCEP may involve making PCEP 382 messages as large as possible in order to consume bandwidth and 383 processing power. The Vendor Constraints object may provide a 384 mechanism for this type of attack. It may be protected against by 385 using the authentication and integrity procedures described in 386 [RFC5440]. 388 8. References 390 8.1. Normative References 392 [RFC2119] S. Bradner, "Key words for use in RFCs to indicate 393 requirements levels", RFC 2119, March 1997. 395 [RFC5440] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E., 396 Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation 397 Element (PCE) communication Protocol (PCEP)", RFC 5440, 398 March 2009. 400 [RFC5511] Farrel, A., "Reduced Backus-Naur Form (RBNF): A Syntax to 401 Form Encoding Rules in Various Routing Protocol 402 Specifications", RFC 5511, April 2007. 404 [RFC6006] Q. Zhao, et al., "Extensions to the Path Computation 405 Element Communication Protocol (PCEP) for Point-to- 406 Multipoint Traffic Engineering Label Switched Paths", RFC 407 6006, September 2009. 409 8.2. Informative References 411 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 412 "Structure of Management Information Version 2 (SMIv2)", 413 STD 58, RFC 2578, April 1999. 415 [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 416 Element (PCE) Architecture", RFC 4655, August 2006. 418 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 419 Communication Protocol Generic Requirements", RFC 4657, 420 September 2006. 422 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 423 "OSPF Protocol Extensions for Path Computation Element 424 (PCE) Discovery", RFC 5088, January 2008. 426 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 427 "IS-IS Protocol Extensions for Path Computation Element 428 (PCE) Discovery", RFC 5089, January 2008. 430 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 431 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 432 May 2008. 434 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Objective 435 Function Encoding in Path Computation Element 436 Communication and Discovery protocols", RFC 5541, June 437 2009. 439 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 440 Management of New Protocols and Protocol Extensions", RFC 441 5706, November 2009. 443 [RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path 444 Computation Element (PCE) Working Group Drafts", RFC 6123, 445 February 2011. 447 [PCE-MIB] Stephan, E. and K. Koushik, "PCE Communication Protocol 448 (PCEP) Management Information Base", draft-ietf-pce-pcep- 449 mib, work in progress. 451 9. Acknowledgements 453 Thanks to Meral Shirazipour, Ramon Casellas, Cyril Margaria, and 454 Dhruv Dhody for review and comments. 456 10. Authors' Addresses 458 Adrian Farrel 459 Old Dog Consulting 460 EMail: adrian@olddog.co.uk 462 Fatai Zhang 463 Huawei Technologies 464 Email: zhangfatai@huawei.com 466 Greg Bernstein 467 Grotto Networking 468 EMail: gregb@grotto-networking.com