idnits 2.17.1 draft-leroux-pce-of-01.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 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 880. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 856. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 863. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 869. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 9 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Introduction' ) ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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.) -- The document date (July 2007) is 6129 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2434' is mentioned on line 595, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Missing Reference: 'PCED-MIB' is mentioned on line 751, but not defined == Missing Reference: 'PCEP-MIB' is mentioned on line 754, but not defined == Unused Reference: 'RFC2119' is defined on line 789, but no explicit reference was found in the text == Unused Reference: 'RFC2740' is defined on line 792, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2740 (Obsoleted by RFC 5340) ** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305) ** Downref: Normative reference to an Informational RFC: RFC 4655 Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J.L. Le Roux 3 Internet Draft France Telecom 4 Category: Standard Track 5 Expires: January 2008 J.P. Vasseur 6 Cisco System Inc. 8 Y. Lee 9 Huawei 11 July 2007 13 Encoding of Objective Functions in Path Computation Element (PCE) 14 communication and discovery protocols 16 draft-leroux-pce-of-01.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that other 27 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet- Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 The computation of one or a series of Traffic Engineering Label 43 Switched Paths (TE LSP) in MultiProtocol Label Switching (MPLS) and 44 Generalized MPLS (GMPLS) networks, is subject to a set of one or more 45 specific optimization criteria(s), referred to as an objective 46 function (e.g. minimum cost path, widest path, etc.). A Path 47 Computation Element (PCE) may support one or multiple objective 48 functions, and it is desired for a Path Computation Client (PCC) to 49 automatically discover the set of objective functions supported by a 50 PCE. Furthermore, it may be useful for a PCC to specify in a path 51 computation request the required objective function used by the PCE 52 to compute a TE LSP or a set of TE LSPs. Thus the aim of this 53 document is to define extensions to the PCE Discovery (PCED) TLV 54 carried within the IS-IS Router Capability TLV and the OSPF Router 55 Information LSA so as to allow a PCC to discover the set of objective 56 functions supported by a PCE. Extensions to the PCE communication 57 Protocol (PCEP) are also specified allowing a PCC to indicate in a 58 path computation request the required objective function and a PCE to 59 indicate in a path computation reply the objective function actually 60 applied. 62 Conventions used in this document 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in RFC-2119. 68 Table of Contents 70 1. Terminology.................................................3 71 2. Introduction................................................4 72 3. PCE Discovery Extensions....................................5 73 3.1. IS-IS PCED Extensions.......................................5 74 3.1.1. IS-IS OF-List sub-TLV.......................................5 75 3.1.2. Elements of Procedure.......................................6 76 3.2. OSPF PCED Extensions........................................6 77 3.2.1. OSPF OF-List sub-TLV........................................6 78 3.2.2. Elements of procedure.......................................7 79 4. PCEP Extensions.............................................7 80 4.1. OF Object...................................................8 81 4.1.1. Elements of procedure.......................................8 82 4.2. Carrying the OF object in a PCEP message....................9 83 4.3. New RP object flag.........................................11 84 4.3.1. Elements of procedure......................................11 85 5. Objective Functions definition.............................11 86 6. IANA Considerations........................................13 87 6.1. PCE Objective Function registry............................13 88 6.2. PCEP code points...........................................14 89 6.2.1. OF Object..................................................14 90 6.2.2. OF Object TLV Space........................................14 91 6.2.3. PCEP Error values..........................................14 92 6.2.4. RP Object flag.............................................15 93 6.3. IS-IS OF-List sub-TLV......................................15 94 6.4. OSPF OF-List sub-TLV.......................................15 95 7. Security Considerations....................................16 96 8. Manageability Considerations...............................16 97 8.1. Control of Function and Policy.............................16 98 8.2. Information and Data Models................................16 99 8.3. Liveness Detection and Monitoring..........................16 100 8.4. Verify Correct Operations..................................16 101 8.5. Requirements on other protocols............................17 102 8.6. Impact on network operations...............................17 103 9. Acknowledgments............................................17 104 10. References.................................................17 105 10.1. Normative references.......................................17 106 10.2. Informative references.....................................18 107 11. Author's Addresses:........................................18 108 12. Intellectual Property Statement............................18 110 1. Terminology 112 Terminology used in this document 114 IGP: Interior Gateway Protocol: Either of the two routing 115 protocols Open Shortest Path First (OSPF) or Intermediate System 116 to Intermediate system (IS-IS). 118 LSR: Label Switching Router. 120 OF: Objective Function: A set of one or more optimization 121 criteria(s) used for the computation of a single path (e.g. path 122 cost minimization), or the synchronized computation of a set of 123 paths (e.g. aggregate bandwidth consumption minimization, etc.). 125 PCC: Path Computation Client: Any client application requesting a 126 path computation to be performed by a Path Computation Element. 128 PCE: Path Computation Element: An entity (component, application, 129 or network node) that is capable of computing a network path or 130 route based on a network graph, and applying computational 131 constraints. 133 PCED: PCE Discovery: Generic term to refer to a PCE Discovery 134 Mechanism. 136 IS-IS PCED: IS-IS based PCE Discovery. 138 OSPF PCED: OSPF based PCE Discovery. 140 PCEP: Path Computation Element communication Protocol. 142 TE LSP: Traffic Engineered Label Switched Path. 144 2. Introduction 146 The PCE-based network architecture [RFC4655] defines a Path 147 Computation Element (PCE) as an entity capable of computing TE LSP 148 paths based on a network graph, and applying computational 149 constraints. A PCE serves path computation requests sent by Path 150 Computation Clients (PCC). 152 The PCE communication Protocol (PCEP), defined in [PCEP], allows for 153 communication between a PCC and a PCE or between two PCEs, in 154 compliance with requirements and guidelines set forth in [RFC4657]. 155 Such interactions include path computation requests and path 156 computation replies. 158 The IS-IS based PCE Discovery and OSPF based PCE Discovery mechanisms 159 defined respectively in [ISIS-PCED] and [OSPF-PCED], allow a PCC to 160 automatically discover a set of PCEs as well as some information 161 required for PCE selection, in compliance with requirements set forth 162 in [RFC4674]. 164 The computation of one or a set of TE LSPs is subject to a set of one 165 or more optimization criteria(s), called an objective function. An 166 objective function is used by the PCE, when it computes a path or a 167 set of paths, in order to select the "best" candidate path(s). There 168 is a variety of objective functions: an objective function could 169 apply either to a set of non synchronized path computation requests, 170 or to a set of synchronized path computation requests. In the former 171 case, the objective function refers to an individual path computation 172 request (e.g. computation of the shortest constrained path where the 173 metric is the IGP metric, computation of the least loaded constrained 174 path, etc.). Conversely in the latter case, the objective function 175 applies to a set of path computation requests the computation of 176 which is synchronized (e.g. minimize the aggregate bandwidth 177 consumption of all links, minimize the sum of the delays for two 178 diverse paths, or the delta between those delays, etc.). Moreover, 179 some objective functions relate to the optimization of a single 180 metric and others to the optimization of a set of metrics (organized 181 in a hierarchical manner, using a weighted function, etc.). 183 As spelled out in [RFC4674], it may be useful for a PCC to discover 184 the set of objective functions supported by a PCE. For that purpose 185 this document specifies PCE Discovery (PCED) extensions in order to 186 allow a PCE advertising a list of supported objective functions. 188 As spelled out in [RFC4657], a PCC must be able to indicate in a path 189 computation request a required/desired objective function, as well as 190 optional function parameters. For that purpose this document extends 191 the PCE communication Protocol (PCEP), so as to carry the objective 192 function as well as function parameters. It thus complements the PCEP 193 specification. 195 Extensions to IS-IS and OSPF based PCE Discovery ([ISIS-PCED], [OSPF- 196 PCED]) are defined in section 3. A new sub-TLV, the OF-List sub-TLV 197 is defined, to be carried within the PCED TLV. It allows advertising 198 the list of objective functions supported by a PCE. 200 Extensions to PCEP ([PCEP]) are defined in section 4. A new PCEP 201 object, the OF object is defined, to be carried within a PCReq 202 message to indicate the required/desired objective function to be 203 applied by a PCE or in a PCRep message to indicate the objective 204 function that was actually applied by the PCE. 206 A common PCE Objective Function code point registry is defined for 207 both PCEP and PCED protocols, to be managed by IANA. 209 Six mandatory objective functions that must be supported by PCEP are 210 listed in [RFC4657]. This document provides a definition of these six 211 mandatory objective functions. Additional objective functions may be 212 defined in other documents. 214 3. PCE Discovery Extensions 216 3.1. IS-IS PCED Extensions 218 3.1.1. IS-IS OF-List sub-TLV 220 The IS-IS Objective Function List (OF-List) sub-TLV is a new sub-TLV 221 carried within the IS-IS PCED sub-TLV defined in [ISIS-PCED]. It 222 allows advertising the list of objective functions supported by a 223 PCE. 225 The OF-List sub-TLV is an optional sub-TLV. It MAY be present 226 within the PCED sub-TLV. It MUST NOT be present more than once. 227 If present more than once, all instances except the first one MUST be 228 ignored. 230 The format of the IS-IS OF-List sub-TLV is the identical to the TLV 231 format used by the Traffic Engineering Extensions to IS-IS [RFC3784]. 232 That is, the TLV is composed of 1 octet for the type, 1 octet 233 specifying the TLV length, and a value field. The Length field 234 defines the length of the value portion in octets. 236 The IS-IS OF-List sub-TLV has the following format: 238 TYPE: To be assigned by IANA (suggested value = 6) 239 LENGTH: N * 2 (where N is the number of objective functions) 240 VALUE: list of 2-bytes objective function code points, 241 identifying the supported objective functions. 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | OF Code #1 | OF Code #2 | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 // // 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | OF Code # N | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 OF Code (2 bytes): Objective Function Identifier 255 The IANA is requested to manage the PCE objective function code point 256 registry (see IANA section). 258 3.1.2. Elements of Procedure 260 The OF-List sub-TLV is advertised within an IS-IS PCED sub-TLV 261 defined in [ISIS-PCED]. As such, elements of procedures are inherited 262 from those defined in [ISIS-PCED]. 264 The OF-List sub-TLV is OPTIONAL. A PCE MAY include an OF-List sub-TLV 265 within the PCED sub-TLV so as to advertise a set of one or more 266 objective functions. When a PCED sub-TLV does not contain any OF-List 267 sub-TLV this means that the supported objective functions of that PCE 268 are unknown. 270 3.2. OSPF PCED Extensions 272 3.2.1. OSPF OF-List sub-TLV 274 The OSPF Objective Function List (OF-List) sub-TLV is a new sub-TLV 275 carried within the OSPF PCED TLV defined in [OSPF-PCED]. It allows 276 advertising the objective functions supported by a PCE. It includes a 277 list of 2-bytes objective function identifiers. 279 The OF-List sub-TLV is an optional TLV. It MAY be present 280 within the PCED TLV. It MUST NOT be present more than once. 281 If present more than once, all instances except the first one MUST be 282 ignored. 284 The format of the OSPF OF-List sub-TLV is the identical to the TLV 285 format used by the Traffic Engineering Extensions to OSPF 286 [RFC3630]. That is, the TLV is composed of 2 octets for the type, 2 287 octets specifying the TLV length, and a value field. The Length field 288 defines the length of the value portion in octets. The TLV is padded 289 to four-octet alignment; padding is not included in the Length field 290 (so a two octet value would have a length of two, but the total size 291 of the TLV would be eight octets). 293 The OSPF OF-List sub-TLV has the following format: 295 TYPE: To be assigned by IANA (suggested value = 6) 296 LENGTH: N * 2 (where N is the number of objective functions) 297 VALUE: list of 2-bytes objective function code points, 298 identifying the supported objective functions. 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | OF Code #1 | OF Code #2 | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 // // 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | OF Code #N | | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 OF Code (2 bytes): Objective Function Identifier 312 The IANA is requested to manage the PCE objective function code point 313 registry (see IANA section). 315 3.2.2. Elements of procedure 317 The OF-List sub-TLV is advertised within an OSPF PCED TLV defined in 318 [OSPF-PCED]. As such, elements of procedures are inherited from those 319 defined in [OSPF-PCED]. 321 The OF-List sub-TLV is OPTIONAL. A PCE MAY include an OF-List sub-TLV 322 within the PCED TLV so as to advertise a set of one or more objective 323 functions. When a PCED TLV does not contain any OF-List sub-TLV this 324 means that the supported objective functions of that PCE are unknown. 326 4. PCEP Extensions 328 This section defines extensions to PCEP ([PCEP]) so as to support the 329 communication of objective functions. A new PCEP OF (Objective 330 Function) object is defined, to be carried within a PCReq message in 331 order for the PCC to indicate the required/desired objective function 332 and within a PCRep message in order for the PCE to indicate the 333 objective function that has actually been applied by the PCE. A new 334 flag is defined in the RP object, so as to indicate in a PCRep 335 message that the inclusion of the objective function actually applied 336 by the PCE is required in the response. Also new PCEP error type and 337 value are defined. 339 4.1. OF Object 341 The PCEP OF (Objective Function) object is optional. It MAY be 342 carried within a PCReq message so as to indicate the desired/required 343 objective function to be applied by the PCE during path computation, 344 or within a PCRep message so as to indicate the objective function 345 that has been actually applied by the PCE. 347 The OF object format is compliant with the PCEP object format defined 348 in [PCEP]. 350 The OF Object-Class is to be assigned by IANA (recommended value=18). 351 The OF Object-Types is to be assigned by IANA (recommended value=1). 353 The format of the OF object body is: 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 |Objective Function Code(IANA) | Reserved | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | | 361 // Optional TLV(s) // 362 | | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 Objective Function Code (2 bytes): The identifier of the Objective 366 Function. The IANA is requested to manage the PCE objective function 367 code point registry (see IANA section). 369 Reserved (2 bytes): This field MUST be set to zero on transmission 370 and MUST be ignored on receipt. 372 Optional TLVs may be defined so as to encode objective function 373 parameters. The IANA is requested to create a registry for this TLVs' 374 name space. 376 4.1.1. Elements of procedure 378 To specify an objective function to be applied by a PCE, a PCC MUST 379 include an OF object in the PCReq message. 381 A bit flag referred to as the P bit is defined in the common header 382 of each PCEP object that can be set by a PCC to enforce a PCE to take 383 into account the related information during the path computation. If 384 the objective function is mandatory (required objective function), 385 the P bit in the OF object MUST be set, else if it is optional 386 (desired objective function) the P bit MUST be cleared. 388 On receipt of a PCReq message with an OF object, a PCE has to proceed 389 as follows: 391 - If the OF object is unknown/unsupported, the PCE MUST follow 392 procedures defined in [PCEP], that is if the P bit is set, it 393 sends a PCErr message with error type unknown/unsupported 394 object (type 3 and 4) else if the P bit is cleared it is free 395 to ignore the object. 397 - If the objective function is unknown / unsupported and the P 398 bit is set, the PCE MUST send a PCErr message with a new PCEP 399 error type "objective function error" and error value 400 "unknown/unsupported objective function" (defined in this 401 document), and the related path computation request MUST be 402 discarded. 404 - If the objective function is unknown / unsupported and the P 405 bit is cleared, the PCE SHOULD apply another (default) 406 objective function. 408 - If the objective function is supported but policy does not 409 permit applying it, and the P bit is set, the PCE MUST send a 410 PCErr message with the PCEP error type "policy-violation" 411 (type 5) and a new error value "objective function not 412 allowed" (defined in this document). 414 - If the objective function is supported but policy does not 415 allow applying it, and the P bit is cleared, the PCE SHOULD 416 apply another (default) objective function. 418 - If the objective function is supported and policy allows 419 applying it, then if the P bit is set the PCE MUST apply the 420 requested objective function, else if the P bit is cleared the 421 PCE is free to apply any other objective function. 423 4.2. Carrying the OF object in a PCEP message 425 The OF object MAY be carried within a PCReq message. An OF object 426 specifying an objective function that applies to a set of 427 synchronized path computation requests MUST be carried just after the 428 corresponding SVEC object, and MUST NOT be repeated for each 429 elementary request. 431 An OF object specifying an objective function that applies to an 432 individual path computation request (non synchronized case) MUST 433 follow the RP object for which it applies. 435 The format of the PCReq message is updated as follows: 437 ::= 438 [] 439 441 where: 442 ::= 443 [] 444 [] 446 ::=[] 448 ::= 449 450 [] 451 [] 452 [] 453 [] 454 [] 455 [] 456 [] 457 where: 459 ::=[] 461 The OF object MAY be carried within a PCRep message to indicate the 462 objective function that was actually applied by the PCE. 464 The format of the PCRep message is updated as follows: 466 ::= 467 469 where: 470 ::=[] 472 ::= 473 [] 474 [] 476 ::=[] 478 ::= 479 [] 480 [] 481 [] 482 [] 483 [] 484 where: 485 ::=[] 487 4.3. New RP object flag 489 In some cases, where no objective function is specified in the 490 request, or an optional objective function is desired (P bit cleared 491 in the OF object header) but the PCE does not follow the 492 recommendation, the PCC may desire to know the objective function 493 actually applied by the PCE. For that purpose, a new flag is defined 494 in the RP object, the OF flag, allowing a PCC to request for the 495 inclusion in the reply of the objective function actually applied by 496 the PCE. 498 The following new bit flag of the RP object is defined: 500 Objective Function (OF) flag (1 bit): 0x200 (suggested value, to be 501 assigned by IANA). When set in a PCReq message, this indicates that 502 the PCE must provide the applied objective function (should a path 503 satisfying the constraints be found) in the PCRep message. When set 504 in a PCRep message this indicates that the Objective Function applied 505 by the PCE is included. 507 4.3.1. Elements of procedure 509 If the PCC wants to know the objective function actually applied by a 510 PCE for a given request, it MUST set the OF flag in the RP object. 512 On receipt of a PCReq message with the OF flag in the RP object set, 513 the PCE has to proceed as follows: 515 - If policy permits it MUST include in the PCRep message an OF 516 object indicating the objective function it actually applied. 518 - If policy does not permit, it MUST send a PCErr message with 519 the PCEP error code "policy-violation" (type 5) and a new 520 error value "objective function indication not allowed" 521 (defined in this document). 523 5. Objective Functions definition 525 Six objective functions that must be supported by PCEP are listed in 526 [RFC4657]. Objective function codes should be assigned by IANA and 527 are suggested below. 529 Objective functions are formulated using the following terminology: 530 - a network comprises a set of N links {Li, (i=1�N)} 531 - a path P is a list of K links {Lpi,(i=1�K)} 532 - Metric of link L is noted M(L), this can be the IGP metric the 533 TE metric or any other metric. 534 - The cost of a path P is noted C(P), 535 C(P) = sum {M(Lpi), (i=1�K)}. 536 - Residual bandwidth on link L is noted R(L) 537 - Speed of link L is noted B(L) 539 There are three objective functions that apply to the computation of 540 a single path: 542 Objective Function Code: 1 (suggested value, to be assigned by IANA) 543 Name: Minimum Cost Path (MCP) 544 Description: Find a path P such that C(P) is minimized. 546 Objective Function Code: 2 (suggested value, to be assigned by IANA) 547 Name: Minimum Load Path (MLP) 548 Description: Find a path P such that ( Max {(B(Lpi) - R(Lpi)) / 549 B(Lpi), i=1�K } ) is minimized 551 Objective Function Code: 3 (suggested value, to be assigned by IANA) 552 Name: Maximum residual Bandwidth Path (MBP) 553 Description: Find a path P such that ( Min { R(Lpi)), i=1�K } ) is 554 maximized. 556 There are three objective functions that apply to a set of path 557 computation requests the computation of which is synchronized: 559 Objective Function Code: 4 (suggested value, to be assigned by IANA) 560 Name: Minimize aggregate Bandwidth Consumption (MBC) 561 Description: Find a set of paths such that ( Sum {B(Li) - R(Li), 562 i=1�N} ) is minimized. 564 Objective Function Code: 5 (suggested value, to be assigned by IANA) 565 Name: Minimize the Load of the most loaded Link (MLL) 566 Description: Find a set of paths such that ( Max { B(Li) - R(Li)) / 567 B(Li), i=1�N}) is minimized. 569 Objective Function Code: 6 (suggested value, to be assigned by IANA) 570 Name: Minimize the Cumulative Cost of a set of paths (MCC) 571 Description: Find a set of paths {P1�Pm} such that (Sum { C(Pi), 572 i=1�m}) is minimized. 574 Other objective functions may be defined in separate documents. 576 6. IANA Considerations 578 6.1. PCE Objective Function registry 580 This document defines a 16-bit PCE Objective Function identifier to 581 be carried within the PCEP OF object, as well as the ISIS and OSPF 582 OF-List sub-TLVs. 584 The IANA is requested to create and manage the 16-bit "PCE Objective 585 Function" code point registry, starting from 1 and continuing through 586 32767, as follows: 588 - Objective Function code point value 589 - Objective Function name 590 - Defining RFC 592 The same registry is applicable to the PCEP OF object and the ISIS 593 and OSPF OF-List sub-TLVs defined in this document. 595 The guidelines (using terms defined in [RFC2434]) for the 596 assignment of objective function code point values are as follows: 598 - Function code value 0 is reserved. 599 - Function code value in the range 1-32767 are to be assigned as 600 follows: 601 - Function code values 1 through 1023 are to be assigned by 602 IANA using the "IETF Consensus" policy. 603 - Function code values 1024 through 32767 are to be 604 assigned by IANA, using the "First Come First Served" 605 policy. 606 - Function code values in the range 32768-65535 are for 607 "Private Use". 609 Six objective functions are defined in section 5 of this document and 610 should be assigned by IANA: 612 Code Point Name Defining RFC 614 1 MCP this doc 615 2 MLP this doc 616 3 MBP this doc 617 4 MBC this doc 618 5 MLL this doc 619 6 MCC this doc 621 6.2. PCEP code points 623 6.2.1. OF Object 625 The IANA has been requested to manage the PCEP Objects code point 626 registry (see [PCEP]). 628 This document defines a new PCEP object, the OF object, to be 629 carried in PCReq and PCRep messages. The IANA is requested to make 630 the following allocation (suggested value): 632 Object Name Object Name Reference 633 Class Type 635 18 OF 1 Objective (this document) 636 Function 638 6.2.2. OF Object TLV Space 640 The new PCEP OF object referenced above includes optional TLVs that 641 encode objective function parameters. Each TLV includes a 16-bit type 642 identifier. 644 The IANA is requested to create a new registry, the "PCEP OF TLV" 645 registry, and manage TLV type identifiers as follows: 647 - TLV Type value 648 - TLV Name 649 - Defining RFC 651 Type values in the range 1-32767 are to be assigned as follows: 652 - Values 1 through 1023 are to be assigned by IANA using the 653 "IETF Consensus" policy. 654 - Values 1024 through 32767 are to be assigned by IANA, using the 655 "First Come First Served" policy. 657 Type values in the range 32768-65535 are for "Private Use". 659 6.2.3. PCEP Error values 661 A new PCEP Error-Type is defined in this document, with two error 662 values (Error-Type and Error-value to be assigned by IANA): 664 Error-type Meaning and error values Reference 666 14 Objective Function Error (this doc) 667 Error-value=1: unknown objective function 668 (request rejected) 669 Error-value=2: unsupported objective function 670 (request rejected) 672 Two new error values are defined for the error type "policy 673 violation" (type 5): 675 Error-type Meaning and error values Reference 677 5 Policy violation 679 Error-value=3: objective function not allowed (this doc) 680 (request rejected) 681 Error-value=4: OF bit of the RP object set (this doc) 682 (request rejected) 684 6.2.4. RP Object flag 686 A new flag of the RP object (specified in [PCEP]) is defined in this 687 document. The IANA is requested to make the following allocation 688 (suggested value): 690 Bit Hex Name Reference 691 Number 693 08 0x200 OF (this document) 695 When set, this indicates that the PCC requests the inclusion, in the 696 PCRep message, of the objective function actually used to compute the 697 path. 699 6.3. IS-IS OF-List sub-TLV 701 Once a registry for the IS-IS PCED sub-TLV defined in [ISIS-PCED] 702 will have been assigned, IANA will assign a new sub-TLV code-point 703 for the OF-List sub-TLV carried in the PCED sub-TLV. Here is the 704 suggested value: 706 Value TLV name References 707 ----- -------- ---------- 708 6 OF-List (This document) 710 6.4. OSPF OF-List sub-TLV 712 Once a registry for the OSPF PCED TLV defined in [OSPF-PCED] will 713 have been assigned, IANA will assign a new sub-TLV code-point for the 714 OF-List sub-TLV carried in the PCED TLV. Here is the suggested value: 716 Value TLV name References 717 ----- -------- ---------- 718 6 OF-List (This document) 720 7. Security Considerations 722 Mechanisms discussed in [ISIS-PCED] and [OSPF-PCED] to secure the PCED 723 TLV can be used to secure the PCED sub-TLV as well. 725 Mechanisms discussed in [PCEP] to secure a PCEP session can be used to 726 secure the PCEP OF object as well. 728 8. Manageability Considerations 730 8.1. Control of Function and Policy 732 It MUST be possible to configure the activation/deactivation of 733 Objective Function Discovery in the PCED protocol. 735 In addition to the parameters already listed in section 8.1 of [PCEP], 736 a PCEP implementation SHOULD allow configuring on a PCE a list of 737 authorized objective functions. This may apply to any session the 738 PCEP speaker participates in, to a specific session with a given PCEP 739 peer or to a specific group of sessions with a specific group of PCEP 740 peers. 742 Note that an implementation may support the specification of the OF 743 to be used in PCEP without supporting the discovery of the set of 744 OF via the IGP. 746 Also note that it is not mandatory for an implementation to support 747 all objective functions defined in section 5. 749 8.2. Information and Data Models 751 The PCED MIB Module defined in [PCED-MIB] MUST be extended to include 752 Objective Functions. 754 The PCEP MIB Module defined in [PCEP-MIB] MUST be extended to include 755 Objective Functions. 757 8.3. Liveness Detection and Monitoring 759 Mechanisms defined in this document do not imply any new liveness 760 detection and monitoring requirements in addition to those already 761 listed in [PCEP], [ISIS-PCED] and [OSPF-PCED]. 763 8.4. Verify Correct Operations 765 Mechanisms defined in this document do not imply any new operation 766 verification requirements in addition to those already 767 listed in [PCEP], [ISIS-PCED] and [OSPF-PCED]. 769 8.5. Requirements on other protocols 771 Mechanisms defined in this draft do not imply any requirements on 772 other protocols in addition to those already listed in [PCEP], [ISIS- 773 PCED] and [OSPF-PCED]. 775 8.6. Impact on network operations 777 Mechanisms defined in this document do not imply any impact on 778 network operations in addition to those already listed in [PCEP], 779 [ISIS-PCED] and [OSPF-PCED]. 781 9. Acknowledgments 783 The authors would like to thank Jerry Ash for his useful comments. 785 10. References 787 10.1. Normative references 789 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 790 Requirement Levels", BCP 14, RFC 2119, March 1997. 792 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 793 RFC 2740, December 1999. 795 [RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 796 Extensions to OSPF Version 2", RFC 3630, September 2003. 798 [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic 799 Engineering", RFC 3784, June 2004. 801 [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 802 Element (PCE)-based Architecture", RFC4655, august 2006. 804 [PCEP] Vasseur, Le Roux, et al., "Path Computation Element (PCE) 805 communication Protocol (PCEP)", draft-ietf-pce-pcep, work in 806 progress. 808 [ISIS-PCED] Le Roux, Vasseur, et al. "IS-IS protocol extensions for 809 Path Computation Element (PCE) Discovery", draft-ietf-pce-disco- 810 proto-isis, work in progress. 812 [OSPF-PCED] Le Roux, Vasseur, et al. "OSPF protocol extensions for 813 Path Computation Element (PCE) Discovery", draft-ietf-pce-disco- 814 proto-ospf, work in progress. 816 10.2. Informative references 818 [RFC4657] Ash, J., Le Roux, J.L., " PCE Communication Protocol 819 Generic Requirements", RFC4657, September 2006. 821 [RFC4674] Le Roux, J.L., et al. "Requirements for PCE discovery", 822 RFC4674, October 2006. 824 11. Authors' Addresses 826 Jean-Louis Le Roux 827 France Telecom 828 2, avenue Pierre-Marzin 829 22307 Lannion Cedex 830 FRANCE 831 Email: jeanlouis.leroux@orange-ftgroup.com 833 Jean-Philippe Vasseur 834 Cisco Systems, Inc. 835 1414 Massachusetts avenue 836 Boxborough , MA - 01719 837 USA 838 Email: jpv@cisco.com 840 Young Lee 841 Huawei Technologies, LTD. 842 1700 Alma Drive, Suite 100 843 Plano, TX 75075 844 USA 845 Email: ylee@huawei.com 847 12. Intellectual Property Statement 849 The IETF takes no position regarding the validity or scope of any 850 Intellectual Property Rights or other rights that might be claimed to 851 pertain to the implementation or use of the technology described in 852 this document or the extent to which any license under such rights 853 might or might not be available; nor does it represent that it has 854 made any independent effort to identify any such rights. Information 855 on the procedures with respect to rights in RFC documents can be 856 found in BCP 78 and BCP 79. 858 Copies of IPR disclosures made to the IETF Secretariat and any 859 assurances of licenses to be made available, or the result of an 860 attempt made to obtain a general license or permission for the use of 861 such proprietary rights by implementers or users of this 862 specification can be obtained from the IETF on-line IPR repository at 863 http://www.ietf.org/ipr. 865 The IETF invites any interested party to bring to its attention any 866 copyrights, patents or patent applications, or other proprietary 867 rights that may cover technology that may be required to implement 868 this standard. Please address the information to the IETF at 869 ietf-ipr@ietf.org. 871 Disclaimer of Validity 873 This document and the information contained herein are provided 874 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 875 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 876 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 877 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 878 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 879 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 880 FOR A PARTICULAR PURPOSE. 882 Copyright Statement 884 Copyright (C) The IETF Trust (2007). This document is subject to the 885 rights, licenses and restrictions contained in BCP 78, and except as 886 set forth therein, the authors retain all their rights.