idnits 2.17.1 draft-ietf-pce-vendor-constraints-07.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 27, 2012) is 4258 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 27, 2013 August 27, 2012 10 Conveying Vendor-Specific Constraints in the Path 11 Computation Element Protocol 13 draft-ietf-pce-vendor-constraints-07.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 an 120 existing PCEP object. 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-bit 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-bit 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-bit 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. 144 The Vendor Constraints object is optional in a PCReq message. 145 Multiple instances of the object MAY be used on a single PCReq 146 message and each MUST be treated according to its P-bit setting. The 147 object can be present in two places within the PCReq message to 148 enable it to apply to a single path computation request or to a set 149 of synchronized requests. This usage mirrors the usage of the 150 Objective Function object [RFC5541]. Thus, the PCReq message based 151 on [RFC6006] is encoded as follows using the syntax described in 152 [RFC5511]. 154 ::= 155 [] 156 158 where 159 ::= 160 [] 161 [] 162 [] 163 [] 164 [] 165 [] 167 ::= 168 [] 170 ::= 171 [] 173 ::= 174 [] 176 ::= 177 [] 178 179 [] 180 [] 181 [] 182 [] 183 [] 184 [] 185 [] 186 where 187 ::= 188 [] 189 [] 190 [] 191 [] 193 ::= [] [] 195 ::= [] 197 The Vendor Constraints object is included in a PCRep message in 198 exactly the same way as any other object as defined in [RFC5440]. 200 3. Procedures for The Vendor Constraints TLV 202 The Vendor Constraints TLV may be used to indicate a vendor-specific 203 constraint that applies to a specific PCEP object by including it in 204 the object. 206 The Vendor Constraints TLV is OPTIONAL in PCEP objects, but MUST be 207 taken into account if present. If the P flag of the object is set, 208 but the PCE does not understand the Vendor Constraints TLV and its 209 enterprise number, the entire PCEP message MUST be rejected and the 210 PCE MUST send a PCErr message with Error-Type="Reception of an 211 invalid object" and Error-Value="Unsupported VENDOR-CONSTRAINT-TLV" 212 along with the corresponding object. 214 Further specifications are needed to define the position and meaning 215 of the Vendor Constraints TLV for specific PCEP objects. 217 4. Protocol Elements 219 The Vendor Constraints object and TLV conform to the format for PCEP 220 objects and TLVs defined in [RFC5440]. 222 VENDOR-CONSTRAINT Object-Class is to be assigned by IANA. 224 VENDOR-CONSTRAINT Object-Type 1 226 VENDOR-CONSTRAINT-TLV Type is to be assigned by IANA. 228 The format of the VENDOR-CONSTRAINT object and the 229 VENDOR-CONSTRAINT-TLV body is as follows: 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Enterprise Number | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 ~ Enterprise-Specific Information ~ 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Enterprise Number 241 A unique identifier of an organization encoded as a 32-bit integer. 242 Enterprise Numbers are assigned by IANA and managed through an IANA 243 registry [RFC2578]. 245 Enterprise-Specific Information 247 The detailed enterprise-specific constraint information carried by 248 the object. The format and interpretation of this information is a 249 matter for the enterprise identified by the Enterprise Number. Such 250 formats and interpretation may be published by the enterprise 251 (possibly through an informational RFC or through commercial 252 documentation) so that PCCs or PCEs that are not part of the 253 organization can use the information. 255 5. IANA Considerations 257 IANA maintains a registry of PCEP parameters called the "Path 258 Computation Element Protocol (PCEP) Numbers". 260 5.1. New PCEP Object 262 IANA is requested to make an allocation from the "PCEP Objects" 263 sub-registry as follows. The value here is suggested for use by IANA. 265 Object-Class Value Name Reference 266 TBD1 VENDOR-CONSTRAINT [This.I-D] 267 Object-Type 268 1: Vendor-Specific Constraints [This.I-D] 269 2-15: Unassigned 271 5.2. New PCEP TLV 273 IANA is requested to make an allocation from the "PCEP TLV Type 274 Indicators" sub-registry as follow. 276 Value Description Reference 277 TBD2 VENDOR-CONSTRAINT-TLV [This.I-D] 279 5.3. New Error Value 281 IANA is requested to make an allocation from the "PCEP-ERROR Object 282 Error Types and Values" sub-registry as follow. Note that Error Type 283 10 is already allocated, and this request is only for a new 284 associated Error Value 285 Error-Type Meaning Reference 286 10 Reception of an invalid object 287 Error-Value 288 TBD3: Unsupported VENDOR-CONSTRAINT-TLV [This.I-D] 290 6. Management Considerations 292 This section follows the guidance of [RFC5706] and [RFC6123]. 294 6.1. Control of Function and Policy 296 A PCEP implementation SHUOLD allow configuring of various parameters 297 as described in [RFC5440]. A PCC implementation that uses vendor- 298 specific constraints MAY make the use of these constraints 299 configurable either across the whole PCC, per PCE that the PCC uses, 300 or per path computation request. A PCE that supports vendor-specific 301 constraints MAY make the support of these constraints configurable, 302 and MAY allow configuration of policies for the use of the 303 constraints. 305 6.2. Information and Data Models 307 A PCEP MIB module is defined in [PCE-MIB] that describes managed 308 objects for modeling of PCEP communications. 310 It is NOT RECOMMENDED that standard MIB modules are extended to 311 include detailed information about the content of the Vendor 312 Constaints object. However, the standard MIB module MAY be extended 313 to report the use of the Vendor Specific object and the Enterprise 314 Numbers that the objects contain. 316 6.3. Liveness Detection and Monitoring 318 This document makes no change to the basic operation of PCEP and so 319 there are no changes to the requirements for liveness detection and 320 monitoring set out in [RFC4657] and [RFC5440]. 322 6.4. Verifying Correct Operation 324 This document makes no change to the basic operation of PCEP and so 325 there are no changes to the requirements or techniques for 326 monitoring the correct operation of the protocol out in [RFC4657] 327 and [RFC5440]. 329 Note that "correct operation" in this context referes to the 330 operation of the protocol itself, and not to the operation of the 331 computation algorithms which are out of scope for all PCEP work. 333 Mechanisms for verifying the correct operation of computation 334 algorithms might involve comparing the results returned by more than 335 one PCE. Scope for this might be limited by the use of vendor 336 constraints unless multiple PCEs support the same set of constraints. 338 6.5. Requirements on Other Protocols and Functional Components 340 This document does not place any new requirements on other network 341 components or protocols. However, it may be beneficial to consider 342 whether a PCE should advertise the enterprise numbers and vendor 343 constraints it supports. This advertisement could be within PCE 344 Discovery ([RFC5088], [RFC5089]) or through extensions to PCEP 345 [RFC5440]. 347 Extensions for discovery and advertisement are outside the scope of 348 this document. 350 6.6. Impact on Network Operation 352 The availability of vendor constraints in PCEP messages may 353 facilitate more complex and detailed path computations that may 354 enhance the way in which the network is operated. 356 On the other hand, the presence of additional vendor-specific 357 information in PCEP messages may congest the operation of the 358 protocol especially if the PCE does not support the constraints 359 supplied by the PCC. Thus, a PCC SHOULD monitor the capabilities of 360 a PCE either by discovery mechanisms as described in Section 6.5, or 361 through the receipt of negative responses. A PCC SHOULD NOT include 362 vendor constraints in a PCReq message to a PCE that it believes does 363 not support the constraints and that will not forward the request to 364 some other PCE that does support the constraints. 366 7. Security Considerations 368 The protocol extensions defined in this document do not 369 substantially change the nature of PCEP. Therefore, the security 370 considerations set out in [RFC5440] apply unchanged. 372 Operators should note that an attack on PCEP may involve making PCEP 373 messages as large as possible in order to consume bandwidth and 374 processing power. The Vendor Constraints object may provide a 375 mechanism for this type of attack. It may be protected against by 376 using the authentication and integrity procedures described in 377 [RFC5440]. 379 8. References 381 8.1. Normative References 383 [RFC2119] S. Bradner, "Key words for use in RFCs to indicate 384 requirements levels", RFC 2119, March 1997. 386 [RFC5440] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E., 387 Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation 388 Element (PCE) communication Protocol (PCEP)", RFC 5440, 389 March 2009. 391 [RFC5511] Farrel, A., "Reduced Backus-Naur Form (RBNF): A Syntax to 392 Form Encoding Rules in Various Routing Protocol 393 Specifications", RFC 5511, April 2007. 395 [RFC6006] Q. Zhao, et al., "Extensions to the Path Computation 396 Element Communication Protocol (PCEP) for Point-to- 397 Multipoint Traffic Engineering Label Switched Paths", RFC 398 6006, September 2009. 400 8.2. Informative References 402 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 403 "Structure of Management Information Version 2 (SMIv2)", 404 STD 58, RFC 2578, April 1999. 406 [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 407 Element (PCE) Architecture", RFC 4655, August 2006. 409 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 410 Communication Protocol Generic Requirements", RFC 4657, 411 September 2006. 413 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 414 "OSPF Protocol Extensions for Path Computation Element 415 (PCE) Discovery", RFC 5088, January 2008. 417 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 418 "IS-IS Protocol Extensions for Path Computation Element 419 (PCE) Discovery", RFC 5089, January 2008. 421 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 422 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 423 May 2008. 425 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Objective 426 Function Encoding in Path Computation Element 427 Communication and Discovery protocols", RFC 5541, June 428 2009. 430 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 431 Management of New Protocols and Protocol Extensions", RFC 432 5706, November 2009. 434 [RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path 435 Computation Element (PCE) Working Group Drafts", RFC 6123, 436 February 2011. 438 [PCE-MIB] Stephan, E. and K. Koushik, "PCE Communication Protocol 439 (PCEP) Management Information Base", draft-ietf-pce-pcep- 440 mib, work in progress. 442 9. Acknowledgements 444 Thanks to Meral Shirazipour, Ramon Casellas, and Cyril Margaria for 445 review and comments. 447 10. Authors' Addresses 449 Adrian Farrel 450 Old Dog Consulting 451 EMail: adrian@olddog.co.uk 453 Fatai Zhang 454 Huawei Technologies 455 Email: zhangfatai@huawei.com 457 Greg Bernstein 458 Grotto Networking 459 EMail: gregb@grotto-networking.com