idnits 2.17.1 draft-ietf-pce-stateful-pce-auto-bandwidth-02.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 (February 22, 2017) is 2613 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: August 26, 2017 R. Singh 6 Juniper Networks 7 R. Gandhi 8 Individual Contributor 9 L. Fang 10 eBay 11 February 22, 2017 13 PCEP Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with 14 Stateful PCE 15 draft-ietf-pce-stateful-pce-auto-bandwidth-02 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. Up-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. Up-Adjustment-Threshold sub-TLV . . . . . . . . . 13 82 5.2.3.2. Up-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 Up-Adjustment-Interval sub-TLV 500 3 4 Down-Adjustment-Interval sub-TLV 501 4 4 Up-Adjustment-Threshold sub-TLV 502 5 4 Up-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. Up-Adjustment-Interval sub-TLV 562 The Up-Adjustment-Interval sub-TLV specifies a time interval in 563 seconds at which bandwidth adjustment should be made when MaxAvgBw is 564 greater 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 | Up-Adjustment-Interval | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 Up-Adjustment-Interval sub-TLV format 580 5.2.2.2. Down-Adjustment-Interval sub-TLV 582 The Adjustment-Interval sub-TLV specifies a time interval in seconds 583 at which bandwidth adjustment should be made when MaxAvgBw is less 584 than the current bandwidth reservation. 586 The Type is 3, Length is 4, and the value comprises of 4-octet time 587 interval, the valid range is from 1 to 604800, in seconds. The 588 default value is 300 seconds. 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Type=3 | Length=4 | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Down-Adjustment-Interval | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 Down-Adjustment-Interval sub-TLV format 600 5.2.3. Adjustment Threshold 602 The sub-TLVs in this section are encoded to inform the PCEP peer the 603 adjustment threshold parameters. An implementation MAY include both 604 sub-TLVs for the absolute value and the percentage, in which case the 605 bandwidth is adjusted when either of the adjustment threshold 606 conditions are met. 608 5.2.3.1. Up-Adjustment-Threshold sub-TLV 610 The Up-Adjustment-Threshold sub-TLV is used to decide when the LSP 611 bandwidth should be adjusted when MaxAvgBw is greater than the 612 current bandwidth reservation. 614 0 1 2 3 615 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 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Type=4 | Length=4 | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Up-Adjustment-Threshold | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 Up-Adjustment-Threshold sub-TLV format 624 The Type is 4, Length is 4, and the value comprises of - 626 o Up-Adjustment Threshold: The absolute Up-Adjustment-Threshold 627 bandwidth value, encoded in IEEE floating point format (see 628 [IEEE.754.1985]), expressed in bytes per second. Refer to Section 629 3.1.2 of [RFC3471] for a table of commonly used values. 631 If the difference between the current MaxAvgBw and the current 632 bandwidth reservation is greater than or equal to the threshold 633 value, the LSP bandwidth is adjusted to the current bandwidth 634 demand (MaxAvgBw). 636 5.2.3.2. Up-Adjustment-Threshold-Percentage sub-TLV 638 The Up-Adjustment-Threshold-Percentage sub-TLV is used to decide when 639 the LSP bandwidth should be adjusted when MaxAvgBw is greater than 640 the current bandwidth reservation. 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Type=5 | Length=4 | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Reserved | Percentage | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 Up-Adjustment-Threshold-Percentage sub-TLV format 652 The Type is 5, Length is 4, and the value comprises of - 654 o Reserved: SHOULD be set to zero on transmission and MUST be 655 ignored on receipt. 657 o Percentage: The Up-Adjustment-Threshold value, encoded in 658 percentage (an integer from 0 to 100). If the percentage 659 difference between the current MaxAvgBw and the current bandwidth 660 reservation is greater than or equal to the threshold percentage, 661 the LSP bandwidth is adjusted to the current bandwidth demand 662 (MaxAvgBw). 664 5.2.3.3. Down-Adjustment-Threshold sub-TLV 666 The Down-Adjustment-Threshold sub-TLV is used to decide when the 667 LSP bandwidth should be adjusted when MaxAvgBw is lesser than the 668 current bandwidth reservation. 670 0 1 2 3 671 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 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | Type=6 | Length=4 | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Down-Adjustment-Threshold | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 Down-Adjustment-Threshold sub-TLV format 680 The Type is 6, Length is 4, and the value comprises of - 682 o Down-Adjustment Threshold: The absolute Down-Adjustment-Threshold 683 bandwidth value, encoded in IEEE floating point format (see 684 [IEEE.754.1985]), expressed in bytes per second. Refer to Section 685 3.1.2 of [RFC3471] for a table of commonly used values. 687 If the difference between current bandwidth reservation and the 688 current MaxAvgBw is greater than or equal to the threshold value, 689 the LSP bandwidth is adjusted to the current bandwidth demand 690 (MaxAvgBw). 692 5.2.3.4. Down-Adjustment-Threshold-Percentage sub-TLV 694 The Down-Adjustment-Threshold-Percentage sub-TLV is used to decide 695 when the LSP bandwidth should be adjusted when MaxAvgBw is lesser 696 than the current bandwidth reservation. 698 0 1 2 3 699 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 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Type=7 | Length=4 | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Reserved | Percentage | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 Down-Adjustment-Threshold-Percentage sub-TLV format 708 The Type is 7, Length is 4, and the value comprises of - 710 o Reserved: SHOULD be set to zero on transmission and MUST be 711 ignored on receipt. 713 o Percentage: The Down-Adjustment-Threshold value, encoded in 714 percentage (an integer from 0 to 100). If the percentage 715 difference between the current bandwidth reservation and the 716 current MaxAvgBw is greater than or equal to the threshold 717 percentage, the LSP bandwidth is adjusted to the current bandwidth 718 demand (MaxAvgBw). 720 5.2.4. Minimum and Maximum Bandwidth Values 722 5.2.4.1. Minimum-Bandwidth sub-TLV 724 The Minimum-Bandwidth sub-TLV specify the minimum bandwidth allowed 725 for the LSP, and is expressed in bytes per second. The LSP bandwidth 726 cannot be adjusted below the minimum bandwidth value. 728 The Type is 8, Length is 4, and the value comprises of 4-octet 729 bandwidth value encoded in IEEE floating point format (see 730 [IEEE.754.1985]), expressed in bytes per second. Refer to Section 731 3.1.2 of [RFC3471] for a table of commonly used values. 733 0 1 2 3 734 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 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Type=8 | Length=4 | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Minimum-Bandwidth | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 Minimum-Bandwidth sub-TLV format 743 5.2.4.2. Maximum-Bandwidth sub-TLV 745 The Maximum-Bandwidth sub-TLV specify the maximum bandwidth allowed 746 for the LSP, and is expressed in bytes per second. The LSP bandwidth 747 cannot be adjusted above the maximum bandwidth value. 749 The Type is 9, Length is 4, and the value comprises of 4-octet 750 bandwidth value encoded in IEEE floating point format (see 751 [IEEE.754.1985]), expressed in bytes per second. Refer to Section 752 3.1.2 of [RFC3471] for a table of commonly used values. 754 0 1 2 3 755 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. 997 When the PCEP speaker is no longer in the overwhelm state and is 998 available to process the auto-bandwidth adjustment, it SHOULD notify 999 its peer by sending a PCNtf message with Notification Type = TBD3 1000 (Auto-bandwidth Overwhelm State) and Notification Value = 2 (Clearing 1001 auto-bandwidth overwhelm state). 1003 When Auto-Bandwidth feature is deployed, a PCE can send this 1004 notification to PCC when a PCC is reporting frequent auto-bandwidth 1005 adjustments. If a PCC is overwhelmed with re-signaling, it can also 1006 notify the PCE to not adjust the LSP bandwidth while in overwhelm 1007 state. 1009 6. Security Considerations 1011 This document defines AUTO-BANDWIDTH-CAPABILITY TLV and 1012 AUTO-BANDWIDTH-ATTRIBUTE TLV which do not add any new security 1013 concerns beyond those discussed in [RFC5440] and 1014 [I-D.ietf-pce-stateful-pce] in itself. Some deployments may find the 1015 auto-bandwidth information as extra sensitive as it could be used to 1016 influence LSP path computation and LSP setup with adverse effect. 1017 Additionally, snooping of PCEP messages with such data or using PCEP 1018 messages for network reconnaissance, may give an attacker sensitive 1019 information about the operations of the network. Thus, such 1020 deployment should employ suitable PCEP security mechanisms like TCP 1021 Authentication Option (TCP-AO) [RFC5925] or [I-D.ietf-pce-pceps]. 1023 7. Manageability Considerations 1025 7.1. Control of Function and Policy 1027 The Auto-Bandwidth feature SHOULD be controlled per tunnel (at 1028 ingress (PCC) or PCE) and the values for auto-bandwidth parameters 1029 e.g. sample-interval, adjustment-interval (up/down), 1030 minimum-bandwidth, maximum-bandwidth, adjustment-threshold (up/down) 1031 SHOULD be configurable by an operator. 1033 7.2. Information and Data Models 1035 A Management Information Base (MIB) module for modeling PCEP is 1036 described in [RFC7420]. However, one may prefer the mechanism for 1037 configuration using YANG data model [I-D.ietf-pce-pcep-yang]. These 1038 SHOULD be enhanced to provide controls and indicators for support of 1039 auto-bandwidth feature. Support for various configuration knobs as 1040 well as counters of messages sent/received containing the TLVs 1041 (defined in this document) SHOULD be added. 1043 7.3. Liveness Detection and Monitoring 1045 Mechanisms defined in this document do not imply any new liveness 1046 detection and monitoring requirements in addition to those already 1047 listed in [RFC5440]. 1049 7.4. Verify Correct Operations 1051 Mechanisms defined in this document do not imply any new operation 1052 verification requirements in addition to those already listed in 1053 [RFC5440]. 1055 7.5. Requirements On Other Protocols 1057 Mechanisms defined in this document do not add any new requirements 1058 on other protocols. 1060 7.6. Impact On Network Operations 1062 In order to avoid any unacceptable impact on network operations, an 1063 implementation SHOULD allow a limit to be placed on the number of 1064 LSPs that can be enabled with auto-bandwidth feature. An 1065 implementation MAY allow a limit to be placed on the rate of auto- 1066 bandwidth messages sent by a PCEP speaker and received by a peer. An 1067 implementation MAY also allow sending a notification when a PCEP 1068 speaker is overwhelmed or the rate of messages reach a threshold. 1070 8. IANA Considerations 1072 8.1. PCEP TLV Type Indicators 1074 This document defines the following new PCEP TLVs; IANA is requested 1075 to make the following allocations from this registry. 1076 . 1079 Value Name Reference 1080 -------------------------------------------------------------- 1081 TBD2 AUTO-BANDWIDTH-CAPABILITY [This I.D.] 1082 TBD1 AUTO-BANDWIDTH-ATTRIBUTE [This I.D.] 1084 8.2. AUTO-BANDWIDTH-CAPABILITY TLV Flag Field 1086 IANA is requested to create a registry to manage the Flag field of 1087 the AUTO-BANDWIDTH-CAPABILITY TLV. 1089 New bit numbers are allocated only by an IETF Review action 1090 [RFC5226]. Each bit should be tracked with the following qualities: 1092 o Bit number (counting from bit 0 as the most significant bit) 1094 o Capability description 1096 o Defining RFC 1098 No bit is defined for the AUTO-BANDWIDTH-CAPABILITY TLV Object flag 1099 field in this document. 1101 8.3. AUTO-BANDWIDTH-ATTRIBUTE Sub-TLV 1103 This document specifies the AUTO-BANDWIDTH-ATTRIBUTE Sub-TLVs. IANA 1104 is requested to create an "AUTO-BANDWIDTH-ATTRIBUTE Sub-TLV Types" 1105 sub-registry in the "PCEP TLV Type Indicators" for the sub-TLVs 1106 carried in the AUTO-BANDWIDTH-ATTRIBUTE TLV. New sub-TLV are 1107 allocated only by an IETF Review action [RFC5226]. 1109 This document defines the following types: 1111 Type Name Reference 1112 -------------------------------------------------------------- 1113 0 Reserved [This I.D.] 1114 1 Sample-Interval sub-TLV [This I.D.] 1115 2 Up-Adjustment-Interval sub-TLV [This I.D.] 1116 3 Down-Adjustment-Interval sub-TLV [This I.D.] 1117 4 Up-Adjustment-Threshold sub-TLV [This I.D.] 1118 5 Up-Adjustment-Threshold-Percentage sub-TLV [This I.D.] 1119 6 Down-Adjustment-Threshold sub-TLV [This I.D.] 1120 7 Down-Adjustment-Threshold-Percentage sub-TLV [This I.D.] 1121 8 Minimum-Bandwidth sub-TLV [This I.D.] 1122 9 Maximum-Bandwidth sub-TLV [This I.D.] 1123 10 Overflow-Threshold sub-TLV [This I.D.] 1124 11 Overflow-Threshold-Percentage sub-TLV [This I.D.] 1125 12 Underflow-Threshold sub-TLV [This I.D.] 1126 13 Underflow-Threshold-Percentage sub-TLV [This I.D.] 1127 14- Unassigned [This I.D.] 1128 65535 1130 8.4. Error Object 1132 This document defines a new Error-Value for PCErr message of type 19 1133 (Invalid Operation) [I-D.ietf-pce-stateful-pce]); IANA is requested 1134 to make the following allocation from this registry. 1135 1137 Error-Value Meaning Reference 1138 -------------------------------------------------------------- 1139 TBD4 Auto-Bandwidth Capability [This I.D.] 1140 was not Advertised 1142 8.5. Notification Object 1144 IANA is requested to allocate new Notification Types and Notification 1145 Values within the "Notification Object" sub-registry of the PCEP 1146 Numbers registry, as follows: 1148 Type Meaning Reference 1149 --------------------------------------------------------------- 1150 TBD3 Auto-Bandwidth Overwhelm State [This I.D.] 1152 Notification-value=1: Entering Auto-Bandwidth 1153 overwhelm state 1154 Notification-value=2: Clearing Auto-Bandwidth 1155 overwhelm state 1157 9. References 1159 9.1. Normative References 1161 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1162 Requirement Levels", BCP 14, RFC 2119, March 1997. 1164 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1165 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1166 May 2008. 1168 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 1169 (PCE) Communication Protocol (PCEP)", RFC 5440, March 1170 2009. 1172 [I-D.ietf-pce-stateful-pce] Crabbe, E., Minei, I., Medved, J., and 1173 R. Varga, "PCEP Extensions for Stateful PCE", draft-ietf- 1174 pce-stateful-pce (work in progress). 1176 [I-D.ietf-pce-pce-initiated-lsp] Crabbe, E., Minei, I., Sivabalan, 1177 S., and R. Varga, "PCEP Extensions for PCE-initiated LSP 1178 Setup in a Stateful PCE Model", draft-ietf-pce-pce- 1179 initiated-lsp (work in progress). 1181 9.2. Informative References 1183 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1184 (GMPLS) Signaling Functional Description", RFC 3471, 1185 January 2003. 1187 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1188 Authentication Option", RFC 5925, June 2010. 1190 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1191 Hardwick, "Path Computation Element Communication Protocol 1192 (PCEP) Management Information Base (MIB) Module", RFC 1193 7420, December 2014. 1195 [RFC8051] Zhang, X. and I. Minei, "Applicability of a Stateful Path 1196 Computation Element (PCE)", RFC 8051, January 2017. 1198 [I-D.ietf-pce-pceps] Lopez, D., Dios, O., Wu, W., and D. Dhody, 1199 "Secure Transport for PCEP", draft-ietf-pce-pceps (work in 1200 progress). 1202 [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. 1203 Tantsura, "A YANG Data Model for Path Computation Element 1204 Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang 1205 (work in progress). 1207 [I-D.gandhi-pce-pm] Gandhi, R., Wen, B., Barth, C., and D. Dhody 1208 "PCEP Extensions for Reporting MPLS-TE LSP Performance 1209 Measurements", draft-gandhi-pce-pm (work in progress). 1211 [IEEE.754.1985] Institute of Electrical and Electronics Engineers, 1212 "Standard for Binary Floating-Point Arithmetic", IEEE 1213 Standard 754, August 1985. 1215 Acknowledgments 1217 Authors would like to thank Robert Varga, Venugopal Reddy, Reeja 1218 Paul, Sandeep Boina, Avantika, JP Vasseur, Himanshu Shah and Adrian 1219 Farrel for their useful comments and suggestions. 1221 Contributors' Addresses 1223 He Zekun 1224 Tencent Holdings Ltd, 1225 Shenzhen P.R.China 1227 EMail: kinghe@tencent.com 1229 Xian Zhang 1230 Huawei Technologies 1231 Research Area F3-1B, 1232 Huawei Industrial Base, 1233 Shenzhen, 518129 1234 China 1236 Phone: +86-755-28972645 1237 EMail: zhang.xian@huawei.com 1239 Young Lee 1240 Huawei Technologies 1241 1700 Alma Drive, Suite 100 1242 Plano, TX 75075 1243 USA 1245 Phone: +1 972 509 5599 x2240 1246 Fax: +1 469 229 5397 1247 EMail: leeyoung@huawei.com 1249 Authors' Addresses 1251 Dhruv Dhody 1252 Huawei Technologies 1253 Divyashree Techno Park, Whitefield 1254 Bangalore, Karnataka 560066 1255 India 1257 EMail: dhruv.ietf@gmail.com 1259 Udayasree Palle 1260 Huawei Technologies 1261 Divyashree Techno Park, Whitefield 1262 Bangalore, Karnataka 560037 1263 India 1265 EMail: udayasree.palle@huawei.com 1267 Ravi Singh 1268 Juniper Networks 1269 1194 N. Mathilda Ave. 1270 Sunnyvale, CA 94089 1271 USA 1273 EMail: ravis@juniper.net 1275 Rakesh Gandhi 1276 Individual Contributor 1278 EMail: rgandhi.ietf@gmail.com 1280 Luyuan Fang 1281 eBay 1282 USA 1284 EMail: lufang@ebay.com