idnits 2.17.1 draft-ietf-teas-te-metric-recording-03.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 13 longer pages, the longest (page 2) being 69 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 8, 2016) is 2971 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: 'RFC6107' is mentioned on line 534, but not defined == Missing Reference: 'RFC5553' is mentioned on line 577, but not defined == Missing Reference: 'RFC3473' is mentioned on line 582, but not defined == Unused Reference: 'RFC2209' is defined on line 700, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group Zafar Ali 3 Internet Draft George Swallow 4 Intended status: Standard Track Clarence Filsfils 5 Expires: August 7, 2016 Matt Hartley 6 Cisco Systems 8 Kenji Kumaki 9 KDDI Corporation 11 Ruediger Kunze 12 Deutsche Telekom AG 14 February 8, 2016 16 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) 17 extension for recording TE Metric of a Label Switched Path 18 draft-ietf-teas-te-metric-recording-03 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other 32 documents at any time. It is inappropriate to use Internet-Drafts 33 as reference material or to cite them other than as "work in 34 progress." 36 This Internet-Draft will expire on August 7, 2016. 38 Internet-Draft draft-ietf-teas-te-metric-recording-03.txt 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with 50 respect to this document. Code Components extracted from this 51 document must include Simplified BSD License text as described in 52 Section 4.e of the Trust Legal Provisions and are provided without 53 warranty as described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) 61 controlling the copyright in such materials, this document may not 62 be modified outside the IETF Standards Process, and derivative 63 works of it may not be created outside the IETF Standards Process, 64 except to format it for publication as an RFC or to translate it 65 into languages other than English. 67 Abstract 69 There are many scenarios in which Traffic Engineering (TE) metrics 70 such as cost, Delay and Delay variation associated with the TE link 71 formed by Label Switched Path (LSP) are not available to the 72 ingress and egress nodes. This draft provides extensions for the 73 Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) to 74 support automatic collection of cost, Delay and Delay variation 75 information for the TE link formed by a LSP. 77 Conventions used in this document 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 81 this document are to be interpreted as described in RFC 2119 82 [RFC2119]. 84 Table of Contents 86 Copyright Notice............................................1 87 1. Introduction.............................................3 88 1.1. Use Cases..............................................4 89 1.1.1. GMPLS..........................................4 90 1.1.2. Inter-area tunnels with loose-hops.............4 91 2. RSVP-TE Requirement......................................4 92 2.1. Cost, Delay and Delay Variation Collection Indication..4 93 2.2. Cost, Delay and Delay Variation Collection.............4 94 2.3. Cost, Delay and Delay Variation Update.................5 95 2.4. Cost Definition........................................5 96 3. RSVP-TE signaling extensions.............................5 97 Internet-Draft draft-ietf-teas-te-metric-recording-03.txt 99 3.1. Cost, Delay and Delay Variation Collection Flags.......5 100 3.2. Cost Subobject.........................................6 101 3.3. Delay Subobject........................................6 102 3.4. Delay Variation Subobject..............................7 103 4. Signaling Procedures.....................................8 104 4.1. Cost, Delay and Delay Variation Collection Request.....8 105 4.2. Cost, Delay and Delay Variation Recoding...............8 106 4.3. Metric Update..........................................10 107 4.4. Compatibility..........................................10 108 5. Endpoint processing......................................11 109 6. Manageability Considerations.............................11 110 6.1. Policy Configuration...................................11 111 7. Security Considerations..................................12 112 8. IANA Considerations......................................12 113 8.1. RSVP Attribute Bit Flags...............................12 114 8.2. Policy Control Failure Error subcodes..................13 115 9. Acknowledgments..........................................13 116 10. References..............................................14 117 10.1. Normative References..................................14 118 10.2. Informative References................................14 120 1. Introduction 122 In certain networks, such as financial information networks, 123 network performance information (e.g. Delay, Delay variation) is 124 becoming as critical to data path selection as other metrics RFC 125 7471 [RFC7471], [DRAFT-ISIS-TE-METRIC]. If cost, Delay or Delay 126 variation associated with a Forwarding Adjacency (FA) or a 127 Routing Adjacency (RA) LSP is not available to the ingress or 128 egress node, it cannot be advertised as an attribute of the TE 129 link (FA or RA). There are scenarios in packet and optical 130 networks where the route information of an LSP may not be 131 provided to the ingress node for confidentiality reasons and/or 132 the ingress node may not run the same routing instance as the 133 intermediate nodes traversed by the path. Similarly, there are 134 scenarios in which measuring Delay and/ or Delay variation on a 135 TE link formed by a LSP is not supported. In such scenarios, the 136 ingress node cannot determine the cost, Delay and Delay 137 variation properties of the LSP's route. 139 One possible way to address this issue is to configure cost, 140 Delay and Delay variation values manually. However, in the event 141 of an LSP being rerouted (e.g. due to re-optimization), such 142 configuration information may become invalid. Consequently, in 143 cases where that an LSP is advertised as a TE-Link, the ingress 144 and/or egress nodes cannot provide the correct Delay, Delay 145 variation and cost information associated with the TE-Link 146 automatically. 148 In summary, there is a requirement for the ingress and egress 149 nodes to learn the cost, Delay and Delay variation information 150 of the TE link formed by a LSP. This document provides a 151 mechanism to collect the cost, Delay and Delay variation 152 information of a LSP, which can then be advertised as properties 153 of the TE-link formed by that LSP. Note that specification of 154 Internet-Draft draft-ietf-teas-te-metric-recording-03.txt 156 the use of the collected cost, Delay and Delay variation 157 information is outside the scope of this document. 159 1.1. Use Cases 161 This section describes some of the use cases for TE metric 162 recording. 164 1.1.1. GMPLS 166 In Generalized Multi-Protocol Label Switching (GMPLS) networks 167 signaling bidirectional LSPs, the egress node cannot determine 168 the cost, Delay and Delay variation properties of the LSP path. 169 A multi-domain or multi-layer network is an example of such 170 networks. A GMPLS User-Network Interface (UNI) [RFC4208] is also 171 an example of such networks. 173 1.1.2. Inter-area tunnels with loose-hops 175 When a LSP is established over multiple IGP-areas using loose 176 hops in the ERO, the ingress node only has knowledge of the 177 first IGP-area traversed by the LSP. In this case, it cannot 178 determine the cost, Delay and Delay variation properties of the 179 LSP path. 181 2. RSVP-TE Requirement 183 This section outlines RSVP-TE requirements for the support of 184 the automatic discovery of cost, Delay and Delay variation 185 information of an LSP. 187 2.1. Cost, Delay and Delay Variation Collection Indication 189 The ingress node of the LSP SHOULD be capable of indicating 190 whether the cost and/or delay and/ or delay variation 191 information of the LSP is to be collected during the signaling 192 procedure of setting up an LSP. A separate collection indication 193 flag for each of this attribute is required. Cost, delay and 194 delay variation information SHOULD NOT be collected without an 195 explicit request for it being made by the ingress node. 197 2.2. Cost, Delay and Delay Variation Collection 199 If requested, the cost and/or delay and/ or delay variation 200 information SHOULD be collected during the setup of an LSP. Each 201 of the cost, delay or delay variation can be collected 202 independently. The endpoints of the LSP can use the collected 203 information, for example, for routing, flooding and other 204 purposes. 206 Internet-Draft draft-ietf-teas-te-metric-recording-03.txt 208 2.3. Cost, Delay and Delay Variation Update 210 When the cost and/or delay and/ or delay variation information 211 of an existing LSP for which corresponding information was 212 collected during signaling changes, the relevant nodes of the 213 LSP SHOULD be capable of updating the associated information of 214 the LSP. This means that the signaling procedure SHOULD be 215 capable of updating the new cost and/or delay and/ or delay 216 variation information. 218 2.4. Cost Definition 220 Although the terms Delay and Delay variation are well 221 understood, "cost" may be ambiguous; in particular, in the 222 context of a LSP that traverses nodes and links operated by 223 different entities, there may be no common definition of cost. 224 However, there are situations in which the entire LSP may be 225 within a single AS (e.g. inter-area LSPs) in which cost 226 discovery is useful. 228 The precise meaning and interpretation of numerical costs is a 229 matter for the network operator. For the purposes of this 230 document, two constraints are assumed: 232 . A higher cost represents an inferior path. 234 . Simple addition of costs for different sections of a path 235 must make sense. 237 3. RSVP-TE signaling extensions 239 3.1. Cost, Delay and Delay Variation Collection Flags 241 In order to indicate nodes that cost and/or Delay and/ or Delay 242 variation collection is desired, this document defines a new 243 flags in the Attribute Flags TLV (see RFC 5420 [RFC5420]), which 244 MAY be carried in an LSP_REQUIRED_ATTRIBUTES or LSP_ATTRIBUTES 245 Object: 247 - Cost Collection flag (Bit number to be assigned by IANA) 249 - Delay Collection flag (Bit number to be assigned by IANA) 251 - Delay Variation Collection flag (Bit number to be assigned by 252 IANA) 254 The Cost, Delay and Delay Variation Collection flag is 255 meaningful on a Path message. If the Cost Collection flag is 256 set to 1, it means that the cost information SHOULD be reported 257 to the ingress and egress node along the setup of the LSP. 258 Similarly, if the Delay Collection flag is set to 1, it means 259 that the Delay information SHOULD be reported to the ingress and 260 Internet-Draft draft-ietf-teas-te-metric-recording-03.txt 262 egress node along the setup of the LSP. Likewise, if the Delay 263 Variation Collection flag is set to 1, it means that the Delay 264 Variation information SHOULD be reported to the ingress and 265 egress node along the setup of the LSP. 267 The rules of the processing of the Attribute Flags TLV are not 268 changed. 270 3.2. Cost Subobject 272 This document defines a new RRO sub-object (ROUTE_RECORD sub- 273 object) to record the cost information of the LSP. Its format 274 is modeled on the RRO sub-objects defined in RFC 3209 [RFC3209]. 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Type | Length | Reserved (must be zero) | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Cost | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Type: The type of the sub-object (value to be assigned by 285 IANA). 287 Length: The Length field contains the total length of the 288 sub-object in bytes, including the Type and Length fields. 289 The Length value is set to 8. 291 Reserved: This field is reserved for future use. It MUST be 292 set to 0 on transmission and MUST be ignored when received. 294 Cost: Cost of the local TE link along the route of the LSP. 296 3.3. Delay Subobject 298 This document defines a new RRO sub-object (ROUTE_RECORD sub- 299 object) to record the delay information of the LSP. Its format 300 is modeled on the RRO sub-objects defined in RFC 3209 [RFC3209]. 302 0 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Type | Length | Reserved (must be zero) | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 |A| Reserved | Delay | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Internet-Draft draft-ietf-teas-te-metric-recording-03.txt 311 Type: The type of the sub-object (value to be assigned by 312 IANA). 314 Length: The Length field contains the total length of the 315 sub-object in bytes, including the Type and Length fields. 316 The Length value is set to 8. 318 A-bit: These fields represent the Anomalous (A) bit 319 associated with the Downstream and Upstream Delay 320 respectively, as defined in RFC 7471 [RFC7471]. 322 Reserved: These fields are reserved for future use. They MUST 323 be set to 0 when sent and MUST be ignored when received. 325 Delay: Delay of the local TE link along the route of the LSP, 326 encoded as 24-bit integer, as defined in RFC 7471 [RFC7471]. 327 When set to the maximum value 16,777,215 (16.777215 sec), the 328 delay is at least that value and may be larger. 330 3.4. Delay Variation Subobject 332 This document defines a new RRO sub-object (ROUTE_RECORD sub- 333 object) to record the delay variation information of the LSP. 334 Its format is modeled on the RRO sub-objects defined in RFC 3209 335 [RFC3209]. 337 0 1 2 3 338 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 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Type | Length | Reserved (must be zero) | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 |A| Reserved | Delay Variation | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 Type: The type of the sub-object (value to be assigned by 346 IANA). 348 Length: The Length field contains the total length of the 349 sub-object in bytes, including the Type and Length fields. 350 The Length value is set to 8. 352 A-bit: These fields represent the Anomalous (A) bit 353 associated with the Downstream and Upstream Delay Variation 354 respectively, as defined in RFC 7471 [RFC7471]. 356 Reserved: These fields are reserved for future use. It SHOULD 357 be set to 0 when sent and MUST be ignored when received. 359 Delay Variation: Delay Variation of the local TE link along 360 the route of the LSP, encoded as 24-bit integer, as defined 361 in RFC 7471 [RFC7471]. When set to the maximum value 362 Internet-Draft draft-ietf-teas-te-metric-recording-03.txt 364 16,777,215 (16.777215 sec), the delay variation is at least 365 that value and may be larger. 367 4. Signaling Procedures 369 The rules of the processing of the LSP_REQUIRED_ATTRIBUTES, 370 LSP_ATTRIBUTE and ROUTE_RECORD Objects are not changed. 372 As signaling procedure for cost, delay and delay variation 373 collection is similar, many parts of this section are written 374 such that they apply equally to cost, delay and delay variation 375 collection. There is also very strong similarity of these 376 procedures with SRLG recording [DRAFT-SRLG-RECORDING]. 378 4.1. Cost, Delay and Delay Variation Collection Request 380 Per RFC 3209 [RFC3209], an ingress node initiates the recording 381 of the route information of an LSP by adding a RRO to a Path 382 message. If an ingress node also desires Cost and/or Delay 383 and/or Delay Variation recording, it MUST set the appropriate 384 flag(s) in the Attribute Flags TLV which MAY be carried either 385 in an LSP_REQUIRED_ATTRIBUTES Object when the collection is 386 mandatory, or in an LSP_ATTRIBUTES Object when the collection is 387 desired, but not mandatory. 389 4.2. Cost, Delay and Delay Variation Recoding 391 When a node receives a Path message which carries an 392 LSP_REQUIRED_ATTRIBUTES Object and the Cost Collection Flag set, 393 if local policy determines that the cost information is not to 394 be provided to the endpoints or the information is not known, it 395 MUST return a PathErr message with error code 2 (policy) and 396 error subcode "Cost Recording Rejected" (value to be assigned by 397 IANA) to reject the Path message. Similarly, when a node 398 receives a Path message which carries an LSP_REQUIRED_ATTRIBUTES 399 Object and the Delay Collection Flag set, if local policy 400 determines that the Delay information is not to be provided to 401 the endpoints or the information is not known, it MUST return a 402 PathErr message with error code 2 (policy) and error subcode 403 "Delay Recording Rejected" (value to be assigned by IANA) to 404 reject the Path message. Likewise, when a node receives a Path 405 message which carries an LSP_REQUIRED_ATTRIBUTES Object and the 406 Delay Variation Collection Flag set, if local policy determines 407 that the Delay Variation information is not to be provided to 408 the endpoints or the information is not known, it MUST return a 409 PathErr message with error code 2 (policy) and error subcode 410 "Delay Variation Recording Rejected" (value to be assigned by 411 IANA) to reject the Path message. 413 When a node receives a Path message which carries an 414 LSP_ATTRIBUTES Object and the Cost and/or Delay and/or Delay 415 Variation Collection Flag set, if local policy determines that 416 Internet-Draft draft-ietf-teas-te-metric-recording-03.txt 418 the corresponding information is not to be provided to the 419 endpoints, or the information is not known, the Path message 420 SHOULD NOT be rejected due to the recording restriction and the 421 Path message SHOULD be forwarded without any Cost and/or Delay 422 and/or Delay Variation sub-object(s) in the RRO of the 423 corresponding outgoing Path message. 425 If local policy permits the recording of the Cost and/or Delay 426 and/or Delay Variation information, the processing node SHOULD 427 add corresponding information for the local TE link, as defined 428 below, to the RRO of the corresponding outgoing Path message. 429 The A-bit for the Delay MUST be set as described in RFC 7471 430 [RFC7471]. Similarly, the A-bit for the Delay Variation MUST be 431 set as described in RFC 7471 [RFC7471]. It then forwards the 432 Path message to the next node in the downstream direction. 434 If the addition of Cost and/or Delay and/or Delay Variation 435 information to the RRO would result in the RRO exceeding its 436 maximum possible size or becoming too large for the Path message 437 to contain it, the requested information MUST NOT be added. If 438 the Cost and/or Delay and/or Delay Variation collection request 439 was contained in an LSP_REQUIRED_ATTRIBUTES Object, the 440 processing node MUST behave as specified by RFC 3209 [RFC3209] 441 and drop the RRO from the Path message entirely. If the Cost 442 and/or Delay and/or Delay Variation collection request was 443 contained in an LSP_ATTRIBUTES Object, the processing node MAY 444 omit some or all of the corresponding information from the RRO; 445 otherwise it MUST behave as specified by RFC 3209 [RFC3209] and 446 drop the RRO from the Path message entirely. 448 Following the steps described above, the intermediate nodes of 449 the LSP can collect the Cost and/or Delay and/or Delay Variation 450 information in the RRO during the processing of the Path message 451 hop by hop. When the Path message arrives at the egress node, 452 the egress node receives the corresponding information in the 453 RRO. 455 Per RFC 3209 [RFC3209], when issuing a Resv message for a Path 456 message, which contains an RRO, an egress node initiates the RRO 457 process by adding an RRO to the outgoing Resv message. The 458 processing for RROs contained in Resv messages then mirrors that 459 of the Path messages. 461 When a node receives a Resv message for an LSP for which Cost 462 and/or Delay and/or Delay Variation Collection is requested, 463 then when local policy allows recording of the requested 464 information, the node SHOULD add corresponding information, to 465 the RRO of the outgoing Resv message, as specified below. The 466 A-bit for the Delay MUST be set as described in RFC 7471 467 [RFC7471]. Similarly, the A-bit for the Delay Variation MUST be 468 set as described in RFC 7471 [RFC7471]. When the Resv message 469 arrives at the ingress node, the ingress node can extract the 470 Internet-Draft draft-ietf-teas-te-metric-recording-03.txt 472 requested information from the RRO in the same way as the egress 473 node. 475 A node MUST NOT push a Cost, Delay or Delay Variation sub-object 476 in the RECORD_ROUTE without also pushing an IPv4 sub-object, an 477 IPv6 sub-object, an Unnumbered Interface ID sub-object or a Path 478 Key sub-object. 480 Note that a link's Cost and/or Delay and/or Delay Variation 481 information for the upstream direction cannot be assumed to be 482 the same as that in the downstream. 484 . For Path and Resv messages for a unidirectional LSP, a node 485 SHOULD include Cost and/or Delay and/or Delay Variation sub- 486 objects in the RRO for the downstream data link only. 488 . For Path and Resv messages for a bidirectional LSP, a node 489 SHOULD include Cost and/or Delay and/or Delay Variation sub- 490 objects in the RRO for both the upstream data link and the 491 downstream data link from the local node. In this case, the 492 node MUST include the information in the same order for both 493 Path messages and Resv messages. That is, the Cost and/or 494 Delay and/or Delay Variation sub- object for the upstream link 495 is added to the RRO before the corresponding sub-object for 496 the downstream link. 498 4.3. Metric Update 500 When the Cost and/or Delay and/or Delay Variation information of 501 a link is changed, the LSPs using that link need to be aware of 502 the changes. The procedures defined in Section 4.4.3 of RFC 503 3209 [RFC3209] MUST be used to refresh the Cost and/or Delay 504 and/or Delay Variation information if the corresponding change 505 is to be communicated to other nodes according to the local 506 node's policy. If local policy is that the Cost and/or Delay 507 and/or Delay Variation change SHOULD be suppressed or would 508 result in no change to the previously signaled information, the 509 node SHOULD NOT send an update. 511 4.4. Compatibility 513 A node that does not recognize the Cost and/or Delay and/or 514 Delay Variation Collection Flag in the Attribute Flags TLV is 515 expected to proceed as specified in RFC 5420 [RFC5420]. It is 516 expected to pass the TLV on unaltered if it appears in a 517 LSP_ATTRIBUTES object, or reject the Path message with the 518 appropriate Error Code and Value if it appears in a 519 LSP_REQUIRED_ATTRIBUTES object. 521 Internet-Draft draft-ietf-teas-te-metric-recording-03.txt 523 A node that does not recognize the Cost and/or Delay and/or 524 Delay Variation RRO sub-object is expected to behave as 525 specified in RFC 3209 [RFC3209]: unrecognized subobjects are to 526 be ignored and passed on unchanged. 528 5. Endpoint processing 530 Based on the procedures mentioned in Section 4, the endpoints 531 can get the Cost and/or Delay and/or Delay Variation information 532 automatically. Then the endpoints can for instance advertise it 533 as a TE link to the routing instance based on the procedure 534 described in [RFC6107]. How the end point uses the collected 535 information is outside the scope of this document. 537 The ingress and egress nodes of a LSP may calculate the end-to- 538 end cost, Delay and/or Delay variation properties of the LSP 539 from the supplied values in the Resv or Path RRO respectively. 541 Typically, cost and Delay are additive metrics, but Delay 542 variation is not an additive metric. The means by which the 543 ingress and egress nodes compute the end-to-end cost, Delay and 544 Delay variation metric from information recorded in the RRO is a 545 local decision and is beyond the scope of this document. 547 Based on the local policy, the ingress and egress nodes can 548 advertise the calculated end-to-end cost, Delay and/or Delay 549 variation properties of the FA or RA LSP in TE link 550 advertisement to the routing instance based on the procedure 551 described in RFC 7471 [RFC7471], [DRAFT-ISIS-TE-METRIC]. 553 Based on the local policy, a transit node (e.g. the edge node of 554 a domain) may edit a Path or Resv RRO to remove route 555 information (e.g. node or interface identifier information) 556 before forwarding it. A node that does this SHOULD summarize the 557 cost, Delay and Delay Variation data. How a node that performs 558 the RRO edit operation calculates the cost, Delay o and/or Delay 559 variation metric is beyond the scope of this document. 561 6. Manageability Considerations 563 6.1. Policy Configuration 565 In a border node of inter-domain or inter-layer network, the 566 following Cost and/or Delay and/or Delay Variation processing 567 policy SHOULD be capable of being configured: 569 Internet-Draft draft-ietf-teas-te-metric-recording-03.txt 571 o Whether the Cost and/or Delay and/or Delay Variation of the 572 domain or specific layer network can be exposed to the nodes 573 outside the domain or layer network, or whether they SHOULD be 574 summarized, mapped to values that are comprehensible to nodes 575 outside the domain or layer network, or removed entirely. 577 A node using RFC 5553 [RFC5553] and PKS MAY apply the same 578 policy. 580 7. Security Considerations 582 This document builds on the mechanisms defined in [RFC3473], 583 which also discusses related security measures. In addition, 584 [RFC5920] provides an overview of security vulnerabilities and 585 protection mechanisms for the GMPLS control plane. The 586 procedures defined in this document permit the transfer of Cost 587 and/or Delay and/or Delay Variation data between layers or 588 domains during the signaling of LSPs, subject to policy at the 589 layer or domain boundary. It is recommended that domain/layer 590 boundary policies take the implications of releasing Cost and/or 591 Delay and/or Delay Variation information into consideration and 592 behave accordingly during LSP signaling. 594 8. IANA Considerations 596 8.1. RSVP Attribute Bit Flags 598 IANA has created a registry and manages the space of the 599 Attribute bit flags of the Attribute Flags TLV, as described in 600 section 11.3 of RFC 5420 [RFC5420], in the "Attribute Flags" 601 section of the "Resource Reservation Protocol-Traffic 602 Engineering (RSVP-TE) Parameters" registry located in 603 http://www.iana.org/assignments/rsvp-te- parameters". 605 This document introduces the following three new Attribute Bit 606 Flags: 608 Bit No Name Attribute Attribute RRO Reference 610 Flags Path Flags Resv 612 ----------- ---------- ---------- ----------- --- ------- 614 TBA by Cost Yes Yes Yes This I-D 615 IANA Collection 616 Flag 618 TBA by Delay Yes Yes Yes This I-D 619 IANA Collection 620 Flag 621 Internet-Draft draft-ietf-teas-te-metric-recording-03.txt 623 TBA by Delay Yes Yes Yes This I-D 624 IANA Variation 625 Collection 626 Flag 628 5.2. ROUTE_RECORD subobject 630 IANA manages the "RSVP PARAMETERS" registry located at 631 http://www.iana.org/assignments/rsvp-parameters. This document 632 introduces the following three new RRO subobject: 634 Type Name Reference 636 --------- ---------------------- --------- 638 TBA by IANA Cost subobject This I-D 640 TBA by IANA Delay subobject This I-D 642 TBA by IANA Delay Variation subobject This I-D 644 8.2. Policy Control Failure Error subcodes 646 IANA manages the assignments in the "Error Codes and Globally- 647 Defined Error Value Sub-Codes" section of the "RSVP PARAMETERS" 648 registry located at http://www.iana.org/assignments/rsvp- 649 parameters. This document introduces the following three new 650 Policy Control Failure Error sub-code: 652 Value Description Reference 653 ----- ----------- --------- 654 TBA by IANA Cost Recoding Rejected This I-D 655 TBA by IANA Delay Recoding Rejected This I-D 656 TBA by IANA Delay Variation Recoding Rejected This I-D 658 9. Acknowledgments 660 Authors would like to thank Ori Gerstel, Gabriele Maria 661 Galimberti, Luyuan Fang and Walid Wakim for their review 662 comments. 664 Internet-Draft draft-ietf-teas-te-metric-recording-03.txt 666 10. References 668 10.1. Normative References 670 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 671 Requirement Levels", BCP 14, RFC 2119, March 1997. 673 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 674 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 675 LSP Tunnels", RFC 3209, December 2001. 677 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and 678 A. Ayyangarps, "Encoding of Attributes for MPLS LSP 679 Establishment Using Resource Reservation Protocol 680 Traffic Engineering (RSVP-TE)", RFC 5420, February 681 2009. 683 [RFC7471] S. Giacalone, D. Ward, J. Drake, A. Atlas, S. 684 Previdi., "OSPF Traffic Engineering (TE) Metric 685 Extensions", RFC 7471, March 2015. 687 [DRAFT-ISIS-TE-METRIC] S. Previdi, S. Giacalone, D. Ward, J. 688 Drake, A. Atlas, C. Filsfils, "IS-IS Traffic 689 Engineering (TE) Metric Extensions", draft-ietf-isis- 690 te-metric-extensions, work in progress. 692 10.2. Informative References 694 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 695 "Generalized Multiprotocol Label Switching (GMPLS) 696 User-Network Interface (UNI): Resource ReserVation 697 Protocol-Traffic Engineering (RSVP-TE) Support for the 698 Overlay Model", RFC 4208, October 2005. 700 [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation 701 Protocol (RSVP) -- Version 1 Message Processing 702 Rules", RFC 2209, September 1997. 704 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 705 Networks", RFC 5920, July 2010. 707 [DRAFT-SRLG-RECORDING] F. Zhang, O. Gonzalez de Dios, M. 708 Hartley, Z. Ali, C. Margaria, "RSVP-TE Extensions for 709 Collecting SRLG Information", draft-ietf-teas-rsvp-te- 710 srlg-collect.txt, work in progress. 712 Authors' Addresses 713 Internet-Draft draft-ietf-teas-te-metric-recording-03.txt 715 Zafar Ali 716 Cisco Systems, Inc. 717 Email: zali@cisco.com 719 George Swallow 720 Cisco Systems, Inc. 721 swallow@cisco.com 723 Clarence Filsfils 724 Cisco Systems, Inc. 725 cfilsfil@cisco.com 727 Matt Hartley 728 Cisco Systems 729 Email: mhartley@cisco.com 731 Kenji Kumaki 732 KDDI Corporation 733 Email: ke-kumaki@kddi.com 735 Rudiger Kunze 736 Deutsche Telekom AG 737 Ruediger.Kunze@telekom.de