idnits 2.17.1 draft-leroux-pce-of-00.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 766. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 742. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 749. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 755. 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? 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 2 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 (March 2007) is 6250 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 542, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Unused Reference: 'RFC2119' is defined on line 675, but no explicit reference was found in the text == Unused Reference: 'RFC2740' is defined on line 678, 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 (~~), 4 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: September 2007 J.P. Vasseur 6 Cisco System Inc. 8 Y. Lee 9 Huawei 11 March 2007 13 Encoding of Objective Functions in Path Computation Element (PCE) 14 communication and discovery protocols 16 draft-leroux-pce-of-00.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. The definition of objective functions is beyond the scope of 61 this document and will be covered in separate documents. 63 Conventions used in this document 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in RFC-2119. 69 Table of Contents 71 1. Terminology.................................................3 72 2. Introduction................................................4 73 3. PCE Discovery Extensions....................................5 74 3.1. IS-IS PCED Extensions.......................................5 75 3.1.1. IS-IS OF-List sub-TLV.......................................5 76 3.1.2. Elements of Procedure.......................................6 77 3.2. OSPF PCED Extensions........................................6 78 3.2.1. OSPF OF-List sub-TLV........................................6 79 3.2.2. Elements of Procedure.......................................7 80 4. PCEP Extensions.............................................8 81 4.1. OF Object...................................................8 82 4.1.1. Elements of Procedure.......................................9 83 4.2. Carrying the OF Object in a PCEP Message...................10 84 4.3. New RP Object Flag.........................................11 85 4.3.1. Elements of Procedure......................................12 86 5. IANA Considerations........................................12 87 5.1. PCE Objective Function Registry............................12 88 5.2. PCEP Code Points...........................................13 89 5.2.1. OF Object..................................................13 90 5.2.2. OF Object TLV Space........................................13 91 5.2.3. PCEP Error Values..........................................13 92 5.2.4. RP Object Flag.............................................14 93 5.3. IS-IS OF-List sub-TLV......................................14 94 5.4. OSPF OF-List sub-TLV.......................................14 95 6. Backward Compatibility.....................................15 96 7. Security Considerations....................................15 97 8. Manageability Considerations...............................15 98 9. Acknowledgments............................................15 99 10. References.................................................15 100 10.1. Normative References.......................................15 101 10.2. Informative References.....................................16 102 11. Author's Addresses:........................................16 103 12. Intellectual Property Statement............................16 105 1. Terminology 107 Terminology used in this document 109 IGP: Interior Gateway Protocol: Either of the two routing 110 protocols Open Shortest Path First (OSPF) or Intermediate System 111 to Intermediate system (IS-IS). 113 LSR: Label Switching Router. 115 OF: Objective Function: A set of one ore more optimization 116 criteria(s) used for the computation of a single path (e.g. path 117 cost minimization), or the synchronized computation of a set of 118 paths (e.g. aggregate bandwidth consumption minimization, etc.). 120 PCC: Path Computation Client: Any client application requesting a 121 path computation to be performed by a Path Computation Element. 123 PCE: Path Computation Element: An entity (component, application, 124 or network node) that is capable of computing a network path or 125 route based on a network graph, and applying computational 126 constraints. 128 PCED: PCE Discovery: Generic term to refer to a PCE Discovery 129 Mechanism. 131 IS-IS PCED: IS-IS based PCE Discovery. 133 OSPF PCED: OSFP based PCE Discovery. 135 PCEP: Path Computation Element communication Protocol. 137 TE LSP: Traffic Engineered Label Switched Path. 139 2. Introduction 141 The PCE-based network architecture [RFC4655] defines a Path 142 Computation Element (PCE) as an entity capable of computing TE LSP 143 paths based on a network graph, and applying computational 144 constraints. A PCE serves path computation requests sent by Path 145 Computation Clients (PCC). 147 The PCE communication Protocol (PCEP), defined in [PCEP], allows for 148 communication between a PCC and a PCE or between two PCEs, in 149 compliance with requirements and guidelines set forth in [RFC4657]. 150 Such interactions include path computation request and path 151 computation replies. 153 The IS-IS based PCE Discovery and OSFP based PCE Discovery mechanisms 154 defined respectively in [ISIS-PCED] and [OSPF-PCED], allow a PCC to 155 automatically discover a set of PCEs as well as some information 156 required for PCE selection, in compliance with requirements set forth 157 in [RFC4674]. 159 The computation of one or a set of TE LSPs is subject to a set of one 160 or more optimization criteria(s), called an objective function. An 161 objective function is used by the PCE, when it computes a path or a 162 set of paths, in order to select the "best" candidate path(s). There 163 is a variety of objective functions: an objective function could 164 apply either to a set of non synchronized path computation requests, 165 or to a set of synchronized path computation requests. In the former 166 case, the objective function refers to an individual path computation 167 request (e.g. computation of the shortest constrained path where the 168 metric is the IGP metric, computation of the least loaded constrained 169 path, etc.). Conversely in the latter case, the objective function 170 applies to a set of path computation requests the computation of 171 which is synchronized (e.g. minimize the aggregate bandwidth 172 consumption of all links, minimize the sum of the delays for two 173 diverse paths, or the delta between those delays, etc.). Moreover, 174 some objective functions relate to the optimization of a single 175 metric and others to the optimization of a set of metrics (organized 176 in a hierarchical manner, using a weighted function, etc.). 178 As spelled out in [RFC4674], it may be useful for a PCC to discover 179 the set of objective functions supported by a PCE. For that purpose 180 this document specifies PCE Discovery (PCED) extensions in order to 181 allow a PCE advertising a list of supported objective functions. 183 As spelled out in [RFC4657], a PCC must be able to indicate in a path 184 computation request a required/desired objective function, as well as 185 optional function parameters. For that purpose this document extends 186 the PCE communication Protocol (PCEP), so as to carry the objective 187 function as well as function parameters. It thus complements the PCEP 188 specification. 190 Extensions to IS-IS and OSPF based PCE Discovery ([ISIS-PCED], [OSPF- 191 PCED]) are defined in section 3. A new sub-TLV, the OF-List sub-TLV 192 is defined, to be carried within the PCED TLV. It allows advertising 193 the list of objective functions supported by a PCE. 195 Extensions to PCEP ([PCEP]) are defined in section 4. A new PCEP 196 object, the OF object is defined, to be carried within a PCReq 197 message to indicate the required/desired objective function to be 198 applied by a PCE or in a PCRep message to indicate the objective 199 function that was actually applied by the PCE. 201 A common PCE Objective Function code point registry is defined for 202 both PCEP and PCED protocols, to be managed by IANA. 204 Note that the objective function examples provided above are just 205 listed for the sake of illustration and the aim of this document is 206 not to standardize such objective functions but rather to specify the 207 PCED and PCEP protocol extensions to discover the set of objective 208 functions supported by a PCE and to indicate in a path computation 209 request the objection function to be used and in a path computation 210 reply the objective function actually used. This document does not 211 define any objective functions. They will be defined in other 212 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 = 7) 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 objectives function 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 = 7) 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. IANA Considerations 525 5.1. PCE Objective Function Registry 527 This document defines a 16-bit PCE Objective Function identifier to 528 be carried within the PCEP OF object, as well as the ISIS and OSPF 529 OF-List sub-TLVs. 531 The IANA is requested to create and manage the 16-bit "PCE Objective 532 Function" code point registry, starting from 1 and continuing through 533 32767, as follows: 535 - Objective Function code point value 536 - Objective Function name 537 - Defining RFC 539 The same registry is applicable to the PCEP OF object and the ISIS 540 and OSPF OF-List sub-TLVs defined in this document. 542 The guidelines (using terms defined in [RFC2434]) for the 543 assignment of objective function code point values are as follows: 545 - Function code value 0 is reserved. 546 - Function code value in the range 1-32767 are to be assigned as 547 follows: 548 - Function code values 1 through 1023 are to be assigned by 549 IANA using the "IETF Consensus" policy. 550 - Function code values 1024 through 32767 are to be 551 assigned by IANA, using the "First Come First Served" 552 policy. 553 - Function code values in the range 32768-65535 are for 554 "Private Use". 556 5.2. PCEP Code Points 558 5.2.1. OF Object 560 The IANA has been requested to manage the PCEP Objects code point 561 registry (see [PCEP]). 563 This document defines a new PCEP object, the OF object, to be 564 carried in PCReq and PCRep messages. The IANA is requested to make 565 the following allocation (suggested value): 567 Object Name Object Name Reference 568 Class Type 570 18 OF 1 Objective (this document) 571 Function 573 5.2.2. OF Object TLV Space 575 The new PCEP OF object referenced above includes optional TLVs that 576 encode objective function parameters. Each TLV includes a 16-bit type 577 identifier. 579 The IANA is requested to create a new registry, the "PCEP OF TLV" 580 registry, and manage TLV type identifiers as follows: 582 - TLV Type value 583 - TLV Name 584 - Defining RFC 586 Type values in the range 1-32767 are to be assigned as follows: 587 - Values 1 through 1023 are to be assigned by IANA using the 588 "IETF Consensus" policy. 589 - Values 1024 through 32767 are to be assigned by IANA, using the 590 "First Come First Served" policy. 592 Type values in the range 32768-65535 are for "Private Use". 594 5.2.3. PCEP Error Values 596 A new PCEP Error-Type is defined in this document, with two error 597 values (Error-Type and Error-value to be assigned by IANA): 599 Error-type Meaning and error values Reference 601 14 objective function error (this doc) 602 Error-value=1: unknown objective function 603 (request rejected) 604 Error-value=2: unsupported objective function 605 (request rejected) 607 Two new error values are defined for the error type "policy 608 violation" (type 5): 610 Error-type Meaning and error values Reference 612 5 Policy violation 614 Error-value=3: objective function not allowed (this doc) 615 (request rejected) 616 Error-value=4: OF bit of the RP object set (this doc) 617 (request rejected) 619 5.2.4. RP Object Flag 621 A new flag of the RP object (specified in [PCEP]) is defined in this 622 document. The IANA is requested to make the following allocation 623 (suggested value): 625 Bit Hex Name Reference 626 Number 628 08 0x200 OF (this document) 630 When set, this indicates that the PCC requests the inclusion, in the 631 PCRep message, of the objective function actually used to compute the 632 path. 634 5.3. IS-IS OF-List sub-TLV 636 Once a registry for the IS-IS PCED sub-TLV defined in [ISIS-PCED] 637 will have been assigned, IANA will assign a new sub-TLV code-point 638 for the OF-List sub-TLV carried in the PCED sub-TLV. Here is the 639 suggested value: 641 Value TLV name References 642 ----- -------- ---------- 643 7 OF-List (This document) 645 5.4. OSPF OF-List sub-TLV 647 Once a registry for the OSPF PCED TLV defined in [OSPF-PCED] will 648 have been assigned, IANA will assign a new sub-TLV code-point for the 649 OF-List sub-TLV carried in the PCED TLV. Here is the suggested value: 651 Value TLV name References 652 ----- -------- ---------- 653 7 OF-List (This document) 655 6. Backward Compatibility 657 TBC 659 7. Security Considerations 661 TBC 663 8. Manageability Considerations 665 TBC 667 9. Acknowledgments 669 TBC 671 10. References 673 10.1. Normative References 675 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 676 Requirement Levels", BCP 14, RFC 2119, March 1997. 678 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 679 RFC 2740, December 1999. 681 [RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 682 Extensions to OSPF Version 2", RFC 3630, September 2003. 684 [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic 685 Engineering", RFC 3784, June 2004. 687 [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 688 Element (PCE)-based Architecture", RFC4655, august 2006. 690 [PCEP] Vasseur, Le Roux, et al., "Path Computation Element (PCE) 691 communication Protocol (PCEP)", draft-ietf-pce-pcep, work in 692 progress. 694 [ISIS-PCED] Le Roux, Vasseur, et al. "IS-IS protocol extensions for 695 Path Computation Element (PCE) Discovery", draft-ietf-pce-disco- 696 proto-isis, work in progress. 698 [OSPF-PCED] Le Roux, Vasseur, et al. "OSPF protocol extensions for 699 Path Computation Element (PCE) Discovery", draft-ietf-pce-disco- 700 proto-ospf, work in progress. 702 10.2. Informative References 704 [RFC4657] Ash, J., Le Roux, J.L., " PCE Communication Protocol 705 Generic Requirements", RFC4657, September 2006. 707 [RFC4674] Le Roux, J.L., et al. "Requirements for PCE discovery", 708 RFC4674, October 2006. 710 11. Author's Addresses: 712 Jean-Louis Le Roux 713 France Telecom 714 2, avenue Pierre-Marzin 715 22307 Lannion Cedex 716 FRANCE 717 Email: jeanlouis.leroux@orange-ftgroup.com 719 Jean-Philippe Vasseur 720 Cisco Systems, Inc. 721 1414 Massachusetts avenue 722 Boxborough , MA - 01719 723 USA 724 Email: jpv@cisco.com 726 Young Lee 727 Huawei Technologies, LTD. 728 1700 Alma Drive, Suite 100 729 Plano, TX 75075 730 USA 731 Email: ylee@huawei.com 733 12. Intellectual Property Statement 735 The IETF takes no position regarding the validity or scope of any 736 Intellectual Property Rights or other rights that might be claimed to 737 pertain to the implementation or use of the technology described in 738 this document or the extent to which any license under such rights 739 might or might not be available; nor does it represent that it has 740 made any independent effort to identify any such rights. Information 741 on the procedures with respect to rights in RFC documents can be 742 found in BCP 78 and BCP 79. 744 Copies of IPR disclosures made to the IETF Secretariat and any 745 assurances of licenses to be made available, or the result of an 746 attempt made to obtain a general license or permission for the use of 747 such proprietary rights by implementers or users of this 748 specification can be obtained from the IETF on-line IPR repository at 749 http://www.ietf.org/ipr. 751 The IETF invites any interested party to bring to its attention any 752 copyrights, patents or patent applications, or other proprietary 753 rights that may cover technology that may be required to implement 754 this standard. Please address the information to the IETF at 755 ietf-ipr@ietf.org. 757 Disclaimer of Validity 759 This document and the information contained herein are provided 760 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 761 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 762 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 763 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 764 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 765 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 766 FOR A PARTICULAR PURPOSE. 768 Copyright Statement 770 Copyright (C) The IETF Trust (2007). This document is subject to the 771 rights, licenses and restrictions contained in BCP 78, and except as 772 set forth therein, the authors retain all their rights.