idnits 2.17.1 draft-ietf-teas-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 17 longer pages, the longest (page 2) being 62 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 (March 21, 2016) is 2952 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: 'RFC5553' is mentioned on line 695, but not defined == Missing Reference: 'RFC5520' is mentioned on line 441, but not defined == Missing Reference: 'RFC6107' is mentioned on line 632, but not defined == Unused Reference: 'RFC2209' is defined on line 826, 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 TEAS Working Group Zafar Ali 3 Internet Draft George Swallow 4 Intended status: Standard Track Clarence Filsfils 5 Expires: September 20, 2016 Matt Hartley 6 Cisco Systems 7 Kenji Kumaki 8 KDDI Corporation 9 Ruediger Kunze 10 Deutsche Telekom AG 11 March 21, 2016 13 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) 14 extension for recording TE Metric of a Label Switched Path 15 draft-ietf-teas-te-metric-recording-04 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet-Drafts 30 as reference material or to cite them other than as "work in 31 progress." 33 This Internet-Draft will expire on September 20, 2016. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described in 47 Section 4.e of the Trust Legal Provisions and are provided without 48 warranty as described in the Simplified BSD License. 50 Internet-Draft draft-ietf-teas-te-metric-recording-04.txt 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 Abstract 66 There are many scenarios in which Traffic Engineering (TE) metrics 67 such as cost, delay and delay variation associated with the TE link 68 formed by Label Switched Path (LSP) are not available to the 69 ingress and egress nodes. This draft provides extensions for the 70 Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) to 71 support automatic collection of cost, delay and delay variation 72 information for the TE link formed by a LSP. 74 Conventions used in this document 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 78 this document are to be interpreted as described in RFC 2119 79 [RFC2119]. 81 Table of Contents 83 1. Introduction ......................................... 3 84 1.1. Use Cases ......................................... 4 85 1.1.1. GMPLS ...................................... 4 86 1.1.2. Inter-area tunnels with loose-hops ......... 4 87 2. RSVP-TE Requirement .................................. 4 88 2.1. Cost, Delay and Delay Variation Collection 89 Indication ......................................... 4 90 2.2. Cost, Delay and Delay Variation Collection ......... 5 91 2.3. Cost, Delay and Delay Variation Update ............. 5 92 2.4. Cost Definition .................................... 5 93 3. Encoding ............................................. 5 94 3.1. Cost, Delay and Delay Variation Collection Flags ... 5 95 3.2. RRO Cost Subobject ................................. 6 96 3.3. RRO Delay Subobject ................................ 7 97 3.4. RRO Delay Variation Subobject ...................... 7 98 4. Signaling Procedures ................................. 8 99 4.1. Cost, Delay and Delay Variation Collection ......... 9 100 4.2. Metric Update ......................................12 101 4.3. Domain Boundaries ..................................12 102 4.4. Endpoint processing ................................12 103 4.5. Compatibility ......................................13 104 Internet-Draft draft-ietf-teas-te-metric-recording-04.txt 106 5. Manageability Considerations .........................13 107 5.1. Policy Configuration ...............................13 108 6. Security Considerations ..............................14 109 7. IANA Considerations ..................................14 110 7.1. RSVP Attribute Bit Flags ...........................14 111 7.2. ROUTE_RECORD subobject .............................15 112 7.3. Policy Control Failure Error subcodes ..............15 113 8. Acknowledgments ......................................15 114 9. References ...........................................16 115 9.1. Normative References ...............................16 116 9.2. Informative References .............................16 118 1. Introduction 120 In certain networks, such as financial information networks, 121 network performance information (e.g. delay, delay variation) is 122 becoming as critical to data path selection as other metrics 123 [RFC7471], [DRAFT-ISIS-TE-METRIC]. If cost, delay or delay 124 variation associated with a Forwarding Adjacency (FA) or a 125 Routing Adjacency (RA) LSP is not available to the ingress or 126 egress node, it cannot be advertised as an attribute of the TE 127 link (FA or RA). There are scenarios in packet and optical 128 networks where the route information of an LSP may not be 129 provided to the ingress node for confidentiality reasons and/or 130 the ingress node may not run the same routing instance as the 131 intermediate nodes traversed by the path. Similarly, there are 132 scenarios in which measuring delay and/ or delay variation on a 133 TE link formed by a LSP is not supported. In such scenarios, the 134 ingress node cannot determine the cost, delay and delay 135 variation properties of the LSP's route. 137 One possible way to address this issue is to configure cost, 138 delay and delay variation values manually. However, in the event 139 of an LSP being rerouted (e.g. due to re-optimization), such 140 configuration information may become invalid. Consequently, in 141 cases where that an LSP is advertised as a TE-Link, the ingress 142 and/or egress nodes cannot provide the correct delay, delay 143 variation and cost information associated with the TE-Link 144 automatically. 146 In summary, there is a requirement for the ingress and egress 147 nodes to learn the cost, delay and delay variation information 148 of the TE link formed by a LSP. This document provides a 149 mechanism to collect the cost, delay and delay variation 150 information of a LSP, which can then be advertised as properties 151 of the TE-link formed by that LSP. Note that specification of 152 the use of the collected cost, delay and delay variation 153 information is outside the scope of this document. 155 Internet-Draft draft-ietf-teas-te-metric-recording-04.txt 157 1.1. Use Cases 159 This section describes some of the use cases for the TE metric 160 recording. 162 1.1.1. GMPLS 164 In Generalized Multi-Protocol Label Switching (GMPLS) networks 165 signaling bidirectional LSPs, the egress node cannot determine 166 the cost, delay and delay variation properties of the LSP path. 167 A multi-domain or multi-layer network is an example of such 168 networks. A GMPLS User-Network Interface (UNI) [RFC4208] is also 169 an example of such networks. 171 1.1.2. Inter-area tunnels with loose-hops 173 When a LSP is established over multiple IGP-areas using loose 174 hops in the ERO, the ingress node may only has knowledge of the 175 first IGP-area traversed by the LSP. In this case, it cannot 176 determine the cost, delay and delay variation properties of the 177 LSP path. 179 2. RSVP-TE Requirement 181 This section outlines RSVP-TE requirements for the support of 182 the automatic collection of cost, delay and delay variation 183 information of an LSP. 185 As RSVP-TE requirements for cost, delay and delay variation 186 collection are similar, many parts of this section are written 187 such that they apply equally to cost, delay and delay variation 188 collection. There is also very strong similarity of these RSVP- 189 requirements with SRLG recording [DRAFT-SRLG-RECORDING]. 191 2.1. Cost, Delay and Delay Variation Collection Indication 193 The ingress node of the LSP needs be capable of indicating 194 whether the cost and/or delay and/ or delay variation 195 information of the LSP is to be collected during the signaling 196 procedure of setting up an LSP. A separate collection indication 197 flag for each of these attributes is required. There is no need 198 for cost and/or delay and/ or delay variation to be collected 199 without an explicit request for it being made by the ingress 200 node. 202 It may be preferable for the cost and/ or delay and/ or delay 203 variation collection request to be understood by all nodes along 204 the LSP's path, or it may be more important for the LSP to be 205 established successfully even if it traverses nodes that cannot 206 supply the requested information or have not implemented the 207 procedures specified in this document. It is desirable for the 208 Internet-Draft draft-ietf-teas-te-metric-recording-04.txt 210 ingress node to make the cost, delay and delay variation 211 collection request in a manner that best suits its own policy. 213 2.2. Cost, Delay and Delay Variation Collection 215 If requested, the cost and/or delay and/ or delay variation 216 information is collected during the setup of an LSP. Each of the 217 cost, delay or delay variation can be collected independently. 218 Cost and/ or delay and/ or delay variation information is for 219 each hop is added to the Path RRO during Path message 220 processing. The corresponding information is also added to the 221 Resv RRO during Resv processing at each hop. The endpoints of 222 the LSP can use the collected information, for example, for 223 routing, sharing and TE link configuration purposes. 225 2.3. Cost, Delay and Delay Variation Update 227 When the cost and/or delay and/ or delay variation information 228 of an existing LSP for which corresponding information was 229 collected during signaling changes, the relevant nodes of the 230 LSP need to be capable of updating the associated information of 231 the LSP. This means that the signaling procedure needs to be 232 capable of updating the new cost and/or delay and/ or delay 233 variation information. 235 2.4. Cost Definition 237 Although the terms delay and delay variation are well 238 understood, "cost" may be ambiguous; in particular, in the 239 context of a LSP that traverses nodes and links operated by 240 different entities, there may be no common definition of cost. 241 However, there are situations in which the entire LSP may be 242 within a single AS (e.g. inter-area LSPs) in which cost 243 discovery is useful. 245 The precise meaning and interpretation of numerical costs is a 246 matter for the network operator. For the purposes of this 247 document, two constraints are assumed: 249 . A higher cost represents an inferior path. 251 . Simple addition of costs for different sections of a path 252 must make sense. 254 3. Encoding 256 3.1. Cost, Delay and Delay Variation Collection Flags 258 In order to indicate nodes that cost and/or Delay and/ or Delay 259 variation collection is desired, this document defines the 260 following new flags in the Attribute Flags TLV (see RFC 5420 261 Internet-Draft draft-ietf-teas-te-metric-recording-04.txt 263 [RFC5420]), which MAY be carried in an LSP_REQUIRED_ATTRIBUTES 264 or LSP_ATTRIBUTES Object: 266 - Cost Collection flag (Bit number to be assigned by IANA) 268 - Delay Collection flag (Bit number to be assigned by IANA) 270 - Delay Variation Collection flag (Bit number to be assigned by 271 IANA) 273 The Cost, Delay and Delay Variation Collection flags are 274 meaningful on a Path message. If the Cost Collection flag is 275 set to 1, it means that the cost information SHOULD be reported 276 to the ingress and egress node along the setup of the LSP. 277 Similarly, if the Delay Collection flag is set to 1, it means 278 that the Delay information SHOULD be reported to the ingress and 279 egress node along the setup of the LSP. Likewise, if the Delay 280 Variation Collection flag is set to 1, it means that the Delay 281 Variation information SHOULD be reported to the ingress and 282 egress node along the setup of the LSP. 284 The rules of the processing of the Attribute Flags TLV are not 285 changed. 287 3.2. RRO Cost Subobject 289 This document defines a new RRO sub-object (ROUTE_RECORD sub- 290 object) to record the cost information of the LSP. Its format 291 is modeled on the RRO sub-objects defined in RFC 3209 [RFC3209]. 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Type | Length |D| Reserved (must be zero) | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Cost | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Type: The type of the sub-object (value to be assigned by 302 IANA). 304 Length: The Length field contains the total length of the 305 sub-object in bytes, including the Type and Length fields. 306 The Length value is set to 8. 308 Direction bit (D-bit) 310 If not set, the cost contained in this sub-object applies to 311 the downstream direction. If set, it applies to the upstream 312 direction. 314 Internet-Draft draft-ietf-teas-te-metric-recording-04.txt 316 Reserved: This field is reserved for future use. It MUST be 317 set to 0 on transmission and MUST be ignored when received. 319 Cost: Cost of the local TE link along the route of the LSP. 321 3.3. RRO Delay Subobject 323 This document defines a new RRO sub-object (ROUTE_RECORD sub- 324 object) to record the delay information of the LSP. Its format 325 is modeled on the RRO sub-objects defined in RFC 3209 [RFC3209]. 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Type | Length |D| Reserved (must be zero) | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 |A| Reserved | Delay | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 Type: The type of the sub-object (value to be assigned by 336 IANA). 338 Length: The Length field contains the total length of the 339 sub-object in bytes, including the Type and Length fields. 340 The Length value is set to 8. 342 Direction bit (D-bit) 344 If not set, the Delay contained in this sub-object applies to 345 the downstream direction. If set, it applies to the upstream 346 direction. 348 A-bit: These fields represent the Anomalous (A) bit 349 associated with the Downstream and Upstream Delay 350 respectively, as defined in RFC 7471 [RFC7471]. 352 Reserved: These fields are reserved for future use. They MUST 353 be set to 0 when sent and MUST be ignored when received. 355 Delay: Delay of the local TE link along the route of the LSP, 356 encoded as 24-bit integer, as defined in RFC 7471 [RFC7471]. 357 When set to the maximum value 16,777,215 (16.777215 sec), the 358 delay is at least that value and may be larger. 360 3.4. RRO Delay Variation Subobject 362 This document defines a new RRO sub-object (ROUTE_RECORD sub- 363 object) to record the delay variation information of the LSP. 365 Internet-Draft draft-ietf-teas-te-metric-recording-04.txt 367 Its format is modeled on the RRO sub-objects defined in RFC 3209 368 [RFC3209]. 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Type | Length |D| Reserved (must be zero) | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 |A| Reserved | Delay Variation | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 Type: The type of the sub-object (value to be assigned by 379 IANA). 381 Length: The Length field contains the total length of the 382 sub-object in bytes, including the Type and Length fields. 383 The Length value is set to 8. 385 Direction bit (D-bit) 387 If not set, the Delay Variation contained in this sub-object 388 applies to the downstream direction. If set, it applies to 389 the upstream direction. 391 A-bit: These fields represent the Anomalous (A) bit 392 associated with the Downstream and Upstream Delay Variation 393 respectively, as defined in RFC 7471 [RFC7471]. 395 Reserved: These fields are reserved for future use. It SHOULD 396 be set to 0 when sent and MUST be ignored when received. 398 Delay Variation: Delay Variation of the local TE link along 399 the route of the LSP, encoded as 24-bit integer, as defined 400 in RFC 7471 [RFC7471]. When set to the maximum value 401 16,777,215 (16.777215 sec), the delay variation is at least 402 that value and may be larger. 404 4. Signaling Procedures 406 As signaling procedure for cost, delay and delay variation 407 collection is similar, many parts of this section are written 408 such that they apply equally to cost, delay and delay variation 409 collection. There is also very strong similarity of these 410 procedures with SRLG recording [DRAFT-SRLG-RECORDING]. 412 The ingress node of the LSP MUST be capable of indicating 413 whether the Cost and/ or Delay and/ or Delay Variation 414 information of the LSP is to be collected during the signaling 415 procedure of setting up an LSP. 417 Internet-Draft draft-ietf-teas-te-metric-recording-04.txt 419 A node MUST NOT push Cost and/ or Delay and/ or Delay Variation 420 sub-object(s) in the RECORD_ROUTE without also pushing either an 421 IPv4 sub-object, an IPv6 sub-object, an Unnumbered Interface ID 422 sub-object or a Path Key sub-object or an SRLG sub-object. 424 As described in RFC 3209 [RFC3209], the RECORD_ROUTE object is 425 managed as a stack. The Cost and/ or Delay and/ or Delay 426 Variation sub-object(s) SHOULD be pushed by the node before the 427 node IP address or link identifier. These sub-object(s) SHOULD 428 be pushed after the Attribute sub-object, if present, and after 429 the LABEL sub-object, if requested, and after the SRLG sub- 430 object, if requested. These sub-object(s) MUST be pushed within 431 the hop to which it applies. 433 RFC 5553 [RFC5553] describes mechanisms to carry a PKS (Path Key 434 Sub-object) in the RRO so as to facilitate confidentiality in 435 the signaling of inter-domain TE LSPs, and allows the path 436 segment that needs to be hidden (that is, a Confidential Path 437 Segment (CPS)) to be replaced in the RRO with a PKS. If the CPS 438 contains Cost and/ or Delay and/ or Delay Variation Sub-objects, 439 these MAY be retained in the RRO by adding them again after the 440 PKS Sub-object in the RRO. The CPS is defined in RFC 5520 441 [RFC5520]. 443 The rules of the processing of the LSP_REQUIRED_ATTRIBUTES, 444 LSP_ATTRIBUTE and ROUTE_RECORD Objects are not changed. 446 4.1. Cost, Delay and Delay Variation Collection 448 Per RFC 3209 [RFC3209], an ingress node initiates the recording 449 of the route information of an LSP by adding a RRO to a Path 450 message. If an ingress node also desires Cost and/or Delay 451 and/or Delay Variation recording, it MUST set the appropriate 452 flag(s) in the Attribute Flags TLV which MAY be carried either 453 in an LSP_REQUIRED_ATTRIBUTES Object when the collection is 454 mandatory, or in an LSP_ATTRIBUTES Object when the collection is 455 desired, but not mandatory. 457 When a node receives a Path message which carries an 458 LSP_REQUIRED_ATTRIBUTES Object with the Cost Collection Flag 459 set, if local policy determines that the Cost information is not 460 to be provided to the endpoints, it MUST return a PathErr 461 message with: 463 o Error Code 2 (policy) and 465 o Error subcode "Cost Recording Rejected" (value to be 466 assigned by IANA) 468 to reject the Path message. Similarly, when a node receives a 469 Path message which carries an LSP_REQUIRED_ATTRIBUTES Object 470 with the Delay Collection Flag set, if local policy determines 471 Internet-Draft draft-ietf-teas-te-metric-recording-04.txt 473 that the Delay information is not to be provided to the 474 endpoints, it MUST return a PathErr message with: 476 o Error Code 2 (policy) and 478 o Error subcode "Delay Recording Rejected" (value to be 479 assigned by IANA) 481 to reject the Path message. Likewise, when a node receives a 482 Path message which carries an LSP_REQUIRED_ATTRIBUTES Object 483 with the Delay Variation Collection Flag set, if local policy 484 determines that the Delay Variation information is not to be 485 provided to the endpoints, it MUST return a PathErr message 486 with: 488 o Error Code 2 (policy) and 490 o Error subcode "Delay Variation Recording Rejected" (value 491 to be assigned by IANA) 493 to reject the Path message. 495 When a node receives a Path message which carries an 496 LSP_ATTRIBUTES Object and the Cost and/or Delay and/or Delay 497 Variation Collection Flag set, if local policy determines that 498 the corresponding information is not to be provided to the 499 endpoints, or the information is not known, the Path message 500 SHOULD NOT be rejected due to the recording restriction and the 501 Path message SHOULD be forwarded without any Cost and/or Delay 502 and/or Delay Variation sub-object(s) in the RRO of the 503 corresponding outgoing Path message. 505 If local policy permits the recording of the Cost and/or Delay 506 and/or Delay Variation information, the processing node SHOULD 507 add corresponding information for the local TE link, as defined 508 below, to the RRO of the corresponding outgoing Path message. 509 The A-bit for the Delay MUST be set as described in RFC 7471 510 [RFC7471]. Similarly, the A-bit for the Delay Variation MUST be 511 set as described in RFC 7471 [RFC7471]. It then forwards the 512 Path message to the next node in the downstream direction. The 513 processing node MUST retain a record of the Cost and/ or Delay 514 and/ or Delay Variation Collection request for reference during 515 Resv processing described below. 517 If the addition of Cost and/or Delay and/or Delay Variation 518 information to the RRO would result in the RRO exceeding its 519 maximum possible size or becoming too large for the Path message 520 to contain it, the requested information MUST NOT be added. If 521 the Cost and/or Delay and/or Delay Variation collection request 522 was contained in an LSP_REQUIRED_ATTRIBUTES Object, the 523 processing node MUST behave as specified by RFC 3209 [RFC3209] 524 and drop the RRO from the Path message entirely. If the Cost 525 Internet-Draft draft-ietf-teas-te-metric-recording-04.txt 527 and/or Delay and/or Delay Variation collection request was 528 contained in an LSP_ATTRIBUTES Object, the processing node MAY 529 omit some or all of the corresponding information from the RRO; 530 otherwise it MUST behave as specified by RFC 3209 [RFC3209] and 531 drop the RRO from the Path message entirely. 533 Following the steps described above, the intermediate nodes of 534 the LSP can collect the Cost and/or Delay and/or Delay Variation 535 information in the RRO during the processing of the Path message 536 hop by hop. When the Path message arrives at the egress node, 537 the egress node receives the corresponding information in the 538 RRO. 540 Per RFC 3209 [RFC3209], when issuing a Resv message for a Path 541 message, which contains an RRO, an egress node initiates the RRO 542 process by adding an RRO to the outgoing Resv message. The 543 processing for RROs contained in Resv messages then mirrors that 544 of the Path messages. 546 When a node receives a Resv message for an LSP for which Cost 547 and/or Delay and/or Delay Variation Collection was specified, 548 then when local policy allows recording of the requested 549 information, the node SHOULD add corresponding information, to 550 the RRO of the outgoing Resv message, as specified below. The 551 A-bit for the Delay MUST be set as described in RFC 7471 552 [RFC7471]. Similarly, the A-bit for the Delay Variation MUST be 553 set as described in RFC 7471 [RFC7471]. When the Resv message 554 arrives at the ingress node, the ingress node can extract the 555 requested information from the RRO in the same way as the egress 556 node. 558 Note that a link's Cost and/ or Delay and/ or Delay Variation 559 information for the upstream direction cannot be assumed to be 560 the same as that in the downstream. 562 o For Path and Resv messages for a unidirectional LSP, a node 563 SHOULD include Cost and/ or Delay and/ or Delay Variation 564 sub-objects in the RRO for the downstream data link only. 566 o For Path and Resv messages for a bidirectional LSP, a node 567 SHOULD include Cost and/ or Delay and/ or Delay Variation 568 sub-objects in the RRO for both the upstream data link and 569 the downstream data link from the local node. In this 570 case, the node MUST include the metric information in the 571 same order for both Path messages and Resv messages. That 572 is, the Cost and/ or Delay and/ or Delay Variation sub- 573 object(s) for the upstream link is added to the RRO before 574 the corresponding sub-object for the downstream link. 576 If Cost and/ or Delay and/ or Delay Variation data is added 577 for both the upstream and downstream links, the two sets of 578 the data MUST be added in separate corresponding sub- 579 Internet-Draft draft-ietf-teas-te-metric-recording-04.txt 581 object(s). A single Cost or Delay or Delay Variation sub- 582 object MUST NOT contain a mixture of the applicable data 583 for upstream and downstream directions. When adding a Cost 584 or Delay or Delay Variation sub-object to an RRO, the D-bit 585 MUST be set appropriately to indicate the direction of the 586 TE Link. If the same value applies in both directions, it 587 SHOULD be added to both the corresponding upstream and 588 downstream sub-objects. 590 Based on the local policy, a transit node may edit a Path or 591 Resv RRO to remove route information (e.g. node or interface 592 identifier information) before forwarding it. A node that does 593 this SHOULD summarize the cost, Delay and Delay Variation data. 594 How a node that performs the RRO edit operation calculates the 595 Cost and/ or Delay and/or Delay variation metric is beyond the 596 scope of this document. 598 A node SHOULD NOT add Cost or Delay or Delay Variation 599 information without an explicit request for the corresponding 600 information being made by the ingress node in the Path message. 602 4.2. Metric Update 604 When the Cost and/or Delay and/or Delay Variation information of 605 a link is changed, the endpoints of LSPs using that link need to 606 be aware of the changes. When a change to Cost or Delay or 607 Delay Variation information associated with a link occurs, the 608 procedures defined in Section 4.4.3 of RFC 3209 [RFC3209] MUST 609 be used to refresh the corresponding metric information if the 610 change is to be communicated to other nodes according to the 611 local node's policy. If local policy is that the Cost and/or 612 Delay and/or Delay Variation change SHOULD be suppressed or 613 would result in no change to the previously signaled 614 information, the node SHOULD NOT send an update. 616 4.3. Domain Boundaries 618 If mandated by local policy, a node MAY remove Cost and/or Delay 619 and/or Delay Variation information from any RRO in a Path or 620 Resv message being processed. A node that does this SHOULD 621 summarize the Cost, Delay and Delay Variation data. How a node 622 that performs the RRO edit operation calculates the Cost, Delay 623 and/or Delay variation metric is beyond the scope of this 624 document. 626 4.4. Endpoint processing 628 Based on the procedures described above, the endpoints can get 629 the Cost and/or Delay and/or Delay Variation information 630 automatically. Then the endpoints can for instance advertise it 631 as a TE link to the routing instance based on the procedure 632 described in [RFC6107] and configure the corresponding TE metric 633 Internet-Draft draft-ietf-teas-te-metric-recording-04.txt 635 information of the Forwarding Adjacency (FA) or Routing 636 Adjacency (RA) automatically. How the end point uses the 637 collected information is outside the scope of this document. 639 The ingress and egress nodes of a LSP may calculate the end-to- 640 end Cost, Delay and/or Delay variation properties of the LSP 641 from the supplied values in the Resv or Path RRO, respectively. 643 Typically, Cost and Delay are additive metrics, but Delay 644 variation is not an additive metric. The means by which the 645 ingress and egress nodes compute the end-to-end Cost, Delay and 646 Delay variation metric from information recorded in the RRO is a 647 local decision and is beyond the scope of this document. 649 Based on the local policy, the ingress and egress nodes can 650 advertise the calculated end-to-end Cost, Delay and/or Delay 651 variation properties of the FA or RA LSP in TE link 652 advertisement to the routing instance based on the procedure 653 described in RFC 7471 [RFC7471], [DRAFT-ISIS-TE-METRIC]. 655 4.5. Compatibility 657 A node that does not recognize the Cost and/or Delay and/or 658 Delay Variation Collection Flag in the Attribute Flags TLV is 659 expected to proceed as specified in RFC 5420 [RFC5420]. 660 Specifically, the node is expected to pass the TLV on unaltered 661 if it appears in a LSP_ATTRIBUTES object. On the other hand, if 662 the TLV appears in a LSP_REQUIRED_ATTRIBUTES object, the node is 663 expected to reject the Path message with the Error Code and 664 Value defined in RFC 5420 [RFC5420]. 666 A node that does not recognize the Cost and/or Delay and/or 667 Delay Variation RRO sub-object is expected to behave as 668 specified in RFC 3209 [RFC3209]: unrecognized sub-objects are to 669 be ignored and passed on unchanged. 671 5. Manageability Considerations 673 5.1. Policy Configuration 675 In a border node of inter-domain or inter-layer network, the 676 following Cost and/or Delay and/or Delay Variation processing 677 policy SHOULD be capable of being configured: 679 o Whether the node is allowed to participate in Cost or Delay 680 or Delay Variation collection. 682 o Whether the node should notify changes to collected Cost 683 and/ or Delay and/ or Delay Variation information to 684 endpoint nodes as described in section 4.2. 686 Internet-Draft draft-ietf-teas-te-metric-recording-04.txt 688 o Whether the Cost and/or Delay and/or Delay Variation of the 689 domain or specific layer network can be exposed to the 690 nodes outside the domain or layer network, or whether they 691 SHOULD be summarized, mapped to values that are 692 comprehensible to nodes outside the domain or layer 693 network, or removed entirely. 695 A node using RFC 5553 [RFC5553] and PKS MAY apply the same 696 policy. 698 6. Security Considerations 700 This document builds on the mechanisms defined in [RFC3473], 701 which also discusses related security measures. In addition, 702 [RFC5920] provides an overview of security vulnerabilities and 703 protection mechanisms for the GMPLS control plane. The 704 procedures defined in this document permit the transfer of Cost 705 and/or Delay and/or Delay Variation data between layers or 706 domains during the signaling of LSPs, subject to policy at the 707 layer or domain boundary. It is recommended that domain/layer 708 boundary policies take the implications of releasing Cost and/or 709 Delay and/or Delay Variation information into consideration and 710 behave accordingly during LSP signaling. 712 7. IANA Considerations 714 7.1. RSVP Attribute Bit Flags 716 IANA has created a registry and manages the space of the 717 Attribute bit flags of the Attribute Flags TLV, as described in 718 section 11.3 of RFC 5420 [RFC5420], in the "Attribute Flags" 719 section of the "Resource Reservation Protocol-Traffic 720 Engineering (RSVP-TE) Parameters" registry located in 721 http://www.iana.org/assignments/rsvp-te- parameters". 723 This document introduces the following three new Attribute Bit 724 Flags: 726 Bit No Name Attribute Attribute RRO Reference 728 Flags Path Flags Resv 730 ----------- ---------- ---------- ----------- --- ------- 732 TBA by Cost Yes No Yes This I-D 733 IANA Collection 734 Flag 736 TBA by Delay Yes No Yes This I-D 737 IANA Collection 738 Flag 739 Internet-Draft draft-ietf-teas-te-metric-recording-04.txt 741 TBA by Delay Yes No Yes This I-D 742 IANA Variation 743 Collection 744 Flag 746 7.2. ROUTE_RECORD sub-object 748 IANA manages the "RSVP PARAMETERS" registry located at 749 http://www.iana.org/assignments/rsvp-parameters. This document 750 introduces the following three new RRO sub-object: 752 Type Name Reference 754 --------- ---------------------- --------- 756 TBA by IANA Cost sub-object This I-D 758 TBA by IANA Delay sub-object This I-D 760 TBA by IANA Delay Variation sub-object This I-D 762 7.3. Policy Control Failure Error subcodes 764 IANA manages the assignments in the "Error Codes and Globally- 765 Defined Error Value Sub-Codes" section of the "RSVP PARAMETERS" 766 registry located at http://www.iana.org/assignments/rsvp- 767 parameters. This document introduces the following three new 768 Policy Control Failure Error sub-code: 770 Value Description Reference 771 ----- ----------- --------- 773 TBA by IANA Cost Recoding Rejected This I-D 775 TBA by IANA Delay Recoding Rejected This I-D 777 TBA by IANA Delay Variation Recoding Rejected This I-D 779 8. Acknowledgments 781 Authors would like to thank Ori Gerstel, Gabriele Maria 782 Galimberti, Luyuan Fang and Walid Wakim for their review 783 comments. 785 Internet-Draft draft-ietf-teas-te-metric-recording-04.txt 787 9. References 789 9.1. Normative References 791 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 792 Requirement Levels", BCP 14, RFC 2119, March 1997. 794 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 795 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 796 LSP Tunnels", RFC 3209, December 2001. 798 [RFC3473] Berger, L., "Generalized Multi-Protocol Lab Switching 799 (GMPLS) Signaling Resource ReserVation Protocol- 800 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 801 January 2003. 803 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and 804 A. Ayyangarps, "Encoding of Attributes for MPLS LSP 805 Establishment Using Resource Reservation Protocol 806 Traffic Engineering (RSVP-TE)", RFC 5420, February 807 2009. 809 [RFC7471] S. Giacalone, D. Ward, J. Drake, A. Atlas, S. 810 Previdi., "OSPF Traffic Engineering (TE) Metric 811 Extensions", RFC 7471, March 2015. 813 [DRAFT-ISIS-TE-METRIC] S. Previdi, S. Giacalone, D. Ward, J. 814 Drake, A. Atlas, C. Filsfils, "IS-IS Traffic 815 Engineering (TE) Metric Extensions", draft-ietf-isis- 816 te-metric-extensions, work in progress. 818 9.2. Informative References 820 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 821 "Generalized Multiprotocol Label Switching (GMPLS) 822 User-Network Interface (UNI): Resource ReserVation 823 Protocol-Traffic Engineering (RSVP-TE) Support for the 824 Overlay Model", RFC 4208, October 2005. 826 [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation 827 Protocol (RSVP) -- Version 1 Message Processing 828 Rules", RFC 2209, September 1997. 830 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 831 Networks", RFC 5920, July 2010. 833 [DRAFT-SRLG-RECORDING] F. Zhang, O. Gonzalez de Dios, M. 834 Hartley, Z. Ali, C. Margaria,, "RSVP-TE Extensions for 835 Collecting SRLG Information", draft-ietf-teas-rsvp-te- 836 srlg-collect.txt, work in progress. 838 Authors' Addresses 839 Internet-Draft draft-ietf-teas-te-metric-recording-04.txt 841 Zafar Ali 842 Cisco Systems, Inc. 843 Email: zali@cisco.com 845 George Swallow 846 Cisco Systems, Inc. 847 swallow@cisco.com 849 Clarence Filsfils 850 Cisco Systems, Inc. 851 cfilsfil@cisco.com 853 Matt Hartley 854 Cisco Systems 855 Email: mhartley@cisco.com 857 Kenji Kumaki 858 KDDI Corporation 859 Email: ke-kumaki@kddi.com 861 Rudiger Kunze 862 Deutsche Telekom AG 863 Ruediger.Kunze@telekom.de