idnits 2.17.1 draft-ietf-ccamp-te-metric-recording-02.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 11 longer pages, the longest (page 3) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 4. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 5. IANA Considerations' ) ** There are 21 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC2205], [DRAFT-SRLG-RECORDING], [RFC4208], [RFC2119], [RFC2209], [RFC3473], [RFC5420], [RFC5920], [DRAFT-OSPF-TE-METRIC], [DRAFT-ISIS-TE-METRIC], [RFC3209]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 14, 2013) is 3933 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 section? 'RFC2119' on line 520 looks like a reference -- Missing reference section? 'RFC4208' on line 552 looks like a reference -- Missing reference section? 'DRAFT-OSPF-TE-METRIC' on line 533 looks like a reference -- Missing reference section? 'DRAFT-ISIS-TE-METRIC' on line 538 looks like a reference -- Missing reference section? 'DRAFT-SRLG-RECORDING' on line 543 looks like a reference -- Missing reference section? 'RFC5420' on line 527 looks like a reference -- Missing reference section? 'RFC3209' on line 523 looks like a reference -- Missing reference section? 'RFC5920' on line 562 looks like a reference -- Missing reference section? 'RFC2205' on line 493 looks like a reference -- Missing reference section? 'RFC3473' on line 441 looks like a reference -- Missing reference section? 'RFC2209' on line 558 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 12 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 13, 2014 Matt Hartley 6 Cisco Systems 8 Kenji Kumaki 9 KDDI Corporation 11 Ruediger Kunze 12 Deutsche Telekom AG 13 July 14, 2013 15 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) 16 extension for recording TE Metric of a Label Switched Path 17 draft-ietf-ccamp-te-metric-recording-02.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 Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 13, 2014. 36 Copyright Notice 38 Copyright (c) 2013 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 respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt 53 Abstract 55 There are many scenarios in which Traffic Engineering (TE) metrics 56 such as cost, latency and latency variation associated with a 57 Forwarding Adjacency (FA) or Routing Adjacency (RA) Label Switched 58 Path (LSP) are not available to the ingress and egress nodes. This 59 draft provides extensions for the Resource ReserVation Protocol- 60 Traffic Engineering (RSVP-TE) for the support of the discovery of 61 cost, latency and latency variation of an LSP. 63 Conventions used in this document 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 67 this document are to be interpreted as described in RFC 2119 68 [RFC2119]. 70 Table of Contents 72 Copyright Notice..................................................1 73 1. Introduction...................................................3 74 2. RSVP-TE Requirement............................................3 75 2.1. Cost, Latency and Latency Variation Collection Indication....4 76 2.2. Cost, Latency and Latency Variation Collection...............4 77 2.3. Cost, Latency and Latency Variation Update...................4 78 3. RSVP-TE signaling extensions...................................4 79 3.1. Cost, Latency and Latency Variation Collection Flags.........4 80 3.2. Cost Subobject...............................................5 81 3.3. Latency Subobject............................................6 82 3.4. Latency Variation Subobject..................................7 83 3.5. Signaling Procedures.........................................8 84 4. Security Considerations........................................9 85 5. IANA Considerations............................................9 86 5.1. RSVP Attribute Bit Flags.....................................9 87 Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt 89 5.2. New RSVP error sub-code.....................................10 90 6. Acknowledgments...............................................11 91 7. References....................................................11 92 7.1. Normative References........................................11 93 7.2. Informative References......................................12 95 1. Introduction 97 There are many scenarios in packet and optical networks where 98 the route information of an LSP may not be provided to the 99 ingress node for confidentiality reasons and/or the ingress node 100 may not run the same routing instance as the intermediate nodes 101 traversed by the path. In such scenarios, the ingress node 102 cannot determine the cost, latency and latency variation 103 properties of the LSP's route. Similarly, in Generalized Multi- 104 Protocol Label Switching (GMPLS) networks signaling 105 bidirectional LSP, the egress node cannot determine the cost, 106 latency and latency variation properties of the LSP route. A 107 multi-domain or multi-layer network is an example of such 108 networks. Similarly, a GMPLS User-Network Interface (UNI) 109 [RFC4208] is also an example of such networks. 111 In certain networks, such as financial information networks, 112 network performance information (e.g. latency, latency 113 variation) is becoming as critical to data path selection as 114 other metrics [DRAFT-OSPF-TE-METRIC], [DRAFT-ISIS-TE-METRIC]. If 115 cost, latency or latency variation associated with an FA or an 116 RA LSP is not available to the ingress or egress node, it cannot 117 be advertised as an attribute of the FA or RA. One possible way 118 to address this issue is to configure cost, latency and latency 119 variation values manually. However, in the event of an LSP being 120 rerouted (e.g. due to re-optimization), such configuration 121 information may become invalid. Consequently, in case where that 122 an LSP is advertised as a TE-Link, the ingress and/or egress 123 nodes cannot provide the correct latency, latency variation and 124 cost attribute associated with the TE-Link automatically. 126 In summary, there is a requirement for the ingress and egress 127 nodes to learn the cost, latency and latency variation 128 attributes of an FA or RA LSP. This draft provides extensions to 129 the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) 130 for the support of the automatic discovery of these attributes. 132 2. RSVP-TE Requirement 134 This section outlines RSVP-TE requirements for the support of 135 the automatic discovery of cost, latency and latency variation 136 attributes of an LSP. These requirements are very similar to the 137 requirement of discovering the Shared Risk Link Groups (SRLGs) 138 associated with the route taken by an LSP [DRAFT-SRLG- 139 RECORDING]. 141 Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt 143 2.1. Cost, Latency and Latency Variation Collection Indication 145 The ingress node of the LSP must be capable of indicating 146 whether the cost, latency and latency variation attributes of 147 the LSP should be collected during the signaling procedure of 148 setting up the LSP. No cost, latency or latency variation 149 information is collected without an explicit request being made 150 by the ingress node. 152 2.2. Cost, Latency and Latency Variation Collection 154 If requested, cost, latency and latency variation is 155 collected during the setup of an LSP. The endpoints of the LSP 156 may use the collected information for routing, flooding and TE 157 link configuration and other purposes. 159 2.3. Cost, Latency and Latency Variation Update 161 When the cost, latency and latency variation property of a TE 162 link along the route of a LSP for which that property was 163 collected changes, e.g., if the administrator changes cost of a 164 TE link, the node where the change occurred needs to be capable 165 of updating the cost, latency and latency variation information 166 of the path and signaling this to the end-points. Similarly, if 167 a path segment of the LSP is rerouted, the endpoints of the re- 168 routed segment need to be capable of updating the cost, latency 169 and latency variation information of the path. Any node, which 170 adds cost, latency or latency variation information to an LSP 171 during initial setup, needs to signal changes to these values to 172 both endpoints. 174 3. RSVP-TE signaling extensions 176 3.1. Cost, Latency and Latency Variation Collection Flags 178 Three Attribute flags are defined in the Attribute Flags TLV, 179 which can be set and carried in either the LSP_ATTRIBUTES or 180 LSP_REQUIRED_ATTRIBUTES Objects. 182 - Cost Collection flag (to be assigned by IANA) 184 - Latency Collection flag (to be assigned by IANA) 186 - Latency Variation Collection flag (to be assigned by IANA) 188 These flags are meaningful in a Path message. If the Cost 189 Collection flag is set to 1, the transit nodes SHOULD report the 190 cost information in the Record Route Objects (RRO) of both the 191 Path and Resv messages. 193 Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt 195 If the Cost Collection flag is set to 1, the transit nodes 196 SHOULD report latency variation information in the Record Route 197 Objects (RRO) of both the Path and Resv messages. 199 If the Latency Collection flag is set to 1, the transit nodes 200 SHOULD report latency variation information in the Record Route 201 Objects (RRO) of both the Path and Resv messages. 203 If the Latency Variation Collection flag is set to 1, the 204 transit nodes SHOULD report latency variation information in the 205 Record Route Objects (RRO) of both the Path and Resv messages. 207 The procedure for the processing the Attribute Flags TLV follows 208 [RFC5420]. 210 3.2. Cost Subobject 212 The cost subobject is defined for the RRO to record the cost 213 information of the LSP. Its format is similar to the RRO 214 subobjects (ROUTE_RECORD sub-object) defined in [RFC3209]. 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Type | Length | Reserved (must be zero) | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Downstream Cost | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Upstream Cost | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Type: TBA1 - Cost subobject (to be assigned by IANA). 228 Length: The Length value is set to 8 or 12 depending on the 229 presence of Upstream Cost information. 231 Reserved: This field is reserved for future use. It MUST be 232 set to 0 when sent and MUST be ignored when received. 234 Downstream Cost: Cost of the local link along the route of 235 the LSP in the direction of the tail-end node, encoded as a 236 32-bit integer. Based on the policy at the recording node, 237 the cost value can be set to the Interior Gateway Protocol 238 (IGP) metric or TE metric of the link in question. This 239 approach has been taken to avoid defining a flag for each 240 cost type in the Attribute-Flags TLV. It is assumed that, 241 based on policy, all nodes report the same cost-type and that 242 Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt 244 the ingress and egress nodes know the cost type reported in 245 the RRO. 247 Upstream Cost: Cost of the local link along the route of the 248 LSP in the direction of the head-end node, encoded as a 32- 249 bit integer. Based on the policy at the recording node, the 250 cost value can be set to the Interior Gateway Protocol (IGP) 251 metric or TE metric of the link in question. This approach 252 has been taken to avoid defining a flag for each cost type in 253 the Attribute-Flags TLV. It is assumed that, based on policy, 254 all nodes report the same cost-type and that the ingress and 255 egress nodes know the cost type reported in the RRO. 257 3.3. Latency Subobject 259 The Latency subobject is defined for RRO to record the latency 260 information of the LSP. Its format is similar the RRO subobjects 261 defined in [RFC3209]. 263 0 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Type | Length | Reserved (must be zero) | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 |A| Reserved | Downstream Delay | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 |A| Reserved | Upstream Delay | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Type: TBA2 - Latency subobject (to be assigned by IANA). 275 Length: 8 or 12 depending on the presence of Upstream Cost 276 information. 278 A-bit: These fields represent the Anomalous (A) bit 279 associated with the Downstream and Upstream Delay 280 respectively, as defined in [DRAFT-OSPF-TE-METRIC]. 282 Reserved: These fields are reserved for future use. They MUST 283 be set to 0 when sent and MUST be ignored when received. 285 Downstream Delay: Delay of the local link along the route of 286 the LSP in the direction of the tail-end node, encoded as 24- 287 bit integer. When set to 0, it has not been measured. When 288 set to the maximum value 16,777,215 (16.777215 sec), the 289 delay is at least that value and may be larger. 291 Upstream Delay: Delay of the local link along the route of 292 the LSP in the direction of the head-end node, encoded as 24- 293 Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt 295 bit integer. When set to 0, it has not been measured. When 296 set to the maximum value 16,777,215 (16.777215 sec), the 297 delay is at least that value and may be larger. 299 3.4. Latency Variation Subobject 301 The Latency Variation subobject is defined for RRO to record the 302 Latency Variation information of the LSP. Its format is similar 303 to the RRO subobjects defined in [RFC3209]. 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Type | Length | Reserved (must be zero) | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 |A| Reserved | Downstream Delay Variation | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 |A| Reserved | Upstream Delay Variation | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Type: TBA3 - Latency Variation subobject (to be assigned by 316 IANA). 318 Length: 8 or 12 depending on the presence of Upstream Latency 319 Variation information. 321 A-bit: These fields represent the Anomalous (A) bit 322 associated with the Downstream and Upstream Delay 323 respectively, as defined in [DRAFT-OSPF-TE-METRIC]. 325 Reserved: These fields are reserved for future use. It MUST 326 be set to 0 when sent and MUST be ignored when received. 328 Downstream Delay Variation: Delay Variation of the local link 329 along the route of the LSP in the direction of the tail-end 330 node, encoded as 24-bit integer. When set to 0, it has not 331 been measured. When set to the maximum value 16,777,215 332 (16.777215 sec), the delay is at least that value and may be 333 larger. 335 Upstream Delay Variation: Delay Variation of the local link 336 along the route of the LSP in the direction of the head-end 337 node, encoded as 24-bit integer. When set to 0, it has not 338 been measured. When set to the maximum value 16,777,215 339 (16.777215 sec), the delay is at least that value and may be 340 larger. 342 Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt 344 3.5. Signaling Procedures 346 Typically, the ingress node learns the route of an LSP by adding 347 a RRO in the Path message. If an ingress node also desires cost, 348 latency and/or latency variation recording, it sets the 349 appropriate flag(s) in the Attribute Flags TLV of the 350 LSP_ATTRIBUTES (if recording is desired but not mandatory) or 351 LSP_REQUIRED_ATTRIBUTES (if recording in mandatory) Object. 352 None, all or any of the Cost Collection, Latency Collection or 353 Latency Variation Collection flags may be set in the Attribute 354 Flags TLV of the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES 355 Object. The rules for processing the LSP_ATTRIBUTES and 356 LSP_REQUIRED_ATTRIBUTES Objects and RRO are not changed. The 357 corresponding sub-objects MUST be included in the RRO, with the 358 Downstream (only) information filled in. 360 When a node receives a Path message which carries an 361 LSP_REQUIRED_ATTRIBUTES Object and the Cost, Latency and/or 362 Latency Variation Collection Flag(s) is (are) set, if local 363 policy disallows providing the requested information to the 364 endpoints, the node MUST return a Path Error message with error 365 code "Policy Control Failure (2)" and one of the following error 366 subcodes: 368 . "Cost Recoding Rejected" (value to be assigned by IANA, 369 suggested value 105) if Cost Collection Flag is set. 371 . "Latency Recording Rejected" (value to be assigned by IANA, 372 suggested value 106) if Latency Collection Flag is set. 374 . "Latency Variation Recording Rejected" (value to be assigned 375 by IANA, suggested value 107) if Latency Variation Collection 376 Flag is set. 378 When a node receives a Path message which carries an 379 LSP_ATTRIBUTES Object and the Cost, Latency and/or Latency 380 Variation Collection Flag(s) is (are) set, if local policy 381 disallows providing the requested information to the endpoints, 382 the Path message SHOULD NOT rejected due to Metric recording 383 restriction and the Path message is forwarded without the 384 appropriate sub-object(s) in the Path RRO. 386 If local policy permits the recording of the requested 387 information, the processing node SHOULD add the requested 388 subobject(s) with the cost, latency and/or latency variation 389 metric value(s) associated with the local hop to the Path RRO. 390 If the LSP being setup is bidirectional, both Downstream and 391 Upstream information SHOULD be included. If the LSP is 392 unidirectional, only Downstream information SHOULD be included. 394 Following the steps described above, the intermediate nodes of 395 the LSP provide the requested metric value(s) associated with 396 Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt 398 the local hop in the Path RRO. When the egress node receives the 399 Path message, it can calculate the end-to-end cost, latency 400 and/or latency variation properties of the LSP. 402 Before the Resv message is sent to the upstream node, the egress 403 node adds the requested subobject(s) with the downstream cost, 404 latency and/or latency variation metric value(s) associated with 405 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 transit 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 ingress node receives the Resv message, it can 412 calculate the end-to-end cost, latency and/or latency variation 413 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 and latency variation metric from information recorded in the 419 RRO is beyond the scope of this document. 421 Based on the local policy, the ingress and egress nodes can 422 advertise the calculated end-to-end cost, latency and/or latency 423 variation properties of the FA or RA LSP in TE link 424 advertisement to the routing instance based on the procedure 425 described in [DRAFT-OSPF-TE-METRIC], [DRAFT-ISIS-TE-METRIC]. 427 Based on the local policy, a transit node (e.g. the edge node of 428 a domain) may edit a Path or Resv RRO to remove route 429 information (e.g. node or interface identifier information) 430 before forwarding it. A node that does this SHOULD summarize the 431 cost, latency and latency variation data removed as a single 432 value for each for the loose hop that is summarized by the 433 transit node. How a transit node calculates the cost, latency o 434 and/or latency variation metric for the segment summarized by 435 the transit node is beyond the scope of this document. 437 4. Security Considerations 439 This document does not introduce any additional security issues 440 above those identified in [RFC5920], [RFC5420], [RFC2205], 441 [RFC3209], and [RFC3473]. 443 5. IANA Considerations 445 5.1. RSVP Attribute Bit Flags 447 The IANA has created a registry and manages the space of 448 attributes bit flags of Attribute Flags TLV as described in 449 section 11.3 of [RFC5420]. It is requested that the IANA makes 450 Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt 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 470 - Bit number: TBD (recommended bit position 13) 472 - Defining RFC: this I-D 474 - Name of bit: Latency Variation Flag 476 5.2. ROUTE_RECORD subobject 478 This document introduces the following three new RRO 479 subobject: 481 Type Name Reference 483 --------- ---------------------- --------- 485 TBD (35) Cost subobject This I-D 487 TBD (36) Latency subobject This I-D 489 TBD (37) Latency Variation subobject This I-D 491 5.2. New RSVP error sub-code 493 For Error Code = 2 "Policy Control Failure" (see [RFC2205]) the 494 following sub-code is defined. 496 Sub-code Value 497 -------- ----- 498 Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt 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 507 IANA. 508 Suggested Value: 107. 510 6. Acknowledgments 512 Authors would like to thank Ori Gerstel, Gabriele Maria 513 Galimberti, Luyuan Fang and Walid Wakim for their review 514 comments. 516 7. References 518 7.1. Normative References 520 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 521 Requirement Levels", BCP 14, RFC 2119, March 1997. 523 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 524 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 525 LSP Tunnels", RFC 3209, December 2001. 527 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and 528 A. Ayyangarps, "Encoding of Attributes for MPLS LSP 529 Establishment Using Resource Reservation Protocol 530 Traffic Engineering (RSVP-TE)", RFC 5420, February 531 2009. 533 [DRAFT-OSPF-TE-METRIC] S. Giacalone, D. Ward, J. Drake, A. 534 Atlas, S. Previdi, "OSPF Traffic Engineering (TE) 535 Metric Extensions", draft-ietf-ospf-te-metric- 536 extensions, work in progress. 538 [DRAFT-ISIS-TE-METRIC] S. Previdi, S. Giacalone, D. Ward, J. 539 Drake, A. Atlas, C. Filsfils, "IS-IS Traffic 540 Engineering (TE) Metric Extensions", draft-ietf-isis- 541 te-metric-extensions, work in progress. 543 [DRAFT-SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C. 544 Margaria,, "RSVP-TE Extensions for Collecting SRLG 545 Information", draft-ietf-ccamp-rsvp-te-srlg- 546 collect.txt, work in progress. 548 Internet-Draft draft-ietf-ccamp-te-metric-recording-02.txt 550 7.2. Informative References 552 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 553 "Generalized Multiprotocol Label Switching (GMPLS) 554 User-Network Interface (UNI): Resource ReserVation 555 Protocol-Traffic Engineering (RSVP-TE) Support for the 556 Overlay Model", RFC 4208, October 2005. 558 [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation 559 Protocol (RSVP) -- Version 1 Message Processing 560 Rules", RFC 2209, September 1997. 562 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 563 Networks", RFC 5920, July 2010. 565 Authors' Addresses 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