idnits 2.17.1 draft-ietf-pce-of-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 852. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 828. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 835. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 841. 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 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 (==), 8 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: August 5, 2008 J.P. Vasseur 5 Expires: February 5, 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-04.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 The computation of one or a set of Traffic Engineering Label Switched 40 Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and 41 Generalized MPLS (GMPLS) networks, is subject to a set of one or more 42 specific optimization criteria, referred to as objective functions 43 (e.g. minimum cost path, widest path, etc.). 45 In the Path Computation Element (PCE) architecture, a Path 46 Computation Client (PCC) may want a path to be computed for one or 47 more TE LSPs according to a specific objective function. Thus, the 48 PCC needs to instruct the PCE to use the correct objective function. 49 Furthermore, it is possible that not all PCEs support the same set of 50 objective functions, therefore it is useful for the PCC to be able to 51 automatically discover the set of objective functions supported by 52 each PCE. 54 This document defines extensions to the PCE communication Protocol 55 (PCEP) to allow a PCE to indicate the set of objective functions it 56 supports. Extensions are also defined so that a PCC can indicate in 57 a path computation request the required objective function, and so 58 that a PCE can report in a path computation reply the objective 59 function that was used for path computation. 61 Table of Contents 63 1. Introduction................................................3 64 1.1. Terminology.................................................4 65 2. Discovery of PCE Objective Functions........................5 66 2.1. OF-List TLV.................................................5 67 2.2. Elements of procedure.......................................6 68 3. Objective Function in PCEP Path Computation Request and 69 Reply Messages............................................6 70 3.1. OF Object...................................................6 71 3.1.1. Elements of Procedure.......................................7 72 3.2. Carrying The OF Object In a PCEP Message....................8 73 3.3. New RP Object Flag.........................................10 74 3.3.1. Elements Of Procedure......................................10 75 4. Objective Functions Definition.............................11 76 5. New Metric Types...........................................12 77 6. IANA Considerations........................................13 78 6.1. PCE Objective Function Sub-registry........................13 79 6.2. PCEP Code Points...........................................13 80 6.2.1. OF Object..................................................13 81 6.2.2. OF-List TLV................................................14 82 6.2.3. PCEP Error values..........................................14 83 6.2.4. RP Object Flag.............................................14 84 6.2.5. Metric Types...............................................15 85 7. Security Considerations....................................15 86 8. Manageability Considerations...............................15 87 8.1. Control of Function and Policy.............................15 88 8.2. Information and Data Models................................15 89 8.3. Liveness Detection and Monitoring..........................15 90 8.4. Verify Correct Operations..................................16 91 8.5. Requirements On Other Protocols............................16 92 8.6. Impact On Network Operations...............................16 93 9. Acknowledgments............................................16 94 10. References.................................................16 95 10.1. Normative Feferences.......................................16 96 10.2. Informative References.....................................16 97 11. Authors' Addresses.........................................17 98 12. Intellectual Property Statement............................17 100 Conventions used in this document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 1. Introduction 108 The Path Computation Element-based network architecture [RFC4655] 109 defines a Path Computation Element (PCE) as an entity capable of 110 computing the paths of Traffic Engineered Label Switched Paths (TE 111 LSPs) based on a network graph, and applying computational 112 constraints. A PCE services path computation requests sent by Path 113 Computation Clients (PCC). 115 The PCE communication Protocol (PCEP), defined in [PCEP], allows for 116 communication between a PCC and a PCE or between two PCEs, in 117 compliance with requirements and guidelines set forth in [RFC4657]. 118 Such interactions include path computation requests and path 119 computation replies. 121 The computation of one or a set of TE LSPs is subject to a set of one 122 or more optimization criteria, called an objective function. An 123 objective function is used by the PCE, when it computes a path or a 124 set of paths, in order to select the "best" candidate paths. There is 125 a variety of objective functions: an objective function could apply 126 either to a set of non-synchronized path computation requests, or to 127 a set of synchronized path computation requests. In the former case, 128 the objective function refers to an individual path computation 129 request (e.g. computation of the shortest constrained path where the 130 metric is the IGP metric, computation of the least loaded constrained 131 path, etc.). Conversely in the latter case, the objective function 132 refers to a set of path computation requests the computation of which 133 is synchronized (e.g., minimize the aggregate bandwidth consumption 134 of all LSPs, minimize the sum of the delays for two diverse paths, or 135 the delta between those delays, etc.). Moreover, some objective 136 functions relate to the optimization of a single metric and others to 137 the optimization of a set of metrics (organized in a hierarchical 138 manner, using a weighted function, etc.). 140 As spelled out in [RFC4674], it may be useful for a PCC to discover 141 the set of objective functions supported by a PCE. Furthermore, 142 [RFC4657] requires the ability for a PCC to indicate in a path 143 computation request a required/desired objective function, as well as 144 optional function parameters. 146 For these purposes, this document extends the PCE communication 147 Protocol (PCEP). It defines PCEP extensions allowing a PCE to 148 advertise a list of supported objective functions, as well as 149 extensions to carry the objective function in PCEP request and reply 150 messages. It complements the PCEP base specification [PCEP]. 152 Note that IS-IS and OSPF-based PCE Discovery mechanisms are defined 153 in ([RFC5089], [RFC5088]). These mechanisms are dedicated to the 154 discovery of a few generic parameters while more detailed PCE 155 parameters should be discovered using the PCE communication Protocol. 156 Objective functions are in this second category; thus the Objective 157 Function discovery procedure is handled by PCEP. 159 A new PCEP TLV, named the OF-List TLV is defined in Section 2. The 160 OF-List TLV is carried in the PCEP OPEN object and allows a PCE to 161 list, during PCEP session setup phase, the objective functions that 162 it supports. 164 A new PCEP object, the OF object, is defined in Section 3. The OF 165 object is carried within a PCReq message to indicate the 166 required/desired objective function to be applied by a PCE, or in a 167 PCRep message to indicate the objective function that was used for 168 path computation. 170 Six mandatory objective functions that must be supported by PCEP are 171 listed in [RFC4657]. This document provides a definition of these six 172 mandatory objective functions. Additional objective functions may be 173 defined in other documents. Note that additional objective functions 174 are defined for PCE Global Concurrent Optimization (GCO) application, 175 in [PCE-GCO]. 177 This document also provides the definition of four new metric types 178 that apply to a set of synchronized requests. 180 1.1. Terminology 182 LSR: Label Switching Router. 184 OF: Objective Function: A set of one or more optimization criteria 185 used for the computation of a single path (e.g. path cost 186 minimization), or the synchronized computation of a set of paths 187 (e.g., aggregate bandwidth consumption minimization, etc.). 189 PCC: Path Computation Client: Any client application requesting a 190 path computation to be performed by a Path Computation Element. 192 PCE: Path Computation Element: An entity (component, application, or 193 network node) that is capable of computing a network path or route 194 based on a network graph, and applying computational constraints. 196 PCEP: Path Computation Element communication Protocol. 198 TE LSP: Traffic Engineered Label Switched Path. 200 2. Discovery of PCE Objective Functions 202 This section defines PCEP extensions (see [PCEP]) so as to support 203 the advertisement of the objective functions supported by a PCE. 205 A new PCEP OF-List (Objective Function list) TLV is defined. The PCEP 206 OF-List TLV is carried within an OPEN object, in order for a PCE to 207 advertise to a PCEP peer the list of objective functions it supports, 208 during PCEP session setup phase. 210 2.1. OF-List TLV 212 The PCEP OF-List TLV is optional. It MAY be carried within an OPEN 213 object sent by a PCE in an Open message to a PCEP peer, so as to 214 indicate the list of supported objective functions. 216 The OF-List TLV format is compliant with the PCEP TLV format defined 217 in [PCEP]. That is, the TLV is composed of 2 octets for the type, 2 218 octets specifying the TLV length, and a value field. The Length field 219 defines the length of the value portion in octets. The TLV is padded 220 to four-octet alignment and padding is not included in the Length 221 field (e.g. a three octet value would have a length of three, but the 222 total size of the TLV would be eight octets). 224 The PCEP OF-List TLV has the following format: 226 TYPE: To be assigned by IANA (suggested value = 4 ) 227 LENGTH: N * 2 (where N is the number of objective functions) 228 VALUE: list of 2-bytes objective function code points, 229 identifying the objective functions supported by the 230 sender of the Open message. 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | OF Code #1 | OF Code #2 | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 // // 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | OF Code #N | padding | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 OF Code (2 bytes): Objective Function code point identifier. 244 IANA is requested to manage the PCE objective function code point 245 registry (see Section 6). 247 2.2. Elements of procedure 249 A PCE MAY include an OF-List TLV within an OPEN object in an Open 250 message sent to a PCEP peer, to advertise a set of one or more 251 objective functions. The OF-List TLV MUST NOT appear more than once 252 in an OPEN object. If it appears more than once the PCEP session MUST 253 be rejected with error type 1 and error value 1 (PCEP session 254 establishment failure / Reception of an invalid Open message). 255 The absence of the OF-List TLV in an OPEN object MUST be interpreted 256 as an absence of information on the list of supported objective 257 functions by the PCE. 259 As specified in [PCEP], a PCEP peer that does not recognize the OF- 260 List TLV will silently ignore it. 262 3. Objective Function in PCEP Path Computation Request and Reply 263 Messages 265 This section defines PCEP extensions ([PCEP]) so as to support the 266 communication of objective functions in PCEP path computation request 267 and reply messages. A new PCEP OF (Objective Function) object is 268 defined, to be carried within a PCReq message in order for the PCC to 269 indicate the required/desired objective function. 271 The PCEP OF Object may also be carried within a PCRep message in 272 order for the PCE to indicate the objective function that was used by 273 the PCE. 275 A new flag is defined in the RP object. The flag is used in a PCReq 276 message to indicate that the PCE MUST include an OF object in the 277 PCRep message to indicate the objective function that was used during 278 path computation. 280 Also, new PCEP error types and values are defined. 282 3.1. OF Object 284 The PCEP OF (Objective Function) object is optional. It MAY be 285 carried within a PCReq message so as to indicate the desired/required 286 objective function to be applied by the PCE during path computation, 287 or within a PCRep message so as to indicate the objective function 288 that was used by the PCE during path computation. 290 The OF object format is compliant with the PCEP object format defined 291 in [PCEP]. 293 The OF Object-Class is to be assigned by IANA (recommended value=21). 294 The OF Object-Type is to be assigned by IANA (recommended value=1). 296 The format of the OF object body is: 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 |Objective Function Code(IANA) | Reserved | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | | 304 // Optional TLV(s) // 305 | | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Objective Function Code (2 bytes): The identifier of the Objective 309 Function. The IANA is requested to manage the PCE objective function 310 code point registry (see Section 6). 312 Reserved (2 bytes): This field MUST be set to zero on transmission 313 and MUST be ignored on receipt. 315 Optional TLVs may be defined in the future so as to encode objective 316 function parameters. 318 3.1.1. Elements of Procedure 320 To request the use of a specific objective function by the PCE, a PCC 321 includes an OF object in the PCReq message. 323 [PCEP] specifies a bit flag, referred to as the P bit, carried in the 324 common PCEP object header. The P bit is set by a PCC to mandate that 325 a PCE must take the information carried in the object into account 326 during the path computation. 328 If the P bit is set in the OF object, the objective function is 329 mandatory (required objective function) and the PCE MUST use the 330 objective function during path computation. If the P bit is clear 331 in the OF object, the objective function is optional (desired 332 objective function) and the PCE SHOULD apply the function if it is 333 supported, but MAY choose to apply a different objective function 334 according to local capabilities and policies. 336 On receipt of a PCReq message with an OF object, a PCE MUST proceed 337 as follows: 339 - If the OF object is unknown/unsupported, the PCE MUST follow 340 procedures defined in [PCEP], that is if the P bit is set, it sends 341 a PCErr message with error type 3 or 4 (Unknown / Not supported 342 object) and error value 1 or 2 (unknown / unsupported object class 343 / object type), and the related path computation request MUST be 344 discarded. If the P bit is cleared it is free to ignore the object. 346 - If the objective function is unknown / unsupported and the P bit is 347 set, the PCE MUST send a PCErr message with error type 3 or 4 348 (Unknown / Not supported Object) and error value 4 (Unrecognized / 349 Unsupported parameter), and the related path computation request 350 MUST be discarded. 352 - If the objective function is unknown / unsupported and the P bit is 353 cleared, the PCE SHOULD apply another (default) objective function. 355 - If the objective function is supported but policy does not permit 356 applying it, and the P bit is set, the PCE MUST send a PCErr 357 message with the PCEP error type "policy-violation" (type 5) and a 358 new error value "objective function not allowed" (defined in this 359 document). 361 - If the objective function is supported but policy does not allow 362 applying it, and the P bit is cleared, the PCE SHOULD apply another 363 (default) objective function. 365 - If the objective function is supported and policy allows applying 366 it, then if the P bit is set the PCE MUST apply the requested 367 objective function, else if the P bit is cleared the PCE is free to 368 apply any other objective function. 370 The default objective function may be locally configured. 372 3.2. Carrying The OF Object In a PCEP Message 374 The OF object MAY be carried within a PCReq message. If an objective 375 function is to be applied to a set of synchronized path computation 376 requests, the OF object MUST be carried just after the corresponding 377 SVEC object, and MUST NOT be repeated for each elementary request. 379 Similarly if a metric is to be applied to a set of synchronized 380 requests, the METRIC object MUST follow the SVEC object and MUST NOT 381 be repeated for each elementary request. Note that metrics applied to 382 a set of synchronized requests are defined in section 5. 384 An OF object specifying an objective function that applies to an 385 individual path computation request (non synchronized case) MUST 386 follow the RP object for which it applies. 388 The format of the PCReq message is updated as follows: 390 ::= 391 [] 392 394 where: 395 ::= 396 [] 397 [] 398 [] 400 ::= [] 402 ::= 403 404 [] 405 [] 406 [] 407 [] 408 [] 409 [] 410 [] 412 and where: 414 ::= [] 416 The OF object MAY be carried within a PCRep message to indicate the 417 objective function used by the PCE during path computation. 419 When the PCE wants to indicate to the PCC the objective function that 420 was used for the synchronized computation of a set of paths, the 421 PCRep message MUST include the corresponding SVEC object directly 422 followed by the OF object, which MUST NOT be repeated for each 423 elementary request. If a metric is applicable to the set of paths, 424 the METRIC object MUST directly follow the SVEC object and MUST NOT 425 be repeated for each elementary request. 427 An OF object specifying an objective function used for an individual 428 path computation (non synchronized case) MUST follow the RP object 429 for which it applies. 431 The format of the PCRep message is updated as follows: 433 ::= 434 [] 435 437 where: 439 ::= 440 [] 441 [] 442 [] 444 ::= [] 446 ::= 447 [] 448 [] 450 ::= [] 452 ::= 453 [] 454 [] 455 [] 456 [] 457 [] 459 and where: 461 ::= [] 463 Note: The OF object MAY be associated to a negative reply, i.e., a 464 reply with a NO-PATH object. 466 3.3. New RP Object Flag 468 In some cases, where no objective function is specified in the 469 request, or an optional objective function is desired (P flag cleared 470 in the OF object common header) but the PCE does not follow the 471 request, the PCC may desire to know the objective function that was 472 used by the PCE during path computation. To that end, a new flag is 473 defined in the RP object, named the OF flag, allowing a PCC to 474 request for the inclusion in the path computation reply of the 475 objective function that was used by the PCE during path computation. 477 The following new bit flag of the RP object is defined: 479 Objective Function (OF) flag (1 bit): 0x200 (bit number 16) 480 (suggested value, to be assigned by IANA). When set in a PCReq 481 message, this indicates that the PCE MUST provide the applied 482 objective function (should a path satisfying the constraints be 483 found) in the PCRep message. When set in a PCRep message this 484 indicates that the Objective Function that was used during path 485 computation is included. 487 3.3.1. Elements Of Procedure 489 If the PCC wants to know the objective function used by the PCE 490 during path computation for a given request, it sets the OF flag in 491 the RP object. 493 On receipt of a PCReq message with the OF flag in the RP object set, 494 the PCE proceeds as follows: 496 - If policy permits it MUST include in the PCRep message an OF object 497 indicating the objective function it used during path computation. 499 - If policy does not permit, it MUST send a PCErr message with the 500 PCEP error code "policy-violation" (type 5) and a new error value 501 "objective function indication not allowed" (defined in this 502 document). 504 4. Objective Functions Definition 506 Six objective functions that must be supported by PCEP are listed in 507 [RFC4657]. Objective function codes should be assigned by IANA and 508 are suggested below. 510 Objective functions are formulated using the following terminology: 512 - a network comprises a set of N links {Li, (i=1...N)} 513 - a path P is a list of K links {Lpi,(i=1...K)} 514 - metric of link L is denoted M(L), this can be the IGP metric the TE 515 metric, or any other metric. 516 - the cost of a path P is denoted C(P), where 517 C(P) = sum {M(Lpi), (i=1...K)}. 518 - residual bandwidth on link L is denoted r(L) 519 - maximum reservable bandwidth on link L is denoted R(L). 521 There are three objective functions that apply to the computation of 522 a single path: 524 Objective Function Code: 1 (suggested value, to be assigned by IANA) 525 Name: Minimum Cost Path (MCP) 526 Description: Find a path P such that C(P) is minimized. 528 Objective Function Code: 2 (suggested value, to be assigned by IANA) 529 Name: Minimum Load Path (MLP) 530 Description: Find a path P such that ( Max {(R(Lpi) - r(Lpi)) / 531 R(Lpi), i=1...K } ) is minimized 533 Objective Function Code: 3 (suggested value, to be assigned by IANA) 534 Name: Maximum residual Bandwidth Path (MBP) 535 Description: Find a path P such that ( Min { r(Lpi)), i=1...K } ) is 536 maximized. 538 There are three objective functions that apply to a set of path 539 computation requests the computation of which is synchronized: 541 Objective Function Code: 4 (suggested value, to be assigned by IANA) 542 Name: Minimize aggregate Bandwidth Consumption (MBC) 543 Description: Find a set of paths such that ( Sum {R(Li) - r(Li), 544 i=1...N} ) is minimized. 546 Objective Function Code: 5 (suggested value, to be assigned by IANA) 547 Name: Minimize the Load of the most loaded Link (MLL) 548 Description: Find a set of paths such that ( Max { (R(Li) - r(Li)) / 549 R(Li), i=1...N}) is minimized. 551 Objective Function Code: 6 (suggested value, to be assigned by IANA) 552 Name: Minimize the Cumulative Cost of a set of paths (MCC) 553 Description: Find a set of paths {P1...Pm} such that (Sum { C(Pi), 554 i=1...m}) is minimized. 556 Other objective functions may be defined in separate documents. 558 5. New Metric Types 560 Three metric types are defined in PCEP for the METRIC object: TE 561 metric, IGP metric and hop count. These metric types apply to an 562 individual request. Here we define four new metric types that apply 563 to a set of synchronized requests: 565 Type 4 (suggested value to be assigned by IANA) : Aggregate 566 bandwidth consumption. 568 Type 5 (suggested value to be assigned by IANA) : Load of the most 569 loaded link. 571 Type 6 (suggested value to be assigned by IANA) : Cumulative IGP 572 cost. 574 Type 7 (suggested value to be assigned by IANA) : Cumulative TE 575 cost. 577 These metrics may be used to indicate a bound (B bit set in the 578 METRIC object) or a computed metric (C bit set in the METRIC 579 object). 581 A METRIC object with one of these four types follows the SVEC object 582 for which it applies. 584 6. IANA Considerations 586 6.1. PCE Objective Function Sub-registry 588 This document defines a 16-bit PCE Objective Function identifier to 589 be carried within the PCEP OF object, as well as the PCEP OF-List 590 TLV. 592 IANA is requested to create and manage the 16-bit "PCE Objective 593 Function" code point registry, starting from 1 and continuing through 594 32767, as follows: 596 - Objective Function code point value 597 - Objective Function name 598 - Defining RFC 600 The same registry is applicable to the OF object and the OF-List TLV 601 defined in this document. 603 The guidelines (using terms defined in [RFC5226]) for the 604 assignment of objective function code point values are as follows: 606 - Function code value 0 is reserved. 607 - Function code values in the range 1-32767 are to be assigned as 608 follows: 609 - Function code values 1 through 1023 are to be assigned by IANA 610 using the "IETF Consensus" policy. 611 - Function code values 1024 through 32767 are to be assigned by 612 IANA, using the "First Come First Served" policy. 613 - Function code values in the range 32768-65535 are for "Private 614 Use". 616 Six objective functions are defined in Section 4 of this document and 617 should be assigned by IANA: 619 Code Point Name Defining RFC 621 1 MCP this doc 622 2 MLP this doc 623 3 MBP this doc 624 4 MBC this doc 625 5 MLL this doc 626 6 MCC this doc 628 6.2. PCEP Code Points 630 6.2.1. OF Object 632 The IANA has been requested to manage the PCEP Objects code point 633 registry (see [PCEP]). 635 This document defines a new PCEP object, the OF object, to be carried 636 in PCReq and PCRep messages. The IANA is requested to make the 637 following allocation (suggested value): 639 Object Name Object Name Reference 640 Class Type 642 21 OF 1 Objective Function (this document) 644 6.2.2. OF-List TLV 646 IANA is requested to manage the PCEP TLV code point registry (see 647 [PCEP]). 649 This document defines a new PCEP TLV, the OF-List TLV, to be carried 650 in the OPEN object. The IANA is requested to make the following 651 allocation (suggested value): 653 Type TLV name References 654 ----- -------- ---------- 655 4 OF-List (This document) 657 6.2.3. PCEP Error values 659 Two new error values are defined for the error type "policy 660 violation" (type 5): 662 Error-type Meaning and error values Reference 664 5 Policy violation (this doc) 666 Error-value=3: objective function not (this doc) 667 allowed (request rejected) 669 Error-value=4: OF bit of the RP object (this doc) 670 set (request rejected) 672 6.2.4. RP Object Flag 674 A new flag of the RP object (specified in [PCEP]) is defined in this 675 document. The IANA is requested to make the following allocation 676 (suggested value): 678 Bit Hex Name Reference 679 Number 681 16 0x200 OF (this document) 683 6.2.5. Metric Types 685 Four new metric types are defined in this document for the METRIC 686 object (specified in [PCEP]). The IANA is requested to make the 687 following allocation (suggested values): 689 - Type 4 : Aggregate bandwidth consumption 690 - Type 5 : Load of the most loaded link 691 - Type 6 : Cumulative IGP cost 692 - Type 7 : Cumulative TE cost 694 7. Security Considerations 696 Mechanisms discussed in [PCEP] to secure a PCEP session can be used 697 to secure the PCEP OF object and OF list TLV as well. 699 8. Manageability Considerations 701 8.1. Control of Function and Policy 703 It MUST be possible to configure the activation/deactivation of 704 Objective Function Discovery in PCEP. 706 In addition to the parameters already listed in section 8.1 of 707 [PCEP], a PCEP implementation SHOULD allow configuring on a PCE a 708 list of authorized objective functions. This may apply to any session 709 the PCEP speaker participates in, to a specific session with a given 710 PCEP peer or to a specific group of sessions with a specific group of 711 PCEP peers. 713 Note that it is not mandatory for an implementation to support all 714 objective functions defined in Section 4. 716 It MUST be possible to configure a default objective function used 717 for path computation when a path request is received that requests to 718 use an optional objective function. 720 8.2. Information and Data Models 722 The PCEP MIB Module defined in [PCEP-MIB] SHOULD be extended to 723 include Objective Functions. 725 8.3. Liveness Detection and Monitoring 727 Mechanisms defined in this document do not imply any new liveness 728 detection and monitoring requirements in addition to those already 729 listed in [PCEP]. 731 8.4. Verify Correct Operations 733 Mechanisms defined in this document do not imply any new operation 734 verification requirements in addition to those already listed in 735 [PCEP]. 737 8.5. Requirements On Other Protocols 739 Mechanisms defined in this document do not imply any requirements on 740 other protocols in addition to those already listed in [PCEP]. 742 8.6. Impact On Network Operations 744 Mechanisms defined in this document do not have any impact on network 745 operations in addition to those already listed in [PCEP]. 747 9. Acknowledgments 749 The authors would like to thank Jerry Ash, Fabien Verhaeghe, and 750 Adrian Farrel for their useful comments. 752 10. References 754 10.1. Normative References 756 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 757 Requirement Levels", BCP 14, RFC 2119, March 1997. 759 [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 760 Element (PCE)-based Architecture", RFC4655, august 2006. 762 [PCEP] Vasseur, Le Roux, et al., "Path Computation Element (PCE) 763 communication Protocol (PCEP)", draft-ietf-pce-pcep, work 764 in progress. 766 10.2. Informative References 768 [RFC4657] Ash, J., Le Roux, J.L., " PCE Communication Protocol 769 Generic Requirements", RFC4657, September 2006. 771 [RFC4674] Le Roux, J.L., et al. "Requirements for PCE discovery", 772 RFC4674, October 2006. 774 [RFC5088] Le Roux, Vasseur, et al. "OSPF protocol extensions for 775 Path Computation Element (PCE) Discovery", RFC5088, January 776 2008. 778 [RFC5089] Le Roux, Vasseur, et al. "IS-IS protocol extensions for 779 Path Computation Element (PCE) Discovery", RFC5089, January 780 2008. 782 [RFC5226] Narten, T. and Alverstrand, H., "Guidelines for Writing an 783 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 784 2008. 786 [PCE-GCO] Y. Lee, J.L. Le Roux, D. King, and E. Oki, "Path 787 Computation Element Communication Protocol (PCECP) 788 Requirements and Protocol Extensions In Support of Global 789 Concurrent Optimization", draft-ietf-pce-global-concurrent- 790 optimization, work in progress. 792 [PCEP-MIB] Koushik, K., and Stephan, E., "PCE communication protocol 793 (PCEP) Management Information Base", draft-kkoushik-pce- 794 pcep-mib, work in progress. 796 11. Authors' Addresses 798 Jean-Louis Le Roux 799 France Telecom 800 2, avenue Pierre-Marzin 801 22307 Lannion Cedex 802 FRANCE 803 Email: jeanlouis.leroux@orange-ftgroup.com 805 Jean-Philippe Vasseur 806 Cisco Systems, Inc. 807 1414 Massachusetts avenue 808 Boxborough , MA - 01719 809 USA 810 Email: jpv@cisco.com 812 Young Lee 813 Huawei Technologies, LTD. 814 1700 Alma Drive, Suite 100 815 Plano, TX 75075 816 USA 817 Email: ylee@huawei.com 819 12. Intellectual Property Statement 821 The IETF takes no position regarding the validity or scope of any 822 Intellectual Property Rights or other rights that might be claimed to 823 pertain to the implementation or use of the technology described in 824 this document or the extent to which any license under such rights 825 might or might not be available; nor does it represent that it has 826 made any independent effort to identify any such rights. Information 827 on the procedures with respect to rights in RFC documents can be 828 found in BCP 78 and BCP 79. 830 Copies of IPR disclosures made to the IETF Secretariat and any 831 assurances of licenses to be made available, or the result of an 832 attempt made to obtain a general license or permission for the use of 833 such proprietary rights by implementers or users of this 834 specification can be obtained from the IETF on-line IPR repository at 835 http://www.ietf.org/ipr. 837 The IETF invites any interested party to bring to its attention any 838 copyrights, patents or patent applications, or other proprietary 839 rights that may cover technology that may be required to implement 840 this standard. Please address the information to the IETF at 841 ietf-ipr@ietf.org. 843 Disclaimer of Validity 845 This document and the information contained herein are provided 846 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 847 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 848 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 849 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 850 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 851 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 852 FOR A PARTICULAR PURPOSE. 854 Copyright Statement 856 Copyright (C) The IETF Trust (2008). This document is subject to the 857 rights, licenses and restrictions contained in BCP 78, and except as 858 set forth therein, the authors retain all their rights.