idnits 2.17.1 draft-ietf-pce-vendor-constraints-11.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 date (October 17, 2013) is 3834 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 (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Fatai Zhang 3 Internet-Draft Huawei 4 Intended status: Standards Track A. Farrel 5 Juniper Networks 7 Expires: April 17, 2014 October 17, 2013 9 Conveying Vendor-Specific Constraints in the Path 10 Computation Element communication Protocol 12 draft-ietf-pce-vendor-constraints-11.txt 14 Abstract 16 The Path Computation Element communication Protocol (PCEP) is used to 17 convey path computation requests and responses between Path 18 Computation Clients (PCCs) and Path Computation Elements (PCEs), and 19 also between cooperating PCEs. In PCEP the path computation requests 20 carry details of the constraints and objective functions that the PCC 21 wishes the PCE to apply in its computation. 23 This document defines a facility to carry vendor-specific information 24 in PCEP using a dedicated object and a new Type-Length-Variable that 25 can be carried in any existing PCEP object. 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 other 34 groups may also distribute working documents as Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Conventions used in this document 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 66 "OPTIONAL" in this document are to be interpreted as described in 67 [RFC2119]. 69 1. Introduction 71 A Path Computation Element (PCE) is an entity (component, application 72 or network node) that is capable of computing a network path or route 73 based on a network graph and applying computational constraints. An 74 architecture for the use of PCEs is defined in [RFC4655]. 76 The Path Computation Element communication Protocol (PCEP) is defined 77 in [RFC5440] to exchange path computation requests and responses 78 between Path Computation Clients (PCCs) and PCEs. It is also used 79 between cooperating PCEs. 81 Path computations performed by a PCE depend on a set of constraints 82 indicated by the PCC. These constraints include the end points of 83 the path to compute (source and destination), and may include other 84 simple constraints such as bandwidth requirements and metric maxima 85 (for example, a maximum threshold for the hop count or the TE metric 86 of the computed path). 88 The PCE also needs to use an objective function to qualify the path 89 it selects as meeting the requirements of the PCC. The PCE may have 90 a default objective function, but the PCC can also indicate which 91 objective function it wants applied by placing an Objective Function 92 object in the path computation request message [RFC5541]. A core set 93 of objective functions to be supported in PCEP messages is defined in 94 the base PCEP requirements [RFC4657], and [RFC5541] defines each of 95 these functions as an abstract formula. 97 The registry of codepoints used to indicate objective functions is 98 managed by IANA and new assignments can be made according to "IETF 99 Review" and "First Come First Served" policies [RFC5226]. PCE 100 implementations may also choose to offer proprietary, vendor-specific 101 objective functions, and there is scope for this within the 102 codepoint registry created by [RFC5541] using the codepoints that are 103 flagged as "Reserved for Private Use." 105 Proprietary objective functions may operate on non-standard 106 constraints or metrics. The PCEP Metric Object defined in [RFC5440] 107 has scope for the definition of new, standardized metrics, but no 108 facility for the definition of vendor-specific metrics. At the same 109 time, there is no mechanism in PCEP for carrying other, more complex, 110 vendor-specific information. 112 This document defines a new PCEP object, the Vendor Information 113 object that can be used to carry arbitrary, proprietary information 114 such as vendor-specific constraints. 116 This document also defines a new PCEP TLV, the VENDOR-INFORMATION-TLV 117 that can be used to carry arbitrary information within any PCEP 118 object that supports TLVs. 120 2. Procedures for The Vendor Information Object 122 A PCC that wants to convey proprietary or vendor-specific constraints 123 or metrics to a PCE does so by including a Vendor Information object 124 in the PCReq message. The contents and format of the object are 125 described in Section 4, but it is important to note that the object 126 includes an Enterprise Number that is a unique identifier of an 127 organization responsible for the definition of the content and 128 meaning of the object. 130 A PCE that receives a PCReq message containing a Vendor Information 131 object MUST act according to the P flag in the object header. That 132 is, if the P flag is set, the object will be treated as mandatory 133 and the request will either be processed using the contents of the 134 object, or the request will be rejected as defined in [RFC5440] (see 135 also Section 2.1). If the P flag is clear then, as defined in 136 [RFC5440], the object may be used by the PCE or may be ignored. The 137 PCC sets the P flag according to how it wishes the request to be 138 processed. 140 The PCE determines how to interpret the information in the Vendor 141 Information object by examining the Enterprise Number it contains. 142 An implementation that supports the Vendor Information object, but 143 receives one carrying an Enterprise number that it does not support 144 MUST act according to the P flag in the object. That is, if the P 145 flag is set, the PCE MUST reject the PCReq as defined in [RFC5440] by 146 sending an Error message with Error-Type="Not supported Object" along 147 with the corresponding Vendor Information object. 149 The Vendor Information 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. 152 Different instances of the object can have different Enterprise 153 Numbers. 155 The object can be present in the PCReq message to enable it to apply 156 to a single path computation request or to a set of synchronized 157 requests. This usage mirrors the usage of the Objective Function 158 object [RFC5541]. Thus, the PCReq message based on [RFC6006] is 159 encoded as follows using the syntax described in [RFC5511]. 161 ::= 162 [] 163 165 where 167 ::= 168 [] 169 [] 170 [] 171 [] 172 [] 173 [] 175 ::= 176 [] 178 ::= 179 [] 181 ::= 182 [] 184 ::= 185 [] 186 187 [] 188 [] 189 [] 190 [] 192 [] 193 [] 194 [] 196 where 198 ::= 199 [] 200 [] 201 [] 202 [] 204 ::= [] [] 206 ::= [] 208 The Vendor Information object can be included in a PCRep message in 209 exactly the same way as any other object as defined in [RFC5440]. 210 Thus, the PCRep is encoded as follows: 212 ::= 213 215 ::= 216 [] 217 [] 218 [] 219 [] 221 where: 223 ::= 224 [] 225 226 [] 227 [] 229 ::= (|) [] 231 ::= [] 232 [] 233 [] 234 [] 235 [] 237 2.1. Backward Compatibility for the Vendor Information Object 239 A legacy implementation that does not recognize the Vendor 240 Information object will act according to the procedures set out in 241 [RFC5440]. If the P flag is set in the object, the message will be 242 rejected using a PCErr message with an Error Type of 3 ("Unknown 243 Object"). If the P flag is not set, the object can safely be ignored 244 by the recipient. 246 3. Procedures for The Vendor Information TLV 248 The Vendor Information TLV can be used to carry vendor-specific 249 information that applies to a specific PCEP object by including the 250 TLV in the object. 252 The PCE determines how to interpret the Vendor Information TLV by 253 examining the Enterprise Number it contains. If the Enterprise 254 Number is unknown to the PCE, it MUST treat the Vendor Information 255 TLV as an unknown TLV and handle it as described in [RFC5440] (see 256 also Section 3.1). 258 Further specifications are needed to define the position and meaning 259 of the Vendor Information TLV for specific PCEP objects. 261 3.1. Backward Compatibility 263 A legacy implementation that does not recognize the Vendor 264 Information TLV in an object will act according to the procedures set 265 out in [RFC5440]. As described in Section 7.1 of [RFC5440], 266 unrecognized TLVs MUST be ignored. 268 4. Protocol Elements 270 The Vendor Information object and TLV conform to the format for PCEP 271 objects and TLVs defined in [RFC5440]. 273 VENDOR-INFORMATION Object-Class is to be assigned by IANA. 275 VENDOR-INFORMATION Object-Type 1 277 VENDOR-INFORMATION-TLV Type is to be assigned by IANA. 279 The format of the VENDOR-INFORMATION object and the format of the 280 VENDOR-INFORMATION-TLV are the same and are as shown in Figure 1. 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Enterprise Number | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 ~ Enterprise-Specific Information ~ 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 Figure 1 : Format of the Vendor Information Object and TLV 292 Enterprise Number 294 A unique identifier of an organization encoded as a 32-bit integer. 295 Enterprise Numbers are assigned by IANA and managed through an IANA 296 registry [RFC2578]. 298 Enterprise-Specific Information 300 The detailed enterprise-specific constraint information carried by 301 the object. The format and interpretation of this information is a 302 matter for the enterprise identified by the Enterprise Number. 303 Such formats and interpretation may be published by the enterprise 304 (possibly through an informational RFC or through commercial 305 documentation) so that PCCs or PCEs that are not part of the 306 organization can use the information. 308 5. IANA Considerations 310 IANA maintains a registry of PCEP parameters called the "Path 311 Computation Element Protocol (PCEP) Numbers". 313 5.1. New PCEP Object 315 IANA is requested to make an allocation from the "PCEP Objects" 316 sub-registry as follows. 318 Object-Class Value Name Reference 319 TBD1 VENDOR-INFORMATION [This.I-D] 320 Object-Type 321 0: Unassigned 322 1: Vendor-Specific Constraints [This.I-D] 323 2-255: Unassigned 325 5.2. New PCEP TLV 327 IANA is requested to make an allocation from the "PCEP TLV Type 328 Indicators" sub-registry as follows. 330 Value Description Reference 331 TBD2 VENDOR-INFORMATION-TLV [This.I-D] 333 6. Management Considerations 335 This section follows the guidance of [RFC5706] and [RFC6123]. 337 6.1. Control of Function and Policy 339 A PCEP implementation SHOULD allow configuring of various parameters 340 as described in [RFC5440]. A PCC implementation that uses vendor- 341 specific information MAY make the use of this information 342 configurable either across the whole PCC, per PCE that the PCC uses, 343 or per path computation request. A PCE that supports vendor-specific 344 information MAY make the support of this information configurable, 345 and MAY allow configuration of policies for the use of the 346 information. 348 6.2. Information and Data Models 350 A PCEP MIB module is defined in [PCE-MIB] that describes managed 351 objects for modeling of PCEP communications. 353 It is NOT RECOMMENDED that standard MIB modules are extended to 354 include detailed information about the content of the Vendor 355 Information object or TLV. However, the standard MIB module MAY be 356 extended to report the use of the Vendor Information object or TLV 357 and the Enterprise Numbers that the objects and TLVs contain. 359 6.3. Liveness Detection and Monitoring 361 This document makes no change to the basic operation of PCEP and so 362 there are no changes to the requirements for liveness detection and 363 monitoring set out in [RFC4657] and [RFC5440]. 365 6.4. Verifying Correct Operation 367 This document makes no change to the basic operation of PCEP and so 368 there are no changes to the requirements or techniques for 369 monitoring the correct operation of the protocol out in [RFC4657] 370 and [RFC5440]. 372 Note that "correct operation" in this context referes to the 373 operation of the protocol itself, and not to the operation of the 374 computation algorithms which are out of scope for all PCEP work. 376 Mechanisms for verifying the correct operation of computation 377 algorithms might involve comparing the results returned by more than 378 one PCE. Scope for this might be limited by the use of vendor 379 information unless multiple PCEs support the same set of vendor 380 information. 382 6.5. Requirements on Other Protocols and Functional Components 384 This document does not place any new requirements on other network 385 components or protocols. However, it may be beneficial to consider 386 whether a PCE should advertise the Enterprise Numbers and vendor 387 information it supports. This advertisement could be within PCE 388 Discovery ([RFC5088], [RFC5089]) or through extensions to PCEP 389 [RFC5440]. 391 Extensions for discovery and advertisement are outside the scope of 392 this document. 394 6.6. Impact on Network Operation 396 The availability of vendor information in PCEP messages may 397 facilitate more complex and detailed path computations that may 398 enhance the way in which the network is operated. 400 On the other hand, the presence of additional vendor-specific 401 information in PCEP messages may congest the operation of the 402 protocol especially if the PCE does not support the information 403 supplied by the PCC. Thus, a PCC SHOULD monitor the capabilities of 404 a PCE either by discovery mechanisms as described in Section 6.5, or 405 through the receipt of negative responses. A PCC SHOULD NOT include 406 vendor information in a PCReq message to a PCE that it believes does 407 not support the information and that will not forward the request to 408 some other PCE that does support the information. 410 7. Security Considerations 412 The protocol extensions defined in this document do not 413 substantially change the nature of PCEP. Therefore, the security 414 considerations set out in [RFC5440] apply unchanged. Note that 415 further security considerations for the use of PCEP over TCP are 416 presented in [RFC6952]. 418 Operators should note that an attack on PCEP may involve making PCEP 419 messages as large as possible in order to consume bandwidth and 420 processing power. The Vendor Information object and TLV may provide 421 a vector for this type of attack. It may be protected against by 422 using the authentication and integrity procedures described in 423 [RFC5440]. 425 8. References 427 8.1. Normative References 429 [RFC2119] S. Bradner, "Key words for use in RFCs to indicate 430 requirements levels", RFC 2119, March 1997. 432 [RFC5440] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E., 433 Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation 434 Element (PCE) communication Protocol (PCEP)", RFC 5440, 435 March 2009. 437 [RFC5511] Farrel, A., "Reduced Backus-Naur Form (RBNF): A Syntax to 438 Form Encoding Rules in Various Routing Protocol 439 Specifications", RFC 5511, April 2007. 441 [RFC6006] Q. Zhao, et al., "Extensions to the Path Computation 442 Element Communication Protocol (PCEP) for Point-to- 443 Multipoint Traffic Engineering Label Switched Paths", RFC 444 6006, September 2009. 446 8.2. Informative References 448 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 449 "Structure of Management Information Version 2 (SMIv2)", 450 STD 58, RFC 2578, April 1999. 452 [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 453 Element (PCE) Architecture", RFC 4655, August 2006. 455 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 456 Communication Protocol Generic Requirements", RFC 4657, 457 September 2006. 459 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 460 "OSPF Protocol Extensions for Path Computation Element 461 (PCE) Discovery", RFC 5088, January 2008. 463 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 464 "IS-IS Protocol Extensions for Path Computation Element 465 (PCE) Discovery", RFC 5089, January 2008. 467 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 468 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 469 May 2008. 471 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Objective 472 Function Encoding in Path Computation Element 473 Communication and Discovery protocols", RFC 5541, June 474 2009. 476 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 477 Management of New Protocols and Protocol Extensions", RFC 478 5706, November 2009. 480 [RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path 481 Computation Element (PCE) Working Group Drafts", RFC 6123, 482 February 2011. 484 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 485 BGP, LDP, PCEP, and MSDP Issues According to the Keying and 486 Authentication for Routing Protocols (KARP) Design Guide", 487 RFC 6952, May 2013. 489 [PCE-MIB] Stephan, E. and K. Koushik, "PCE Communication Protocol 490 (PCEP) Management Information Base", draft-ietf-pce-pcep- 491 mib, work in progress. 493 9. Acknowledgements 495 Thanks to Meral Shirazipour, Ramon Casellas, Cyril Margaria, Dhruv 496 Dhody, and Julien Meuric for review and comments. 498 10. Authors' Addresses 500 Adrian Farrel 501 Juniper Networks 502 EMail: adrian@olddog.co.uk 504 Fatai Zhang 505 Huawei Technologies 506 EMail: zhangfatai@huawei.com 508 11. Contributors 510 Greg Bernstein 511 Grotto Networking 512 EMail: gregb@grotto-networking.com 514 Ina Minei 515 Juniper Networks 516 EMail: ina@juniper.net