idnits 2.17.1 draft-ali-ccamp-rc-objective-function-metric-bound-03.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 9 longer pages, the longest (page 1) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 23 instances of too long lines in the document, the longest one being 5 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 (July 15, 2013) is 3910 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: 'OSPF-TE-METRIC' is mentioned on line 122, but not defined == Missing Reference: 'ISIS-TE-METRIC' is mentioned on line 122, but not defined == Missing Reference: 'RFC 4208' is mentioned on line 142, but not defined == Missing Reference: 'RFC5541' is mentioned on line 252, but not defined == Missing Reference: 'RFC5440' is mentioned on line 159, but not defined == Missing Reference: 'RFC2205' is mentioned on line 526, but not defined == Unused Reference: 'RFC2209' is defined on line 562, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754.1985' Summary: 1 error (**), 0 flaws (~~), 10 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: January 14, 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 July 15, 2013 15 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) 16 extension for signaling Objective Function and Metric Bound 17 draft-ali-ccamp-rc-objective-function-metric-bound-03.txt 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current 27 Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet-Drafts 32 as reference material or to cite them other than as "work in 33 progress." 35 This Internet-Draft will expire on January 14, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. Code Components extracted from this 48 ID draft-ali-ccamp-rc-objective-function-metric-bound-03.txt 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 Abstract 68 In particular networks such as those used by financial 69 institutions, network performance criteria such as latency are 70 becoming as critical to data path selection. However cost is still 71 an important consideration. This leads to a situation where path 72 calculation involves multiple metrics and more complex objective 73 functions. 75 When using GMPLS control plane, there are many scenarios in which a 76 node may need to request a remote node to perform path computation 77 or expansion, like for example multi-domain LSP setup, Generalized 78 Multi-Protocol Label Switching (GMPLS) User-Network Interface (UNI) 79 or simply the utilization of a loose ERO in intra domain signaling. 80 In such cases, the node requesting for the setup of an LSP needs to 81 convey the required objective function to the remote node, to 82 enable it to perform route computation in the desired fashion. 83 Similarly, there are cases the ingress needs to indicate a TE 84 metric bound for a loose segment that is expanded by a remote node. 86 This document defines extensions to the RSVP-TE Protocol to allow 87 an ingress node to request the required objective function for the 88 route computation, as well as a metric bound to influence route 89 computation decisions at a remote node(s). 91 Conventions used in this document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 95 this document are to be interpreted as described in RFC 2119 96 [RFC2119]. 98 ID draft-ali-ccamp-rc-objective-function-metric-bound-03.txt 100 Table of Contents 102 Copyright Notice.....................................................1 103 1. Introduction......................................................3 104 2. RSVP-TE signaling extensions......................................4 105 2.1. Objective Function (OF) Subobject.........................4 106 2.1.1. Minimum TE Metric Cost Path Objective Function.......6 107 2.1.2. Minimum IGP Metric Cost Path Objective Function......6 108 2.1.3. Minimum Latency Path Objective Function..............6 109 2.1.4. Minimum Latency Variation Path Objective Function....7 110 2.2. Metric subobject..........................................7 111 2.3. Processing Rules for the OF Subobjects....................8 112 2.4. Processing Rules for the Metric subobject.................9 113 3. Security Considerations..........................................11 114 4. IANA Considerations..............................................11 115 5. Acknowledgments..................................................12 116 6. References.......................................................12 117 6.1. Normative References.....................................12 118 6.2. Informative References...................................12 120 1. Introduction 122 As noted in [OSPF-TE-METRIC] and [ISIS-TE-METRIC], in certain 123 networks such as financial information networks (e.g. stock 124 market data providers), performance criteria such as latency are 125 becoming as critical to data path selection along with other 126 metrics. Such networks may require selection of a path that 127 minimizes end-to-end latency. Or a path may need to be found 128 that minimizes some other TE metric, but subject a latency 129 bound. Thus there is a requirement to be able to find end-to-end 130 paths with different optimization criteria. 132 When the entire route for an LSP is computed at the ingress 133 node, this requirement can be met by a local decision at that 134 node. However, there are scenarios where partial or full route 135 computations are performed by remote nodes. The scenarios 136 include (but are not limited to): 138 . LSPs with loose hops in the Explicit Route Object (ERO), 139 including intra-domain LSPs. 141 . GMPLS-UNI where route computation may be performed by the UNI- 142 Network (server) node [RFC 4208]; 144 . Multi domain LSP setup with per domain path computation; 146 ID draft-ali-ccamp-rc-objective-function-metric-bound-03.txt 148 In these scenarios, there is a need for the ingress node to 149 convey the optimization criteria including the TE metrics (e.g., 150 IGP metric, TE metric, hop counts, latency, etc.) to be used for 151 the path computation to the node performing route computation or 152 expansion. Similarly, there is a need for the ingress node to 153 indicate a TE metric bound for the loose segment being expanded 154 by a remote node. 156 [RFC5541] defines extensions to the Path Computation Element 157 communication Protocol (PCEP) to allow a Path Computation Client 158 (PCC) indicate in a path computation request the desired 159 objective function. [RFC5440] defines extension to the PCEP to 160 allow a PCC indicate in a path computation request a bound on 161 given TE metric(s). This draft defines similar mechanisms for 162 the RSVP-TE protocol allowing an ingress node to indicate in a 163 Path request the desired objective function along with any 164 associated TE metric bound(s). The nodes performing route 165 expansion use this information to find the ''best'' candidate 166 route. 168 2. RSVP-TE signaling extensions 170 This section defines RSVP-TE signaling extensions required to 171 address the above-mentioned requirements. Two new ERO subobject 172 types, Objective Function (OF) and Metric, are defined for this 173 purpose. Their purpose is as follows. 175 . OF subobject conveys a set of one or more specific 176 optimization criteria that needs be followed in expanding 177 route of a TE-LSP in MultiProtocol Label Switching (MPLS) and 178 GMPLS networks. 180 . Metric subobject indicates the bound on the path metric that 181 needs to be observed for the loose segment to be considered as 182 acceptable by the ingress node. 184 The scope of the Metric and OF subobjects is the node performing 185 the expansion for loose ERO and the subsequent ERO subobject 186 that identifies an abstract node. The following subsection 187 provides the details. 189 2.1. Objective Function (OF) Subobject 191 A new ERO subobject type Objective Function (OF) is defined in 192 order for the ingress node to indicate the required objective 193 function on a loose hop. The ERO subobject type OF is optional. 194 It MAY be carried within an ERO object of RSVP-TE Path message 195 and its scope is limited to previous ERO subobject that 197 ID draft-ali-ccamp-rc-objective-function-metric-bound-03.txt 199 identifies an abstract node. For more details please refer to 200 the Processing Rules for the OF Subobjects section. 202 The OF subobject has the following format: 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 |L| Type | Length | OF Code | Reserved | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 The fields of OF subobject are defined as follows: 212 L bit: The L bit MUST be set to represent a loose hop in the 213 explicit route. 215 Type: The Type is to be assigned by IANA (suggested value: 216 66). 218 Length: The Length contains the total length of the subobject 219 in bytes, including the Type field, the Length field and the 220 length of the optional TLV(s). When there is no optional TLV, 221 the Length 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 Interior 234 Gateway Protocol (IGP) Metric Cost Path (MIMCP) OF defined in the 235 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-03.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-03.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-03.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. General Processing rules 372 A single OF subobjects SHOULD be used for each ERO object. 373 Multiple Metric Bound subobjects MAY be indicated for each hop 374 to be expanded and MUST be placed after each abstract node 375 subobject. Different Metric Bounds MAY be identified for each 376 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-03.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 sends 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 it, 423 the processing node SHOULD send a Path Error with error code 424 "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-03.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 sends 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 a 466 route to the next abstract node such that the requested metric 467 bound(s) can be satisfied and the best-effort (B) bit is set, 468 it SHOULD send a Path Error message with error code "Notify 469 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-03.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) 503 subobject 505 TBA (suggest value: 67) Metric subobject 507 These subobject may be present in the Explicit Route Object, but 508 not in the Route Record Object. 510 OF Code values carried in OF subobject requires an IANA entry 511 with suggested values as defined in section 2.1. 513 4.2. New RSVP error sub-code 515 For Error Code = 24 ''Routing Problem" (see [RFC2205]) the 516 following sub-code is defined. 518 Sub-code Value 519 -------- ----- 521 No route available toward destination To be assigned by IANA. 522 with the requested metric bounds Suggested Value: TBA. 524 ID draft-ali-ccamp-rc-objective-function-metric-bound-03.txt 526 For Error Code = 25 ''Notify Error" (see [RFC2205]) the following 527 sub-code is defined. 529 Sub-code Value 530 -------- ----- 532 Route not matching the requested To be assigned by IANA. 533 metric bounds Suggested Value: TBA. 535 5. Acknowledgments 537 Authors would like to thank Matt Hartley, Ori Gerstel, Gabriele 538 Maria Galimberti, Luyuan Fang and Walid Wakim for their review 539 comments. 541 6. References 543 6.1. Normative References 545 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 546 Requirement Levels", BCP 14, RFC 2119, March 1997. 548 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 549 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 550 LSP Tunnels", RFC 3209, December 2001. 552 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 553 Switching (GMPLS) Signaling Resource ReserVation 554 Protocol-Traffic Engineering (RSVP-TE) Extensions", 555 RFC 3473, January 2003. 557 [IEEE.754.1985] IEEE Standard 754, "Standard for Binary 558 Floating-Point Arithmetic", August 1985. 560 6.2. Informative References 562 [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation 563 Protocol (RSVP) -- Version 1 Message Processing 564 Rules", RFC 2209, September 1997. 566 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 567 Networks", RFC 5920, July 2010. 569 Authors' Addresses 570 ID draft-ali-ccamp-rc-objective-function-metric-bound-03.txt 572 Zafar Ali 573 Cisco Systems. 574 Email: zali@cisco.com 576 George Swallow 577 Cisco Systems. 578 swallow@cisco.com 580 Clarence Filsfils 581 Cisco Systems. 582 cfilsfil@cisco.com 584 Luyuan Fang 585 Cisco Systems. 586 lufang@cisco.com 588 Kenji Kumaki 589 KDDI Corporation 590 Email: ke-kumaki@kddi.com 592 Rudiger Kunze 593 Deutsche Telekom AG 594 Ruediger.Kunze@telekom.de 596 Daniele Ceccarelli 597 Ericsson 598 Email: daniele.ceccarelli@ericsson.com