idnits 2.17.1 draft-ali-ccamp-te-metric-recording-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 12 longer pages, the longest (page 2) being 61 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 (October 22, 2012) is 4196 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 494, but not defined == Missing Reference: 'RFC3473' is mentioned on line 443, but not defined == Unused Reference: 'RFC2209' is defined on line 557, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). 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 21, 2013 Matt Hartley 6 Cisco Systems 7 Kenji Kumaki 8 KDDI Corporation 9 Ruediger Kunze 10 Deutsche Telekom AG 12 October 22, 2012 14 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) 15 extension for recording TE Metric of a Label Switched Path 16 draft-ali-ccamp-te-metric-recording-03.txt 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet-Drafts 31 as reference material or to cite them other than as "work in 32 progress." 34 This Internet-Draft will expire on April 21, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described in 48 Internet-Draft draft-ali-ccamp-te-metric-recording-03.txt 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) 59 controlling the copyright in such materials, this document may not 60 be modified outside the IETF Standards Process, and derivative 61 works of it may not be created outside the IETF Standards Process, 62 except to format it for publication as an RFC or to translate it 63 into languages other than English. 65 Abstract 67 There are many scenarios in which Traffic Engineering (TE) metrics 68 such as cost, latency and latency variation associated with a 69 Forwarding Adjacency (FA) or Routing Adjacency (RA) Label Switched 70 Path (LSP) are not available to the ingress and egress nodes. This 71 draft provides extensions for the Resource ReserVation Protocol- 72 Traffic Engineering (RSVP-TE) for the support of the discovery of 73 cost, latency and latency variation of an LSP. 75 Conventions used in this document 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 79 this document are to be interpreted as described in RFC 2119 80 [RFC2119]. 82 Table of Contents 84 Copyright Notice...............................................1 85 1. Introduction................................................3 86 2. RSVP-TE Requirement.........................................3 87 2.1. Cost, Latency and Latency Variation Collection Indication....4 88 2.2. Cost, Latency and Latency Variation Collection...............4 89 2.3. Cost, Latency and Latency Variation Update...................4 90 3. RSVP-TE signaling extensions................................4 91 3.1. Cost Collection Flag.........................................4 92 3.2. Latency Collection Flag......................................5 93 3.3. Latency Variation Collection Flag............................5 94 3.4. Cost subobject...............................................5 95 3.5. Latency subobject............................................6 96 3.6. Latency Variation subobject..................................7 97 3.7. Signaling Procedures.........................................7 98 4. Security Considerations.....................................9 99 Internet-Draft draft-ali-ccamp-te-metric-recording-03.txt 101 5. IANA Considerations.........................................9 102 5.1. RSVP Attribute Bit Flags.....................................9 103 5.2. New RSVP error sub-code.....................................10 104 6. Acknowledgments............................................10 105 7. References.................................................11 106 7.1. Normative References........................................11 107 7.2. Informative References......................................11 109 1. Introduction 111 There are many scenarios in packet and optical networks where 112 the route information of an LSP may not be provided to the 113 ingress node for confidentiality reasons and/ or the ingress 114 node may not run the same routing instance as the intermediate 115 nodes traversed by the path. In such scenarios, the ingress node 116 cannot determine the cost, latency and latency variation 117 properties of the LSP's route. Similarly, in Generalized Multi- 118 Protocol Label Switching (GMPLS) networks signaling 119 bidirectional LSP, the egress node cannot determine the cost, 120 latency and latency variation properties of the LSP route. A 121 multi-domain or multi-layer network is an example of such 122 networks. Similarly, a GMPLS User-Network Interface (UNI) 123 [RFC4208] is also an example of such networks. 125 In certain networks, such as financial information networks, 126 network performance information (e.g. latency, latency 127 variation) is becoming as critical to data path selection as 128 other metrics [DRAFT-OSPF-TE-METRIC], [DRAFT-ISIS-TE-METRIC]. If 129 cost, latency or latency variation associated with an FA or an 130 RA LSP is not available to the ingress or egress node, it cannot 131 be advertised as an attribute of the FA or RA. One possible way 132 to address this issue is to configure cost, latency and latency 133 variation values manually. However, in the event of an LSP being 134 rerouted (e.g. due to re-optimization), such configuration 135 information may become invalid. Consequently, in case where that 136 an LSP is advertised as a TE-Link, the ingress and/ or egress 137 nodes cannot provide the correct latency, latency variation and 138 cost attribute associated with the TE-Link automatically. 140 In summary, there is a requirement for the ingress and egress 141 nodes to learn the cost, latency and latency variation 142 attributes of an FA or RA LSP. This draft provides extensions to 143 the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) 144 for the support of the automatic discovery of these attributes. 146 2. RSVP-TE Requirement 148 This section outlines RSVP-TE requirements for the support of 149 the automatic discovery of cost, latency and latency variation 150 attributes of an LSP. These requirements are very similar to the 151 requirement of discovering the Shared Risk Link Groups (SRLGs) 152 Internet-Draft draft-ali-ccamp-te-metric-recording-03.txt 154 associated with the route taken by an LSP [DRAFT-SRLG- 155 RECORDING]. 157 2.1. Cost, Latency and Latency Variation Collection Indication 159 The ingress and egress nodes of the LSP must be capable of 160 indicating whether the cost, latency and latency variation 161 attributes of the LSP should be collected during the signaling 162 procedure of setting up the LSP. No cost, latency or latency 163 variation information is collected without an explicit request 164 being made by the ingress node. 166 2.2. Cost, Latency and Latency Variation Collection 168 If requested, cost, latency and latency variation is 169 collected during the setup of an LSP. The endpoints of the LSP 170 may use the collected information and use it for routing, 171 flooding and TE link configuration purposes. 173 2.3. Cost, Latency and Latency Variation Update 175 When the cost, latency and latency variation property of a TE 176 link along the route of a LSP for which that property was 177 collected changes, e.g., if the administrator changes cost of a 178 TE link, the node where the change occurred needs to be capable 179 of updating the cost, latency and latency variation information 180 of the path and signaling this to the end-points. Similarly, if 181 a path segment of the LSP is rerouted, the endpoints of the re- 182 routed segment need to be capable of updating the cost, latency 183 and latency variation information of the path. Any node which 184 adds cost, latency or latency variation information to an LSP 185 during initial setup must signal changes to these values to both 186 endpoints. 188 3. RSVP-TE signaling extensions 190 3.1. Cost Collection Flag 192 In order to indicate that cost collection is desired, a new 193 flag in the Attribute Flags TLV which can be carried in an 194 LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES Objects is required: 196 Cost Collection flag (to be assigned by IANA, recommended bit 197 position 11) 199 The Cost Collection flag is meaningful in a Path message. If 200 the Cost Collection flag is set to 1, the transit nodes SHOULD 201 report the cost information in the Path Record Route Object 202 (RRO) and the Resv RRO. 204 The procedure for processing the Attribute Flags TLV follows 205 [RFC5420]. 207 Internet-Draft draft-ali-ccamp-te-metric-recording-03.txt 209 3.2. Latency Collection Flag 211 In order to indicate that latency collection is desired, a 212 new flag in the Attribute Flags TLV which can be carried in an 213 LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES Object is required: 215 Latency Collection flag (to be assigned by IANA, recommended bit 216 position 12) 218 The Latency Collection flag is meaningful on a Path message. 219 If the Latency Collection flag is set to 1, the transit nodes 220 SHOULD report the latency information in the Path RRO and the 221 Resv RRO. 223 The procedure for the processing the Attribute Flags TLV follows 224 [RFC5420]. 226 3.3. Latency Variation Collection Flag 228 In order to indicate that latency variation collection is 229 desired, a new flag in the Attribute Flags TLV which can be 230 carried in an LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES Object 231 is required: 233 Latency Variation Collection flag (to be assigned by IANA, 234 recommended bit position 13) 236 The Latency Variation Collection flag is meaningful on a Path 237 message. If the Latency Variation Collection flag is set to 1, 238 the transit nodes SHOULD report the latency variation 239 information in the Path RRO and the Resv RRO. 241 The procedure for the processing the Attribute Flags TLV follows 242 [RFC5420]. 244 3.4. Cost subobject 246 A new cost subobject is defined for the RRO to record the 247 cost information of the LSP. Its format is similar to the RRO 248 subobjects defined in [RFC3209]. 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Type | Length | Reserved (must be zero) | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | COST Value | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Type: The type of the subobject, to be assigned by IANA 259 (recommended value 35). 261 Internet-Draft draft-ali-ccamp-te-metric-recording-03.txt 263 Length: The Length value is set to 8. 265 Reserved: This field is reserved for future use. It MUST be 266 set to 0 when sent and MUST be ignored when received. 268 Cost Value: Cost of the link along the route of the LSP. 269 Based on the policy at the recording node, the cost value can 270 be set to the Interior Gateway Protocol (IGP) metric or TE 271 metric of the link in question. This approach has been taken 272 to avoid defining a flag for each cost type in the Attribute- 273 Flags TLV. It is assumed that, based on policy, all nodes 274 reports the same cost-type and that the ingress and egress 275 nodes know the cost type reported in the RRO. 277 The rules for processing the LSP_ATTRIBUTES and 278 LSP_REQUIRED_ATTRIBUTES Objects and RRO are not changed. 280 3.5. Latency subobject 282 A new Latency subobject is defined for RRO to record the latency 283 information of the LSP. Its format is similar the RRO subobjects 284 defined in [RFC3209]. 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Type | Length | Reserved (must be zero) | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 |A| Reserved | Delay | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Type: The type of the subobject, to be assigned by IANA 295 (recommended value 36). 297 Length: The Length value is set to 8. 299 A-bit: This field represents the Anomalous (A) bit, as 300 defined in [DRAFT-OSPF-TE-METRIC]. 302 Reserved: These fields are reserved for future use. They MUST 303 be set to 0 when sent and MUST be ignored when received. 305 Delay Value: This 24-bit field carries the average link delay 306 over a configurable interval in micro-seconds, encoded as an 307 integer value. When set to 0, it has not been measured. When 308 set to the maximum value 16,777,215 (16.777215 sec), then the 309 delay is at least that value and may be larger. 311 Internet-Draft draft-ali-ccamp-te-metric-recording-03.txt 313 The rules for processing the LSP_ATTRIBUTES and 314 LSP_REQUIRED_ATTRIBUTES Objects and RRO are not changed. 316 3.6. Latency Variation subobject 318 A new Latency Variation subobject is defined for RRO to 319 record the Latency Variation information of the LSP. Its format 320 is similar to the RRO subobjects defined in [RFC3209]. 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Type | Length | Reserved (must be zero) | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 |A| Reserved | Delay Variation | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Type: The type of the subobject, to be assigned by IANA 331 (recommended value 37). 333 Length: The Length value is set to 8. 335 A-bit: This field represents the Anomalous (A) bit, as 336 defined in [DRAFT-OSPF-TE-METRIC]. 338 Reserved: These fields are reserved for future use. It MUST 339 be set to 0 when sent and MUST be ignored when received. 341 Delay Variation Value: This 24-bit field carries the average 342 link delay variation over a configurable interval in micro- 343 seconds, encoded as an integer value. When set to 0, it has 344 not been measured. When set to the maximum value 16,777,215 345 (16.777215 sec), then the delay is at least that value and 346 may be larger. 348 The rules for processing the LSP_ATTRIBUTES and 349 LSP_REQUIRED_ATTRIBUTES Objects and RRO are not changed. 351 3.7. Signaling Procedures 353 Typically, the ingress node learns the route of an LSP by 354 adding a RRO in the Path message. If an ingress node also 355 desires cost, latency and/or latency variation recording, it 356 sets the appropriate flag(s) in the Attribute Flags TLV of the 357 LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES Object. None, all or 358 any of the Cost Collection, Latency Collection or Latency 359 Variation Collection flags may be set in the Attribute Flags TLV 360 of the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES Object. 362 When a node receives a Path message which carries an 363 LSP_REQUIRED_ATTRIBUTES Object and the Cost, Latency and/or 364 Internet-Draft draft-ali-ccamp-te-metric-recording-03.txt 366 Latency Variation Collection Flag(s) is (are) set, if local 367 policy disallows providing the requested information to the 368 endpoints, the node MUST return a Path Error message with error 369 code "Policy Control Failure (2)" and one of the following error 370 subcodes: 372 . "Cost Recoding Rejected" (value to be assigned by IANA, 373 suggest value 105) if Cost Collection Flag is set. 375 . "Latency Recording Rejected" (value to be assigned by IANA, 376 suggest value 106) if Latency Collection Flag is set. 378 . "Latency Variation Recording Rejected" (value to be assigned 379 by IANA, suggest value 107) if Latency Variation Collection 380 Flag is set. 382 When a node receives a Path message which carries an 383 LSP_ATTRIBUTES Object and the Cost, Latency and/or Latency 384 Variation Collection Flag(s) is (are) set, if local policy 385 disallows providing the requested information to the endpoints, 386 the node MAY return a Path Error as described for the 387 LSP_REQUIRED_ATTRIBUTES Object. 389 If local policy permits the provision of the requested 390 information, the processing node SHOULD add the requested 391 subobject(s) with the cost, latency or/ and latency variation 392 metric value(s) associated with the local hop to the Path RRO. 393 It then forwards the Path message to the next node in the 394 downstream direction. 396 Following the steps described above, the intermediate nodes 397 of the LSP provide the requested metric value(s) associated with 398 the local hop in the Path RRO. When the Path message is received 399 by the egress node, the egress node can calculate the end-to-end 400 cost, latency and/or latency variation properties of the LSP. 402 Before the Resv message is sent to the upstream node, the 403 egress node adds the requested subobject(s) with the cost, 404 latency or/ and latency variation metric value(s) associated 405 with the local hop to the Resv RRO in a similar manner to that 406 specified above for the addition of Path RRO sub-objects by 407 midpoint nodes. 409 Similarly, the intermediate nodes of the LSP provide the 410 requested metric value(s) associated with the local hop in the 411 Resv RRO. When the Resv message is received by the ingress node, 412 it can calculate the end-to-end cost, latency or/ and latency 413 variation properties of the LSP. 415 Typically, cost and latency are additive metrics, but latency 416 variation is not an additive metric. The means by which the 417 ingress and egress nodes compute the end-to-end cost, latency 418 Internet-Draft draft-ali-ccamp-te-metric-recording-03.txt 420 and latency variation metric from information recorded in the 421 RRO is beyond the scope of this document. 423 Based on the local policy, the ingress and egress nodes can 424 advertise the calculated end-to-end cost, latency and/or latency 425 variation properties of the FA/ RA LSP in TE link advertisement 426 to the routing instance based on the procedure described in 427 [DRAFT-OSPF-TE-METRIC], [DRAFT-ISIS-TE-METRIC]. 429 Based on the local policy, a transit node (e.g. the edge node of 430 a domain) may edit a Path or Resv RRO to remove route 431 information (e.g. node or interface identifier information) 432 before forwarding it. A node that does this SHOULD summarize the 433 cost, latency and latency variation data removed as a single 434 value for each for the loose hop that is summarized by the 435 transit node. How a transit node calculates the cost, latency 436 or/ and latency variation metric for the segment summarized by 437 the transit node is beyond the scope of this document. 439 4. Security Considerations 441 This document does not introduce any additional security issues 442 above those identified in [RFC5920], [RFC5420], [RFC2205], 443 [RFC3209], and [RFC3473]. 445 5. IANA Considerations 447 5.1. RSVP Attribute Bit Flags 449 The IANA has created a registry and manages the space of 450 attributes bit flags of Attribute Flags TLV as described in 451 section 11.3 of [RFC5420]. It is requested that the IANA makes 452 assignments from the Attribute Bit Flags defined in this 453 document. 455 This document introduces the following three new Attribute 456 Bit Flag: 458 - Bit number: TBD (recommended bit position 11) 460 - Defining RFC: this I-D 462 - Name of bit: Cost Collection Flag 464 - Bit number: TBD (recommended bit position 12) 466 - Defining RFC: this I-D 468 - Name of bit: Latency Collection Flag 469 Internet-Draft draft-ali-ccamp-te-metric-recording-03.txt 471 - Bit number: TBD (recommended bit position 13) 473 - Defining RFC: this I-D 475 - Name of bit: Latency Variation Flag 477 5.2. ROUTE_RECORD subobject 479 This document introduces the following three new RRO 480 subobject: 482 Type Name Reference 484 --------- ---------------------- --------- 486 TBD (35) Cost subobject This I-D 488 TBD (36) Latency subobject This I-D 490 TBD (37) Latency Variation subobject This I-D 492 5.2. New RSVP error sub-code 494 For Error Code = 2 "Policy Control Failure" (see [RFC2205]) the 495 following sub-code is defined. 497 Sub-code Value 498 -------- ----- 500 Cost Recoding Rejected To be assigned by IANA. 501 Suggested Value: 105. 503 Latency Recoding Rejected To be assigned by IANA. 504 Suggested Value: 106. 506 Latency Variation Recoding Rejected To be assigned by IANA. 507 Suggested Value: 107. 509 6. Acknowledgments 511 Authors would like to thank Ori Gerstel, Gabriele Maria 512 Galimberti, Luyuan Fang and Walid Wakim for their review 513 comments. 515 Internet-Draft draft-ali-ccamp-te-metric-recording-03.txt 517 7. References 519 7.1. Normative References 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, March 1997. 524 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 525 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 526 LSP Tunnels", RFC 3209, December 2001. 528 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and 529 A. Ayyangarps, "Encoding of Attributes for MPLS LSP 530 Establishment Using Resource Reservation Protocol 531 Traffic Engineering (RSVP-TE)", RFC 5420, February 532 2009. 534 [DRAFT-OSPF-TE-METRIC] S. Giacalone, D. Ward, J. Drake, A. 535 Atlas, S. Previdi, "OSPF Traffic Engineering (TE) 536 Metric Extensions", draft-ietf-ospf-te-metric- 537 extensions, work in progress. 539 [DRAFT-ISIS-TE-METRIC] S. Previdi, S. Giacalone, D. Ward, J. 540 Drake, A. Atlas, C. Filsfils, "IS-IS Traffic 541 Engineering (TE) Metric Extensions", draft-previdi- 542 isis-te-metric-extensions, work in progress. 544 [DRAFT-SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C. 545 Margaria,, "RSVP-TE Extensions for Collecting SRLG 546 Information", draft-ietf-ccamp-rsvp-te-srlg- 547 collect.txt, work in progress. 549 7.2. Informative References 551 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 552 "Generalized Multiprotocol Label Switching (GMPLS) 553 User-Network Interface (UNI): Resource ReserVation 554 Protocol-Traffic Engineering (RSVP-TE) Support for the 555 Overlay Model", RFC 4208, October 2005. 557 [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation 558 Protocol (RSVP) -- Version 1 Message Processing 559 Rules", RFC 2209, September 1997. 561 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 562 Networks", RFC 5920, July 2010. 564 Authors' Addresses 565 Internet-Draft draft-ali-ccamp-te-metric-recording-03.txt 567 Zafar Ali 568 Cisco Systems, Inc. 569 Email: zali@cisco.com 571 George Swallow 572 Cisco Systems, Inc. 573 swallow@cisco.com 575 Clarence Filsfils 576 Cisco Systems, Inc. 577 cfilsfil@cisco.com 579 Matt Hartley 580 Cisco Systems 581 Email: mhartley@cisco.com 583 Kenji Kumaki 584 KDDI Corporation 585 Email: ke-kumaki@kddi.com 587 Rudiger Kunze 588 Deutsche Telekom AG 589 Ruediger.Kunze@telekom.de