idnits 2.17.1 draft-ietf-teas-te-metric-recording-08.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 9 longer pages, the longest (page 17) being 73 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 (Nov 16, 2018) is 1960 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 806 looks like a reference -- Missing reference section? 'RFC7471' on line 824 looks like a reference -- Missing reference section? 'RFC7810' on line 828 looks like a reference -- Missing reference section? 'RFC4208' on line 835 looks like a reference -- Missing reference section? 'RFC8001' on line 848 looks like a reference -- Missing reference section? 'RFC5420' on line 818 looks like a reference -- Missing reference section? 'RFC3209' on line 809 looks like a reference -- Missing reference section? 'RFC5553' on line 715 looks like a reference -- Missing reference section? 'RFC5520' on line 457 looks like a reference -- Missing reference section? 'RFC6107' on line 651 looks like a reference -- Missing reference section? 'DRAFT-ISIS-TE-METRIC' on line 673 looks like a reference -- Missing reference section? 'RFC3473' on line 813 looks like a reference -- Missing reference section? 'RFC5920' on line 845 looks like a reference -- Missing reference section? 'RFC2209' on line 841 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group Zafar Ali 3 Internet Draft Clarence Filsfils 4 Intended status: Standard Track Cisco Systems 5 Expires: May 15, 2019 Julien Meuric 6 France telecom 7 Kenji Kumaki 8 KDDI Corporation 9 Ruediger Kunze 10 Deutsche Telekom AG 11 Nov 16, 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-08 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 May 15, 2019. 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. Inter-domain TE LSPs ....................... 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], [RFC7810]. 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 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. 156 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 158 1.1. Use Cases 160 This section describes some of the use cases for the TE metric 161 recording. 163 1.1.1. Inter-domain TE LSPs 165 The cost, delay, delay-variation information of a LSP collected 166 by procedures defined in this document can be advertised as 167 properties of TE-link formed by that LSP. This information is 168 very helpful in multi-domain or multi-layer network. A GMPLS 169 User-Network Interface (UNI) [RFC4208] is also an example of 170 such networks. 172 1.1.2. Inter-area tunnels with loose-hops 174 When a LSP is established over multiple IGP-areas using loose 175 hops in the ERO, the ingress node may only have knowledge of the 176 first IGP-area traversed by the LSP. In this case, it cannot 177 determine the cost, delay and delay variation properties of the 178 LSP path. 180 2. RSVP-TE Requirement 182 This section outlines RSVP-TE requirements for the support of 183 the automatic collection of cost, delay and delay variation 184 information of an LSP. 186 As RSVP-TE requirements for cost, delay and delay variation 187 collection are similar, many parts of this section are written 188 such that they apply equally to cost, delay and delay variation 189 collection. There is also very strong similarity of these RSVP- 190 requirements with SRLG recording [RFC8001]. 192 The Cost, Delay, Delay variation collection process takes place 193 in three stages: 195 o The LSP's ingress node requests that Cost, Delay, Delay 196 Variation collection should take place; 198 o Cost, Delay, Delay Variation data is added to the Path and 199 Resv ROUTE_RECORD Objects(RROs) by all nodes during signaling; 201 o Changes to previously signaled Cost, Delay, Delay variation 202 data are made by sending updated Path and Resv messages as 203 required. 205 2.1. Cost, Delay and Delay Variation Collection Indication 207 The ingress node of the LSP needs be capable of indicating 208 whether the cost and/or delay and/ or delay variation 209 information of the LSP is to be collected during the signaling 210 procedure of setting up an LSP. A separate collection indication 211 flag for each of these attributes is required. There is no need 212 for cost and/or delay and/ or delay variation to be collected 213 without an explicit request for it being made by the ingress 214 node. 216 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 218 It may be preferable for the cost and/ or delay and/ or delay 219 variation collection request to be understood by all nodes along 220 the LSP's path, or it may be more important for the LSP to be 221 established successfully even if it traverses nodes that cannot 222 supply the requested information or have not implemented the 223 procedures specified in this document. It is desirable for the 224 ingress node to make the cost, delay and delay variation 225 collection request in a manner that best suits its own policy. 227 2.2. Cost, Delay and Delay Variation Collection 229 If requested, the cost and/or delay and/ or delay variation 230 information is collected during the setup of an LSP. Each of the 231 cost, delay or delay variation can be collected independently. 232 Cost and/ or delay and/ or delay variation information is added 233 by each hop to the Path RRO during Path message processing. The 234 corresponding information is also added to the Resv RRO during 235 Resv processing at each hop. 237 2.3. Cost, Delay and Delay Variation Update 239 When the cost and/or delay and/ or delay variation information 240 of an existing LSP for which corresponding information was 241 collected during signaling changes, the relevant nodes of the 242 LSP need to be capable of updating the associated information of 243 the LSP. This means that the signaling procedure needs to be 244 capable of updating the new cost and/or delay and/ or delay 245 variation information. 247 2.4. Cost Definition 249 Although the terms delay and delay variation are well 250 understood, "cost" may be ambiguous; in particular, in the 251 context of a LSP that traverse nodes and links operated by 252 different entities, there may be no common definition of cost. 253 However, there are situations in which the entire LSP may be 254 within a single AS (e.g. inter-area LSPs) in which cost 255 discovery is useful. 257 The precise meaning and interpretation of numerical costs is a 258 matter for the network operator. For the purposes of this 259 document, two constraints are assumed: 261 . A higher cost represents an inferior path. 263 . Simple addition of costs for different sections of a path 264 must make sense. 266 3. Encoding 268 3.1. Cost, Delay and Delay Variation Collection Flags 270 In order to indicate nodes that cost and/or Delay and/or Delay 271 variation collection is desired, this document defines the 272 following new flags in the Attribute Flags TLV (see RFC 5420 274 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 276 [RFC5420]). A node that wishes to indicate Cost and/or Delay 277 and/or Delay Variation collection is desired MUST set 278 corresponding flag in Attribute Flags TLV in an 279 LSP_REQUIRED_ATTRIBUTES object (if collection is mandatory) 280 or LSP_ATTRIBUTES Object(if collection is desired but not mandatory): 282 - Cost Collection flag (Bit number to be assigned by IANA) 284 - Delay Collection flag (Bit number to be assigned by IANA) 286 - Delay Variation Collection flag (Bit number to be assigned by 287 IANA) 289 The Cost, Delay and Delay Variation Collection flags are 290 meaningful on a Path message. If the Cost Collection flag is 291 set to 1, it means that the cost information SHOULD be reported 292 to the ingress and egress node along the setup of the LSP. 293 Similarly, if the Delay Collection flag is set to 1, it means 294 that the Delay information SHOULD be reported to the ingress and 295 egress node along the setup of the LSP. Likewise, if the Delay 296 Variation Collection flag is set to 1, it means that the Delay 297 Variation information SHOULD be reported to the ingress and 298 egress node along the setup of the LSP. 300 The rules of the processing of the Attribute Flags TLV are not 301 changed. 303 3.2. RRO Cost Subobject 305 This document defines a new RRO sub-object (ROUTE_RECORD sub- 306 object) to record the cost information of the LSP. Its format 307 is modeled on the RRO sub-objects defined in RFC 3209 [RFC3209]. 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type | Length |D| Reserved (must be zero) | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Cost | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Type: The type of the sub-object (value to be assigned by 318 IANA). 320 Length: The Length field contains the total length of the 321 sub-object in bytes, including the Type and Length fields. 322 The Length value is set to 8. 324 Direction bit (D-bit) 326 If not set, the cost contained in this sub-object applies to 327 the downstream direction. If set, it applies to the upstream 328 direction. 330 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 332 Reserved: This field is reserved for future use. It MUST be 333 set to 0 on transmission and MUST be ignored when received. 335 Cost: Cost of the local TE link along the route of the LSP. 337 3.3. RRO Delay Subobject 339 This document defines a new RRO sub-object (ROUTE_RECORD sub- 340 object) to record the delay information of the LSP. Its format 341 is modeled on the RRO sub-objects defined in RFC 3209 [RFC3209]. 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Type | Length |D| Reserved (must be zero) | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 |A| Reserved | Delay | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 Type: The type of the sub-object (value to be assigned by 352 IANA). 354 Length: The Length field contains the total length of the 355 sub-object in bytes, including the Type and Length fields. 356 The Length value is set to 8. 358 Direction bit (D-bit) 360 If not set, the Delay contained in this sub-object applies to 361 the downstream direction. If set, it applies to the upstream 362 direction. 364 A-bit: These fields represent the Anomalous (A) bit 365 associated with the Downstream and Upstream Delay 366 respectively, as defined in RFC 7471 [RFC7471]. 368 Reserved: These fields are reserved for future use. They MUST 369 be set to 0 when sent and MUST be ignored when received. 371 Delay: Delay of the local TE link along the route of the LSP, 372 encoded as 24-bit integer, as defined in RFC 7471 [RFC7471]. 373 When set to the maximum value 16,777,215 (16.777215 sec), the 374 delay is at least that value and may be larger. 376 3.4. RRO Delay Variation Subobject 378 This document defines a new RRO sub-object (ROUTE_RECORD sub- 379 object) to record the delay variation information of the LSP. 381 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 383 Its format is modeled on the RRO sub-objects defined in RFC 3209 384 [RFC3209]. 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Type | Length |D| Reserved (must be zero) | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 |A| Reserved | Delay Variation | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Type: The type of the sub-object (value to be assigned by 395 IANA). 397 Length: The Length field contains the total length of the 398 sub-object in bytes, including the Type and Length fields. 399 The Length value is set to 8. 401 Direction bit (D-bit) 403 If not set, the Delay Variation contained in this sub-object 404 applies to the downstream direction. If set, it applies to 405 the upstream direction. 407 A-bit: These fields represent the Anomalous (A) bit 408 associated with the Downstream and Upstream Delay Variation 409 respectively, as defined in RFC 7471 [RFC7471]. 411 Reserved: These fields are reserved for future use. It SHOULD 412 be set to 0 when sent and MUST be ignored when received. 414 Delay Variation: Delay Variation of the local TE link along 415 the route of the LSP, encoded as 24-bit integer, as defined 416 in RFC 7471 [RFC7471]. When set to the maximum value 417 16,777,215 (16.777215 sec), the delay variation is at least 418 that value and may be larger. 420 4. Signaling Procedures 422 As signaling procedure for cost, delay and delay variation 423 collection is similar, many parts of this section are written 424 such that they apply equally to cost, delay and delay variation 425 collection. There is also very strong similarity of these 426 procedures with SRLG recording [RFC8001]. 428 The ingress node of the LSP MUST be capable of indicating 429 whether the Cost and/ or Delay and/ or Delay Variation 430 information of the LSP is to be collected during the signaling 431 procedure of setting up an LSP. 433 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 435 A node MUST NOT push Cost and/ or Delay and/ or Delay Variation 436 sub-object(s) in the RECORD_ROUTE without also pushing either an 437 IPv4 sub-object, an IPv6 sub-object, an Unnumbered Interface ID 438 sub-object or a Path Key sub-object or an SRLG sub-object. 440 As described in RFC 3209 [RFC3209], the RECORD_ROUTE object is 441 managed as a stack. The Cost and/ or Delay and/ or Delay 442 Variation sub-object(s) SHOULD be pushed by the node before the 443 node IP address or link identifier. These sub-object(s) SHOULD 444 be pushed after the Attribute sub-object, if present, and after 445 the LABEL sub-object, if requested, and after the SRLG sub- 446 object, if requested. These sub-object(s) MUST be pushed within 447 the hop to which it applies. 449 RFC 5553 [RFC5553] describes mechanisms to carry a PKS (Path Key 450 Sub-object) in the RRO so as to facilitate confidentiality in 451 the signaling of inter-domain TE LSPs, and allows the path 452 segment that needs to be hidden (that is, a Confidential Path 453 Segment (CPS)) to be replaced in the RRO with a PKS. If the CPS 454 contains Cost and/ or Delay and/ or Delay Variation Sub-objects, 455 these MAY be retained in the RRO by adding them again after the 456 PKS Sub-object in the RRO. The CPS is defined in RFC 5520 457 [RFC5520]. 459 The rules of the processing of the LSP_REQUIRED_ATTRIBUTES, 460 LSP_ATTRIBUTE and ROUTE_RECORD Objects are not changed. 462 4.1. Cost, Delay and Delay Variation Collection 464 Per RFC 3209 [RFC3209], an ingress node initiates the recording 465 of the route information of an LSP by adding a RRO to a Path 466 message. If an ingress node also desires Cost and/or Delay 467 and/or Delay Variation recording, it MUST set the appropriate 468 flag(s) in the Attribute Flags TLV which MAY be carried either 469 in an LSP_REQUIRED_ATTRIBUTES Object when the collection is 470 mandatory, or in an LSP_ATTRIBUTES Object when the collection is 471 desired, but not mandatory. 473 When a node receives a Path message which carries an 474 LSP_REQUIRED_ATTRIBUTES Object with the Cost Collection Flag 475 set, if local policy determines that the Cost information is not 476 to be provided to the endpoints, it MUST return a PathErr 477 message with: 479 o Error Code 2 (policy) and 481 o Error subcode "Cost Recording Rejected" (value to be 482 assigned by IANA) 484 to reject the Path message. Similarly, when a node receives a 485 Path message which carries an LSP_REQUIRED_ATTRIBUTES Object 486 with the Delay Collection Flag set, if local policy determines 488 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 490 that the Delay information is not to be provided to the 491 endpoints, it MUST return a PathErr message with: 493 o Error Code 2 (policy) and 495 o Error subcode "Delay Recording Rejected" (value to be 496 assigned by IANA) 498 to reject the Path message. Likewise, when a node receives a 499 Path message which carries an LSP_REQUIRED_ATTRIBUTES Object 500 with the Delay Variation Collection Flag set, if local policy 501 determines that the Delay Variation information is not to be 502 provided to the endpoints, it MUST return a PathErr message 503 with: 505 o Error Code 2 (policy) and 507 o Error subcode "Delay Variation Recording Rejected" (value 508 to be assigned by IANA) 510 to reject the Path message. 512 When a node receives a Path message which carries an 513 LSP_ATTRIBUTES Object and the Cost and/or Delay and/or Delay 514 Variation Collection Flag set, if local policy determines that 515 the corresponding information is not to be provided to the 516 endpoints, or the information is not known, the Path message 517 SHOULD NOT be rejected due to the recording restriction and the 518 Path message SHOULD be forwarded without any Cost and/or Delay 519 and/or Delay Variation sub-object(s) in the RRO of the 520 corresponding outgoing Path message. 522 If local policy permits the recording of the Cost and/or Delay 523 and/or Delay Variation information, the processing node SHOULD 524 add corresponding information for the local TE link, as defined 525 below, to the RRO of the corresponding outgoing Path message. 526 The A-bit for the Delay MUST be set as described in RFC 7471 527 [RFC7471]. Similarly, the A-bit for the Delay Variation MUST be 528 set as described in RFC 7471 [RFC7471]. It then forwards the 529 Path message to the next node in the downstream direction. The 530 processing node MUST retain a record of the Cost and/ or Delay 531 and/ or Delay Variation Collection request for reference during 532 Resv processing described below. 534 If the addition of Cost and/or Delay and/or Delay Variation 535 information to the RRO would result in the RRO exceeding its 536 maximum possible size or becoming too large for the Path message 537 to contain it, the requested information MUST NOT be added. If 538 the Cost and/or Delay and/or Delay Variation collection request 539 was contained in an LSP_REQUIRED_ATTRIBUTES Object, the 540 processing node MUST behave as specified by RFC 3209 [RFC3209] 541 and drop the RRO from the Path message entirely. If the Cost 543 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 545 and/or Delay and/or Delay Variation collection request was 546 contained in an LSP_ATTRIBUTES Object, the processing node MAY 547 omit some or all of the corresponding information from the RRO; 548 otherwise it MUST behave as specified by RFC 3209 [RFC3209] and 549 drop the RRO from the Path message entirely. 551 Following the steps described above, the intermediate nodes of 552 the LSP can collect the Cost and/or Delay and/or Delay Variation 553 information in the RRO during the processing of the Path message 554 hop by hop. When the Path message arrives at the egress node, 555 the egress node receives the corresponding information in the 556 RRO. 558 Per RFC 3209 [RFC3209], when issuing a Resv message for a Path 559 message, which contains an RRO, an egress node initiates the RRO 560 process by adding an RRO to the outgoing Resv message. The 561 processing for RROs contained in Resv messages then mirrors that 562 of the Path messages. 564 When a node receives a Resv message for an LSP for which Cost 565 and/or Delay and/or Delay Variation Collection was specified, 566 then when local policy allows recording of the requested 567 information, the node SHOULD add corresponding information, to 568 the RRO of the outgoing Resv message, as specified below. The 569 A-bit for the Delay MUST be set as described in RFC 7471 570 [RFC7471]. Similarly, the A-bit for the Delay Variation MUST be 571 set as described in RFC 7471 [RFC7471]. When the Resv message 572 arrives at the ingress node, the ingress node can extract the 573 requested information from the RRO in the same way as the egress 574 node. 576 Note that a link's Cost and/ or Delay and/ or Delay Variation 577 information for the upstream direction cannot be assumed to be 578 the same as that in the downstream. 580 o For Path and Resv messages for a unidirectional LSP, a node 581 SHOULD include Cost and/ or Delay and/ or Delay Variation 582 sub-objects in the RRO for the downstream data link only. 584 o For Path and Resv messages for a bidirectional LSP, a node 585 SHOULD include Cost and/ or Delay and/ or Delay Variation 586 sub-objects in the RRO for both the upstream data link and 587 the downstream data link from the local node. In this 588 case, the node MUST include the metric information in the 589 same order for both Path messages and Resv messages. That 590 is, the Cost and/ or Delay and/ or Delay Variation sub- 591 object(s) for the upstream link is added to the RRO before 592 the corresponding sub-object for the downstream link. 594 If Cost and/ or Delay and/ or Delay Variation data is added 595 for both the upstream and downstream links, the two sets of 596 the data MUST be added in separate corresponding sub- 598 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 600 object(s). A single Cost or Delay or Delay Variation sub- 601 object MUST NOT contain a mixture of the applicable data 602 for upstream and downstream directions. When adding a Cost 603 or Delay or Delay Variation sub-object to an RRO, the D-bit 604 MUST be set appropriately to indicate the direction of the 605 TE Link. If the same value applies in both directions, it 606 SHOULD be added to both the corresponding upstream and 607 downstream sub-objects. 609 Based on the local policy, a transit node may edit a Path or 610 Resv RRO to remove route information (e.g. node or interface 611 identifier information) before forwarding it. A node that does 612 this SHOULD summarize the cost, Delay and Delay Variation data. 613 How a node that performs the RRO edit operation calculates the 614 Cost and/ or Delay and/or Delay variation metric is beyond the 615 scope of this document. 617 A node SHOULD NOT add Cost or Delay or Delay Variation 618 information without an explicit request for the corresponding 619 information being made by the ingress node in the Path message. 621 4.2. Metric Update 623 When the Cost and/or Delay and/or Delay Variation information of 624 a link is changed, the endpoints of LSPs using that link need to 625 be aware of the changes. When a change to Cost or Delay or 626 Delay Variation information associated with a link occurs, the 627 procedures defined in Section 4.4.3 of RFC 3209 [RFC3209] MUST 628 be used to refresh the corresponding metric information if the 629 change is to be communicated to other nodes according to the 630 local node's policy. If local policy is that the Cost and/or 631 Delay and/or Delay Variation change SHOULD be suppressed or 632 would result in no change to the previously signaled 633 information, the node SHOULD NOT send an update. 635 4.3. Domain Boundaries 637 If mandated by local policy, a node MAY remove Cost and/or Delay 638 and/or Delay Variation information from any RRO in a Path or 639 Resv message being processed. A node that does this SHOULD 640 summarize the Cost, Delay and Delay Variation data. How a node 641 that performs the RRO edit operation calculates the Cost, Delay 642 and/or Delay variation metric is beyond the scope of this 643 document. 645 4.4. Endpoint processing 647 Based on the procedures described above, the endpoints can get 648 the Cost and/or Delay and/or Delay Variation information 649 automatically. Then the endpoints can for instance advertise it 650 as a TE link to the routing instance based on the procedure 651 described in [RFC6107] and configure the corresponding TE metric 653 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 655 information of the Forwarding Adjacency (FA) or Routing 656 Adjacency (RA) automatically. How the end point uses the 657 collected information is outside the scope of this document. 659 The ingress and egress nodes of a LSP may calculate the end-to- 660 end Cost, Delay and/or Delay variation properties of the LSP 661 from the supplied values in the Resv or Path RRO, respectively. 663 Typically, Cost and Delay are additive metrics, but Delay 664 variation is not an additive metric. The means by which the 665 ingress and egress nodes compute the end-to-end Cost, Delay and 666 Delay variation metric from information recorded in the RRO is a 667 local decision and is beyond the scope of this document. 669 Based on the local policy, the ingress and egress nodes can 670 advertise the calculated end-to-end Cost, Delay and/or Delay 671 variation properties of the FA or RA LSP in TE link 672 advertisement to the routing instance based on the procedure 673 described in RFC 7471 [RFC7471], [DRAFT-ISIS-TE-METRIC]. 675 4.5. Compatibility 677 A node that does not recognize the Cost and/or Delay and/or 678 Delay Variation Collection Flag in the Attribute Flags TLV is 679 expected to proceed as specified in RFC 5420 [RFC5420]. 680 Specifically, the node is expected to pass the TLV on unaltered 681 if it appears in a LSP_ATTRIBUTES object. On the other hand, if 682 the TLV appears in a LSP_REQUIRED_ATTRIBUTES object, the node is 683 expected to reject the Path message with the Error Code and 684 Value defined in RFC 5420 [RFC5420]. 686 A node that does not recognize the Cost and/or Delay and/or 687 Delay Variation RRO sub-object is expected to behave as 688 specified in RFC 3209 [RFC3209]: unrecognized sub-objects are to 689 be ignored and passed on unchanged. 691 5. Manageability Considerations 693 5.1. Policy Configuration 695 In a border node of inter-domain or inter-layer network, the 696 following Cost and/or Delay and/or Delay Variation processing 697 policy SHOULD be capable of being configured: 699 o Whether the node is allowed to participate in Cost or Delay 700 or Delay Variation collection. 702 o Whether the node should notify changes to collected Cost 703 and/ or Delay and/ or Delay Variation information to 704 endpoint nodes as described in section 4.2. 706 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 708 o Whether the Cost and/or Delay and/or Delay Variation of the 709 domain or specific layer network can be exposed to the 710 nodes outside the domain or layer network, or whether they 711 SHOULD be summarized, mapped to values that are 712 comprehensible to nodes outside the domain or layer 713 network, or removed entirely. 715 A node using RFC 5553 [RFC5553] and PKS MAY apply the same 716 policy. 718 6. Security Considerations 720 This document builds on the mechanisms defined in [RFC3473], 721 which also discusses related security measures. In addition, 722 [RFC5920] provides an overview of security vulnerabilities and 723 protection mechanisms for the GMPLS control plane. The 724 procedures defined in this document permit the transfer of Cost 725 and/or Delay and/or Delay Variation data between layers or 726 domains during the signaling of LSPs, subject to policy at the 727 layer or domain boundary. It is recommended that domain/layer 728 boundary policies take the implications of releasing Cost and/or 729 Delay and/or Delay Variation information into consideration and 730 behave accordingly during LSP signaling. 732 7. IANA Considerations 734 7.1. RSVP Attribute Bit Flags 736 IANA has created a registry and manages the space of the 737 Attribute bit flags of the Attribute Flags TLV, as described in 738 section 11.3 of RFC 5420 [RFC5420], in the "Attribute Flags" 739 section of the "Resource Reservation Protocol-Traffic 740 Engineering (RSVP-TE) Parameters" registry located in 741 http://www.iana.org/assignments/rsvp-te- parameters". 743 This document introduces the following three new Attribute Bit 744 Flags: 746 Bit No Name Attribute Attribute RRO Reference 748 Flags Path Flags Resv 750 ----------- ---------- ---------- ----------- --- ------- 752 TBA by Cost Yes No Yes This I-D 753 IANA Collection 754 Flag 756 TBA by Delay Yes No Yes This I-D 757 IANA Collection 758 Flag 760 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 762 TBA by Delay Yes No Yes This I-D 763 IANA Variation 764 Collection 765 Flag 767 7.2. ROUTE_RECORD sub-object 769 IANA manages the "RSVP PARAMETERS" registry located at 770 http://www.iana.org/assignments/rsvp-parameters. This document 771 introduces the following three new RRO sub-object: 773 Type Name Reference 775 --------- ---------------------- --------- 777 TBA by IANA Cost sub-object This I-D 779 TBA by IANA Delay sub-object This I-D 781 TBA by IANA Delay Variation sub-object This I-D 783 7.3. Policy Control Failure Error subcodes 785 IANA manages the assignments in the "Error Codes and Globally- 786 Defined Error Value Sub-Codes" section of the "RSVP PARAMETERS" 787 registry located at http://www.iana.org/assignments/rsvp- 788 parameters. This document introduces the following three new 789 Policy Control Failure Error sub-code: 791 Value Description Reference 792 ----- ----------- --------- 794 TBA by IANA Cost Recoding Rejected This I-D 796 TBA by IANA Delay Recoding Rejected This I-D 798 TBA by IANA Delay Variation Recoding Rejected This I-D 800 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 802 8. References 804 8.1. Normative References 806 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 807 Requirement Levels", BCP 14, RFC 2119, March 1997. 809 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 810 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 811 LSP Tunnels", RFC 3209, December 2001. 813 [RFC3473] Berger, L., "Generalized Multi-Protocol Lab Switching 814 (GMPLS) Signaling Resource ReserVation Protocol- 815 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 816 January 2003. 818 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and 819 A. Ayyangarps, "Encoding of Attributes for MPLS LSP 820 Establishment Using Resource Reservation Protocol 821 Traffic Engineering (RSVP-TE)", RFC 5420, February 822 2009. 824 [RFC7471] S. Giacalone, D. Ward, J. Drake, A. Atlas, S. 825 Previdi., "OSPF Traffic Engineering (TE) Metric 826 Extensions", RFC 7471, March 2015. 828 [RFC7810] S. Previdi, S. Giacalone, D. Ward, J. 829 Drake, A. Atlas, C. Filsfils, "IS-IS Traffic 830 Engineering (TE) Metric Extensions", draft-ietf-isis- 831 te-metric-extensions, work in progress. 833 8.2. Informative References 835 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 836 "Generalized Multiprotocol Label Switching (GMPLS) 837 User-Network Interface (UNI): Resource ReserVation 838 Protocol-Traffic Engineering (RSVP-TE) Support for the 839 Overlay Model", RFC 4208, October 2005. 841 [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation 842 Protocol (RSVP) -- Version 1 Message Processing 843 Rules", RFC 2209, September 1997. 845 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 846 Networks", RFC 5920, July 2010. 848 [RFC8001] F. Zhang, O. Gonzalez de Dios, M. 849 Hartley, Z. Ali, C. Margaria,, "RSVP-TE Extensions for 850 Collecting SRLG Information", draft-ietf-teas-rsvp-te- 851 srlg-collect.txt, work in progress. 853 Acknowledgements 855 Authors would like to thank Ori Gerstel, Gabriele Maria 856 Galimberti, Luyuan Fang and Walid Wakim for their review 857 comments. 859 Internet-Draft draft-ietf-teas-te-metric-recording-07.txt 861 Contributors 863 Sajal Agarwal 864 Cisco Systems 865 Email: sajaagar@cisco.com 867 George Swallow 868 Individual 870 Matt Hartley 871 Individual 873 Authors' Addresses 875 Zafar Ali 876 Cisco Systems, Inc. 877 Email: zali@cisco.com 879 George Swallow 880 Cisco Systems, Inc. 881 swallow@cisco.com 883 Clarence Filsfils 884 Cisco Systems, Inc. 885 cfilsfil@cisco.com 887 Matt Hartley 888 Cisco Systems 889 Email: mhartley@cisco.com 891 Kenji Kumaki 892 KDDI Corporation 893 Email: ke-kumaki@kddi.com 895 Rudiger Kunze 896 Deutsche Telekom AG 897 Ruediger.Kunze@telekom.de 899 Julien Meuric 900 France Telecom 901 Email: julien.meuric@orange.com