idnits 2.17.1 draft-ali-ccamp-rc-objective-function-metric-bound-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 1) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 17 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 19, 2013) is 3842 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: 'RFC2205' is mentioned on line 523, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754.1985' Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Zafar Ali 3 Internet Draft George Swallow 4 Intended status: Standard Track Clarence Filsfils 5 Expires: April 18, 2014 Luyuan Fang 6 Cisco Systems 7 Kenji Kumaki 8 KDDI Corporation 9 Ruediger Kunze 10 Deutsche Telekom AG 11 Daniele Ceccarelli 12 Ericsson 13 Xian Zhang 14 Huawei 15 October 19, 2013 17 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) 18 Extension for Signaling Objective Function and Metric Bound 19 draft-ali-ccamp-rc-objective-function-metric-bound-04.txt 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current 29 Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other 33 documents at any time. It is inappropriate to use Internet-Drafts 34 as reference material or to cite them other than as "work in 35 progress." 37 This Internet-Draft will expire on April 18, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described in 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Simplified BSD License. 54 ID draft-ali-ccamp-rc-objective-function-metric-bound-04.txt 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) 62 controlling the copyright in such materials, this document may not 63 be modified outside the IETF Standards Process, and derivative 64 works of it may not be created outside the IETF Standards Process, 65 except to format it for publication as an RFC or to translate it 66 into languages other than English. 68 Abstract 70 In particular networks such as those used by financial 71 institutions, network performance criteria such as latency are 72 becoming critical to data path selection. However cost is still an 73 important consideration. This leads to a situation where path 74 calculation involves multiple metrics and more complex objective 75 functions. 77 When using GMPLS control plane, there are many scenarios in which a 78 node may need to request a remote node to perform path computation 79 or expansion, like for example multi-domain LSP setup, Generalized 80 Multi-Protocol Label Switching (GMPLS) User-Network Interface (UNI) 81 or simply the utilization of a loose ERO in intra domain signaling. 82 In such cases, the node requesting for the setup of an LSP needs to 83 convey the required objective function to the remote node, to 84 enable it to perform route computation in the desired fashion. 85 Similarly, there are cases the ingress needs to indicate a TE 86 metric bound for a loose segment that is expanded by a remote node. 88 This document defines extensions to the RSVP-TE Protocol to allow 89 an ingress node to request the required objective function for the 90 route computation, as well as a metric bound to influence route 91 computation decisions at a remote node(s). 93 Conventions used in this document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 97 this document are to be interpreted as described in RFC 2119 98 [RFC2119]. 100 ID draft-ali-ccamp-rc-objective-function-metric-bound-04.txt 102 Table of Contents 104 Copyright Notice.....................................................1 105 1. Introduction......................................................3 106 2. RSVP-TE signaling extensions......................................4 107 2.1. Objective Function (OF) Subobject.........................4 108 2.1.1. Minimum TE Metric Cost Path Objective Function.......6 109 2.1.2. Minimum IGP Metric Cost Path Objective Function......6 110 2.1.3. Minimum Latency Path Objective Function..............6 111 2.1.4. Minimum Latency Variation Path Objective Function....7 112 2.2. Metric subobject..........................................7 113 2.3. Processing Rules for the OF Subobjects....................8 114 2.4. Processing Rules for the Metric subobject.................9 115 3. Security Considerations..........................................11 116 4. IANA Considerations..............................................11 117 5. Acknowledgments..................................................12 118 6. References.......................................................12 119 6.1. Normative References.....................................12 120 6.2. Informative References...................................12 122 1. Introduction 124 As noted in [OSPF-TE-METRIC] and [ISIS-TE-METRIC], in certain 125 networks such as financial information networks (e.g. stock 126 market data providers), performance criteria such as latency are 127 becoming critical to data path selection along with other 128 metrics. Such networks may require selection of a path that 129 minimizes end-to-end latency. Or a path may need to be found that 130 minimized some other TE metric(s), while subject to a latency 131 bound. Thus there is a requirement to be able to find end-to-end 132 paths with different optimization criteria. 134 When the entire route for an LSP is computed at the ingress node, 135 this requirement can be met by a local decision at that node. 136 However, there are scenarios where partial or full route 137 computations are performed by remote nodes. The scenarios include 138 (but are not limited to): 140 . LSPs with loose hops in the Explicit Route Object (ERO), 141 including intra-domain LSPs. 143 . GMPLS-UNI where route computation may be performed by the 144 UNI-Network (server) node [RFC4208]; 146 ID draft-ali-ccamp-rc-objective-function-metric-bound-04.txt 148 . Multi domain LSP setup with per domain path computation; 150 In these scenarios, there is a need for the ingress node to 151 convey the optimization criteria (e.g., IGP cost, TE cost, hop 152 counts, latency, etc.) to be used for the path computation to the 153 node performing route computation or expansion. Similarly, there 154 is a need for the ingress node to indicate a TE metric bound for 155 the loose segment being expanded by a remote node. 157 [RFC5541] defines extensions to the Path Computation Element 158 communication Protocol (PCEP) to allow a Path Computation Client 159 (PCC) indicate in a path computation request the desired 160 objective function. [RFC5440] and [ID-SERVICE-AWARE] defines 161 extension to the PCEP to allow a PCC indicate in a path 162 computation request a bound on given TE metric(s). This draft 163 defines similar mechanisms for the RSVP-TE protocol allowing an 164 ingress node to indicate in a Path request the desired objective 165 function along with any associated TE metric bound(s). The nodes 166 performing route expansion use this information to find the 167 "best" candidate route. 169 2. RSVP-TE signaling extensions 171 This section defines RSVP-TE signaling extensions required to 172 address the above-mentioned requirements. Two new ERO subobject 173 types, Objective Function (OF) and Metric, are defined. Their 174 purpose is as follows. 176 . OF subobject conveys a set of one or more specific 177 optimization criteria that needs be followed in expanding 178 route of a TE-LSP in MultiProtocol Label Switching (MPLS) and 179 GMPLS networks. 181 . Metric Bound subobject indicates the bound on the path metric 182 that needs to be observed for the loose segment to be 183 considered as acceptable by the ingress node. 185 The scope of the Metric and OF subobjects is the node performing 186 the expansion for loose ERO and the subsequent ERO subobject that 187 identifies an abstract node. The following subsection provides 188 the details. 190 2.1. Objective Function (OF) Subobject 192 A new ERO subobject type Objective Function (OF) is defined in 193 order for the ingress node to indicate the required objective 194 function on a loose hop. The ERO subobject type OF is optional. 195 It MAY be carried within an ERO object of RSVP-TE Path message 197 ID draft-ali-ccamp-rc-objective-function-metric-bound-04.txt 199 and its scope is limited to previous ERO subobject that 200 identifies an abstract node. For more details please refer to 201 the Processing Rules for the OF Subobjects section. 203 The OF subobject has the following format: 205 0 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 |L| Type | Length | OF Code | Reserved | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 The fields of OF subobject are defined as follows: 213 L bit: The L bit MUST be set to represent a loose hop in the 214 explicit route. 216 Type: The Type is to be assigned by IANA (suggested value: 217 66). 219 Length: The Length contains the total length of the subobject 220 in bytes, including the Type field, the Length field. The Length 221 of the subobject is 4. 223 OF Code (1 byte): The identifier of the objective function. 224 The following OF code values are suggested. These values are to 225 be assigneyd by IANA. 227 * OF code value 0 is reserved. 229 * OF code value 1 (to be assigned by IANA) is for Minimum TE 230 Metric Cost Path (MTMCP) OF defined in this document. See 231 definition of MTCP OF in the following. 233 * OF code value 2 (to be assigned by IANA) is for Minimum 234 Interior Gateway Protocol (IGP) Metric Cost Path (MIMCP) OF 235 defined in the following. 237 * OF code value 3 (to be assigned by IANA) is for Minimum 238 Load Path (MLP) OF as defined in RFC5541. 240 * OF code value 4 (to be assigned by IANA) is for Maximum 241 Residual Bandwidth Path (MBP) OF as defined in RFC5541. 243 * OF code value 5 (to be assigned by IANA) is for Minimize 244 Aggregate Bandwidth Consumption (MBC) OF as defined in RFC5541. 246 ID draft-ali-ccamp-rc-objective-function-metric-bound-04.txt 248 * OF code value 6 (to be assigned by IANA) is for Minimize 249 the Load of the most loaded Link (MLL) OF as defined in RFC5541. 251 * OF code value 7 is skipped (to keep the objective function 252 code values consistent between [RFC5541] and this draft. 254 * OF code value 8 (to be assigned by IANA) is for Minimum 255 Latency Path (MLP) OF defined in this document. See definition 256 of MLP OF in the following. 258 * OF code value 9 (to be assigned by IANA) is for Minimum 259 Latency Variation Path (MLVP) OF defined in this document. See 260 definition of MLVP OF in the following. 262 Other objective functions may be defined in future. 264 Reserved (5 bytes): This field MUST be set to zero on 265 transmission and MUST be ignored on receipt. 267 2.1.1. Minimum TE Metric Cost Path Objective Function 269 Minimum TE Metric Cost Path (MTMCP) OF is defined as an 270 Objective Function where a path is computed such that the sum of 271 the TE metric of the links along the path is minimized. In the 272 context of loose hop expansion, the ERO expanding node MUST try 273 to find a route such that the sum of the TE metric of the links 274 along the route is minimized. 276 2.1.2. Minimum IGP Metric Cost Path Objective Function 278 Minimum IGP Metric Cost Path (MIMCP) OF is defined as an 279 Objective Function where a path is computed such that the sum of 280 the IGP metric of the links along the path is minimized. In the 281 context of loose hop expansion, the ERO expanding node MUST try 282 to find a route such that the sum of the IGP metric of the links 283 along the route is minimized. 285 2.1.3. Minimum Latency Path Objective Function 287 Minimum Latency Path (MLP) OF is defined as an Objective 288 Function where a path is computed such that latency of the path 289 is minimized. In the context of loose hop expansion, the ERO 290 expanding node MUST try to find a route such that overall 291 latency of the loose hop is minimized. 293 ID draft-ali-ccamp-rc-objective-function-metric-bound-04.txt 295 2.1.4. Minimum Latency Variation Path Objective Function 297 Minimum Latency Variation Path (MLVP) OF is defined as an 298 Objective Function where a path is computed such that latency 299 variation in the path is minimized. In the context of loose hop 300 expansion, the ERO expanding node MUST try to find a route such 301 that overall latency variation of the loose hop is minimized. 303 2.2. Metric Bound subobject 305 The ERO subobject type Metric Bound (MB) is optional. It MAY be 306 carried within an ERO object of RSVP-TE Path message and its 307 scope is limited to previous ERO subobject that identifies an 308 abstract node. It is possible to identify different Metric Bound 309 subobjects for different hops of the ERO to be expanded. For 310 more details please refer to the Processing Rules for the Metric 311 Bound Subobjects section. 313 This subobject has the following format: 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 |L| Type | Length | metric-type |B| Reserved | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | metric-bound | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 The fields of the Metric subobject are defined as follows: 325 L bit: The L bit is set if the subobject represents a loose 326 hop in the explicit route. If the bit is not set, the 327 subobject represents a strict hop in the explicit route. 328 Please note that use of MB subobject is also applicable to 329 strict hops, e.g., in selecting a component link within a 330 heterogeneous bundled TE link. 332 Type: The Type is to be assigned by IANA (suggested value: 333 67). 335 Length: The Length is 8. 337 Metric-type (8 bits): Specifies the metric type associated 338 with the partial route expended by the node processing the 339 loose ERO. The following values are currently defined: 341 ID draft-ali-ccamp-rc-objective-function-metric-bound-04.txt 343 * T=1: cumulative IGP cost 345 * T=2: cumulative TE cost 347 * T=3: Hop Counts 349 * T=4: Cumulative Latency 351 * T=5: Cumulative Latency Variation 353 B bit: Best-effort bit. When the best-effort (B) bit is set, 354 it means that the ingress allows for the set up of an LSP 355 that does not meeting the MB requirement. When the best- 356 effort (B) bit is not set, it means that the MB needs to be 357 observed. 359 Reserved: This field MUST be set to zero on transmission and 360 MUST be ignored on receipt. 362 Metric-bound (32 bits): The metric-bound indicates an upper 363 bound for the path metric that MUST NOT be exceeded for the 364 ERO expending node to consider the computed path as 365 acceptable. The metric bound is encoded in 32 bits using IEEE 366 floating point format as defined in [IEEE.754.1985]). When it 367 indicates a time value (i.e. Latency or Latency Variation) it 368 is expressed in milliseconds. 370 2.3. Processing rules 372 A single OF subobjects SHOULD be used between a pair of 373 abstract nodes in ERO. Multiple Metric Bound subobjects MAY be 374 indicated for each hop to be expanded and MUST be placed after 375 each abstract node subobject. Different Metric Bounds MAY be 376 identified for each hop expansion. 378 2.3.1. Processing Rules for the OF Subobjects 380 The basic processing rules of an ERO are not altered. Please 381 refer to [RFC3209] for details. 383 The scope of the OF subobject is the previous ERO subobject that 384 identifies an abstract node, and the subsequent ERO subobject 385 that identifies an abstract node. Multiple OF subobjects may be 386 present between any pair of abstract nodes. However, only first 387 OF subobject is analyzed and others are ignored. 389 ID draft-ali-ccamp-rc-objective-function-metric-bound-04.txt 391 The following conditions SHOULD result in Path Error with error 392 code "Routing Problem" and error subcode "Bad EXPLICIT_ROUTE 393 object": 395 . If the first OF subobject is not preceded by an ERO subobject 396 identifying the next hop. 397 . If the OF subobject follows an ERO subobject identifying the 398 next hop that does not have the L-bit set. 400 If the processing node does not understand the OF subobject, it 401 SHOULD send a PathErr with the error code "Routing Error" and 402 error value of "Bad Explicit Route Object" toward the sender 403 [RFC3209]. 405 If the processing node understands the OF subobject and the ERO 406 passes the above mentioned sanity check and any other sanity 407 checks associated with other ERO subobjects local to the node, 408 the node takes the following actions: 410 . If the node supports the requested OF, the node expands the 411 loose hop using the requested OF as optimization criterion for 412 computing the route to the next abstract node. After 413 processing, the OF subobjects are removed from the ERO. The 414 rest of the steps for the loose ERO processing follow 415 procedures outlined in [RFC3209]. 416 . If the node understands the OF subobject but does not support 417 the requested OF, it SHOULD send a Path Error with error code 418 "Routing Problem" and a new error subcode "Unsupported 419 Objective Function". The error subcode "Unsupported Objective 420 Function" for Path Error code "Routing Problem" is to be 421 assigned by IANA. 422 . If the OF is supported but policy does not permit applying 423 it, the processing node SHOULD send a Path Error with error 424 code "Policy control failure" (value 2) and subcode "objective 425 function not allowed". The error subcode "objective function 426 not allowed" for Path Error code "Policy control failure" is 427 to be assigned by IANA. 428 2.3.2. Processing Rules for the MB subobject 430 The basic processing rules of an ERO are not altered. Please 431 refer to [RFC3209] for details. 433 ID draft-ali-ccamp-rc-objective-function-metric-bound-04.txt 435 The scope of the MB subobject is between the previous ERO 436 subobject that identifies an abstract node, and the subsequent 437 ERO subobject that identifies an abstract node. Multiple MB 438 subobjects may be present between any pair of abstract nodes. 440 If the processing node does not understand the MB subobject, it 441 SHOULD send a PathErr with the error code "Routing Error" and 442 error value of "Bad Explicit Route Object" toward the sender 443 [RFC3209]. 445 If the processing node understands the MB subobject and the ERO 446 passes the above mentioned sanity check and any other sanity 447 checks associated with other ERO subobjects local to the node, 448 the node takes the following actions: 450 . For all the MB subobject(s), the node expands the ERO such 451 that the requested metric bound(s) are met for the route 452 between the two abstract nodes in the ERO. After processing, 453 the Metric subobjects are removed from the ERO. The rest of 454 the steps for the ERO processing follow procedure outlined in 455 [RFC3209]. 456 . If the node understands the MB subobject but cannot find a 457 route to the next abstract node such that the requested metric 458 bound(s) can be satisfied and the best-effort (B) bit is not 459 set, it SHOULD send a Path Error with error code "Routing 460 Problem" and a new error subcode "No route available toward 461 destination with the requested metric bounds". The error 462 subcode "No route available toward destination with the 463 requested metric bounds" for Path Error code "Routing Problem" 464 is to be assigned by IANA (See IANA section for details). 465 . If the node understands the Metric subobject but cannot find 466 a route to the next abstract node such that the requested 467 metric bound(s) can be satisfied and the best-effort (B) bit 468 is set, it SHOULD send a Path Error message with error code 469 "Notify Error" and a new error subcode "Route not matching the 470 requested metric bounds" is to be assigned by IANA (See IANA 471 section for details). 472 . The ERO expanding node SHOULD respect the Metric Bound 473 constraints in realizing any segment recovery procedure to 474 change the route of the segment expanded by the said node. If 476 ID draft-ali-ccamp-rc-objective-function-metric-bound-04.txt 478 best-effort (B) bit is set and the new recovery segment 479 violates the Metric Bound constraints, the ERO expanding 480 SHOULD send a Path Error message with error code "Notify 481 Error" and a new error subcode "Route not matching the 482 requested metric bounds" is to be assigned by IANA (See IANA 483 section for details). 485 3. Security Considerations 487 This document does not introduce any additional security issues 488 above those identified in [RFC5920], [RFC2205], [RFC3209], and 489 [RFC3473]. 491 4. IANA Considerations 493 4.1. ERO Subobject 495 This document adds the following two new subobject of the 496 existing entry for ERO (20, EXPLICIT_ROUTE): 498 Value Description 500 ----- ------------ 502 TBA (suggest value: 66) Objective Function (OF) subobject 504 TBA (suggest value: 67) Metric subobject 506 These subobject may be present in the Explicit Route Object, but 507 not in the Route Record Object. 509 OF Code values carried in OF subobject requires an IANA entry 510 with suggested values as defined in section 2.1. 512 4.2. New RSVP error sub-code 514 For Error Code = 24 "Routing Problem" (see [RFC2205]) the 515 following sub-code is defined. 517 Sub-code Value 518 -------- ----- 520 No route available toward destination To be assigned by IANA. 521 with the requested metric bounds Suggested Value: TBA. 523 For Error Code = 25 "Notify Error" (see [RFC2205]) the following 524 sub-code is defined. 526 ID draft-ali-ccamp-rc-objective-function-metric-bound-04.txt 528 Sub-code Value 529 -------- ----- 531 Route not matching the requested To be assigned by IANA. 532 metric bounds Suggested Value: TBA. 534 5. Acknowledgments 536 Authors would like to thank Matt Hartley, Ori Gerstel, Gabriele 537 Maria Galimberti, Luyuan Fang and Walid Wakim for their review 538 comments. 540 6. References 542 6.1. Normative References 544 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 545 Requirement Levels", BCP 14, RFC 2119, March 1997. 547 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 548 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 549 LSP Tunnels", RFC 3209, December 2001. 551 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 552 Switching (GMPLS) Signaling Resource ReserVation 553 Protocol-Traffic Engineering (RSVP-TE) Extensions", 554 RFC 3473, January 2003. 556 [IEEE.754.1985] IEEE Standard 754, "Standard for Binary 557 Floating-Point Arithmetic", August 1985. 559 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 560 "Generalized Multiprotocol Label Switching (GMPLS) 561 User-Network Interface (UNI): Resource ReserVation 562 Protocol-Traffic Engineering (RSVP-TE) Support for the 563 Overlay Model", RFC 4208, October 2005. 565 6.2. Informative References 566 ID draft-ali-ccamp-rc-objective-function-metric-bound-04.txt 568 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 569 Networks", RFC 5920, July 2010. 571 [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 572 Computation Element (PCE) Communication Protocol 573 (PCEP)", RFC 5440, March 2009. 575 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 576 Objective Functions in the Path Computation Element 577 Communication Protocol (PCEP)", RFC 5541, June 2009. 579 [ID-SERVICE-AWARE] D. Dhody, V. Manral, Z. Ali, G. Swallow, K. 580 Kumaki, " Extensions to the Path Computation Element 581 Communication Protocol (PCEP) to compute service aware 582 Label Switched Path (LSP)", draft-ietf-pce-pcep- 583 service-aware, work in progress. 585 [OSPF-TE-METRIC] S. Giacalone, D. Ward, J. Drake, A. Atlas, S. 586 Previdi, "OSPF Traffic Engineering (TE) Metric 587 Extensions", draft-ietf-ospf-te-metric-extensions, 588 work in progress. 590 [ISIS-TE-METRIC] S. Previdi, S. Giacalone, D. Ward, J. Drake, A. 591 Atlas, C. Filsfils, "IS-IS Traffic Engineering (TE) 592 Metric Extensions", draft-previdi-isis-te-metric- 593 extensions, work in progress. 595 Author's Addresses 597 Zafar Ali 598 Cisco Systems. 599 Email: zali@cisco.com 601 George Swallow 602 Cisco Systems. 603 swallow@cisco.com 605 Clarence Filsfils 606 Cisco Systems. 607 cfilsfil@cisco.com 609 Luyuan Fang 610 Cisco Systems. 611 lufang@cisco.com 613 ID draft-ali-ccamp-rc-objective-function-metric-bound-04.txt 615 Kenji Kumaki 616 KDDI Corporation 617 Email: ke-kumaki@kddi.com 619 Rudiger Kunze 620 Deutsche Telekom AG 621 Ruediger.Kunze@telekom.de 623 Daniele Ceccarelli 624 Ericsson 625 Email: daniele.ceccarelli@ericsson.com 627 Xian Zhang 628 Huawei Technologies 629 Email: zhang.xian@huawei.com