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