idnits 2.17.1 draft-ali-ccamp-rc-objective-function-metric-bound-05.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 77 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 (February 14, 2014) is 3714 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 148, but not defined == Missing Reference: 'RFC2205' is mentioned on line 525, but not defined == Unused Reference: 'RFC4208' is defined on line 558, but no explicit reference was found in the text == Unused Reference: 'RFC2209' is defined on line 568, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 575, but no explicit reference was found in the text == Unused Reference: 'ID-SERVICE-AWARE' is defined on line 583, 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. -------------------------------------------------------------------------------- 2 CCAMP Working Group Zafar Ali 3 Internet Draft George Swallow 4 Intended status: Standard Track Clarence Filsfils 5 Expires: August 13, 2014 Cisco Systems 6 Luyuan Fang 7 Microsoft 8 Kenji Kumaki 9 KDDI Corporation 10 Ruediger Kunze 11 Deutsche Telekom AG 12 Daniele Ceccarelli 13 Ericsson 14 Xian Zhang 15 Huawei 16 February 14, 2014 18 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) 19 Extension for Signaling Objective Function and Metric Bound 20 draft-ali-ccamp-rc-objective-function-metric-bound-05.txt 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current 30 Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet-Drafts 35 as reference material or to cite them other than as "work in 36 progress." 38 This Internet-Draft will expire on August 13, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with 50 respect to this document. Code Components extracted from this 51 document must include Simplified BSD License text as described in 52 Section 4.e of the Trust Legal Provisions and are provided without 53 warranty as described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) 61 controlling the copyright in such materials, this document may not 62 be modified outside the IETF Standards Process, and derivative 63 works of it may not be created outside the IETF Standards Process, 64 except to format it for publication as an RFC or to translate it 65 into languages other than English. 67 ID draft-ali-ccamp-rc-objective-function-metric-bound-05.txt 69 Abstract 71 In particular networks such as those used by financial 72 institutions, network performance criteria such as latency are 73 becoming critical to data path selection. However cost is still an 74 important consideration. This leads to a situation where path 75 calculation involves multiple metrics and more complex objective 76 functions. 78 When using GMPLS control plane, there are many scenarios in which a 79 node may need to request a remote node to perform path computation 80 or expansion, like for example multi-domain LSP setup, Generalized 81 Multi-Protocol Label Switching (GMPLS) User-Network Interface (UNI) 82 or simply the utilization of a loose ERO in intra domain signaling. 83 In such cases, the node requesting the setup of an LSP needs to 84 convey the required objective function to the remote node, to 85 enable it to perform route computation in the desired fashion. 86 Similarly, there are cases where the ingress node needs to indicate 87 a TE metric bound for a loose segment that is expanded by a remote 88 node. 90 This document defines extensions to the RSVP-TE Protocol to allow 91 an ingress node to request the required objective function for the 92 route computation, as well as a metric bound to influence route 93 computation decisions at a remote node(s). 95 ID draft-ali-ccamp-rc-objective-function-metric-bound-05.txt 97 Conventions used in this document 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 101 this document are to be interpreted as described in RFC 2119 102 [RFC2119]. 104 Table of Contents 106 Copyright Notice..................................................1 107 1. Introduction...................................................3 108 2. RSVP-TE signaling extensions...................................4 109 2.1. Objective Function (OF) Subobject......................4 110 2.1.1. Minimum TE Metric Cost Path Objective Function....6 111 2.1.2. Minimum IGP Metric Cost Path Objective Function...6 112 2.1.3. Minimum Latency Path Objective Function...........6 113 2.1.4. Minimum Latency Variation Path Objective Function.7 114 2.2. Metric subobject.......................................7 115 2.3. Processing Rules for the OF Subobjects.................8 116 2.4. Processing Rules for the Metric subobject..............9 117 3. Security Considerations.......................................11 118 4. IANA Considerations...........................................11 119 5. Acknowledgments...............................................12 120 6. References....................................................12 121 6.1. Normative References..................................12 122 6.2. Informative References................................13 124 1. Introduction 126 As noted in [OSPF-TE-METRIC] and [ISIS-TE-METRIC], in certain 127 networks such as financial information networks, performance 128 criteria such as latency are becoming critical to data path 129 selection along with other metrics. Such networks may require 130 selection of a path that minimizes end-to-end latency. Or a path 131 may need to be found that minimizes some other TE metric(s), 132 while subject to a latency bound. In summary, there is a 133 requirement to find end-to-end paths with different optimization 134 criteria while subjected to a metric bound. 136 When the entire route for an LSP is computed at the ingress node, 137 this requirement can be met by a local decision at that node. 138 However, there are scenarios where partial or full route 139 computations are performed by remote nodes. The scenarios include 140 (but are not limited to): 142 . LSPs with loose hops in the Explicit Route Object (ERO), 143 including intra-domain LSPs. 145 ID draft-ali-ccamp-rc-objective-function-metric-bound-05.txt 147 . GMPLS-UNI where route computation may be performed by the 148 UNI-Network (server) node [RFC 4208]; 150 . Multi domain LSP setup with per domain path computation; 152 In these scenarios, there is a need for the ingress node to 153 convey the optimization criteria (e.g., IGP cost, TE cost, hop 154 counts, latency, etc.) to be used for the path computation to the 155 node performing route computation or expansion. Similarly, there 156 is a need for the ingress node to indicate a TE metric bound for 157 the loose segment being expanded by a remote node. 159 This draft defines mechanisms for the RSVP-TE protocol allowing 160 an ingress node to indicate in a Path request the desired 161 objective function along with any associated TE metric bound(s). 162 The nodes performing route expansion use this information to 163 find the "best" candidate route. 165 2. RSVP-TE signaling extensions 167 This section defines RSVP-TE signaling extensions required to 168 address the above-mentioned requirements. Two new ERO subobject 169 types, Objective Function (OF) and Metric, are defined. Their 170 purpose is as follows. 172 . OF subobject conveys a set of one or more specific 173 optimization criteria that needs be followed in expanding 174 route of a TE-LSP in MultiProtocol Label Switching (MPLS) and 175 GMPLS networks. 177 . Metric Bound subobject indicates the bound on the path metric 178 that needs to be observed for the loose segment to be 179 considered as acceptable by the ingress node. 181 The scope of the Metric and OF subobjects is the node performing 182 the expansion for loose ERO and the subsequent ERO subobject that 183 identifies an abstract node. The following subsection provides 184 the details. 186 2.1. Objective Function (OF) Subobject 188 A new ERO subobject type Objective Function (OF) is defined in 189 order for the ingress node to indicate the required objective 190 function on a loose hop. The ERO subobject type OF is optional. 191 It MAY be carried within an ERO object of RSVP-TE Path message 192 and its scope is limited to the node performing the expansion 193 for loose ERO and the subsequent ERO subobject that identifies 195 ID draft-ali-ccamp-rc-objective-function-metric-bound-05.txt 197 an abstract node. For more details please refer to the 198 Processing Rules for the OF Subobjects section. 200 The OF subobject has the following format: 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 |L| Type | Length | OF Code | Reserved | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 The fields of OF subobject are defined as follows: 210 L bit: The L bit MUST be set to represent a loose hop in the 211 explicit route. 213 Type: The Type is to be assigned by IANA (suggested value: 214 66). 216 Length: The Length contains the total length of the subobject 217 in bytes, including the Type field, the Length field. The Length 218 of the subobject is 4. 220 OF Code (8 bits): The identifier of the objective function. 221 The following OF code values are suggested. These values are to 222 be assigned by IANA. 224 * OF code value 0 is reserved. 226 * OF code value 1 (to be assigned by IANA) is for Minimum TE 227 Metric Cost Path (MTMCP) OF defined in this document. See 228 definition of MTCP OF in the following. 230 * OF code value 2 (to be assigned by IANA) is for Minimum 231 Interior Gateway Protocol (IGP) Metric Cost Path (MIMCP) OF 232 defined in the following. 234 * OF code value 3 (to be assigned by IANA) is for Minimum 235 Load Path (MLP) OF as defined in RFC5541. 237 * OF code value 4 (to be assigned by IANA) is for Maximum 238 Residual Bandwidth Path (MBP) OF as defined in RFC5541. 240 * OF code value 5 (to be assigned by IANA) is for Minimize 241 Aggregate Bandwidth Consumption (MBC) OF as defined in RFC5541. 243 ID draft-ali-ccamp-rc-objective-function-metric-bound-05.txt 245 * OF code value 6 (to be assigned by IANA) is for Minimize 246 the Load of the most loaded Link (MLL) OF as defined in RFC5541. 248 - OF code value 7 is skipped (to keep the objective function 249 code values consistent between [RFC5541] and this draft. 251 * OF code value 8 (to be assigned by IANA) is for Minimum 252 Latency Path (MLP) OF defined in this document. See definition 253 of MLP OF in the following. 255 * OF code value 9 (to be assigned by IANA) is for Minimum 256 Latency Variation Path (MLVP) OF defined in this document. See 257 definition of MLVP OF in the following. 259 Other objective functions may be defined in future. 261 Reserved (8 bits): This field MUST be set to zero on 262 transmission and MUST be ignored on receipt. 264 2.1.1. Minimum TE Metric Cost Path Objective Function 266 Minimum TE Metric Cost Path (MTMCP) OF is defined as an 267 Objective Function where a path is computed such that the sum of 268 the TE metric of the links along the path is minimized. In the 269 context of loose hop expansion, the ERO expanding node MUST try 270 to find a route such that the sum of the TE metric of the links 271 along the route is minimized. 273 2.1.2. Minimum IGP Metric Cost Path Objective Function 275 Minimum IGP Metric Cost Path (MIMCP) OF is defined as an 276 Objective Function where a path is computed such that the sum of 277 the IGP metric of the links along the path is minimized. In the 278 context of loose hop expansion, the ERO expanding node MUST try 279 to find a route such that the sum of the IGP metric of the links 280 along the route is minimized. 282 2.1.3. Minimum Latency Path Objective Function 284 Minimum Latency Path (MLP) OF is defined as an Objective 285 Function where a path is computed such that latency of the path 286 is minimized. In the context of loose hop expansion, the ERO 287 expanding node MUST try to find a route such that overall 288 latency of the loose hop is minimized. 290 ID draft-ali-ccamp-rc-objective-function-metric-bound-05.txt 292 2.1.4. Minimum Latency Variation Path Objective Function 294 Minimum Latency Variation Path (MLVP) OF is defined as an 295 Objective Function where a path is computed such that latency 296 variation in the path is minimized. In the context of loose hop 297 expansion, the ERO expanding node MUST try to find a route such 298 that overall latency variation of the loose hop is minimized. 300 2.2. Metric Bound subobject 302 The ERO subobject type Metric Bound (MB) is optional. It MAY be 303 carried within an ERO object of RSVP-TE Path message and its 304 scope is limited to the node performing the expansion for loose 305 ERO and the subsequent ERO subobject that identifies an abstract 306 node. It is possible to identify different Metric Bound 307 subobjects for different loose hops of the ERO to be expanded. 308 For more details please refer to the Processing Rules for the 309 Metric Bound Subobjects section. 311 This subobject has the following format: 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 |L| Type | Length |metric-type|B| Reserved | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | metric-bound | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 The fields of the Metric subobject are defined as follows: 323 L bit: The L bit is set if the subobject represents a loose 324 hop in the explicit route. If the bit is not set, the 325 subobject represents a strict hop in the explicit route. 326 Please note that use of MB subobject is also applicable to 327 strict hops, e.g., in selecting a component link within a 328 heterogeneous bundled TE link. 330 Type: The Type is to be assigned by IANA (suggested value: 331 67). 333 Length: The Length is 8. 335 Metric-type (6 bits): Specifies the metric type associated 336 with the bound. The following values are currently defined: 338 ID draft-ali-ccamp-rc-objective-function-metric-bound-05.txt 340 * T=1: cumulative IGP cost 342 * T=2: cumulative TE cost 344 * T=3: Hop Count 346 * T=4: Cumulative Latency 348 * T=5: Cumulative Latency Variation 350 B bit: Best-effort bit. When the best-effort (B) bit is set, 351 it means that the ingress node allows loose hop expansion 352 that does not meeting the MB requirement. When the best- 353 effort (B) bit is not set, it means that the MB MUST be 354 observed. 356 Reserved (9 bits): This field MUST be set to zero on 357 transmission and MUST be ignored on receipt. 359 Metric-bound (32 bits): The metric-bound indicates an upper 360 metric bound for the loose hop. The metric bound is encoded 361 in 32 bits using IEEE floating point format as defined in 362 [IEEE.754.1985]). When it indicates a time value (i.e. 363 Latency or Latency Variation) it is expressed in 364 milliseconds. 366 2.3. Processing rules 368 2.3.1. Processing Rules for the OF Subobjects 370 A single OF subobjects SHOULD be used between a pair of abstract 371 nodes in ERO. Same OF SHOULD be identified for each hop 372 expansion. 374 The basic processing rules of an ERO are not altered. Please 375 refer to [RFC3209] for details. 377 The scope of the OF subobject is the previous ERO subobject that 378 identifies an abstract node, and the subsequent ERO subobject 379 that identifies an abstract node. Multiple OF subobjects MAY be 380 present between any pair of abstract nodes. However, only first 381 OF subobject is analyzed and others are ignored. 383 The following conditions SHOULD result in Path Error with error 384 code "Routing Problem" and error subcode "Bad EXPLICIT_ROUTE 385 object": 387 ID draft-ali-ccamp-rc-objective-function-metric-bound-05.txt 389 . If the first OF subobject is not preceded by an ERO subobject 390 identifying the next hop. 391 . If the OF subobject follows an ERO subobject identifying the 392 next hop that does not have the L-bit set. 394 If the processing node does not understand the OF subobject, it 395 SHOULD send a PathErr with the error code "Routing Error" and 396 error value of "Bad Explicit Route Object" toward the sender 397 [RFC3209]. 399 If the processing node understands the OF subobject and the ERO 400 passes the above mentioned sanity check and any other sanity 401 checks associated with other ERO subobjects local to the node, 402 the node takes the following actions: 404 . If the node supports the requested OF, the node expands the 405 loose hop using the requested OF as optimization criterion for 406 computing the route to the next abstract node. After 407 processing, the OF subobjects are removed from the ERO. The 408 rest of the steps for the loose ERO processing follow 409 procedures outlined in [RFC3209]. 410 . If the node understands the OF subobject but does not support 411 the requested OF, it SHOULD send a Path Error with error code 412 "Routing Problem" and a new error subcode "Unsupported 413 Objective Function". The error subcode "Unsupported Objective 414 Function" for Path Error code "Routing Problem" is to be 415 assigned by IANA. 416 . If the OF is supported but policy does not permit applying 417 it, the processing node SHOULD send a Path Error with error 418 code "Policy control failure" (value 2) and subcode "objective 419 function not allowed". The error subcode "objective function 420 not allowed" for Path Error code "Policy control failure" is 421 to be assigned by IANA. 422 2.3.2. Processing Rules for the MB subobject 424 Multiple Metric Bound subobjects MAY be indicated for each hop 425 to be expanded and MUST be placed after each abstract node 426 subobject. Different Metric Bounds MAY be identified for each 427 hop expansion. 429 ID draft-ali-ccamp-rc-objective-function-metric-bound-05.txt 431 The basic processing rules of an ERO are not altered. Please 432 refer to [RFC3209] for details. 434 The scope of the MB subobject is between the previous ERO 435 subobject that identifies an abstract node, and the subsequent 436 ERO subobject that identifies an abstract node. Multiple MB 437 subobjects may be present between any pair of abstract nodes. 439 If the processing node does not understand the MB subobject, it 440 SHOULD send a PathErr with the error code "Routing Error" and 441 error value of "Bad Explicit Route Object" toward the sender 442 [RFC3209]. 444 If the processing node understands the MB subobject and the ERO 445 passes the above mentioned sanity check and any other sanity 446 checks associated with other ERO subobjects local to the node, 447 the node takes the following actions: 449 . For all the MB subobject(s), the node expands the ERO such 450 that the requested metric bound(s) are met for the route 451 between the two abstract nodes in the ERO. After processing, 452 the Metric subobjects are removed from the ERO. The rest of 453 the steps for the ERO processing follow procedure outlined in 454 [RFC3209]. 455 . If the node understands the MB subobject but cannot find a 456 route to the next abstract node such that the requested metric 457 bound(s) can be satisfied and the best-effort (B) bit is not 458 set, it SHOULD send a Path Error with error code "Routing 459 Problem" and a new error subcode "No route available toward 460 destination with the requested metric bounds". The error 461 subcode "No route available toward destination with the 462 requested metric bounds" for Path Error code "Routing Problem" 463 is to be assigned by IANA (See IANA section for details). 464 . If the node understands the Metric subobject but cannot find 465 a route to the next abstract node such that the requested 466 metric bound(s) can be satisfied and the best-effort (B) bit 467 is set, it SHOULD send a Path Error message with error code 468 "Notify Error" and a new error subcode "Route not matching the 469 requested metric bounds" is to be assigned by IANA (See IANA 470 section for details). 472 ID draft-ali-ccamp-rc-objective-function-metric-bound-05.txt 474 . The ERO expanding node SHOULD respect the Metric Bound 475 constraints in realizing any segment recovery procedure to 476 change the route of the segment expanded by the said node. If 477 best-effort (B) bit is set and the new recovery segment 478 violates the Metric Bound constraints, the ERO expanding 479 SHOULD send a Path Error message with error code "Notify 480 Error" and a new error subcode "Route not matching the 481 requested metric bounds" is to be assigned by IANA (See IANA 482 section for details). 484 3. Security Considerations 486 This document does not introduce any additional security issues 487 above those identified in [RFC5920], [RFC2205], [RFC3209], and 488 [RFC3473]. 490 4. IANA Considerations 492 4.1. ERO Subobject 494 This document adds the following two new subobject of the 495 existing entry for ERO (20, EXPLICIT_ROUTE): 497 Value Description 499 ----- ------------ 501 TBA (suggest value: 66) Objective Function (OF) subobject 503 TBA (suggest value: 67) Metric subobject 505 These subobject may be present in the Explicit Route Object, but 506 not in the Route Record Object. 508 OF Code values carried in OF subobject requires an IANA entry 509 with suggested values as defined in section 2.1. 511 4.2. New RSVP error sub-code 513 For Error Code = 24 "Routing Problem" (see [RFC2205]) the 514 following sub-code is defined. 516 Sub-code Value 517 -------- ----- 519 No route available toward destination To be assigned by IANA. 521 ID draft-ali-ccamp-rc-objective-function-metric-bound-05.txt 523 with the requested metric bounds Suggested Value: TBA. 525 For Error Code = 25 "Notify Error" (see [RFC2205]) the following 526 sub-code is defined. 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, and Walid Wakim for their review comments. 539 6. References 541 6.1. Normative References 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, March 1997. 546 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 547 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 548 LSP Tunnels", RFC 3209, December 2001. 550 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 551 Switching (GMPLS) Signaling Resource ReserVation 552 Protocol-Traffic Engineering (RSVP-TE) Extensions", 553 RFC 3473, January 2003. 555 [IEEE.754.1985] IEEE Standard 754, "Standard for Binary 556 Floating-Point Arithmetic", August 1985. 558 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 559 "Generalized Multiprotocol Label Switching (GMPLS) 560 User-Network Interface (UNI): Resource ReserVation 561 Protocol-Traffic Engineering (RSVP-TE) Support for the 562 Overlay Model", RFC 4208, October 2005. 564 ID draft-ali-ccamp-rc-objective-function-metric-bound-05.txt 566 6.2. Informative References 568 [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation 569 Protocol (RSVP) -- Version 1 Message Processing 570 Rules", RFC 2209, September 1997. 572 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 573 Networks", RFC 5920, July 2010. 575 [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 576 Computation Element (PCE) Communication Protocol 577 (PCEP)", RFC 5440, March 2009. 579 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 580 Objective Functions in the Path Computation Element 581 Communication Protocol (PCEP)", RFC 5541, June 2009. 583 [ID-SERVICE-AWARE] D. Dhody, V. Manral, Z. Ali, G. Swallow, K. 584 Kumaki, " Extensions to the Path Computation Element 585 Communication Protocol (PCEP) to compute service aware 586 Label Switched Path (LSP)", draft-ietf-pce-pcep- 587 service-aware, work in progress. 589 [OSPF-TE-METRIC] S. Giacalone, D. Ward, J. Drake, A. Atlas, S. 590 Previdi, "OSPF Traffic Engineering (TE) Metric 591 Extensions", draft-ietf-ospf-te-metric-extensions, 592 work in progress. 594 [ISIS-TE-METRIC] S. Previdi, S. Giacalone, D. Ward, J. Drake, A. 595 Atlas, C. Filsfils, "IS-IS Traffic Engineering (TE) 596 Metric Extensions", draft-previdi-isis-te-metric- 597 extensions, work in progress. 599 Authors' Addresses 601 Zafar Ali 602 Cisco Systems. 603 Email: zali@cisco.com 605 George Swallow 606 Cisco Systems. 607 swallow@cisco.com 609 Clarence Filsfils 611 ID draft-ali-ccamp-rc-objective-function-metric-bound-05.txt 613 Cisco Systems. 614 cfilsfil@cisco.com 616 Luyuan Fang 617 Microsoft 618 lufang@microsoft.com 620 Kenji Kumaki 621 KDDI Corporation 622 Email: ke-kumaki@kddi.com 624 Rudiger Kunze 625 Deutsche Telekom AG 626 Ruediger.Kunze@telekom.de 628 Daniele Ceccarelli 629 Ericsson 630 Email: daniele.ceccarelli@ericsson.com 632 Xian Zhang 633 Huawei Technologies 634 Email: zhang.xian@huawei.com