idnits 2.17.00 (12 Aug 2021) /tmp/idnits30717/draft-ietf-isis-te-metric-extensions-11.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: ---------------------------------------------------------------------------- No issues found here. 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 date (February 12, 2016) is 2283 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group S. Previdi, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track S. Giacalone 5 Expires: August 15, 2016 Unaffiliated 6 D. Ward 7 Cisco Systems, Inc. 8 J. Drake 9 Juniper Networks 10 Q. Wu 11 Huawei 12 February 12, 2016 14 IS-IS Traffic Engineering (TE) Metric Extensions 15 draft-ietf-isis-te-metric-extensions-11 17 Abstract 19 In certain networks, such as, but not limited to, financial 20 information networks (e.g. stock market data providers), network 21 performance criteria (e.g. latency) are becoming as critical to data 22 path selection as other metrics. 24 This document describes extensions to IS-IS Traffic Engineering 25 Extensions (RFC5305) such that network performance information can be 26 distributed and collected in a scalable fashion. The information 27 distributed using IS-IS TE Metric Extensions can then be used to make 28 path selection decisions based on network performance. 30 Note that this document only covers the mechanisms with which network 31 performance information is distributed. The mechanisms for measuring 32 network performance or acting on that information, once distributed, 33 are outside the scope of this document. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in RFC 2119 [RFC2119]. 41 In this document, these words will appear with that interpretation 42 only when in ALL CAPS. Lower case uses of these words are not to be 43 interpreted as carrying RFC-2119 significance. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at http://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on August 15, 2016. 62 Copyright Notice 64 Copyright (c) 2016 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (http://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2. TE Metric Extensions to IS-IS . . . . . . . . . . . . . . . . 4 81 3. Interface and Neighbor Addresses . . . . . . . . . . . . . . 5 82 4. Sub TLV Details . . . . . . . . . . . . . . . . . . . . . . . 6 83 4.1. Unidirectional Link Delay Sub-TLV . . . . . . . . . . . . 6 84 4.2. Min/Max Unidirectional Link Delay Sub-TLV . . . . . . . . 7 85 4.3. Unidirectional Delay Variation Sub-TLV . . . . . . . . . 8 86 4.4. Unidirectional Link Loss Sub-TLV . . . . . . . . . . . . 8 87 4.5. Unidirectional Residual Bandwidth Sub-TLV . . . . . . . . 9 88 4.6. Unidirectional Available Bandwidth Sub-TLV . . . . . . . 10 89 4.7. Unidirectional Utilized Bandwidth Sub-TLV . . . . . . . . 11 90 5. Announcement Thresholds and Filters . . . . . . . . . . . . . 12 91 6. Announcement Suppression . . . . . . . . . . . . . . . . . . 13 92 7. Network Stability and Announcement Periodicity . . . . . . . 13 93 8. Enabling and Disabling Sub-TLVs . . . . . . . . . . . . . . . 14 94 9. Static Metric Override . . . . . . . . . . . . . . . . . . . 14 95 10. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 14 96 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 97 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 98 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 99 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 100 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 101 15.1. Normative References . . . . . . . . . . . . . . . . . . 16 102 15.2. Informative References . . . . . . . . . . . . . . . . . 17 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 105 1. Introduction 107 In certain networks, such as, but not limited to, financial 108 information networks (e.g. stock market data providers), network 109 performance information (e.g. latency) is becoming as critical to 110 data path selection as other metrics. 112 In these networks, extremely large amounts of money rest on the 113 ability to access market data in "real time" and to predictably make 114 trades faster than the competition. Because of this, using metrics 115 such as hop count or cost as routing metrics is becoming only 116 tangentially important. Rather, it would be beneficial to be able to 117 make path selection decisions based on performance data (such as 118 latency) in a cost-effective and scalable way. 120 This document describes extensions (hereafter called "IS-IS TE Metric 121 Extensions") to IS-IS Extended Reachability TLV defined in [RFC5305], 122 that can be used to distribute network performance information (such 123 as link delay, delay variation, packet loss, residual bandwidth, and 124 available bandwidth). 126 The data distributed by the IS-IS TE Metric Extensions proposed in 127 this document is meant to be used as part of the operation of the 128 routing protocol (e.g. by replacing cost with latency or considering 129 bandwidth as well as cost), by enhancing Constrained-SPF (CSPF), or 130 for other uses such as supplementing the data used by an ALTO server 131 [RFC7285]. With respect to CSPF, the data distributed by IS-IS TE 132 Metric Extensions can be used to setup, fail over, and fail back data 133 paths using protocols such as RSVP-TE [RFC3209]. 135 Note that the mechanisms described in this document only disseminate 136 performance information. The methods for initially gathering that 137 performance information, such as [RFC6375], or acting on it once it 138 is distributed are outside the scope of this document. Example 139 mechanisms to measure latency, delay variation, and loss in an MPLS 140 network are given in [RFC6374]. While this document does not specify 141 how the performance information should be obtained, the measurement 142 of delay SHOULD NOT vary significantly based upon the offered traffic 143 load. Thus, queuing delays SHOULD NOT be included in the delay 144 measurement. For links such as Forwarding Adjacencies, care must be 145 taken that measurement of the associated delay avoids significant 146 queuing delay; that could be accomplished in a variety of ways, 147 including either by measuring with a traffic class that experiences 148 minimal queuing or by summing the measured link delays of the 149 components of the link's path. 151 2. TE Metric Extensions to IS-IS 153 This document proposes new IS-IS TE sub-TLVs that can be announced in 154 TLVs 22, 141, 222, and 223 in order to distribute network performance 155 information. The extensions in this document build on the ones 156 provided in IS-IS TE [RFC5305] and GMPLS [RFC4203]. 158 IS-IS Extended Reachability TLV 22 (defined in [RFC5305]), Inter-AS 159 reachability information TLV 141 (defined in [RFC5316]) and MT-ISIS 160 TLV 222 (defined in [RFC5120]) have nested sub-TLVs which permit the 161 TLVs to be readily extended. This document proposes several 162 additional sub-TLVs: 164 Type Value 165 ---------------------------------------------------- 166 33 (Suggested) Unidirectional Link Delay 168 34 (Suggested) Min/Max Unidirectional Link Delay 170 35 (Suggested) Unidirectional Delay Variation 172 36 (Suggested) Unidirectional Packet Loss 174 37 (Suggested) Unidirectional Residual Bandwidth 176 38 (Suggested) Unidirectional Available Bandwidth 178 39 (Suggested) Unidirectional Bandwidth Utilization 180 As can be seen in the list above, the sub-TLVs described in this 181 document carry different types of network performance information. 182 The new sub-TLVs include a bit called the Anomalous (or "A") bit. 183 When the A bit is clear (or when the sub-TLV does not include an A 184 bit), the sub-TLV describes steady state link performance. This 185 information could conceivably be used to construct a steady state 186 performance topology for initial tunnel path computation, or to 187 verify alternative failover paths. 189 When network performance violates configurable link-local thresholds 190 a sub-TLV with the A bit set is advertised. These sub-TLVs could be 191 used by the receiving node to determine whether to fail traffic to a 192 backup path, or whether to calculate an entirely new path. From an 193 MPLS perspective, the intent of the A bit is to permit LSP ingress 194 nodes to: 196 A) Determine whether the link referenced in the sub-TLV affects any 197 of the LSPs for which it is ingress. If there are, then: 199 B) Determine whether those LSPs still meet end-to-end performance 200 objectives. If not, then: 202 C) The node could then conceivably move affected traffic to a pre- 203 established protection LSP or establish a new LSP and place the 204 traffic in it. 206 If link performance then improves beyond a configurable minimum value 207 (reuse threshold), that sub-TLV can be re-advertised with the 208 Anomalous bit cleared. In this case, a receiving node can 209 conceivably do whatever re-optimization (or failback) it wishes to do 210 (including nothing). 212 Note that when a sub-TLV does not include the A bit, that sub-TLV 213 cannot be used for failover purposes. The A bit was intentionally 214 omitted from some sub-TLVs to help mitigate oscillations. See 215 Section 5 for more information. 217 Consistent with existing IS-IS TE specification [RFC5305], the 218 bandwidth advertisements defined in this draft MUST be encoded as 219 IEEE floating point values. The delay and delay variation 220 advertisements defined in this draft MUST be encoded as integer 221 values. Delay values MUST be quantified in units of microseconds, 222 packet loss MUST be quantified as a percentage of packets sent, and 223 bandwidth MUST be sent as bytes per second. All values (except 224 residual bandwidth) MUST be calculated as rolling averages where the 225 averaging period MUST be a configurable period of time. See 226 Section 5 for more information. 228 3. Interface and Neighbor Addresses 230 The use of IS-IS TE Metric Extensions sub-TLVs is not confined to the 231 TE context. In other words, IS-IS TE Metric Extensions sub-TLVs 232 defined in this document can also be used for computing paths in the 233 absence of a TE subsystem. 235 However, as for the TE case, Interface Address and Neighbor Address 236 sub-TLVs (IPv4 or IPv6) MUST be present. The encoding is defined in 237 [RFC5305] for IPv4 and in [RFC6119] for IPv6. 239 4. Sub TLV Details 241 4.1. Unidirectional Link Delay Sub-TLV 243 This sub-TLV advertises the average link delay between two directly 244 connected IS-IS neighbors. The delay advertised by this sub-TLV MUST 245 be the delay from the local neighbor to the remote one (i.e. the 246 forward path latency). The format of this sub-TLV is shown in the 247 following diagram: 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Type | Length | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 |A| RESERVED | Delay | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 where: 259 Figure 1 261 Type: TBA (suggested value: 33). 263 Length: 4. 265 A-bit. The A-bit represents the Anomalous (A) bit. The A-bit is set 266 when the measured value of this parameter exceeds its configured 267 maximum threshold. The A bit is cleared when the measured value 268 falls below its configured reuse threshold. If the A-bit is clear, 269 the sub-TLV represents steady state link performance. 271 RESERVED. This field is reserved for future use. It MUST be set to 272 0 when sent and MUST be ignored when received. 274 Delay. This 24-bit field carries the average link delay over a 275 configurable interval in micro-seconds, encoded as an integer value. 276 When set to the maximum value 16,777,215 (16.777215 sec), then the 277 delay is at least that value and may be larger. 279 4.2. Min/Max Unidirectional Link Delay Sub-TLV 281 This sub-TLV advertises the minimum and maximum delay values between 282 two directly connected IS-IS neighbors. The delay advertised by this 283 sub-TLV MUST be the delay from the local neighbor to the remote one 284 (i.e. the forward path latency). The format of this sub-TLV is shown 285 in the following diagram: 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Type | Length | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 |A| RESERVED | Min Delay | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | RESERVED | Max Delay | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 where: 299 Figure 2 301 Type: TBA (suggested value: 34). 303 Length: 8. 305 This field represents the Anomalous (A) bit. The A bit is set when 306 one or more measured values exceed a configured maximum threshold. 307 The A bit is cleared when the measured value falls below its 308 configured reuse threshold. If the A bit is clear, the sub-TLV 309 represents steady state link performance. 311 RESERVED. This field is reserved for future use. It MUST be set to 312 0 when sent and MUST be ignored when received. 314 Min Delay. This 24-bit field carries minimum measured link delay 315 value (in microseconds) over a configurable interval, encoded as an 316 integer value. 318 Max Delay. This 24-bit field carries the maximum measured link delay 319 value (in microseconds) over a configurable interval, encoded as an 320 integer value. 322 Implementations MAY also permit the configuration of an offset value 323 (in microseconds) to be added to the measured delay value, to 324 facilitate the communication of operator specific delay constraints. 326 It is possible for the Min and Max delay to be the same value. 328 When the delay value (Min or Max) is set to maximum value 16,777,215 329 (16.777215 sec), then the delay is at least that value and may be 330 larger. 332 4.3. Unidirectional Delay Variation Sub-TLV 334 This sub-TLV advertises the average link delay variation between two 335 directly connected IS-IS neighbors. The delay variation advertised 336 by this sub-TLV MUST be the delay from the local neighbor to the 337 remote one (i.e. the forward path latency). The format of this sub- 338 TLV is shown in the following diagram: 340 0 1 2 3 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Type | Length | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | RESERVED | Delay Variation | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 where: 350 Figure 3 352 Type: TBA (suggested value: 35). 354 Length: 4. 356 RESERVED. This field is reserved for future use. It MUST be set to 357 0 when sent and MUST be ignored when received. 359 Delay Variation. This 24-bit field carries the average link delay 360 variation over a configurable interval in microseconds, encoded as an 361 integer value. When set to 0, it has not been measured. When set to 362 the maximum value 16,777,215 (16.777215 sec), then the delay is at 363 least that value and may be larger. 365 4.4. Unidirectional Link Loss Sub-TLV 367 This sub-TLV advertises the loss (as a packet percentage) between two 368 directly connected IS-IS neighbors. The link loss advertised by this 369 sub-TLV MUST be the packet loss from the local neighbor to the remote 370 one (i.e. the forward path loss). The format of this sub-TLV is 371 shown in the following diagram: 373 0 1 2 3 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Type | Length | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 |A| RESERVED | Link Loss | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 This sub-TLV has a type of TBD3. 382 The length is 4. 384 where: 386 Type: TBA (suggested value: 36). 388 Length: 4. 390 A-bit. The A-bit represents the Anomalous (A) bit. The A-bit is set 391 when the measured value of this parameter exceeds its configured 392 maximum threshold. The A bit is cleared when the measured value 393 falls below its configured reuse threshold. If the A-bit is clear, 394 the sub-TLV represents steady state link performance. 396 RESERVED. This field is reserved for future use. It MUST be set to 397 0 when sent and MUST be ignored when received. 399 Link Loss. This 24-bit field carries link packet loss as a 400 percentage of the total traffic sent over a configurable interval. 401 The basic unit is 0.000003%, where (2^24 - 2) is 50.331642%. This 402 value is the highest packet loss percentage that can be expressed 403 (the assumption being that precision is more important on high speed 404 links than the ability to advertise loss rates greater than this, and 405 that high speed links with over 50% loss are unusable). Therefore, 406 measured values that are larger than the field maximum SHOULD be 407 encoded as the maximum value. 409 4.5. Unidirectional Residual Bandwidth Sub-TLV 411 This sub-TLV advertises the residual bandwidth between two directly 412 connected IS-IS neighbors. The residual bandwidth advertised by this 413 sub-TLV MUST be the residual bandwidth from the system originating 414 the LSA to its neighbor. 416 0 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Type | Length | RESERVED | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Residual Bandwidth | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 where: 426 Type: TBA (suggested value: 37). 428 Length: 4. 430 RESERVED. This field is reserved for future use. It MUST be set to 431 0 when sent and MUST be ignored when received. 433 Residual Bandwidth. This field carries the residual bandwidth on a 434 link, forwarding adjacency [RFC4206], or bundled link in IEEE 435 floating point format with units of bytes per second. For a link or 436 forwarding adjacency, residual bandwidth is defined to be Maximum 437 Bandwidth [RFC5305] minus the bandwidth currently allocated to RSVP- 438 TE LSPs. For a bundled link, residual bandwidth is defined to be the 439 sum of the component link residual bandwidths. 441 The calculation of Residual Bandwidth is different than that of 442 Unreserved Bandwidth [RFC5305]. Residual Bandwidth subtracts tunnel 443 reservations from Maximum Bandwidth (i.e. the link capacity) 444 [RFC5305] and provides an aggregated remainder across priorities. 445 Unreserved Bandwidth, on the other hand, is subtracted from the 446 Maximum Reservable Bandwidth (the bandwidth that can theoretically be 447 reserved) and provides per priority remainders. Residual Bandwidth 448 and Unreserved Bandwidth [RFC5305] can be used concurrently, and each 449 has a separate use case (e.g. the former can be used for applications 450 like Weighted ECMP while the latter can be used for call admission 451 control). 453 4.6. Unidirectional Available Bandwidth Sub-TLV 455 This sub-TLV advertises the available bandwidth between two directly 456 connected IS-IS neighbors. The available bandwidth advertised by 457 this sub-TLV MUST be the available bandwidth from the system 458 originating this sub-TLV. The format of this sub-TLV is shown in the 459 following diagram: 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Type | Length | RESERVED | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Available Bandwidth | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 where: 471 Figure 4 473 Type: TBA (suggested value: 38). 475 Length: 4. 477 RESERVED. This field is reserved for future use. It MUST be set to 478 0 when sent and MUST be ignored when received. 480 Available Bandwidth. This field carries the available bandwidth on a 481 link, forwarding adjacency, or bundled link in IEEE floating point 482 format with units of bytes per second. For a link or forwarding 483 adjacency, available bandwidth is defined to be residual bandwidth 484 (see Section 4.5 minus the measured bandwidth used for the actual 485 forwarding of non-RSVP-TE LSP packets. For a bundled link, available 486 bandwidth is defined to be the sum of the component link available 487 bandwidths minus the measured bandwidth used for the actual 488 forwarding of non-RSVP-TE Label Switched Paths packets. For a 489 bundled link, available bandwidth is defined to be the sum of the 490 component link available bandwidths. 492 4.7. Unidirectional Utilized Bandwidth Sub-TLV 494 This sub-TLV advertises the bandwidth utilization between two 495 directly connected IS-IS neighbors. The bandwidth utilization 496 advertised by this sub-TLV MUST be the bandwidth from the system 497 originating this sub-TLV. The format of this sub-TLV is shown in the 498 following diagram: 500 0 1 2 3 501 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 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Type | Length | RESERVED | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Utilized Bandwidth | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 where: 510 Figure 5 512 Type: TBA (suggested value: 39). 514 Length: 4. 516 RESERVED. This field is reserved for future use. It MUST be set to 517 0 when sent and MUST be ignored when received. 519 This field carries the bandwidth utilization on a link, forwarding 520 adjacency, or bundled link in IEEE floating-point format with units 521 of bytes per second. For a link or forwarding adjacency, bandwidth 522 utilization represents the actual utilization of the link (i.e., as 523 measured by the advertising node). For a bundled link, bandwidth 524 utilization is defined to be the sum of the component link bandwidth 525 utilizations. 527 5. Announcement Thresholds and Filters 529 The values advertised in all sub-TLVs (except Min/Max delay and 530 residual bandwidth) MUST represent an average over a period or be 531 obtained by a filter that is reasonably representative of an average. 532 For example, a rolling average is one such filter. 534 Min and max delay MUST each be derived in one of the following ways: 535 by taking the lowest and/or highest measured value over a measurement 536 interval, or by making use of a filter or other technique to obtain a 537 reasonable representation of a min and max value representative of 538 the interval, with compensation for outliers. 540 The measurement interval, any filter coefficients, and any 541 advertisement intervals MUST be configurable per sub-TLV. 543 In addition to the measurement intervals governing re-advertisement, 544 implementations SHOULD provide per sub-TLV configurable accelerated 545 advertisement thresholds, such that: 547 1. If the measured parameter falls outside a configured upper 548 bound for all but the min delay metric (or lower bound for 549 min delay metric only) and the advertised sub-TLV is not 550 already outside that bound or, 552 2. If the difference between the last advertised value and 553 current measured value exceed a configured threshold then, 555 3. The advertisement is made immediately. 557 4. For sub-TLVs which include an A-bit, an additional 558 threshold SHOULD be included corresponding to the 559 threshold for which the performance is considered 560 anomalous (and sub-TLVs with the A-bit are sent). The 561 A-bit is cleared when the sub-TLV's performance has 562 been below (or re-crosses) this threshold for an 563 advertisement interval(s) to permit fail back. 565 To prevent oscillations, only the high threshold or the low threshold 566 (but not both) may be used to trigger any given sub-TLV that supports 567 both. 569 Additionally, once outside of the bounds of the threshold, any 570 readvertisement of a measurement within the bounds would remain 571 governed solely by the measurement interval for that sub-TLV. 573 6. Announcement Suppression 575 When link performance values change by small amounts that fall under 576 thresholds that would cause the announcement of a sub-TLV, 577 implementations SHOULD suppress sub-TLV readvertisement and/or 578 lengthen the period within which they are refreshed. 580 Only the accelerated advertisement threshold mechanism described in 581 Section 5 may shorten the re-advertisement interval. All suppression 582 and re-advertisement interval backoff timer features SHOULD be 583 configurable. 585 7. Network Stability and Announcement Periodicity 587 Section 5 and Section 6 provide configurable mechanisms to bound the 588 number of re-advertisements. Instability might occur in very large 589 networks if measurement intervals are set low enough to overwhelm the 590 processing of flooded information at some of the routers in the 591 topology. Therefore care should be taken in setting these values. 593 Additionally, the default measurement interval for all sub-TLVs 594 SHOULD be 30 seconds. 596 Announcements MUST also be able to be throttled using configurable 597 inter-update throttle timers. The minimum announcement periodicity 598 is 1 announcement per second. The default value SHOULD be set to 120 599 seconds. 601 Implementations SHOULD NOT permit the inter-update timer to be lower 602 than the measurement interval. 604 Furthermore, it is RECOMMENDED that any underlying performance 605 measurement mechanisms not include any significant buffer delay, any 606 significant buffer induced delay variation, or any significant loss 607 due to buffer overflow or due to active queue management. 609 8. Enabling and Disabling Sub-TLVs 611 Implementations MUST make it possible to individually enable or 612 disable each sub-TLV based on configuration. 614 9. Static Metric Override 616 Implementations SHOULD permit the static configuration and/or manual 617 override of dynamic measurements for each sub-TLV in order to 618 simplify migration and to mitigate scenarios where dynamic 619 measurements are not possible. 621 10. Compatibility 623 As per [RFC5305], unrecognized sub-TLVs should be silently ignored. 625 11. Security Considerations 627 The subTLVs introduced in this document allow an operator to 628 advertise state information of links (bandwidth, delay) that could be 629 sensitive and that an operator may not want to disclose. 631 Section 7 describe a mechanism in order to ensure network stability 632 when the new sub-TLVs defined in this document are advertised. 633 Implementation SHOULD follow the described guidelines in order to 634 mitigate the instability risk. 636 [RFC5304] describes an authentication method for IS-IS LSP that 637 allows cryptographic authentication of IS-IS LSPs. 639 It is anticipated that in most deployments, IS-IS protocol is used 640 within an infrastructure entirely under control of the same operator. 641 However, it is worth to consider that the effect of sending IS-IS 642 Traffic Engineering sub-TLVs over insecure links could result in a 643 man-in-the-middle attacker delaying real time data to a given site 644 (or destination), which could negatively affect the value of the data 645 for that site/destination. The use of LSP cryptographic 646 authentication allows to mitigate the risk of man-in-the-middle 647 attack. 649 12. IANA Considerations 651 IANA maintains the registry for the sub-TLVs. IS-IS TE Metric 652 Extensions will require one new type code per sub-TLV defined in this 653 document in the following sub-TLV registry: TLVs 22, 23, 141, 222, 654 and 223: 656 Type Value 657 ---------------------------------------------------- 658 33 (Suggested) Unidirectional Link Delay 660 34 (Suggested) Min/Max Unidirectional Link Delay 662 35 (Suggested) Unidirectional Delay Variation 664 36 (Suggested) Unidirectional Packet Loss 666 37 (Suggested) Unidirectional Residual Bandwidth 668 38 (Suggested) Unidirectional Available Bandwidth 670 39 (Suggested) Unidirectional Bandwidth Utilization 672 13. Contributors 674 The following people gave a substantial contribution to the content 675 of this document and should be considered as co-authors: 677 Alia Atlas 678 Juniper Networks 679 US 681 akatlas@juniper.net 683 Clarence Filsfils 684 Cisco Systems Inc. 685 Belgium 687 Email: cfilsfil@cisco.com 689 14. Acknowledgements 691 The authors would like to recognize Ayman Soliman, Nabil Bitar, David 692 McDysan, Les Ginsberg, Edward Crabbe, Don Fedyk, Hannes Gredler, Uma 693 Chunduri, Alvaro Retana, Brian Weis and Barry Leiba for their 694 contribution and review of this document. 696 The authors also recognize Curtis Villamizar for significant comments 697 and direct content collaboration. 699 15. References 701 15.1. Normative References 703 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 704 Requirement Levels", BCP 14, RFC 2119, 705 DOI 10.17487/RFC2119, March 1997, 706 . 708 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 709 Hierarchy with Generalized Multi-Protocol Label Switching 710 (GMPLS) Traffic Engineering (TE)", RFC 4206, 711 DOI 10.17487/RFC4206, October 2005, 712 . 714 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 715 Topology (MT) Routing in Intermediate System to 716 Intermediate Systems (IS-ISs)", RFC 5120, 717 DOI 10.17487/RFC5120, February 2008, 718 . 720 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 721 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 722 2008, . 724 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 725 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 726 2008, . 728 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 729 Support of Inter-Autonomous System (AS) MPLS and GMPLS 730 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 731 December 2008, . 733 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 734 Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, 735 February 2011, . 737 15.2. Informative References 739 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 740 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 741 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 742 . 744 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 745 Support of Generalized Multi-Protocol Label Switching 746 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 747 . 749 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 750 Measurement for MPLS Networks", RFC 6374, 751 DOI 10.17487/RFC6374, September 2011, 752 . 754 [RFC6375] Frost, D., Ed. and S. Bryant, Ed., "A Packet Loss and 755 Delay Measurement Profile for MPLS-Based Transport 756 Networks", RFC 6375, DOI 10.17487/RFC6375, September 2011, 757 . 759 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 760 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 761 "Application-Layer Traffic Optimization (ALTO) Protocol", 762 RFC 7285, DOI 10.17487/RFC7285, September 2014, 763 . 765 Authors' Addresses 767 Stefano Previdi (editor) 768 Cisco Systems, Inc. 769 Via Del Serafico 200 770 Rome 00191 771 IT 773 Email: sprevidi@cisco.com 775 Spencer Giacalone 776 Unaffiliated 778 Email: spencer.giacalone@gmail.com 779 Dave Ward 780 Cisco Systems, Inc. 781 3700 Cisco Way 782 SAN JOSE, CA 95134 783 US 785 Email: wardd@cisco.com 787 John Drake 788 Juniper Networks 789 1194 N. Mathilda Ave. 790 Sunnyvale, CA 94089 791 USA 793 Email: jdrake@juniper.net 795 Qin Wu 796 Huawei 797 101 Software Avenue, Yuhua District 798 Nanjing, Jiangsu 210012 799 China 801 Email: sunseawq@huawei.com