idnits 2.17.1 draft-ietf-ospf-te-metric-extensions-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3630]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 165 has weird spacing: '...Example mech...' == Line 606 has weird spacing: '...figured upper...' -- The document date (November 11, 2014) is 3425 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: 'RFC4203' is mentioned on line 193, but not defined == Missing Reference: 'RFC4206' is mentioned on line 501, but not defined == Missing Reference: 'RFC5329' is mentioned on line 687, but not defined == Unused Reference: 'RFC2328' is defined on line 724, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 726, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Giacalone 2 Internet Draft Unaffiliated 3 Intended status: Proposed Standard 4 Expires: May 2015 D. Ward 5 Cisco Systems 7 J. Drake 8 Juniper Networks 10 A. Atlas 11 Juniper Networks 13 S. Previdi 14 Cisco Systems 16 November 11, 2014 18 OSPF Traffic Engineering (TE) Metric Extensions 19 draft-ietf-ospf-te-metric-extensions-07.txt 21 Abstract 23 In certain networks, such as, but not limited to, financial 24 information networks (e.g. stock market data providers), network 25 performance criteria (e.g. latency) are becoming as critical to data 26 path selection as other metrics. 28 This document describes extensions to OSPF TE [RFC3630] such that 29 network performance information can be distributed and collected in a 30 scalable fashion. The information distributed using OSPF TE Metric 31 Extensions can then be used to make path selection decisions based on 32 network performance. 34 Note that this document only covers the mechanisms with which network 35 performance information is distributed. The mechanisms for measuring 36 network performance or acting on that information, once distributed, 37 are outside the scope of this document. 39 Status of this Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF), its areas, and its working groups. Note that 46 other groups may also distribute working documents as Internet- 47 Drafts. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 The list of current Internet-Drafts can be accessed at 55 http://www.ietf.org/ietf/1id-abstracts.txt 57 The list of Internet-Draft Shadow Directories can be accessed at 58 http://www.ietf.org/shadow.html 60 This Internet-Draft will expire on May 11, 2015. 62 Copyright Notice 64 Copyright (c) 2014 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...................................................4 80 2. Conventions used in this document..............................5 81 3. TE Metric Extensions to OSPF TE................................5 82 4. Sub TLV Details................................................7 83 4.1. Unidirectional Link Delay Sub-TLV.........................7 84 4.1.1. Type.................................................7 85 4.1.2. Length...............................................7 86 4.1.3. A bit................................................7 87 4.1.4. Reserved.............................................7 88 4.1.5. Delay Value..........................................8 89 4.2. Min/Max Unidirectional Link Delay Sub-TLV.................8 90 4.2.1. Type.................................................8 91 4.2.2. Length...............................................8 92 4.2.3. A bit................................................8 93 4.2.4. Reserved.............................................9 94 4.2.5. Min Delay............................................9 95 4.2.6. Max Delay............................................9 96 4.2.7. Reserved.............................................9 97 4.3. Unidirectional Delay Variation Sub-TLV....................9 98 4.3.1. Type................................................10 99 4.3.2. Length..............................................10 100 4.3.3. Reserved............................................10 101 4.3.4. Delay Variation.....................................10 102 4.4. Unidirectional Link Loss Sub-TLV.........................10 103 4.4.1. Type................................................11 104 4.4.2. Length..............................................11 105 4.4.3. A bit...............................................11 106 4.4.4. Reserved............................................11 107 4.4.5. Link Loss...........................................11 108 4.5. Unidirectional Residual Bandwidth Sub-TLV................11 109 4.5.1. Type................................................12 110 4.5.2. Length..............................................12 111 4.5.3. Residual Bandwidth..................................12 112 4.6. Unidirectional Available Bandwidth Sub-TLV...............13 113 4.6.1. Type................................................13 114 4.6.2. Length..............................................13 115 4.6.3. Available Bandwidth.................................13 116 4.7. Unidirectional Utilized Bandwidth Sub-TLV................13 117 4.7.1. Type................................................14 118 4.7.2. Length..............................................14 119 4.7.3. Utilized Bandwidth..................................14 120 5. Announcement Thresholds and Filters...........................14 121 6. Announcement Suppression......................................15 122 7. Network Stability and Announcement Periodicity................15 123 8. Enabling and Disabling Sub-TLVs...............................16 124 9. Static Metric Override........................................16 125 10. Compatibility................................................16 126 11. Security Considerations......................................17 127 12. IANA Considerations..........................................17 128 13. References...................................................17 129 13.1. Normative References....................................17 130 13.2. Informative References..................................18 131 14. Acknowledgments..............................................18 132 15. Author's Addresses...........................................19 134 1. Introduction 136 In certain networks, such as, but not limited to, financial 137 information networks (e.g. stock market data providers), network 138 performance information (e.g. latency) is becoming as critical to 139 data path selection as other metrics. 141 In these networks, extremely large amounts of money rest on the 142 ability to access market data in "real time" and to predictably make 143 trades faster than the competition. Because of this, using metrics 144 such as hop count or cost as routing metrics is becoming only 145 tangentially important. Rather, it would be beneficial to be able to 146 make path selection decisions based on performance data (such as 147 latency) in a cost-effective and scalable way. 149 This document describes extensions to OSPF TE (hereafter called "OSPF 150 TE Metric Extensions"), that can be used to distribute network 151 performance information (viz link delay, delay variation, link loss, 152 residual bandwidth, available bandwidth, and utilized bandwidth). 154 The data distributed by OSPF TE Metric Extensions is meant to be used 155 as part of the operation of the routing protocol (e.g. by replacing 156 cost with latency or considering bandwidth as well as cost), by 157 enhancing CSPF, or for use by a PCE [RFC4655] or an Alto server 158 [RFC7285]. With respect to CSPF, the data distributed by OSPF TE 159 Metric Extensions can be used to setup, fail over, and fail back data 160 paths using protocols such as RSVP-TE [RFC3209]. 162 Note that the mechanisms described in this document only disseminate 163 performance information. The methods for initially gathering that 164 performance information or acting on it once it is distributed are 165 outside the scope of this document. Example mechanisms to measure 166 latency, delay variation, and loss in an MPLS network are given in 167 [RFC6374]. While this document does not specify how the performance 168 information should be obtained, the measurement of delay SHOULD NOT 169 vary significantly based upon the offered traffic load. Thus, 170 queuing delays and/or loss SHOULD NOT be included in any dynamic 171 delay measurement. For links, such as Forwarding Adjacencies, care 172 must be taken that measurement of the associated delay avoids 173 significant queuing delay; that could be accomplished in a variety 174 of ways, including either by measuring with a traffic class that 175 experiences minimal queuing or by summing the measured link delays 176 of the components of the link's path. 178 2. Conventions used in this document 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in RFC-2119 [RFC2119]. 184 In this document, these words will appear with that interpretation 185 only when in ALL CAPS. Lower case uses of these words are not to be 186 interpreted as carrying RFC-2119 significance. 188 3. TE Metric Extensions to OSPF TE 190 This document proposes new OSPF TE sub-TLVs that can be announced in 191 OSPF TE LSAs to distribute network performance information. The 192 extensions in this document build on the ones provided in OSPF TE 193 [RFC3630] and GMPLS [RFC4203]. 195 OSPF TE LSAs [RFC3630] are opaque LSAs [RFC5250] with area flooding 196 scope. Each TLV has one or more nested sub-TLVs which permit the TE 197 LSA to be readily extended. There are two main types of OSPF TE LSA; 198 the Router Address or Link TE LSA. Like the extensions in GMPLS 199 (RFC4203), this document proposes several additional sub-TLVs for 200 the Link TE LSA: 202 Type Length Value 204 TBD1 4 Unidirectional Link Delay 206 TBD2 8 Min/Max Unidirectional Link Delay 208 TBD3 4 Unidirectional Delay Variation 210 TBD4 4 Unidirectional Link Loss 212 TBD5 4 Unidirectional Residual Bandwidth 214 TBD6 4 Unidirectional Available Bandwidth 216 TBD7 4 Unidirectional Utilized Bandwidth 217 As can be seen in the list above, the sub-TLVs described in this 218 document carry different types of network performance information. 219 Many (but not all) of the sub-TLVs include a bit called the Anomalous 220 (or "A") bit. When the A bit is clear (or when the sub-TLV does not 221 include an A bit), the sub-TLV describes steady state link 222 performance. This information could conceivably be used to construct 223 a steady state performance topology for initial tunnel path 224 computation, or to verify alternative failover paths. 226 When network performance violates configurable link-local thresholds 227 a sub-TLV with the A bit set is advertised. These sub-TLVs could be 228 used by the receiving node to determine whether to fail traffic to a 229 backup path, or whether to calculate an entirely new path. From an 230 MPLS perspective, the intent of the A bit is to permit LSP ingress 231 nodes to: 233 A) Determine whether the link referenced in the sub-TLV affects any 234 of the LSPs for which it is ingress. If there are, then: 236 B) The node determines whether those LSPs still meet end-to-end 237 performance objectives. If not, then: 239 C) The node could then conceivably move affected traffic to a pre- 240 established protection LSP or establish a new LSP and place the 241 traffic in it. 243 If link performance then improves beyond a configurable minimum 244 value (reuse threshold), that sub-TLV can be re-advertised with the 245 Anomalous bit cleared. In this case, a receiving node can 246 conceivably do whatever re-optimization (or failback) it wishes to 247 do (including nothing). 249 Note that when a sub-TLV does not include the A bit, that sub-TLV 250 cannot be used for failover purposes. The A bit was intentionally 251 omitted from some sub-TLVs to help mitigate oscillations. See section 252 7. 1. for more information. 254 Link delay, delay variation, and link loss MUST be encoded as 255 integers. Consistent with existing OSPF TE specifications [RFC3630], 256 residual, available, and utilized bandwidth MUST be encoded in IEEE 257 floating point. Link delay and delay variation MUST be in units of 258 microseconds, link loss MUST be a percentage, and bandwidth MUST be 259 in units of bytes per second. All values (except residual bandwidth) 260 MUST be calculated as rolling averages where the averaging period 261 MUST be a configurable period of time. See section 5. for more 262 information. 264 4. Sub TLV Details 266 4.1. Unidirectional Link Delay Sub-TLV 268 This sub-TLV advertises the average link delay between two directly 269 connected OSPF neighbors. The delay advertised by this sub-TLV MUST 270 be the delay from the local neighbor to the remote one (i.e. the 271 forward path delay). The format of this sub-TLV is shown in the 272 following diagram: 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | TBD1 | 4 | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 |A| RESERVED | Delay | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 4.1.1. Type 284 This sub-TLV has a type of TBD1. 286 4.1.2. Length 288 The length is 4. 290 4.1.3. A bit 292 This field represents the Anomalous (A) bit. The A bit is set when 293 the measured value of this parameter exceeds its configured maximum 294 threshold. The A bit is cleared when the measured value falls below 295 its configured reuse threshold. If the A bit is clear, the sub-TLV 296 represents steady state link performance. 298 4.1.4. Reserved 300 This field is reserved for future use. It MUST be set to 0 when sent 301 and MUST be ignored when received. 303 4.1.5. Delay Value 305 This 24-bit field carries the average link delay over a configurable 306 interval in micro-seconds, encoded as an integer value. When set to 307 the maximum value 16,777,215 (16.777215 sec), then the delay is at 308 least that value and may be larger. If there is no value to send 309 (unmeasured and not statically specified), then the sub-TLV should 310 not be sent or be withdrawn. 312 4.2. Min/Max Unidirectional Link Delay Sub-TLV 314 This sub-TLV advertises the minimum and maximum delay values between 315 two directly connected OSPF neighbors. The delay advertised by this 316 sub-TLV MUST be the delay from the local neighbor to the remote one 317 (i.e. the forward path delay). The format of this sub-TLV is shown in 318 the following diagram: 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | TBD2 | 8 | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 |A| RESERVED | Min Delay | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | RESERVED | Max Delay | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 4.2.1. Type 332 This sub-TLV has a type of TBD2. 334 4.2.2. Length 336 The length is 8. 338 4.2.3. A bit 340 This field represents the Anomalous (A) bit. The A bit is set when 341 one or more measured values exceed a configured maximum threshold. 342 The A bit is cleared when the measured value falls below its 343 configured reuse threshold. If the A bit is clear, the sub-TLV 344 represents steady state link performance. 346 4.2.4. Reserved 348 This field is reserved for future use. It MUST be set to 0 when sent 349 and MUST be ignored when received. 351 4.2.5. Min Delay 353 This 24-bit field carries minimum measured link delay value (in 354 microseconds) over a configurable interval, encoded as an integer 355 value. 357 Implementations MAY also permit the configuration of a static (non 358 dynamic) offset value (in microseconds) to be added to the measured 359 delay value, to facilitate the communication of operator specific 360 delay constraints. 362 When set to the maximum value 16,777,215 (16.777215 sec), then the 363 delay is at least that value and may be larger. 365 4.2.6. Max Delay 367 This 24-bit field carries the maximum measured link delay value (in 368 microseconds) over a configurable interval, encoded as an integer 369 value. 371 Implementations MAY also permit the configuration of a static (non 372 dynamic) offset value (in microseconds) to be added to the measured 373 delay value, to facilitate the communication of operator specific 374 delay constraints. 376 It is possible for min delay and max delay to be the same value. 378 When the delay value is set to maximum value 16,777,215 (16.777215 379 sec), then the delay is at least that value and may be larger. 381 4.2.7. Reserved 383 This field is reserved for future use. It MUST be set to 0 when sent 384 and MUST be ignored when received. 386 4.3. Unidirectional Delay Variation Sub-TLV 388 This sub-TLV advertises the average link delay variation between two 389 directly connected OSPF neighbors. The delay variation advertised by 390 this sub-TLV MUST be the delay from the local neighbor to the remote 391 one (i.e. the forward path delay variation). The format of this sub- 392 TLV is shown in the following diagram: 394 0 1 2 3 395 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 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | TBD3 | 4 | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | RESERVED | Delay Variation | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 4.3.1. Type 404 This sub-TLV has a type of TBD3. 406 4.3.2. Length 408 The length is 4. 410 4.3.3. Reserved 412 This field is reserved for future use. It MUST be set to 0 when sent 413 and MUST be ignored when received. 415 4.3.4. Delay Variation 417 This 24-bit field carries the average link delay variation over a 418 configurable interval in micro-seconds, encoded as an integer value. 419 When set to 0, it has not been measured. When set to the maximum 420 value 16,777,215 (16.777215 sec), then the delay is at least that 421 value and may be larger. 423 4.4. Unidirectional Link Loss Sub-TLV 425 This sub-TLV advertises the loss (as a packet percentage) between two 426 directly connected OSPF neighbors. The link loss advertised by this 427 sub-TLV MUST be the packet loss from the local neighbor to the remote 428 one (i.e. the forward path loss). The format of this sub-TLV is shown 429 in the following diagram: 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | TBD4 | 4 | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 |A| RESERVED | Link Loss | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 4.4.1. Type 441 This sub-TLV has a type of TBD4 443 4.4.2. Length 445 The length is 4. 447 4.4.3. A bit 449 This field represents the Anomalous (A) bit. The A bit is set when 450 the measured value of this parameter exceeds its configured maximum 451 threshold. The A bit is cleared when the measured value falls below 452 its configured reuse threshold. If the A bit is clear, the sub-TLV 453 represents steady state link performance. 455 4.4.4. Reserved 457 This field is reserved for future use. It MUST be set to 0 when sent 458 and MUST be ignored when received. 460 4.4.5. Link Loss 462 This 24-bit field carries link packet loss as a percentage of the 463 total traffic sent over a configurable interval. The basic unit is 464 0.000003%, where (2^24 - 2) is 50.331642%. This value is the highest 465 packet loss percentage that can be expressed (the assumption being 466 that precision is more important on high speed links than the ability 467 to advertise loss rates greater than this, and that high speed links 468 with over 50% loss are unusable). Therefore, measured values that are 469 larger than the field maximum SHOULD be encoded as the maximum value. 470 When set to a value of all 1s (2^24 - 1), the link packet loss has 471 not been measured. 473 4.5. Unidirectional Residual Bandwidth Sub-TLV 475 This sub-TLV advertises the residual bandwidth between two directly 476 connected OSPF neighbors. The residual bandwidth advertised by this 477 sub-TLV MUST be the residual bandwidth from the system originating 478 the LSA to its neighbor. 480 The format of this sub-TLV is shown in the following diagram: 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | TBD5 | 4 | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Residual Bandwidth | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 4.5.1. Type 492 This sub-TLV has a type of TBD5. 494 4.5.2. Length 496 The length is 4. 498 4.5.3. Residual Bandwidth 500 This field carries the residual bandwidth on a link, forwarding 501 adjacency [RFC4206], or bundled link in IEEE floating point format 502 with units of bytes per second. For a link or forwarding adjacency, 503 residual bandwidth is defined to be Maximum Bandwidth [RFC3630] minus 504 the bandwidth currently allocated to RSVP-TE LSPs. For a bundled 505 link, residual bandwidth is defined to be the sum of the component 506 link residual bandwidths. 508 The calculation of Residual Bandwidth is different than that of 509 Unreserved Bandwidth [RFC3630]. Residual Bandwidth subtracts tunnel 510 reservations from Maximum Bandwidth (i.e. the link capacity) 511 [RFC3630] and provides an aggregated remainder across QoS classes. 512 Unreserved Bandwidth [RFC3630], on the other hand, is subtracted from 513 the Maximum Reservable Bandwidth (the bandwidth that can 514 theoretically be reserved) [RFC3630] and provides per-QoS-class 515 remainders. Residual Bandwidth and Unreserved Bandwidth [RFC3630] can 516 be used concurrently, and each has a separate use case (e.g. the 517 former can be used for applications like Weighted ECMP while the 518 latter can be used for call admission control). 520 4.6. Unidirectional Available Bandwidth Sub-TLV 522 This TLV advertises the available bandwidth between two directly 523 connected OSPF neighbors. The available bandwidth advertised by this 524 sub-TLV MUST be the available bandwidth from the system originating 525 the LSA to its neighbor. The format of this sub-TLV is shown in the 526 following diagram: 528 0 1 2 3 529 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 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | TBD6 | 4 | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Available Bandwidth | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 4.6.1. Type 538 This sub-TLV has a type of TBD6. 540 4.6.2. Length 542 The length is 4. 544 4.6.3. Available Bandwidth 546 This field carries the available bandwidth on a link, forwarding 547 adjacency, or bundled link in IEEE floating point format with units 548 of bytes per second. For a link or forwarding adjacency, available 549 bandwidth is defined to be residual bandwidth (see section 4.5. ) 550 minus the measured bandwidth used for the actual forwarding of non- 551 RSVP-TE LSP packets. For a bundled link, available bandwidth is 552 defined to be the sum of the component link available bandwidths. 554 4.7. Unidirectional Utilized Bandwidth Sub-TLV 556 This Sub-TLV advertises the bandwidth utilization between two 557 directly connected OSPF neighbors. The bandwidth utilization 558 advertised by this sub-TLV MUST be the bandwidth from the system 559 originating this Sub-TLV. The format of this Sub-TLV is shown in the 560 following diagram: 562 0 1 2 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | TBD7 | 4 | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Utilized Bandwidth | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 4.7.1. Type 572 This sub-TLV has a type of TBD7. 574 4.7.2. Length 576 The length is 4. 578 4.7.3. Utilized Bandwidth 580 This field carries the bandwidth utilization on a link, forwarding 581 adjacency, or bundled link in IEEE floating point format with units 582 of bytes per second. For a link or forwarding adjacency, bandwidth 583 utilization represents the actual utilization of the link (i.e. as 584 measured in the router). For a bundled link, bandwidth utilization is 585 defined to be the sum of the component link bandwidth utilizations. 587 5. Announcement Thresholds and Filters 589 The values advertised in all sub-TLVs (except min/max delay and 590 residual bandwidth) MUST represent an average over a period or be 591 obtained by a filter that is reasonably representative of an 592 average. For example, a rolling average is one such filter. 594 Min and max delay MAY be the lowest and/or highest measured value 595 over a measurement interval or MAY make use of a filter, or other 596 technique to obtain a reasonable representation of a min and max 597 value representative of the interval with compensation for outliers. 599 The measurement interval, any filter coefficients, and any 600 advertisement intervals MUST be configurable per sub-TLV. 602 In addition to the measurement intervals governing re-advertisement, 603 implementations SHOULD provide per sub-TLV configurable accelerated 604 advertisement thresholds, such that: 606 1. If the measured parameter falls outside a configured upper bound 607 for all but the min delay metric (or lower bound for min delay 608 metric only) and the advertised sub-TLV is not already outside 609 that bound or, 611 2. If the difference between the last advertised value and current 612 measured value exceed a configured threshold then, 614 3. The advertisement is made immediately. 616 4. For sub-TLVs which include an A-bit (except min/max delay), an 617 additional threshold SHOULD be included corresponding to the 618 threshold for which the performance is considered anomalous (and 619 sub-TLVs with the A bit are sent). The A-bit is cleared when the 620 sub-TLV's performance has been below (or re-crosses) this 621 threshold for an advertisement interval(s) to permit fail back. 623 To prevent oscillations, only the high threshold or the low threshold 624 (but not both) may be used to trigger any given sub-TLV that supports 625 both. 627 Additionally, once outside of the bounds of the threshold, any re- 628 advertisement of a measurement within the bounds would remain 629 governed solely by the measurement interval for that sub-TLV. 631 6. Announcement Suppression 633 When link performance values change by small amounts that fall under 634 thresholds that would cause the announcement of a sub-TLV, 635 implementations SHOULD suppress sub-TLV readvertisement and/or 636 lengthen the period within which they are refreshed. 638 Only the accelerated advertisement threshold mechanism described in 639 section 6 may shorten the re-advertisement interval. 641 All suppression and re-advertisement interval back-off timer features 642 SHOULD be configurable. 644 7. Network Stability and Announcement Periodicity 646 Sections 6 and 7 provide configurable mechanisms to bound the number 647 of re-advertisements. Instability might occur in very large networks 648 if measurement intervals are set low enough to overwhelm the 649 processing of flooded information at some of the routers in the 650 topology. Therefore care SHOULD be taken in setting these values. 652 Additionally, the default measurement interval for all sub-TLVs 653 SHOULD be 30 seconds. 655 Announcements MUST also be able to be throttled using configurable 656 inter-update throttle timers. The minimum announcement periodicity is 657 1 announcement per second. The default value SHOULD be set to 120 658 seconds. 660 Implementations SHOULD NOT permit the inter-update timer to be lower 661 than the measurement interval. 663 Furthermore, it is RECOMMENDED that any underlying performance 664 measurement mechanisms not include any significant buffer delay, any 665 significant buffer induced delay variation, or any significant 666 loss due to buffer overflow or due to active queue management. 668 8. Enabling and Disabling Sub-TLVs 670 Implementations MUST make it possible to individually enable or 671 disable each sub-TLV based on configuration. 673 9. Static Metric Override 675 Implementations SHOULD permit the static configuration and/or manual 676 override of dynamic measurements data on a per sub-TLV, per metric 677 basis in order to simplify migrations and to mitigate scenarios where 678 measurements are not possible across an entire network. 680 10. Compatibility 682 As per (RFC3630), unrecognized TLVs should be silently ignored 684 11. Security Considerations 686 This document does not introduce security issues beyond those 687 discussed in [RFC3630] and [RFC5329]. 689 12. IANA Considerations 691 IANA maintains the registry for the sub-TLVs. OSPF TE Metric 692 Extensions will require one new type code per sub-TLV defined in this 693 document, as follows: 695 Type Description 697 TBD1 Unidirectional Link Delay 699 TBD2 Min/Max Unidirectional Link Delay 701 TBD3 Unidirectional Delay Variation 703 TBD4 Unidirectional Link Loss 705 TBD5 Unidirectional Residual Bandwidth 707 TBD6 Unidirectional Available Bandwidth 709 TBD7 Unidirectional Utilized Bandwidth 711 13. References 713 13.1. Normative References 715 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 716 Requirement Levels", BCP 14, RFC 2119, March 1997. 718 [RFC3630] Katz, D., Kompella, K., Yeung, D., "Traffic 719 Engineering (TE) Extensions to OSPF Version 2", RFC 3630, 720 September 2003. 722 13.2. Informative References 724 [RFC2328] Moy, J, "OSPF Version 2", RFC 2328, April 1998 726 [RFC3031] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol 727 Label Switching Architecture", January 2001 729 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 730 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 731 Tunnels", RFC 3209, December 2001. 733 [RFC5250] Berger, L., Bryskin I., Zinin, A., Coltun, R., "The OSPF 734 Opaque LSA Option", RFC 5250, July 2008. 736 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 737 Computation Element (PCE)-Based Architecture", RFC 4655, 738 August 2006. 740 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 741 Measurement for MPLS Networks", RFC 6374, September 2011. 743 [RFC7285] Almi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., 744 Roome, W., Shalunov, S., and R. Woundy, "Application- 745 Layer Traffic Optimization (ALTO) Protocol", RFC 7285, 746 September 2014. 748 14. Acknowledgments 750 The authors would like to recognize Ayman Soliman, Nabil Bitar, David 751 McDysan, Edward Crabbe, and Don Fedyk for their contributions. 753 The authors also recognize Curtis Villamizar for significant comments 754 and direct content collaboration. 756 This document was prepared using 2-Word-v2.0.template.dot. 758 15. Author's Addresses 760 Spencer Giacalone 761 Unaffiliated 763 Email: spencer.giacalone@gmail.com 765 Dave Ward 766 Cisco Systems 767 170 West Tasman Dr. 768 San Jose, CA 95134, USA 770 Email: dward@cisco.com 772 John Drake 773 Juniper Networks 774 1194 N. Mathilda Ave. 775 Sunnyvale, CA 94089, USA 777 Email: jdrake@juniper.net 779 Alia Atlas 780 Juniper Networks 781 1194 N. Mathilda Ave. 782 Sunnyvale, CA 94089, USA 784 Email: akatlas@juniper.net 786 Stefano Previdi 787 Cisco Systems 788 Via Del Serafico 200 789 00142 Rome 790 Italy 792 Email: sprevidi@cisco.com