idnits 2.17.1 draft-ietf-pce-stateful-pce-auto-bandwidth-06.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 (October 21, 2017) is 2377 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody 3 Internet-Draft U. Palle 4 Intended status: Standards Track Huawei Technologies 5 Expires: April 24, 2018 R. Singh 6 Juniper Networks 7 R. Gandhi 8 Cisco Systems, Inc. 9 L. Fang 10 Expedia, Inc. 11 October 21, 2017 13 PCEP Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with 14 Stateful PCE 15 draft-ietf-pce-stateful-pce-auto-bandwidth-06 17 Abstract 19 The Path Computation Element Communication Protocol (PCEP) provides 20 mechanisms for Path Computation Elements (PCEs) to perform path 21 computations in response to Path Computation Clients (PCCs) requests. 22 The Stateful PCE extensions allow stateful control of Multi-Protocol 23 Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE 24 LSPs) using PCEP. 26 Automatic bandwidth allows automatic and dynamic adjustment of the TE 27 LSP bandwidth reservation based on the volume of traffic flowing 28 through the LSP. This document describes PCEP extensions for 29 automatic bandwidth adjustment when employing an Active Stateful PCE 30 for both PCE-Initiated and PCC-Initiated LSPs. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 66 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 67 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 68 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Requirements for PCEP Extensions . . . . . . . . . . . . . . . 7 70 4. Architectural Overview . . . . . . . . . . . . . . . . . . . . 8 71 4.1. Auto-Bandwidth Overview . . . . . . . . . . . . . . . . . 8 72 4.2. Auto-bandwidth Theory of Operation . . . . . . . . . . . . 8 73 4.3. Scaling Considerations . . . . . . . . . . . . . . . . . . 10 74 5. Extensions to the PCEP . . . . . . . . . . . . . . . . . . . . 10 75 5.1. Capability Advertisement . . . . . . . . . . . . . . . . . 10 76 5.1.1. AUTO-BANDWIDTH-CAPABILITY TLV . . . . . . . . . . . . 11 77 5.2. AUTO-BANDWIDTH-ATTRIBUTES TLV . . . . . . . . . . . . . . 11 78 5.2.1. Sample-Interval sub-TLV . . . . . . . . . . . . . . . 13 79 5.2.2. Adjustment Intervals . . . . . . . . . . . . . . . . . 13 80 5.2.2.1. Adjustment-Interval sub-TLV . . . . . . . . . . . 13 81 5.2.2.2. Down-Adjustment-Interval sub-TLV . . . . . . . . . 14 82 5.2.3. Adjustment Thresholds . . . . . . . . . . . . . . . . 14 83 5.2.3.1. Adjustment-Threshold sub-TLV . . . . . . . . . . . 15 84 5.2.3.2. Adjustment-Threshold-Percentage sub-TLV . . . . . 15 85 5.2.3.3. Down-Adjustment-Threshold sub-TLV . . . . . . . . 16 86 5.2.3.4. Down-Adjustment-Threshold-Percentage sub-TLV . . . 17 87 5.2.4. Minimum and Maximum Bandwidth Values . . . . . . . . . 18 88 5.2.4.1. Minimum-Bandwidth sub-TLV . . . . . . . . . . . . 18 89 5.2.4.2. Maximum-Bandwidth sub-TLV . . . . . . . . . . . . 18 90 5.2.5. Overflow and Underflow Conditions . . . . . . . . . . 19 91 5.2.5.1. Overflow-Threshold sub-TLV . . . . . . . . . . . . 19 92 5.2.5.2. Overflow-Threshold-Percentage sub-TLV . . . . . . 20 93 5.2.5.3. Underflow-Threshold sub-TLV . . . . . . . . . . . 20 94 5.2.5.4. Underflow-Threshold-Percentage sub-TLV . . . . . . 21 95 5.3. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 22 96 5.4. The PCInitiate Message . . . . . . . . . . . . . . . . . . 22 97 5.5. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 23 98 5.6. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 23 99 5.7. The PCNtf Message . . . . . . . . . . . . . . . . . . . . 23 100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 101 7. Manageability Considerations . . . . . . . . . . . . . . . . . 24 102 7.1. Control of Function and Policy . . . . . . . . . . . . . . 24 103 7.2. Information and Data Models . . . . . . . . . . . . . . . 25 104 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 25 105 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 25 106 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 25 107 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 25 108 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 109 8.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 26 110 8.2. AUTO-BANDWIDTH-CAPABILITY TLV Flag Field . . . . . . . . . 26 111 8.3. AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV . . . . . . . . . . . . 26 112 8.4. Error Object . . . . . . . . . . . . . . . . . . . . . . . 27 113 8.5. Notification Object . . . . . . . . . . . . . . . . . . . 27 114 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 115 9.1. Normative References . . . . . . . . . . . . . . . . . . . 28 116 9.2. Informative References . . . . . . . . . . . . . . . . . . 28 117 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30 118 Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 121 1. Introduction 123 [RFC5440] describes the Path Computation Element Protocol (PCEP) as a 124 communication mechanism between a Path Computation Client (PCC) and a 125 Path Control Element (PCE), or between PCE and PCE, that enables 126 computation of Multi-Protocol Label Switching (MPLS) Traffic 127 Engineering Label Switched Paths (TE LSPs). 129 [RFC8231] specifies extensions to PCEP to enable stateful control of 130 MPLS TE LSPs. It describes two mode of operations - Passive stateful 131 PCE and Active stateful PCE. Further, [I-D.ietf-pce-pce-initiated- 132 lsp] describes the setup, maintenance and teardown of PCE-Initiated 133 LSPs for the stateful PCE model. In this document, the focus is on 134 Active stateful PCE where the LSPs are controlled by the PCE. 136 Over time, based on the varying traffic pattern, an LSP established 137 with a certain bandwidth may require to adjust the bandwidth reserved 138 in the network dynamically. The head-end Label Switch Router (LSR) 139 monitors the actual bandwidth demand of the established LSP and 140 periodically computes new bandwidth. The head-end LSR adjusts the 141 bandwidth reservation of the LSP based on the computed bandwidth 142 automatically. This feature is commonly referred to as Auto- 143 Bandwidth. The Auto-Bandwidth feature is described in detail in 144 Section 4 of this document. 146 In the model considered in this document, the PCC (head-end of the 147 LSP) collects the traffic rate samples flowing through the LSP and 148 calculates the new adjusted bandwidth. The PCC reports the 149 calculated bandwidth to be adjusted to the PCE. This is similar to 150 the Passive stateful PCE model, while the Passive stateful PCE uses 151 path request/reply mechanism, the Active stateful PCE uses 152 report/update mechanism. In case of PCE-Initiated LSP, the PCC is 153 requested during the LSP initiation to monitor and calculate the new 154 adjusted bandwidth. [RFC8051] describes the use-case for Auto- 155 Bandwidth adjustment for Passive and Active stateful PCE. 157 [I-D.gandhi-pce-pm] describes the PCEP extensions for reporting the 158 performance measurements to the PCE, and includes the real-time 159 bandwidth utilization information of a TE LSP. Those extensions can 160 be used to implement the auto-bandwidth feature on a stateful PCE, 161 i.e. can be used to calculate the new bandwidth to be adjusted on the 162 stateful PCE. 164 This document defines the PCEP extensions needed to support Auto- 165 Bandwidth feature in a Active stateful PCE model where the LSP 166 bandwidth to be adjusted is calculated on the PCC (head-end of the 167 LSP). 169 2. Conventions Used in This Document 171 2.1. Requirements Language 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [RFC2119]. 177 2.2. Abbreviations 179 PCC: Path Computation Client. 181 PCE: Path Computation Element. 183 PCEP: Path Computation Element Communication Protocol. 185 TE LSP: Traffic Engineering Label Switched Path. 187 2.3. Terminology 189 The reader is assumed to be familiar with the terminology defined in 190 [RFC5440], [RFC8231], and [I-D.ietf-pce-pce-initiated-lsp]. 192 The following auto-bandwidth terminology is defined in this document. 194 Maximum Average Bandwidth (MaxAvgBw): The maximum average bandwidth 195 represents the current traffic bandwidth demand of the LSP during 196 a time interval. This is the maximum value of the traffic 197 bandwidth rate samples (Bandwidth-Samples) in a given 198 Adjustment-Interval. 200 Adjusted Bandwidth: This is the Auto-Bandwidth computed bandwidth 201 that is used to adjust the bandwidth reservation of the LSP. 203 Sample-Interval: The periodic time interval at which the measured 204 traffic rate of the LSP is collected as a Bandwidth-Sample. 206 Bandwidth-Sample: The bandwidth sample of the measured traffic rate 207 of the LSP collected at every Sample-Interval. 209 Maximum-Bandwidth: The maximum bandwidth that can be reserved for 210 the LSP. 212 Minimum-Bandwidth: The minimum bandwidth that can be reserved for 213 the LSP. 215 Up-Adjustment-Interval: The periodic time interval at which the 216 bandwidth adjustment should be made using the MaxAvgBw, when 217 MaxAvgBw is greater than the current bandwidth reservation of the 218 LSP. 220 Down-Adjustment-Interval: The periodic time interval at which the 221 bandwidth adjustment should be made using the MaxAvgBw, when 222 MaxAvgBw is lesser than the current bandwidth reservation of the 223 LSP. 225 Up-Adjustment-Threshold: This parameter is used to decide when the 226 LSP bandwidth should be adjusted. If the percentage or absolute 227 difference between the current MaxAvgBw and the current bandwidth 228 reservation is greater than or equal to the threshold value, the 229 LSP bandwidth is adjusted (upsized) to the current bandwidth 230 demand (Adjusted Bandwidth) at the Up-Adjustment-Interval expiry. 232 Down-Adjustment-Threshold: This parameter is used to decide when the 233 LSP bandwidth should be adjusted. If the percentage or absolute 234 difference between the current bandwidth reservation and the 235 current MaxAvgBw is greater than or equal to the threshold value, 236 the LSP bandwidth is adjusted (downsized) to the current bandwidth 237 demand (Adjusted Bandwidth) at the Down-Adjustment-Interval 238 expiry. 240 Overflow-Count: This parameter is used to decide when the LSP 241 bandwidth should be adjusted when there is a sudden increase in 242 traffic demand. This value indicates how many times 243 consecutively, the percentage or absolute difference between the 244 current MaxAvgBw and the current bandwidth reservation of the LSP 245 is greater than or equal to the Overflow-Threshold value. 247 Overflow-Threshold: This parameter is used to decide when the LSP 248 bandwidth should be adjusted when there is a sudden increase in 249 traffic demand. If the percentage or absolute difference between 250 the current MaxAvgBw and the current bandwidth reservation of the 251 LSP is greater than or equal to the threshold value, the overflow 252 condition is set to be met. The LSP bandwidth is adjusted to the 253 current bandwidth demand bypassing the Up-Adjustment-Interval if 254 the overflow condition is met consecutively for the Overflow- 255 Count. 257 Underflow-Count: This parameter is used to decide when the LSP 258 bandwidth should be adjusted when there is a sudden decrease in 259 traffic demand. This value indicates how many times 260 consecutively, the percentage or absolute difference between the 261 current MaxAvgBw and the current bandwidth reservation of the LSP 262 is greater than or equal to the Underflow-Threshold value. 264 Underflow-Threshold: This parameter is used to decide when the LSP 265 bandwidth should be adjusted when there is a sudden decrease in 266 traffic demand. If the percentage or absolute difference between 267 the current MaxAvgBw and the current bandwidth reservation of the 268 LSP is greater than or equal to the threshold value, the underflow 269 condition is set to be met. The LSP bandwidth is adjusted to the 270 current bandwidth demand bypassing the Down-Adjustment-Interval if 271 the underflow condition is met consecutively for the Underflow- 272 Count. 274 Minimum-Threshold: The increase or decrease of the LSP bandwidth 275 should be at least or above the minimum-threshold represented as 276 an absolute bandwidth value before the bandwidth adjustment for 277 the LSP is made. This threshold can be seen as a suppression 278 threshold that is used along with a percentage threshold to avoid 279 unnecessary auto-bandwidth adjustments and re-signaling of the LSP 280 at low bandwidth values. 282 3. Requirements for PCEP Extensions 284 The PCEP extensions required for auto-bandwidth are summarized in the 285 following table as well as in Figure 1. 287 +---------------------------------+---------------------------------+ 288 | PCC Initiated | PCE Initiated | 289 +---------------------------------+---------------------------------+ 290 | | | 291 | PCC monitors the traffic | At the time of initiation, | 292 | and reports the calculated | PCE request PCC to monitor | 293 | bandwidth to be adjusted | the traffic and report the | 294 | to the PCE. | calculated bandwidth to be | 295 | | adjusted to the PCE. | 296 | | | 297 | Extension is needed for PCC | Extension is needed for PCE | 298 | to pass on the adjustment | to pass on the adjustment | 299 | parameters at the time of | parameters at the time of | 300 | LSP Delegation. | LSP Initiation. | 301 | | | 302 +---------------------------------+---------------------------------+ 304 Table 1: Requirements for Auto-Bandwidth PCEP extensions 306 ---------- 307 | | 308 | PCE | 309 | | 310 ---------- 311 | ^ 312 AUTO-BANDWIDTH CAPABILITY | | AUTO-BANDWIDTH CAPABILITY 313 | | 314 AUTO-BANDWIDTH ATTRIBUTES | | AUTO-BANDWIDTH ATTRIBUTES 315 | | (For Delegated LSPs) 316 | | 317 | | REQUESTED BANDWIDTH 318 v | 319 ---------- 320 | | 321 | PCC | 322 | | 323 ---------- 325 Figure 1: Overview of Auto-Bandwidth PCEP extensions 327 The PCEP speaker supporting this document must have a mechanism to 328 advertise the automatic bandwidth adjustment capability for both PCC- 329 Initiated and PCE-Initiated LSPs. 331 Auto-bandwidth deployment considerations for PCEP extensions are 332 summarized below: 334 o It is required to identify and inform the PCC, the LSP that are 335 enabled with Auto-Bandwidth feature. Not all LSPs in some 336 deployments would like their bandwidth to be dependent on the 337 real-time bandwidth usage but be constant as set by the operator. 339 o In addition, an operator should be able to specify the auto- 340 bandwidth adjustment parameters (i.e. configuration knobs) to 341 control this feature (e.g. minimum/ maximum bandwidth range). The 342 PCC should be informed about these adjustment parameters. 344 4. Architectural Overview 346 4.1. Auto-Bandwidth Overview 348 Auto-Bandwidth feature allows automatic and dynamic adjustment of the 349 reserved bandwidth of an LSP over time, i.e. without network operator 350 intervention to accommodate the varying traffic demand of the LSP. 351 If the traffic flowing through the LSP is lower than the configured 352 or current reserved bandwidth of the LSP, the extra bandwidth is 353 being reserved needlessly and being wasted. Conversely, if the 354 actual traffic flowing through the LSP is higher than the configured 355 or current reserved bandwidth of the LSP, it can potentially cause 356 congestion or packet loss in the network. The initial LSP bandwidth 357 can be set to an arbitrary value (including zero), in practice, it 358 can be operator expected value based on design and planning. The 359 head-end Label Switch Router (LSR) monitors the actual traffic 360 flowing through the LSP and uses that information to adjust the 361 bandwidth reservation of the LSP in the network. The bandwidth 362 adjustment uses the make-before-break (MBB) signaling method so that 363 there is no disruption to the traffic flow carried by the LSP. 365 4.2. Auto-bandwidth Theory of Operation 367 When the Auto-Bandwidth feature is enabled, the measured traffic rate 368 is periodically sampled at each Sample-Interval (which can be 369 configured by an operator and the default value as 5 minutes) by the 370 PCC which is the head-end node of the LSP. The traffic rate samples 371 are accumulated over the Adjustment-Interval period (which can be 372 configured by an operator and the default value as 24 hours). The 373 PCC, in-charge of calculating the bandwidth to be adjusted, will 374 adjust the bandwidth of the LSP to the highest traffic rate sample 375 (MaxAvgBw) amongst the set of bandwidth samples collected over the 376 adjustment-interval period (in the Up or Down direction). 378 Note that the highest traffic rate sample could be higher or lower 379 than the current LSP bandwidth. Only if the difference between the 380 current bandwidth demand (MaxAvgBw) and the current bandwidth 381 reservation is greater than or equal to the Adjustment-Threshold 382 (percentage or absolute value) (which can be configured by an 383 operator and the default as 5 percentage), the LSP bandwidth is 384 adjusted (upsized) to the current bandwidth demand (MaxAvgBw). 385 Similarly, if the difference between the current bandwidth 386 reservation and the current bandwidth demand (MaxAvgBw) is greater 387 than or equal to the Down-Adjustment-Threshold (percentage or 388 absolute value), the LSP bandwidth is adjusted (downsized) to the 389 current bandwidth demand (MaxAvgBw). Some LSPs are less eventful 390 while other LSPs may encounter a lot of changes in the traffic 391 pattern. The thresholds and intervals for bandwidth adjustment are 392 configured based on the traffic pattern of the LSP. 394 In order to avoid frequent re-signaling, an operator may set a longer 395 adjustment-interval value (Up and/or Down). However, longer 396 adjustment-interval can result in an undesirable effect of masking 397 sudden changes in traffic demands of an LSP. To avoid this, the 398 Auto-Bandwidth feature may pre-maturely expire the adjustment- 399 interval and adjust the LSP bandwidth to accommodate the sudden 400 bursts of increase in traffic demand as an overflow condition or 401 decrease in traffic demand as an underflow condition. An operator 402 needs to configure appropriate values for the Overflow-Threshold 403 and/or Underflow-Threshold parameters and they do not have default 404 values defined in this document. 406 All thresholds in this document could be represented in both absolute 407 value and percentage, and could be used together. This is provided 408 to accommodate the cases where the LSP bandwidth reservation may 409 become very large or very small over time. For example, an operator 410 may use the percentage threshold to handle small to large bandwidth 411 values and absolute values to handle very large bandwidth values. 412 The auto-bandwidth adjustment is made when either one of the two 413 thresholds, the absolute or percentage, is crossed. 415 When using the (adjustment/overflow/underflow) percentage thresholds, 416 if the LSP bandwidth changes rapidly at very low values, it may 417 trigger frequent auto-bandwidth adjustments due to the crossing of 418 the percentage thresholds. This can lead to unnecessary re-signaling 419 of the LSPs in the network. This is suppressed by setting the 420 minimum-threshold parameters along with the percentage thresholds. 421 The auto-bandwidth adjustment is only made if the LSP bandwidth 422 crosses both the percentage threshold and the minimum-threshold 423 parameters. 425 4.3. Scaling Considerations 427 It should be noted that any bandwidth change requires re-signaling of 428 an LSP in a make-before-break fashion, which can further trigger 429 preemption of lower priority LSPs in the network. When deployed 430 under scale, this can lead to a signaling churn in the network. The 431 Auto-bandwidth application algorithm is thus advised to take this 432 into consideration before adjusting the LSP bandwidth. Operators are 433 advised to set the values of various auto-bandwidth adjustment 434 parameters appropriate for the deployed LSP scale. 436 If a PCE gets overwhelmed, it can notify the PCC to temporarily 437 suspend the reporting of the new LSP bandwidth to be adjusted (see 438 Section 5.7 of this document). Similarly, if a PCC gets overwhelmed 439 due to signaling churn, it can notify the PCE to temporarily suspend 440 new LSP setup requests. 442 5. Extensions to the PCEP 444 5.1. Capability Advertisement 446 During PCEP Initialization Phase, PCEP speakers (PCE or PCC) 447 advertise their support of Automatic Bandwidth adjustment feature. A 448 PCEP speaker includes the "Auto-Bandwidth Capability" TLV, in the 449 OPEN Object to advertise its support for PCEP Auto-Bandwidth 450 extensions. The presence of the "Auto-Bandwidth Capability" TLV in 451 the OPEN Object indicates that the Automatic Bandwidth feature is 452 supported as described in this document. 454 o The PCEP protocol extensions for Auto-Bandwidth adjustments MUST 455 NOT be used if one or both PCEP speakers have not included the 456 "Auto-Bandwidth Capability" TLV in their respective OPEN message. 458 o The PCEP speaker that does not recognize the extensions defined in 459 this document sends the PCErr message with error-type 2 460 (capability not supported) as per Section 6.9 in [RFC5440]. 462 o If the PCEP speaker that supports the extensions defined in this 463 document but did not advertise this capability, then upon receipt 464 of AUTO-BANDWIDTH-ATTRIBUTES TLV in the LSPA object, it SHOULD 465 generate a PCErr with error-type 19 (Invalid Operation), error- 466 value TBD4 (Auto-Bandwidth capability was not advertised) and 467 ignore the AUTO-BANDWIDTH-ATTRIBUTES TLV. 469 5.1.1. AUTO-BANDWIDTH-CAPABILITY TLV 471 The AUTO-BANDWIDTH-CAPABILITY TLV is an optional TLV for use in the 472 OPEN Object for Automatic Bandwidth Adjustment via PCEP capability 473 advertisement. Its format is shown in the following figure: 475 0 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Type=TBD2 | Length=4 | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Flags | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 AUTO-BANDWIDTH-CAPABILITY TLV format 485 The Type of the TLV is (TBD2) and it has a fixed Length of 4 octets. 487 The value comprises a single field - Flags (32 bits). No flags are 488 defined for this TLV in this document. 490 Unassigned bits are considered reserved. They MUST be set to 0 on 491 transmission and MUST be ignored on receipt. 493 Advertisement of the Auto-Bandwidth capability TLV implies support of 494 auto-bandwidth adjustment, as well as the objects, TLVs and 495 procedures defined in this document. 497 5.2. AUTO-BANDWIDTH-ATTRIBUTES TLV 499 The AUTO-BANDWIDTH-ATTRIBUTES TLV provides the 'configurable knobs' 500 of the feature and it can be included as an optional TLV in the LSPA 501 Object (as described in [RFC5440]). 503 For PCE-Initiated LSP [I-D.ietf-pce-pce-initiated-lsp], this TLV is 504 included in the LSPA Object with the PCInitiate message. For the 505 PCC-Initiated delegated LSPs, this TLV is carried in the PCRpt 506 message in LSPA Object. This TLV is also carried in the LSPA object 507 with the PCUpd message to direct the PCC (LSP head-end) to make 508 updates to auto-bandwidth attributes such as Adjustment-Interval. 510 The TLV is encoded in all PCEP messages for the LSP while the auto- 511 bandwidth adjustment feature is enabled, the absence of the TLV 512 indicates the PCEP speaker wish to disable the feature. 514 The format of the AUTO-BANDWIDTH-ATTRIBUTES TLV is shown in the 515 following figure: 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Type=TBD1 | Length | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | | 523 // sub-TLVs // 524 | | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 AUTO-BANDWIDTH-ATTRIBUTES TLV format 529 Type: TBD1 531 Length: The Length field defines the length of the value portion 532 in octets as per [RFC5440]. 534 Value: This comprises one or more sub-TLVs. 536 Following sub-TLVs are defined in this document: 538 Type Len Name 539 ------------------------------------------------------------------- 540 1 4 Sample-Interval sub-TLV 541 2 4 Adjustment-Interval sub-TLV 542 3 4 Down-Adjustment-Interval sub-TLV 543 4 4 Adjustment-Threshold sub-TLV 544 5 8 Adjustment-Threshold-Percentage sub-TLV 545 6 4 Down-Adjustment-Threshold sub-TLV 546 7 8 Down-Adjustment-Threshold-Percentage sub-TLV 547 8 4 Minimum-Bandwidth sub-TLV 548 9 4 Maximum-Bandwidth sub-TLV 549 10 8 Overflow-Threshold sub-TLV 550 11 8 Overflow-Threshold-Percentage sub-TLV 551 12 8 Underflow-Threshold sub-TLV 552 13 8 Underflow-Threshold-Percentage sub-TLV 554 Future specification can define additional sub-TLVs. 556 The sub-TLVs are encoded to inform the PCEP peer the various sampling 557 and adjustment parameters. If sub-TLVs are not present, the default 558 values as specified in this document are used or otherwise based on 559 the local policy are assumed. 561 All sub-TLVs are optional and any unrecognized sub-TLV MUST be 562 silently ignored. If a sub-TLV of same type appears more than once, 563 only the first occurrence is processed and all others MUST be 564 ignored. 566 The following sub-sections describe the sub-TLVs which are currently 567 defined to be carried within the AUTO-BANDWIDTH-ATTRIBUTES TLV. 569 5.2.1. Sample-Interval sub-TLV 571 The Sample-Interval sub-TLV specifies a time interval in seconds at 572 which traffic samples are collected at the PCC. 574 0 1 2 3 575 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 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Type=1 | Length=4 | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Sample-Interval | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 Sample-Interval sub-TLV format 584 The Type is 1, Length is 4 octets, and the value comprises of - 586 o Sample-Interval: The 4-octet time interval for bandwidth sample 587 collection. The valid range is from 1 to 604800, in seconds. The 588 default value is 300 seconds. The sample-interval parameter MUST 589 NOT be greater than the (down) adjustment-interval. 591 5.2.2. Adjustment Intervals 593 The sub-TLVs in this section are encoded to inform the PCEP peer the 594 adjustment interval parameters. An implementation MAY require to set 595 different adjustment interval values for when the bandwidth usage 596 trend is moving upwards or downwards. The Adjustment-Interval sub- 597 TLV specifies the time interval for both upward and downward trend. 598 If the operator would like to use a different adjustment interval 599 during the downward trend, the Down-Adjustment-Interval sub-TLV is 600 included. 602 5.2.2.1. Adjustment-Interval sub-TLV 604 The Adjustment-Interval sub-TLV specifies a time interval in seconds 605 at which bandwidth adjustment should be made when MaxAvgBw is greater 606 than or less than the current bandwidth reservation of the LSP. 608 0 1 2 3 609 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 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Type=2 | Length=4 | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Adjustment-Interval | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 Adjustment-Interval sub-TLV format 618 The Type is 2, Length is 4 octets, and the value comprises of - 620 o Adjustment-Interval: The 4-octet time interval for bandwidth 621 adjustments. The valid range is from 1 to 604800, in seconds. 622 The default value is 86400 seconds. The adjustment-interval 623 parameter MUST NOT be less than the sample-interval. 625 5.2.2.2. Down-Adjustment-Interval sub-TLV 627 The Down-Adjustment-Interval sub-TLV specifies a time interval in 628 seconds at which bandwidth adjustment should be made when MaxAvgBw is 629 less than the current bandwidth reservation of the LSP. This 630 parameter overwrites the Adjustment-Interval for the downward trend. 632 0 1 2 3 633 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 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Type=3 | Length=4 | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Down-Adjustment-Interval | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 Down-Adjustment-Interval sub-TLV format 642 The Type is 3, Length is 4 octets, and the value comprises of - 644 o Down-Adjustment-Interval: The 4-octet time interval for downward 645 bandwidth adjustments. The valid range is from 1 to 604800, in 646 seconds. The default value equals the adjustment-interval. The 647 down-adjustment-interval parameter MUST NOT be less than the 648 sample-interval. 650 5.2.3. Adjustment Thresholds 652 The sub-TLVs in this section are encoded to inform the PCEP peer the 653 adjustment threshold parameters. An implementation MAY include both 654 sub-TLVs for the absolute value and the percentage, in which case the 655 bandwidth is adjusted when either of the adjustment threshold 656 conditions are met. The Adjustment-Threshold sub-TLV specifies the 657 threshold for both upward and downward trend. If the operator would 658 like to use a different adjustment threshold during the downward 659 trend, the Down-Adjustment-Threshold sub-TLV is included. Similarly, 660 the Adjustment-Threshold-Percentage sub-TLV specifies the threshold 661 percentage for both upward and downward trend. If the operator would 662 like to use a different adjustment threshold percentage during the 663 downward trend, the Down-Adjustment-Threshold-Percentage sub-TLV is 664 included. 666 5.2.3.1. Adjustment-Threshold sub-TLV 668 The Adjustment-Threshold sub-TLV is used to decide when the LSP 669 bandwidth should be adjusted when MaxAvgBw is greater than or less 670 than the current bandwidth reservation. 672 0 1 2 3 673 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 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Type=4 | Length=4 | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Adjustment-Threshold | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 Adjustment-Threshold sub-TLV format 682 The Type is 4, Length is 4 octets, and the value comprises of - 684 o Adjustment-Threshold: The absolute Adjustment-Threshold bandwidth 685 value, encoded in IEEE floating point format (see 686 [IEEE.754.1985]), expressed in bytes per second. The default 687 adjustment-threshold value is not set. Refer to Section 3.1.2 of 688 [RFC3471] for a table of commonly used values. 690 If the difference between the current MaxAvgBw and the current 691 bandwidth reservation is greater than or less than or equal to the 692 threshold value, the LSP bandwidth is adjusted to the current 693 bandwidth demand (MaxAvgBw). 695 5.2.3.2. Adjustment-Threshold-Percentage sub-TLV 697 The Adjustment-Threshold-Percentage sub-TLV is used to decide when 698 the LSP bandwidth should be adjusted when MaxAvgBw is greater than or 699 less than the current bandwidth reservation. 701 0 1 2 3 702 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 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Type=5 | Length=8 | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Reserved | Percentage | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Minimum-Threshold | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 Adjustment-Threshold-Percentage sub-TLV format 713 The Type is 5, Length is 8 octets, and the value comprises of - 715 o Reserved: SHOULD be set to zero on transmission and MUST be 716 ignored on receipt. 718 o Percentage: The Adjustment-Threshold value (7 bits), encoded in 719 percentage (an integer from 1 to 100). The value 0 is considered 720 to be invalid. The default value is 5 percent. 722 o Minimum-Threshold: The absolute Minimum-Threshold bandwidth value, 723 encoded in IEEE floating point format (see [IEEE.754.1985]), 724 expressed in bytes per second. The increase or decrease of the 725 LSP bandwidth should be at least or above the minimum-threshold 726 before the bandwidth adjustment is made. The default value is 0. 728 If the percentage difference between the current MaxAvgBw and the 729 current bandwidth reservation is greater than or less than or equal 730 to the threshold percentage, the LSP bandwidth is adjusted to the 731 current bandwidth demand (MaxAvgBw) (as long as the difference in the 732 bandwidth is at least or above the Minimum-Threshold). 734 5.2.3.3. Down-Adjustment-Threshold sub-TLV 736 The Down-Adjustment-Threshold sub-TLV is used to decide when the LSP 737 bandwidth should be adjusted when MaxAvgBw is lesser than the current 738 bandwidth reservation. This parameter overwrites the Adjustment- 739 Threshold for the downward trend. 741 0 1 2 3 742 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 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | Type=6 | Length=4 | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Down-Adjustment-Threshold | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 Down-Adjustment-Threshold sub-TLV format 751 The Type is 6, Length is 4 octets, and the value comprises of - 752 o Down-Adjustment-Threshold: The absolute Down-Adjustment-Threshold 753 bandwidth value, encoded in IEEE floating point format (see 754 [IEEE.754.1985]), expressed in bytes per second. The default 755 value equals the adjustment-threshold. Refer to Section 3.1.2 of 756 [RFC3471] for a table of commonly used values. 758 If the difference between current bandwidth reservation and the 759 current MaxAvgBw is greater than or equal to the threshold value, the 760 LSP bandwidth is adjusted to the current bandwidth demand (MaxAvgBw). 762 5.2.3.4. Down-Adjustment-Threshold-Percentage sub-TLV 764 The Down-Adjustment-Threshold-Percentage sub-TLV is used to decide 765 when the LSP bandwidth should be adjusted when MaxAvgBw is lesser 766 than the current bandwidth reservation. This parameter overwrites 767 the Adjustment-Threshold-Percentage for the downward trend. 769 0 1 2 3 770 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 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Type=7 | Length=8 | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | Reserved | Percentage | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | Minimum-Threshold | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 Down-Adjustment-Threshold-Percentage sub-TLV format 781 The Type is 7, Length is 8 octets, and the value comprises of - 783 o Reserved: SHOULD be set to zero on transmission and MUST be 784 ignored on receipt. 786 o Percentage: The Down-Adjustment-Threshold value (7 bits), encoded 787 in percentage (an integer from 1 to 100). The value 0 is 788 considered to be invalid. The default value equals the 789 adjustment-threshold-percentage. 791 o Minimum-Threshold: The absolute Minimum-Threshold bandwidth value, 792 encoded in IEEE floating point format (see [IEEE.754.1985]), 793 expressed in bytes per second. The decrease of the LSP bandwidth 794 should be at least or above the minimum-threshold before the 795 bandwidth adjustment is made. The default value equals the 796 minimum-threshold for the adjustment-threshold-percentage. 798 If the percentage difference between the current bandwidth 799 reservation and the current MaxAvgBw is greater than or equal to the 800 threshold percentage, the LSP bandwidth is adjusted to the current 801 bandwidth demand (MaxAvgBw) (as long as the difference in the 802 bandwidth is at least or above the Minimum-Threshold). 804 5.2.4. Minimum and Maximum Bandwidth Values 806 5.2.4.1. Minimum-Bandwidth sub-TLV 808 The Minimum-Bandwidth sub-TLV specify the minimum bandwidth allowed 809 for the LSP, and is expressed in bytes per second. The LSP bandwidth 810 cannot be adjusted below the minimum bandwidth value. 812 0 1 2 3 813 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 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Type=8 | Length=4 | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Minimum-Bandwidth | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 Minimum-Bandwidth sub-TLV format 822 The Type is 8, Length is 4 octets, and the value comprises of - 824 o Minimum-Bandwidth: The 4-octet bandwidth value encoded in IEEE 825 floating point format (see [IEEE.754.1985]), expressed in bytes 826 per second. The default minimum-bandwidth value is set to 0. 827 Refer to Section 3.1.2 of [RFC3471] for a table of commonly used 828 values. 830 5.2.4.2. Maximum-Bandwidth sub-TLV 832 The Maximum-Bandwidth sub-TLV specify the maximum bandwidth allowed 833 for the LSP, and is expressed in bytes per second. The LSP bandwidth 834 cannot be adjusted above the maximum bandwidth value. 836 0 1 2 3 837 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 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Type=9 | Length=4 | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Maximum-Bandwidth | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 Maximum-Bandwidth sub-TLV format 846 The Type is 9, Length is 4 octets, and the value comprises of - 847 o Maximum-Bandwidth: The 4-octet bandwidth value encoded in IEEE 848 floating point format (see [IEEE.754.1985]), expressed in bytes 849 per second. The default maximum-bandwidth value is not set. 850 Refer to Section 3.1.2 of [RFC3471] for a table of commonly used 851 values. 853 5.2.5. Overflow and Underflow Conditions 855 The sub-TLVs in this section are encoded to inform the PCEP peer the 856 overflow and underflow threshold parameters. An implementation MAY 857 include sub-TLVs for an absolute value and/or a percentage for the 858 threshold, in which case the bandwidth is immediately adjusted when 859 either of the threshold conditions is met consecutively for the given 860 count (as long as the difference in the bandwidth is at least or 861 above the Minimum-Threshold). By default, the threshold values for 862 overflow and underflow conditions are not set. 864 5.2.5.1. Overflow-Threshold sub-TLV 866 The Overflow-Threshold sub-TLV is used to decide if the LSP bandwidth 867 should be adjusted immediately. 869 0 1 2 3 870 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 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Type=10 | Length=8 | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Reserved | Count | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | Overflow-Threshold | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 Overflow-Threshold sub-TLV format 881 The Type is 10, Length is 8 octets, and the value comprises of - 883 o Reserved: SHOULD be set to zero on transmission and MUST be 884 ignored on receipt. 886 o Count: The Overflow-Count value (5 bits), encoded in integer. The 887 value 0 is considered to be invalid. The number of consecutive 888 samples for which the overflow condition MUST be met for the LSP 889 bandwidth to be immediately adjusted to the current bandwidth 890 demand, bypassing the (up) adjustment-interval. 892 o Overflow-Threshold: The absolute Overflow-Threshold bandwidth 893 value, encoded in IEEE floating point format (see 894 [IEEE.754.1985]), expressed in bytes per second. Refer to Section 895 3.1.2 of [RFC3471] for a table of commonly used values. If the 896 increase of the current MaxAvgBw from the current bandwidth 897 reservation is greater than or equal to the threshold value, the 898 overflow condition is met. 900 5.2.5.2. Overflow-Threshold-Percentage sub-TLV 902 The Overflow-Threshold-Percentage sub-TLV is used to decide if the 903 LSP bandwidth should be adjusted immediately. 905 0 1 2 3 906 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 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | Type=11 | Length=8 | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Percentage | Reserved | Count | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Minimum-Threshold | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 Overflow-Threshold-Percentage sub-TLV format 917 The Type is 11, Length is 8 octets, and the value comprises of - 919 o Percentage: The Overflow-Threshold value (7 bits), encoded in 920 percentage (an integer from 1 to 100). The value 0 is considered 921 to be invalid. If the percentage increase of the current MaxAvgBw 922 from the current bandwidth reservation is greater than or equal to 923 the threshold percentage, the overflow condition is met. 925 o Reserved: SHOULD be set to zero on transmission and MUST be 926 ignored on receipt. 928 o Count: The Overflow-Count value (5 bits), encoded in integer. The 929 value 0 is considered to be invalid. The number of consecutive 930 samples for which the overflow condition MUST be met for the LSP 931 bandwidth to be immediately adjusted to the current bandwidth 932 demand, bypassing the (up) adjustment-interval. 934 o Minimum-Threshold: The absolute Minimum-Threshold bandwidth value, 935 encoded in IEEE floating point format (see [IEEE.754.1985]), 936 expressed in bytes per second. The increase of the LSP bandwidth 937 should be at least or above the minimum-threshold before the 938 bandwidth adjustment is made. 940 5.2.5.3. Underflow-Threshold sub-TLV 942 The Underflow-Threshold sub-TLV is used to decide if the LSP 943 bandwidth should be adjusted immediately. 945 0 1 2 3 946 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 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Type=12 | Length=8 | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Reserved | Count | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | Underflow-Threshold | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 Underflow-Threshold sub-TLV format 957 The Type is 12, Length is 8 octets, and the value comprises of - 959 o Reserved: SHOULD be set to zero on transmission and MUST be 960 ignored on receipt. 962 o Count: The Underflow-Count value (5 bits), encoded in integer. 963 The value 0 is considered to be invalid. The number of 964 consecutive samples for which the underflow condition MUST be met 965 for the LSP bandwidth to be immediately adjusted to the current 966 bandwidth demand, bypassing the down-adjustment-interval. 968 o Underflow-Threshold: The absolute Underflow-Threshold bandwidth 969 value, encoded in IEEE floating point format (see 970 [IEEE.754.1985]), expressed in bytes per second. Refer to Section 971 3.1.2 of [RFC3471] for a table of commonly used values. If the 972 decrease of the current MaxAvgBw from the current bandwidth 973 reservation is greater than or equal to the threshold value, the 974 underflow condition is met. 976 5.2.5.4. Underflow-Threshold-Percentage sub-TLV 978 The Underflow-Threshold-Percentage sub-TLV is used to decide if the 979 LSP bandwidth should be adjusted immediately. 981 0 1 2 3 982 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 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Type=13 | Length=8 | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Percentage | Reserved | Count | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Minimum-Threshold | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 Underflow-Threshold-Percentage sub-TLV format 992 The Type is 13, Length is 8 octets, and the value comprises of - 994 o Percentage: The Underflow-Threshold value (7 bits), encoded in 995 percentage (an integer from 1 to 100). The value 0 is considered 996 to be invalid. If the percentage decrease of the current MaxAvgBw 997 from the current bandwidth reservation is greater than or equal to 998 the threshold percentage, the underflow condition is met. 1000 o Reserved: SHOULD be set to zero on transmission and MUST be 1001 ignored on receipt. 1003 o Count: The Underflow-Count value (5 bits), encoded in integer. 1004 The value 0 is considered to be invalid. The number of 1005 consecutive samples for which the underflow condition MUST be met 1006 for the LSP bandwidth to be immediately adjusted to the current 1007 bandwidth demand, bypassing the down-adjustment-interval. 1009 o Minimum-Threshold: The absolute Minimum-Threshold bandwidth value, 1010 encoded in IEEE floating point format (see [IEEE.754.1985]), 1011 expressed in bytes per second. The decrease of the LSP bandwidth 1012 should be at least or above the minimum-threshold before the 1013 bandwidth adjustment is made. 1015 5.3. BANDWIDTH Object 1017 As per [RFC5440], the BANDWIDTH object (Object-Class value 5) is 1018 defined with two Object-Type values as following: 1020 o Requested Bandwidth: BANDWIDTH Object-Type value is 1. 1022 o Re-optimization Bandwidth: Bandwidth of an existing TE LSP for 1023 which a re-optimization is requested. BANDWIDTH Object-Type value 1024 is 2. 1026 The PCC reports the calculated bandwidth to be adjusted (MaxAvgBw) to 1027 the Stateful PCE using the existing 'Requested Bandwidth' with 1028 BANDWIDTH Object-Type as 1. The reporting of the 're-optimization 1029 bandwidth' with BANDWIDTH Object-Type as 2 is not required as the 1030 Stateful PCE is aware of the existing LSP bandwidth. 1032 5.4. The PCInitiate Message 1034 A PCInitiate message is a PCEP message sent by a PCE to a PCC to 1035 trigger LSP instantiation or deletion 1036 [I.D.ietf-pce-pce-initiated-lsp]. 1038 For the PCE-Initiated LSP with Auto-Bandwidth feature enabled, AUTO- 1039 BANDWIDTH-ATTRIBUTES TLV MUST be included in the LSPA object with the 1040 PCInitiate message. 1042 The definition (RBNF) of the PCInitiate message 1043 [I.D.ietf-pce-pce-initiated-lsp] is unchanged by this document. 1045 5.5. The PCUpd Message 1047 A PCUpd message is a PCEP message sent by a PCE to a PCC to update 1048 the LSP parameters [RFC8231]. 1050 For PCE-Initiated LSPs with Auto-Bandwidth feature enabled, AUTO- 1051 BANDWIDTH-ATTRIBUTES TLV MUST be included in the LSPA object with the 1052 PCUpd message. The PCE can send this TLV to direct the PCC to change 1053 the auto-bandwidth parameters. 1055 The definition (RBNF) of the PCUpd message [RFC8231] is unchanged by 1056 this document. 1058 5.6. The PCRpt Message 1060 The PCRpt message [RFC8231] is a PCEP message sent by a PCC to a PCE 1061 to report the status of one or more LSPs. 1063 For PCE-Initiated LSPs [I.D.ietf-pce-pce-initiated-lsp], the PCC 1064 creates the LSP using the attributes communicated by the PCE, and 1065 using the local values for the unspecified parameters. After the 1066 successful instantiation of the LSP, PCC automatically delegates the 1067 LSP to the PCE and generates a PCRpt message to provide the status 1068 report for the LSP. 1070 For both PCE-Initiated and PCC-Initiated LSPs, when the LSP is 1071 delegated to a PCE for the very first time as well as after the 1072 successful delegation, the BANDWIDTH object of type 1 is used to 1073 specify the requested bandwidth in the PCRpt message. 1075 For all LSPs with Auto-Bandwidth feature enabled, AUTO-BANDWIDTH- 1076 ATTRIBUTES TLV MUST be included in the LSPA object of the PCRpt 1077 message. 1079 The definition (RBNF) of the PCRpt message [RFC8231] is unchanged by 1080 this document. 1082 5.7. The PCNtf Message 1084 As per [RFC5440], the PCEP Notification message (PCNtf) can be sent 1085 by a PCEP speaker to notify its peer of a specific event. 1087 A PCEP speaker (PCE or PCC) SHOULD notify its PCEP peer (PCC or PCE) 1088 when it is in overwhelmed state due to the auto-bandwidth feature. 1089 Upon receipt of such notification, the peer SHOULD NOT send any PCEP 1090 messages related to auto-bandwidth adjustment. If a PCEP message 1091 related to auto-bandwidth is received during in overwhelmed state, it 1092 MUST be silently ignored. 1094 o When a PCEP speaker is overwhelmed, it SHOULD notify its peer by 1095 sending a PCNtf message with Notification Type = TBD3 (Auto- 1096 bandwidth Overwhelm State) and Notification Value = 1 (Entering 1097 auto-bandwidth overwhelm state). Optionally, OVERLOADED-DURATION 1098 TLV [RFC5440] MAY be included that specifies the time period 1099 during which no further PCEP messages related to auto-bandwidth 1100 adjustment should be sent. 1102 o When the PCEP speaker is no longer in the overwhelm state and is 1103 available to process the auto-bandwidth adjustments, it SHOULD 1104 notify its peer by sending a PCNtf message with Notification Type 1105 = TBD3 (Auto-bandwidth Overwhelm State) and Notification Value = 2 1106 (Clearing auto-bandwidth overwhelm state). 1108 When Auto-Bandwidth feature is deployed, a PCE can send this 1109 notification to PCC when a PCC is reporting frequent auto-bandwidth 1110 adjustments. If a PCC is overwhelmed with re-signaling, it can also 1111 notify the PCE to not adjust the LSP bandwidth while in overwhelm 1112 state. 1114 6. Security Considerations 1116 This document defines AUTO-BANDWIDTH-CAPABILITY TLV and 1117 AUTO-BANDWIDTH-ATTRIBUTES TLV which do not add any new security 1118 concerns beyond those discussed in [RFC5440] and [RFC8231] in itself. 1119 Some deployments may find the auto-bandwidth information as extra 1120 sensitive as it could be used to influence LSP path computation and 1121 LSP setup with adverse effect. Additionally, snooping of PCEP 1122 messages with such data or using PCEP messages for network 1123 reconnaissance, may give an attacker sensitive information about the 1124 operations of the network. Thus, such deployment should employ 1125 suitable PCEP security mechanisms like TCP Authentication Option 1126 (TCP-AO) [RFC5925] or [RFC8253]. 1128 7. Manageability Considerations 1130 7.1. Control of Function and Policy 1132 The Auto-Bandwidth feature SHOULD be controlled per LSP (at PCC 1133 (head-end of the LSP) or PCE) and the values for auto-bandwidth 1134 parameters e.g. sample-interval, adjustment-interval (up/down), 1135 minimum-bandwidth, maximum-bandwidth, adjustment-threshold (up/down) 1136 SHOULD be configurable by an operator. 1138 7.2. Information and Data Models 1140 A Management Information Base (MIB) module for modeling PCEP is 1141 described in [RFC7420]. However, one may prefer the mechanism for 1142 configuration using YANG data model [I-D.ietf-pce-pcep-yang]. These 1143 SHOULD be enhanced to provide controls and indicators for support of 1144 auto-bandwidth feature. Support for various configuration knobs as 1145 well as counters of messages sent/received containing the TLVs 1146 defined in this document SHOULD be added. 1148 7.3. Liveness Detection and Monitoring 1150 The mechanisms defined in this document do not imply any new liveness 1151 detection and monitoring requirements in addition to those already 1152 listed in [RFC5440]. 1154 7.4. Verify Correct Operations 1156 The mechanisms defined in this document do not imply any new 1157 operation verification requirements in addition to those already 1158 listed in [RFC5440]. 1160 7.5. Requirements On Other Protocols 1162 The mechanisms defined in this document do not add any new 1163 requirements on other protocols. 1165 7.6. Impact On Network Operations 1167 In order to avoid any unacceptable impact on network operations, an 1168 implementation SHOULD allow a limit to be placed on the number of 1169 LSPs that can be enabled with auto-bandwidth feature. An 1170 implementation MAY allow a limit to be placed on the rate of auto- 1171 bandwidth related messages sent by a PCEP speaker and received by a 1172 peer. An implementation MAY also allow sending a notification when a 1173 PCEP speaker is overwhelmed or the rate of messages reach a 1174 threshold. 1176 8. IANA Considerations 1178 8.1. PCEP TLV Type Indicators 1180 This document defines the following new PCEP TLVs; IANA is requested 1181 to make the following allocations from the "PCEP TLV Type Indicators" 1182 sub-registry of the PCEP Numbers registry, as follows: 1184 Value Name Reference 1185 ----------------------------------------------------------------- 1186 TBD2 AUTO-BANDWIDTH-CAPABILITY [This document] 1187 TBD1 AUTO-BANDWIDTH-ATTRIBUTES [This document] 1189 8.2. AUTO-BANDWIDTH-CAPABILITY TLV Flag Field 1191 IANA is requested to create a sub-registry to manage the Flag field 1192 of the AUTO-BANDWIDTH-CAPABILITY TLV. 1194 New bit numbers are to be assigned by Standards Action [RFC8126]. 1195 Each bit should be tracked with the following qualities: 1197 o Bit number (counting from bit 0 as the most significant bit) 1199 o Capability description 1201 o Defining RFC 1203 There is no bit defined for the AUTO-BANDWIDTH-CAPABILITY TLV Object 1204 flag field in this document. 1206 8.3. AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV 1208 This document specifies the AUTO-BANDWIDTH-ATTRIBUTES Sub-TLVs. IANA 1209 is requested to create an "AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV Types" 1210 sub-registry in the "PCEP TLV Type Indicators" for the sub-TLVs 1211 carried in the AUTO-BANDWIDTH-ATTRIBUTES TLV. New sub-TLV are 1212 assigned by Standards Action [RFC8126]. 1214 This document defines the following types: 1216 Type Name Reference 1217 ----------------------------------------------------------------- 1218 0 Reserved [This document] 1219 1 Sample-Interval sub-TLV [This document] 1220 2 Adjustment-Interval sub-TLV [This document] 1221 3 Down-Adjustment-Interval sub-TLV [This document] 1222 4 Adjustment-Threshold sub-TLV [This document] 1223 5 Adjustment-Threshold-Percentage sub-TLV [This document] 1224 6 Down-Adjustment-Threshold sub-TLV [This document] 1225 7 Down-Adjustment-Threshold-Percentage sub-TLV [This document] 1226 8 Minimum-Bandwidth sub-TLV [This document] 1227 9 Maximum-Bandwidth sub-TLV [This document] 1228 10 Overflow-Threshold sub-TLV [This document] 1229 11 Overflow-Threshold-Percentage sub-TLV [This document] 1230 12 Underflow-Threshold sub-TLV [This document] 1231 13 Underflow-Threshold-Percentage sub-TLV [This document] 1232 14- Unassigned [This document] 1233 65535 1235 8.4. Error Object 1237 This document defines a new Error-Value for PCErr message of Error- 1238 Type 19 (Invalid Operation) [RFC8231]. IANA is requested to allocate 1239 new error-value within the "PCEP-ERROR Object Error Types and Values" 1240 subregistry of the PCEP Numbers registry, as follows: 1242 Error-Type Meaning & error values Reference 1243 ----------------------------------------------------------------- 1244 19 Invalid Operations 1246 Error-Value = TBD4: [This document] 1247 Auto-Bandwidth Capability 1248 was not Advertised 1250 8.5. Notification Object 1252 IANA is requested to allocate new Notification Types and Notification 1253 Values within the "Notification Object" sub-registry of the PCEP 1254 Numbers registry, as follows: 1256 Type Meaning Reference 1257 ----------------------------------------------------------------- 1258 TBD3 Auto-Bandwidth Overwhelm State [This document] 1260 Notification-value=1: Entering Auto-Bandwidth 1261 overwhelm state 1262 Notification-value=2: Clearing Auto-Bandwidth 1263 overwhelm state 1265 9. References 1267 9.1. Normative References 1269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1270 Requirement Levels", BCP 14, RFC 2119, March 1997. 1272 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 1273 (PCE) Communication Protocol (PCEP)", RFC 5440, March 1274 2009. 1276 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1277 Writing an IANA Considerations Section in RFCs", BCP 26, 1278 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1279 . 1281 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Pah 1282 Computation Element Communication Protocol (PCEP) 1283 Extensions for Stateful PCE", RFC 8231, DOI 1284 10.17487/RFC8231, September 2017, . 1287 [I-D.ietf-pce-pce-initiated-lsp] Crabbe, E., Minei, I., Sivabalan, 1288 S., and R. Varga, "PCEP Extensions for PCE-initiated LSP 1289 Setup in a Stateful PCE Model", draft-ietf-pce-pce- 1290 initiated-lsp (work in progress). 1292 9.2. Informative References 1294 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1295 (GMPLS) Signaling Functional Description", RFC 3471, 1296 January 2003. 1298 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1299 Authentication Option", RFC 5925, June 2010. 1301 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1302 Hardwick, "Path Computation Element Communication Protocol 1303 (PCEP) Management Information Base (MIB) Module", RFC 1304 7420, December 2014. 1306 [RFC8051] Zhang, X. and I. Minei, "Applicability of a Stateful Path 1307 Computation Element (PCE)", RFC 8051, January 2017. 1309 [RFC8253] Lopez, D., Dios, O., Wu, W., and D. Dhody, "PCEPS: Usage 1310 of TLS to Provide a Secure Transport for the Path 1311 Computation Element Communication Protocol (PCEP)", RFC 1312 8253, October 2017, . 1315 [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. 1316 Tantsura, "A YANG Data Model for Path Computation Element 1317 Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang 1318 (work in progress). 1320 [I-D.gandhi-pce-pm] Gandhi, R., Wen, B., Barth, C., and D. Dhody, 1321 "PCEP Extensions for MPLS-TE LSP Performance Measurements 1322 with Stateful PCE", draft-gandhi-pce-pm (work in 1323 progress). 1325 [IEEE.754.1985] Institute of Electrical and Electronics Engineers, 1326 "Standard for Binary Floating-Point Arithmetic", IEEE 1327 Standard 754, August 1985. 1329 Acknowledgments 1331 Authors would like to thank Robert Varga, Venugopal Reddy, Reeja 1332 Paul, Sandeep Boina, Avantika, JP Vasseur, Himanshu Shah and Adrian 1333 Farrel for their useful comments and suggestions. 1335 Contributors' Addresses 1337 He Zekun 1338 Tencent Holdings Ltd, 1339 Shenzhen P.R.China 1341 Email: kinghe@tencent.com 1343 Xian Zhang 1344 Huawei Technologies 1345 Research Area F3-1B, 1346 Huawei Industrial Base, 1347 Shenzhen, 518129 1348 China 1350 Phone: +86-755-28972645 1351 Email: zhang.xian@huawei.com 1353 Young Lee 1354 Huawei Technologies 1355 1700 Alma Drive, Suite 100 1356 Plano, TX 75075 1357 USA 1359 Phone: +1 972 509 5599 x2240 1360 Fax: +1 469 229 5397 1361 Email: leeyoung@huawei.com 1363 Authors' Addresses 1365 Dhruv Dhody 1366 Huawei Technologies 1367 Divyashree Techno Park, Whitefield 1368 Bangalore, Karnataka 560066 1369 India 1371 Email: dhruv.ietf@gmail.com 1373 Udayasree Palle 1374 Huawei Technologies 1375 Divyashree Techno Park, Whitefield 1376 Bangalore, Karnataka 560037 1377 India 1379 Email: udayasreereddy@gmail.com 1381 Ravi Singh 1382 Juniper Networks 1383 1194 N. Mathilda Ave. 1384 Sunnyvale, CA 94089 1385 USA 1387 Email: ravis@juniper.net 1389 Rakesh Gandhi 1390 Cisco Systems, Inc. 1392 Email: rgandhi@cisco.com 1394 Luyuan Fang 1395 Expedia, Inc. 1396 USA 1398 Email: luyuanf@gmail.com