idnits 2.17.1 draft-ali-teas-rc-objective-function-metric-bound-00.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 70 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (July 6, 2015) is 3215 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: 'RFC 4208' is mentioned on line 147, but not defined == Missing Reference: 'RFC2205' is mentioned on line 524, but not defined == Unused Reference: 'RFC4208' is defined on line 557, but no explicit reference was found in the text == Unused Reference: 'RFC2209' is defined on line 567, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 574, but no explicit reference was found in the text == Unused Reference: 'ID-SERVICE-AWARE' is defined on line 582, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754.1985' Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group Zafar Ali 2 Internet Draft George Swallow 3 Intended status: Standard Track Clarence Filsfils 4 Expires: January 5, 2016 Cisco Systems 5 Luyuan Fang 6 Microsoft 7 Kenji Kumaki 8 KDDI Corporation 9 Ruediger Kunze 10 Deutsche Telekom AG 11 Daniele Ceccarelli 12 Ericsson 13 Xian Zhang 14 Huawei 15 July 6, 2015 17 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) 18 Extension for Signaling Objective Function and Metric Bound 19 draft-ali-teas-rc-objective-function-metric-bound-00.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 January 5, 2016. 39 Copyright Notice 41 Copyright (c) 2015 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 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) 60 controlling the copyright in such materials, this document may not 61 be modified outside the IETF Standards Process, and derivative 62 works of it may not be created outside the IETF Standards Process, 63 except to format it for publication as an RFC or to translate it 64 into languages other than English. 66 ID draft-ali-teas-rc-objective-function-metric-bound-00.txt 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 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 where the ingress node needs to indicate 86 a TE metric bound for a loose segment that is expanded by a remote 87 node. 89 This document defines extensions to the RSVP-TE Protocol to allow 90 an ingress node to request the required objective function for the 91 route computation, as well as a metric bound to influence route 92 computation decisions at a remote node(s). 94 ID draft-ali-teas-rc-objective-function-metric-bound-00.txt 96 Conventions used in this document 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 100 this document are to be interpreted as described in RFC 2119 101 [RFC2119]. 103 Table of Contents 105 Copyright Notice..................................................1 106 1. Introduction...................................................3 107 2. RSVP-TE signaling extensions...................................4 108 2.1. Objective Function (OF) Subobject......................4 109 2.1.1. Minimum TE Metric Cost Path Objective Function....6 110 2.1.2. Minimum IGP Metric Cost Path Objective Function...6 111 2.1.3. Minimum Latency Path Objective Function...........6 112 2.1.4. Minimum Latency Variation Path Objective Function.7 113 2.2. Metric subobject.......................................7 114 2.3. Processing Rules for the OF Subobjects.................8 115 2.4. Processing Rules for the Metric subobject..............9 116 3. Security Considerations.......................................11 117 4. IANA Considerations...........................................11 118 5. Acknowledgments...............................................12 119 6. References....................................................12 120 6.1. Normative References..................................12 121 6.2. Informative References................................13 123 1. Introduction 125 As noted in [OSPF-TE-METRIC] and [ISIS-TE-METRIC], in certain 126 networks such as financial information networks, performance 127 criteria such as latency are becoming critical to data path 128 selection along with other metrics. Such networks may require 129 selection of a path that minimizes end-to-end latency. Or a path 130 may need to be found that minimizes some other TE metric(s), 131 while subject to a latency bound. In summary, there is a 132 requirement to find end-to-end paths with different optimization 133 criteria while subjected to a metric bound. 135 When the entire route for an LSP is computed at the ingress node, 136 this requirement can be met by a local decision at that node. 137 However, there are scenarios where partial or full route 138 computations are performed by remote nodes. The scenarios include 139 (but are not limited to): 141 . LSPs with loose hops in the Explicit Route Object (ERO), 142 including intra-domain LSPs. 144 ID draft-ali-teas-rc-objective-function-metric-bound-00.txt 146 . GMPLS-UNI where route computation may be performed by the 147 UNI-Network (server) node [RFC 4208]; 149 . Multi domain LSP setup with per domain path computation; 151 In these scenarios, there is a need for the ingress node to 152 convey the optimization criteria (e.g., IGP cost, TE cost, hop 153 counts, latency, etc.) to be used for the path computation to the 154 node performing route computation or expansion. Similarly, there 155 is a need for the ingress node to indicate a TE metric bound for 156 the loose segment being expanded by a remote node. 158 This draft defines mechanisms for the RSVP-TE protocol allowing 159 an ingress node to indicate in a Path request the desired 160 objective function along with any associated TE metric bound(s). 161 The nodes performing route expansion use this information to 162 find the "best" candidate route. 164 2. RSVP-TE signaling extensions 166 This section defines RSVP-TE signaling extensions required to 167 address the above-mentioned requirements. Two new ERO subobject 168 types, Objective Function (OF) and Metric, are defined. Their 169 purpose is as follows. 171 . OF subobject conveys a set of one or more specific 172 optimization criteria that needs be followed in expanding 173 route of a TE-LSP in MultiProtocol Label Switching (MPLS) and 174 GMPLS networks. 176 . Metric Bound subobject indicates the bound on the path metric 177 that needs to be observed for the loose segment to be 178 considered as acceptable by the ingress node. 180 The scope of the Metric and OF subobjects is the node performing 181 the expansion for loose ERO and the subsequent ERO subobject that 182 identifies an abstract node. The following subsection provides 183 the details. 185 2.1. Objective Function (OF) Subobject 187 A new ERO subobject type Objective Function (OF) is defined in 188 order for the ingress node to indicate the required objective 189 function on a loose hop. The ERO subobject type OF is optional. 190 It MAY be carried within an ERO object of RSVP-TE Path message 191 and its scope is limited to the node performing the expansion 192 for loose ERO and the subsequent ERO subobject that identifies 194 ID draft-ali-teas-rc-objective-function-metric-bound-00.txt 196 an abstract node. For more details please refer to the 197 Processing Rules for the OF Subobjects section. 199 The OF subobject has the following format: 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 |L| Type | Length | OF Code | Reserved | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 The fields of OF subobject are defined as follows: 209 L bit: The L bit MUST be set to represent a loose hop in the 210 explicit route. 212 Type: The Type is to be assigned by IANA (suggested value: 213 66). 215 Length: The Length contains the total length of the subobject 216 in bytes, including the Type field, the Length field. The Length 217 of the subobject is 4. 219 OF Code (8 bits): The identifier of the objective function. 220 The following OF code values are suggested. These values are to 221 be assigned by IANA. 223 * OF code value 0 is reserved. 225 * OF code value 1 (to be assigned by IANA) is for Minimum TE 226 Metric Cost Path (MTMCP) OF defined in this document. See 227 definition of MTCP OF in the following. 229 * OF code value 2 (to be assigned by IANA) is for Minimum 230 Interior Gateway Protocol (IGP) Metric Cost Path (MIMCP) OF 231 defined in the following. 233 * OF code value 3 (to be assigned by IANA) is for Minimum 234 Load Path (MLP) OF as defined in RFC5541. 236 * OF code value 4 (to be assigned by IANA) is for Maximum 237 Residual Bandwidth Path (MBP) OF as defined in RFC5541. 239 * OF code value 5 (to be assigned by IANA) is for Minimize 240 Aggregate Bandwidth Consumption (MBC) OF as defined in RFC5541. 242 ID draft-ali-teas-rc-objective-function-metric-bound-00.txt 244 * OF code value 6 (to be assigned by IANA) is for Minimize 245 the Load of the most loaded Link (MLL) OF as defined in RFC5541. 247 - OF code value 7 is skipped (to keep the objective function 248 code values consistent between [RFC5541] and this draft. 250 * OF code value 8 (to be assigned by IANA) is for Minimum 251 Latency Path (MLP) OF defined in this document. See definition 252 of MLP OF in the following. 254 * OF code value 9 (to be assigned by IANA) is for Minimum 255 Latency Variation Path (MLVP) OF defined in this document. See 256 definition of MLVP OF in the following. 258 Other objective functions may be defined in future. 260 Reserved (8 bits): This field MUST be set to zero on 261 transmission and MUST be ignored on receipt. 263 2.1.1. Minimum TE Metric Cost Path Objective Function 265 Minimum TE Metric Cost Path (MTMCP) OF is defined as an 266 Objective Function where a path is computed such that the sum of 267 the TE metric of the links along the path is minimized. In the 268 context of loose hop expansion, the ERO expanding node MUST try 269 to find a route such that the sum of the TE metric of the links 270 along the route is minimized. 272 2.1.2. Minimum IGP Metric Cost Path Objective Function 274 Minimum IGP Metric Cost Path (MIMCP) OF is defined as an 275 Objective Function where a path is computed such that the sum of 276 the IGP metric of the links along the path is minimized. In the 277 context of loose hop expansion, the ERO expanding node MUST try 278 to find a route such that the sum of the IGP metric of the links 279 along the route is minimized. 281 2.1.3. Minimum Latency Path Objective Function 283 Minimum Latency Path (MLP) OF is defined as an Objective 284 Function where a path is computed such that latency of the path 285 is minimized. In the context of loose hop expansion, the ERO 286 expanding node MUST try to find a route such that overall 287 latency of the loose hop is minimized. 289 ID draft-ali-teas-rc-objective-function-metric-bound-00.txt 291 2.1.4. Minimum Latency Variation Path Objective Function 293 Minimum Latency Variation Path (MLVP) OF is defined as an 294 Objective Function where a path is computed such that latency 295 variation in the path is minimized. In the context of loose hop 296 expansion, the ERO expanding node MUST try to find a route such 297 that overall latency variation of the loose hop is minimized. 299 2.2. Metric Bound subobject 301 The ERO subobject type Metric Bound (MB) is optional. It MAY be 302 carried within an ERO object of RSVP-TE Path message and its 303 scope is limited to the node performing the expansion for loose 304 ERO and the subsequent ERO subobject that identifies an abstract 305 node. It is possible to identify different Metric Bound 306 subobjects for different loose hops of the ERO to be expanded. 307 For more details please refer to the Processing Rules for the 308 Metric Bound Subobjects section. 310 This subobject has the following format: 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |L| Type | Length |metric-type|B| Reserved | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | metric-bound | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 The fields of the Metric subobject are defined as follows: 322 L bit: The L bit is set if the subobject represents a loose 323 hop in the explicit route. If the bit is not set, the 324 subobject represents a strict hop in the explicit route. 325 Please note that use of MB subobject is also applicable to 326 strict hops, e.g., in selecting a component link within a 327 heterogeneous bundled TE link. 329 Type: The Type is to be assigned by IANA (suggested value: 330 67). 332 Length: The Length is 8. 334 Metric-type (6 bits): Specifies the metric type associated 335 with the bound. The following values are currently defined: 337 ID draft-ali-teas-rc-objective-function-metric-bound-00.txt 339 * T=1: cumulative IGP cost 341 * T=2: cumulative TE cost 343 * T=3: Hop Count 345 * T=4: Cumulative Latency 347 * T=5: Cumulative Latency Variation 349 B bit: Best-effort bit. When the best-effort (B) bit is set, 350 it means that the ingress node allows loose hop expansion 351 that does not meeting the MB requirement. When the best- 352 effort (B) bit is not set, it means that the MB MUST be 353 observed. 355 Reserved (9 bits): This field MUST be set to zero on 356 transmission and MUST be ignored on receipt. 358 Metric-bound (32 bits): The metric-bound indicates an upper 359 metric bound for the loose hop. The metric bound is encoded 360 in 32 bits using IEEE floating point format as defined in 361 [IEEE.754.1985]). When it indicates a time value (i.e. 362 Latency or Latency Variation) it is expressed in 363 milliseconds. 365 2.3. Processing rules 367 2.3.1. Processing Rules for the OF Subobjects 369 A single OF subobjects SHOULD be used between a pair of abstract 370 nodes in ERO. Same OF SHOULD be identified for each hop 371 expansion. 373 The basic processing rules of an ERO are not altered. Please 374 refer to [RFC3209] for details. 376 The scope of the OF subobject is the previous ERO subobject that 377 identifies an abstract node, and the subsequent ERO subobject 378 that identifies an abstract node. Multiple OF subobjects MAY be 379 present between any pair of abstract nodes. However, only first 380 OF subobject is analyzed and others are ignored. 382 The following conditions SHOULD result in Path Error with error 383 code "Routing Problem" and error subcode "Bad EXPLICIT_ROUTE 384 object": 386 ID draft-ali-teas-rc-objective-function-metric-bound-00.txt 388 . If the first OF subobject is not preceded by an ERO subobject 389 identifying the next hop. 390 . If the OF subobject follows an ERO subobject identifying the 391 next hop that does not have the L-bit set. 393 If the processing node does not understand the OF subobject, it 394 SHOULD send a PathErr with the error code "Routing Error" and 395 error value of "Bad Explicit Route Object" toward the sender 396 [RFC3209]. 398 If the processing node understands the OF subobject and the ERO 399 passes the above mentioned sanity check and any other sanity 400 checks associated with other ERO subobjects local to the node, 401 the node takes the following actions: 403 . If the node supports the requested OF, the node expands the 404 loose hop using the requested OF as optimization criterion for 405 computing the route to the next abstract node. After 406 processing, the OF subobjects are removed from the ERO. The 407 rest of the steps for the loose ERO processing follow 408 procedures outlined in [RFC3209]. 409 . If the node understands the OF subobject but does not support 410 the requested OF, it SHOULD send a Path Error with error code 411 "Routing Problem" and a new error subcode "Unsupported 412 Objective Function". The error subcode "Unsupported Objective 413 Function" for Path Error code "Routing Problem" is to be 414 assigned by IANA. 415 . If the OF is supported but policy does not permit applying 416 it, the processing node SHOULD send a Path Error with error 417 code "Policy control failure" (value 2) and subcode "objective 418 function not allowed". The error subcode "objective function 419 not allowed" for Path Error code "Policy control failure" is 420 to be assigned by IANA. 421 2.3.2. Processing Rules for the MB subobject 423 Multiple Metric Bound subobjects MAY be indicated for each hop 424 to be expanded and MUST be placed after each abstract node 425 subobject. Different Metric Bounds MAY be identified for each 426 hop expansion. 428 ID draft-ali-teas-rc-objective-function-metric-bound-00.txt 430 The basic processing rules of an ERO are not altered. Please 431 refer to [RFC3209] for details. 433 The scope of the MB subobject is between the previous ERO 434 subobject that identifies an abstract node, and the subsequent 435 ERO subobject that identifies an abstract node. Multiple MB 436 subobjects may be present between any pair of abstract nodes. 438 If the processing node does not understand the MB subobject, it 439 SHOULD send a PathErr with the error code "Routing Error" and 440 error value of "Bad Explicit Route Object" toward the sender 441 [RFC3209]. 443 If the processing node understands the MB subobject and the ERO 444 passes the above mentioned sanity check and any other sanity 445 checks associated with other ERO subobjects local to the node, 446 the node takes the following actions: 448 . For all the MB subobject(s), the node expands the ERO such 449 that the requested metric bound(s) are met for the route 450 between the two abstract nodes in the ERO. After processing, 451 the Metric subobjects are removed from the ERO. The rest of 452 the steps for the ERO processing follow procedure outlined in 453 [RFC3209]. 454 . If the node understands the MB subobject but cannot find a 455 route to the next abstract node such that the requested metric 456 bound(s) can be satisfied and the best-effort (B) bit is not 457 set, it SHOULD send a Path Error with error code "Routing 458 Problem" and a new error subcode "No route available toward 459 destination with the requested metric bounds". The error 460 subcode "No route available toward destination with the 461 requested metric bounds" for Path Error code "Routing Problem" 462 is to be assigned by IANA (See IANA section for details). 463 . If the node understands the Metric subobject but cannot find 464 a route to the next abstract node such that the requested 465 metric bound(s) can be satisfied and the best-effort (B) bit 466 is set, it SHOULD send a Path Error message with error code 467 "Notify Error" and a new error subcode "Route not matching the 468 requested metric bounds" is to be assigned by IANA (See IANA 469 section for details). 471 ID draft-ali-teas-rc-objective-function-metric-bound-00.txt 473 . The ERO expanding node SHOULD respect the Metric Bound 474 constraints in realizing any segment recovery procedure to 475 change the route of the segment expanded by the said node. If 476 best-effort (B) bit is set and the new recovery segment 477 violates the Metric Bound constraints, the ERO expanding 478 SHOULD send a Path Error message with error code "Notify 479 Error" and a new error subcode "Route not matching the 480 requested metric bounds" is to be assigned by IANA (See IANA 481 section for details). 483 3. Security Considerations 485 This document does not introduce any additional security issues 486 above those identified in [RFC5920], [RFC2205], [RFC3209], and 487 [RFC3473]. 489 4. IANA Considerations 491 4.1. ERO Subobject 493 This document adds the following two new subobject of the 494 existing entry for ERO (20, EXPLICIT_ROUTE): 496 Value Description 498 ----- ------------ 500 TBA (suggest value: 66) Objective Function (OF) subobject 502 TBA (suggest value: 67) Metric subobject 504 These subobject may be present in the Explicit Route Object, but 505 not in the Route Record Object. 507 OF Code values carried in OF subobject requires an IANA entry 508 with suggested values as defined in section 2.1. 510 4.2. New RSVP error sub-code 512 For Error Code = 24 "Routing Problem" (see [RFC2205]) the 513 following sub-code is defined. 515 Sub-code Value 516 -------- ----- 518 No route available toward destination To be assigned by IANA. 520 ID draft-ali-teas-rc-objective-function-metric-bound-00.txt 522 with the requested metric bounds Suggested Value: TBA. 524 For Error Code = 25 "Notify Error" (see [RFC2205]) the following 525 sub-code is defined. 527 Sub-code Value 528 -------- ----- 530 Route not matching the requested To be assigned by IANA. 531 metric bounds Suggested Value: TBA. 533 5. Acknowledgments 535 Authors would like to thank Matt Hartley, Ori Gerstel, Gabriele 536 Maria Galimberti, and Walid Wakim for their review comments. 538 6. References 540 6.1. Normative References 542 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 543 Requirement Levels", BCP 14, RFC 2119, March 1997. 545 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 546 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 547 LSP Tunnels", RFC 3209, December 2001. 549 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 550 Switching (GMPLS) Signaling Resource ReserVation 551 Protocol-Traffic Engineering (RSVP-TE) Extensions", 552 RFC 3473, January 2003. 554 [IEEE.754.1985] IEEE Standard 754, "Standard for Binary 555 Floating-Point Arithmetic", August 1985. 557 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 558 "Generalized Multiprotocol Label Switching (GMPLS) 559 User-Network Interface (UNI): Resource ReserVation 560 Protocol-Traffic Engineering (RSVP-TE) Support for the 561 Overlay Model", RFC 4208, October 2005. 563 ID draft-ali-teas-rc-objective-function-metric-bound-00.txt 565 6.2. Informative References 567 [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation 568 Protocol (RSVP) -- Version 1 Message Processing 569 Rules", RFC 2209, September 1997. 571 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 572 Networks", RFC 5920, July 2010. 574 [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 575 Computation Element (PCE) Communication Protocol 576 (PCEP)", RFC 5440, March 2009. 578 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 579 Objective Functions in the Path Computation Element 580 Communication Protocol (PCEP)", RFC 5541, June 2009. 582 [ID-SERVICE-AWARE] D. Dhody, V. Manral, Z. Ali, G. Swallow, K. 583 Kumaki, " Extensions to the Path Computation Element 584 Communication Protocol (PCEP) to compute service aware 585 Label Switched Path (LSP)", draft-ietf-pce-pcep- 586 service-aware, work in progress. 588 [OSPF-TE-METRIC] S. Giacalone, D. Ward, J. Drake, A. Atlas, S. 589 Previdi, "OSPF Traffic Engineering (TE) Metric 590 Extensions", draft-ietf-ospf-te-metric-extensions, 591 work in progress. 593 [ISIS-TE-METRIC] S. Previdi, S. Giacalone, D. Ward, J. Drake, A. 594 Atlas, C. Filsfils, "IS-IS Traffic Engineering (TE) 595 Metric Extensions", draft-previdi-isis-te-metric- 596 extensions, work in progress. 598 Authors' Addresses 600 Zafar Ali 601 Cisco Systems. 602 Email: zali@cisco.com 604 George Swallow 605 Cisco Systems. 606 swallow@cisco.com 608 Clarence Filsfils 610 ID draft-ali-teas-rc-objective-function-metric-bound-00.txt 612 Cisco Systems. 613 cfilsfil@cisco.com 615 Luyuan Fang 616 Microsoft 617 lufang@microsoft.com 619 Kenji Kumaki 620 KDDI Corporation 621 Email: ke-kumaki@kddi.com 623 Rudiger Kunze 624 Deutsche Telekom AG 625 Ruediger.Kunze@telekom.de 627 Daniele Ceccarelli 628 Ericsson 629 Email: daniele.ceccarelli@ericsson.com 631 Xian Zhang 632 Huawei Technologies 633 Email: zhang.xian@huawei.com