idnits 2.17.1 draft-ietf-ospf-te-metric-extensions-09.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 (December 27, 2014) is 3401 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE754' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: June 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 December 27, 2014 18 OSPF Traffic Engineering (TE) Metric Extensions 19 draft-ietf-ospf-te-metric-extensions-09.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 RFC 3630 'Traffic Engineering 29 (TE) Extensions to OSPF Version 2' such that network performance 30 information can be distributed and collected in a scalable fashion. 31 The information distributed using OSPF TE Metric Extensions can then 32 be used to make path selection decisions based on network 33 performance. 35 Note that this document only covers the mechanisms with which network 36 performance information is distributed. The mechanisms for measuring 37 network performance or acting on that information, once distributed, 38 are outside the scope of this document. 40 Status of this Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF), its areas, and its working groups. Note that 47 other groups may also distribute working documents as Internet- 48 Drafts. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 The list of current Internet-Drafts can be accessed at 56 http://www.ietf.org/ietf/1id-abstracts.txt 58 The list of Internet-Draft Shadow Directories can be accessed at 59 http://www.ietf.org/shadow.html 61 This Internet-Draft will expire on June 27, 2015. 63 Copyright Notice 65 Copyright (c) 2014 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction...................................................4 81 2. Conventions used in this document..............................5 82 3. TE Metric Extensions to OSPF TE................................5 83 4. Sub-TLV Details................................................7 84 4.1. Unidirectional Link Delay Sub-TLV.........................7 85 4.1.1. Type.................................................7 86 4.1.2. Length...............................................7 87 4.1.3. A bit................................................7 88 4.1.4. Reserved.............................................7 89 4.1.5. Delay Value..........................................8 90 4.2. Min/Max Unidirectional Link Delay Sub-TLV.................8 91 4.2.1. Type.................................................8 92 4.2.2. Length...............................................8 93 4.2.3. A bit................................................8 94 4.2.4. Reserved.............................................9 95 4.2.5. Min Delay............................................9 96 4.2.6. Reserved.............................................9 97 4.2.7 Max Delay.............................................9 98 4.3. Unidirectional Delay Variation Sub-TLV....................9 99 4.3.1. Type................................................10 100 4.3.2. Length..............................................10 101 4.3.3. Reserved............................................10 102 4.3.4. Delay Variation.....................................10 103 4.4. Unidirectional Link Loss Sub-TLV.........................10 104 4.4.1. Type................................................11 105 4.4.2. Length..............................................11 106 4.4.3. A bit...............................................11 107 4.4.4. Reserved............................................11 108 4.4.5. Link Loss...........................................11 109 4.5. Unidirectional Residual Bandwidth Sub-TLV................11 110 4.5.1. Type................................................12 111 4.5.2. Length..............................................12 112 4.5.3. Residual Bandwidth..................................12 113 4.6. Unidirectional Available Bandwidth Sub-TLV...............12 114 4.6.1. Type................................................13 115 4.6.2. Length..............................................13 116 4.6.3. Available Bandwidth.................................13 117 4.7. Unidirectional Utilized Bandwidth Sub-TLV................13 118 4.7.1. Type................................................14 119 4.7.2. Length..............................................14 120 4.7.3. Utilized Bandwidth..................................14 121 5. Announcement Thresholds and Filters...........................14 122 6. Announcement Suppression......................................15 123 7. Network Stability and Announcement Periodicity................15 124 8. Enabling and Disabling Sub-TLVs...............................16 125 9. Static Metric Override........................................16 126 10. Compatibility................................................16 127 11. Security Considerations......................................16 128 12. IANA Considerations..........................................17 129 13. References...................................................17 130 13.1. Normative References....................................17 131 13.2. Informative References..................................18 132 14. Acknowledgments..............................................18 133 15. Author's Addresses...........................................19 135 1. Introduction 137 In certain networks, such as, but not limited to, financial 138 information networks (e.g., stock market data providers), network 139 performance information (e.g., latency) is becoming as critical to 140 data path selection as other metrics. 142 In these networks, extremely large amounts of money rest on the 143 ability to access market data in "real time" and to predictably make 144 trades faster than the competition. Because of this, using metrics 145 such as hop count or cost as routing metrics is becoming only 146 tangentially important. Rather, it would be beneficial to be able to 147 make path selection decisions based on performance data (such as 148 latency) in a cost-effective and scalable way. 150 This document describes extensions to OSPF TE (hereafter called "OSPF 151 TE Metric Extensions"), that can be used to distribute network 152 performance information (viz link delay, delay variation, link loss, 153 residual bandwidth, available bandwidth, and utilized bandwidth). 155 The data distributed by OSPF TE Metric Extensions is meant to be used 156 as part of the operation of the routing protocol (e.g., by replacing 157 cost with latency or considering bandwidth as well as cost), by 158 enhancing CSPF, or for use by a PCE [RFC4655] or an Alto server 159 [RFC7285]. With respect to CSPF, the data distributed by OSPF TE 160 Metric Extensions can be used to setup, fail over, and fail back data 161 paths using protocols such as RSVP-TE [RFC3209]. 163 Note that the mechanisms described in this document only disseminate 164 performance information. The methods for initially gathering that 165 performance information or acting on it once it is distributed are 166 outside the scope of this document. Example mechanisms to measure 167 latency, delay variation, and loss in an MPLS network are given in 168 [RFC6374]. While this document does not specify how the performance 169 information should be obtained, the measurement of delay SHOULD NOT 170 vary significantly based upon the offered traffic load. Thus, 171 queuing delays and/or loss SHOULD NOT be included in any dynamic 172 delay measurement. For links, such as Forwarding Adjacencies, care 173 must be taken that measurement of the associated delay avoids 174 significant queuing delay; that could be accomplished in a variety 175 of ways, including either by measuring with a traffic class that 176 experiences minimal queuing or by summing the measured link delays 177 of the components of the link's path. 179 2. Conventions used in this document 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in RFC-2119 [RFC2119]. 185 In this document, these words will appear with that interpretation 186 only when in ALL CAPS. Lower case uses of these words are not to be 187 interpreted as carrying RFC-2119 significance. 189 3. TE Metric Extensions to OSPF TE 191 This document defines new OSPF TE sub-TLVs that can be announced in 192 OSPF TE LSAs to distribute network performance information. The 193 extensions in this document build on the ones provided in OSPF TE 194 [RFC3630] and GMPLS [RFC4203]. 196 OSPF TE LSAs [RFC3630] are opaque LSAs [RFC5250] with area flooding 197 scope. Each consists of a single TLV with one or more nested sub- 198 TLVs, permitting the TE LSA to be readily extended. There are two 199 OSPF TE LSA TLVs, the Router Address and the Link TLV. Like the 200 extensions in GMPLS (RFC4203), this document defines several 201 additional sub-TLVs for the Link TLV: 203 Type Length Value 205 TBD1 4 Unidirectional Link Delay 207 TBD2 8 Min/Max Unidirectional Link Delay 209 TBD3 4 Unidirectional Delay Variation 211 TBD4 4 Unidirectional Link Loss 213 TBD5 4 Unidirectional Residual Bandwidth 215 TBD6 4 Unidirectional Available Bandwidth 217 TBD7 4 Unidirectional Utilized Bandwidth 218 As can be seen in the list above, the sub-TLVs described in this 219 document carry different types of network performance information. 220 Many (but not all) of the sub-TLVs include a bit called the Anomalous 221 (or "A") bit. When the A bit is clear (or when the sub-TLV does not 222 include an A bit), the sub-TLV describes steady state link 223 performance. This information could conceivably be used to construct 224 a steady state performance topology for initial tunnel path 225 computation, or to verify alternative failover paths. 227 When network performance violates configurable link-local thresholds 228 a sub-TLV with the A bit set is advertised. These sub-TLVs could be 229 used by the receiving node to determine whether to fail traffic to a 230 backup path, or whether to calculate an entirely new path. From an 231 MPLS perspective, the intent of the A bit is to permit LSP ingress 232 nodes to: 234 A) Determine whether the link referenced in the sub-TLV affects any 235 of the LSPs for which it is ingress. If there are, then: 237 B) The node determines whether those LSPs still meet end-to-end 238 performance objectives. If not, then: 240 C) The node could then conceivably move affected traffic to a pre- 241 established protection LSP or establish a new LSP and place the 242 traffic in it. 244 If link performance then improves beyond a configurable minimum 245 value (reuse threshold), that sub-TLV can be re-advertised with the 246 Anomalous bit cleared. In this case, a receiving node can 247 conceivably do whatever re-optimization (or failback) it wishes to 248 do (including nothing). 250 Note that when a sub-TLV does not include the A bit, that sub-TLV 251 cannot be used for failover purposes. The A bit was intentionally 252 omitted from some sub-TLVs to help mitigate oscillations. See section 253 7. 1. for more information. 255 Link delay, delay variation, and link loss MUST be encoded as 256 integers. Consistent with existing OSPF TE specifications [RFC3630], 257 residual, available, and utilized bandwidth MUST be encoded in IEEE 258 floating point [IEEE754]. Link delay and delay variation MUST be in 259 units of microseconds, link loss MUST be a percentage, and bandwidth 260 MUST be in units of bytes per second. All values (except residual 261 bandwidth) MUST be calculated as rolling averages where the averaging 262 period MUST be a configurable period of time. See section 5. for more 263 information. 265 4. Sub-TLV Details 267 4.1. Unidirectional Link Delay Sub-TLV 269 This sub-TLV advertises the average link delay between two directly 270 connected OSPF neighbors. The delay advertised by this sub-TLV MUST 271 be the delay from the advertising node to its neighbor (i.e., the 272 forward path delay). The format of this sub-TLV is shown in the 273 following diagram: 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | TBD1 | 4 | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 |A| RESERVED | Delay | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 4.1.1. Type 285 This sub-TLV has a type of TBD1. 287 4.1.2. Length 289 The length is 4. 291 4.1.3. A bit 293 This field represents the Anomalous (A) bit. The A bit is set when 294 the measured value of this parameter exceeds its configured maximum 295 threshold. The A bit is cleared when the measured value falls below 296 its configured reuse threshold. If the A bit is clear, the sub-TLV 297 represents steady state link performance. 299 4.1.4. Reserved 301 This field is reserved for future use. It MUST be set to 0 when sent 302 and MUST be ignored when received. 304 4.1.5. Delay Value 306 This 24-bit field carries the average link delay over a configurable 307 interval in micro-seconds, encoded as an integer value. When set to 308 the maximum value 16,777,215 (16.777215 sec), then the delay is at 309 least that value and may be larger. If there is no value to send 310 (unmeasured and not statically specified), then the sub-TLV should 311 not be sent or be withdrawn. 313 4.2. Min/Max Unidirectional Link Delay Sub-TLV 315 This sub-TLV advertises the minimum and maximum delay values between 316 two directly connected OSPF neighbors. The delay advertised by this 317 sub-TLV MUST be the delay from the advertising node to its neighbor 318 (i.e., the forward path delay). The format of this sub-TLV is shown 319 in the following diagram: 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | TBD2 | 8 | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 |A| RESERVED | Min Delay | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | RESERVED | Max Delay | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 4.2.1. Type 333 This sub-TLV has a type of TBD2. 335 4.2.2. Length 337 The length is 8. 339 4.2.3. A bit 341 This field represents the Anomalous (A) bit. The A bit is set when 342 one or more measured values exceed a configured maximum threshold. 343 The A bit is cleared when the measured value falls below its 344 configured reuse threshold. If the A bit is clear, the sub-TLV 345 represents steady state link performance. 347 4.2.4. Reserved 349 This field is reserved for future use. It MUST be set to 0 when sent 350 and MUST be ignored when received. 352 4.2.5. Min Delay 354 This 24-bit field carries minimum measured link delay value (in 355 microseconds) over a configurable interval, encoded as an integer 356 value. 358 Implementations MAY also permit the configuration of an offset value 359 (in microseconds) to be added to the measured delay value to 360 advertise operator specific 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. Reserved 367 This field is reserved for future use. It MUST be set to 0 when sent 368 and MUST be ignored when received. 370 4.2.7 Max Delay 372 This 24-bit field carries the maximum measured link delay value (in 373 microseconds) over a configurable interval, encoded as an integer 374 value. 376 Implementations MAY also permit the configuration of an offset value 377 (in microseconds) to be added to the measured delay value to 378 advertise operator specific delay constraints. 380 It is possible for min delay and max delay to be the same value. 382 When the delay value is set to maximum value 16,777,215 (16.777215 383 sec), then the delay is at least that value and may be larger. 385 4.3. Unidirectional Delay Variation Sub-TLV 387 This sub-TLV advertises the average link delay variation between two 388 directly connected OSPF neighbors. The delay variation advertised by 389 this sub-TLV MUST be the delay from the advertising node to its 390 neighbor (i.e., the forward path delay variation). The format of this 391 sub-TLV is shown in the following diagram: 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | TBD3 | 4 | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | RESERVED | Delay Variation | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 4.3.1. Type 403 This sub-TLV has a type of TBD3. 405 4.3.2. Length 407 The length is 4. 409 4.3.3. Reserved 411 This field is reserved for future use. It MUST be set to 0 when sent 412 and MUST be ignored when received. 414 4.3.4. Delay Variation 416 This 24-bit field carries the average link delay variation over a 417 configurable interval in micro-seconds, encoded as an integer value. 418 When set to 0, it has not been measured. When set to the maximum 419 value 16,777,215 (16.777215 sec), then the delay is at least that 420 value and may be larger. 422 4.4. Unidirectional Link Loss Sub-TLV 424 This sub-TLV advertises the loss (as a packet percentage) between two 425 directly connected OSPF neighbors. The link loss advertised by this 426 sub-TLV MUST be the packet loss from the advertising node to its 427 neighbor (i.e., the forward path loss). The format of this sub-TLV is 428 shown in the following diagram: 430 0 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | TBD4 | 4 | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 |A| RESERVED | Link Loss | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 4.4.1. Type 440 This sub-TLV has a type of TBD4 442 4.4.2. Length 444 The length is 4. 446 4.4.3. A bit 448 This field represents the Anomalous (A) bit. The A bit is set when 449 the measured value of this parameter exceeds its configured maximum 450 threshold. The A bit is cleared when the measured value falls below 451 its configured reuse threshold. If the A bit is clear, the sub-TLV 452 represents steady state link performance. 454 4.4.4. Reserved 456 This field is reserved for future use. It MUST be set to 0 when sent 457 and MUST be ignored when received. 459 4.4.5. Link Loss 461 This 24-bit field carries link packet loss as a percentage of the 462 total traffic sent over a configurable interval. The basic unit is 463 0.000003%, where (2^24 - 2) is 50.331642%. This value is the highest 464 packet loss percentage that can be expressed (the assumption being 465 that precision is more important on high speed links than the ability 466 to advertise loss rates greater than this, and that high speed links 467 with over 50% loss are unusable). Therefore, measured values that are 468 larger than the field maximum SHOULD be encoded as the maximum value. 469 When set to a value of all 1s (2^24 - 1), the link packet loss has 470 not been measured. 472 4.5. Unidirectional Residual Bandwidth Sub-TLV 474 This sub-TLV advertises the residual bandwidth between two directly 475 connected OSPF neighbors. The residual bandwidth advertised by this 476 sub-TLV MUST be the residual bandwidth from the advertising node to 477 its neighbor. 479 The format of this sub-TLV is shown in the following diagram: 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | TBD5 | 4 | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Residual Bandwidth | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 4.5.1. Type 491 This sub-TLV has a type of TBD5. 493 4.5.2. Length 495 The length is 4. 497 4.5.3. Residual Bandwidth 499 This field carries the residual bandwidth on a link, forwarding 500 adjacency [RFC4206], or bundled link in IEEE floating point format 501 with units of bytes per second. For a link or forwarding adjacency, 502 residual bandwidth is defined to be Maximum Bandwidth [RFC3630] minus 503 the bandwidth currently allocated to RSVP-TE LSPs. For a bundled 504 link, residual bandwidth is defined to be the sum of the component 505 link residual bandwidths. 507 The calculation of Residual Bandwidth is different than that of 508 Unreserved Bandwidth [RFC3630]. Residual Bandwidth subtracts tunnel 509 reservations from Maximum Bandwidth (i.e., the link capacity) 510 [RFC3630] and provides an aggregated remainder across QoS classes. 511 Unreserved Bandwidth [RFC3630], on the other hand, is subtracted from 512 the Maximum Reservable Bandwidth (the bandwidth that can 513 theoretically be reserved) [RFC3630] and provides per-QoS-class 514 remainders. Residual Bandwidth and Unreserved Bandwidth [RFC3630] can 515 be used concurrently, and each has a separate use case (e.g., the 516 former can be used for applications like Weighted ECMP while the 517 latter can be used for call admission control). 519 4.6. Unidirectional Available Bandwidth Sub-TLV 521 This TLV advertises the available bandwidth between two directly 522 connected OSPF neighbors. The available bandwidth advertised by this 523 sub-TLV MUST be the available bandwidth from the advertising node to 524 its neighbor. The format of this sub-TLV is shown in the following 525 diagram: 527 0 1 2 3 528 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 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | TBD6 | 4 | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Available Bandwidth | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 4.6.1. Type 537 This sub-TLV has a type of TBD6. 539 4.6.2. Length 541 The length is 4. 543 4.6.3. Available Bandwidth 545 This field carries the available bandwidth on a link, forwarding 546 adjacency, or bundled link in IEEE floating point format with units 547 of bytes per second. For a link or forwarding adjacency, available 548 bandwidth is defined to be residual bandwidth (see section 4.5. ) 549 minus the measured bandwidth used for the actual forwarding of non- 550 RSVP-TE LSP packets. For a bundled link, available bandwidth is 551 defined to be the sum of the component link available bandwidths. 553 4.7. Unidirectional Utilized Bandwidth Sub-TLV 555 This Sub-TLV advertises the bandwidth utilization between two 556 directly connected OSPF neighbors. The bandwidth utilization 557 advertised by this sub-TLV MUST be the bandwidth from the advertising 558 node to its neighbor. The format of this Sub-TLV is shown in the 559 following diagram: 561 0 1 2 3 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | TBD7 | 4 | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Utilized Bandwidth | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 4.7.1. Type 571 This sub-TLV has a type of TBD7. 573 4.7.2. Length 575 The length is 4. 577 4.7.3. Utilized Bandwidth 579 This field carries the bandwidth utilization on a link, forwarding 580 adjacency, or bundled link in IEEE floating point format with units 581 of bytes per second. For a link or forwarding adjacency, bandwidth 582 utilization represents the actual utilization of the link (i.e., as 583 measured by the advertising node). For a bundled link, bandwidth 584 utilization is defined to be the sum of the component link bandwidth 585 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 re-advertisement and/or 636 lengthen the period within which they are refreshed. 638 Only the accelerated advertisement threshold mechanism described in 639 section 5 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 5 and 6 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]. 689 12. IANA Considerations 691 IANA maintains the registry for the Link TLV 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 [RFC4203] Kompella, K., Rekhter, Y., "OSPF Extensions in Support of 723 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 724 4203, October 2005. 726 [IEEE754] Institute of Electrical and Electronics Engineers, 727 "Standard for Floating-Point Arithmetic", IEEE Standard 728 754, August 2008. 730 13.2. Informative References 732 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 733 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 734 Tunnels", RFC 3209, December 2001. 736 [RFC4206] Kompella, K., Rekhter, Y., "Label Switched Paths (LSP) 737 Hierarchy with Generalized Multi-Protocol Label Switching 738 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 740 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 741 Computation Element (PCE)-Based Architecture", RFC 4655, 742 August 2006. 744 [RFC5250] Berger, L., Bryskin I., Zinin, A., Coltun, R., "The OSPF 745 Opaque LSA Option", RFC 5250, July 2008. 747 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 748 Measurement for MPLS Networks", RFC 6374, September 2011. 750 [RFC7285] Almi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., 751 Roome, W., Shalunov, S., and R. Woundy, "Application- 752 Layer Traffic Optimization (ALTO) Protocol", RFC 7285, 753 September 2014. 755 14. Acknowledgments 757 The authors would like to recognize Ayman Soliman, Nabil Bitar, David 758 McDysan, Edward Crabbe, and Don Fedyk for their contributions. 760 The authors also recognize Curtis Villamizar for significant comments 761 and direct content collaboration. 763 This document was prepared using 2-Word-v2.0.template.dot. 765 15. Author's Addresses 767 Spencer Giacalone 768 Unaffiliated 770 Email: spencer.giacalone@gmail.com 772 Dave Ward 773 Cisco Systems 774 170 West Tasman Dr. 775 San Jose, CA 95134, USA 777 Email: dward@cisco.com 779 John Drake 780 Juniper Networks 781 1194 N. Mathilda Ave. 782 Sunnyvale, CA 94089, USA 784 Email: jdrake@juniper.net 786 Alia Atlas 787 Juniper Networks 788 1194 N. Mathilda Ave. 789 Sunnyvale, CA 94089, USA 791 Email: akatlas@juniper.net 793 Stefano Previdi 794 Cisco Systems 795 Via Del Serafico 200 796 00142 Rome 797 Italy 799 Email: sprevidi@cisco.com