idnits 2.17.1 draft-ietf-teas-te-metric-recording-07.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 10 longer pages, the longest (page 4) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' scope of this document.' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7. IANA Considerations' ) ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 25 instances of lines with control characters in the document. 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 (June 21, 2018) is 2136 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2119' on line 810 looks like a reference -- Missing reference section? 'RFC7471' on line 828 looks like a reference -- Missing reference section? 'DRAFT-ISIS-TE-METRIC' on line 832 looks like a reference -- Missing reference section? 'RFC4208' on line 839 looks like a reference -- Missing reference section? 'RFC8001' on line 852 looks like a reference -- Missing reference section? 'RFC5420' on line 822 looks like a reference -- Missing reference section? 'RFC3209' on line 813 looks like a reference -- Missing reference section? 'RFC5553' on line 719 looks like a reference -- Missing reference section? 'RFC5520' on line 461 looks like a reference -- Missing reference section? 'RFC6107' on line 655 looks like a reference -- Missing reference section? 'RFC3473' on line 817 looks like a reference -- Missing reference section? 'RFC5920' on line 849 looks like a reference -- Missing reference section? 'RFC2209' on line 845 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). 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: December 20, 2018 Matt Hartley 6 Cisco Systems 7 Kenji Kumaki 8 KDDI Corporation 9 Ruediger Kunze 10 Deutsche Telekom AG 11 June 21, 2018 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-07 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 https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 20, 2018. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) 57 controlling the copyright in such materials, this document may not 58 be modified outside the IETF Standards Process, and derivative 59 works of it may not be created outside the IETF Standards Process, 60 except to format it for publication as an RFC or to translate it 61 into languages other than English. 63 Abstract 65 There are many scenarios in which Traffic Engineering (TE) metrics 66 such as cost, delay and delay variation associated with the TE link 67 formed by Label Switched Path (LSP) are not available to the 68 ingress and egress nodes. This draft provides extensions for the 69 Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) to 70 support automatic collection of cost, delay and delay variation 71 information for the TE link formed by a LSP. 73 Conventions used in this document 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 77 this document are to be interpreted as described in RFC 2119 78 [RFC2119]. 80 Table of Contents 82 1. Introduction ......................................... 3 83 1.1. Use Cases ......................................... 4 84 1.1.1. GMPLS ...................................... 4 85 1.1.2. Inter-area tunnels with loose-hops ......... 4 86 2. RSVP-TE Requirement .................................. 4 87 2.1. Cost, Delay and Delay Variation Collection 88 Indication ......................................... 4 89 2.2. Cost, Delay and Delay Variation Collection ......... 5 90 2.3. Cost, Delay and Delay Variation Update ............. 5 91 2.4. Cost Definition .................................... 5 92 3. Encoding ............................................. 5 93 3.1. Cost, Delay and Delay Variation Collection Flags ... 5 94 3.2. RRO Cost Subobject ................................. 6 95 3.3. RRO Delay Subobject ................................ 7 96 3.4. RRO Delay Variation Subobject ...................... 7 97 4. Signaling Procedures ................................. 8 98 4.1. Cost, Delay and Delay Variation Collection ......... 9 99 4.2. Metric Update ......................................12 100 4.3. Domain Boundaries ..................................12 101 4.4. Endpoint processing ................................12 102 4.5. Compatibility ......................................13 104 Internet-Draft draft-ietf-teas-te-metric-recording-07.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 114 8. References ...........................................16 115 8.1. Normative References ...............................16 116 8.2. Informative References .............................16 117 Acknowledgements .........................................16 118 Contributors .............................................17 119 Authors' Addresses .......................................17 121 1. Introduction 123 In certain networks, such as financial information networks, 124 network performance information (e.g. delay, delay variation) is 125 becoming as critical to data path selection as other metrics 126 [RFC7471], [DRAFT-ISIS-TE-METRIC]. If cost, delay or delay 127 variation associated with a Forwarding Adjacency (FA) or a 128 Routing Adjacency (RA) LSP is not available to the ingress or 129 egress node, it cannot be advertised as an attribute of the TE 130 link (FA or RA). There are scenarios in packet and optical 131 networks where the route information of an LSP may not be 132 provided to the ingress node for confidentiality reasons and/or 133 the ingress node may not run the same routing instance as the 134 intermediate nodes traversed by the path. Similarly, there are 135 scenarios in which measuring delay and/ or delay variation on a 136 TE link formed by a LSP is not supported. In such scenarios, the 137 ingress node cannot determine the cost, delay and delay 138 variation properties of the LSP's route. 140 One possible way to address this issue is to configure cost, 141 delay and delay variation values manually. However, in the event 142 of an LSP being rerouted (e.g. due to re-optimization), such 143 configuration information may become invalid. Consequently, in 144 cases where that an LSP is advertised as a TE-Link, the ingress 145 and/or egress nodes cannot provide the correct delay, delay 146 variation and cost information associated with the TE-Link 147 automatically. 149 In summary, there is a requirement for the ingress and egress 150 nodes to learn the cost, delay and delay variation information 151 of the TE link formed by a LSP. This document provides a 152 mechanism to collect the cost, delay and delay variation 153 information of a LSP, which can then be advertised as properties 154 of the TE-link formed by that LSP. Note that specification of 155 the use of the collected cost, delay and delay variation 156 information is outside the scope of this document. 158 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 160 1.1. Use Cases 162 This section describes some of the use cases for the TE metric 163 recording. 165 1.1.1. GMPLS 167 In Generalized Multi-Protocol Label Switching (GMPLS) networks 168 signaling bidirectional LSPs, the egress node cannot determine 169 the cost, delay and delay variation properties of the LSP path. 170 A multi-domain or multi-layer network is an example of such 171 networks. A GMPLS User-Network Interface (UNI) [RFC4208] is also 172 an example of such networks. 174 1.1.2. Inter-area tunnels with loose-hops 176 When a LSP is established over multiple IGP-areas using loose 177 hops in the ERO, the ingress node may only has knowledge of the 178 first IGP-area traversed by the LSP. In this case, it cannot 179 determine the cost, delay and delay variation properties of the 180 LSP path. 182 2. RSVP-TE Requirement 184 This section outlines RSVP-TE requirements for the support of 185 the automatic collection of cost, delay and delay variation 186 information of an LSP. 188 As RSVP-TE requirements for cost, delay and delay variation 189 collection are similar, many parts of this section are written 190 such that they apply equally to cost, delay and delay variation 191 collection. There is also very strong similarity of these RSVP- 192 requirements with SRLG recording [RFC8001]. 194 The Cost, Delay, Delay variation collection process takes place 195 in three stages: 197 o The LSP's ingress node requests that Cost, Delay, Delay 198 Variation collection should take place; 200 o Cost, Delay, Delay Variation data is added to the Path and 201 Resv ROUTE_RECORD Objects(RROs) by all nodes during signaling; 203 o Changes to previously signaled Cost, Delay, Delay variation 204 data are made by sending updated Path and Resv messages as 205 required. 207 2.1. Cost, Delay and Delay Variation Collection Indication 209 The ingress node of the LSP needs be capable of indicating 210 whether the cost and/or delay and/ or delay variation 211 information of the LSP is to be collected during the signaling 212 procedure of setting up an LSP. A separate collection indication 213 flag for each of these attributes is required. There is no need 214 for cost and/or delay and/ or delay variation to be collected 215 without an explicit request for it being made by the ingress 216 node. 218 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 220 It may be preferable for the cost and/ or delay and/ or delay 221 variation collection request to be understood by all nodes along 222 the LSP's path, or it may be more important for the LSP to be 223 established successfully even if it traverses nodes that cannot 224 supply the requested information or have not implemented the 225 procedures specified in this document. It is desirable for the 226 ingress node to make the cost, delay and delay variation 227 collection request in a manner that best suits its own policy. 229 2.2. Cost, Delay and Delay Variation Collection 231 If requested, the cost and/or delay and/ or delay variation 232 information is collected during the setup of an LSP. Each of the 233 cost, delay or delay variation can be collected independently. 234 Cost and/ or delay and/ or delay variation information is for 235 each hop is added to the Path RRO during Path message 236 processing. The corresponding information is also added to the 237 Resv RRO during Resv processing at each hop. The endpoints of 238 the LSP can use the collected information, for example, for 239 routing, sharing and TE link configuration purposes. 241 2.3. Cost, Delay and Delay Variation Update 243 When the cost and/or delay and/ or delay variation information 244 of an existing LSP for which corresponding information was 245 collected during signaling changes, the relevant nodes of the 246 LSP need to be capable of updating the associated information of 247 the LSP. This means that the signaling procedure needs to be 248 capable of updating the new cost and/or delay and/ or delay 249 variation information. 251 2.4. Cost Definition 253 Although the terms delay and delay variation are well 254 understood, "cost" may be ambiguous; in particular, in the 255 context of a LSP that traverse nodes and links operated by 256 different entities, there may be no common definition of cost. 257 However, there are situations in which the entire LSP may be 258 within a single AS (e.g. inter-area LSPs) in which cost 259 discovery is useful. 261 The precise meaning and interpretation of numerical costs is a 262 matter for the network operator. For the purposes of this 263 document, two constraints are assumed: 265 . A higher cost represents an inferior path. 267 . Simple addition of costs for different sections of a path 268 must make sense. 270 3. Encoding 272 3.1. Cost, Delay and Delay Variation Collection Flags 274 In order to indicate nodes that cost and/or Delay and/or Delay 275 variation collection is desired, this document defines the 276 following new flags in the Attribute Flags TLV (see RFC 5420 278 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 280 [RFC5420]). A node that wishes to indicate Cost and/or Delay 281 and/or Delay Variation collection is desired MUST set 282 corresponding flag in Attribute Flags TLV in an 283 LSP_REQUIRED_ATTRIBUTES object (if collection is mandatory) 284 or LSP_ATTRIBUTES Object(if collection is desired but not mandatory): 286 - Cost Collection flag (Bit number to be assigned by IANA) 288 - Delay Collection flag (Bit number to be assigned by IANA) 290 - Delay Variation Collection flag (Bit number to be assigned by 291 IANA) 293 The Cost, Delay and Delay Variation Collection flags are 294 meaningful on a Path message. If the Cost Collection flag is 295 set to 1, it means that the cost information SHOULD be reported 296 to the ingress and egress node along the setup of the LSP. 297 Similarly, if the Delay Collection flag is set to 1, it means 298 that the Delay information SHOULD be reported to the ingress and 299 egress node along the setup of the LSP. Likewise, if the Delay 300 Variation Collection flag is set to 1, it means that the Delay 301 Variation information SHOULD be reported to the ingress and 302 egress node along the setup of the LSP. 304 The rules of the processing of the Attribute Flags TLV are not 305 changed. 307 3.2. RRO Cost Subobject 309 This document defines a new RRO sub-object (ROUTE_RECORD sub- 310 object) to record the cost information of the LSP. Its format 311 is modeled on the RRO sub-objects defined in RFC 3209 [RFC3209]. 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Type | Length |D| Reserved (must be zero) | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Cost | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Type: The type of the sub-object (value to be assigned by 322 IANA). 324 Length: The Length field contains the total length of the 325 sub-object in bytes, including the Type and Length fields. 326 The Length value is set to 8. 328 Direction bit (D-bit) 330 If not set, the cost contained in this sub-object applies to 331 the downstream direction. If set, it applies to the upstream 332 direction. 334 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 336 Reserved: This field is reserved for future use. It MUST be 337 set to 0 on transmission and MUST be ignored when received. 339 Cost: Cost of the local TE link along the route of the LSP. 341 3.3. RRO Delay Subobject 343 This document defines a new RRO sub-object (ROUTE_RECORD sub- 344 object) to record the delay information of the LSP. Its format 345 is modeled on the RRO sub-objects defined in RFC 3209 [RFC3209]. 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Type | Length |D| Reserved (must be zero) | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 |A| Reserved | Delay | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Type: The type of the sub-object (value to be assigned by 356 IANA). 358 Length: The Length field contains the total length of the 359 sub-object in bytes, including the Type and Length fields. 360 The Length value is set to 8. 362 Direction bit (D-bit) 364 If not set, the Delay contained in this sub-object applies to 365 the downstream direction. If set, it applies to the upstream 366 direction. 368 A-bit: These fields represent the Anomalous (A) bit 369 associated with the Downstream and Upstream Delay 370 respectively, as defined in RFC 7471 [RFC7471]. 372 Reserved: These fields are reserved for future use. They MUST 373 be set to 0 when sent and MUST be ignored when received. 375 Delay: Delay of the local TE link along the route of the LSP, 376 encoded as 24-bit integer, as defined in RFC 7471 [RFC7471]. 377 When set to the maximum value 16,777,215 (16.777215 sec), the 378 delay is at least that value and may be larger. 380 3.4. RRO Delay Variation Subobject 382 This document defines a new RRO sub-object (ROUTE_RECORD sub- 383 object) to record the delay variation information of the LSP. 385 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 387 Its format is modeled on the RRO sub-objects defined in RFC 3209 388 [RFC3209]. 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Type | Length |D| Reserved (must be zero) | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 |A| Reserved | Delay Variation | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 Type: The type of the sub-object (value to be assigned by 399 IANA). 401 Length: The Length field contains the total length of the 402 sub-object in bytes, including the Type and Length fields. 403 The Length value is set to 8. 405 Direction bit (D-bit) 407 If not set, the Delay Variation contained in this sub-object 408 applies to the downstream direction. If set, it applies to 409 the upstream direction. 411 A-bit: These fields represent the Anomalous (A) bit 412 associated with the Downstream and Upstream Delay Variation 413 respectively, as defined in RFC 7471 [RFC7471]. 415 Reserved: These fields are reserved for future use. It SHOULD 416 be set to 0 when sent and MUST be ignored when received. 418 Delay Variation: Delay Variation of the local TE link along 419 the route of the LSP, encoded as 24-bit integer, as defined 420 in RFC 7471 [RFC7471]. When set to the maximum value 421 16,777,215 (16.777215 sec), the delay variation is at least 422 that value and may be larger. 424 4. Signaling Procedures 426 As signaling procedure for cost, delay and delay variation 427 collection is similar, many parts of this section are written 428 such that they apply equally to cost, delay and delay variation 429 collection. There is also very strong similarity of these 430 procedures with SRLG recording [RFC8001]. 432 The ingress node of the LSP MUST be capable of indicating 433 whether the Cost and/ or Delay and/ or Delay Variation 434 information of the LSP is to be collected during the signaling 435 procedure of setting up an LSP. 437 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 439 A node MUST NOT push Cost and/ or Delay and/ or Delay Variation 440 sub-object(s) in the RECORD_ROUTE without also pushing either an 441 IPv4 sub-object, an IPv6 sub-object, an Unnumbered Interface ID 442 sub-object or a Path Key sub-object or an SRLG sub-object. 444 As described in RFC 3209 [RFC3209], the RECORD_ROUTE object is 445 managed as a stack. The Cost and/ or Delay and/ or Delay 446 Variation sub-object(s) SHOULD be pushed by the node before the 447 node IP address or link identifier. These sub-object(s) SHOULD 448 be pushed after the Attribute sub-object, if present, and after 449 the LABEL sub-object, if requested, and after the SRLG sub- 450 object, if requested. These sub-object(s) MUST be pushed within 451 the hop to which it applies. 453 RFC 5553 [RFC5553] describes mechanisms to carry a PKS (Path Key 454 Sub-object) in the RRO so as to facilitate confidentiality in 455 the signaling of inter-domain TE LSPs, and allows the path 456 segment that needs to be hidden (that is, a Confidential Path 457 Segment (CPS)) to be replaced in the RRO with a PKS. If the CPS 458 contains Cost and/ or Delay and/ or Delay Variation Sub-objects, 459 these MAY be retained in the RRO by adding them again after the 460 PKS Sub-object in the RRO. The CPS is defined in RFC 5520 461 [RFC5520]. 463 The rules of the processing of the LSP_REQUIRED_ATTRIBUTES, 464 LSP_ATTRIBUTE and ROUTE_RECORD Objects are not changed. 466 4.1. Cost, Delay and Delay Variation Collection 468 Per RFC 3209 [RFC3209], an ingress node initiates the recording 469 of the route information of an LSP by adding a RRO to a Path 470 message. If an ingress node also desires Cost and/or Delay 471 and/or Delay Variation recording, it MUST set the appropriate 472 flag(s) in the Attribute Flags TLV which MAY be carried either 473 in an LSP_REQUIRED_ATTRIBUTES Object when the collection is 474 mandatory, or in an LSP_ATTRIBUTES Object when the collection is 475 desired, but not mandatory. 477 When a node receives a Path message which carries an 478 LSP_REQUIRED_ATTRIBUTES Object with the Cost Collection Flag 479 set, if local policy determines that the Cost information is not 480 to be provided to the endpoints, it MUST return a PathErr 481 message with: 483 o Error Code 2 (policy) and 485 o Error subcode "Cost Recording Rejected" (value to be 486 assigned by IANA) 488 to reject the Path message. Similarly, when a node receives a 489 Path message which carries an LSP_REQUIRED_ATTRIBUTES Object 490 with the Delay Collection Flag set, if local policy determines 492 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 494 that the Delay information is not to be provided to the 495 endpoints, it MUST return a PathErr message with: 497 o Error Code 2 (policy) and 499 o Error subcode "Delay Recording Rejected" (value to be 500 assigned by IANA) 502 to reject the Path message. Likewise, when a node receives a 503 Path message which carries an LSP_REQUIRED_ATTRIBUTES Object 504 with the Delay Variation Collection Flag set, if local policy 505 determines that the Delay Variation information is not to be 506 provided to the endpoints, it MUST return a PathErr message 507 with: 509 o Error Code 2 (policy) and 511 o Error subcode "Delay Variation Recording Rejected" (value 512 to be assigned by IANA) 514 to reject the Path message. 516 When a node receives a Path message which carries an 517 LSP_ATTRIBUTES Object and the Cost and/or Delay and/or Delay 518 Variation Collection Flag set, if local policy determines that 519 the corresponding information is not to be provided to the 520 endpoints, or the information is not known, the Path message 521 SHOULD NOT be rejected due to the recording restriction and the 522 Path message SHOULD be forwarded without any Cost and/or Delay 523 and/or Delay Variation sub-object(s) in the RRO of the 524 corresponding outgoing Path message. 526 If local policy permits the recording of the Cost and/or Delay 527 and/or Delay Variation information, the processing node SHOULD 528 add corresponding information for the local TE link, as defined 529 below, to the RRO of the corresponding outgoing Path message. 530 The A-bit for the Delay MUST be set as described in RFC 7471 531 [RFC7471]. Similarly, the A-bit for the Delay Variation MUST be 532 set as described in RFC 7471 [RFC7471]. It then forwards the 533 Path message to the next node in the downstream direction. The 534 processing node MUST retain a record of the Cost and/ or Delay 535 and/ or Delay Variation Collection request for reference during 536 Resv processing described below. 538 If the addition of Cost and/or Delay and/or Delay Variation 539 information to the RRO would result in the RRO exceeding its 540 maximum possible size or becoming too large for the Path message 541 to contain it, the requested information MUST NOT be added. If 542 the Cost and/or Delay and/or Delay Variation collection request 543 was contained in an LSP_REQUIRED_ATTRIBUTES Object, the 544 processing node MUST behave as specified by RFC 3209 [RFC3209] 545 and drop the RRO from the Path message entirely. If the Cost 547 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 549 and/or Delay and/or Delay Variation collection request was 550 contained in an LSP_ATTRIBUTES Object, the processing node MAY 551 omit some or all of the corresponding information from the RRO; 552 otherwise it MUST behave as specified by RFC 3209 [RFC3209] and 553 drop the RRO from the Path message entirely. 555 Following the steps described above, the intermediate nodes of 556 the LSP can collect the Cost and/or Delay and/or Delay Variation 557 information in the RRO during the processing of the Path message 558 hop by hop. When the Path message arrives at the egress node, 559 the egress node receives the corresponding information in the 560 RRO. 562 Per RFC 3209 [RFC3209], when issuing a Resv message for a Path 563 message, which contains an RRO, an egress node initiates the RRO 564 process by adding an RRO to the outgoing Resv message. The 565 processing for RROs contained in Resv messages then mirrors that 566 of the Path messages. 568 When a node receives a Resv message for an LSP for which Cost 569 and/or Delay and/or Delay Variation Collection was specified, 570 then when local policy allows recording of the requested 571 information, the node SHOULD add corresponding information, to 572 the RRO of the outgoing Resv message, as specified below. The 573 A-bit for the Delay MUST be set as described in RFC 7471 574 [RFC7471]. Similarly, the A-bit for the Delay Variation MUST be 575 set as described in RFC 7471 [RFC7471]. When the Resv message 576 arrives at the ingress node, the ingress node can extract the 577 requested information from the RRO in the same way as the egress 578 node. 580 Note that a link's Cost and/ or Delay and/ or Delay Variation 581 information for the upstream direction cannot be assumed to be 582 the same as that in the downstream. 584 o For Path and Resv messages for a unidirectional LSP, a node 585 SHOULD include Cost and/ or Delay and/ or Delay Variation 586 sub-objects in the RRO for the downstream data link only. 588 o For Path and Resv messages for a bidirectional LSP, a node 589 SHOULD include Cost and/ or Delay and/ or Delay Variation 590 sub-objects in the RRO for both the upstream data link and 591 the downstream data link from the local node. In this 592 case, the node MUST include the metric information in the 593 same order for both Path messages and Resv messages. That 594 is, the Cost and/ or Delay and/ or Delay Variation sub- 595 object(s) for the upstream link is added to the RRO before 596 the corresponding sub-object for the downstream link. 598 If Cost and/ or Delay and/ or Delay Variation data is added 599 for both the upstream and downstream links, the two sets of 600 the data MUST be added in separate corresponding sub- 602 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 604 object(s). A single Cost or Delay or Delay Variation sub- 605 object MUST NOT contain a mixture of the applicable data 606 for upstream and downstream directions. When adding a Cost 607 or Delay or Delay Variation sub-object to an RRO, the D-bit 608 MUST be set appropriately to indicate the direction of the 609 TE Link. If the same value applies in both directions, it 610 SHOULD be added to both the corresponding upstream and 611 downstream sub-objects. 613 Based on the local policy, a transit node may edit a Path or 614 Resv RRO to remove route information (e.g. node or interface 615 identifier information) before forwarding it. A node that does 616 this SHOULD summarize the cost, Delay and Delay Variation data. 617 How a node that performs the RRO edit operation calculates the 618 Cost and/ or Delay and/or Delay variation metric is beyond the 619 scope of this document. 621 A node SHOULD NOT add Cost or Delay or Delay Variation 622 information without an explicit request for the corresponding 623 information being made by the ingress node in the Path message. 625 4.2. Metric Update 627 When the Cost and/or Delay and/or Delay Variation information of 628 a link is changed, the endpoints of LSPs using that link need to 629 be aware of the changes. When a change to Cost or Delay or 630 Delay Variation information associated with a link occurs, the 631 procedures defined in Section 4.4.3 of RFC 3209 [RFC3209] MUST 632 be used to refresh the corresponding metric information if the 633 change is to be communicated to other nodes according to the 634 local node's policy. If local policy is that the Cost and/or 635 Delay and/or Delay Variation change SHOULD be suppressed or 636 would result in no change to the previously signaled 637 information, the node SHOULD NOT send an update. 639 4.3. Domain Boundaries 641 If mandated by local policy, a node MAY remove Cost and/or Delay 642 and/or Delay Variation information from any RRO in a Path or 643 Resv message being processed. A node that does this SHOULD 644 summarize the Cost, Delay and Delay Variation data. How a node 645 that performs the RRO edit operation calculates the Cost, Delay 646 and/or Delay variation metric is beyond the scope of this 647 document. 649 4.4. Endpoint processing 651 Based on the procedures described above, the endpoints can get 652 the Cost and/or Delay and/or Delay Variation information 653 automatically. Then the endpoints can for instance advertise it 654 as a TE link to the routing instance based on the procedure 655 described in [RFC6107] and configure the corresponding TE metric 657 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 659 information of the Forwarding Adjacency (FA) or Routing 660 Adjacency (RA) automatically. How the end point uses the 661 collected information is outside the scope of this document. 663 The ingress and egress nodes of a LSP may calculate the end-to- 664 end Cost, Delay and/or Delay variation properties of the LSP 665 from the supplied values in the Resv or Path RRO, respectively. 667 Typically, Cost and Delay are additive metrics, but Delay 668 variation is not an additive metric. The means by which the 669 ingress and egress nodes compute the end-to-end Cost, Delay and 670 Delay variation metric from information recorded in the RRO is a 671 local decision and is beyond the scope of this document. 673 Based on the local policy, the ingress and egress nodes can 674 advertise the calculated end-to-end Cost, Delay and/or Delay 675 variation properties of the FA or RA LSP in TE link 676 advertisement to the routing instance based on the procedure 677 described in RFC 7471 [RFC7471], [DRAFT-ISIS-TE-METRIC]. 679 4.5. Compatibility 681 A node that does not recognize the Cost and/or Delay and/or 682 Delay Variation Collection Flag in the Attribute Flags TLV is 683 expected to proceed as specified in RFC 5420 [RFC5420]. 684 Specifically, the node is expected to pass the TLV on unaltered 685 if it appears in a LSP_ATTRIBUTES object. On the other hand, if 686 the TLV appears in a LSP_REQUIRED_ATTRIBUTES object, the node is 687 expected to reject the Path message with the Error Code and 688 Value defined in RFC 5420 [RFC5420]. 690 A node that does not recognize the Cost and/or Delay and/or 691 Delay Variation RRO sub-object is expected to behave as 692 specified in RFC 3209 [RFC3209]: unrecognized sub-objects are to 693 be ignored and passed on unchanged. 695 5. Manageability Considerations 697 5.1. Policy Configuration 699 In a border node of inter-domain or inter-layer network, the 700 following Cost and/or Delay and/or Delay Variation processing 701 policy SHOULD be capable of being configured: 703 o Whether the node is allowed to participate in Cost or Delay 704 or Delay Variation collection. 706 o Whether the node should notify changes to collected Cost 707 and/ or Delay and/ or Delay Variation information to 708 endpoint nodes as described in section 4.2. 710 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 712 o Whether the Cost and/or Delay and/or Delay Variation of the 713 domain or specific layer network can be exposed to the 714 nodes outside the domain or layer network, or whether they 715 SHOULD be summarized, mapped to values that are 716 comprehensible to nodes outside the domain or layer 717 network, or removed entirely. 719 A node using RFC 5553 [RFC5553] and PKS MAY apply the same 720 policy. 722 6. Security Considerations 724 This document builds on the mechanisms defined in [RFC3473], 725 which also discusses related security measures. In addition, 726 [RFC5920] provides an overview of security vulnerabilities and 727 protection mechanisms for the GMPLS control plane. The 728 procedures defined in this document permit the transfer of Cost 729 and/or Delay and/or Delay Variation data between layers or 730 domains during the signaling of LSPs, subject to policy at the 731 layer or domain boundary. It is recommended that domain/layer 732 boundary policies take the implications of releasing Cost and/or 733 Delay and/or Delay Variation information into consideration and 734 behave accordingly during LSP signaling. 736 7. IANA Considerations 738 7.1. RSVP Attribute Bit Flags 740 IANA has created a registry and manages the space of the 741 Attribute bit flags of the Attribute Flags TLV, as described in 742 section 11.3 of RFC 5420 [RFC5420], in the "Attribute Flags" 743 section of the "Resource Reservation Protocol-Traffic 744 Engineering (RSVP-TE) Parameters" registry located in 745 http://www.iana.org/assignments/rsvp-te- parameters". 747 This document introduces the following three new Attribute Bit 748 Flags: 750 Bit No Name Attribute Attribute RRO Reference 752 Flags Path Flags Resv 754 ----------- ---------- ---------- ----------- --- ------- 756 TBA by Cost Yes No Yes This I-D 757 IANA Collection 758 Flag 760 TBA by Delay Yes No Yes This I-D 761 IANA Collection 762 Flag 764 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 766 TBA by Delay Yes No Yes This I-D 767 IANA Variation 768 Collection 769 Flag 771 7.2. ROUTE_RECORD sub-object 773 IANA manages the "RSVP PARAMETERS" registry located at 774 http://www.iana.org/assignments/rsvp-parameters. This document 775 introduces the following three new RRO sub-object: 777 Type Name Reference 779 --------- ---------------------- --------- 781 TBA by IANA Cost sub-object This I-D 783 TBA by IANA Delay sub-object This I-D 785 TBA by IANA Delay Variation sub-object This I-D 787 7.3. Policy Control Failure Error subcodes 789 IANA manages the assignments in the "Error Codes and Globally- 790 Defined Error Value Sub-Codes" section of the "RSVP PARAMETERS" 791 registry located at http://www.iana.org/assignments/rsvp- 792 parameters. This document introduces the following three new 793 Policy Control Failure Error sub-code: 795 Value Description Reference 796 ----- ----------- --------- 798 TBA by IANA Cost Recoding Rejected This I-D 800 TBA by IANA Delay Recoding Rejected This I-D 802 TBA by IANA Delay Variation Recoding Rejected This I-D 804 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 806 8. References 808 8.1. Normative References 810 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 811 Requirement Levels", BCP 14, RFC 2119, March 1997. 813 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 814 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 815 LSP Tunnels", RFC 3209, December 2001. 817 [RFC3473] Berger, L., "Generalized Multi-Protocol Lab Switching 818 (GMPLS) Signaling Resource ReserVation Protocol- 819 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 820 January 2003. 822 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and 823 A. Ayyangarps, "Encoding of Attributes for MPLS LSP 824 Establishment Using Resource Reservation Protocol 825 Traffic Engineering (RSVP-TE)", RFC 5420, February 826 2009. 828 [RFC7471] S. Giacalone, D. Ward, J. Drake, A. Atlas, S. 829 Previdi., "OSPF Traffic Engineering (TE) Metric 830 Extensions", RFC 7471, March 2015. 832 [DRAFT-ISIS-TE-METRIC] S. Previdi, S. Giacalone, D. Ward, J. 833 Drake, A. Atlas, C. Filsfils, "IS-IS Traffic 834 Engineering (TE) Metric Extensions", draft-ietf-isis- 835 te-metric-extensions, work in progress. 837 8.2. Informative References 839 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 840 "Generalized Multiprotocol Label Switching (GMPLS) 841 User-Network Interface (UNI): Resource ReserVation 842 Protocol-Traffic Engineering (RSVP-TE) Support for the 843 Overlay Model", RFC 4208, October 2005. 845 [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation 846 Protocol (RSVP) -- Version 1 Message Processing 847 Rules", RFC 2209, September 1997. 849 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 850 Networks", RFC 5920, July 2010. 852 [RFC8001] F. Zhang, O. Gonzalez de Dios, M. 853 Hartley, Z. Ali, C. Margaria,, "RSVP-TE Extensions for 854 Collecting SRLG Information", draft-ietf-teas-rsvp-te- 855 srlg-collect.txt, work in progress. 857 Acknowledgements 859 Authors would like to thank Ori Gerstel, Gabriele Maria 860 Galimberti, Luyuan Fang and Walid Wakim for their review 861 comments. 863 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 865 Contributors 867 Sajal Agarwal 868 Cisco Systems 869 Email: sajaagar@cisco.com 871 Authors' Addresses 873 Zafar Ali 874 Cisco Systems, Inc. 875 Email: zali@cisco.com 877 George Swallow 878 Cisco Systems, Inc. 879 swallow@cisco.com 881 Clarence Filsfils 882 Cisco Systems, Inc. 883 cfilsfil@cisco.com 885 Matt Hartley 886 Cisco Systems 887 Email: mhartley@cisco.com 889 Kenji Kumaki 890 KDDI Corporation 891 Email: ke-kumaki@kddi.com 893 Rudiger Kunze 894 Deutsche Telekom AG 895 Ruediger.Kunze@telekom.de