idnits 2.17.1 draft-ietf-ccamp-te-metric-recording-04.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 72 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 (August 20, 2014) is 3530 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 599, but not defined == Missing Reference: 'RFC2205' is mentioned on line 658, but not defined == Missing Reference: 'RFC3473' is mentioned on line 607, but not defined == Unused Reference: 'RFC2209' is defined on line 716, 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. -------------------------------------------------------------------------------- 2 CCAMP Working Group Zafar Ali 3 Internet Draft George Swallow 4 Intended status: Standard Track Clarence Filsfils 5 Expires: February 20, 2015 Matt Hartley 6 Cisco Systems 8 Kenji Kumaki 9 KDDI Corporation 11 Ruediger Kunze 12 Deutsche Telekom AG 14 August 20, 2014 16 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) 17 extension for recording TE Metric of a Label Switched Path 18 draft-ietf-ccamp-te-metric-recording-04.txt 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other 32 documents at any time. It is inappropriate to use Internet-Drafts 33 as reference material or to cite them other than as "work in 34 progress." 36 This Internet-Draft will expire on February 20, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 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 Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt 67 Abstract 69 There are many scenarios in which Traffic Engineering (TE) metrics 70 such as cost, latency and latency variation associated with a 71 Forwarding Adjacency (FA) or Routing Adjacency (RA) Label Switched 72 Path (LSP) are not available to the ingress and egress nodes. This 73 draft provides extensions for the Resource ReserVation Protocol- 74 Traffic Engineering (RSVP-TE) for the support of the discovery of 75 cost, latency and latency variation of an LSP. 77 Conventions used in this document 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 81 this document are to be interpreted as described in RFC 2119 82 [RFC2119]. 84 Table of Contents 86 1. Introduction................................................3 87 2. RSVP-TE Requirement.........................................4 88 2.1. Cost, Latency and Latency Variation Collection Indication.4 89 2.2. Cost, Latency and Latency Variation Collection............4 90 2.3. Cost, Latency and Latency Variation Update................4 91 3. RSVP-TE signaling extensions................................5 92 3.1. Cost, Latency, and Latency Variation Collection Flags.....5 93 3.4. Cost subobject............................................5 94 3.5. Latency subobject.........................................6 95 3.6. Latency Variation subobject...............................7 96 3.7. Signaling Procedures......................................8 97 4. Security Considerations....................................12 98 5. IANA Considerations........................................12 99 5.1. RSVP Attribute Bit Flags.................................12 100 Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt 102 5.2. New RSVP error sub-code..................................13 103 6. Acknowledgments............................................14 104 7. References.................................................14 105 7.1. Normative References.....................................14 106 7.2. Informative References...................................14 108 1. Introduction 110 In certain networks, such as financial information networks, 111 network performance information (e.g. latency, latency 112 variation) is becoming as critical to data path selection as 113 other metrics [DRAFT-OSPF-TE-METRIC], [DRAFT-ISIS-TE-METRIC]. If 114 cost, latency or latency variation associated with a Forwarding 115 Adjacency (FA) or a Routing Adjacency (RA) LSP is not available 116 to the ingress or egress node, it cannot be advertised as an 117 attribute of the FA or RA. There are scenarios in packet and 118 optical networks where the route information of an LSP may not 119 be provided to the ingress node for confidentiality reasons 120 and/or the ingress node may not run the same routing instance as 121 the intermediate nodes traversed by the path. In such scenarios, 122 the ingress node cannot determine the cost, latency and latency 123 variation properties of the LSP's route. 125 One possible way to address this issue is to configure cost, 126 latency and latency variation values manually. However, in the 127 event of an LSP being rerouted (e.g. due to re-optimization), 128 such configuration information may become invalid. Consequently, 129 in cases where that an LSP is advertised as a TE-Link, the 130 ingress and/or egress nodes cannot provide the correct latency, 131 latency variation and cost attribute associated with the TE-Link 132 automatically. 134 In summary, there is a requirement for the ingress and egress 135 nodes to learn the cost, latency and latency variation 136 attributes of an FA or RA LSP. This draft provides extensions to 137 the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) 138 for the support of the automatic discovery of these attributes. 140 1.1. Use Cases 142 1.1.1. GMPLS 144 In Generalized Multi-Protocol Label Switching (GMPLS) networks 145 signaling bidirectional LSPs, the egress node cannot determine 146 the cost, latency and latency variation properties of the LSP 147 path. A multi-domain or multi-layer network is an example of 148 such networks. A GMPLS User-Network Interface (UNI) [RFC4208] is 149 also an example of such networks. 151 Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt 153 1.1.2. Inter-area tunnels with loose-hops 155 When a LSP is established over multiple IGP-areas using loose 156 hops in the ERO, the ingress node only has knowledge of the 157 first IGP-area traversed by the LSP. In this case, it cannot 158 determine the cost, latency and latency variation properties of 159 the LSP path. 161 2. RSVP-TE Requirements 163 This section outlines RSVP-TE requirements for the support of 164 the automatic discovery of cost, latency and latency variation 165 attributes of an LSP. These requirements are very similar to the 166 requirement of discovering the Shared Risk Link Groups (SRLGs) 167 associated with the route taken by an LSP [DRAFT-SRLG- 168 RECORDING]. 170 2.1. Cost, Latency and Latency Variation Collection Indication 172 The ingress node of the LSP must be capable of indicating 173 whether the cost, latency and latency variation attributes of 174 the LSP should be collected during the signaling procedure of 175 setting up the LSP. No cost, latency or latency variation 176 information is collected without an explicit request being made 177 by the ingress node. 179 2.2. Cost, Latency and Latency Variation Collection 181 If requested, cost, latency and latency variation is 182 collected during the setup of an LSP. The endpoints of the LSP 183 may use the collected information for routing, flooding and TE 184 link configuration and other purposes. 186 2.3. Cost, Latency and Latency Variation Update 188 When the cost, latency or latency variation property of a TE 189 link along the route of a LSP for which that property was 190 collected changes (e.g., if the administrator changes the cost 191 of a TE link traversed by the LSP), the node where the change 192 occurred needs to be capable of updating the cost, latency and 193 latency variation information of the path and signaling this to 194 the end-points. Similarly, if a path segment of the LSP is 195 rerouted, the endpoints of the re-routed segment need to be 196 capable of updating the cost, latency and latency variation 197 information of the path. Any node which adds cost, latency or 198 latency variation information to an LSP during initial setup, 199 needs to signal changes to these values to both endpoints. 201 2.4. Cost Definition 203 Although the terms latency and latency variation are well 204 understood, "cost" may be ambiguous; in particular, in the 205 Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt 207 context of a LSP that traverses nodes and links operated by 208 different entities, there may be no common definition of cost. 209 However, there are situations in which the entire LSP may be 210 within a single AS (e.g. inter-area LSPs) in which cost 211 discovery is useful. 213 The precise meaning and interpretation of numerical costs is a 214 matter for the network operator. For the purposes of this 215 document, two constraints are assumed: 217 . A higher cost represents an inferior path 219 . Simple addition of costs for different sections of a path 220 must make sense. 222 3. RSVP-TE signaling extensions 224 3.1. Cost, Latency and Latency Variation Collection Flags 226 In order to indicate nodes that cost, latency and/ or latency 227 variation collection is desired, the following three Attribute 228 flags are defined in the Attribute Flags TLV: 230 - Cost Collection flag (to be assigned by IANA) 232 - Latency Collection flag (to be assigned by IANA) 234 - Latency Variation Collection flag (to be assigned by IANA) 236 These flags are set and carried in either the LSP_ATTRIBUTES or 237 LSP_REQUIRED_ATTRIBUTES Objects in a Path message. 239 3.2. Cost Subobject 241 The Cost subobject is a new RRO (ROUTE_RECORD OBJECT) sub-object 242 used to record the cost information of the LSP. Its format is 243 similar to the other RRO subobjects defined in [RFC3209]. 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type | Length | Reserved (must be zero) | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Downstream Cost | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Upstream Cost | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Type: TBA1 - Cost subobject (to be assigned by IANA). 257 Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt 259 Length: The Length value is set to 8 or 12 depending on the 260 presence of Upstream Cost information. It MUST NOT be set to 261 any other value. 263 Reserved: This field is reserved for future use. It MUST be 264 set to 0 on transmission and MUST be ignored when received. 266 Downstream Cost: Cost of the local link along the route of 267 the LSP in the direction of the tail-end node, encoded as a 268 32-bit integer. This approach has been taken to avoid 269 defining a flag for each cost type in the Attribute-Flags 270 TLV. 272 Upstream Cost: Cost of the local link along the route of the 273 LSP in the direction of the head-end node, encoded as a 32- 274 bit integer. 276 3.3. Latency Subobject 278 The Latency subobject is a new RRO sub-object to record the 279 latency information of the LSP. Its format is similar the other 280 RRO subobjects defined in [RFC3209]. 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Type | Length | Reserved (must be zero) | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 |A| Reserved | Downstream Delay | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 |A| Reserved | Upstream Delay | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Type: TBA2 - Latency subobject (to be assigned by IANA). 294 Length: 8 or 12 depending on the presence of Upstream Delay 295 information. 297 A-bit: These fields represent the Anomalous (A) bit 298 associated with the Downstream and Upstream Delay 299 respectively, as defined in [DRAFT-OSPF-TE-METRIC]. 301 Reserved: These fields are reserved for future use. They MUST 302 be set to 0 when sent and MUST be ignored when received. 304 Downstream Delay: Delay of the local link along the route of 305 the LSP in the direction of the tail-end node, encoded as 24- 306 bit integer, as defined in [DRAFT-OSPF-TE-METRIC]. When set 307 Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt 309 to the maximum value 16,777,215 (16.777215 sec), the delay is 310 at least that value and may be larger. 312 Upstream Delay: Delay of the local link along the route of 313 the LSP in the direction of the head-end node, encoded as 24- 314 bit integer, as defined in [DRAFT-OSPF-TE-METRIC]. When set 315 to the maximum value 16,777,215 (16.777215 sec), the delay is 316 at least that value and may be larger. 318 3.4. Latency Variation Subobject 320 The Latency Variation subobject is a new RRO sub-object to 321 record the Latency Variation information of the LSP. Its format 322 is similar to the other RRO subobjects defined in [RFC3209]. 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Type | Length | Reserved (must be zero) | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 |A| Reserved | Downstream Delay Variation | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 |A| Reserved | Upstream Delay Variation | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 Type: TBA3 - Latency Variation subobject (to be assigned by 335 IANA). 337 Length: 8 or 12 depending on the presence of Upstream Latency 338 Variation information. 340 A-bit: These fields represent the Anomalous (A) bit 341 associated with the Downstream and Upstream Delay Variation 342 respectively, as defined in [DRAFT-OSPF-TE-METRIC]. 344 Reserved: These fields are reserved for future use. It SHOULD 345 be set to 0 when sent and MUST be ignored when received. 347 Downstream Delay Variation: Delay Variation of the local link 348 along the route of the LSP in the direction of the tail-end 349 node, encoded as 24-bit integer, as defined in [DRAFT-OSPF- 350 TE-METRIC]. When set to the maximum value 16,777,215 351 (16.777215 sec), the delay is at least that value and may be 352 larger. 354 Upstream Delay Variation: Delay Variation of the local link 355 along the route of the LSP in the direction of the head-end 356 node, encoded as 24-bit integer. When set to 0, it has not 357 been measured. When set to the maximum value 16,777,215 358 Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt 360 (16.777215 sec), the delay is at least that value and may be 361 larger. 363 4. Signaling Procedures 365 The rules for processing the LSP_ATTRIBUTES and 366 LSP_REQUIRED_ATTRIBUTES Objects and RRO defined in [RFC5420] are 367 not changed. 369 4.1. Collection request 371 Typically, the ingress node learns the route of an LSP by adding 372 a RRO in the Path message. If an ingress node also desires cost, 373 latency and/or latency variation recording, it MUST set the 374 appropriate flag(s) in the Attribute Flags TLV of the 375 LSP_ATTRIBUTES (if recording is desired but not mandatory) or 376 LSP_REQUIRED_ATTRIBUTES (if recording in mandatory) Object. 377 None, all or any of the Cost Collection, Latency Collection or 378 Latency Variation Collection flags MAY be set in the Attribute 379 Flags TLV of the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES 380 Object. These flags affect both Path and Resv RRO processing, as 381 described below. 383 The Cost Collection, Latency Collection or Latency Variation 384 Collection flags SHOULD NOT be set in an Attribute Flags TLV in 385 a Resv message. If any of these flags is set in a received 386 Attribute Flags TLV in a Resv message, it MUST be ignored. 388 The Cost Collection, Latency Collection or Latency Variation 389 Collection flags SHOULD NOT be set in an Attribute Flags TLV in 390 a RRO. If any of these flags is set in a received Attribute 391 Flags TLV in a RRO, it MUST be ignored. 393 4.2. Path and Resv message processing 395 4.2.1. Cost 397 If a node receives a Path message containing a 398 LSP_REQUIRED_ATTRIBUTES Object with the Cost Collection Flag set 399 in the Attribute Flags TLV: 401 . If local policy disallows providing the requested 402 information to the endpoints, the node MUST return a Path 403 Error message with error code "Policy Control Failure" (2) 404 and subcode "Cost Recording Rejected" (value to be assigned 405 by IANA, suggested value 105). 407 . It SHOULD add a Cost subobject to the Path and Resv RROs 408 for the LSP. It SHOULD supply only downstream information 409 for a unidirectional LSP, and SHOULD provide both upstream 410 Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt 412 and downstream information if a bidirectional LSP is being 413 signaled. 415 . If Cost information is not known, a Cost subobject SHOULD 416 NOT be added to either the Path or Resv RRO. 418 If a node receives a Path message containing a LSP_ATTRIBUTES 419 Object with the Cost Collection Flag set in the Attribute Flags 420 TLV: 422 . If local policy disallows providing the requested 423 information to the endpoints, the Path message SHOULD NOT 424 be rejected. A Cost subobject is not added to the Path or 425 Resv RRO. 427 . If local policy permits, it SHOULD add a Cost subobject to 428 the Path and Resv RROs for the LSP. It SHOULD supply only 429 downstream information for a unidirectional LSP, and SHOULD 430 provide both upstream and downstream information if a 431 bidirectional LSP is being signaled. 433 . If Cost information is not known, a Cost subobject SHOULD 434 NOT be added to either the Path or Resv RRO. 436 When adding a Cost subobject to a Path or Resv RRO: 438 . The Downstream Cost is set to the cost of the local link 439 used by the LSP in the direction of the egress node. It 440 SHOULD be set to zero by the egress node. 442 . The Upstream Cost, if set, is set to the cost of the local 443 link used by the LSP in the direction of the ingress node. 444 It SHOULD be set to zero by the ingress node. 446 . The cost of a local link is the Interior Gateway Protocol 447 (IGP) metric or TE metric of the link in question, 448 depending on the policy of the processing node. 450 4.2.2. Latency 452 If a node receives a Path message containing a 453 LSP_REQUIRED_ATTRIBUTES Object with the Latency Collection Flag 454 set in the Attribute Flags TLV: 456 . If local policy disallows providing the requested 457 information to the endpoints, the node MUST return a Path 458 Error message with error code "Policy Control Failure" (2) 459 and subcode "Latency Recording Rejected" (value to be 460 assigned by IANA, suggested value 106). 462 . It SHOULD add a Latency subobject to the Path and Resv 463 RROs for the LSP. It SHOULD supply only downstream 464 Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt 466 information for a unidirectional LSP, and SHOULD provide 467 both upstream and downstream information if a bidirectional 468 LSP is being signaled. 470 . If Latency information is not known, a Latency subobject 471 SHOULD NOT be added to either the Path or Resv RRO. 473 If a node receives a Path message containing a LSP_ATTRIBUTES 474 Object with the Latency Collection Flag set in the Attribute 475 Flags TLV: 477 . If local policy disallows providing the requested 478 information to the endpoints, the Path message SHOULD NOT 479 be rejected. A Latency subobject is not added to the Path 480 or Resv RRO. 482 . If local policy permits, it SHOULD add a Latency subobject 483 to the Path and Resv RROs for the LSP. It SHOULD supply 484 only downstream information for a unidirectional LSP, and 485 SHOULD provide both upstream and downstream information if 486 a bidirectional LSP is being signaled. 488 . If Latency information is not known, a Latency subobject 489 SHOULD NOT be added to either the Path or Resv RRO. 491 When adding a Latency subobject to a Path or Resv RRO: 493 . The Downstream Delay is set to the delay of the local link 494 used by the LSP in the direction of the egress node. It 495 SHOULD be set to zero by the egress node. 497 . The Upstream Delay, if set, is set to the delay of the 498 local link used by the LSP in the direction of the ingress 499 node. It SHOULD be set to zero by the ingress node. 501 . The A-bit for the downstream and upstream latency SHOULD 502 be set as described in [DRAFT-OSPF-TE-METRIC]. 504 4.2.3. Latency Variation 506 If a node receives a Path message containing a 507 LSP_REQUIRED_ATTRIBUTES Object with the Latency Variation 508 Collection Flag set in the Attribute Flags TLV: 510 . If local policy disallows providing the requested 511 information to the endpoints, the node MUST return a Path 512 Error message with error code "Policy Control Failure" (2) 513 and subcode "Latency Variation Recording Rejected" (value 514 to be assigned by IANA, suggested value 107). 516 . It SHOULD add a Latency Variation subobject to the Path 517 and Resv RROs for the LSP. It SHOULD supply only downstream 518 Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt 520 information for a unidirectional LSP, and SHOULD provide 521 both upstream and downstream information if a bidirectional 522 LSP is being signaled. 524 . If Latency Variation information is not known, a Latency 525 subobject SHOULD NOT be added to either the Path or Resv 526 RRO. 528 If a node receives a Path message containing a LSP_ATTRIBUTES 529 Object with the Latency Variation Collection Flag set in the 530 Attribute Flags TLV: 532 . If local policy disallows providing the requested 533 information to the endpoints, the Path message SHOULD NOT 534 be rejected. A Latency Variation subobject is not added to 535 the Path or Resv RRO. 537 . If local policy permits, it SHOULD add a Latency Variation 538 subobject to the Path and Resv RROs for the LSP. It SHOULD 539 supply only downstream information for a unidirectional 540 LSP, and SHOULD provide both upstream and downstream 541 information if a bidirectional LSP is being signaled. 543 . If Latency Variation information is not known, a Latency 544 subobject SHOULD NOT be added to either the Path or Resv 545 RRO. 547 When adding a Latency Variation subobject to a Path or Resv RRO: 549 . The Downstream Latency Variation is set to the latency of 550 the local link used by the LSP in the direction of the 551 egress node. It SHOULD be set to zero by the egress node. 553 . The Upstream Latency Variation, if set, is set to the 554 latency of the local link used by the LSP in the direction 555 of the ingress node. It SHOULD be set to zero by the egress 556 node. 558 . The A-bit for the downstream and upstream latency SHOULD 559 be set as described in [DRAFT-OSPF-TE-METRIC]. 561 4.3. Metric Update 563 When the cost, latency and/or latency variation information of a 564 link is changed, the corresponding metric values for the LSPs 565 using that link should also be updated. If node has added Cost, 566 Latency and/or Latency Variation subobjects to the Path or Resv 567 RRO, the procedures defined in Section 4.4.3 of RFC 3209 568 [RFC3209] MUST be used to communicate any changes to relevant 569 information to the other nodes on the LSP's path. The node need 570 not send an update for changes to information which has not been 571 added to the RRO. 573 Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt 575 5. Endpoint processing 577 The ingress and egress nodes of a LSP may calculate the end-to- 578 end cost, latency and/or latency variation properties of the LSP 579 from the supplied values in the Resv or Path RRO respectively. 581 Typically, cost and latency are additive metrics, but latency 582 variation is not an additive metric. The means by which the 583 ingress and egress nodes compute the end-to-end cost, latency 584 and latency variation metric from information recorded in the 585 RRO is a local decision and is beyond the scope of this 586 document. 588 Based on the local policy, the ingress and egress nodes can 589 advertise the calculated end-to-end cost, latency and/or latency 590 variation properties of the FA or RA LSP in TE link 591 advertisement to the routing instance based on the procedure 592 described in [DRAFT-OSPF-TE-METRIC], [DRAFT-ISIS-TE-METRIC]. 594 Based on the local policy, a transit node (e.g. the edge node of 595 a domain) may edit a Path or Resv RRO to remove route 596 information (e.g. node or interface identifier information) 597 before forwarding it. A node that does this SHOULD summarize the 598 cost, latency and latency variation data and SHOULD follow 599 procedure defined in [DRAFT-RRO-EDIT]. How a node that performs 600 the RRO edit operation calculates the cost, latency o and/or 601 latency variation metric is beyond the scope of this document. 603 6. Security Considerations 605 This document does not introduce any additional security issues 606 above those identified in [RFC5920], [RFC5420], [RFC2205], 607 [RFC3209], and [RFC3473]. 609 7. IANA Considerations 611 7.1. RSVP Attribute Bit Flags 613 The IANA has created a registry and manages the space of 614 attributes bit flags of Attribute Flags TLV as described in 615 section 11.3 of [RFC5420]. It is requested that the IANA makes 616 assignments from the Attribute Bit Flags defined in this 617 document. 619 This document introduces the following three new Attribute 620 Bit Flag: 622 - Bit number: TBD (recommended bit position 11) 624 - Defining RFC: this I-D 626 - Name of bit: Cost Collection Flag 627 Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt 629 - Bit number: TBD (recommended bit position 12) 631 - Defining RFC: this I-D 633 - Name of bit: Latency Collection Flag 635 - Bit number: TBD (recommended bit position 13) 637 - Defining RFC: this I-D 639 - Name of bit: Latency Variation Flag 641 5.2. ROUTE_RECORD subobject 643 This document introduces the following three new RRO 644 subobject: 646 Type Name Reference 648 --------- ---------------------- --------- 650 TBD (35) Cost subobject This I-D 652 TBD (36) Latency subobject This I-D 654 TBD (37) Latency Variation subobject This I-D 656 7.2. New RSVP error sub-code 658 For Error Code = 2 "Policy Control Failure" (see [RFC2205]) the 659 following sub-code is defined. 661 Sub-code Value 662 -------- ----- 664 Cost Recoding Rejected To be assigned by IANA. 665 Suggested Value: 105. 667 Latency Recoding Rejected To be assigned by IANA. 668 Suggested Value: 106. 670 Latency Variation Recoding Rejected To be assigned by IANA. 671 Suggested Value: 107. 673 Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt 675 8. Acknowledgments 677 Authors would like to thank Ori Gerstel, Gabriele Maria 678 Galimberti, Luyuan Fang and Walid Wakim for their review 679 comments. 681 9. References 683 9.1. Normative References 685 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 686 Requirement Levels", BCP 14, RFC 2119, March 1997. 688 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 689 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 690 LSP Tunnels", RFC 3209, December 2001. 692 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and 693 A. Ayyangarps, "Encoding of Attributes for MPLS LSP 694 Establishment Using Resource Reservation Protocol 695 Traffic Engineering (RSVP-TE)", RFC 5420, February 696 2009. 698 [DRAFT-OSPF-TE-METRIC] S. Giacalone, D. Ward, J. Drake, A. 699 Atlas, S. Previdi, "OSPF Traffic Engineering (TE) 700 Metric Extensions", draft-ietf-ospf-te-metric- 701 extensions, work in progress. 703 [DRAFT-ISIS-TE-METRIC] S. Previdi, S. Giacalone, D. Ward, J. 704 Drake, A. Atlas, C. Filsfils, "IS-IS Traffic 705 Engineering (TE) Metric Extensions", draft-ietf-isis- 706 te-metric-extensions, work in progress. 708 9.2. Informative References 710 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 711 "Generalized Multiprotocol Label Switching (GMPLS) 712 User-Network Interface (UNI): Resource ReserVation 713 Protocol-Traffic Engineering (RSVP-TE) Support for the 714 Overlay Model", RFC 4208, October 2005. 716 [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation 717 Protocol (RSVP) -- Version 1 Message Processing 718 Rules", RFC 2209, September 1997. 720 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 721 Networks", RFC 5920, July 2010. 723 Internet-Draft draft-ietf-ccamp-te-metric-recording-04.txt 725 [DRAFT-SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C. 726 Margaria,, "RSVP-TE Extensions for Collecting SRLG 727 Information", draft-ietf-ccamp-rsvp-te-srlg- 728 collect.txt, work in progress. 730 Authors' Addresses 732 Zafar Ali 733 Cisco Systems, Inc. 734 Email: zali@cisco.com 736 George Swallow 737 Cisco Systems, Inc. 738 swallow@cisco.com 740 Clarence Filsfils 741 Cisco Systems, Inc. 742 cfilsfil@cisco.com 744 Matt Hartley 745 Cisco Systems 746 Email: mhartley@cisco.com 748 Kenji Kumaki 749 KDDI Corporation 750 Email: ke-kumaki@kddi.com 752 Rudiger Kunze 753 Deutsche Telekom AG 754 Ruediger.Kunze@telekom.de