idnits 2.17.1 draft-ietf-pce-of-05.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 861. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 837. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 844. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 850. 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: September 6, 2008 J.P. Vasseur 5 Expires: March 6, 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-05.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 1.2. Message Formats.............................................5 66 2. Discovery of PCE Objective Functions........................5 67 2.1. OF-List TLV.................................................5 68 2.2. Elements of procedure.......................................6 69 3. Objective Function in PCEP Path Computation Request and 70 Reply Messages............................................6 71 3.1. OF Object...................................................6 72 3.1.1. Elements of Procedure.......................................7 73 3.2. Carrying The OF Object In a PCEP Message....................8 74 3.3. New RP Object Flag.........................................10 75 3.3.1. Elements Of Procedure......................................10 76 4. Objective Functions Definition.............................11 77 5. New Metric Types...........................................12 78 6. IANA Considerations........................................13 79 6.1. PCE Objective Function Sub-registry........................13 80 6.2. PCEP Code Points...........................................13 81 6.2.1. OF Object..................................................13 82 6.2.2. OF-List TLV................................................14 83 6.2.3. PCEP Error values..........................................14 84 6.2.4. RP Object Flag.............................................14 85 6.2.5. Metric Types...............................................15 86 7. Security Considerations....................................15 87 8. Manageability Considerations...............................15 88 8.1. Control of Function and Policy.............................15 89 8.2. Information and Data Models................................15 90 8.3. Liveness Detection and Monitoring..........................15 91 8.4. Verify Correct Operations..................................16 92 8.5. Requirements On Other Protocols............................16 93 8.6. Impact On Network Operations...............................16 94 9. Acknowledgments............................................16 95 10. References.................................................16 96 10.1. Normative Feferences.......................................16 97 10.2. Informative References.....................................16 98 11. Authors' Addresses.........................................17 99 12. Intellectual Property Statement............................17 101 Conventions used in this document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 1. Introduction 109 The Path Computation Element-based network architecture [RFC4655] 110 defines a Path Computation Element (PCE) as an entity capable of 111 computing the paths of Traffic Engineered Label Switched Paths (TE 112 LSPs) based on a network graph, and applying computational 113 constraints. A PCE services path computation requests sent by Path 114 Computation Clients (PCC). 116 The PCE communication Protocol (PCEP), defined in [PCEP], allows for 117 communication between a PCC and a PCE or between two PCEs, in 118 compliance with requirements and guidelines set forth in [RFC4657]. 119 Such interactions include path computation requests and path 120 computation replies. 122 The computation of one or a set of TE LSPs is subject to a set of one 123 or more optimization criteria, called an objective function. An 124 objective function is used by the PCE, when it computes a path or a 125 set of paths, in order to select the "best" candidate paths. There is 126 a variety of objective functions: an objective function could apply 127 either to a set of non-synchronized path computation requests, or to 128 a set of synchronized path computation requests. In the former case, 129 the objective function refers to an individual path computation 130 request (e.g. computation of the shortest constrained path where the 131 metric is the IGP metric, computation of the least loaded constrained 132 path, etc.). Conversely in the latter case, the objective function 133 refers to a set of path computation requests the computation of which 134 is synchronized (e.g., minimize the aggregate bandwidth consumption 135 of all LSPs, minimize the sum of the delays for two diverse paths, or 136 the delta between those delays, etc.). Moreover, some objective 137 functions relate to the optimization of a single metric and others to 138 the optimization of a set of metrics (organized in a hierarchical 139 manner, using a weighted function, etc.). 141 As spelled out in [RFC4674], it may be useful for a PCC to discover 142 the set of objective functions supported by a PCE. Furthermore, 143 [RFC4657] requires the ability for a PCC to indicate in a path 144 computation request a required/desired objective function, as well as 145 optional function parameters. 147 For these purposes, this document extends the PCE communication 148 Protocol (PCEP). It defines PCEP extensions allowing a PCE to 149 advertise a list of supported objective functions, as well as 150 extensions to carry the objective function in PCEP request and reply 151 messages. It complements the PCEP base specification [PCEP]. 153 Note that IS-IS and OSPF-based PCE Discovery mechanisms are defined 154 in ([RFC5089], [RFC5088]). These mechanisms are dedicated to the 155 discovery of a few generic parameters while more detailed PCE 156 parameters should be discovered using the PCE communication Protocol. 157 Objective functions are in this second category; thus the Objective 158 Function discovery procedure is handled by PCEP. 160 A new PCEP TLV, named the OF-List TLV is defined in Section 2. The 161 OF-List TLV is carried in the PCEP OPEN object and allows a PCE to 162 list, during PCEP session setup phase, the objective functions that 163 it supports. 165 A new PCEP object, the OF object, is defined in Section 3. The OF 166 object is carried within a PCReq message to indicate the 167 required/desired objective function to be applied by a PCE, or in a 168 PCRep message to indicate the objective function that was used for 169 path computation. 171 Six mandatory objective functions that must be supported by PCEP are 172 listed in [RFC4657]. This document provides a definition of these six 173 mandatory objective functions. Additional objective functions may be 174 defined in other documents. Note that additional objective functions 175 are defined for PCE Global Concurrent Optimization (GCO) application, 176 in [PCE-GCO]. 178 This document also provides the definition of four new metric types 179 that apply to a set of synchronized requests. 181 1.1. Terminology 183 LSR: Label Switching Router. 185 OF: Objective Function: A set of one or more optimization criteria 186 used for the computation of a single path (e.g. path cost 187 minimization), or the synchronized computation of a set of paths 188 (e.g., aggregate bandwidth consumption minimization, etc.). 190 PCC: Path Computation Client: Any client application requesting a 191 path computation to be performed by a Path Computation Element. 193 PCE: Path Computation Element: An entity (component, application, or 194 network node) that is capable of computing a network path or route 195 based on a network graph, and applying computational constraints. 197 PCEP: Path Computation Element communication Protocol. 199 TE LSP: Traffic Engineered Label Switched Path. 201 1.2. Message Formats 203 Message formats in this document are expressed using Reduced BNF as 204 used in [PCEP] and defined in [RBNF]. 206 2. Discovery of PCE Objective Functions 208 This section defines PCEP extensions (see [PCEP]) so as to support 209 the advertisement of the objective functions supported by a PCE. 211 A new PCEP OF-List (Objective Function list) TLV is defined. The PCEP 212 OF-List TLV is carried within an OPEN object, in order for a PCE to 213 advertise to a PCEP peer the list of objective functions it supports, 214 during PCEP session setup phase. 216 2.1. OF-List TLV 218 The PCEP OF-List TLV is optional. It MAY be carried within an OPEN 219 object sent by a PCE in an Open message to a PCEP peer, so as to 220 indicate the list of supported objective functions. 222 The OF-List TLV format is compliant with the PCEP TLV format defined 223 in [PCEP]. That is, the TLV is composed of 2 octets for the type, 2 224 octets specifying the TLV length, and a value field. The Length field 225 defines the length of the value portion in octets. The TLV is padded 226 to four-octet alignment and padding is not included in the Length 227 field (e.g. a three octet value would have a length of three, but the 228 total size of the TLV would be eight octets). 230 The PCEP OF-List TLV has the following format: 232 TYPE: To be assigned by IANA (suggested value = 4 ) 233 LENGTH: N * 2 (where N is the number of objective functions) 234 VALUE: list of 2-bytes objective function code points, identifying 235 the objective functions supported by the sender of the Open message. 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | OF Code #1 | OF Code #2 | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 // // 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | OF Code #N | padding | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 OF Code (2 bytes): Objective Function code point identifier. 249 IANA is requested to manage the PCE objective function code point 250 registry (see Section 6). 252 2.2. Elements of procedure 254 A PCE MAY include an OF-List TLV within an OPEN object in an Open 255 message sent to a PCEP peer, to advertise a set of one or more 256 objective functions. The OF-List TLV MUST NOT appear more than once 257 in an OPEN object. If it appears more than once the PCEP session MUST 258 be rejected with error type 1 and error value 1 (PCEP session 259 establishment failure / Reception of an invalid Open message). 260 The absence of the OF-List TLV in an OPEN object MUST be interpreted 261 as an absence of information on the list of supported objective 262 functions by the PCE. 264 As specified in [PCEP], a PCEP peer that does not recognize the OF- 265 List TLV will silently ignore it. 267 3. Objective Function in PCEP Path Computation Request and Reply 268 Messages 270 This section defines PCEP extensions ([PCEP]) so as to support the 271 communication of objective functions in PCEP path computation request 272 and reply messages. A new PCEP OF (Objective Function) object is 273 defined, to be carried within a PCReq message in order for the PCC to 274 indicate the required/desired objective function. 276 The PCEP OF Object may also be carried within a PCRep message in 277 order for the PCE to indicate the objective function that was used by 278 the PCE. 280 A new flag is defined in the RP object. The flag is used in a PCReq 281 message to indicate that the PCE MUST include an OF object in the 282 PCRep message to indicate the objective function that was used during 283 path computation. 285 Also, new PCEP error types and values are defined. 287 3.1. OF Object 289 The PCEP OF (Objective Function) object is optional. It MAY be 290 carried within a PCReq message so as to indicate the desired/required 291 objective function to be applied by the PCE during path computation, 292 or within a PCRep message so as to indicate the objective function 293 that was used by the PCE during path computation. 295 The OF object format is compliant with the PCEP object format defined 296 in [PCEP]. 298 The OF Object-Class is to be assigned by IANA (recommended value=21). 299 The OF Object-Type is to be assigned by IANA (recommended value=1). 301 The format of the OF object body is: 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 |Objective Function Code(IANA) | Reserved | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | | 309 // Optional TLV(s) // 310 | | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Objective Function Code (2 bytes): The identifier of the Objective 314 Function. The IANA is requested to manage the PCE objective function 315 code point registry (see Section 6). 317 Reserved (2 bytes): This field MUST be set to zero on transmission 318 and MUST be ignored on receipt. 320 Optional TLVs may be defined in the future so as to encode objective 321 function parameters. 323 3.1.1. Elements of Procedure 325 To request the use of a specific objective function by the PCE, a PCC 326 includes an OF object in the PCReq message. 328 [PCEP] specifies a bit flag, referred to as the P bit, carried in the 329 common PCEP object header. The P bit is set by a PCC to mandate that 330 a PCE must take the information carried in the object into account 331 during the path computation. 333 If the P bit is set in the OF object, the objective function is 334 mandatory (required objective function) and the PCE MUST use the 335 objective function during path computation. If the P bit is clear 336 in the OF object, the objective function is optional (desired 337 objective function) and the PCE SHOULD apply the function if it is 338 supported, but MAY choose to apply a different objective function 339 according to local capabilities and policies. 341 On receipt of a PCReq message with an OF object, a PCE MUST proceed 342 as follows: 344 - If the OF object is unknown/unsupported, the PCE MUST follow 345 procedures defined in [PCEP], that is if the P bit is set, it sends 346 a PCErr message with error type 3 or 4 (Unknown / Not supported 347 object) and error value 1 or 2 (unknown / unsupported object class 348 / object type), and the related path computation request MUST be 349 discarded. If the P bit is cleared it is free to ignore the object. 351 - If the objective function is unknown / unsupported and the P bit is 352 set, the PCE MUST send a PCErr message with error type 3 or 4 353 (Unknown / Not supported Object) and error value 4 (Unrecognized / 354 Unsupported parameter), and the related path computation request 355 MUST be discarded. 357 - If the objective function is unknown / unsupported and the P bit is 358 cleared, the PCE SHOULD apply another (default) objective function. 360 - If the objective function is supported but policy does not permit 361 applying it, and the P bit is set, the PCE MUST send a PCErr 362 message with the PCEP error type "policy-violation" (type 5) and a 363 new error value "objective function not allowed" (defined in this 364 document). 366 - If the objective function is supported but policy does not allow 367 applying it, and the P bit is cleared, the PCE SHOULD apply another 368 (default) objective function. 370 - If the objective function is supported and policy allows applying 371 it, then if the P bit is set the PCE MUST apply the requested 372 objective function, else if the P bit is cleared the PCE is free to 373 apply any other objective function. 375 The default objective function may be locally configured. 377 3.2. Carrying The OF Object In a PCEP Message 379 The OF object MAY be carried within a PCReq message. If an objective 380 function is to be applied to a set of synchronized path computation 381 requests, the OF object MUST be carried just after the corresponding 382 SVEC object, and MUST NOT be repeated for each elementary request. 384 Similarly if a metric is to be applied to a set of synchronized 385 requests, the METRIC object MUST follow the SVEC object and MUST NOT 386 be repeated for each elementary request. Note that metrics applied to 387 a set of synchronized requests are defined in section 5. 389 An OF object specifying an objective function that applies to an 390 individual path computation request (non synchronized case) MUST 391 follow the RP object for which it applies. 393 The format of the PCReq message is updated as follows: 395 ::= 396 [] 397 399 where: 400 ::= 401 [] 402 [] 403 [] 405 ::= [] 407 ::= 408 409 [] 410 [] 411 [] 412 [] 413 [] 414 [] 415 [] 417 and where: 419 ::= [] 421 The OF object MAY be carried within a PCRep message to indicate the 422 objective function used by the PCE during path computation. 424 When the PCE wants to indicate to the PCC the objective function that 425 was used for the synchronized computation of a set of paths, the 426 PCRep message MUST include the corresponding SVEC object directly 427 followed by the OF object, which MUST NOT be repeated for each 428 elementary request. If a metric is applicable to the set of paths, 429 the METRIC object MUST directly follow the SVEC object and MUST NOT 430 be repeated for each elementary request. 432 An OF object specifying an objective function used for an individual 433 path computation (non synchronized case) MUST follow the RP object 434 for which it applies. 436 The format of the PCRep message is updated as follows: 438 ::= 439 [] 440 442 where: 444 ::= 445 [] 446 [] 447 [] 449 ::= [] 451 ::= 452 [] 453 [] 455 ::= [] 457 ::= 458 [] 459 [] 460 [] 461 [] 462 [] 464 and where: 466 ::= [] 468 Note: The OF object MAY be associated to a negative reply, i.e., a 469 reply with a NO-PATH object. 471 3.3. New RP Object Flag 473 In some cases, where no objective function is specified in the 474 request, or an optional objective function is desired (P flag cleared 475 in the OF object common header) but the PCE does not follow the 476 request, the PCC may desire to know the objective function that was 477 used by the PCE during path computation. To that end, a new flag is 478 defined in the RP object, named the OF flag, allowing a PCC to 479 request for the inclusion in the path computation reply of the 480 objective function that was used by the PCE during path computation. 482 The following new bit flag of the RP object is defined: 484 Objective Function (OF) flag (1 bit): 0x200 (bit number 16) 485 (suggested value, to be assigned by IANA). When set in a PCReq 486 message, this indicates that the PCE MUST provide the applied 487 objective function (should a path satisfying the constraints be 488 found) in the PCRep message. When set in a PCRep message this 489 indicates that the Objective Function that was used during path 490 computation is included. 492 3.3.1. Elements Of Procedure 494 If the PCC wants to know the objective function used by the PCE 495 during path computation for a given request, it sets the OF flag in 496 the RP object. 498 On receipt of a PCReq message with the OF flag in the RP object set, 499 the PCE proceeds as follows: 501 - If policy permits it MUST include in the PCRep message an OF object 502 indicating the objective function it used during path computation. 504 - If policy does not permit, it MUST send a PCErr message with the 505 PCEP error code "policy-violation" (type 5) and a new error value 506 "objective function indication not allowed" (defined in this 507 document). 509 4. Objective Functions Definition 511 Six objective functions that must be supported by PCEP are listed in 512 [RFC4657]. Objective function codes should be assigned by IANA and 513 are suggested below. 515 Objective functions are formulated using the following terminology: 517 - a network comprises a set of N links {Li, (i=1...N)} 518 - a path P is a list of K links {Lpi,(i=1...K)} 519 - metric of link L is denoted M(L), this can be the IGP metric the TE 520 metric, or any other metric. 521 - the cost of a path P is denoted C(P), where 522 C(P) = sum {M(Lpi), (i=1...K)}. 523 - residual bandwidth on link L is denoted r(L) 524 - maximum reservable bandwidth on link L is denoted R(L). 526 There are three objective functions that apply to the computation of 527 a single path: 529 Objective Function Code: 1 (suggested value, to be assigned by IANA) 530 Name: Minimum Cost Path (MCP) 531 Description: Find a path P such that C(P) is minimized. 533 Objective Function Code: 2 (suggested value, to be assigned by IANA) 534 Name: Minimum Load Path (MLP) 535 Description: Find a path P such that ( Max {(R(Lpi) - r(Lpi)) / 536 R(Lpi), i=1...K } ) is minimized 538 Objective Function Code: 3 (suggested value, to be assigned by IANA) 539 Name: Maximum residual Bandwidth Path (MBP) 540 Description: Find a path P such that ( Min { r(Lpi)), i=1...K } ) is 541 maximized. 543 There are three objective functions that apply to a set of path 544 computation requests the computation of which is synchronized: 546 Objective Function Code: 4 (suggested value, to be assigned by IANA) 547 Name: Minimize aggregate Bandwidth Consumption (MBC) 548 Description: Find a set of paths such that ( Sum {R(Li) - r(Li), 549 i=1...N} ) is minimized. 551 Objective Function Code: 5 (suggested value, to be assigned by IANA) 552 Name: Minimize the Load of the most loaded Link (MLL) 553 Description: Find a set of paths such that ( Max { (R(Li) - r(Li)) / 554 R(Li), i=1...N}) is minimized. 556 Objective Function Code: 6 (suggested value, to be assigned by IANA) 557 Name: Minimize the Cumulative Cost of a set of paths (MCC) 558 Description: Find a set of paths {P1...Pm} such that (Sum { C(Pi), 559 i=1...m}) is minimized. 561 Other objective functions may be defined in separate documents. 563 5. New Metric Types 565 Three metric types are defined in PCEP for the METRIC object: TE 566 metric, IGP metric and hop count. These metric types apply to an 567 individual request. Here we define four new metric types that apply 568 to a set of synchronized requests: 570 Type 4 (suggested value to be assigned by IANA) : Aggregate 571 bandwidth consumption. 573 Type 5 (suggested value to be assigned by IANA) : Load of the most 574 loaded link. 576 Type 6 (suggested value to be assigned by IANA) : Cumulative IGP 577 cost. 579 Type 7 (suggested value to be assigned by IANA) : Cumulative TE 580 cost. 582 These metrics may be used to indicate a bound (B bit set in the 583 METRIC object) or a computed metric (C bit set in the METRIC 584 object). 586 A METRIC object with one of these four types follows the SVEC object 587 for which it applies. 589 6. IANA Considerations 591 6.1. PCE Objective Function Sub-registry 593 This document defines a 16-bit PCE Objective Function identifier to 594 be carried within the PCEP OF object, as well as the PCEP OF-List 595 TLV. 597 IANA is requested to create and manage the 16-bit "PCE Objective 598 Function" code point registry, starting from 1 and continuing through 599 32767, as follows: 601 - Objective Function code point value 602 - Objective Function name 603 - Defining RFC 605 The same registry is applicable to the OF object and the OF-List TLV 606 defined in this document. 608 The guidelines (using terms defined in [RFC5226]) for the 609 assignment of objective function code point values are as follows: 611 - Function code value 0 is reserved. 612 - Function code values in the range 1-32767 are to be assigned as 613 follows: 614 - Function code values 1 through 1023 are to be assigned by IANA 615 using the "IETF Consensus" policy. 616 - Function code values 1024 through 32767 are to be assigned by 617 IANA, using the "First Come First Served" policy. 618 - Function code values in the range 32768-65535 are for "Private 619 Use". 621 Six objective functions are defined in Section 4 of this document and 622 should be assigned by IANA: 624 Code Point Name Defining RFC 626 1 MCP this doc 627 2 MLP this doc 628 3 MBP this doc 629 4 MBC this doc 630 5 MLL this doc 631 6 MCC this doc 633 6.2. PCEP Code Points 635 6.2.1. OF Object 637 The IANA has been requested to manage the PCEP Objects code point 638 registry (see [PCEP]). 640 This document defines a new PCEP object, the OF object, to be carried 641 in PCReq and PCRep messages. The IANA is requested to make the 642 following allocation (suggested value): 644 Object Name Object Name Reference 645 Class Type 647 21 OF 1 Objective Function (this document) 649 6.2.2. OF-List TLV 651 IANA is requested to manage the PCEP TLV code point registry (see 652 [PCEP]). 654 This document defines a new PCEP TLV, the OF-List TLV, to be carried 655 in the OPEN object. The IANA is requested to make the following 656 allocation (suggested value): 658 Type TLV name References 659 ----- -------- ---------- 660 4 OF-List (This document) 662 6.2.3. PCEP Error values 664 Two new error values are defined for the error type "policy 665 violation" (type 5): 667 Error-type Meaning and error values Reference 669 5 Policy violation (this doc) 671 Error-value=3: objective function not (this doc) 672 allowed (request rejected) 674 Error-value=4: OF bit of the RP object (this doc) 675 set (request rejected) 677 6.2.4. RP Object Flag 679 A new flag of the RP object (specified in [PCEP]) is defined in this 680 document. The IANA is requested to make the following allocation 681 (suggested value): 683 Bit Hex Name Reference 684 Number 686 16 0x200 OF (this document) 688 6.2.5. Metric Types 690 Four new metric types are defined in this document for the METRIC 691 object (specified in [PCEP]). The IANA is requested to make the 692 following allocation (suggested values): 694 - Type 4 : Aggregate bandwidth consumption 695 - Type 5 : Load of the most loaded link 696 - Type 6 : Cumulative IGP cost 697 - Type 7 : Cumulative TE cost 699 7. Security Considerations 701 Mechanisms discussed in [PCEP] to secure a PCEP session can be used 702 to secure the PCEP OF object and OF list TLV as well. 704 8. Manageability Considerations 706 8.1. Control of Function and Policy 708 It MUST be possible to configure the activation/deactivation of 709 Objective Function Discovery in PCEP. 711 In addition to the parameters already listed in section 8.1 of 712 [PCEP], a PCEP implementation SHOULD allow configuring on a PCE a 713 list of authorized objective functions. This may apply to any session 714 the PCEP speaker participates in, to a specific session with a given 715 PCEP peer or to a specific group of sessions with a specific group of 716 PCEP peers. 718 Note that it is not mandatory for an implementation to support all 719 objective functions defined in Section 4. 721 It MUST be possible to configure a default objective function used 722 for path computation when a path request is received that requests to 723 use an optional objective function. 725 8.2. Information and Data Models 727 The PCEP MIB Module defined in [PCEP-MIB] SHOULD be extended to 728 include Objective Functions. 730 8.3. Liveness Detection and Monitoring 732 Mechanisms defined in this document do not imply any new liveness 733 detection and monitoring requirements in addition to those already 734 listed in [PCEP]. 736 8.4. Verify Correct Operations 738 Mechanisms defined in this document do not imply any new operation 739 verification requirements in addition to those already listed in 740 [PCEP]. 742 8.5. Requirements On Other Protocols 744 Mechanisms defined in this document do not imply any requirements on 745 other protocols in addition to those already listed in [PCEP]. 747 8.6. Impact On Network Operations 749 Mechanisms defined in this document do not have any impact on network 750 operations in addition to those already listed in [PCEP]. 752 9. Acknowledgments 754 The authors would like to thank Jerry Ash, Fabien Verhaeghe, and 755 Adrian Farrel for their useful comments. 757 10. References 759 10.1. Normative References 761 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 762 Requirement Levels", BCP 14, RFC 2119, March 1997. 764 [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 765 Element (PCE)-based Architecture", RFC4655, august 2006. 767 [PCEP] Vasseur, Le Roux, et al., "Path Computation Element (PCE) 768 communication Protocol (PCEP)", draft-ietf-pce-pcep, work 769 in progress. 771 10.2. Informative References 773 [RFC4657] Ash, J., Le Roux, J.L., " PCE Communication Protocol 774 Generic Requirements", RFC4657, September 2006. 776 [RFC4674] Le Roux, J.L., et al. "Requirements for PCE discovery", 777 RFC4674, October 2006. 779 [RFC5088] Le Roux, Vasseur, et al. "OSPF protocol extensions for 780 Path Computation Element (PCE) Discovery", RFC5088, January 781 2008. 783 [RFC5089] Le Roux, Vasseur, et al. "IS-IS protocol extensions for 784 Path Computation Element (PCE) Discovery", RFC5089, January 785 2008. 787 [RFC5226] Narten, T. and Alverstrand, H., "Guidelines for Writing an 788 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 789 2008. 791 [PCE-GCO] Y. Lee, J.L. Le Roux, D. King, and E. Oki, "Path 792 Computation Element Communication Protocol (PCECP) 793 Requirements and Protocol Extensions In Support of Global 794 Concurrent Optimization", draft-ietf-pce-global-concurrent- 795 optimization, work in progress. 797 [PCEP-MIB] Koushik, K., and Stephan, E., "PCE communication protocol 798 (PCEP) Management Information Base", draft-kkoushik-pce- 799 pcep-mib, work in progress. 801 [RBNF] A. Farrel, "Reduced Backus-Naur Form (RBNF) - A Syntax Used 802 in Various Protocol Specifications", draft-farrel-rtg- 803 common-bnf, work in progress. 805 11. Authors' Addresses 807 Jean-Louis Le Roux 808 France Telecom 809 2, avenue Pierre-Marzin 810 22307 Lannion Cedex 811 FRANCE 812 Email: jeanlouis.leroux@orange-ftgroup.com 814 Jean-Philippe Vasseur 815 Cisco Systems, Inc. 816 1414 Massachusetts avenue 817 Boxborough , MA - 01719 818 USA 819 Email: jpv@cisco.com 821 Young Lee 822 Huawei Technologies, LTD. 823 1700 Alma Drive, Suite 100 824 Plano, TX 75075 825 USA 826 Email: ylee@huawei.com 828 12. Intellectual Property Statement 830 The IETF takes no position regarding the validity or scope of any 831 Intellectual Property Rights or other rights that might be claimed to 832 pertain to the implementation or use of the technology described in 833 this document or the extent to which any license under such rights 834 might or might not be available; nor does it represent that it has 835 made any independent effort to identify any such rights. Information 836 on the procedures with respect to rights in RFC documents can be 837 found in BCP 78 and BCP 79. 839 Copies of IPR disclosures made to the IETF Secretariat and any 840 assurances of licenses to be made available, or the result of an 841 attempt made to obtain a general license or permission for the use of 842 such proprietary rights by implementers or users of this 843 specification can be obtained from the IETF on-line IPR repository at 844 http://www.ietf.org/ipr. 846 The IETF invites any interested party to bring to its attention any 847 copyrights, patents or patent applications, or other proprietary 848 rights that may cover technology that may be required to implement 849 this standard. Please address the information to the IETF at 850 ietf-ipr@ietf.org. 852 Disclaimer of Validity 854 This document and the information contained herein are provided 855 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 856 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 857 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 858 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 859 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 860 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 861 FOR A PARTICULAR PURPOSE. 863 Copyright Statement 865 Copyright (C) The IETF Trust (2008). This document is subject to the 866 rights, licenses and restrictions contained in BCP 78, and except as 867 set forth therein, the authors retain all their rights.