idnits 2.17.1 draft-ietf-pce-stateful-pce-auto-bandwidth-03.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 (March 13, 2017) is 2601 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 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: September 14, 2017 R. Singh 6 Juniper Networks 7 R. Gandhi 8 Cisco Systems, Inc. 9 L. Fang 10 eBay 11 March 13, 2017 13 PCEP Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with 14 Stateful PCE 15 draft-ietf-pce-stateful-pce-auto-bandwidth-03 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 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 65 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 66 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Requirements for PCEP Extensions . . . . . . . . . . . . . . . 5 68 4. Architectural Overview . . . . . . . . . . . . . . . . . . . . 6 69 4.1. Auto-Bandwidth Overview . . . . . . . . . . . . . . . . . 6 70 4.2. Auto-bandwidth Theory of Operation . . . . . . . . . . . . 8 71 4.3. Scaling Considerations . . . . . . . . . . . . . . . . . . 9 72 5. Extensions to the PCEP . . . . . . . . . . . . . . . . . . . . 9 73 5.1. Capability Advertisement . . . . . . . . . . . . . . . . . 9 74 5.1.1 AUTO-BANDWIDTH-CAPABILITY TLV . . . . . . . . . . . . . 10 75 5.2. AUTO-BANDWIDTH-ATTRIBUTE TLV . . . . . . . . . . . . . . . 10 76 5.2.1. Sample-Interval sub-TLV . . . . . . . . . . . . . . . 12 77 5.2.2. Adjustment Interval . . . . . . . . . . . . . . . . . 12 78 5.2.2.1. Adjustment-Interval sub-TLV . . . . . . . . . . . 12 79 5.2.2.2. Down-Adjustment-Interval sub-TLV . . . . . . . . . 13 80 5.2.3. Adjustment Threshold . . . . . . . . . . . . . . . . . 13 81 5.2.3.1. Adjustment-Threshold sub-TLV . . . . . . . . . . . 13 82 5.2.3.2. Adjustment-Threshold-Percentage sub-TLV . . . . . 14 83 5.2.3.3. Down-Adjustment-Threshold sub-TLV . . . . . . . . 15 84 5.2.3.4. Down-Adjustment-Threshold-Percentage sub-TLV . . . 15 85 5.2.4. Minimum and Maximum Bandwidth Values . . . . . . . . . 16 86 5.2.4.1. Minimum-Bandwidth sub-TLV . . . . . . . . . . . . 16 87 5.2.4.2. Maximum-Bandwidth sub-TLV . . . . . . . . . . . . 16 88 5.2.5. Overflow and Underflow Conditions . . . . . . . . . . 17 89 5.2.5.1. Overflow-Threshold sub-TLV . . . . . . . . . . . . 17 90 5.2.5.2. Overflow-Threshold-Percentage sub-TLV . . . . . . 18 91 5.2.5.3. Underflow-Threshold sub-TLV . . . . . . . . . . . 18 92 5.2.5.4. Underflow-Threshold-Percentage sub-TLV . . . . . . 19 94 5.3. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 20 95 5.4. The PCInitiate Message . . . . . . . . . . . . . . . . . . 20 96 5.5. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 20 97 5.6. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 21 98 5.7. The PCNtf Message . . . . . . . . . . . . . . . . . . . . 21 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 100 7. Manageability Considerations . . . . . . . . . . . . . . . . . 22 101 7.1. Control of Function and Policy . . . . . . . . . . . . . . 22 102 7.2. Information and Data Models . . . . . . . . . . . . . . . 22 103 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 23 104 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 23 105 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 23 106 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 23 107 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 108 8.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 24 109 8.2. AUTO-BANDWIDTH-CAPABILITY TLV Flag Field . . . . . . . . . 24 110 8.3. AUTO-BANDWIDTH-ATTRIBUTE Sub-TLV . . . . . . . . . . . . . 24 111 8.4. Error Object . . . . . . . . . . . . . . . . . . . . . . . 25 112 8.5. Notification Object . . . . . . . . . . . . . . . . . . . 25 113 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 114 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 115 9.2. Informative References . . . . . . . . . . . . . . . . . . 26 116 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28 117 Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 28 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 120 1. Introduction 122 [RFC5440] describes the Path Computation Element Protocol (PCEP) as a 123 communication mechanism between a Path Computation Client (PCC) and a 124 Path Control Element (PCE), or between PCE and PCE, that enables 125 computation of Multi-Protocol Label Switching (MPLS) Traffic 126 Engineering Label Switched Paths (TE LSPs). 128 [I-D.ietf-pce-stateful-pce] specifies extensions to PCEP to enable 129 stateful control of MPLS TE LSPs. It describes two mode of 130 operations - Passive stateful PCE and Active stateful PCE. Further 131 [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and 132 teardown of PCE-Initiated LSPs for the stateful PCE model. In this 133 document, the focus is on Active stateful PCE where the LSPs are 134 controlled by the PCE. 136 Over time, based on the varying traffic pattern, an LSP established 137 with certain bandwidth may require to adjust the bandwidth reserved 138 in the network automatically. The head-end Label Switch Router (LSR) 139 needs to monitor the actual bandwidth demand of the LSP and adjust 140 the LSP bandwidth reservation periodically. This feature is commonly 141 referred to as Auto-Bandwidth. 143 Enabling Auto-Bandwidth feature on an LSP results in the head-end LSR 144 automatically adjusting the LSP bandwidth reservation based on the 145 traffic flowing through the LSP. The initial LSP bandwidth can be 146 set to an arbitrary value (including zero), in practice, it can be 147 operator expected value based on design and planning. Once the LSP 148 is set-up, the head-end monitors the traffic flow on the LSP and 149 adjusts the bandwidth every adjustment-interval. The bandwidth 150 adjustment uses the make-before-break signaling method so that there 151 is no disruption to the traffic flow. The Auto-Bandwidth feature is 152 described in detail in Section 4.1 of this document. 154 The PCC (head-end of the LSP) collects the traffic rate samples 155 flowing through the LSP and calculates the new adjusted bandwidth. 156 The PCC reports the calculated bandwidth to be adjusted to the PCE. 157 This is similar to a passive stateful PCE model, while the passive 158 stateful PCE uses path request/reply mechanism, the active stateful 159 PCE uses report/update mechanism to adjust the LSP bandwidth. In 160 case of PCE-Initiated LSP, the PCC is requested during the LSP 161 initiation to monitor and calculate the new adjusted bandwidth. 162 [RFC8051] describes the use-case for Auto-Bandwidth adjustment for 163 passive and active stateful PCE. 165 The document [I-D.gandhi-pce-pm] describes the PCEP extensions for 166 reporting the performance measurements to the PCE, and includes the 167 real-time bandwidth usage information of a TE LSP. Those extensions 168 can be used to implement the auto-bandwidth feature on a stateful 169 PCE, i.e. can be used to calculate the new bandwidth to be adjusted 170 on the stateful PCE. 172 This document defines the extensions needed to support Auto-Bandwidth 173 features on the LSPs in a active stateful PCE model using PCEP where 174 the bandwidth to be adjusted is calculated on the PCC (the head-end 175 of the LSP). 177 2. Conventions Used in This Document 179 2.1. Requirements Language 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in [RFC2119]. 185 2.2. Terminology 186 The following terminology is used in this document. 188 Active Stateful PCE: PCE that uses tunnel state information learned 189 from PCCs to optimize path computations. Additionally, it 190 actively updates tunnel parameters in those PCCs that delegated 191 control over their tunnels to the PCE. 193 Delegation: An operation to grant a PCE temporary rights to modify a 194 subset of tunnel parameters on one or more PCC's tunnels. Tunnels 195 are delegated from a PCC to a PCE. 197 PCC: Path Computation Client. Any client application requesting a 198 path computation to be performed by a Path Computation Element. 200 PCE: Path Computation Element. An entity (component, application, 201 or network node) that is capable of computing a network path or 202 route based on a network graph and applying computational 203 constraints. 205 TE LSP: Traffic Engineering Label Switched Path. 207 Note the Auto-Bandwidth feature specific terms are defined in Section 208 4.1. 210 3. Requirements for PCEP Extensions 212 The PCEP speaker supporting this document MUST have a mechanism to 213 advertise the automatic bandwidth adjustment capability. 215 Additional auto-bandwidth PCEP extensions required are summarized in 216 the following table. 218 +---------------------------------+---------------------------------+ 219 | PCC Initiated | PCE Initiated | 220 +---------------------------------+---------------------------------+ 221 | | | 222 | PCC monitors the traffic | At the time of initiation, | 223 | and reports the calculated | PCE request PCC to monitor | 224 | bandwidth to be adjusted | the traffic and report the | 225 | to the PCE. | calculated bandwidth to be | 226 | | adjusted to the PCE. | 227 | | | 228 | Extension is needed for PCC | Extension is needed for PCE | 229 | to pass on the adjustment | to pass on the adjustment | 230 | parameters at the time of | parameters at the time of | 231 | Delegation. | Initiation. | 232 | | | 233 +---------------------------------+---------------------------------+ 235 Table 1: Auto-Bandwidth PCEP extensions 237 Further Auto-Bandwidth deployment considerations are summarized 238 below: 240 o It is required to identify and inform the PCEP peer, the LSP that 241 are enabled with Auto-Bandwidth feature. Not all LSPs in some 242 deployments would like their bandwidth to be dependent on the 243 real-time bandwidth usage but be constant as set by the operator. 245 o Further for the LSP with Auto-Bandwidth feature enabled, an 246 operator should be able to specify the adjustment parameters (i.e. 247 configuration knobs) to control this feature (e.g. minimum/ 248 maximum bandwidth range) and PCEP peer should be informed. 250 4. Architectural Overview 252 4.1. Auto-Bandwidth Overview 254 Auto-Bandwidth feature allows automatic and dynamic adjustment of the 255 reserved bandwidth of an LSP over time, i.e. without network operator 256 intervention. The new bandwidth reservation is determined by 257 sampling the actual traffic flowing through the LSP. If the traffic 258 flowing through the LSP is lower than the configured or current 259 bandwidth of the LSP, the extra bandwidth is being reserved 260 needlessly and being wasted. Conversely, if the actual traffic 261 flowing through the LSP is higher than the configured or current 262 bandwidth of the LSP, it can potentially cause congestion or packet 263 loss in the network. With Auto-Bandwidth feature, the LSP bandwidth 264 can be set to some arbitrary value (including zero) during initial 265 setup time, and it will be periodically adjusted over time based on 266 the actual bandwidth demand. 268 Note the following definitions of the Auto-Bandwidth terms: 270 Maximum Average Bandwidth (MaxAvgBw): The maximum average bandwidth 271 represents the current traffic bandwidth demand during a time 272 interval. This is the maximum value of the averaged traffic 273 bandwidth rate in a given adjustment-interval. 275 Adjusted Bandwidth: This is the Auto-Bandwidth computed bandwidth 276 that needs to be adjusted for the LSP. 278 Sample-Interval: The periodic time interval at which the traffic 279 rate is collected as a sample. 281 Bandwidth-Sample: The bandwidth sample collected at every sample 282 interval to measure the traffic rate. 284 Up-Adjustment-Interval: The periodic time interval at which the 285 bandwidth adjustment should be made using the MaxAvgBw, when 286 MaxAvgBw is greater than the current bandwidth reservation. 288 Down-Adjustment-Interval: The periodic time interval at which the 289 bandwidth adjustment should be made using the MaxAvgBw, when 290 MaxAvgBw is lesser than the current bandwidth reservation. 292 Maximum-Bandwidth: The maximum bandwidth that can be reserved for 293 the LSP. 295 Minimum-Bandwidth: The minimum bandwidth that can be reserved for 296 the LSP. 298 Up-Adjustment-Threshold: This value is used to decide when the 299 bandwidth should be adjusted. If the percentage or absolute 300 difference between the current MaxAvgBw and the current bandwidth 301 reservation is greater than or equal to the threshold value, the 302 LSP bandwidth is adjusted (upsized) to the current bandwidth 303 demand (Adjusted Bandwidth) at the up-adjustment-interval expiry. 305 Down-Adjustment-Threshold: This value is used to decide when the 306 bandwidth should be adjusted. If the percentage or absolute 307 difference between the current bandwidth reservation and the 308 current MaxAvgBw is greater than or equal to the threshold value, 309 the LSP bandwidth is adjusted (downsized) to the current bandwidth 310 demand (Adjusted Bandwidth) at the down-adjustment-interval 311 expiry. 313 Overflow-Count: This value is used to decide when the bandwidth 314 should be adjusted when there is a sudden increase in traffic 315 demand. This value indicates how many times consecutively, the 316 percentage or absolute difference between the current MaxAvgBw and 317 the current bandwidth reservation is greater than or equal to the 318 Overflow-Threshold value. 320 Overflow-Threshold: This value is used to decide when the bandwidth 321 should be adjusted when there is a sudden increase in traffic 322 demand. If the percentage or absolute difference between the 323 current MaxAvgBw and the current bandwidth reservation is greater 324 than or equal to the threshold value, the overflow-condition is 325 set to be met. The LSP bandwidth is adjusted to the current 326 bandwidth demand bypassing the adjustment-interval if the 327 overflow-condition is met consecutively for the Overflow-Count. 329 Underflow-Count: This value is used to decide when the bandwidth 330 should be adjusted when there is a sudden decrease in traffic 331 demand. This value indicates how many times consecutively, the 332 percentage or absolute difference between the current MaxAvgBw and 333 the current bandwidth reservation is greater than or equal to the 334 Underflow-Threshold value. 336 Underflow-Threshold: This value is used to decide when the bandwidth 337 should be adjusted when there is a sudden decrease in traffic 338 demand. If the percentage or absolute difference between the 339 current MaxAvgBw and the current bandwidth reservation is greater 340 than or equal to the threshold value, the underflow-condition is 341 set to be met. The LSP bandwidth is adjusted to the current 342 bandwidth demand bypassing the adjustment-interval if the 343 underflow-condition is met consecutively for the Underflow-Count. 345 4.2. Auto-bandwidth Theory of Operation 347 The traffic rate is periodically sampled at each sample-interval 348 (which can be configured by the user and the default value as 5 349 minutes) by the PCC which is the head-end node of the LSP. The 350 sampled traffic rates are accumulated over the adjustment-interval 351 period (which can be configured by the user and the default value as 352 24 hours). The PCC (the head-end of the LSP) is in-charge of 353 calculating the bandwidth to be adjusted, will adjust the bandwidth 354 of the LSP to the highest sampled traffic rate (MaxAvgBw) amongst the 355 set of bandwidth samples collected over the adjustment-interval 356 period (Up or Down). 358 Note that the highest sampled traffic rate could be higher or lower 359 than the current LSP bandwidth. Only if the difference between the 360 current bandwidth demand (MaxAvgBw) and the current bandwidth 361 reservation is greater than or equal to the Up-Adjustment-Threshold 362 (percentage or absolute value), the LSP bandwidth is adjusted 363 (upsized) to the current bandwidth demand (MaxAvgBw). Similarly if 364 the difference between the current bandwidth reservation and the 365 current bandwidth demand (MaxAvgBw) is greater than or equal to the 366 Down-Adjustment-Threshold (percentage or absolute value), the LSP 367 bandwidth is adjusted (downsized) to the current bandwidth demand 368 (MaxAvgBw). Some LSPs are less eventful while other LSPs may 369 encounter a lot of changes in the traffic pattern. The intervals for 370 adjustment is configured based on the traffic pattern of the LSP. 372 In order to avoid frequent re-signaling, an operator may set a longer 373 adjustment-interval value (Up and/or Down). However, longer 374 adjustment-interval can result in an undesirable effect of masking 375 sudden changes in traffic demands of an LSP. To avoid this, the 376 Auto-Bandwidth feature may pre-maturely expire the adjustment- 377 interval and adjust the LSP bandwidth to accommodate the sudden 378 bursts of increase in traffic demand as an overflow condition or 379 decrease in traffic demand as an underflow condition. 381 All thresholds in this document could be represented in both absolute 382 value and percentage, and could be used together. This is done to 383 accommodate case where the LSP bandwidth reservation may become very 384 large or very small over time, the two representations help the 385 operator to provide conditions when the bandwidth usage is too large 386 or too small. 388 4.3. Scaling Considerations 390 It should be noted that any bandwidth change requires re-signaling of 391 an LSP in a make-before-break fashion, which can further trigger 392 preemption of lower priority LSPs in the network. When deployed 393 under scale, this can lead to a signaling churn in the network. The 394 Auto-bandwidth application algorithm is thus advised to take this 395 into consideration before adjusting the LSP bandwidth. Operators are 396 advised to set the values of various auto-bandwidth adjustment 397 parameters appropriate for the deployed LSP scale. 399 If a PCE gets overwhelmed, it can notify the PCC to temporarily 400 suspend the reporting of the new LSP bandwidth to be adjusted (see 401 Section 5.7). Similarly if a PCC gets overwhelmed due to signaling 402 churn, it can notify the PCE to temporarily suspend the new LSP setup 403 requests. 405 5. Extensions to the PCEP 407 5.1. Capability Advertisement 409 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 410 advertise their support of Automatic Bandwidth Adjustment feature. A 411 PCEP Speaker includes the "Auto-Bandwidth Capability" TLV, in the 412 OPEN Object to advertise its support for PCEP Auto-Bandwidth 413 extensions. The presence of the "Auto-Bandwidth Capability" TLV in 414 the OPEN Object indicates that the Automatic Bandwidth Adjustment is 415 supported as described in this document. 417 The PCEP protocol extensions for Auto-Bandwidth adjustments MUST NOT 418 be used if one or both PCEP Speakers have not included the "Auto- 419 Bandwidth Capability" TLV in their respective OPEN message. If the 420 PCEP speaker that supports the extensions of this draft but did not 421 advertise this capability, then upon receipt of AUTO-BANDWIDTH- 422 ATTRIBUTE TLV in LSPA object, it SHOULD generate a PCErr with error- 423 type 19 (Invalid Operation), error-value TBD4 (Auto-Bandwidth 424 capability was not advertised) and it will terminate the PCEP 425 session. 427 5.1.1 AUTO-BANDWIDTH-CAPABILITY TLV 429 The AUTO-BANDWIDTH-CAPABILITY TLV is an optional TLV for use in the 430 OPEN Object for Automatic Bandwidth Adjustment via PCEP capability 431 advertisement. Its format is shown in the following figure: 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Type=TBD2 | Length=4 | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Flags | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 AUTO-BANDWIDTH-CAPABILITY TLV format 443 The type of the TLV is (TBD2) and it has a fixed length of 4 octets. 445 The value comprises a single field - Flags (32 bits). Currently no 446 flags are defined for this TLV. 448 Unassigned bits are considered reserved. They MUST be set to 0 on 449 transmission and MUST be ignored on receipt. 451 Advertisement of the Auto-Bandwidth capability TLV implies support of 452 auto-bandwidth adjustment, as well as the objects, TLVs and 453 procedures defined in this document. 455 5.2. AUTO-BANDWIDTH-ATTRIBUTE TLV 457 The AUTO-BANDWIDTH-ATTRIBUTE TLV provides the 'configurable knobs' of 458 the feature and it can be included as an optional TLV in the LSPA 459 Object (as described in [RFC5440]). 461 For PCE-Initiated LSP ([I-D.ietf-pce-pce-initiated-lsp]), this TLV is 462 included in the LSPA Object with the PCInitiate message. For the 463 PCC-Initiated delegated LSPs, this TLV is carried in the PCRpt 464 message in LSPA Object. This TLV is also included in the LSPA object 465 with the PCUpd message to direct the PCC (the LSP head-end) to use 466 different parameters with the LSP. 468 The TLV is encoded in all PCEP messages for the LSP while the auto 469 bandwidth adjustment feature is enabled, the absence of the TLV 470 indicate the PCEP speaker wish to disable the feature. 472 The format of the AUTO-BANDWIDTH-ATTRIBUTE TLV is shown in the 473 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=TBD1 | Length | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | | 481 // sub-TLVs // 482 | | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 AUTO-BANDWIDTH-ATTRIBUTE TLV format 487 Type: TBD1 489 Length: The Length field defines the length of the value portion 490 in bytes as per [RFC5440]. 492 Value: This comprises one or more sub-TLVs. 494 Following sub-TLVs are defined in this document: 496 Type Len Name 497 ------------------------------------------------------------------- 498 1 4 Sample-Interval sub-TLV 499 2 4 Adjustment-Interval sub-TLV 500 3 4 Down-Adjustment-Interval sub-TLV 501 4 4 Adjustment-Threshold sub-TLV 502 5 4 Adjustment-Threshold-Percentage sub-TLV 503 6 4 Down-Adjustment-Threshold sub-TLV 504 7 4 Down-Adjustment-Threshold-Percentage sub-TLV 505 8 4 Minimum-Bandwidth sub-TLV 506 9 4 Maximum-Bandwidth sub-TLV 507 10 8 Overflow-Threshold sub-TLV 508 11 4 Overflow-Threshold-Percentage sub-TLV 509 12 8 Underflow-Threshold sub-TLV 510 13 4 Underflow-Threshold-Percentage sub-TLV 512 Future specification can define additional sub-TLVs. 514 The presence of AUTO-BANDWIDTH-ATTRIBUTE TLV in LSPA Object means 515 that the automatic bandwidth adjustment feature is enabled. All 516 sub-TLVs are optional and any unrecognized sub-TLV MUST be silently 517 ignored. If a sub-TLV of same type appears more than once, only the 518 first occurrence is processed and all others MUST be ignored. 520 The AUTO-BANDWIDTH-ATTRIBUTE TLV can also be carried in PCUpd message 521 in LSPA Object in order to make updates to auto-bandwidth attributes 522 such as Adjustment-Interval. 524 If sub-TLVs are not present, the default values based on the local 525 policy are assumed. 527 The sub-TLVs are encoded to inform the PCEP peer the various sampling 528 and adjustment parameters. 530 The following sub-sections describe the sub-TLVs which are currently 531 defined to be carried within the AUTO-BANDWIDTH-ATTRIBUTE TLV. 533 5.2.1. Sample-Interval sub-TLV 535 The Sample-Interval sub-TLV specifies a time interval in seconds at 536 which traffic samples are collected at the PCC. 538 The Type is 1, Length is 4, and the value comprises of 4-octet time 539 interval, the valid range is from 1 to 604800, in seconds. The 540 default value is 300 seconds. 542 0 1 2 3 543 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 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Type=1 | Length=4 | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Sample-Interval | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 Sample-Interval sub-TLV format 552 5.2.2. Adjustment Interval 554 The sub-TLVs in this section are encoded to inform the PCEP peer the 555 adjustment interval parameters. An implementation MAY want to set 556 different adjustment interval, as the bandwidth usage trend is moving 557 upwards or downwards. When the TLV is not included default value are 558 used. 560 5.2.2.1. Adjustment-Interval sub-TLV 562 The Adjustment-Interval sub-TLV specifies a time interval in seconds 563 at which bandwidth adjustment should be made when MaxAvgBw is greater 564 than or less than the current bandwidth reservation. 566 The Type is 2, Length is 4, and the value comprises of 4-octet time 567 interval, the valid range is from 1 to 604800, in seconds. The 568 default value is 300 seconds. 570 0 1 2 3 571 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 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Type=2 | Length=4 | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Adjustment-Interval | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 Adjustment-Interval sub-TLV format 580 5.2.2.2. Down-Adjustment-Interval sub-TLV 582 The Down-Adjustment-Interval sub-TLV specifies a time interval in 583 seconds at which bandwidth adjustment should be made when MaxAvgBw is 584 less than the current bandwidth reservation. This parameter 585 overwrites the Adjustment-Interval. 587 The Type is 3, Length is 4, and the value comprises of 4-octet time 588 interval, the valid range is from 1 to 604800, in seconds. The 589 default value is 300 seconds. 591 0 1 2 3 592 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 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Type=3 | Length=4 | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Down-Adjustment-Interval | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 Down-Adjustment-Interval sub-TLV format 601 5.2.3. Adjustment Threshold 603 The sub-TLVs in this section are encoded to inform the PCEP peer the 604 adjustment threshold parameters. An implementation MAY include both 605 sub-TLVs for the absolute value and the percentage, in which case the 606 bandwidth is adjusted when either of the adjustment threshold 607 conditions are met. 609 5.2.3.1. Adjustment-Threshold sub-TLV 611 The Adjustment-Threshold sub-TLV is used to decide when the LSP 612 bandwidth should be adjusted when MaxAvgBw is greater than or less 613 than the current bandwidth reservation. 615 0 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Type=4 | Length=4 | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Adjustment-Threshold | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 Adjustment-Threshold sub-TLV format 625 The Type is 4, Length is 4, and the value comprises of - 627 o Adjustment Threshold: The absolute Adjustment-Threshold bandwidth 628 value, encoded in IEEE floating point format (see 629 [IEEE.754.1985]), expressed in bytes per second. Refer to Section 630 3.1.2 of [RFC3471] for a table of commonly used values. 632 If the difference between the current MaxAvgBw and the current 633 bandwidth reservation is greater than or less than or equal to the 634 threshold value, the LSP bandwidth is adjusted to the current 635 bandwidth demand (MaxAvgBw). 637 5.2.3.2. Adjustment-Threshold-Percentage sub-TLV 639 The Adjustment-Threshold-Percentage sub-TLV is used to decide when 640 the LSP bandwidth should be adjusted when MaxAvgBw is greater than or 641 less than the current bandwidth reservation. 643 0 1 2 3 644 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 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Type=5 | Length=4 | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Reserved | Percentage | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 Adjustment-Threshold-Percentage sub-TLV format 653 The Type is 5, Length is 4, and the value comprises of - 655 o Reserved: SHOULD be set to zero on transmission and MUST be 656 ignored on receipt. 658 o Percentage: The Adjustment-Threshold value, encoded in percentage 659 (an integer from 0 to 100). If the percentage difference between 660 the current MaxAvgBw and the current bandwidth reservation is 661 greater than or less than or equal to the threshold percentage, 662 the LSP bandwidth is adjusted to the current bandwidth demand 663 (MaxAvgBw). 665 5.2.3.3. Down-Adjustment-Threshold sub-TLV 667 The Down-Adjustment-Threshold sub-TLV is used to decide when the 668 LSP bandwidth should be adjusted when MaxAvgBw is lesser than the 669 current bandwidth reservation. This parameter overwrites the 670 Adjustment-Threshold. 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=6 | Length=4 | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Down-Adjustment-Threshold | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 Down-Adjustment-Threshold sub-TLV format 682 The Type is 6, Length is 4, and the value comprises of - 684 o Down-Adjustment Threshold: The absolute Down-Adjustment-Threshold 685 bandwidth value, encoded in IEEE floating point format (see 686 [IEEE.754.1985]), expressed in bytes per second. Refer to Section 687 3.1.2 of [RFC3471] for a table of commonly used values. 689 If the difference between current bandwidth reservation and the 690 current MaxAvgBw is greater than or equal to the threshold value, the 691 LSP bandwidth is adjusted to the current bandwidth demand (MaxAvgBw). 693 5.2.3.4. Down-Adjustment-Threshold-Percentage sub-TLV 695 The Down-Adjustment-Threshold-Percentage sub-TLV is used to decide 696 when the LSP bandwidth should be adjusted when MaxAvgBw is lesser 697 than the current bandwidth reservation. This parameter overwrites 698 the Adjustment-Threshold-Percentage. 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Type=7 | Length=4 | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Reserved | Percentage | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 Down-Adjustment-Threshold-Percentage sub-TLV format 709 The Type is 7, Length is 4, and the value comprises of - 711 o Reserved: SHOULD be set to zero on transmission and MUST be 712 ignored on receipt. 714 o Percentage: The Down-Adjustment-Threshold value, encoded in 715 percentage (an integer from 0 to 100). If the percentage 716 difference between the current bandwidth reservation and the 717 current MaxAvgBw is greater than or equal to the threshold 718 percentage, the LSP bandwidth is adjusted to the current bandwidth 719 demand (MaxAvgBw). 721 5.2.4. Minimum and Maximum Bandwidth Values 723 5.2.4.1. Minimum-Bandwidth sub-TLV 725 The Minimum-Bandwidth sub-TLV specify the minimum bandwidth allowed 726 for the LSP, and is expressed in bytes per second. The LSP bandwidth 727 cannot be adjusted below the minimum bandwidth value. 729 The Type is 8, Length is 4, and the value comprises of 4-octet 730 bandwidth value encoded in IEEE floating point format (see 731 [IEEE.754.1985]), expressed in bytes per second. Refer to Section 732 3.1.2 of [RFC3471] for a table of commonly used values. 734 0 1 2 3 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Type=8 | Length=4 | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Minimum-Bandwidth | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 Minimum-Bandwidth sub-TLV format 744 5.2.4.2. Maximum-Bandwidth sub-TLV 746 The Maximum-Bandwidth sub-TLV specify the maximum bandwidth allowed 747 for the LSP, and is expressed in bytes per second. The LSP bandwidth 748 cannot be adjusted above the maximum bandwidth value. 750 The Type is 9, Length is 4, and the value comprises of 4-octet 751 bandwidth value encoded in IEEE floating point format (see 752 [IEEE.754.1985]), expressed in bytes per second. Refer to Section 753 3.1.2 of [RFC3471] for a table of commonly used values. 755 0 1 2 3 756 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 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Type=9 | Length=4 | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Maximum-Bandwidth | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 Maximum-Bandwidth sub-TLV format 765 5.2.5. Overflow and Underflow Conditions 767 The sub-TLVs in this section are encoded to inform the PCEP peer the 768 overflow and underflow threshold parameters. An implementation MAY 769 include sub-TLVs for the absolute value and the percentage for the 770 threshold, in which case the bandwidth is immediately adjusted when 771 either of the adjustment threshold conditions are met consecutively 772 for the given count. 774 5.2.5.1. Overflow-Threshold sub-TLV 776 The Overflow-Threshold sub-TLV is used to decide if the bandwidth 777 should be adjusted immediately. 779 0 1 2 3 780 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 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Type=10 | Length=8 | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | Reserved | Count | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Overflow-Threshold | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 Overflow-Threshold sub-TLV format 791 The Type is 10, Length is 8, and the value comprises of - 793 o Reserved: SHOULD be set to zero on transmission and MUST be 794 ignored on receipt. 796 o Count: The Overflow-Count value, encoded in integer. The value 0 797 is considered to be invalid. The number of consecutive samples 798 for which the overflow condition MUST be met for the LSP bandwidth 799 to be immediately adjusted to the current bandwidth demand, 800 bypassing the adjustment-interval. 802 o Overflow-Threshold: The absolute Overflow-Threshold bandwidth 803 value, encoded in IEEE floating point format (see 804 [IEEE.754.1985]), expressed in bytes per second. Refer to Section 805 3.1.2 of [RFC3471] for a table of commonly used values. If the 806 increase of the current MaxAvgBw from the current bandwidth 807 reservation is greater than or equal to the threshold value, the 808 overflow condition is met. 810 5.2.5.2. Overflow-Threshold-Percentage sub-TLV 812 The Overflow-Threshold-Percentage sub-TLV is used to decide if the 813 bandwidth should be adjusted immediately. 815 0 1 2 3 816 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 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Type=11 | Length=4 | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | Percentage | Reserved | Count | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 Overflow-Threshold-Percentage sub-TLV format 825 The Type is 11, Length is 4, and the value comprises of - 827 o Percentage: The Overflow-Threshold value, encoded in percentage 828 (an integer from 0 to 100). If the percentage increase of the 829 current MaxAvgBw from the current bandwidth reservation is greater 830 than or equal to the threshold percentage, the overflow condition 831 is met. 833 o Reserved: SHOULD be set to zero on transmission and MUST be 834 ignored on receipt. 836 o Count: The Overflow-Count value, encoded in integer. The value 0 837 is considered to be invalid. The number of consecutive samples 838 for which the overflow condition MUST be met for the LSP bandwidth 839 to be immediately adjusted to the current bandwidth demand, 840 bypassing the adjustment-interval. 842 5.2.5.3. Underflow-Threshold sub-TLV 844 The Underflow-Threshold sub-TLV is used to decide if the bandwidth 845 should be adjusted immediately. 847 0 1 2 3 848 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 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Type=12 | Length=8 | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Reserved | Count | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Underflow-Threshold | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 Underflow-Threshold sub-TLV format 859 The Type is 12, Length is 8, and the value comprises of - 861 o Reserved: SHOULD be set to zero on transmission and MUST be 862 ignored on receipt. 864 o Count: The Underflow-Count value, encoded in integer. The value 0 865 is considered to be invalid. The number of consecutive samples 866 for which the underflow condition MUST be met for the LSP 867 bandwidth to be immediately adjusted to the current bandwidth 868 demand, bypassing the adjustment-interval. 870 o Underflow-Threshold: The absolute Underflow-Threshold bandwidth 871 value, encoded in IEEE floating point format (see 872 [IEEE.754.1985]), expressed in bytes per second. Refer to Section 873 3.1.2 of [RFC3471] for a table of commonly used values. If the 874 decrease of the current MaxAvgBw from the current bandwidth 875 reservation is greater than or equal to the threshold value, the 876 underflow condition is met. 878 5.2.5.4. Underflow-Threshold-Percentage sub-TLV 880 The Underflow-Threshold-Percentage sub-TLV is used to decide if the 881 bandwidth should be adjusted immediately. 883 0 1 2 3 884 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 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | Type=13 | Length=4 | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Percentage | Reserved | Count | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 Underflow-Threshold-Percentage sub-TLV format 893 The Type is 13, Length is 4, and the value comprises of - 895 o Percentage: The Underflow-Threshold value, encoded in percentage 896 (an integer from 0 to 100). If the percentage decrease of the 897 current MaxAvgBw from the current bandwidth reservation is greater 898 than or equal to the threshold percentage, the underflow condition 899 is met. 901 o Reserved: SHOULD be set to zero on transmission and MUST be 902 ignored on receipt. 904 o Count: The Underflow-Count value, encoded in integer. The value 0 905 is considered to be invalid. The number of consecutive samples 906 for which the underflow condition MUST be met for the LSP 907 bandwidth to be immediately adjusted to the current bandwidth 908 demand, bypassing the adjustment-interval. 910 5.3. BANDWIDTH Object 912 As per [RFC5440], the BANDWIDTH object (Object-Class value 5) is 913 defined with two Object-Type values as following: 915 o Requested Bandwidth: BANDWIDTH Object-Type value is 1. 917 o Re-optimization Bandwidth: Bandwidth of an existing TE LSP for 918 which a re-optimization is requested. BANDWIDTH Object-Type value 919 is 2. 921 PCC reports the calculated bandwidth to be adjusted (MaxAvgBw) to the 922 PCE using the existing 'Requested Bandwidth' with BANDWIDTH Object- 923 Type as 1. 925 5.4. The PCInitiate Message 927 A PCInitiate message is a PCEP message sent by a PCE to a PCC to 928 trigger LSP instantiation or deletion [I.D.ietf-pce-pce-initiated- 929 lsp]. 931 For the PCE-Initiated LSP with Auto-Bandwidth feature enabled, AUTO- 932 BANDWIDTH-ATTRIBUTE TLV MUST be included in the LSPA object with the 933 PCInitiate message. 935 The definition of the PCInitiate message (see 936 [I-D.ietf-pce-stateful-pce]) is unchanged by this document. 938 5.5. The PCUpd Message 940 A PCUpd message is a PCEP message sent by a PCE to a PCC to update 941 the LSP parameters [I-D.ietf-pce-stateful-pce]. 943 For PCE-Initiated LSPs with Auto-Bandwidth feature enabled, AUTO- 944 BANDWIDTH-ATTRIBUTE TLV MUST be included in the LSPA object with the 945 PCUpd message. The PCE can send this TLV to direct the PCC to change 946 the auto bandwidth parameters. 948 The definition of the PCUpd message (see [I-D.ietf-pce-stateful-pce]) 949 is unchanged by this document. 951 5.6. The PCRpt Message 953 The PCRpt message ([I-D.ietf-pce-stateful-pce]) is a PCEP message 954 sent by a PCC to a PCE to report the status of one or more LSPs. 956 For PCE-Initiated LSPs [I.D.ietf-pce-pce-initiated-lsp], the PCC 957 creates the LSP using the attributes communicated by the PCE, and 958 using the local values for the unspecified parameters. After the 959 successful instantiation of the LSP, PCC automatically delegates the 960 LSP to the PCE and generates a PCRpt message to provide the status 961 report for the LSP. 963 For both PCE-Initiated and PCC-Initiated LSPs, when the LSP is 964 delegated to a PCE for the very first time, the BANDWIDTH object of 965 type 1 is used to specify the requested bandwidth in the PCRpt 966 message. After the successful delegation, to specify the LSP 967 bandwidth to be adjusted, the BANDWIDTH object of type 1 is included 968 in the PCRpt message. 970 For PCC-Initiated LSPs with Auto-Bandwidth feature enabled, AUTO- 971 BANDWIDTH-ATTRIBUTE TLV MUST be included in the LSPA object of the 972 PCRpt message. 974 The definition of the PCRpt message (see [I-D.ietf-pce-stateful-pce]) 975 is unchanged by this document. 977 5.7. The PCNtf Message 979 As per [RFC5440], the PCEP Notification message (PCNtf) can be sent 980 by a PCEP speaker to notify its peer of a specific event. 982 As described in Section 4.3 of this document, a PCEP speaker (PCE or 983 PCC) SHOULD notify its PCEP peer (PCC or PCE) when it is in 984 overwhelmed state for the auto-bandwidth feature. Upon receipt of 985 such notification, the peer SHOULD NOT send any PCEP messages related 986 to auto-bandwidth adjustment. If a PCEP message related to auto- 987 bandwidth is received during in overwhelmed state, it MUST be 988 silently ignored. 990 When a PCEP speaker is overwhelmed, it SHOULD notify its peer by 991 sending a PCNtf message with Notification Type = TBD3 (Auto-bandwidth 992 Overwhelm State) and Notification Value = 1 (Entering auto-bandwidth 993 overwhelm state). Optionally, OVERLOADED-DURATION TLV [RFC5440] MAY 994 be included that specifies the time period during which no further 995 PCEP messages related to auto-bandwidth adjustment should be sent. 996 When the PCEP speaker is no longer in the overwhelm state and is 997 available to process the auto-bandwidth adjustment, it SHOULD notify 998 its peer by sending a PCNtf message with Notification Type = TBD3 999 (Auto-bandwidth Overwhelm State) and Notification Value = 2 (Clearing 1000 auto-bandwidth overwhelm state). 1002 When Auto-Bandwidth feature is deployed, a PCE can send this 1003 notification to PCC when a PCC is reporting frequent auto-bandwidth 1004 adjustments. If a PCC is overwhelmed with re-signaling, it can also 1005 notify the PCE to not adjust the LSP bandwidth while in overwhelm 1006 state. 1008 6. Security Considerations 1010 This document defines AUTO-BANDWIDTH-CAPABILITY TLV and 1011 AUTO-BANDWIDTH-ATTRIBUTE TLV which do not add any new security 1012 concerns beyond those discussed in [RFC5440] and 1013 [I-D.ietf-pce-stateful-pce] in itself. Some deployments may find the 1014 auto-bandwidth information as extra sensitive as it could be used to 1015 influence LSP path computation and LSP setup with adverse effect. 1016 Additionally, snooping of PCEP messages with such data or using PCEP 1017 messages for network reconnaissance, may give an attacker sensitive 1018 information about the operations of the network. Thus, such 1019 deployment should employ suitable PCEP security mechanisms like TCP 1020 Authentication Option (TCP-AO) [RFC5925] or [I-D.ietf-pce-pceps]. 1022 7. Manageability Considerations 1024 7.1. Control of Function and Policy 1026 The Auto-Bandwidth feature SHOULD be controlled per tunnel (at 1027 ingress (PCC) or PCE) and the values for auto-bandwidth parameters 1028 e.g. sample-interval, adjustment-interval (up/down), 1029 minimum-bandwidth, maximum-bandwidth, adjustment-threshold (up/down) 1030 SHOULD be configurable by an operator. 1032 7.2. Information and Data Models 1034 A Management Information Base (MIB) module for modeling PCEP is 1035 described in [RFC7420]. However, one may prefer the mechanism for 1036 configuration using YANG data model [I-D.ietf-pce-pcep-yang]. These 1037 SHOULD be enhanced to provide controls and indicators for support of 1038 auto-bandwidth feature. Support for various configuration knobs as 1039 well as counters of messages sent/received containing the TLVs 1040 (defined in this document) SHOULD be added. 1042 7.3. Liveness Detection and Monitoring 1044 Mechanisms defined in this document do not imply any new liveness 1045 detection and monitoring requirements in addition to those already 1046 listed in [RFC5440]. 1048 7.4. Verify Correct Operations 1050 Mechanisms defined in this document do not imply any new operation 1051 verification requirements in addition to those already listed in 1052 [RFC5440]. 1054 7.5. Requirements On Other Protocols 1056 Mechanisms defined in this document do not add any new requirements 1057 on other protocols. 1059 7.6. Impact On Network Operations 1061 In order to avoid any unacceptable impact on network operations, an 1062 implementation SHOULD allow a limit to be placed on the number of 1063 LSPs that can be enabled with auto-bandwidth feature. An 1064 implementation MAY allow a limit to be placed on the rate of auto- 1065 bandwidth messages sent by a PCEP speaker and received by a peer. An 1066 implementation MAY also allow sending a notification when a PCEP 1067 speaker is overwhelmed or the rate of messages reach a threshold. 1069 8. IANA Considerations 1071 8.1. PCEP TLV Type Indicators 1073 This document defines the following new PCEP TLVs; IANA is requested 1074 to make the following allocations from this registry. 1075 . 1078 Value Name Reference 1079 -------------------------------------------------------------- 1080 TBD2 AUTO-BANDWIDTH-CAPABILITY [This I.D.] 1081 TBD1 AUTO-BANDWIDTH-ATTRIBUTE [This I.D.] 1083 8.2. AUTO-BANDWIDTH-CAPABILITY TLV Flag Field 1085 IANA is requested to create a registry to manage the Flag field of 1086 the AUTO-BANDWIDTH-CAPABILITY TLV. 1088 New bit numbers are allocated only by an IETF Review action 1089 [RFC5226]. Each bit should be tracked with the following qualities: 1091 o Bit number (counting from bit 0 as the most significant bit) 1093 o Capability description 1095 o Defining RFC 1097 No bit is defined for the AUTO-BANDWIDTH-CAPABILITY TLV Object flag 1098 field in this document. 1100 8.3. AUTO-BANDWIDTH-ATTRIBUTE Sub-TLV 1102 This document specifies the AUTO-BANDWIDTH-ATTRIBUTE Sub-TLVs. IANA 1103 is requested to create an "AUTO-BANDWIDTH-ATTRIBUTE Sub-TLV Types" 1104 sub-registry in the "PCEP TLV Type Indicators" for the sub-TLVs 1105 carried in the AUTO-BANDWIDTH-ATTRIBUTE TLV. New sub-TLV are 1106 allocated only by an IETF Review action [RFC5226]. 1108 This document defines the following types: 1110 Type Name Reference 1111 -------------------------------------------------------------- 1112 0 Reserved [This I.D.] 1113 1 Sample-Interval sub-TLV [This I.D.] 1114 2 Adjustment-Interval sub-TLV [This I.D.] 1115 3 Down-Adjustment-Interval sub-TLV [This I.D.] 1116 4 Adjustment-Threshold sub-TLV [This I.D.] 1117 5 Adjustment-Threshold-Percentage sub-TLV [This I.D.] 1118 6 Down-Adjustment-Threshold sub-TLV [This I.D.] 1119 7 Down-Adjustment-Threshold-Percentage sub-TLV [This I.D.] 1120 8 Minimum-Bandwidth sub-TLV [This I.D.] 1121 9 Maximum-Bandwidth sub-TLV [This I.D.] 1122 10 Overflow-Threshold sub-TLV [This I.D.] 1123 11 Overflow-Threshold-Percentage sub-TLV [This I.D.] 1124 12 Underflow-Threshold sub-TLV [This I.D.] 1125 13 Underflow-Threshold-Percentage sub-TLV [This I.D.] 1126 14- Unassigned [This I.D.] 1127 65535 1129 8.4. Error Object 1131 This document defines a new Error-Value for PCErr message of type 19 1132 (Invalid Operation) [I-D.ietf-pce-stateful-pce]); IANA is requested 1133 to make the following allocation from this registry. 1134 1136 Error-Value Meaning Reference 1137 -------------------------------------------------------------- 1138 TBD4 Auto-Bandwidth Capability [This I.D.] 1139 was not Advertised 1141 8.5. Notification Object 1143 IANA is requested to allocate new Notification Types and Notification 1144 Values within the "Notification Object" sub-registry of the PCEP 1145 Numbers registry, as follows: 1147 Type Meaning Reference 1148 --------------------------------------------------------------- 1149 TBD3 Auto-Bandwidth Overwhelm State [This I.D.] 1151 Notification-value=1: Entering Auto-Bandwidth 1152 overwhelm state 1153 Notification-value=2: Clearing Auto-Bandwidth 1154 overwhelm state 1156 9. References 1158 9.1. Normative References 1160 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1161 Requirement Levels", BCP 14, RFC 2119, March 1997. 1163 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1164 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1165 May 2008. 1167 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 1168 (PCE) Communication Protocol (PCEP)", RFC 5440, March 1169 2009. 1171 [I-D.ietf-pce-stateful-pce] Crabbe, E., Minei, I., Medved, J., and 1172 R. Varga, "PCEP Extensions for Stateful PCE", draft-ietf- 1173 pce-stateful-pce (work in progress). 1175 [I-D.ietf-pce-pce-initiated-lsp] Crabbe, E., Minei, I., Sivabalan, 1176 S., and R. Varga, "PCEP Extensions for PCE-initiated LSP 1177 Setup in a Stateful PCE Model", draft-ietf-pce-pce- 1178 initiated-lsp (work in progress). 1180 9.2. Informative References 1182 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1183 (GMPLS) Signaling Functional Description", RFC 3471, 1184 January 2003. 1186 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1187 Authentication Option", RFC 5925, June 2010. 1189 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1190 Hardwick, "Path Computation Element Communication Protocol 1191 (PCEP) Management Information Base (MIB) Module", RFC 1192 7420, December 2014. 1194 [RFC8051] Zhang, X. and I. Minei, "Applicability of a Stateful Path 1195 Computation Element (PCE)", RFC 8051, January 2017. 1197 [I-D.ietf-pce-pceps] Lopez, D., Dios, O., Wu, W., and D. Dhody, 1198 "Secure Transport for PCEP", draft-ietf-pce-pceps (work in 1199 progress). 1201 [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. 1202 Tantsura, "A YANG Data Model for Path Computation Element 1203 Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang 1204 (work in progress). 1206 [I-D.gandhi-pce-pm] Gandhi, R., Wen, B., Barth, C., and D. Dhody 1207 "PCEP Extensions for Reporting MPLS-TE LSP Performance 1208 Measurements", draft-gandhi-pce-pm (work in progress). 1210 [IEEE.754.1985] Institute of Electrical and Electronics Engineers, 1211 "Standard for Binary Floating-Point Arithmetic", IEEE 1212 Standard 754, August 1985. 1214 Acknowledgments 1216 Authors would like to thank Robert Varga, Venugopal Reddy, Reeja 1217 Paul, Sandeep Boina, Avantika, JP Vasseur, Himanshu Shah and Adrian 1218 Farrel for their useful comments and suggestions. 1220 Contributors' Addresses 1222 He Zekun 1223 Tencent Holdings Ltd, 1224 Shenzhen P.R.China 1226 EMail: kinghe@tencent.com 1228 Xian Zhang 1229 Huawei Technologies 1230 Research Area F3-1B, 1231 Huawei Industrial Base, 1232 Shenzhen, 518129 1233 China 1235 Phone: +86-755-28972645 1236 EMail: zhang.xian@huawei.com 1238 Young Lee 1239 Huawei Technologies 1240 1700 Alma Drive, Suite 100 1241 Plano, TX 75075 1242 USA 1244 Phone: +1 972 509 5599 x2240 1245 Fax: +1 469 229 5397 1246 EMail: leeyoung@huawei.com 1248 Authors' Addresses 1250 Dhruv Dhody 1251 Huawei Technologies 1252 Divyashree Techno Park, Whitefield 1253 Bangalore, Karnataka 560066 1254 India 1256 EMail: dhruv.ietf@gmail.com 1258 Udayasree Palle 1259 Huawei Technologies 1260 Divyashree Techno Park, Whitefield 1261 Bangalore, Karnataka 560037 1262 India 1264 EMail: udayasree.palle@huawei.com 1266 Ravi Singh 1267 Juniper Networks 1268 1194 N. Mathilda Ave. 1269 Sunnyvale, CA 94089 1270 USA 1272 EMail: ravis@juniper.net 1274 Rakesh Gandhi 1275 Cisco Systems, Inc. 1277 EMail: rgandhi@cisco.com 1279 Luyuan Fang 1280 eBay 1281 USA 1283 EMail: lufang@ebay.com