idnits 2.17.1 draft-ietf-teas-te-metric-recording-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 1) being 66 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 (December 11, 2014) is 3421 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: 'DRAFT-RRO-EDIT' is mentioned on line 598, but not defined == Missing Reference: 'RFC2205' is mentioned on line 657, but not defined == Missing Reference: 'RFC3473' is mentioned on line 606, but not defined == Unused Reference: 'RFC2209' is defined on line 715, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group Zafar Ali 2 Internet Draft George Swallow 3 Intended status: Standard Track Clarence Filsfils 4 Expires: June 10, 2015 Matt Hartley 5 Cisco Systems 7 Kenji Kumaki 8 KDDI Corporation 10 Ruediger Kunze 11 Deutsche Telekom AG 13 December 11, 2014 15 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) 16 extension for recording TE Metric of a Label Switched Path 17 draft-ietf-teas-te-metric-recording-00.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 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 June 10, 2015. 37 Copyright Notice 39 Copyright (c) 2014 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 document must include Simplified BSD License text as described in 49 Section 4.e of the Trust Legal Provisions and are provided without 50 warranty as described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) 58 controlling the copyright in such materials, this document may not 59 be modified outside the IETF Standards Process, and derivative 60 works of it may not be created outside the IETF Standards Process, 61 except to format it for publication as an RFC or to translate it 62 into languages other than English. 64 Internet-Draft draft-ietf-teas-te-metric-recording-00.txt 66 Abstract 68 There are many scenarios in which Traffic Engineering (TE) metrics 69 such as cost, latency and latency variation associated with a 70 Forwarding Adjacency (FA) or Routing Adjacency (RA) Label Switched 71 Path (LSP) are not available to the ingress and egress nodes. This 72 draft provides extensions for the Resource ReserVation Protocol- 73 Traffic Engineering (RSVP-TE) for the support of the discovery of 74 cost, latency and latency variation of an LSP. 76 Conventions used in this document 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 80 this document are to be interpreted as described in RFC 2119 81 [RFC2119]. 83 Table of Contents 85 1. Introduction................................................3 86 2. RSVP-TE Requirement.........................................4 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................................5 91 3.1. Cost, Latency, and Latency Variation Collection Flags.....5 92 3.4. Cost subobject............................................5 93 3.5. Latency subobject.........................................6 94 3.6. Latency Variation subobject...............................7 95 3.7. Signaling Procedures......................................8 96 4. Security Considerations....................................12 97 5. IANA Considerations........................................12 98 5.1. RSVP Attribute Bit Flags.................................12 99 Internet-Draft draft-ietf-teas-te-metric-recording-00.txt 101 5.2. New RSVP error sub-code..................................13 102 6. Acknowledgments............................................14 103 7. References.................................................14 104 7.1. Normative References.....................................14 105 7.2. Informative References...................................14 107 1. Introduction 109 In certain networks, such as financial information networks, 110 network performance information (e.g. latency, latency 111 variation) is becoming as critical to data path selection as 112 other metrics [DRAFT-OSPF-TE-METRIC], [DRAFT-ISIS-TE-METRIC]. If 113 cost, latency or latency variation associated with a Forwarding 114 Adjacency (FA) or a Routing Adjacency (RA) LSP is not available 115 to the ingress or egress node, it cannot be advertised as an 116 attribute of the FA or RA. There are scenarios in packet and 117 optical networks where the route information of an LSP may not 118 be provided to the ingress node for confidentiality reasons 119 and/or the ingress node may not run the same routing instance as 120 the intermediate nodes traversed by the path. In such scenarios, 121 the ingress node cannot determine the cost, latency and latency 122 variation properties of the LSP's route. 124 One possible way to address this issue is to configure cost, 125 latency and latency variation values manually. However, in the 126 event of an LSP being rerouted (e.g. due to re-optimization), 127 such configuration information may become invalid. Consequently, 128 in cases where that an LSP is advertised as a TE-Link, the 129 ingress and/or egress nodes cannot provide the correct latency, 130 latency variation and cost attribute associated with the TE-Link 131 automatically. 133 In summary, there is a requirement for the ingress and egress 134 nodes to learn the cost, latency and latency variation 135 attributes of an FA or RA LSP. This draft provides extensions to 136 the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) 137 for the support of the automatic discovery of these attributes. 139 1.1. Use Cases 141 1.1.1. GMPLS 143 In Generalized Multi-Protocol Label Switching (GMPLS) networks 144 signaling bidirectional LSPs, the egress node cannot determine 145 the cost, latency and latency variation properties of the LSP 146 path. A multi-domain or multi-layer network is an example of 147 such networks. A GMPLS User-Network Interface (UNI) [RFC4208] is 148 also an example of such networks. 150 Internet-Draft draft-ietf-teas-te-metric-recording-00.txt 152 1.1.2. Inter-area tunnels with loose-hops 154 When a LSP is established over multiple IGP-areas using loose 155 hops in the ERO, the ingress node only has knowledge of the 156 first IGP-area traversed by the LSP. In this case, it cannot 157 determine the cost, latency and latency variation properties of 158 the LSP path. 160 2. RSVP-TE Requirements 162 This section outlines RSVP-TE requirements for the support of 163 the automatic discovery of cost, latency and latency variation 164 attributes of an LSP. These requirements are very similar to the 165 requirement of discovering the Shared Risk Link Groups (SRLGs) 166 associated with the route taken by an LSP [DRAFT-SRLG- 167 RECORDING]. 169 2.1. Cost, Latency and Latency Variation Collection Indication 171 The ingress node of the LSP must be capable of indicating 172 whether the cost, latency and latency variation attributes of 173 the LSP should be collected during the signaling procedure of 174 setting up the LSP. No cost, latency or latency variation 175 information is collected without an explicit request being made 176 by the ingress node. 178 2.2. Cost, Latency and Latency Variation Collection 180 If requested, cost, latency and latency variation is 181 collected during the setup of an LSP. The endpoints of the LSP 182 may use the collected information for routing, flooding and TE 183 link configuration and other purposes. 185 2.3. Cost, Latency and Latency Variation Update 187 When the cost, latency or latency variation property of a TE 188 link along the route of a LSP for which that property was 189 collected changes (e.g., if the administrator changes the cost 190 of a TE link traversed by the LSP), the node where the change 191 occurred needs to be capable of updating the cost, latency and 192 latency variation information of the path and signaling this to 193 the end-points. Similarly, if a path segment of the LSP is 194 rerouted, the endpoints of the re-routed segment need to be 195 capable of updating the cost, latency and latency variation 196 information of the path. Any node which adds cost, latency or 197 latency variation information to an LSP during initial setup, 198 needs to signal changes to these values to both endpoints. 200 2.4. Cost Definition 202 Although the terms latency and latency variation are well 203 understood, "cost" may be ambiguous; in particular, in the 204 Internet-Draft draft-ietf-teas-te-metric-recording-00.txt 206 context of a LSP that traverses nodes and links operated by 207 different entities, there may be no common definition of cost. 208 However, there are situations in which the entire LSP may be 209 within a single AS (e.g. inter-area LSPs) in which cost 210 discovery is useful. 212 The precise meaning and interpretation of numerical costs is a 213 matter for the network operator. For the purposes of this 214 document, two constraints are assumed: 216 . A higher cost represents an inferior path 218 . Simple addition of costs for different sections of a path 219 must make sense. 221 3. RSVP-TE signaling extensions 223 3.1. Cost, Latency and Latency Variation Collection Flags 225 In order to indicate nodes that cost, latency and/ or latency 226 variation collection is desired, the following three Attribute 227 flags are defined in the Attribute Flags TLV: 229 - Cost Collection flag (to be assigned by IANA) 231 - Latency Collection flag (to be assigned by IANA) 233 - Latency Variation Collection flag (to be assigned by IANA) 235 These flags are set and carried in either the LSP_ATTRIBUTES or 236 LSP_REQUIRED_ATTRIBUTES Objects in a Path message. 238 3.2. Cost Subobject 240 The Cost subobject is a new RRO (ROUTE_RECORD OBJECT) sub-object 241 used to record the cost information of the LSP. Its format is 242 similar to the other RRO subobjects defined in [RFC3209]. 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Type | Length | Reserved (must be zero) | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Downstream Cost | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Upstream Cost | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Type: TBA1 - Cost subobject (to be assigned by IANA). 256 Internet-Draft draft-ietf-teas-te-metric-recording-00.txt 258 Length: The Length value is set to 8 or 12 depending on the 259 presence of Upstream Cost information. It MUST NOT be set to 260 any other value. 262 Reserved: This field is reserved for future use. It MUST be 263 set to 0 on transmission and MUST be ignored when received. 265 Downstream Cost: Cost of the local link along the route of 266 the LSP in the direction of the tail-end node, encoded as a 267 32-bit integer. This approach has been taken to avoid 268 defining a flag for each cost type in the Attribute-Flags 269 TLV. 271 Upstream Cost: Cost of the local link along the route of the 272 LSP in the direction of the head-end node, encoded as a 32- 273 bit integer. 275 3.3. Latency Subobject 277 The Latency subobject is a new RRO sub-object to record the 278 latency information of the LSP. Its format is similar the other 279 RRO subobjects defined in [RFC3209]. 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Type | Length | Reserved (must be zero) | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 |A| Reserved | Downstream Delay | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 |A| Reserved | Upstream Delay | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Type: TBA2 - Latency subobject (to be assigned by IANA). 293 Length: 8 or 12 depending on the presence of Upstream Delay 294 information. 296 A-bit: These fields represent the Anomalous (A) bit 297 associated with the Downstream and Upstream Delay 298 respectively, as defined in [DRAFT-OSPF-TE-METRIC]. 300 Reserved: These fields are reserved for future use. They MUST 301 be set to 0 when sent and MUST be ignored when received. 303 Downstream Delay: Delay of the local link along the route of 304 the LSP in the direction of the tail-end node, encoded as 24- 305 bit integer, as defined in [DRAFT-OSPF-TE-METRIC]. When set 306 Internet-Draft draft-ietf-teas-te-metric-recording-00.txt 308 to the maximum value 16,777,215 (16.777215 sec), the delay is 309 at least that value and may be larger. 311 Upstream Delay: Delay of the local link along the route of 312 the LSP in the direction of the head-end node, encoded as 24- 313 bit integer, as defined in [DRAFT-OSPF-TE-METRIC]. When set 314 to the maximum value 16,777,215 (16.777215 sec), the delay is 315 at least that value and may be larger. 317 3.4. Latency Variation Subobject 319 The Latency Variation subobject is a new RRO sub-object to 320 record the Latency Variation information of the LSP. Its format 321 is similar to the other RRO subobjects defined in [RFC3209]. 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Type | Length | Reserved (must be zero) | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 |A| Reserved | Downstream Delay Variation | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 |A| Reserved | Upstream Delay Variation | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 Type: TBA3 - Latency Variation subobject (to be assigned by 334 IANA). 336 Length: 8 or 12 depending on the presence of Upstream Latency 337 Variation information. 339 A-bit: These fields represent the Anomalous (A) bit 340 associated with the Downstream and Upstream Delay Variation 341 respectively, as defined in [DRAFT-OSPF-TE-METRIC]. 343 Reserved: These fields are reserved for future use. It SHOULD 344 be set to 0 when sent and MUST be ignored when received. 346 Downstream Delay Variation: Delay Variation of the local link 347 along the route of the LSP in the direction of the tail-end 348 node, encoded as 24-bit integer, as defined in [DRAFT-OSPF- 349 TE-METRIC]. When set to the maximum value 16,777,215 350 (16.777215 sec), the delay is at least that value and may be 351 larger. 353 Upstream Delay Variation: Delay Variation of the local link 354 along the route of the LSP in the direction of the head-end 355 node, encoded as 24-bit integer. When set to 0, it has not 356 been measured. When set to the maximum value 16,777,215 357 Internet-Draft draft-ietf-teas-te-metric-recording-00.txt 359 (16.777215 sec), the delay is at least that value and may be 360 larger. 362 4. Signaling Procedures 364 The rules for processing the LSP_ATTRIBUTES and 365 LSP_REQUIRED_ATTRIBUTES Objects and RRO defined in [RFC5420] are 366 not changed. 368 4.1. Collection request 370 Typically, the ingress node learns the route of an LSP by adding 371 a RRO in the Path message. If an ingress node also desires cost, 372 latency and/or latency variation recording, it MUST set the 373 appropriate flag(s) in the Attribute Flags TLV of the 374 LSP_ATTRIBUTES (if recording is desired but not mandatory) or 375 LSP_REQUIRED_ATTRIBUTES (if recording in mandatory) Object. 376 None, all or any of the Cost Collection, Latency Collection or 377 Latency Variation Collection flags MAY be set in the Attribute 378 Flags TLV of the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES 379 Object. These flags affect both Path and Resv RRO processing, as 380 described below. 382 The Cost Collection, Latency Collection or Latency Variation 383 Collection flags SHOULD NOT be set in an Attribute Flags TLV in 384 a Resv message. If any of these flags is set in a received 385 Attribute Flags TLV in a Resv message, it MUST be ignored. 387 The Cost Collection, Latency Collection or Latency Variation 388 Collection flags SHOULD NOT be set in an Attribute Flags TLV in 389 a RRO. If any of these flags is set in a received Attribute 390 Flags TLV in a RRO, it MUST be ignored. 392 4.2. Path and Resv message processing 394 4.2.1. Cost 396 If a node receives a Path message containing a 397 LSP_REQUIRED_ATTRIBUTES Object with the Cost Collection Flag set 398 in the Attribute Flags TLV: 400 . If local policy disallows providing the requested 401 information to the endpoints, the node MUST return a Path 402 Error message with error code "Policy Control Failure" (2) 403 and subcode "Cost Recording Rejected" (value to be assigned 404 by IANA, suggested value 105). 406 . It SHOULD add a Cost subobject to the Path and Resv RROs 407 for the LSP. It SHOULD supply only downstream information 408 for a unidirectional LSP, and SHOULD provide both upstream 409 Internet-Draft draft-ietf-teas-te-metric-recording-00.txt 411 and downstream information if a bidirectional LSP is being 412 signaled. 414 . If Cost information is not known, a Cost subobject SHOULD 415 NOT be added to either the Path or Resv RRO. 417 If a node receives a Path message containing a LSP_ATTRIBUTES 418 Object with the Cost Collection Flag set in the Attribute Flags 419 TLV: 421 . If local policy disallows providing the requested 422 information to the endpoints, the Path message SHOULD NOT 423 be rejected. A Cost subobject is not added to the Path or 424 Resv RRO. 426 . If local policy permits, it SHOULD add a Cost subobject to 427 the Path and Resv RROs for the LSP. It SHOULD supply only 428 downstream information for a unidirectional LSP, and SHOULD 429 provide both upstream and downstream information if a 430 bidirectional LSP is being signaled. 432 . If Cost information is not known, a Cost subobject SHOULD 433 NOT be added to either the Path or Resv RRO. 435 When adding a Cost subobject to a Path or Resv RRO: 437 . The Downstream Cost is set to the cost of the local link 438 used by the LSP in the direction of the egress node. It 439 SHOULD be set to zero by the egress node. 441 . The Upstream Cost, if set, is set to the cost of the local 442 link used by the LSP in the direction of the ingress node. 443 It SHOULD be set to zero by the ingress node. 445 . The cost of a local link is the Interior Gateway Protocol 446 (IGP) metric or TE metric of the link in question, 447 depending on the policy of the processing node. 449 4.2.2. Latency 451 If a node receives a Path message containing a 452 LSP_REQUIRED_ATTRIBUTES Object with the Latency Collection Flag 453 set in the Attribute Flags TLV: 455 . If local policy disallows providing the requested 456 information to the endpoints, the node MUST return a Path 457 Error message with error code "Policy Control Failure" (2) 458 and subcode "Latency Recording Rejected" (value to be 459 assigned by IANA, suggested value 106). 461 . It SHOULD add a Latency subobject to the Path and Resv 462 RROs for the LSP. It SHOULD supply only downstream 463 Internet-Draft draft-ietf-teas-te-metric-recording-00.txt 465 information for a unidirectional LSP, and SHOULD provide 466 both upstream and downstream information if a bidirectional 467 LSP is being signaled. 469 . If Latency information is not known, a Latency subobject 470 SHOULD NOT be added to either the Path or Resv RRO. 472 If a node receives a Path message containing a LSP_ATTRIBUTES 473 Object with the Latency Collection Flag set in the Attribute 474 Flags TLV: 476 . If local policy disallows providing the requested 477 information to the endpoints, the Path message SHOULD NOT 478 be rejected. A Latency subobject is not added to the Path 479 or Resv RRO. 481 . If local policy permits, it SHOULD add a Latency subobject 482 to the Path and Resv RROs for the LSP. It SHOULD supply 483 only downstream information for a unidirectional LSP, and 484 SHOULD provide both upstream and downstream information if 485 a bidirectional LSP is being signaled. 487 . If Latency information is not known, a Latency subobject 488 SHOULD NOT be added to either the Path or Resv RRO. 490 When adding a Latency subobject to a Path or Resv RRO: 492 . The Downstream Delay is set to the delay of the local link 493 used by the LSP in the direction of the egress node. It 494 SHOULD be set to zero by the egress node. 496 . The Upstream Delay, if set, is set to the delay of the 497 local link used by the LSP in the direction of the ingress 498 node. It SHOULD be set to zero by the ingress node. 500 . The A-bit for the downstream and upstream latency SHOULD 501 be set as described in [DRAFT-OSPF-TE-METRIC]. 503 4.2.3. Latency Variation 505 If a node receives a Path message containing a 506 LSP_REQUIRED_ATTRIBUTES Object with the Latency Variation 507 Collection Flag set in the Attribute Flags TLV: 509 . If local policy disallows providing the requested 510 information to the endpoints, the node MUST return a Path 511 Error message with error code "Policy Control Failure" (2) 512 and subcode "Latency Variation Recording Rejected" (value 513 to be assigned by IANA, suggested value 107). 515 . It SHOULD add a Latency Variation subobject to the Path 516 and Resv RROs for the LSP. It SHOULD supply only downstream 517 Internet-Draft draft-ietf-teas-te-metric-recording-00.txt 519 information for a unidirectional LSP, and SHOULD provide 520 both upstream and downstream information if a bidirectional 521 LSP is being signaled. 523 . If Latency Variation information is not known, a Latency 524 subobject SHOULD NOT be added to either the Path or Resv 525 RRO. 527 If a node receives a Path message containing a LSP_ATTRIBUTES 528 Object with the Latency Variation Collection Flag set in the 529 Attribute Flags TLV: 531 . If local policy disallows providing the requested 532 information to the endpoints, the Path message SHOULD NOT 533 be rejected. A Latency Variation subobject is not added to 534 the Path or Resv RRO. 536 . If local policy permits, it SHOULD add a Latency Variation 537 subobject to the Path and Resv RROs for the LSP. It SHOULD 538 supply only downstream information for a unidirectional 539 LSP, and SHOULD provide both upstream and downstream 540 information if a bidirectional LSP is being signaled. 542 . If Latency Variation information is not known, a Latency 543 subobject SHOULD NOT be added to either the Path or Resv 544 RRO. 546 When adding a Latency Variation subobject to a Path or Resv RRO: 548 . The Downstream Latency Variation is set to the latency of 549 the local link used by the LSP in the direction of the 550 egress node. It SHOULD be set to zero by the egress node. 552 . The Upstream Latency Variation, if set, is set to the 553 latency of the local link used by the LSP in the direction 554 of the ingress node. It SHOULD be set to zero by the egress 555 node. 557 . The A-bit for the downstream and upstream latency SHOULD 558 be set as described in [DRAFT-OSPF-TE-METRIC]. 560 4.3. Metric Update 562 When the cost, latency and/or latency variation information of a 563 link is changed, the corresponding metric values for the LSPs 564 using that link should also be updated. If node has added Cost, 565 Latency and/or Latency Variation subobjects to the Path or Resv 566 RRO, the procedures defined in Section 4.4.3 of RFC 3209 567 [RFC3209] MUST be used to communicate any changes to relevant 568 information to the other nodes on the LSP's path. The node need 569 not send an update for changes to information which has not been 570 added to the RRO. 572 Internet-Draft draft-ietf-teas-te-metric-recording-00.txt 574 5. Endpoint processing 576 The ingress and egress nodes of a LSP may calculate the end-to- 577 end cost, latency and/or latency variation properties of the LSP 578 from the supplied values in the Resv or Path RRO respectively. 580 Typically, cost and latency are additive metrics, but latency 581 variation is not an additive metric. The means by which the 582 ingress and egress nodes compute the end-to-end cost, latency 583 and latency variation metric from information recorded in the 584 RRO is a local decision and is beyond the scope of this 585 document. 587 Based on the local policy, the ingress and egress nodes can 588 advertise the calculated end-to-end cost, latency and/or latency 589 variation properties of the FA or RA LSP in TE link 590 advertisement to the routing instance based on the procedure 591 described in [DRAFT-OSPF-TE-METRIC], [DRAFT-ISIS-TE-METRIC]. 593 Based on the local policy, a transit node (e.g. the edge node of 594 a domain) may edit a Path or Resv RRO to remove route 595 information (e.g. node or interface identifier information) 596 before forwarding it. A node that does this SHOULD summarize the 597 cost, latency and latency variation data and SHOULD follow 598 procedure defined in [DRAFT-RRO-EDIT]. How a node that performs 599 the RRO edit operation calculates the cost, latency o and/or 600 latency variation metric is beyond the scope of this document. 602 6. Security Considerations 604 This document does not introduce any additional security issues 605 above those identified in [RFC5920], [RFC5420], [RFC2205], 606 [RFC3209], and [RFC3473]. 608 7. IANA Considerations 610 7.1. RSVP Attribute Bit Flags 612 The IANA has created a registry and manages the space of 613 attributes bit flags of Attribute Flags TLV as described in 614 section 11.3 of [RFC5420]. It is requested that the IANA makes 615 assignments from the Attribute Bit Flags defined in this 616 document. 618 This document introduces the following three new Attribute 619 Bit Flag: 621 - Bit number: TBD (recommended bit position 11) 623 - Defining RFC: this I-D 625 - Name of bit: Cost Collection Flag 626 Internet-Draft draft-ietf-teas-te-metric-recording-00.txt 628 - Bit number: TBD (recommended bit position 12) 630 - Defining RFC: this I-D 632 - Name of bit: Latency Collection Flag 634 - Bit number: TBD (recommended bit position 13) 636 - Defining RFC: this I-D 638 - Name of bit: Latency Variation Flag 640 5.2. ROUTE_RECORD subobject 642 This document introduces the following three new RRO 643 subobject: 645 Type Name Reference 647 --------- ---------------------- --------- 649 TBD (35) Cost subobject This I-D 651 TBD (36) Latency subobject This I-D 653 TBD (37) Latency Variation subobject This I-D 655 7.2. New RSVP error sub-code 657 For Error Code = 2 "Policy Control Failure" (see [RFC2205]) the 658 following sub-code is defined. 660 Sub-code Value 661 -------- ----- 663 Cost Recoding Rejected To be assigned by IANA. 664 Suggested Value: 105. 666 Latency Recoding Rejected To be assigned by IANA. 667 Suggested Value: 106. 669 Latency Variation Recoding Rejected To be assigned by IANA. 670 Suggested Value: 107. 672 Internet-Draft draft-ietf-teas-te-metric-recording-00.txt 674 8. Acknowledgments 676 Authors would like to thank Ori Gerstel, Gabriele Maria 677 Galimberti, Luyuan Fang and Walid Wakim for their review 678 comments. 680 9. References 682 9.1. Normative References 684 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 685 Requirement Levels", BCP 14, RFC 2119, March 1997. 687 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 688 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 689 LSP Tunnels", RFC 3209, December 2001. 691 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and 692 A. Ayyangarps, "Encoding of Attributes for MPLS LSP 693 Establishment Using Resource Reservation Protocol 694 Traffic Engineering (RSVP-TE)", RFC 5420, February 695 2009. 697 [DRAFT-OSPF-TE-METRIC] S. Giacalone, D. Ward, J. Drake, A. 698 Atlas, S. Previdi, "OSPF Traffic Engineering (TE) 699 Metric Extensions", draft-ietf-ospf-te-metric- 700 extensions, work in progress. 702 [DRAFT-ISIS-TE-METRIC] S. Previdi, S. Giacalone, D. Ward, J. 703 Drake, A. Atlas, C. Filsfils, "IS-IS Traffic 704 Engineering (TE) Metric Extensions", draft-ietf-isis- 705 te-metric-extensions, work in progress. 707 9.2. Informative References 709 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 710 "Generalized Multiprotocol Label Switching (GMPLS) 711 User-Network Interface (UNI): Resource ReserVation 712 Protocol-Traffic Engineering (RSVP-TE) Support for the 713 Overlay Model", RFC 4208, October 2005. 715 [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation 716 Protocol (RSVP) -- Version 1 Message Processing 717 Rules", RFC 2209, September 1997. 719 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 720 Networks", RFC 5920, July 2010. 722 Internet-Draft draft-ietf-teas-te-metric-recording-00.txt 724 [DRAFT-SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C. 725 Margaria,, "RSVP-TE Extensions for Collecting SRLG 726 Information", draft-ietf-ccamp-rsvp-te-srlg- 727 collect.txt, work in progress. 729 Authors' Addresses 731 Zafar Ali 732 Cisco Systems, Inc. 733 Email: zali@cisco.com 735 George Swallow 736 Cisco Systems, Inc. 737 swallow@cisco.com 739 Clarence Filsfils 740 Cisco Systems, Inc. 741 cfilsfil@cisco.com 743 Matt Hartley 744 Cisco Systems 745 Email: mhartley@cisco.com 747 Kenji Kumaki 748 KDDI Corporation 749 Email: ke-kumaki@kddi.com 751 Rudiger Kunze 752 Deutsche Telekom AG 753 Ruediger.Kunze@telekom.de