idnits 2.17.1 draft-ietf-pce-stateful-pce-auto-bandwidth-12.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 (September 26, 2019) is 1646 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 7525 (Obsoleted by RFC 9325) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754.1985' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track R. Gandhi, Ed. 5 Expires: March 29, 2020 Cisco Systems, Inc. 6 U. Palle 7 R. Singh 8 Individual Contributor 9 L. Fang 10 Expedia, Inc. 11 September 26, 2019 13 PCEP Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with 14 Stateful PCE 15 draft-ietf-pce-stateful-pce-auto-bandwidth-12 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 The automatic bandwidth feature allows automatic and dynamic 27 adjustment of the TE LSP bandwidth reservation based on the volume of 28 traffic flowing through the LSP. This document describes PCEP 29 extensions for automatic bandwidth adjustment when employing an 30 Active Stateful PCE 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 https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 66 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 67 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 68 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Requirements for PCEP Extensions . . . . . . . . . . . . . . . 7 70 4. Architectural Overview . . . . . . . . . . . . . . . . . . . . 8 71 4.1. Auto-Bandwidth Overview . . . . . . . . . . . . . . . . . 8 72 4.2. Auto-bandwidth Theory of Operation . . . . . . . . . . . . 9 73 4.3. Scaling Considerations . . . . . . . . . . . . . . . . . . 10 74 5. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 10 75 5.1. Capability Advertisement . . . . . . . . . . . . . . . . . 10 76 5.1.1. AUTO-BANDWIDTH-CAPABILITY TLV . . . . . . . . . . . . 11 77 5.2. AUTO-BANDWIDTH-ATTRIBUTES TLV . . . . . . . . . . . . . . 12 78 5.2.1. Sample-Interval sub-TLV . . . . . . . . . . . . . . . 13 79 5.2.2. Adjustment Intervals . . . . . . . . . . . . . . . . . 14 80 5.2.2.1. Adjustment-Interval sub-TLV . . . . . . . . . . . 14 81 5.2.2.2. Down-Adjustment-Interval sub-TLV . . . . . . . . . 14 82 5.2.3. Adjustment Thresholds . . . . . . . . . . . . . . . . 15 83 5.2.3.1. Adjustment-Threshold sub-TLV . . . . . . . . . . . 15 84 5.2.3.2. Adjustment-Threshold-Percentage sub-TLV . . . . . 16 85 5.2.3.3. Down-Adjustment-Threshold sub-TLV . . . . . . . . 17 86 5.2.3.4. Down-Adjustment-Threshold-Percentage sub-TLV . . . 18 87 5.2.4. Minimum and Maximum Bandwidth Values . . . . . . . . . 19 88 5.2.4.1. Minimum-Bandwidth sub-TLV . . . . . . . . . . . . 19 89 5.2.4.2. Maximum-Bandwidth sub-TLV . . . . . . . . . . . . 19 90 5.2.5. Overflow and Underflow Conditions . . . . . . . . . . 20 91 5.2.5.1. Overflow-Threshold sub-TLV . . . . . . . . . . . . 20 92 5.2.5.2. Overflow-Threshold-Percentage sub-TLV . . . . . . 21 93 5.2.5.3. Underflow-Threshold sub-TLV . . . . . . . . . . . 22 94 5.2.5.4. Underflow-Threshold-Percentage sub-TLV . . . . . . 23 95 5.3. BANDWIDTH Object . . . . . . . . . . . . . . . . . . . . . 24 96 5.4. The PCInitiate Message . . . . . . . . . . . . . . . . . . 24 97 5.5. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 24 98 5.6. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 24 99 5.7. The PCNtf Message . . . . . . . . . . . . . . . . . . . . 25 100 6. Manageability Considerations . . . . . . . . . . . . . . . . . 26 101 6.1. Control of Function and Policy . . . . . . . . . . . . . . 26 102 6.2. Information and Data Models . . . . . . . . . . . . . . . 26 103 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 27 104 6.4. Verify Correct Operations . . . . . . . . . . . . . . . . 27 105 6.5. Requirements On Other Protocols . . . . . . . . . . . . . 27 106 6.6. Impact On Network Operations . . . . . . . . . . . . . . . 27 107 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 108 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 109 8.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 28 110 8.2. AUTO-BANDWIDTH-CAPABILITY TLV Flag Field . . . . . . . . . 28 111 8.3. AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV . . . . . . . . . . . . 29 112 8.4. Error Object . . . . . . . . . . . . . . . . . . . . . . . 29 113 8.5. Notification Object . . . . . . . . . . . . . . . . . . . 30 114 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 115 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31 116 9.2. Informative References . . . . . . . . . . . . . . . . . . 31 117 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33 118 Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 33 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 121 1. Introduction 123 [RFC5440] describes the Path Computation Element Protocol (PCEP) as a 124 communication mechanism between a Path Computation Client (PCC) and a 125 Path Computation Element (PCE), or between PCE and PCE, that enables 126 computation of Multi-Protocol Label Switching (MPLS) Traffic 127 Engineering Label Switched Paths (TE LSPs). 129 [RFC8231] specifies extensions to PCEP to enable stateful control of 130 MPLS TE LSPs. It describes two mode of operations - Passive stateful 131 PCE and Active stateful PCE. Further, [RFC8281] describes the setup, 132 maintenance and teardown of PCE-Initiated LSPs for the stateful PCE 133 model. In this document, the focus is on Active stateful PCE where 134 the LSPs are controlled by the PCE. 136 Over time, based on the varying traffic pattern, an LSP established 137 with a certain bandwidth may require adjustment of the bandwidth 138 reserved in the network dynamically. The head-end Label Switch 139 Router (LSR) monitors the actual bandwidth demand of the established 140 LSP and periodically computes new bandwidth. The head-end LSR 141 adjusts the bandwidth reservation of the LSP based on the computed 142 bandwidth automatically. This feature, when available in the head- 143 end Label Switching Router (LSR) implementation, is common referred 144 to as Auto-Bandwidth. The Auto-Bandwidth feature is described in 145 detail in Section 4 of this document. 147 In the model considered in this document, the PCC (head-end of the 148 LSP) collects the traffic rate samples flowing through the LSP and 149 calculates the new adjusted bandwidth. The PCC reports the 150 calculated bandwidth to be adjusted to the PCE. This is similar to 151 the Passive stateful PCE model: while the Passive stateful PCE uses a 152 path request/reply mechanism, the Active stateful PCE uses a 153 report/update mechanism. In case of PCE-Initiated LSP, the PCC is 154 requested during the LSP initiation to monitor and calculate the new 155 adjusted bandwidth. [RFC8051] describes the use-case for Auto- 156 Bandwidth adjustment for Passive and Active stateful PCE. 158 Another approach would be to send the measured values itself to the 159 PCE, which is considered out of scope for this document. 161 This document defines the PCEP extensions needed to support an Auto- 162 Bandwidth feature in an Active stateful PCE model where the LSP 163 bandwidth to be adjusted is calculated on the PCC (head-end of the 164 LSP). The use of PCE to calculate the bandwidth to be adjusted is out 165 of scope of this document. 167 2. Conventions Used in This Document 169 2.1. Requirements Language 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 173 "OPTIONAL" in this document are to be interpreted as described in BCP 174 14 [RFC2119] [RFC8174] when, and only when, they appear in all 175 capitals, as shown here. 177 2.2. Abbreviations 179 PCC: Path Computation Client. 181 PCE: Path Computation Element. 183 PCEP: Path Computation Element Communication Protocol. 185 TE LSP: Traffic Engineering Label Switched Path. 187 2.3. Terminology 189 The reader is assumed to be familiar with the terminology defined in 190 [RFC5440], [RFC8231], and [RFC8281]. 192 In this document, the PCC is considered to be the head end LSR of the 193 LSP. Other types of PCC are not in scope. 195 The following auto-bandwidth terminology is defined in this document. 197 Maximum Average Bandwidth (MaxAvgBw): The maximum average bandwidth 198 represents the current 'measured' traffic bandwidth demand of the 199 LSP during a time interval. This is the maximum value of the 200 traffic bandwidth rate samples (Bandwidth-Samples) in a given time 201 interval. 203 Adjusted Bandwidth: This is the Auto-Bandwidth 'computed' bandwidth 204 that is used to adjust the bandwidth reservation of the LSP. 206 Sample-Interval: The periodic time interval at which the measured 207 traffic rate of the LSP is collected as a Bandwidth-Sample. 209 Bandwidth-Sample: The bandwidth sample of the measured traffic rate 210 of the LSP collected at every Sample-Interval. 212 Maximum-Bandwidth: The maximum bandwidth that can be reserved for 213 the LSP. 215 Minimum-Bandwidth: The minimum bandwidth that can be reserved for 216 the LSP. 218 Up-Adjustment-Interval: The periodic time interval at which the 219 bandwidth adjustment should be made using the MaxAvgBw, when 220 MaxAvgBw is greater than the current bandwidth reservation of the 221 LSP. 223 Down-Adjustment-Interval: The periodic time interval at which the 224 bandwidth adjustment should be made using the MaxAvgBw, when 225 MaxAvgBw is less than the current bandwidth reservation of the 226 LSP. 228 Up-Adjustment-Threshold: This parameter is used to decide when the 229 LSP bandwidth should be adjusted. If the percentage or absolute 230 difference between the current MaxAvgBw and the current bandwidth 231 reservation is greater than or equal to the threshold value, the 232 LSP bandwidth is adjusted (upsized) to the current bandwidth 233 demand (Adjusted Bandwidth) at the Up-Adjustment-Interval expiry. 235 Down-Adjustment-Threshold: This parameter is used to decide when the 236 LSP bandwidth should be adjusted. If the percentage or absolute 237 difference between the current bandwidth reservation and the 238 current MaxAvgBw is greater than or equal to the threshold value, 239 the LSP bandwidth is adjusted (downsized) to the current bandwidth 240 demand (Adjusted Bandwidth) at the Down-Adjustment-Interval 241 expiry. 243 Overflow-Count: This parameter is used to decide when the LSP 244 bandwidth should be adjusted when there is a sudden increase in 245 traffic demand. This value indicates how many times, 246 consecutively, the percentage or absolute difference between the 247 current MaxAvgBw and the current bandwidth reservation of the LSP 248 needs to be greater than or equal to the Overflow-Threshold value 249 in order to meet the overflow condition. 251 Overflow-Threshold: This parameter is used to decide when the LSP 252 bandwidth should be adjusted when there is a sudden increase in 253 traffic demand. If the percentage or absolute difference between 254 the current MaxAvgBw and the current bandwidth reservation of the 255 LSP is greater than or equal to the threshold value, the overflow 256 condition is said to be met. The LSP bandwidth is adjusted to the 257 current bandwidth demand bypassing the Up-Adjustment-Interval if 258 the overflow condition is met consecutively for the Overflow- 259 Count. The Overflow-Threshold needs to be greater than or equal to 260 the Up-Adjustment-Threshold. 262 Underflow-Count: This parameter is used to decide when the LSP 263 bandwidth should be adjusted when there is a sudden decrease in 264 traffic demand. This value indicates how many times 265 consecutively, the percentage or absolute difference between the 266 current MaxAvgBw and the current bandwidth reservation of the LSP 267 needs to be greater than or equal to the Underflow-Threshold value 268 in order to meet the underflow condition. 270 Underflow-Threshold: This parameter is used to decide when the LSP 271 bandwidth should be adjusted when there is a sudden decrease in 272 traffic demand. If the percentage or absolute difference between 273 the current MaxAvgBw and the current bandwidth reservation of the 274 LSP is greater than or equal to the threshold value, the underflow 275 condition is said to be met. The LSP bandwidth is adjusted to the 276 current bandwidth demand bypassing the Down-Adjustment-Interval if 277 the underflow condition is met consecutively for the Underflow- 278 Count. The Underflow-Threshold needs to be greater than or equal 279 to the Down-Adjustment-Threshold. 281 Minimum-Threshold: When percentage-based thresholds are in use, they 282 are accompanied by this minimum threshold, which is used to 283 enforce that the magnitude of deviation of calculated LSP 284 bandwidth to be adjusted from the current bandwidth reservations 285 exceeds a specific non-percentage-based criterion (represented as 286 an absolute bandwidth value) before any adjustments are made. This 287 serves to suppress unnecessary auto-bandwidth adjustments and re- 288 signaling of the LSP at low bandwidth values. 290 3. Requirements for PCEP Extensions 292 The PCEP extensions required for auto-bandwidth are summarized in the 293 following table as well as in Figure 1. 295 +---------------------------------+---------------------------------+ 296 | PCC Initiated | PCE Initiated | 297 +---------------------------------+---------------------------------+ 298 | | | 299 | PCC monitors the traffic | At the time of initiation, | 300 | and reports the calculated | PCE request PCC to monitor | 301 | bandwidth to be adjusted | the traffic and report the | 302 | to the PCE. | calculated bandwidth to be | 303 | | adjusted to the PCE. | 304 | | | 305 | Extension is needed for PCC | Extension is needed for PCE | 306 | to pass on the adjustment | to pass on the adjustment | 307 | parameters at the time of | parameters at the time of | 308 | LSP Delegation. | LSP Initiation. | 309 | | | 310 +---------------------------------+---------------------------------+ 312 Table 1: Requirements for Auto-Bandwidth PCEP extensions 314 ---------- 315 | | 316 | PCE | 317 | | 318 ---------- 319 | ^ 320 AUTO-BANDWIDTH CAPABILITY | | AUTO-BANDWIDTH CAPABILITY 321 | | 322 AUTO-BANDWIDTH ATTRIBUTES | | AUTO-BANDWIDTH ATTRIBUTES 323 | | (For Delegated LSPs) 324 | | 325 | | REQUESTED BANDWIDTH 326 v | 327 ---------- 328 | | 329 | PCC | 330 | | 331 ---------- 333 Figure 1: Overview of Auto-Bandwidth PCEP extensions 335 A PCEP speaker supporting this document must have a mechanism to 336 advertise the automatic bandwidth adjustment capability for both PCC- 337 Initiated and PCE-Initiated LSPs. 339 Auto-bandwidth deployment considerations for PCEP extensions are 340 summarized below: 342 o It is necessary to identify and inform the PCC which LSPs have 343 enabled the Auto-Bandwidth feature. Not all LSPs in some 344 deployments would like their bandwidth to be dependent on the 345 real-time bandwidth usage; for some LSPs leaving the bandwidth 346 constant as set by the operator is preferred. 348 o In addition, an operator should be able to specify the auto- 349 bandwidth adjustment parameters (i.e. configuration knobs) to 350 control this feature (e.g. minimum/ maximum bandwidth range). The 351 PCC should be informed about these adjustment parameters. 353 4. Architectural Overview 355 4.1. Auto-Bandwidth Overview 357 The Auto-Bandwidth feature allows automatic and dynamic adjustment of 358 the reserved bandwidth of an LSP over time (i.e., without network 359 operator intervention) to accommodate the varying traffic demand of 360 the LSP. If the traffic flowing through the LSP is lower than the 361 configured or current reserved bandwidth of the LSP, the extra 362 bandwidth is being reserved needlessly and being wasted. Conversely, 363 if the actual traffic flowing through the LSP is higher than the 364 configured or current reserved bandwidth of the LSP, it can 365 potentially cause congestion or packet loss in the network. The 366 initial LSP bandwidth can be set to an arbitrary value (including 367 zero). In practice, it can be set to an expected value based on 368 design and planning. The head-end Label Switch Router (LSR) monitors 369 the actual traffic flowing through the LSP and uses that information 370 to adjust the bandwidth reservation of the LSP in the network. 372 Bandwidth adjustment must not cause disruption to the traffic flow 373 carried by the LSP. One way to achieve this is to use the 374 make-before-break signaling method [RFC3209]. 376 4.2. Auto-bandwidth Theory of Operation 378 This section describes the Auto-Bandwidth feature in a general way. 379 When the Auto-Bandwidth feature is enabled, the measured traffic rate 380 is periodically sampled at each Sample-Interval by the PCC, when the 381 PCC is the head-end node of the LSP. The sample interval can be 382 configured by an operator, with a default value of 5 minutes. A very 383 low Sample-Interval could have some undesirable interactions with 384 transport protocols (see Section 6.6). 386 The traffic rate samples are accumulated over the Adjustment-Interval 387 period (in the Up or Down direction). The period can be configured 388 by an operator, with a default value of 24 hours. The PCC in-charge 389 of calculating the bandwidth to be adjusted can decide to adjust the 390 bandwidth of the LSP to the highest traffic rate sample (MaxAvgBw) 391 amongst the set of bandwidth samples collected over the 392 Adjustment-Interval period (in the Up or Down direction) depending on 393 the operator policy. 395 Note that the highest traffic rate sample could be higher or lower 396 than the current LSP bandwidth. Only if the difference between the 397 current bandwidth demand (MaxAvgBw) and the current bandwidth 398 reservation is greater than or equal to the Adjustment-Threshold the 399 LSP bandwidth is adjusted (upsized) to the current bandwidth demand 400 (MaxAvgBw). The Adjustment-Threshold could be an absolute value or a 401 percentage. The threshold can be configured by an operator, with a 402 default value of 5 percentage. Similarly, if the difference between 403 the current bandwidth reservation and the current bandwidth demand 404 (MaxAvgBw) is greater than or equal to the Down-Adjustment-Threshold 405 (percentage or absolute value), the LSP bandwidth is adjusted 406 (downsized) to the current bandwidth demand (MaxAvgBw). Some LSPs 407 are less eventful while other LSPs may encounter a lot of changes in 408 the traffic pattern. The thresholds and intervals for bandwidth 409 adjustment are configured based on the traffic pattern of the LSP. 411 In order to avoid frequent re-signaling, an operator may set a longer 412 adjustment-interval value (Up and/or Down). However, a longer 413 Adjustment-Interval can result in an undesirable effect of masking 414 sudden changes in traffic demands of an LSP. To avoid this, the 415 Auto-Bandwidth feature may prematurely expire the adjustment interval 416 and adjust the LSP bandwidth to accommodate the sudden bursts of 417 increase in traffic demand as an overflow condition or decrease in 418 traffic demand as an underflow condition. An operator needs to 419 configure appropriate values for the Overflow-Threshold and/or 420 Underflow-Threshold parameters and they do not have default values 421 defined in this document. 423 All thresholds in this document could be represented in both absolute 424 value and percentage, and could be used together. This is provided 425 to accommodate the cases where the LSP bandwidth reservation may 426 become very large or very small over time. For example, an operator 427 may use the percentage threshold to handle small to large bandwidth 428 values and absolute values to handle very large bandwidth values. 429 The auto-bandwidth adjustment is made when either one of the two 430 thresholds, the absolute or percentage, is crossed. 432 When using the (adjustment/overflow/underflow) percentage thresholds, 433 if the LSP bandwidth changes rapidly at very low values, it may 434 trigger frequent auto-bandwidth adjustments due to the crossing of 435 the percentage thresholds. This can lead to unnecessary re-signaling 436 of the LSPs in the network. This is suppressed by setting the 437 minimum-threshold parameters along with the percentage thresholds. 438 The auto-bandwidth adjustment is only made if the LSP bandwidth 439 crosses both the percentage threshold and the minimum-threshold 440 parameters. 442 4.3. Scaling Considerations 444 It should be noted that any bandwidth change requires re-signaling of 445 an LSP, which can further trigger preemption of lower priority LSPs 446 in the network. When deployed under scale, this can lead to a 447 signaling churn in the network. The Auto-bandwidth application 448 algorithm is thus advised to take this into consideration before 449 adjusting the LSP bandwidth. Operators are advised to set the values 450 of various auto-bandwidth adjustment parameters appropriate for the 451 deployed LSP scale. 453 If a PCE gets overwhelmed, it can notify the PCC to temporarily 454 suspend the reporting of the new LSP bandwidth to be adjusted (see 455 Section 5.7 of this document). Similarly, if a PCC gets overwhelmed 456 due to signaling churn, it can notify the PCE to temporarily suspend 457 new LSP setup requests (see Section 5.7 of this document). 459 5. PCEP Extensions 461 5.1. Capability Advertisement 463 During PCEP Initialization Phase, PCEP speakers (PCE or PCC) 464 advertise their support of Automatic Bandwidth adjustment feature. A 465 PCEP speaker includes the AUTO-BANDWIDTH-CAPABILITY TLV, in the OPEN 466 Object to advertise its support for PCEP Auto-Bandwidth extensions. 467 The presence of the AUTO-BANDWIDTH-CAPABILITY TLV in the OPEN Object 468 indicates that the Automatic Bandwidth feature is supported as 469 described in this document. 471 o The PCEP protocol extensions for Auto-Bandwidth adjustments MUST 472 NOT be used if one or both PCEP speakers have not included the 473 AUTO-BANDWIDTH-CAPABILITY TLV in their respective OPEN message. 475 o A PCEP speaker that does not recognize the extensions defined in 476 this document would simply ignore the TLVs as per [RFC5440]. 478 o If a PCEP speaker that supports the extensions defined in this 479 document but did not advertise this capability, then upon receipt 480 of AUTO-BANDWIDTH-ATTRIBUTES TLV in the LSP Attributes (LSPA) 481 object, it SHOULD generate a PCErr with error-type 19 (Invalid 482 Operation), error-value TBD4 (Auto-Bandwidth capability was not 483 advertised) and ignore the AUTO-BANDWIDTH-ATTRIBUTES TLV. 485 5.1.1. AUTO-BANDWIDTH-CAPABILITY TLV 487 The AUTO-BANDWIDTH-CAPABILITY TLV is an optional TLV for use in the 488 OPEN Object for Automatic Bandwidth Adjustment via PCEP capability 489 advertisement. Its format is shown in the following figure: 491 0 1 2 3 492 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 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Type=TBD2 | Length=4 | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Flags | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 AUTO-BANDWIDTH-CAPABILITY TLV format 501 The Type of the TLV is (TBD2) and it has a fixed Length of 4 octets. 503 The value comprises a single field - Flags (32 bits). No flags are 504 defined for this TLV in this document. 506 Unassigned bits are considered reserved. They MUST be set to 0 on 507 transmission and MUST be ignored on receipt. 509 Advertisement of the AUTO-BANDWIDTH-CAPABILITY TLV implies support of 510 auto-bandwidth adjustment, as well as the objects, TLVs and 511 procedures defined in this document. 513 5.2. AUTO-BANDWIDTH-ATTRIBUTES TLV 515 The AUTO-BANDWIDTH-ATTRIBUTES TLV provides the 'configurable knobs' 516 of the feature and it can be included as an optional TLV in the LSPA 517 Object (as described in [RFC5440]). 519 For PCE-Initiated LSP [RFC8281], this TLV is included in the LSPA 520 Object with the PCInitiate message. For the PCC-Initiated delegated 521 LSPs, this TLV is carried in the PCRpt message in LSPA Object. This 522 TLV is also carried in the LSPA object with the PCUpd message to 523 direct the PCC (LSP head-end) to make updates to auto-bandwidth 524 attributes such as Adjustment-Interval. 526 The TLV is encoded in all PCEP messages for the LSP while the auto- 527 bandwidth adjustment feature is enabled, the absence of the TLV 528 indicates the PCEP speaker wishes to disable the feature. This TLV 529 includes multiple AUTO-BANDWIDTH-ATTRIBUTES sub-TLVs. The 530 AUTO-BANDWIDTH-ATTRIBUTES sub-TLVs are included if there is a change 531 since the last information sent in the PCEP message. The default 532 values for missing sub-TLVs apply for the first PCEP message for the 533 LSP. 535 The format of the AUTO-BANDWIDTH-ATTRIBUTES TLV is shown in the 536 following figure: 538 0 1 2 3 539 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 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Type=TBD1 | Length | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | | 544 // sub-TLVs // 545 | | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 AUTO-BANDWIDTH-ATTRIBUTES TLV format 550 Type: TBD1 552 Length: The Length field defines the length of the value portion 553 in octets as per [RFC5440]. 555 Value: This comprises one or more sub-TLVs. 557 Following sub-TLVs are defined in this document: 559 Type Len Name 560 ------------------------------------------------------------------- 561 1 4 Sample-Interval sub-TLV 562 2 4 Adjustment-Interval sub-TLV 563 3 4 Down-Adjustment-Interval sub-TLV 564 4 4 Adjustment-Threshold sub-TLV 565 5 8 Adjustment-Threshold-Percentage sub-TLV 566 6 4 Down-Adjustment-Threshold sub-TLV 567 7 8 Down-Adjustment-Threshold-Percentage sub-TLV 568 8 4 Minimum-Bandwidth sub-TLV 569 9 4 Maximum-Bandwidth sub-TLV 570 10 8 Overflow-Threshold sub-TLV 571 11 8 Overflow-Threshold-Percentage sub-TLV 572 12 8 Underflow-Threshold sub-TLV 573 13 8 Underflow-Threshold-Percentage sub-TLV 575 Future specifications can define additional sub-TLVs. 577 The sub-TLVs are encoded to inform the PCEP peer of the various 578 sampling and adjustment parameters. In case of a missing sub-TLV, as 579 per the local policy, either the default value (as specified in this 580 document) or some other operator configured value is used. 582 All sub-TLVs are optional and any unrecognized sub-TLV MUST be 583 ignored. If a sub-TLV of the same type appears more than once, only 584 the first occurrence is processed and all others MUST be ignored. 586 The following sub-sections describe the sub-TLVs which are currently 587 defined to be carried within the AUTO-BANDWIDTH-ATTRIBUTES TLV. 589 5.2.1. Sample-Interval sub-TLV 591 The Sample-Interval sub-TLV specifies a time interval in seconds at 592 which traffic samples are collected at the PCC. 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Type=1 | Length=4 | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Sample-Interval | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 Sample-Interval sub-TLV format 604 The Type is 1, Length is 4 octets, and the value comprises of - 606 o Sample-Interval: The 4-octet time interval for bandwidth sample 607 collection. The valid range is from 1 to 604800 (7 days), in 608 seconds. The default value is 300 seconds. Due care needs to be 609 taken in case of a very low Sample-Interval, as it can have some 610 undesirable interactions with transport protocols (see Section 611 6.6). The sample-interval parameter MUST NOT be greater than the 612 (down) adjustment-interval. In case of an invalid value, the Sub- 613 TLV MUST be ignored and the previous value is maintained. 615 5.2.2. Adjustment Intervals 617 The sub-TLVs in this section are encoded to inform the PCEP peer the 618 adjustment interval parameters. The Adjustment-Interval sub-TLV 619 specifies the time interval for both upward (Up-Adjustment-Interval) 620 and downward (Down-Adjustment-Interval) trends. An implementation MAY 621 require to set a different adjustment interval values for when the 622 bandwidth usage trend is downwards from when it is moving upwards. In 623 that case, the operator could use the Down-Adjustment-Interval sub- 624 TLV which overrides the Adjustment-Interval value for Down- 625 Adjustment-Interval. 627 5.2.2.1. Adjustment-Interval sub-TLV 629 The Adjustment-Interval sub-TLV specifies a time interval in seconds 630 at which bandwidth adjustment should be made in upward or downward 631 direction. This sub-TLV specify the value for Up-Adjustment-Interval 632 and Down-Adjustment-Interval when they are the same and the Down- 633 Adjustment-Interval sub-TLV is not included. 635 0 1 2 3 636 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 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Type=2 | Length=4 | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Adjustment-Interval | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 Adjustment-Interval sub-TLV format 645 The Type is 2, Length is 4 octets, and the value comprises of - 647 o Adjustment-Interval: The 4-octet time interval for bandwidth 648 adjustments. The valid range is from 1 to 604800 (7 days), in 649 seconds. The default value is 86400 seconds (1 day). The 650 adjustment-interval parameter MUST NOT be less than the 651 sample-interval, otherwise the Sub-TLV MUST be ignored and the 652 previous value is maintained. 654 5.2.2.2. Down-Adjustment-Interval sub-TLV 656 The Down-Adjustment-Interval sub-TLV specifies a time interval in 657 seconds at which bandwidth adjustment should be made when MaxAvgBw is 658 less than the current bandwidth reservation of the LSP. This 659 parameter overrides the Adjustment-Interval for the downward trend. 660 This sub-TLV is used only when there is a need for different 661 adjustment intervals in the upward and downward directions. 663 0 1 2 3 664 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 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Type=3 | Length=4 | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | Down-Adjustment-Interval | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 Down-Adjustment-Interval sub-TLV format 673 The Type is 3, Length is 4 octets, and the value comprises of - 675 o Down-Adjustment-Interval: The 4-octet time interval for downward 676 bandwidth adjustments. The valid range is from 1 to 604800 (7 677 days), in seconds. The default value equals the adjustment- 678 interval. The down-adjustment-interval parameter MUST NOT be less 679 than the sample-interval, otherwise the Sub-TLV MUST be ignored 680 and the previous value is maintained. 682 5.2.3. Adjustment Thresholds 684 The sub-TLVs in this section are encoded to inform the PCEP peer of 685 the adjustment threshold parameters. An implementation MAY include 686 both sub-TLVs for the absolute value and the percentage, in which 687 case the bandwidth is adjusted when either of the adjustment 688 threshold conditions are met. The Adjustment-Threshold sub-TLV 689 specifies the threshold for both upward (Up-Adjustment-Threshold) and 690 downward (Down-Adjustment-Threshold) trend. If the operator would 691 like to use a different adjustment threshold during the downward 692 trend, the Down-Adjustment-Threshold sub-TLV is included. Similarly, 693 the Adjustment-Threshold-Percentage sub-TLV specifies the threshold 694 percentage for both upward and downward trend. If the operator would 695 like to use a different adjustment threshold percentage during the 696 downward trend, the Down-Adjustment-Threshold-Percentage sub-TLV is 697 included. It is worth noting that regardless of how the threshold 698 are set, the adjustment will not be made until at least one sample- 699 interval simply because no sample will be made on which to base a 700 comparison with a threshold. 702 5.2.3.1. Adjustment-Threshold sub-TLV 703 The Adjustment-Threshold sub-TLV is used to decide when the LSP 704 bandwidth should be adjusted in upward or downward direction. This 705 sub-TLV specify the absolute value for Up-Adjustment-Threshold and 706 Down-Adjustment-Threshold when they are the same and the Down- 707 Adjustment-Threshold sub-TLV is not included. 709 0 1 2 3 710 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 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Type=4 | Length=4 | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Adjustment-Threshold | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 Adjustment-Threshold sub-TLV format 719 The Type is 4, Length is 4 octets, and the value comprises of - 721 o Adjustment-Threshold: The absolute Adjustment-Threshold bandwidth 722 difference value, encoded in IEEE floating point format (see 723 [IEEE.754.1985]), expressed in bytes per second. The default 724 adjustment-threshold value is not set. Refer to Section 3.1.2 of 725 [RFC3471] for a table of commonly used values. 727 If the modulus of difference between the current MaxAvgBw and the 728 current bandwidth reservation is greater than or equal to the 729 threshold value, the LSP bandwidth is adjusted to the current 730 bandwidth demand (MaxAvgBw). 732 In case of an invalid value, the Sub-TLV MUST be ignored and the 733 previous value is maintained. 735 5.2.3.2. Adjustment-Threshold-Percentage sub-TLV 737 The Adjustment-Threshold-Percentage sub-TLV is used to decide when 738 the LSP bandwidth should be adjusted in upward or downward direction. 739 This sub-TLV specify the percentage value for Up-Adjustment-Threshold 740 and Down-Adjustment-Threshold when they are the same and the Down- 741 Adjustment-Threshold-Percentage sub-TLV is not included. 743 0 1 2 3 744 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 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Type=5 | Length=8 | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Reserved | Percentage | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | Minimum-Threshold | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 Adjustment-Threshold-Percentage sub-TLV format 755 The Type is 5, Length is 8 octets, and the value comprises of - 757 o Reserved: MUST be set to zero on transmission and MUST be ignored 758 on receipt. 760 o Percentage: The Adjustment-Threshold value (7 bits), encoded in 761 percentage (an integer from 1 to 100). The value 0 is considered 762 to be invalid. The default value is 5 percent. 764 o Minimum-Threshold: The absolute Minimum-Threshold bandwidth value, 765 encoded in IEEE floating point format (see [IEEE.754.1985]), 766 expressed in bytes per second. The increase or decrease of the 767 LSP bandwidth MUST be at least or above the minimum-threshold 768 before the bandwidth adjustment is made. The default value is 0. 770 If the percentage absolute difference between the current MaxAvgBw 771 and the current bandwidth reservation is greater than or equal to the 772 threshold percentage, and the difference in the bandwidth is at least 773 or above the Minimum-Threshold, the LSP bandwidth is adjusted to the 774 current bandwidth demand (MaxAvgBw). 776 In case of an invalid value, the Sub-TLV MUST be ignored and the 777 previous value is maintained. 779 5.2.3.3. Down-Adjustment-Threshold sub-TLV 781 The Down-Adjustment-Threshold sub-TLV is used to decide when the LSP 782 bandwidth should be adjusted when MaxAvgBw is lesser than the current 783 bandwidth reservation. This parameter overrides the Adjustment- 784 Threshold for the downward trend. This sub-TLV is used only when 785 there is a need for different threshold in the upward and downward 786 directions. 788 0 1 2 3 789 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 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Type=6 | Length=4 | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | Down-Adjustment-Threshold | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 Down-Adjustment-Threshold sub-TLV format 798 The Type is 6, Length is 4 octets, and the value comprises of - 799 o Down-Adjustment-Threshold: The absolute Down-Adjustment-Threshold 800 bandwidth value, encoded in IEEE floating point format (see 801 [IEEE.754.1985]), expressed in bytes per second. The default 802 value equals the adjustment-threshold. Refer to Section 3.1.2 of 803 [RFC3471] for a table of commonly used values. 805 If the difference between current bandwidth reservation and the 806 current MaxAvgBw is greater than or equal to the threshold value, the 807 LSP bandwidth is adjusted to the current bandwidth demand (MaxAvgBw). 809 In case of an invalid value, the Sub-TLV MUST be ignored and the 810 previous value is maintained. 812 5.2.3.4. Down-Adjustment-Threshold-Percentage sub-TLV 814 The Down-Adjustment-Threshold-Percentage sub-TLV is used to decide 815 when the LSP bandwidth should be adjusted when MaxAvgBw is lesser 816 than the current bandwidth reservation. This parameter overrides the 817 Adjustment-Threshold-Percentage for the downward trend. This sub-TLV 818 is used only when there is a need for different threshold percentage 819 in the upward and downward directions. 821 0 1 2 3 822 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 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | Type=7 | Length=8 | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | Reserved | Percentage | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Minimum-Threshold | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 Down-Adjustment-Threshold-Percentage sub-TLV format 833 The Type is 7, Length is 8 octets, and the value comprises of - 835 o Reserved: MUST be set to zero on transmission and MUST be ignored 836 on receipt. 838 o Percentage: The Down-Adjustment-Threshold value (7 bits), encoded 839 in percentage (an integer from 1 to 100). The value 0 is 840 considered to be invalid. The default value equals the 841 adjustment-threshold-percentage. 843 o Minimum-Threshold: The absolute Minimum-Threshold bandwidth value, 844 encoded in IEEE floating point format (see [IEEE.754.1985]), 845 expressed in bytes per second. The decrease of the LSP bandwidth 846 MUST be at least or above the minimum-threshold before the 847 bandwidth adjustment is made. The default value equals the 848 minimum-threshold for the adjustment-threshold-percentage. 850 If the percentage difference between the current bandwidth 851 reservation and the current MaxAvgBw is greater than or equal to the 852 threshold percentage, and the difference in the bandwidth is at least 853 or above the Minimum-Threshold, the LSP bandwidth is adjusted to the 854 current bandwidth demand (MaxAvgBw). 856 In case of an invalid value, the Sub-TLV MUST be ignored and the 857 previous value is maintained. 859 5.2.4. Minimum and Maximum Bandwidth Values 861 5.2.4.1. Minimum-Bandwidth sub-TLV 863 The Minimum-Bandwidth sub-TLV specify the minimum bandwidth allowed 864 for the LSP, and is expressed in bytes per second. The LSP bandwidth 865 cannot be adjusted below the minimum bandwidth value. 867 0 1 2 3 868 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 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Type=8 | Length=4 | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Minimum-Bandwidth | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 Minimum-Bandwidth sub-TLV format 877 The Type is 8, Length is 4 octets, and the value comprises of - 879 o Minimum-Bandwidth: The 4-octet bandwidth value encoded in IEEE 880 floating point format (see [IEEE.754.1985]), expressed in bytes 881 per second. The default minimum-bandwidth value is set to 0. 882 Refer to Section 3.1.2 of [RFC3471] for a table of commonly used 883 values. 885 In case of an invalid value, the Sub-TLV MUST be ignored and the 886 previous value is maintained. 888 5.2.4.2. Maximum-Bandwidth sub-TLV 890 The Maximum-Bandwidth sub-TLV specify the maximum bandwidth allowed 891 for the LSP, and is expressed in bytes per second. The LSP bandwidth 892 cannot be adjusted above the maximum bandwidth value. 894 0 1 2 3 895 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 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Type=9 | Length=4 | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Maximum-Bandwidth | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 Maximum-Bandwidth sub-TLV format 904 The Type is 9, Length is 4 octets, and the value comprises of - 906 o Maximum-Bandwidth: The 4-octet bandwidth value encoded in IEEE 907 floating point format (see [IEEE.754.1985]), expressed in bytes 908 per second. The default maximum-bandwidth value is not set. 909 Refer to Section 3.1.2 of [RFC3471] for a table of commonly used 910 values. 912 In case of an invalid value, the Sub-TLV MUST be ignored and the 913 previous value is maintained. 915 5.2.5. Overflow and Underflow Conditions 917 The sub-TLVs in this section are encoded to inform the PCEP peer the 918 overflow and underflow threshold parameters. An implementation MAY 919 include sub-TLVs for an absolute value and/or a percentage for the 920 threshold, in which case the bandwidth is immediately adjusted when 921 either of the threshold conditions is met consecutively for the given 922 count (as long as the difference in the bandwidth is at least or 923 above the Minimum-Threshold). By default, the threshold values for 924 overflow and underflow conditions are not set. 926 5.2.5.1. Overflow-Threshold sub-TLV 928 The Overflow-Threshold sub-TLV is used to decide if the LSP bandwidth 929 should be adjusted immediately. 931 0 1 2 3 932 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 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Type=10 | Length=8 | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | Reserved | Count | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Overflow-Threshold | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 Overflow-Threshold sub-TLV format 943 The Type is 10, Length is 8 octets, and the value comprises of - 945 o Reserved: MUST be set to zero on transmission and MUST be ignored 946 on receipt. 948 o Count: The Overflow-Count value (5 bits), encoded in integer. The 949 value 0 is considered to be invalid. The number of consecutive 950 samples for which the overflow condition MUST be met for the LSP 951 bandwidth to be immediately adjusted to the current bandwidth 952 demand, bypassing the (up) adjustment-interval. 954 o Overflow-Threshold: The absolute Overflow-Threshold bandwidth 955 value, encoded in IEEE floating point format (see 956 [IEEE.754.1985]), expressed in bytes per second. Refer to Section 957 3.1.2 of [RFC3471] for a table of commonly used values. If the 958 difference of the current MaxAvgBw from the current bandwidth 959 reservation is greater than or equal to the threshold value, the 960 overflow condition is met. 962 In case of an invalid value, the Sub-TLV MUST be ignored and the 963 previous value is maintained. 965 5.2.5.2. Overflow-Threshold-Percentage sub-TLV 967 The Overflow-Threshold-Percentage sub-TLV is used to decide if the 968 LSP bandwidth should be adjusted immediately. 970 0 1 2 3 971 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 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Type=11 | Length=8 | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | Percentage | Reserved | Count | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | Minimum-Threshold | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 Overflow-Threshold-Percentage sub-TLV format 982 The Type is 11, Length is 8 octets, and the value comprises of - 984 o Percentage: The Overflow-Threshold value (7 bits), encoded in 985 percentage (an integer from 1 to 100). The value 0 is considered 986 to be invalid. If the percentage increase of the current MaxAvgBw 987 from the current bandwidth reservation is greater than or equal to 988 the threshold percentage, the overflow condition is met. 990 o Reserved: MUST be set to zero on transmission and MUST be ignored 991 on receipt. 993 o Count: The Overflow-Count value (5 bits), encoded in integer. The 994 value 0 is considered to be invalid. The number of consecutive 995 samples for which the overflow condition MUST be met for the LSP 996 bandwidth to be immediately adjusted to the current bandwidth 997 demand, bypassing the (up) adjustment-interval. 999 o Minimum-Threshold: The absolute Minimum-Threshold bandwidth value, 1000 encoded in IEEE floating point format (see [IEEE.754.1985]), 1001 expressed in bytes per second. The increase of the LSP bandwidth 1002 MUST be at least or above the minimum-threshold before the 1003 bandwidth adjustment is made. 1005 In case of an invalid value, the Sub-TLV MUST be ignored and the 1006 previous value is maintained. 1008 5.2.5.3. Underflow-Threshold sub-TLV 1010 The Underflow-Threshold sub-TLV is used to decide if the LSP 1011 bandwidth should be adjusted immediately. 1013 0 1 2 3 1014 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 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 | Type=12 | Length=8 | 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | Reserved | Count | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | Underflow-Threshold | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 Underflow-Threshold sub-TLV format 1025 The Type is 12, Length is 8 octets, and the value comprises of - 1027 o Reserved: MUST be set to zero on transmission and MUST be ignored 1028 on receipt. 1030 o Count: The Underflow-Count value (5 bits), encoded in integer. 1031 The value 0 is considered to be invalid. The number of 1032 consecutive samples for which the underflow condition MUST be met 1033 for the LSP bandwidth to be immediately adjusted to the current 1034 bandwidth demand, bypassing the down-adjustment-interval. 1036 o Underflow-Threshold: The absolute Underflow-Threshold bandwidth 1037 value, encoded in IEEE floating point format (see 1038 [IEEE.754.1985]), expressed in bytes per second. Refer to Section 1039 3.1.2 of [RFC3471] for a table of commonly used values. If the 1040 difference of the current MaxAvgBw from the current bandwidth 1041 reservation is greater than or equal to the threshold value, the 1042 underflow condition is met. 1044 In case of an invalid value, the Sub-TLV MUST be ignored and the 1045 previous value is maintained. 1047 5.2.5.4. Underflow-Threshold-Percentage sub-TLV 1049 The Underflow-Threshold-Percentage sub-TLV is used to decide if the 1050 LSP bandwidth should be adjusted immediately. 1052 0 1 2 3 1053 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 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | Type=13 | Length=8 | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | Percentage | Reserved | Count | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | Minimum-Threshold | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 Underflow-Threshold-Percentage sub-TLV format 1064 The Type is 13, Length is 8 octets, and the value comprises of - 1066 o Percentage: The Underflow-Threshold value (7 bits), encoded in 1067 percentage (an integer from 1 to 100). The value 0 is considered 1068 to be invalid. If the percentage decrease of the current MaxAvgBw 1069 from the current bandwidth reservation is greater than or equal to 1070 the threshold percentage, the underflow condition is met. 1072 o Reserved: MUST be set to zero on transmission and MUST be ignored 1073 on receipt. 1075 o Count: The Underflow-Count value (5 bits), encoded in integer. 1076 The value 0 is considered to be invalid. The number of 1077 consecutive samples for which the underflow condition MUST be met 1078 for the LSP bandwidth to be immediately adjusted to the current 1079 bandwidth demand, bypassing the down-adjustment-interval. 1081 o Minimum-Threshold: The absolute Minimum-Threshold bandwidth value, 1082 encoded in IEEE floating point format (see [IEEE.754.1985]), 1083 expressed in bytes per second. The decrease of the LSP bandwidth 1084 MUST be at least or above the minimum-threshold before the 1085 bandwidth adjustment is made. 1087 In case of an invalid value, the Sub-TLV MUST be ignored and the 1088 previous value is maintained. 1090 5.3. BANDWIDTH Object 1092 As per [RFC5440], the BANDWIDTH object (Object-Class value 5) is 1093 defined with two Object-Type values as following: 1095 o Requested Bandwidth: BANDWIDTH Object-Type value is 1. 1097 o Re-optimization Bandwidth: Bandwidth of an existing TE LSP for 1098 which a re-optimization is requested. BANDWIDTH Object-Type value 1099 is 2. 1101 The PCC reports the calculated bandwidth to be adjusted (MaxAvgBw) to 1102 the Stateful PCE using the existing 'Requested Bandwidth' with 1103 BANDWIDTH Object-Type as 1. The reporting of the 're-optimization 1104 bandwidth' with BANDWIDTH Object-Type as 2 is not required as the 1105 Stateful PCE is aware of the existing LSP bandwidth. 1107 5.4. The PCInitiate Message 1109 A PCInitiate message is a PCEP message sent by a PCE to a PCC to 1110 trigger LSP instantiation or deletion [RFC8281]. 1112 For the PCE-Initiated LSP with Auto-Bandwidth feature enabled, AUTO- 1113 BANDWIDTH-ATTRIBUTES TLV MUST be included in the LSPA object with the 1114 PCInitiate message. 1116 The Routing Backus-Naur Format (RBNF) definition of the PCInitiate 1117 message [RFC8281] is unchanged by this document. 1119 5.5. The PCUpd Message 1121 A PCUpd message is a PCEP message sent by a PCE to a PCC to update 1122 the LSP parameters [RFC8231]. 1124 For PCE-Initiated LSPs with Auto-Bandwidth feature enabled, AUTO- 1125 BANDWIDTH-ATTRIBUTES TLV MUST be included in the LSPA object with the 1126 PCUpd message. The PCE can send this TLV to direct the PCC to change 1127 the auto-bandwidth parameters. 1129 The RBNF definition of the PCUpd message [RFC8231] is unchanged by 1130 this document. 1132 5.6. The PCRpt Message 1134 The PCRpt message [RFC8231] is a PCEP message sent by a PCC to a PCE 1135 to report the status of one or more LSPs. 1137 For PCE-Initiated LSPs [RFC8281], the PCC creates the LSP using the 1138 attributes communicated by the PCE, and using the local values for 1139 the unspecified parameters. After the successful instantiation of 1140 the LSP, PCC automatically delegates the LSP to the PCE and generates 1141 a PCRpt message to provide the status report for the LSP. 1143 For both PCE-Initiated and PCC-Initiated LSPs, when the LSP is 1144 delegated to a PCE for the very first time as well as after the 1145 successful delegation, the BANDWIDTH object of type 1 is used to 1146 specify the requested bandwidth in the PCRpt message. 1148 The RBNF definition of the PCRpt message [RFC8231] is unchanged by 1149 this document. 1151 5.7. The PCNtf Message 1153 As per [RFC5440], the PCEP Notification message (PCNtf) can be sent 1154 by a PCEP speaker to notify its peer of a specific event. 1156 A PCEP speaker (PCE or PCC) SHOULD notify its PCEP peer (PCC or PCE) 1157 when it is in overwhelmed state due to the auto-bandwidth feature. 1158 An implementation needs to make an attempt to send this notification 1159 (when overwhelmed by auto-bandwidth adjustments) unless sending this 1160 notification would only serve to increase the load further. Note that 1161 when the notification is not received the PCEP speaker would continue 1162 to request bandwidth adjustments even when they could not be handled 1163 in a timely fashion. 1165 Upon receipt of auto-bandwidth overwhelm notification, the peer 1166 SHOULD NOT send any PCEP messages related to auto-bandwidth 1167 adjustment. If a PCEP message related to auto-bandwidth adjustment 1168 is received during in overwhelmed state, it MUST be ignored. 1170 o When a PCEP speaker is overwhelmed, it SHOULD notify its peer by 1171 sending a PCNtf message with Notification-Type = TBD3 (Auto- 1172 bandwidth Overwhelm State) and Notification-Value = 1 (Entering 1173 auto-bandwidth overwhelm state). Optionally, OVERLOADED-DURATION 1174 TLV [RFC5440] MAY be included that specifies the time period 1175 during which no further PCEP messages related to auto-bandwidth 1176 adjustment should be sent. 1178 o When the PCEP speaker is no longer in the overwhelm state and is 1179 available to process the auto-bandwidth adjustments, it SHOULD 1180 notify its peers by sending a PCNtf message with Notification Type 1181 = TBD3 (Auto-bandwidth Overwhelm State) and Notification Value = 2 1182 (Clearing auto-bandwidth overwhelm state). A PCEP speaker SHOULD 1183 send such notification to all peers to with a Notification message 1184 (Notification-Type=TBD3, Notification-Value=1) was sent earlier 1185 unless an OVERLOADED-DURATION TLV was included and the PCEP 1186 speakers wishes for the peer to wait for the expiration of that 1187 period of time before receiving further PCEP messages related to 1188 auto-bandwidth adjustment. 1190 When Auto-Bandwidth feature is deployed, a PCE can send this 1191 notification to PCC when a PCC is reporting frequent auto-bandwidth 1192 adjustments. If a PCC is overwhelmed with re-signaling, it can also 1193 notify the PCE to not adjust the LSP bandwidth while in overwhelm 1194 state. 1196 Some dampening notification procedure (as per [RFC5440]) to avoid 1197 oscillations of the overwhelm state is RECOMMENDED. On receipt of an 1198 auto-bandwidth overwhelm notification from the PCE, a PCC should 1199 consider the impact on the entire network. Moving the delegations of 1200 auto-bandwidth enabled LSP to another PCE could cause further 1201 overloading. 1203 6. Manageability Considerations 1205 6.1. Control of Function and Policy 1207 The Auto-Bandwidth feature SHOULD be controlled per LSP (at PCC 1208 (head-end of the LSP) or PCE) and the values for auto-bandwidth 1209 parameters e.g. sample-interval, adjustment-interval (up/down), 1210 minimum-bandwidth, maximum-bandwidth, adjustment-threshold (up/down) 1211 SHOULD be configurable by an operator. 1213 The Maximum-Bandwidth (and Minimum-Bandwidth) should be set to 1214 acceptable limit to avoid impact on the rest of the MPLS-TE domain. 1216 The operator should make sure that the Overflow-Threshold is greater 1217 than or at least equal to the Up-Adjustment-Threshold. And similarly, 1218 make sure that the Underflow-Threshold is greater than or at least 1219 equal to the Down-Adjustment-Threshold. 1221 6.2. Information and Data Models 1223 A MIB module for gathering operational information about PCEP is 1224 defined in [RFC7420]. Additionally, the YANG module defined in 1225 [I-D.ietf-pce-pcep-yang] provides for both configuration of PCEP as 1226 well as operational management. These could be enhanced to provide 1227 controls and indicators for support of auto-bandwidth feature. 1228 Support for various configuration knobs as well as counters of 1229 messages sent/received containing the TLVs defined in this document 1230 could be added. 1232 6.3. Liveness Detection and Monitoring 1234 The mechanisms defined in this document do not imply any new liveness 1235 detection and monitoring requirements in addition to those already 1236 listed in [RFC5440]. 1238 6.4. Verify Correct Operations 1240 The mechanisms defined in this document do not imply any new 1241 operation verification requirements in addition to those already 1242 listed in [RFC5440]. 1244 In case of an invalid value, the Sub-TLV would get ignored and the 1245 previous value would be maintained. In such case the implementation 1246 SHOULD log the event. 1248 6.5. Requirements On Other Protocols 1250 The mechanisms defined in this document do not add any new 1251 requirements on other protocols. 1253 6.6. Impact On Network Operations 1255 In order to avoid any unacceptable impact on network operations, an 1256 implementation SHOULD allow a limit to be placed on the number of 1257 LSPs that can be enabled with auto-bandwidth feature. For each LSP 1258 enabled with auto-bandwidth feature there is an extra load on PCC, as 1259 it needs to monitor the traffic and report the calculated bandwidth 1260 to be adjusted to the PCE. The PCE further re-compute paths based on 1261 the requested bandwidth and update the path to the PCC, which in 1262 turns triggers the re-signaling of the path. All these steps adds 1263 extra load and churn in the network and thus operator needs to take 1264 due care while enabling this features on a number of LSPs. 1266 An implementation MAY allow a limit to be placed on the rate of auto- 1267 bandwidth related messages sent by a PCEP speaker and received by a 1268 peer. An implementation SHOULD also allow sending a notification 1269 when a PCEP speaker is overwhelmed or the rate of messages reach a 1270 threshold. 1272 Due care is required by the operator if a Sample-Interval value 1273 significantly smaller than the default (5 minute) is used, as a small 1274 Sample-Interval values, e.g., 1 minute or less, could cause 1275 undesirable interactions with transport protocols. These undesirable 1276 interactions result from providing insufficient time for transport 1277 protocol reactions to a prior bandwidth adjustment to settle out 1278 before bandwidth samples are taken for the next bandwidth adjustment. 1280 7. Security Considerations 1282 This document defines AUTO-BANDWIDTH-CAPABILITY TLV and AUTO- 1283 BANDWIDTH-ATTRIBUTES sub-TLVs which do not add any substantial new 1284 security concerns beyond those already discussed in [RFC8231] and 1285 [RFC8281] for stateful PCE operations. As per [RFC8231], it is 1286 RECOMMENDED that these PCEP extensions only be activated on 1287 authenticated and encrypted sessions across PCEs and PCCs belonging 1288 to the same administrative authority, using Transport Layer Security 1289 (TLS) [RFC8253], as per the recommendations and best current 1290 practices in BCP 195 [RFC7525] (unless explicitly set aside in 1291 [RFC8253]). 1293 Incorrect auto-bandwidth parameters in the AUTO-BANDWIDTH-ATTRIBUTES 1294 sub-TLVs could have an adverse effect on the LSP as well as on the 1295 network. 1297 8. IANA Considerations 1299 8.1. PCEP TLV Type Indicators 1301 This document defines the following new PCEP TLVs; IANA is requested 1302 to make the following allocations from the "PCEP TLV Type Indicators" 1303 sub-registry of the PCEP Numbers registry, as follows: 1305 Value Name Reference 1306 ----------------------------------------------------------------- 1307 TBD2 AUTO-BANDWIDTH-CAPABILITY [This document] 1308 TBD1 AUTO-BANDWIDTH-ATTRIBUTES [This document] 1310 8.2. AUTO-BANDWIDTH-CAPABILITY TLV Flag Field 1312 IANA is requested to create a sub-registry to manage the Flag field 1313 of the AUTO-BANDWIDTH-CAPABILITY TLV within the "Path Computation 1314 Element Protocol (PCEP) Numbers" registry. 1316 New bit numbers are to be assigned by Standards Action [RFC8126]. 1317 Each bit should be tracked with the following qualities: 1319 o Bit number (counting from bit 0 as the most significant bit) 1321 o Capability description 1323 o Defining RFC 1325 The initial contents of the sub-registry are empty, with all bits 1326 marked unassigned 1328 8.3. AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV 1330 This document specifies the AUTO-BANDWIDTH-ATTRIBUTES Sub-TLVs. IANA 1331 is requested to create an "AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV Types" 1332 sub-registry within the "Path Computation Element Protocol (PCEP) 1333 Numbers" registry to manage the type indicator space for sub-TLVs of 1334 the AUTO-BANDWIDTH-ATTRIBUTES TLV. The valid range of values in the 1335 registry is 0-65535. IANA is requested to initialize the registry 1336 with the following values. All other values in the registry should 1337 be marked as "Unassigned". 1339 IANA is requested to set the registration procedure for this registry 1340 to read as follows: 1342 0-65503 IETF Review 1343 65504-65535 Experimental Use 1345 This document defines the following types: 1347 Type Name Reference 1348 ----------------------------------------------------------------- 1349 0 Reserved [This document] 1350 1 Sample-Interval sub-TLV [This document] 1351 2 Adjustment-Interval sub-TLV [This document] 1352 3 Down-Adjustment-Interval sub-TLV [This document] 1353 4 Adjustment-Threshold sub-TLV [This document] 1354 5 Adjustment-Threshold-Percentage sub-TLV [This document] 1355 6 Down-Adjustment-Threshold sub-TLV [This document] 1356 7 Down-Adjustment-Threshold-Percentage sub-TLV [This document] 1357 8 Minimum-Bandwidth sub-TLV [This document] 1358 9 Maximum-Bandwidth sub-TLV [This document] 1359 10 Overflow-Threshold sub-TLV [This document] 1360 11 Overflow-Threshold-Percentage sub-TLV [This document] 1361 12 Underflow-Threshold sub-TLV [This document] 1362 13 Underflow-Threshold-Percentage sub-TLV [This document] 1363 14- Unassigned [This document] 1364 65503 1366 8.4. Error Object 1368 This document defines a new Error-Value for PCErr message of Error- 1369 Type 19 (Invalid Operation) [RFC8231]. IANA is requested to allocate 1370 new error-value within the "PCEP-ERROR Object Error Types and Values" 1371 subregistry of the PCEP Numbers registry, as follows: 1373 Error-Type Meaning & error values Reference 1374 ----------------------------------------------------------------- 1375 19 Invalid Operations 1377 Error-Value = TBD4: [This document] 1378 Auto-Bandwidth Capability 1379 was not Advertised 1381 8.5. Notification Object 1383 IANA is requested to allocate new Notification Type and Notification 1384 Values within the "Notification Object" sub-registry of the PCEP 1385 Numbers registry, as follows: 1387 Type Meaning Reference 1388 ----------------------------------------------------------------- 1389 TBD3 Auto-Bandwidth Overwhelm State [This document] 1391 Notification-value=1: Entering Auto-Bandwidth 1392 overwhelm state 1393 Notification-value=2: Clearing Auto-Bandwidth 1394 overwhelm state 1396 9. References 1398 9.1. Normative References 1400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1401 Requirement Levels", BCP 14, RFC 2119, March 1997. 1403 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 1404 (PCE) Communication Protocol (PCEP)", RFC 5440, March 1405 2009. 1407 [RFC7525] Sheffer, Y., Holz, R. and P. Saint-Andre, "Recommendations 1408 for Secure Use of Transport Layer Security (TLS) and 1409 Datagram Transport Layer Security (DTLS)", BCP 195, RFC 1410 7525, DOI 10.17487/RFC7525, May 2015. 1412 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1413 Writing an IANA Considerations Section in RFCs", BCP 26, 1414 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1415 . 1417 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1418 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1419 May 2017, . 1421 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Pah 1422 Computation Element Communication Protocol (PCEP) 1423 Extensions for Stateful PCE", RFC 8231, DOI 1424 10.17487/RFC8231, September 2017, 1425 . 1427 [RFC8253] Lopez, D., Dios, O., Wu, W., and D. Dhody, "PCEPS: Usage 1428 of TLS to Provide a Secure Transport for the Path 1429 Computation Element Communication Protocol (PCEP)", RFC 1430 8253, October 2017, 1431 . 1433 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1434 Computation Element Communication Protocol (PCEP) 1435 Extensions for PCE-Initiated LSP Setup in a Stateful PCE, 1436 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1437 . 1439 [IEEE.754.1985] Institute of Electrical and Electronics Engineers, 1440 "Standard for Binary Floating-Point Arithmetic", IEEE 1441 Standard 754, August 1985. 1443 9.2. Informative References 1445 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1446 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1447 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1448 . 1450 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1451 (GMPLS) Signaling Functional Description", RFC 3471, 1452 January 2003. 1454 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1455 Hardwick, "Path Computation Element Communication Protocol 1456 (PCEP) Management Information Base (MIB) Module", RFC 1457 7420, December 2014. 1459 [RFC8051] Zhang, X. and I. Minei, "Applicability of a Stateful Path 1460 Computation Element (PCE)", RFC 8051, January 2017. 1462 [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. 1463 Tantsura, "A YANG Data Model for Path Computation Element 1464 Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang 1465 (work in progress). 1467 Acknowledgments 1469 Authors would like to thank Robert Varga, Venugopal Reddy, Reeja 1470 Paul, Sandeep Boina, Avantika, JP Vasseur, Himanshu Shah, Jonathan 1471 Hardwick and Adrian Farrel for their useful comments and suggestions. 1473 Thanks to Daniel Franke, Joe Clarke, David Black, and Erik Kline for 1474 the directorate reviews. 1476 Thanks to Mirja Kuhlewind, Barry Leiba, Benjamin Kaduk, and Roman 1477 Danyliw for the IESG review. 1479 Contributors' Addresses 1481 He Zekun 1482 Tencent Holdings Ltd, 1483 Shenzhen P.R.China 1485 Email: kinghe@tencent.com 1487 Xian Zhang 1488 Huawei Technologies 1489 Research Area F3-1B, 1490 Huawei Industrial Base, 1491 Shenzhen, 518129 1492 China 1494 Phone: +86-755-28972645 1495 Email: zhang.xian@huawei.com 1497 Young Lee 1498 SKKU 1500 Email: younglee.tx@gmail.com 1502 Authors' Addresses 1504 Dhruv Dhody (editor) 1505 Huawei Technologies 1506 Divyashree Techno Park, Whitefield 1507 Bangalore, Karnataka 560066 1508 India 1510 Email: dhruv.ietf@gmail.com 1512 Rakesh Gandhi (editor) 1513 Cisco Systems, Inc. 1514 Canada 1516 Email: rgandhi@cisco.com 1518 Udayasree Palle 1519 Individual Contributor 1521 Email: udayasreereddy@gmail.com 1523 Ravi Singh 1524 Individual Contributor 1526 Email: ravi.singh.ietf@gmail.com 1528 Luyuan Fang 1529 Expedia, Inc. 1530 USA 1532 Email: luyuanf@gmail.com