idnits 2.17.1 draft-ietf-ospf-te-metric-extensions-04.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 572 has weird spacing: '...figured upper...' -- The document date (June 3, 2013) is 3972 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 189, but not defined == Missing Reference: 'RFC4206' is mentioned on line 500, but not defined == Missing Reference: 'RFC5329' is mentioned on line 653, but not defined == Unused Reference: 'RFC2328' is defined on line 677, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 679, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 7 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 Thomson Reuters 3 Intended status: Proposed Standard 4 Expires: December 2013 D. Ward 5 Cisco Systems 7 J. Drake 8 Juniper Networks 10 A. Atlas 11 Juniper Networks 13 S. Previdi 14 Cisco Systems 16 June 3, 2013 18 OSPF Traffic Engineering (TE) Metric Extensions 19 draft-ietf-ospf-te-metric-extensions-04.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 December 3, 2013. 62 Copyright Notice 64 Copyright (c) 2013 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..........................................7 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.............................................8 94 4.2.5. Low Delay............................................9 95 4.2.6. High 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.5. Unidirectional Available Bandwidth Sub-TLV...............13 113 4.5.4. Type................................................13 114 4.5.5. Length..............................................13 115 4.5.6. Available Bandwidth.................................13 116 5. Announcement Thresholds and Filters...........................13 117 6. Announcement Suppression......................................14 118 7. Network Stability and Announcement Periodicity................15 119 8. Enabling and Disabling Sub-TLVs...............................15 120 9. Static Metric Override........................................15 121 10. Compatibility................................................16 122 11. Security Considerations......................................16 123 12. IANA Considerations..........................................16 124 13. References...................................................16 125 13.1. Normative References....................................16 126 13.2. Informative References..................................16 127 14. Acknowledgments..............................................17 128 15. Author's Addresses...........................................17 130 1. Introduction 132 In certain networks, such as, but not limited to, financial 133 information networks (e.g. stock market data providers), network 134 performance information (e.g. latency) is becoming as critical to 135 data path selection as other metrics. 137 In these networks, extremely large amounts of money rest on the 138 ability to access market data in "real time" and to predictably make 139 trades faster than the competition. Because of this, using metrics 140 such as hop count or cost as routing metrics is becoming only 141 tangentially important. Rather, it would be beneficial to be able to 142 make path selection decisions based on performance data (such as 143 latency) in a cost-effective and scalable way. 145 This document describes extensions to OSPF TE (hereafter called "OSPF 146 TE Metric Extensions"), that can be used to distribute network 147 performance information (such as link delay, delay variation, packet 148 loss, residual bandwidth, and available bandwidth). 150 The data distributed by OSPF TE Metric Extensions is meant to be used 151 as part of the operation of the routing protocol (e.g. by replacing 152 cost with latency or considering bandwidth as well as cost), by 153 enhancing CSPF, or for other uses such as supplementing the data used 154 by an Alto server [Alto]. With respect to CSPF, the data distributed 155 by OSPF TE Metric Extensions can be used to setup, fail over, and 156 fail back data paths using protocols such as RSVP-TE [RFC3209]. 158 Note that the mechanisms described in this document only disseminate 159 performance information. The methods for initially gathering that 160 performance information, such as [RFC6375], or acting on it once it 161 is distributed are outside the scope of this document. Example 162 mechanisms to measure latency, delay variation, and loss in an MPLS 163 network are given in [RFC6374]. While this document does not 164 specify how the performance information should be obtained, the 165 measurement of delay SHOULD NOT vary significantly based upon the 166 offered traffic load. Thus, queuing delays and/or loss SHOULD NOT 167 be included in any dynamic delay measurement. For links, such as 168 Forwarding Adjacencies, care must be taken that measurement of the 169 associated delay avoids significant queuing delay; that could be 170 accomplished in a variety of ways, including either by measuring 171 with a traffic class that experiences minimal queuing or by summing 172 the measured link delays of the components of the link's path. 174 2. Conventions used in this document 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in RFC-2119 [RFC2119]. 180 In this document, these words will appear with that interpretation 181 only when in ALL CAPS. Lower case uses of these words are not to be 182 interpreted as carrying RFC-2119 significance. 184 3. TE Metric Extensions to OSPF TE 186 This document proposes new OSPF TE sub-TLVs that can be announced in 187 OSPF TE LSAs to distribute network performance information. The 188 extensions in this document build on the ones provided in OSPF TE 189 [RFC3630] and GMPLS [RFC4203]. 191 OSPF TE LSAs [RFC3630] are opaque LSAs [RFC5250] with area flooding 192 scope. Each TLV has one or more nested sub-TLVs which permit the TE 193 LSA to be readily extended. There are two main types of OSPF TE LSA; 194 the Router Address or Link TE LSA. Like the extensions in GMPLS 195 (RFC4203), this document proposes several additional sub-TLVs for 196 the Link TE LSA: 198 Type Length Value 200 TBD1 4 Unidirectional Link Delay 202 TBD2 8 Low/High Unidirectional Link Delay 204 TBD3 4 Unidirectional Delay Variation 206 TBD4 4 Unidirectional Packet Loss 208 TBD5 4 Unidirectional Residual Bandwidth 210 TBD6 4 Unidirectional Available Bandwidth 212 As can be seen in the list above, the sub-TLVs described in this 213 document carry different types of network performance information. 214 Many (but not all) of the sub-TLVs include a bit called the Anomalous 215 (or "A") bit. When the A bit is clear (or when the sub-TLV does not 216 include an A bit), the sub-TLV describes steady state link 217 performance. This information could conceivably be used to construct 218 a steady state performance topology for initial tunnel path 219 computation, or to verify alternative failover paths. 221 When network performance violates configurable link-local thresholds 222 a sub-TLV with the A bit set is advertised. These sub-TLVs could be 223 used by the receiving node to determine whether to fail traffic to a 224 backup path, or whether to calculate an entirely new path. From an 225 MPLS perspective, the intent of the A bit is to permit LSP ingress 226 nodes to: 228 A) Determine whether the link referenced in the sub-TLV affects any 229 of the LSPs for which it is ingress. If there are, then: 231 B) The node determines whether those LSPs still meet end-to-end 232 performance objectives. If not, then: 234 C) The node could then conceivably move affected traffic to a pre- 235 established protection LSP or establish a new LSP and place the 236 traffic in it. 238 If link performance then improves beyond a configurable minimum 239 value (reuse threshold), that sub-TLV can be re-advertised with the 240 Anomalous bit cleared. In this case, a receiving node can 241 conceivably do whatever re-optimization (or failback) it wishes to 242 do (including nothing). 244 Note that when a sub-TLV does not include the A bit, that sub-TLV 245 cannot be used for failover purposes. The A bit was intentionally 246 omitted from some sub-TLVs to help mitigate oscillations. See section 247 7. 1. for more information. 249 Consistent with existing OSPF TE specifications (RFC3630), the 250 bandwidth advertisements defined in this draft MUST be encoded as 251 IEEE floating point values. The delay and delay variation 252 advertisements defined in this draft MUST be encoded as integer 253 values. Delay values MUST be quantified in units of microseconds, 254 packet loss MUST be quantified as a percentage of packets sent, and 255 bandwidth MUST be sent as bytes per second. All values (except 256 residual bandwidth) MUST be calculated as rolling averages where the 257 averaging period MUST be a configurable period of time. See section 258 5. for more information. 260 4. Sub TLV Details 262 4.1. Unidirectional Link Delay Sub-TLV 264 This sub-TLV advertises the average link delay between two directly 265 connected OSPF neighbors. The delay advertised by this sub-TLV MUST 266 be the delay from the local neighbor to the remote one (i.e. the 267 forward path latency). The format of this sub-TLV is shown in the 268 following diagram: 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | TBD1 | 4 | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 |A| RESERVED | Delay | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 4.1.1. Type 280 This sub-TLV has a type of TBD1. 282 4.1.2. Length 284 The length is 4. 286 4.1.3. A bit 288 This field represents the Anomalous (A) bit. The A bit is set when 289 the measured value of this parameter exceeds its configured maximum 290 threshold. The A bit is cleared when the measured value falls below 291 its configured reuse threshold. If the A bit is clear, the sub-TLV 292 represents steady state link performance. 294 4.1.4. Reserved 296 This field is reserved for future use. It MUST be set to 0 when sent 297 and MUST be ignored when received. 299 4.1.5. Delay Value 301 This 24-bit field carries the average link delay over a configurable 302 interval in micro-seconds, encoded as an integer value. When set to 303 the maximum value 16,777,215 (16.777215 sec), then the delay is at 304 least that value and may be larger. If there is no value to send 305 (unmeasured and not statically specified), then the sub-TLV should 306 not be sent or be withdrawn. 308 4.2. Min/Max Unidirectional Link Delay Sub-TLV 310 This sub-TLV advertises the minimum and maximum delay values between 311 two directly connected OSPF neighbors. The delay advertised by this 312 sub-TLV MUST be the delay from the local neighbor to the remote one 313 (i.e. the forward path latency). The format of this sub-TLV is shown 314 in the following diagram: 316 0 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | TBD2 | 8 | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 |A| RESERVED | Min Delay | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | RESERVED | Max Delay | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 4.2.1. Type 328 This sub-TLV has a type of TBD2. 330 4.2.2. Length 332 The length is 8. 334 4.2.3. A bit 336 This field represents the Anomalous (A) bit. The A bit is set when 337 one or more measured values exceed a configured maximum threshold. 338 The A bit is cleared when the measured value falls below its 339 configured reuse threshold. If the A bit is clear, the sub-TLV 340 represents steady state link performance. 342 4.2.4. Reserved 344 This field is reserved for future use. It MUST be set to 0 when sent 345 and MUST be ignored when received. 347 4.2.5. Low Delay 349 This 24-bit field carries minimum measured link delay value (in 350 microseconds) over a configurable interval, encoded as an integer 351 value. 353 Implementations MAY also permit the configuration of a static (non 354 dynamic) offset value (in microseconds) to be added to the measured 355 delay value, to facilitate the communication of operator specific 356 delay constraints. 358 When set to the maximum value 16,777,215 (16.777215 sec), then the 359 delay is at least that value and may be larger. 361 4.2.6. High Delay 363 This 24-bit field carries the maximum measured link delay value (in 364 microseconds) over a configurable interval, encoded as an integer 365 value. 367 Implementations MAY also permit the configuration of a static (non 368 dynamic) offset value (in microseconds) to be added to the measured 369 delay value, to facilitate the communication of operator specific 370 delay constraints. 372 It is possible for the high delay and low delay to be the same value. 374 When the delay value is set to maximum value 16,777,215 (16.777215 375 sec), then the delay is at least that value and may be larger. 377 4.2.7. Reserved 379 This field is reserved for future use. It MUST be set to 0 when sent 380 and MUST be ignored when received. 382 When only an average delay value is sent, this field is not present 383 in the TLV. 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 local neighbor to the remote 390 one (i.e. the forward path latency). The format of this sub-TLV is 391 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 local neighbor to the remote 427 one (i.e. the forward path loss). The format of this sub-TLV is shown 428 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 TLV advertises the residual bandwidth (defined in section 4.5.3. 475 between two directly connected OSPF neighbors. The residual bandwidth 476 advertised by this sub-TLV MUST be the residual bandwidth from the 477 system originating the LSA to 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.5. Unidirectional Available Bandwidth Sub-TLV 521 This TLV advertises the available bandwidth (defined in section 522 4.5.6. ) between two directly connected OSPF neighbors. The available 523 bandwidth advertised by this sub-TLV MUST be the available bandwidth 524 from the system originating the LSA to its neighbor. The format of 525 this sub-TLV is shown in the following 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.5.4. Type 537 This sub-TLV has a type of TBD6. 539 4.5.5. Length 541 The length is 4. 543 4.5.6. 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 5. Announcement Thresholds and Filters 555 The values advertised in all sub-TLVs (except min/max delay and 556 residual bandwidth) MUST represent an average over a period or be 557 obtained by a filter that is reasonably representative of an 558 average. For example, a rolling average is one such filter. 560 Low or high delay MAY be the lowest and/or highest measured value 561 over a measurement interval or MAY make use of a filter, or other 562 technique to obtain a reasonable representation of a low and high 563 value representative of the interval with compensation for outliers. 565 The measurement interval, any filter coefficients, and any 566 advertisement intervals MUST be configurable per sub-TLV. 568 In addition to the measurement intervals governing re-advertisement, 569 implementations SHOULD provide per sub-TLV configurable accelerated 570 advertisement thresholds, such that: 572 1. If the measured parameter falls outside a configured upper bound 573 for all but the min delay metric (or lower bound for min-delay 574 metric only) and the advertised sub-TLV is not already outside 575 that bound or, 577 2. If the difference between the last advertised value and current 578 measured value exceed a configured threshold then, 580 3. The advertisement is made immediately. 582 4. For sub-TLVs which include an A-bit (except low/high delay), an 583 additional threshold SHOULD be included corresponding to the 584 threshold for which the performance is considered anomalous (and 585 sub-TLVs with the A bit are sent). The A-bit is cleared when the 586 sub-TLV's performance has been below (or re-crosses) this 587 threshold for an advertisement interval(s) to permit fail back. 589 To prevent oscillations, only the high threshold or the low threshold 590 (but not both) may be used to trigger any given sub-TLV that supports 591 both. 593 Additionally, once outside of the bounds of the threshold, any 594 readvertisement of a measurement within the bounds would remain 595 governed solely by the measurement interval for that sub-TLV. 597 6. Announcement Suppression 599 When link performance values change by small amounts that fall under 600 thresholds that would cause the announcement of a sub-TLV, 601 implementations SHOULD suppress sub-TLV readvertisement and/or 602 lengthen the period within which they are refreshed. 604 Only the accelerated advertisement threshold mechanism described in 605 section 6 may shorten the re-advertisement interval. 607 All suppression and re-advertisement interval backoff timer features 608 SHOULD be configurable. 610 7. Network Stability and Announcement Periodicity 612 Sections 6 and 7 provide configurable mechanisms to bound the number 613 of re-advertisements. Instability might occur in very large networks 614 if measurement intervals are set low enough to overwhelm the 615 processing of flooded information at some of the routers in the 616 topology. Therefore care SHOULD be taken in setting these values. 618 Additionally, the default measurement interval for all sub-TLVs 619 SHOULD be 30 seconds. 621 Announcements MUST also be able to be throttled using configurable 622 inter-update throttle timers. The minimum announcement periodicity is 623 1 announcement per second. The default value SHOULD be set to 120 624 seconds. 626 Implementations SHOULD NOT permit the inter-update timer to be lower 627 than the measurement interval. 629 Furthermore, it is RECOMMENDED that any underlying performance 630 measurement mechanisms not include any significant buffer delay, any 631 significant buffer induced delay variation, or any significant 632 loss due to buffer overflow or due to active queue management. 634 8. Enabling and Disabling Sub-TLVs 636 Implementations MUST make it possible to individually enable or 637 disable each sub-TLV based on configuration. 639 9. Static Metric Override 641 Implementations SHOULD permit the static configuration and/or manual 642 override of dynamic measurements data on a per sub-TLV, per metric 643 basis in order to simplify migrations and to mitigate scenarios where 644 measurements are not possible across an entire network. 646 10. Compatibility 648 As per (RFC3630), unrecognized TLVs should be silently ignored 650 11. Security Considerations 652 This document does not introduce security issues beyond those 653 discussed in [RFC3630] and [RFC5329]. 655 12. IANA Considerations 657 IANA maintains the registry for the sub-TLVs. OSPF TE Metric 658 Extensions will require one new type code per sub-TLV defined in this 659 document. 661 13. References 663 13.1. Normative References 665 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 666 Requirement Levels", BCP 14, RFC 2119, March 1997. 668 [RFC3630] Katz, D., Kompella, K., Yeung, D., "Traffic 669 Engineering (TE) Extensions to OSPF Version 2", RFC 3630, 670 September 2003. 672 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 673 Measurement for MPLS Networks", RFC 6374, September 2011. 675 13.2. Informative References 677 [RFC2328] Moy, J, "OSPF Version 2", RFC 2328, April 1998 679 [RFC3031] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol 680 Label Switching Architecture", January 2001 682 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 683 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 684 Tunnels", RFC 3209, December 2001. 686 [RFC5250] Berger, L., Bryskin I., Zinin, A., Coltun, R., "The OSPF 687 Opaque LSA Option", RFC 5250, July 2008. 689 [RFC6375] Frost, D. and S. Bryant, "A Packet Loss and Delay 690 Measurement Profile for MPLS-Based Transport Networks", 691 RFC 6375, September 2011. 693 [Alto] R. Alimi R. Penno Y. Yang, "ALTO Protocol" 695 14. Acknowledgments 697 The authors would like to recognize Ayman Soliman, Nabil Bitar, David 698 McDysan, Edward Crabbe, and Don Fedyk for their contributions. 700 The authors also recognize Curtis Villamizar for significant comments 701 and direct content collaboration. 703 This document was prepared using 2-Word-v2.0.template.dot. 705 15. Author's Addresses 707 Spencer Giacalone 708 Thomson Reuters 709 195 Broadway 710 New York, NY 10007, USA 712 Email: Spencer.giacalone@thomsonreuters.com 714 Dave Ward 715 Cisco Systems 716 170 West Tasman Dr. 717 San Jose, CA 95134, USA 719 Email: dward@cisco.com 720 John Drake 721 Juniper Networks 722 1194 N. Mathilda Ave. 723 Sunnyvale, CA 94089, USA 725 Email: jdrake@juniper.net 727 Alia Atlas 728 Juniper Networks 729 1194 N. Mathilda Ave. 730 Sunnyvale, CA 94089, USA 732 Email: akatlas@juniper.net 734 Stefano Previdi 735 Cisco Systems 736 Via Del Serafico 200 737 00142 Rome 738 Italy 740 Email: sprevidi@cisco.com