idnits 2.17.1 draft-ietf-pce-of-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- 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) ** Downref: Normative reference to an Informational RFC: RFC 4655 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J.L. Le Roux 2 Internet Draft France Telecom 3 Category: Standard Track 4 Created: December 27, 2008 J.P. Vasseur 5 Expires: June 27, 2009 Cisco System Inc. 7 Y. Lee 8 Huawei 10 Encoding of Objective Functions in the Path Computation Element 11 Communication Protocol (PCEP) 13 draft-ietf-pce-of-06.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with 18 the provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 The computation of one or a set of Traffic Engineering Label Switched 38 Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and 39 Generalized MPLS (GMPLS) networks, is subject to a set of one or more 40 specific optimization criteria, referred to as objective functions 41 (e.g. minimum cost path, widest path, etc.). 43 In the Path Computation Element (PCE) architecture, a Path 44 Computation Client (PCC) may want a path to be computed for one or 45 more TE LSPs according to a specific objective function. Thus, the 46 PCC needs to instruct the PCE to use the correct objective function. 47 Furthermore, it is possible that not all PCEs support the same set of 48 objective functions, therefore it is useful for the PCC to be able to 49 automatically discover the set of objective functions supported by 50 each PCE. 52 This document defines extensions to the PCE communication Protocol 53 (PCEP) to allow a PCE to indicate the set of objective functions it 54 supports. Extensions are also defined so that a PCC can indicate in 55 a path computation request the required objective function, and so 56 that a PCE can report in a path computation reply the objective 57 function that was used for path computation. 59 This document defines objective function code types for six 60 objective functions previously listed in the PCE requirments work, 61 and provides the definition of four new metric types that apply to a 62 set of synchronized requests. 64 Table of Contents 66 1. Introduction................................................3 67 1.1. Terminology.................................................4 68 1.2. Message Formats.............................................5 69 2. Discovery of PCE Objective Functions........................5 70 2.1. OF-List TLV.................................................5 71 2.2. Elements of procedure.......................................6 72 3. Objective Function in PCEP Path Computation Request and 73 Reply Messages............................................6 74 3.1. OF Object...................................................6 75 3.1.1. Elements of Procedure.......................................7 76 3.2. Carrying The OF Object In a PCEP Message....................8 77 3.3. New RP Object Flag.........................................10 78 3.3.1. Elements Of Procedure......................................10 79 4. Objective Functions Definition.............................11 80 5. New Metric Types...........................................12 81 6. IANA Considerations........................................13 82 6.1. PCE Objective Function Sub-registry........................13 83 6.2. PCEP Code Points...........................................14 84 6.2.1. OF Object..................................................14 85 6.2.2. OF-List TLV................................................14 86 6.2.3. PCEP Error values..........................................15 87 6.2.4. RP Object Flag.............................................15 88 6.2.5. Metric Types...............................................15 89 7. Security Considerations....................................16 90 8. Manageability Considerations...............................16 91 8.1. Control of Function and Policy.............................16 92 8.2. Information and Data Models................................16 93 8.3. Liveness Detection and Monitoring..........................16 94 8.4. Verify Correct Operations..................................17 95 8.5. Requirements On Other Protocols............................17 96 8.6. Impact On Network Operations...............................17 97 9. Acknowledgments............................................17 98 10. References.................................................17 99 10.1. Normative Feferences.......................................17 100 10.2. Informative References.....................................17 101 11. Authors' Addresses.........................................18 103 Conventions used in this document 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 1. Introduction 111 The Path Computation Element-based network architecture [RFC4655] 112 defines a Path Computation Element (PCE) as an entity capable of 113 computing the paths of Traffic Engineered Label Switched Paths (TE 114 LSPs) based on a network graph, and applying computational 115 constraints. A PCE services path computation requests sent by Path 116 Computation Clients (PCC). 118 The PCE communication Protocol (PCEP), defined in [PCEP], allows for 119 communication between a PCC and a PCE or between two PCEs, in 120 compliance with requirements and guidelines set forth in [RFC4657]. 121 Such interactions include path computation requests and path 122 computation replies. 124 The computation of one or a set of TE LSPs is subject to a set of one 125 or more optimization criteria, called an objective function. An 126 objective function is used by the PCE, when it computes a path or a 127 set of paths, in order to select the "best" candidate paths. There is 128 a variety of objective functions: an objective function could apply 129 either to a set of non-synchronized path computation requests, or to 130 a set of synchronized path computation requests. In the former case, 131 the objective function refers to an individual path computation 132 request (e.g. computation of the shortest constrained path where the 133 metric is the IGP metric, computation of the least loaded constrained 134 path, etc.). Conversely in the latter case, the objective function 135 refers to a set of path computation requests the computation of which 136 is synchronized (e.g., minimize the aggregate bandwidth consumption 137 of all LSPs, minimize the sum of the delays for two diverse paths, or 138 the delta between those delays, etc.). Moreover, some objective 139 functions relate to the optimization of a single metric and others to 140 the optimization of a set of metrics (organized in a hierarchical 141 manner, using a weighted function, etc.). 143 As spelled out in [RFC4674], it may be useful for a PCC to discover 144 the set of objective functions supported by a PCE. Furthermore, 145 [RFC4657] requires the ability for a PCC to indicate in a path 146 computation request a required/desired objective function, as well as 147 optional function parameters. 149 For these purposes, this document extends the PCE communication 150 Protocol (PCEP). It defines PCEP extensions allowing a PCE to 151 advertise a list of supported objective functions, as well as 152 extensions to carry the objective function in PCEP request and reply 153 messages. It complements the PCEP base specification [PCEP]. 155 Note that IS-IS and OSPF-based PCE Discovery mechanisms are defined 156 in ([RFC5089], [RFC5088]). These mechanisms are dedicated to the 157 discovery of a few generic parameters while more detailed PCE 158 parameters should be discovered using the PCE communication Protocol. 159 Objective functions are in this second category; thus the Objective 160 Function discovery procedure is handled by PCEP. 162 A new PCEP TLV, named the OF-List TLV is defined in Section 2. The 163 OF-List TLV is carried in the PCEP OPEN object and allows a PCE to 164 list, during PCEP session setup phase, the objective functions that 165 it supports. 167 A new PCEP object, the OF object, is defined in Section 3. The OF 168 object is carried within a PCReq message to indicate the 169 required/desired objective function to be applied by a PCE, or in a 170 PCRep message to indicate the objective function that was used for 171 path computation. 173 Six mandatory objective functions that must be supported by PCEP are 174 listed in [RFC4657]. This document provides a definition of these six 175 mandatory objective functions. Additional objective functions may be 176 defined in other documents. Note that additional objective functions 177 are defined for PCE Global Concurrent Optimization (GCO) application, 178 in [PCE-GCO]. 180 This document also provides the definition of four new metric types 181 that apply to a set of synchronized requests. 183 1.1. Terminology 185 LSR: Label Switching Router. 187 OF: Objective Function: A set of one or more optimization criteria 188 used for the computation of a single path (e.g. path cost 189 minimization), or the synchronized computation of a set of paths 190 (e.g., aggregate bandwidth consumption minimization, etc.). 192 PCC: Path Computation Client: Any client application requesting a 193 path computation to be performed by a Path Computation Element. 195 PCE: Path Computation Element: An entity (component, application, or 196 network node) that is capable of computing a network path or route 197 based on a network graph, and applying computational constraints. 199 PCEP: Path Computation Element communication Protocol. 201 TE LSP: Traffic Engineered Label Switched Path. 203 1.2. Message Formats 205 Message formats in this document are expressed using Reduced BNF as 206 used in [PCEP] and defined in [RBNF]. 208 2. Discovery of PCE Objective Functions 210 This section defines PCEP extensions (see [PCEP]) so as to support 211 the advertisement of the objective functions supported by a PCE. 213 A new PCEP OF-List (Objective Function list) TLV is defined. The PCEP 214 OF-List TLV is carried within an OPEN object, in order for a PCE to 215 advertise to a PCEP peer the list of objective functions it supports, 216 during PCEP session setup phase. 218 2.1. OF-List TLV 220 The PCEP OF-List TLV is optional. It MAY be carried within an OPEN 221 object sent by a PCE in an Open message to a PCEP peer, so as to 222 indicate the list of supported objective functions. 224 The OF-List TLV format is compliant with the PCEP TLV format defined 225 in [PCEP]. That is, the TLV is composed of 2 octets for the type, 2 226 octets specifying the TLV length, and a value field. The Length field 227 defines the length of the value portion in octets. The TLV is padded 228 to four-octet alignment and padding is not included in the Length 229 field (e.g. a three octet value would have a length of three, but the 230 total size of the TLV would be eight octets). 232 The PCEP OF-List TLV has the following format: 234 TYPE: To be assigned by IANA (suggested value = 4 ) 235 LENGTH: N * 2 (where N is the number of objective functions) 236 VALUE: list of 2-bytes objective function code points, identifying 237 the objective functions supported by the sender of the Open message. 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | OF Code #1 | OF Code #2 | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 // // 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | OF Code #N | padding | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 OF Code (2 bytes): Objective Function code point identifier. 251 IANA is requested to manage the PCE objective function code point 252 registry (see Section 6). 254 2.2. Elements of procedure 256 A PCE MAY include an OF-List TLV within an OPEN object in an Open 257 message sent to a PCEP peer, to advertise a set of one or more 258 objective functions. The OF-List TLV MUST NOT appear more than once 259 in an OPEN object. If it appears more than once the PCEP session MUST 260 be rejected with error type 1 and error value 1 (PCEP session 261 establishment failure / Reception of an invalid Open message). 262 The absence of the OF-List TLV in an OPEN object MUST be interpreted 263 as an absence of information on the list of supported objective 264 functions by the PCE. 266 As specified in [PCEP], a PCEP peer that does not recognize the OF- 267 List TLV will silently ignore it. 269 3. Objective Function in PCEP Path Computation Request and Reply 270 Messages 272 This section defines PCEP extensions ([PCEP]) so as to support the 273 communication of objective functions in PCEP path computation request 274 and reply messages. A new PCEP OF (Objective Function) object is 275 defined, to be carried within a PCReq message in order for the PCC to 276 indicate the required/desired objective function. 278 The PCEP OF Object may also be carried within a PCRep message in 279 order for the PCE to indicate the objective function that was used by 280 the PCE. 282 A new flag is defined in the RP object. The flag is used in a PCReq 283 message to indicate that the PCE MUST include an OF object in the 284 PCRep message to indicate the objective function that was used during 285 path computation. 287 Also, new PCEP error types and values are defined. 289 3.1. OF Object 291 The PCEP OF (Objective Function) object is optional. It MAY be 292 carried within a PCReq message so as to indicate the desired/required 293 objective function to be applied by the PCE during path computation, 294 or within a PCRep message so as to indicate the objective function 295 that was used by the PCE during path computation. 297 The OF object format is compliant with the PCEP object format defined 298 in [PCEP]. 300 The OF Object-Class is to be assigned by IANA (recommended value=21). 301 The OF Object-Type is to be assigned by IANA (recommended value=1). 303 The format of the OF object body is: 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 |Objective Function Code(IANA) | Reserved | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | | 311 // Optional TLV(s) // 312 | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Objective Function Code (2 bytes): The identifier of the Objective 316 Function. IANA is requested to manage the PCE objective function code 317 point registry (see Section 6). 319 Reserved (2 bytes): This field MUST be set to zero on transmission 320 and MUST be ignored on receipt. 322 Optional TLVs may be defined in the future so as to encode objective 323 function parameters. 325 3.1.1. Elements of Procedure 327 To request the use of a specific objective function by the PCE, a PCC 328 includes an OF object in the PCReq message. 330 [PCEP] specifies a bit flag, referred to as the P bit, carried in the 331 common PCEP object header. The P bit is set by a PCC to mandate that 332 a PCE must take the information carried in the object into account 333 during the path computation. 335 If the P bit is set in the OF object, the objective function is 336 mandatory (required objective function) and the PCE MUST use the 337 objective function during path computation. If the P bit is clear 338 in the OF object, the objective function is optional (desired 339 objective function) and the PCE SHOULD apply the function if it is 340 supported, but MAY choose to apply a different objective function 341 according to local capabilities and policies. 343 On receipt of a PCReq message with an OF object, a PCE MUST proceed 344 as follows: 346 - If the OF object is unknown/unsupported, the PCE MUST follow 347 procedures defined in [PCEP], that is if the P bit is set, it sends 348 a PCErr message with error type 3 or 4 (Unknown / Not supported 349 object) and error value 1 or 2 (unknown / unsupported object class 350 / object type), and the related path computation request MUST be 351 discarded. If the P bit is cleared it is free to ignore the object. 353 - If the objective function is unknown / unsupported and the P bit is 354 set, the PCE MUST send a PCErr message with error type 3 or 4 355 (Unknown / Not supported Object) and error value 4 (Unrecognized / 356 Unsupported parameter), and the related path computation request 357 MUST be discarded. 359 - If the objective function is unknown / unsupported and the P bit is 360 cleared, the PCE SHOULD apply another (default) objective function. 362 - If the objective function is supported but policy does not permit 363 applying it, and the P bit is set, the PCE MUST send a PCErr 364 message with the PCEP error type "policy-violation" (type 5) and a 365 new error value "objective function not allowed" (defined in this 366 document). 368 - If the objective function is supported but policy does not allow 369 applying it, and the P bit is cleared, the PCE SHOULD apply another 370 (default) objective function. 372 - If the objective function is supported and policy allows applying 373 it, then if the P bit is set the PCE MUST apply the requested 374 objective function, else if the P bit is cleared the PCE is free to 375 apply any other objective function. 377 The default objective function may be locally configured. 379 3.2. Carrying The OF Object In a PCEP Message 381 The OF object MAY be carried within a PCReq message. If an objective 382 function is to be applied to a set of synchronized path computation 383 requests, the OF object MUST be carried just after the corresponding 384 SVEC object, and MUST NOT be repeated for each elementary request. 386 Similarly if a metric is to be applied to a set of synchronized 387 requests, the METRIC object MUST follow the SVEC object and MUST NOT 388 be repeated for each elementary request. Note that metrics applied to 389 a set of synchronized requests are defined in section 5. 391 An OF object specifying an objective function that applies to an 392 individual path computation request (non synchronized case) MUST 393 follow the RP object for which it applies. 395 The format of the PCReq message is updated as follows: 397 ::= 398 [] 399 401 where: 402 ::= 403 [] 404 [] 405 [] 407 ::= [] 409 ::= 410 411 [] 412 [] 413 [] 414 [] 415 [[]] 416 [] 417 [] 419 and where: 421 ::= [] 423 The OF object MAY be carried within a PCRep message to indicate the 424 objective function used by the PCE during path computation. 426 When the PCE wants to indicate to the PCC the objective function that 427 was used for the synchronized computation of a set of paths, the 428 PCRep message MUST include the corresponding SVEC object directly 429 followed by the OF object, which MUST NOT be repeated for each 430 elementary request. If a metric is applicable to the set of paths, 431 the METRIC object MUST directly follow the SVEC object and MUST NOT 432 be repeated for each elementary request. 434 An OF object specifying an objective function used for an individual 435 path computation (non synchronized case) MUST follow the RP object 436 for which it applies. 438 The format of the PCRep message is updated as follows: 440 ::= 441 [] 442 444 where: 446 ::= 447 [] 448 [] 449 [] 451 ::= [] 453 ::= 454 [] 455 [] 456 [] 458 ::= [] 460 ::= 461 463 and where: 465 ::= [] 466 [] 467 [] 468 [] 469 [] 471 ::= [] 473 Note: The OF object MAY be associated to a negative reply, i.e., a 474 reply with a NO-PATH object. 476 3.3. New RP Object Flag 478 In some cases, where no objective function is specified in the 479 request, or an optional objective function is desired (P flag cleared 480 in the OF object common header) but the PCE does not follow the 481 request, the PCC may desire to know the objective function that was 482 used by the PCE during path computation. To that end, a new flag is 483 defined in the RP object, named the OF flag, allowing a PCC to 484 request for the inclusion in the path computation reply of the 485 objective function that was used by the PCE during path computation. 487 The following new bit flag of the RP object is defined: 489 Objective Function (OF) flag (bit number 24) (suggested value, to be 490 assigned by IANA). When set in a PCReq message, this indicates that 491 the PCE MUST provide the applied objective function (should a path 492 satisfying the constraints be found) in the PCRep message. When set 493 in a PCRep message this indicates that the Objective Function that 494 was used during path computation is included. 496 3.3.1. Elements Of Procedure 498 If the PCC wants to know the objective function used by the PCE 499 during path computation for a given request, it sets the OF flag in 500 the RP object. 502 On receipt of a PCReq message with the OF flag in the RP object set, 503 the PCE proceeds as follows: 505 - If policy permits it MUST include in the PCRep message an OF object 506 indicating the objective function it used during path computation. 508 - If policy does not permit, it MUST send a PCErr message with the 509 PCEP error code "policy-violation" (type 5) and a new error value 510 "objective function indication not allowed" (defined in this 511 document). 513 Note that a legacy PCE might not recognize the OF flag in the RP 514 object. According to the definition of the RP object Flag Field in 515 Section 7.4.1 of [PCEP], the legacy PCE will ignore the unknown flag 516 resulting in it sending a PCRep that does not contain an OF object. 517 In this case, the PCC's beahvior is an implementation choice. The PCC 518 might: 519 - Discard the PCRep because it really wanted the OF object returned. 520 - Accept the PCRep without the knowledge of the OF that was applied. 522 Note also that these procedures can give rise to the situation where 523 a PCC receives a PCRep that contains an OF object with an Objective 524 Function identifier that the PCC does not recognize. In this 525 situation the PCC behavior is dependent on implementaiton and 526 configuration. The PCC could choose any of the following (or some 527 other action): 529 - Ignore the OF object and use the computed path. 530 - Add the Objective Function to its view of the PCE's repetoire for 531 inclusion in future computation requests. 532 - Discard the PCRep (i.e., the computed path) and send a PCReq to 533 another PCE. 534 - Discard the PCRep (i.e., the computed path) and send another PCReq 535 to the same PCE explicitly requiring the use of some other 536 Objective Function (i.e., by setting the P bit in the OF object). 538 4. Objective Functions Definition 540 Six objective functions that must be supported by PCEP are listed in 541 [RFC4657]. Objective function codes should be assigned by IANA and 542 are suggested below. 544 Objective functions are formulated using the following terminology: 546 - a network comprises a set of N links {Li, (i=1...N)} 547 - a path P is a list of K links {Lpi,(i=1...K)} 548 - metric of link L is denoted M(L), this can be the IGP metric the TE 549 metric, or any other metric. 550 - the cost of a path P is denoted C(P), where 551 C(P) = sum {M(Lpi), (i=1...K)}. 553 - residual bandwidth on link L is denoted r(L) 554 - maximum reservable bandwidth on link L is denoted R(L). 556 There are three objective functions that apply to the computation of 557 a single path: 559 Objective Function Code: 1 (suggested value, to be assigned by IANA) 560 Name: Minimum Cost Path (MCP) 561 Description: Find a path P such that C(P) is minimized. 563 Objective Function Code: 2 (suggested value, to be assigned by IANA) 564 Name: Minimum Load Path (MLP) 565 Description: Find a path P such that 566 ( Max {(R(Lpi) - r(Lpi) / R(Lpi), i=1...K } ) is minimized. 568 Objective Function Code: 3 (suggested value, to be assigned by IANA) 569 Name: Maximum residual Bandwidth Path (MBP) 570 Description: Find a path P such that ( Min { r(Lpi), i=1...K } ) is 571 maximized. 573 There are three objective functions that apply to a set of path 574 computation requests the computation of which is synchronized: 576 Objective Function Code: 4 (suggested value, to be assigned by IANA) 577 Name: Minimize aggregate Bandwidth Consumption (MBC) 578 Description: Find a set of paths such that ( Sum {R(Li) - r(Li), 579 i=1...N} ) is minimized. 581 Objective Function Code: 5 (suggested value, to be assigned by IANA) 582 Name: Minimize the Load of the most loaded Link (MLL) 583 Description: Find a set of paths such that ( Max { (R(Li) - r(Li)) / 584 R(Li), i=1...N}) is minimized. 586 Objective Function Code: 6 (suggested value, to be assigned by IANA) 587 Name: Minimize the Cumulative Cost of a set of paths (MCC) 588 Description: Find a set of paths {P1...Pm} such that (Sum { C(Pi), 589 i=1...m}) is minimized. 591 Other objective functions may be defined in separate documents. 593 5. New Metric Types 595 Three metric types are defined in PCEP for the METRIC object: TE 596 metric, IGP metric and hop count. These metric types apply to an 597 individual request. Here we define four new metric types that apply 598 to a set of synchronized requests: 600 Type 4 (suggested value to be assigned by IANA) : Aggregate 601 bandwidth consumption. 603 Type 5 (suggested value to be assigned by IANA) : Load of the most 604 loaded link. 606 Type 6 (suggested value to be assigned by IANA) : Cumulative IGP 607 cost. 609 Type 7 (suggested value to be assigned by IANA) : Cumulative TE 610 cost. 612 These metrics may be used to indicate a bound (B bit set in the 613 METRIC object) or a computed metric (C bit set in the METRIC 614 object). 616 A METRIC object with one of these four types follows the SVEC object 617 for which it applies. 619 6. IANA Considerations 621 6.1. PCE Objective Function Sub-registry 623 This document defines a 16-bit PCE Objective Function identifier to 624 be carried within the PCEP OF object, as well as the PCEP OF-List 625 TLV. 627 IANA is requested to create and manage the 16-bit "PCE Objective 628 Function" code point registry, starting from 1 and continuing through 629 32767, as follows: 631 - Objective Function code point value 632 - Objective Function name 633 - Defining RFC 635 The same registry is applicable to the OF object and the OF-List TLV 636 defined in this document. 638 The guidelines (using terms defined in [RFC5226]) for the 639 assignment of objective function code point values are as follows: 641 - Function code value 0 is reserved. 642 - Function code values in the range 1-32767 are to be assigned as 643 follows: 644 - Function code values 1 through 1023 are to be assigned by IANA 645 using the "IETF Consensus" policy. 646 - Function code values 1024 through 32767 are to be assigned by 647 IANA, using the "First Come First Served" policy. 648 - Function code values in the range 32768-65535 are for "Private 649 Use". 651 Six objective functions are defined in Section 4 of this document and 652 should be assigned by IANA: 654 Code Point Name Defining RFC 656 1 MCP this doc 657 2 MLP this doc 658 3 MBP this doc 659 4 MBC this doc 660 5 MLL this doc 661 6 MCC this doc 663 6.2. PCEP Code Points 665 6.2.1. OF Object 667 IANA manages the PCEP Objects code point registry (see [PCEP]). This 668 is maintained as the "PCEP Objects" sub-registry of the "Path 669 Computation Element Protocol (PCEP) Numbers" registry. 671 This document defines a new PCEP object, the OF object, to be carried 672 in PCReq and PCRep messages. IANA is requested to make the following 673 allocation (suggested value): 675 Object Name Object Name Reference 676 Class Type 678 21 OF 1 Objective Function (this document) 680 6.2.2. OF-List TLV 682 IANA manages the PCEP TLV code point registry (see [PCEP]). This is 683 maintained as the "PCEP TLV Type Indicators" sub-registry of the 684 "Path Computation Element Protocol (PCEP) Numbers" registry. 686 This document defines a new PCEP TLV, the OF-List TLV, to be carried 687 in the OPEN object. IANA is requested to make the following 688 allocation (suggested value): 690 Type TLV name References 691 ----- -------- ---------- 692 4 OF-List (This document) 694 6.2.3. PCEP Error values 696 IANA maintains a registry of Error-types and Error-values for use in 697 PCEP messages. This is maintained as the "PCEP-ERROR Object Error 698 Types and Values" sub-registry of the "Path Computation Element 699 Protocol (PCEP) Numbers" registry. 701 Two new Error-values are defined for the Error-type "policy 702 violation" (type 5): 704 Error-type Meaning and error values Reference 706 5 Policy violation 708 Error-value=3: objective function not (this doc) 709 allowed (request rejected) 711 Error-value=4: OF bit of the RP object (this doc) 712 set (request rejected) 714 6.2.4. RP Object Flag 716 A new flag of the RP object (specified in [PCEP]) is defined in this 717 document. IANA maintains a registry of RP object flags in the "RP 718 Object Flag Field" sub-registry of the "Path Computation Element 719 Protocol (PCEP) Numbers" registry. 721 IANA is requested to make the following allocation (suggested value): 723 Bit Description Reference 725 24 Supply OF on response This document 727 6.2.5. Metric Types 729 Four new metric types are defined in this document for the METRIC 730 object (specified in [PCEP]). IANA maintains a registry of metric 731 types in the "METRIC Object T Field" sub-registry of the "Path 732 Computation Element Protocol (PCEP) Numbers" registry. 734 IANA is requested to make the following allocation (suggested 735 values): 737 - Type 4 : Aggregate bandwidth consumption 738 - Type 5 : Load of the most loaded link 739 - Type 6 : Cumulative IGP cost 740 - Type 7 : Cumulative TE cost 742 7. Security Considerations 744 PCEP security mechanisms are described in [PCEP] and are used to 745 secure entire PCEP messages. Nothing in this document changes the 746 message flows or introduces any new messages, so the security 747 mechanisms set out in [PCEP] continue to be applicable. 749 This document introduces a single new object that may optionally be 750 carried on PCEP messages and will be automatically secured using the 751 mechanims described in [PCEP]. 753 If a PCEP message is vulnerable to attack, for example because the 754 security mechanisms are not used, then the OF object could be used as 755 part of an attack, however, it is likely that other objects will 756 provide far more significant ways of attacking a PCE or PCC in this 757 case. 759 8. Manageability Considerations 761 8.1. Control of Function and Policy 763 It MUST be possible to configure the activation/deactivation of 764 Objective Function Discovery in PCEP. 766 In addition to the parameters already listed in section 8.1 of 767 [PCEP], a PCEP implementation SHOULD allow configuring on a PCE a 768 list of authorized objective functions. This may apply to any session 769 the PCEP speaker participates in, to a specific session with a given 770 PCEP peer or to a specific group of sessions with a specific group of 771 PCEP peers. 773 Note that it is not mandatory for an implementation to support all 774 objective functions defined in Section 4. 776 It MUST be possible to configure a default objective function used 777 for path computation when a path request is received that requests to 778 use an optional objective function. 780 8.2. Information and Data Models 782 The PCEP MIB Module defined in [PCEP-MIB] could be extended to 783 include Objective Functions. 785 8.3. Liveness Detection and Monitoring 787 Mechanisms defined in this document do not imply any new liveness 788 detection and monitoring requirements in addition to those already 789 listed in [PCEP]. 791 8.4. Verify Correct Operations 793 Mechanisms defined in this document do not imply any new operation 794 verification requirements in addition to those already listed in 795 [PCEP]. 797 8.5. Requirements On Other Protocols 799 Mechanisms defined in this document do not imply any requirements on 800 other protocols in addition to those already listed in [PCEP]. 802 8.6. Impact On Network Operations 804 Mechanisms defined in this document do not have any impact on network 805 operations in addition to those already listed in [PCEP]. 807 9. Acknowledgments 809 The authors would like to thank Jerry Ash, Fabien Verhaeghe, 810 Robert Sparks, and Adrian Farrel for their useful comments. 812 10. References 814 10.1. Normative References 816 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 817 Requirement Levels", BCP 14, RFC 2119, March 1997. 819 [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 820 Element (PCE)-based Architecture", RFC4655, august 2006. 822 [PCEP] Vasseur, Le Roux, et al., "Path Computation Element (PCE) 823 communication Protocol (PCEP)", draft-ietf-pce-pcep, work 824 in progress. 826 10.2. Informative References 828 [RFC4657] Ash, J., Le Roux, J.L., " PCE Communication Protocol 829 Generic Requirements", RFC4657, September 2006. 831 [RFC4674] Le Roux, J.L., et al. "Requirements for PCE discovery", 832 RFC4674, October 2006. 834 [RFC5088] Le Roux, Vasseur, et al. "OSPF protocol extensions for 835 Path Computation Element (PCE) Discovery", RFC5088, January 836 2008. 838 [RFC5089] Le Roux, Vasseur, et al. "IS-IS protocol extensions for 839 Path Computation Element (PCE) Discovery", RFC5089, January 840 2008. 842 [RFC5226] Narten, T. and Alverstrand, H., "Guidelines for Writing an 843 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 844 2008. 846 [PCE-GCO] Y. Lee, J.L. Le Roux, D. King, and E. Oki, "Path 847 Computation Element Communication Protocol (PCECP) 848 Requirements and Protocol Extensions In Support of Global 849 Concurrent Optimization", draft-ietf-pce-global-concurrent- 850 optimization, work in progress. 852 [PCEP-MIB] Koushik, K., and Stephan, E., "PCE communication protocol 853 (PCEP) Management Information Base", draft-kkoushik-pce- 854 pcep-mib, work in progress. 856 [RBNF] A. Farrel, "Reduced Backus-Naur Form (RBNF) - A Syntax Used 857 in Various Protocol Specifications", draft-farrel-rtg- 858 common-bnf, work in progress. 860 11. Authors' Addresses 862 Jean-Louis Le Roux 863 France Telecom 864 2, avenue Pierre-Marzin 865 22307 Lannion Cedex 866 FRANCE 867 Email: jeanlouis.leroux@orange-ftgroup.com 869 Jean-Philippe Vasseur 870 Cisco Systems, Inc. 871 1414 Massachusetts avenue 872 Boxborough , MA - 01719 873 USA 874 Email: jpv@cisco.com 876 Young Lee 877 Huawei Technologies, LTD. 878 1700 Alma Drive, Suite 100 879 Plano, TX 75075 880 USA 881 Email: ylee@huawei.com 883 Full Copyright Statement 885 Copyright (c) 2008 IETF Trust and the persons identified as the 886 document authors. All rights reserved. 888 This document is subject to BCP 78 and the IETF Trust's Legal 889 Provisions Relating to IETF Documents 890 (http://trustee.ietf.org/license-info) in effect on the date of 891 publication of this document. Please review these documents 892 carefully, as they describe your rights and restrictions with respect 893 to this document. 895 All IETF Documents and the information contained therein are provided 896 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 897 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 898 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 899 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 900 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 901 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 902 FOR A PARTICULAR PURPOSE. 904 Intellectual Property 906 The IETF Trust takes no position regarding the validity or scope of 907 any Intellectual Property Rights or other rights that might be 908 claimed to pertain to the implementation or use of the technology 909 described in any IETF Document or the extent to which any license 910 under such rights might or might not be available; nor does it 911 represent that it has made any independent effort to identify any 912 such rights. 914 Copies of Intellectual Property disclosures made to the IETF 915 Secretariat and any assurances of licenses to be made available, or 916 the result of an attempt made to obtain a general license or 917 permission for the use of such proprietary rights by implementers or 918 users of this specification can be obtained from the IETF on-line IPR 919 repository at http://www.ietf.org/ipr 921 The IETF invites any interested party to bring to its attention any 922 copyrights, patents or patent applications, or other proprietary 923 rights that may cover technology that may be required to implement 924 any standard or specification contained in an IETF Document. Please 925 address the information to the IETF at ietf-ipr@ietf.org. 927 The definitive version of an IETF Document is that published by, or 928 under the auspices of, the IETF. Versions of IETF Documents that are 929 published by third parties, including those that are translated into 930 other languages, should not be considered to be definitive versions 931 of IETF Documents. The definitive version of these Legal Provisions 932 is that published by, or under the auspices of, the IETF. Versions of 933 these Legal Provisions that are published by third parties, including 934 those that are translated into other languages, should not be 935 considered to be definitive versions of these Legal Provisions. 937 For the avoidance of doubt, each Contributor to the IETF Standards 938 Process licenses each Contribution that he or she makes as part of 939 the IETF Standards Process to the IETF Trust pursuant to the 940 provisions of RFC 5378. No language to the contrary, or terms, 941 conditions or rights that differ from or are inconsistent with the 942 rights and licenses granted under RFC 5378, shall have any effect and 943 shall be null and void, whether published or posted by such 944 Contributor, or included with or in such Contribution.