RFC 8733
Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE
RFC 8733 ✨ PCEP Auto-Bandwidth Adjustment for Stateful PCE 🦋
Okay bestie, the title block is giving a lot of authors 💅 This is an IETF Standards Track document, so it's the real deal, not an experimental side quest. It was published in February 2020 and its ISSN is 2070-1721. It doesn't obsolete or update any other RFC.
The editors are D. Dhody (Ed.) from Huawei Technologies and R. Gandhi (Ed.) from Cisco Systems, Inc. The other contributors are U. Palle, R. Singh (an Individual Contributor), and L. Fang from Expedia Group, Inc. The whole crew is iconic 🫶
The title is "Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE" 🌈
Abstract 🌸
Okay so PCEP gives Path Computation Elements (PCEs) a way to do path computations when a Path Computation Client (PCC) asks for one 💖 Stateful PCE extensions let you control MPLS-TE Label Switched Paths (LSPs) through PCEP, which is so powerful 😭
Auto-bandwidth is the feature where the bandwidth reserved for a TE LSP changes automatically and dynamically based on how much traffic is actually flowing through it ✨ This document defines PCEP extensions for auto-bandwidth adjustment when there's an active stateful PCE, for both PCE-initiated and PCC-initiated LSPs. Main character energy 👑
Status of This Memo 🎀
This is an Internet Standards Track document 🔥
It's a product of the IETF, it represents IETF community consensus, and it got public review and was approved for publication by the IESG. If you want more on Internet Standards, check Section 2 of RFC 7841 🧚
Info about the current status, errata, and how to give feedback lives at https://www.rfc-editor.org/info/rfc8733 🍓
Copyright Notice 💜
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved 🌈
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License 🦋
Table of Contents 🌸
1. Introduction
2. Conventions Used in This Document
2.1. Requirements Language
2.2. Abbreviations
2.3. Terminology
3. Requirements for PCEP Extensions
4. Architectural Overview
4.1. Auto-Bandwidth Overview
4.2. Auto-Bandwidth Theory of Operation
4.3. Scaling Considerations
5. PCEP Extensions
5.1. Capability Advertisement
5.1.1. AUTO-BANDWIDTH-CAPABILITY TLV
5.2. AUTO-BANDWIDTH-ATTRIBUTES TLV
5.2.1. Sample-Interval Sub-TLV
5.2.2. Adjustment-Intervals
5.2.2.1. Adjustment-Interval Sub-TLV
5.2.2.2. Down-Adjustment-Interval Sub-TLV
5.2.3. Adjustment-Thresholds
5.2.3.1. Adjustment-Threshold Sub-TLV
5.2.3.2. Adjustment-Threshold-Percentage Sub-TLV
5.2.3.3. Down-Adjustment-Threshold Sub-TLV
5.2.3.4. Down-Adjustment-Threshold-Percentage Sub-TLV
5.2.4. Minimum and Maximum-Bandwidth Values
5.2.4.1. Minimum-Bandwidth Sub-TLV
5.2.4.2. Maximum-Bandwidth Sub-TLV
5.2.5. Overflow and Underflow Conditions
5.2.5.1. Overflow-Threshold Sub-TLV
5.2.5.2. Overflow-Threshold-Percentage Sub-TLV
5.2.5.3. Underflow-Threshold Sub-TLV
5.2.5.4. Underflow-Threshold-Percentage Sub-TLV
5.3. BANDWIDTH Object
5.4. The PCInitiate Message
5.5. The PCUpd Message
5.6. The PCRpt Message
5.7. The PCNtf Message
6. Manageability Considerations
6.1. Control of Function and Policy
6.2. Information and Data Models
6.3. Liveness Detection and Monitoring
6.4. Verifying Correct Operations
6.5. Requirements for Other Protocols
6.6. Impact on Network Operations
7. Security Considerations
8. IANA Considerations
8.1. PCEP TLV Type Indicators
8.2. AUTO-BANDWIDTH-CAPABILITY TLV Flag Field
8.3. AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV
8.4. Error Object
8.5. Notification Object
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Contributors
Authors' Addresses1. Introduction 🌷
Okay so [RFC5440] describes PCEP as the communication mechanism between a PCC and a PCE (or between a PCE and another PCE) that lets you compute MPLS-TE LSPs 💖
[RFC8231] adds stateful control of MPLS-TE LSPs through PCEP. It describes two modes: passive stateful PCE and active stateful PCE 🦋 Then [RFC8281] covers setting up, maintaining, and tearing down PCE-initiated LSPs for the stateful PCE model. This document is all about the active stateful PCE, where the PCE controls the LSPs 👑
Here's the thing. Traffic patterns change over time, so an LSP that was set up with a certain bandwidth may need its reserved bandwidth adjusted on the fly ✨ The head-end Label Switching Router (LSR) watches how much bandwidth the LSP actually uses, periodically works out a new bandwidth, and automatically adjusts the LSP's reservation to match. When an implementation supports this, people call it auto-bandwidth 🔥 Section 4 of this document goes into the details.
In the model here, the PCC (the head-end of the LSP) collects traffic rate samples for the LSP and calculates the new Adjusted Bandwidth, then reports it to the PCE 🌈 This is kind of like the passive stateful PCE model, except passive uses a path request/reply mechanism while active uses a report/update mechanism 🫶 For a PCE-initiated LSP, the PCC is asked during LSP initiation to monitor and calculate the new Adjusted Bandwidth. [RFC8051] describes the use case for auto-bandwidth adjustment with both passive and active stateful PCEs 💅
Sending the measured values themselves to the PCE is another approach, but it's out of scope for this document 🙈
So this document defines the PCEP extensions needed for auto-bandwidth in an active stateful PCE model where the bandwidth is calculated on the PCC (head-end of the LSP) 💖 Using the PCE to calculate the bandwidth is out of scope too 🧚
2. Conventions Used in This Document 🎀
2.1. Requirements Language 💜
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🔥
2.2. Abbreviations 🌸
PCC: Path Computation Client
PCE: Path Computation Element
PCEP: Path Computation Element Communication Protocol
TE: Traffic Engineering
LSP: Label Switched PathPart 1 of 8. More parts are coming, so stay tuned bestie 🦋💖
2.3. Terminology 🎀
okay so bestie, you need to be familiar with the terms defined in [RFC5440], [RFC8231], and [RFC8281] before this makes sense 📚✨ no cap, go read those first if you haven't.
In this document, the PCC is considered to be the head-end LSR of the LSP 🦋. Other types of PCCs are not in scope, so we're not going there today 💅
The following auto-bandwidth terminology is defined in this document 🌸
Maximum Average Bandwidth (MaxAvgBw): this is the traffic bandwidth the LSP is measured to be demanding right now, over a time interval 📈. It's the biggest value among the traffic bandwidth rate samples (Bandwidth-Samples) taken in that interval. Iconic stat, honestly 👑
Adjusted Bandwidth: this is the auto-bandwidth computed number that gets used to adjust the LSP's bandwidth reservation 🧮
Sample-Interval: the regular time gap at which the LSP's measured traffic rate gets collected as a Bandwidth-Sample ⏱️
Bandwidth-Sample: a single measured traffic rate snapshot of the LSP, collected every Sample-Interval 📸
Maximum-Bandwidth: the most bandwidth that can be reserved for the LSP 🔝
Minimum-Bandwidth: the least bandwidth that can be reserved for the LSP 🔻
Up-Adjustment-Interval: the regular time interval at which a bandwidth adjustment should be made using the MaxAvgBw, but only when MaxAvgBw is greater than the LSP's current bandwidth reservation 🚀
Down-Adjustment-Interval: the regular time interval at which a bandwidth adjustment should be made using the MaxAvgBw, but only when MaxAvgBw is less than the LSP's current bandwidth reservation 🐢
Up-Adjustment-Threshold: this one decides when the LSP bandwidth should be adjusted 🎯. If the percentage or absolute difference between the current MaxAvgBw and the current bandwidth reservation is greater than or equal to the threshold value, the LSP bandwidth gets upsized to the current bandwidth demand (Adjusted Bandwidth) when the Up-Adjustment-Interval expires 💖
Down-Adjustment-Threshold: same energy, but flipped 🙃. If the percentage or absolute difference between the current bandwidth reservation and the current MaxAvgBw is greater than or equal to the threshold value, the LSP bandwidth gets downsized to the current bandwidth demand (Adjusted Bandwidth) when the Down-Adjustment-Interval expires 🍃
Overflow-Count: this one handles sudden spikes in traffic demand 📣. It's how many times in a row the percentage or absolute difference between the current MaxAvgBw and the current bandwidth reservation of the LSP has to be greater than or equal to the Overflow-Threshold value before the overflow condition is met 🔥
Overflow-Threshold: also for sudden spikes 💥. If the percentage or absolute difference between the current MaxAvgBw and the current bandwidth reservation of the LSP is greater than or equal to the threshold value, the overflow condition is said to be met. The LSP bandwidth is then adjusted to the current bandwidth demand, skipping the Up-Adjustment-Interval if the overflow condition is met consecutively for the Overflow-Count 🏃♀️💨. The Overflow-Threshold needs to be greater than or equal to the Up-Adjustment-Threshold 🧠
Underflow-Count: the sudden-drop version of Overflow-Count 📉. It indicates how many times in a row the percentage or absolute difference between the current MaxAvgBw and the current bandwidth reservation of the LSP needs to be greater than or equal to the Underflow-Threshold value in order to meet the underflow condition 🫠
Underflow-Threshold: the sudden-drop version of Overflow-Threshold 🌊. If the percentage or absolute difference between the current MaxAvgBw and the current bandwidth reservation of the LSP is greater than or equal to the threshold value, the underflow condition is said to be met. The LSP bandwidth is adjusted to the current bandwidth demand, skipping the Down-Adjustment-Interval if the underflow condition is met consecutively for the Underflow-Count 🏃♀️. The Underflow-Threshold needs to be greater than or equal to the Down-Adjustment-Threshold 💅
Minimum-Threshold: when percentage-based thresholds are being used, they come with this buddy, the Minimum-Threshold 🫶. Its job is to make sure the size of the gap between the calculated LSP bandwidth to be adjusted and the current bandwidth reservations passes a specific non-percentage-based criterion (an absolute bandwidth value) before any adjustments happen 🛑. This stops unnecessary auto-bandwidth adjustments and resignaling of the LSP at low bandwidth values, which is so relatable because nobody needs drama over tiny numbers 🙄
3. Requirements for PCEP Extensions 🌈
The PCEP extensions required for auto-bandwidth are summarized in the following table as well as in Figure 1 ✨
+-------------------------+--------------------------------------+
| PCC Initiated | PCE Initiated |
+=========================+======================================+
| PCC monitors the | At the time of initiation, the PCE |
| traffic and reports the | requests that the PCC monitor the |
| calculated bandwidth to | traffic and report the calculated |
| be adjusted to the PCE. | bandwidth to be adjusted to the PCE. |
+-------------------------+--------------------------------------+
| Extension is needed for | Extension is needed for the PCE to |
| the PCC to pass on the | pass on the adjustment parameters at |
| adjustment parameters | the time of LSP initiation. |
| at the time of LSP | |
| delegation. | |
+-------------------------+--------------------------------------+
Table 1: Requirements for Auto-Bandwidth PCEP Extensions ----------
| |
| PCE |
| |
----------
| ^
AUTO-BANDWIDTH CAPABILITY | | AUTO-BANDWIDTH CAPABILITY
| |
AUTO-BANDWIDTH ATTRIBUTES | | AUTO-BANDWIDTH ATTRIBUTES
| | (For Delegated LSPs)
| |
| | REQUESTED BANDWIDTH
v |
----------
| |
| PCC |
| |
----------
Figure 1: Overview of Auto-Bandwidth PCEP ExtensionsA PCEP speaker supporting this document must have a mechanism to advertise the auto-bandwidth adjustment capability for both PCC-initiated and PCE-initiated LSPs 📣
Auto-bandwidth deployment considerations for PCEP extensions are summarized below 👀
- It is necessary to identify and inform the PCC which LSPs have enabled the auto-bandwidth feature 🏷️ Not every LSP in every deployment wants its bandwidth tied to real-time usage 🙈. For some LSPs, keeping the bandwidth constant as set by the operator is what they prefer 💜
- In addition, an operator should be able to specify the auto-bandwidth adjustment parameters (i.e., configuration knobs) to control this feature, such as the Minimum/Maximum-Bandwidth range 🎛️ The PCC should be informed about these adjustment parameters 📬
4. Architectural Overview 🧚
4.1. Auto-Bandwidth Overview 💖
The auto-bandwidth feature allows automatic and dynamic adjustment of the reserved bandwidth of an LSP over time (i.e., without network operator intervention) to accommodate the varying traffic demand of the LSP 🦋 If the traffic flowing through the LSP is lower than the configured or current reserved bandwidth of the LSP, the extra bandwidth is being reserved needlessly and is being wasted 😭 Conversely, if the actual traffic flowing through the LSP is higher than the configured or current reserved bandwidth of the LSP, it can potentially cause congestion or packet loss in the network 💀 The initial LSP bandwidth can be set to an arbitrary value (including zero) 🎲 In practice, it can be set to an expected value based on design and planning 📐 The head-end LSR monitors the actual traffic flowing through the LSP and uses that information to adjust the bandwidth reservation of the LSP in the network 👑
Bandwidth adjustment must not cause disruption to the traffic flow carried by the LSP 🚨 One way to achieve this is to use the make-before-break signaling method [RFC3209] 🫶
4.2. Auto-Bandwidth Theory of Operation ✨
okay so this section is the general vibe check on how auto-bandwidth works 🦋 When the feature is turned on, the PCC samples the measured traffic rate every Sample-Interval, but only when it's the head-end node of the LSP 💅 An operator can configure the Sample-Interval, and the default is 5 minutes. Heads up though: a super tiny Sample-Interval can have some undesirable interactions with transport protocols (see Section 6.6) 😭
The traffic rate samples pile up over the Adjustment-Interval period (in the Up or Down direction). That period is operator-configurable too, with a default of 24 hours. The PCC in charge of working out the bandwidth to adjust can decide, depending on operator policy, to set the bandwidth to the highest traffic rate sample (MaxAvgBw) among the Bandwidth-Samples collected over that Adjustment-Interval period (in the Up or Down direction) 👑
Note that the highest sample could be higher OR lower than the current LSP bandwidth 👀 The LSP only gets upsized to the current bandwidth demand (MaxAvgBW) if the gap between that demand (MaxAvgBw) and the current bandwidth reservation is greater than or equal to the Adjustment-Threshold. The Adjustment-Threshold can be an absolute value or a percentage, it's operator-configured, and the default is 5 percent. Same energy in reverse: if the gap between the current bandwidth reservation and the current bandwidth demand (MaxAvgBw) is greater than or equal to the Down-Adjustment-Threshold (percentage or absolute value), the LSP gets downsized to the current bandwidth demand (MaxAvgBw) 🍓 Some LSPs are super chill, while others have a LOT of traffic drama, so the thresholds and intervals get tuned based on each LSP's traffic pattern 🌈
In order to avoid frequent resignaling, an operator may set a longer Adjustment-Interval value (Up and/or Down). BUT a longer Adjustment-Interval can totally mask sudden changes in an LSP's traffic demands 🙈 To fix that, the auto-bandwidth feature may force the Adjustment-Interval to expire early and adjust the LSP bandwidth for sudden bursts: an increase in traffic demand counts as an overflow condition, and a decrease counts as an underflow condition. An operator needs to configure appropriate values for the Overflow-Threshold and/or Underflow-Threshold parameters, and these do not have default values defined in this document.
All thresholds in this document could be represented as both an absolute value and a percentage, and they could be used together 🧚 This exists for cases where the LSP bandwidth reservation may get really large or really small over time. For example, an operator might use the percentage threshold for small to large bandwidth values, and absolute values for very large bandwidth values. The auto-bandwidth adjustment happens when either one of the two thresholds, the absolute or the percentage, is crossed.
When using the (adjustment/overflow/underflow) percentage thresholds, if the LSP bandwidth changes rapidly at very low values, it may trigger frequent auto-bandwidth adjustments just from crossing those percentages. That can lead to unnecessary resignaling of the LSPs in the network 💀 The fix is to set the Minimum-Threshold parameters along with the percentage thresholds. The auto-bandwidth adjustment is only made if the LSP bandwidth crosses both the percentage threshold AND the Minimum-Threshold parameters. Iconic restraint 💜
4.3. Scaling Considerations 🎀
It should be noted that any bandwidth change requires resignaling of an LSP, which can further trigger preemption of lower-priority LSPs in the network 😬 When deployed at scale, this can lead to signaling churn in the network. The auto-bandwidth application algorithm is thus advised to take this into consideration before adjusting the LSP bandwidth. Operators are advised to set the values of the various auto-bandwidth adjustment parameters appropriately for the deployed LSP scale.
If a PCE gets overwhelmed, it can notify the PCC to temporarily suspend the reporting of the new LSP bandwidth to be adjusted. Similarly, if a PCC gets overwhelmed by signaling churn, it can notify the PCE to temporarily suspend new LSP setup requests. See Section 5.7 of this document 🫶
5. PCEP Extensions 🌸
5.1. Capability Advertisement 🤝
During the PCEP initialization phase, PCEP speakers (PCE or PCC) advertise their support of the auto-bandwidth adjustment feature. A PCEP speaker includes the AUTO-BANDWIDTH-CAPABILITY TLV in the OPEN object to advertise its support for PCEP auto-bandwidth extensions. The presence of the AUTO-BANDWIDTH-CAPABILITY TLV in the OPEN object indicates that the auto-bandwidth feature is supported as described in this document. Bestie, this handshake is EVERYTHING ✨
- The PCEP protocol extensions for auto-bandwidth adjustments MUST NOT be used if one or both PCEP speakers have not included the AUTO-BANDWIDTH-CAPABILITY TLV in their respective OPEN message. 🚫
- A PCEP speaker that does not recognize the extensions defined in this document would simply ignore the TLVs as per [RFC5440]. 🙃
- If a PCEP speaker supports the extensions defined in this document but did not advertise this capability, then upon receipt of the AUTO-BANDWIDTH-ATTRIBUTES TLV in the LSP Attributes (LSPA) object, it SHOULD generate a PCErr with Error-Type 19 (Invalid Operation) and Error-value 14 (Auto-Bandwidth capability was not advertised) and ignore the AUTO-BANDWIDTH-ATTRIBUTES TLV. 📢
5.1.1. AUTO-BANDWIDTH-CAPABILITY TLV 🦋
The AUTO-BANDWIDTH-CAPABILITY TLV is an optional TLV for use in the OPEN Object for auto-bandwidth adjustment via PCEP capability advertisement. Its format is shown in the following figure:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=36 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: AUTO-BANDWIDTH-CAPABILITY TLV FormatThe TLV Type is 36, and it has a fixed Length of 4 octets. 🔢
The value comprises a single field: Flag (32 bits). No flags are defined for this TLV in this document. 🏳️
Unassigned bits are considered reserved. They MUST be set to 0 on transmission and MUST be ignored on receipt. Be careful with those bits, periodt 🙅♀️
Advertisement of the AUTO-BANDWIDTH-CAPABILITY TLV implies support of auto-bandwidth adjustment, as well as the objects, TLVs, and procedures defined in this document. So sending this TLV is basically saying "I'm in" 💖
5.2. AUTO-BANDWIDTH-ATTRIBUTES TLV 👑
The AUTO-BANDWIDTH-ATTRIBUTES TLV provides the 'configurable knobs' of the feature, and it can be included as an optional TLV in the LSPA object (as described in [RFC5440]). These are the knobs, bestie 🎛️
For a PCE-initiated LSP [RFC8281], this TLV is included in the LSPA object with the PCInitiate message. For PCC-initiated delegated LSPs, this TLV is carried in the LSPA object of the Path Computation State Report (PCRpt) message. This TLV is also carried in the LSPA object with the Path Computation Update Request (PCUpd) message to direct the PCC (LSP head-end) to make updates to auto-bandwidth attributes such as Adjustment-Interval. 📬
The TLV is encoded in all PCEP messages for the LSP while the auto-bandwidth adjustment feature is enabled. The absence of the TLV indicates the PCEP speaker wishes to disable the feature. This TLV includes multiple AUTO-BANDWIDTH-ATTRIBUTES sub-TLVs. The AUTO-BANDWIDTH-ATTRIBUTES sub-TLVs are included if there is a change since the last information sent in the PCEP message. The default values for missing sub-TLVs apply for the first PCEP message for the LSP. 🧩
The format of the AUTO-BANDWIDTH-ATTRIBUTES TLV is shown in the following figure:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=37 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// sub-TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: AUTO-BANDWIDTH-ATTRIBUTES TLV Format- Type: 37
- Length: The Length field defines the length of the value portion in bytes as per [RFC5440]. 📏
- Value: This comprises one or more sub-TLVs. 🫧
The following sub-TLVs are defined in this document: 💅
+------+-----+--------------------------------------+
| Type | Len | Name |
+======+=====+======================================+
| 1 | 4 | Sample-Interval |
+------+-----+--------------------------------------+
| 2 | 4 | Adjustment-Interval |
+------+-----+--------------------------------------+
| 3 | 4 | Down-Adjustment-Interval |
+------+-----+--------------------------------------+
| 4 | 4 | Adjustment-Threshold |
+------+-----+--------------------------------------+
| 5 | 8 | Adjustment-Threshold-Percentage |
+------+-----+--------------------------------------+
| 6 | 4 | Down-Adjustment-Threshold |
+------+-----+--------------------------------------+
| 7 | 8 | Down-Adjustment-Threshold-Percentage |
+------+-----+--------------------------------------+
| 8 | 4 | Minimum-Bandwidth |
+------+-----+--------------------------------------+
| 9 | 4 | Maximum-Bandwidth |
+------+-----+--------------------------------------+
| 10 | 8 | Overflow-Threshold |
+------+-----+--------------------------------------+
| 11 | 8 | Overflow-Threshold-Percentage |
+------+-----+--------------------------------------+
| 12 | 8 | Underflow-Threshold |
+------+-----+--------------------------------------+
| 13 | 8 | Underflow-Threshold-Percentage |
+------+-----+--------------------------------------+
Table 2: Sub-TLV Types of the AUTO-BANDWIDTH-
ATTRIBUTES TLVFuture specifications can define additional sub-TLVs. The door's open for more sub-TLVs later 🚪✨
The sub-TLVs are encoded to inform the PCEP peer of the various sampling and adjustment parameters. In the case of a missing sub-TLV, as per the local policy, either the default value (as specified in this document) or some other operator-configured value is used. 🔧
All sub-TLVs are optional, and any unrecognized sub-TLV MUST be ignored. If a sub-TLV of the same type appears more than once, only the first occurrence is processed, and all others MUST be ignored. Duplicates are NOT the vibe 🙅♀️
The following subsections describe the sub-TLVs that are currently defined as being carried within the AUTO-BANDWIDTH-ATTRIBUTES TLV. Let's go deeper 🌈
5.2.1. Sample-Interval Sub-TLV 📊
okay so this sub-TLV is all about the time interval in seconds where traffic samples get collected at the PCC 💖
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=1 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sample-Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: Sample-Interval Sub-TLV Format
So the Type is 1, the Length is 4 octets, and the value is just this one field:
Sample-Interval: the 4-octet time interval for the Bandwidth-Sample collection 🎀 The valid range is from 1 to 604800 (7 days), in seconds, and the default is 300 seconds. Bestie, you gotta be careful with a super lowSample-Interval, because it can cause some undesirable interactions with transport protocols (see Section 6.6) 🙈 TheSample-Intervalparameter MUST NOT be greater than the (down) Adjustment-Interval. If an invalid value shows up, the sub-TLV MUST be ignored and the previous value will be maintained 💅
5.2.2. Adjustment-Intervals ⏰
The sub-TLVs in this section tell the PCEP peer about the Adjustment-Interval parameters ✨ The Adjustment-Interval sub-TLV sets the time interval for both upward (Up-Adjustment-Interval) and downward (Down-Adjustment-Interval) trends. An implementation MAY require that a different Adjustment-Interval value be set when the bandwidth usage trend is moving downwards than the one used when it is moving upwards. In that case, the operator could use the Down-Adjustment-Interval sub-TLV, which overrides the Adjustment-Interval value for Down-Adjustment-Interval 🦋
5.2.2.1. Adjustment-Interval Sub-TLV 🌸
The Adjustment-Interval sub-TLV specifies a time interval in seconds for when a bandwidth adjustment should be made, either upward or downward 💖 This sub-TLV sets the value for Up-Adjustment-Interval and Down-Adjustment-Interval when they are the same, and when the Down-Adjustment-Interval sub-TLV is not included.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=2 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adjustment-Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: Adjustment-Interval Sub-TLV Format
The Type is 2, the Length is 4 octets, and the value is this one field:
Adjustment-Interval: the 4-octet time interval for bandwidth adjustments 🎀 The valid range is from 1 to 604800 (7 days), in seconds. The default is 86400 seconds (1 day). TheAdjustment-Intervalparameter MUST NOT be less than the Sample-Interval; otherwise, the sub-TLV MUST be ignored, and the previous value will be maintained 🙅♀️
5.2.2.2. Down-Adjustment-Interval Sub-TLV 🍓
The Down-Adjustment-Interval sub-TLV specifies a time interval in seconds for when a bandwidth adjustment should be made if MaxAvgBw is less than the current bandwidth reservation of the LSP. This parameter overrides the Adjustment-Interval for the downward trend 🧚 It's only used when you actually need different Adjustment-Intervals going up and going down, so don't add it just because 💅
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=3 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Down-Adjustment-Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: Down-Adjustment-Interval Sub-TLV Format
The Type is 3, the Length is 4 octets, and the value is this one field:
Down-Adjustment-Interval: the 4-octet time interval for downward bandwidth adjustments 🌈 The valid range is from 1 to 604800 (7 days), in seconds. The default equals the Adjustment-Interval. TheDown-Adjustment-Intervalparameter MUST NOT be less than the Sample-Interval; otherwise, the sub-TLV MUST be ignored and the previous value will be maintained 💜
5.2.3. Adjustment-Thresholds 🎯
The sub-TLVs in this section tell the PCEP peer about the Adjustment-Threshold parameters 🫶 An implementation MAY include both the sub-TLVs for the absolute value and the percentage. In that case, the bandwidth gets adjusted when either of the Adjustment-Threshold conditions is met 🔥 The Adjustment-Threshold sub-TLV sets the threshold for both upward (Up-Adjustment-Threshold) and downward (Down-Adjustment-Threshold) trends. If the operator wants a different Adjustment-Threshold during the downward trend, they include the Down-Adjustment-Threshold sub-TLV. Similarly, the Adjustment-Threshold-Percentage sub-TLV sets the threshold percentage for both upward and downward trends, and if the operator wants a different percentage going down, the Down-Adjustment-Threshold-Percentage sub-TLV is included 👑
It is worth noting that no matter how the thresholds are set, the adjustment will not be made until at least one Sample-Interval has passed. That's simply because no sample will exist to base a comparison with a threshold on 😭
5.2.3.1. Adjustment-Threshold Sub-TLV 💖
The Adjustment-Threshold sub-TLV decides when the LSP bandwidth should be adjusted, either upward or downward ✨ This sub-TLV sets the absolute value for Up-Adjustment-Threshold and Down-Adjustment-Threshold when they are the same, and when the Down-Adjustment-Threshold sub-TLV is not included.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=4 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adjustment-Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: Adjustment-Threshold Sub-TLV Format
The Type is 4, the Length is 4 octets, and the value is this one field:
Adjustment-Threshold: the absolute bandwidth difference value, encoded in IEEE floating point format (see [IEEE.754.1985]) and expressed in bytes per second 🦋 The default value is not set. For a table of commonly used values, refer to Section 3.1.2 of [RFC3471] 📚
Here's the vibe check: if the modulus of the difference between the current MaxAvgBw and the current bandwidth reservation is greater than or equal to the threshold value, the LSP bandwidth gets adjusted to the current bandwidth demand (MaxAvgBw) 🌟 If an invalid value shows up, the sub-TLV MUST be ignored and the previous value will be maintained 🙈
5.2.3.2. Adjustment-Threshold-Percentage Sub-TLV 🍓
The Adjustment-Threshold-Percentage sub-TLV decides when the LSP bandwidth should be adjusted, either upward or downward 🌸 This sub-TLV sets the percentage value for Up-Adjustment-Threshold and Down-Adjustment-Threshold when they are the same, and when the Down-Adjustment-Threshold-Percentage sub-TLV is not included.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=5 | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Percentage |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum-Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 8: Adjustment-Threshold-Percentage Sub-TLV Format
The Type is 5, the Length is 8 octets, and the value has these fields:
Reserved: MUST be set to zero on transmission and MUST be ignored on receipt 🫧Percentage: the Adjustment-Threshold value (7 bits), encoded as a percentage (an integer from 1 to 100) 💅 The value 0 is considered to be invalid. The default is 5 percent 🎀Minimum-Threshold: the absolute bandwidth value, encoded in IEEE floating point format (see [IEEE.754.1985]) and expressed in bytes per second ✨ The increase or decrease of the LSP bandwidth MUST be at or above the Minimum-Threshold before the bandwidth adjustment is made. The default is 0 🌈
Okay, so if the percentage absolute difference between the current MaxAvgBw and the current bandwidth reservation is greater than or equal to the threshold percentage, and the difference in bandwidth is at or above the Minimum-Threshold, the LSP bandwidth gets adjusted to the current bandwidth demand (MaxAvgBw) 🔥 If an invalid value shows up, the sub-TLV MUST be ignored and the previous value will be maintained 💜
5.2.3.3. Down-Adjustment-Threshold Sub-TLV 🌷
The Down-Adjustment-Threshold sub-TLV decides when the LSP bandwidth should be adjusted if MaxAvgBw is less than the current bandwidth reservation 🫶 This parameter overrides the Adjustment-Threshold for the downward trend. It's only used when you need a different threshold going up versus going down 👑
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=6 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Down-Adjustment-Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9: Down-Adjustment-Threshold Sub-TLV Format
The Type is 6, the Length is 4 octets, and the value is this one field:
Down-Adjustment-Threshold: the absolute bandwidth value, encoded in IEEE floating point format (see [IEEE.754.1985]) and expressed in bytes per second 🦋 The default value equals the Adjustment-Threshold. For a table of commonly used values, refer to Section 3.1.2 of [RFC3471] 📚
If the difference between the current bandwidth reservation and the current MaxAvgBw is greater than or equal to the threshold value, the LSP bandwidth gets adjusted to the current bandwidth demand (MaxAvgBw) 🌟 If an invalid value shows up, the sub-TLV MUST be ignored and the previous value will be maintained 🙈
5.2.3.4. Down-Adjustment-Threshold-Percentage Sub-TLV ✨
The Down-Adjustment-Threshold-Percentage sub-TLV is the one that decides when the LSP bandwidth should get adjusted when MaxAvgBw is less than the current bandwidth reservation 📉. It overrides the Adjustment-Threshold-Percentage for the downward trend 🙌. This sub-TLV is only used when you need a different threshold percentage going up versus going down 💅.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=7 | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Percentage |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum-Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 10: Down-Adjustment-Threshold-Percentage Sub-TLV Format
The Type is 7, the Length is 8 octets, and the value is made up of the following 💖
Reserved: MUST be set to zero on transmission and MUST be ignored on receipt. Basically, zero it out when sending and don't read anything into it when receiving 🙈
Percentage: The Down-Adjustment-Threshold value (7 bits), encoded in a percentage (an integer from 1 to 100). The value 0 is considered to be invalid 🚫. The default value equals the Adjustment-Threshold-Percentage.
Minimum-Threshold: The absolute Minimum-Threshold bandwidth value, encoded in IEEE floating point format (see [IEEE.754.1985]) and expressed in bytes per second 🧮. The decrease of the LSP bandwidth MUST be at or above the Minimum-Threshold before the bandwidth adjustment is made. The default value equals the Minimum-Threshold for the Adjustment-Threshold-Percentage.
So when the percentage difference between the current bandwidth reservation and the current MaxAvgBw is greater than or equal to the threshold percentage, and the difference in bandwidth is at or above the Minimum-Threshold, the LSP bandwidth gets adjusted to the current bandwidth demand (MaxAvgBw) 🎯 Both checks have to pass, bestie 🫶
If an invalid value shows up, the sub-TLV MUST be ignored and the previous value will be maintained 🛑
5.2.4. Minimum and Maximum-Bandwidth Values 🎀
5.2.4.1. Minimum-Bandwidth Sub-TLV 🌸
The Minimum-Bandwidth sub-TLV specifies the Minimum-Bandwidth allowed for the LSP, expressed in bytes per second. The LSP bandwidth can't be adjusted below the Minimum-Bandwidth value 📉🚫
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=8 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum-Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 11: Minimum-Bandwidth Sub-TLV Format
The Type is 8, the Length is 4 octets, and the value is made up of the following ✨
Minimum-Bandwidth: The 4-octet bandwidth value encoded in IEEE floating point format (see [IEEE.754.1985]) and expressed in bytes per second. The default Minimum-Bandwidth value is set to 0. Refer to Section 3.1.2 of [RFC3471] for a table of commonly used values 📚
If an invalid value shows up, the sub-TLV MUST be ignored and the previous value will be maintained 🛑
5.2.4.2. Maximum-Bandwidth Sub-TLV 🦋
The Maximum-Bandwidth sub-TLV specifies the Maximum-Bandwidth allowed for the LSP, expressed in bytes per second. The LSP bandwidth can't be adjusted above the Maximum-Bandwidth value 📈🚫
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=9 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum-Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 12: Maximum-Bandwidth Sub-TLV Format
The Type is 9, the Length is 4 octets, and the value is made up of the following 💜
Maximum-Bandwidth: The 4-octet bandwidth value encoded in IEEE floating point format (see [IEEE.754.1985]) and expressed in bytes per second. The default Maximum-Bandwidth value is not set. Refer to Section 3.1.2 of [RFC3471] for a table of commonly used values 📚
If an invalid value shows up, the sub-TLV MUST be ignored and the previous value will be maintained 🛑
5.2.5. Overflow and Underflow Conditions 🌊
The sub-TLVs in this section are encoded to tell the PCEP peer about the overflow and underflow threshold parameters 🗣️ An implementation MAY include sub-TLVs for an absolute value and/or a percentage for the threshold. In that case, the bandwidth is immediately adjusted when either of the threshold conditions is met consecutively for the given count (as long as the difference in the bandwidth is at or above the Minimum-Threshold) ⚡ By default, the threshold values for overflow and underflow conditions are not set 🙅♀️
5.2.5.1. Overflow-Threshold Sub-TLV 🔥
The Overflow-Threshold sub-TLV is used to decide if the LSP bandwidth should be adjusted immediately ⏩
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=10 | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Overflow-Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 13: Overflow-Threshold Sub-TLV Format
The Type is 10, the Length is 8 octets, and the value is made up of the following 🍓
Reserved: MUST be set to zero on transmission and MUST be ignored on receipt.
Count: The Overflow-Count value (5 bits), encoded in an integer. The value 0 is considered to be invalid. The number of consecutive samples for which the overflow condition MUST be met for the LSP bandwidth is to be immediately adjusted to the current bandwidth demand, bypassing the (up) Adjustment-Interval 🏃♀️💨
Overflow-Threshold: The absolute Overflow-Threshold bandwidth value, encoded in IEEE floating point format (see [IEEE.754.1985]) and expressed in bytes per second. Refer to Section 3.1.2 of [RFC3471] for a table of commonly used values. If the difference between the current MaxAvgBw and the current bandwidth reservation is greater than or equal to the threshold value, the overflow condition is met ✅
If an invalid value shows up, the sub-TLV MUST be ignored and the previous value will be maintained 🛑
5.2.5.2. Overflow-Threshold-Percentage Sub-TLV 🧁
The Overflow-Threshold-Percentage sub-TLV is used to decide if the LSP bandwidth should be adjusted immediately 💅
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=11 | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Percentage | Reserved | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum-Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 14: Overflow-Threshold-Percentage Sub-TLV Format
The Type is 11, the Length is 8 octets, and the value is made up of the following 🌈
Percentage: The Overflow-Threshold value (7 bits), encoded in a percentage (an integer from 1 to 100). The value 0 is considered to be invalid. If the percentage increase of the current MaxAvgBw from the current bandwidth reservation is greater than or equal to the threshold percentage, the overflow condition is met 📈
Reserved: MUST be set to zero on transmission and MUST be ignored on receipt.
Count: The Overflow-Count value (5 bits), encoded in an integer. The value 0 is considered to be invalid. The number of consecutive samples for which the overflow condition MUST be met for the LSP bandwidth is to be immediately adjusted to the current bandwidth demand, bypassing the (up) Adjustment-Interval ⏭️
Minimum-Threshold: The absolute Minimum-Threshold bandwidth value, encoded in IEEE floating point format (see [IEEE.754.1985]) and expressed in bytes per second. The increase of the LSP bandwidth MUST be at or above the Minimum-Threshold before the bandwidth adjustment is made 🧮
If an invalid value shows up, the sub-TLV MUST be ignored and the previous value will be maintained 🛑
5.2.5.3. Underflow-Threshold Sub-TLV 🌙
The Underflow-Threshold sub-TLV is used to decide if the LSP bandwidth should be adjusted immediately 🫧
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=12 | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Underflow-Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 15: Underflow-Threshold Sub-TLV Format
The Type is 12, the Length is 8 octets, and the value is made up of the following 🎀
Reserved: MUST be set to zero on transmission and MUST be ignored on receipt.
Count: The Underflow-Count value (5 bits), encoded in an integer. The value 0 is considered to be invalid. The number of consecutive samples for which the underflow condition MUST be met for the LSP bandwidth is to be immediately adjusted to the current bandwidth demand, bypassing the Down-Adjustment-Interval 🐢➡️⚡
Underflow-Threshold: The absolute Underflow-Threshold bandwidth value, encoded in IEEE floating point format (see [IEEE.754.1985]) and expressed in bytes per second. Refer to Section 3.1.2 of [RFC3471] for a table of commonly used values. If the difference between the current MaxAvgBw and the current bandwidth reservation is greater than or equal to the threshold value, the underflow condition is met 🙌
If an invalid value shows up, the sub-TLV MUST be ignored and the previous value will be maintained 🛑
5.2.5.4. Underflow-Threshold-Percentage Sub-TLV ✨
okay so the Underflow-Threshold-Percentage sub-TLV is the one that decides if the LSP bandwidth should be adjusted right now 🫶 no waiting around, bestie!
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=13 | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Percentage | Reserved | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum-Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 16: Underflow-Threshold-Percentage Sub-TLV Format 🎀
So the Type is 13, the Length is 8 octets, and the value is made up of these bits 💅:
- Percentage: This is the Underflow-Threshold value (7 bits), encoded in percentage (an integer from 1 to 100). The value 0 is considered to be invalid 🙈. If the percentage decrease of the current
MaxAvgBwfrom the current bandwidth reservation is greater than or equal to the threshold percentage, the underflow condition is met. - Reserved: MUST be set to zero on transmission and MUST be ignored on receipt. no touching this one, periodt 🚫
- Count: This is the Underflow-Count value (5 bits), encoded in an integer. The value 0 is considered to be invalid. The number of consecutive samples for which the underflow condition MUST be met for the LSP bandwidth is to be immediately adjusted to the current bandwidth demand, bypassing the Down-Adjustment-Interval. ⚡
- Minimum-Threshold: This is the absolute Minimum-Threshold bandwidth value, encoded in IEEE floating point format (see [IEEE.754.1985]) and expressed in bytes per second. The decrease of the LSP bandwidth MUST be at or above the Minimum-Threshold before the bandwidth adjustment is made. 🌸
In the case in which an invalid value is present, the sub-TLV MUST be ignored and the previous value will be maintained. so if something's off, you just ignore it and keep the old vibe 🧚
5.3. BANDWIDTH Object ✨
As per [RFC5440], the BANDWIDTH object (Object-Class value 5) is defined with two Object-Type values, and they go like this 💖:
- Requested Bandwidth: The BANDWIDTH Object-Type value is 1.
- Reoptimization Bandwidth: This is the bandwidth of an existing TE LSP for which a reoptimization is requested. The BANDWIDTH Object-Type value is 2.
The PCC reports the calculated bandwidth to be adjusted (MaxAvgBw) to the stateful PCE using the existing 'Requested Bandwidth' with the BANDWIDTH Object-Type as 1. The reporting of the 'reoptimization bandwidth' with BANDWIDTH Object-Type as 2 is not required, because the stateful PCE already knows the existing LSP bandwidth 🧠
5.4. The PCInitiate Message ✨
A PCInitiate message is a PCEP message sent by a PCE to a PCC to trigger LSP instantiation or deletion [RFC8281]. 🚀
For the PCE-initiated LSP with the auto-bandwidth feature enabled, AUTO-BANDWIDTH-ATTRIBUTES TLV MUST be included in the LSPA object with the PCInitiate message. this part is non-negotiable 👑
The Routing Backus-Naur Form (RBNF) definition of the PCInitiate message [RFC8281] is unchanged by this document. 🌈
5.5. The PCUpd Message ✨
A PCUpd message is a PCEP message sent by a PCE to a PCC to update the LSP parameters [RFC8231]. 💜
For PCE-initiated LSPs with the auto-bandwidth feature enabled, the AUTO-BANDWIDTH-ATTRIBUTES TLV MUST be included in the LSPA object with the PCUpd message. The PCE can send this TLV to direct the PCC to change the auto-bandwidth parameters. the PCE is literally the boss here 💅
The RBNF definition of the PCUpd message [RFC8231] is unchanged by this document.
5.6. The PCRpt Message ✨
The PCRpt message [RFC8231] is a PCEP message sent by a PCC to a PCE to report the status of one or more LSPs. 🦋
For PCE-initiated LSPs [RFC8281], the PCC creates the LSP using the attributes communicated by the PCE and the local values for the unspecified parameters. After the successful instantiation of the LSP, the PCC automatically delegates the LSP to the PCE and generates a PCRpt message to provide the status report for the LSP. it's giving teamwork 🫶
For both PCE-initiated and PCC-initiated LSPs, when the LSP is delegated to a PCE for the very first time as well as after the successful delegation, the BANDWIDTH object of type 1 is used to specify the requested bandwidth in the PCRpt message. 📨
The RBNF definition of the PCRpt message [RFC8231] is unchanged by this document.
5.7. The PCNtf Message ✨
As per [RFC5440], the PCEP Notification message (PCNtf) can be sent by a PCEP speaker to notify its peer of a specific event. ⭐
A PCEP speaker (PCE or PCC) SHOULD notify its PCEP peer (PCC or PCE) when it is in an overwhelmed state due to the auto-bandwidth feature. An implementation needs to make an attempt to send this notification (when overwhelmed by auto-bandwidth adjustments) unless sending this notification would only serve to increase the load further. Note that when the notification is not received, the PCEP speaker would continue to request bandwidth adjustments even when they cannot be handled in a timely fashion. 😭
Upon receipt of an auto-bandwidth overwhelm notification, the peer SHOULD NOT send any PCEP messages related to auto-bandwidth adjustment. If a PCEP message related to auto-bandwidth adjustment is received while in an overwhelmed state, it MUST be ignored. 🙅♀️
- When a PCEP speaker is overwhelmed, it SHOULD notify its peer by sending a PCNtf message with
Notification-type = 5(Auto-Bandwidth Overwhelm State) andNotification-value = 1(Entering Auto-Bandwidth Overwhelm State). Optionally, an OVERLOADED-DURATION TLV [RFC5440] MAY be included to specify the time period during which no further PCEP messages related to auto-bandwidth adjustment should be sent. ⏳ - When the PCEP speaker is no longer in the overwhelm state and is available to process the auto-bandwidth adjustments, it SHOULD notify its peers by sending a PCNtf message with
Notification-type = 5(Auto-Bandwidth Overwhelm State) andNotification-value = 2(Clearing Auto-Bandwidth Overwhelm State). A PCEP speaker SHOULD send such notification to all peers if a Notification message (Notification-type = 5, Notification-value = 1) was sent earlier. This message is not sent if an OVERLOADED-DURATION TLV was included and the PCEP speakers wishes for the peer to wait for the expiration of that period of time before receiving further PCEP messages related to auto-bandwidth adjustment. 🌤️
When the auto-bandwidth feature is deployed, a PCE can send this notification to a PCC when it reports frequent auto-bandwidth adjustments. If a PCC is overwhelmed with resignaling, it can also notify the PCE to not adjust the LSP bandwidth while in the overwhelm state. 🧯
Some dampening notification procedure (as per [RFC5440]) to avoid oscillations of the overwhelm state is RECOMMENDED. On receipt of an auto-bandwidth overwhelm notification from the PCE, a PCC should consider the impact on the entire network. Moving the delegations of auto-bandwidth-enabled LSPs to another PCE could cause further overloading. think of the whole network, bestie 🌍
6. Manageability Considerations ✨
6.1. Control of Function and Policy
The auto-bandwidth feature SHOULD be controlled on a per-LSP basis (at the PCC (head-end of the LSP) or PCE), and the values for auto-bandwidth parameters, e.g., Sample-Interval, Adjustment-Interval (up/down), Minimum-Bandwidth, Maximum-Bandwidth, and Adjustment-Threshold (up/down), SHOULD be configurable by an operator. 🎛️
The Maximum-Bandwidth (and Minimum-Bandwidth) should be set to an acceptable limit to avoid having an impact on the rest of the MPLS-TE domain. keep the limits sensible, babe 🌸
The operator should make sure that the Overflow-Threshold is greater than or at least equal to the Up-Adjustment-Threshold. And similarly, it is important to ensure that the Underflow-Threshold is greater than or at least equal to the Down-Adjustment-Threshold. 📏
6.2. Information and Data Models
A MIB module for gathering operational information about the PCEP is defined in [RFC7420]. Additionally, the YANG module defined in [PCE-PCEP-YANG] provides both configuration of PCEP as well as operational management. These could be enhanced to provide controls and indicators for support of the auto-bandwidth feature. Support for various configuration knobs as well as counters of messages sent/received containing the TLVs defined in this document could be added. 📊
6.3. Liveness Detection and Monitoring
The mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440]. 💓
6.4. Verifying Correct Operations
The mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440].
In the case in which an invalid value is present, the sub-TLV would get ignored and the previous value will be maintained. In such a case, the implementation SHOULD log the event. 📝
6.5. Requirements for Other Protocols
The mechanisms defined in this document do not add any new requirements for other protocols. no drama for the other protocols 🫧
6.6. Impact on Network Operations
In order to avoid any unacceptable impact on network operations, an implementation SHOULD allow a limit to be placed on the number of LSPs that can be enabled with the auto-bandwidth feature. For each LSP enabled with the auto-bandwidth feature, there is an extra load on the PCC, as it needs to monitor the traffic and report the calculated bandwidth to be adjusted to the PCE. The PCE further recomputes paths based on the requested bandwidth and updates the path to the PCC, which, in turn, triggers the resignaling of the path. All these steps add extra load and churn in the network; thus, the operator needs to take due care while enabling these features on a number of LSPs. that's a lot of moving pieces, so be careful 😮💨
An implementation MAY allow a limit to be placed on the rate of auto-bandwidth-related messages sent by a PCEP speaker and received by a peer. An implementation SHOULD also allow notifications to be sent when a PCEP speaker is overwhelmed or when the rate of messages reaches a threshold. 🚦
Due care is required by the operator if a Sample-Interval value significantly smaller than the default (5 minutes) is used, as small Sample-Interval values, e.g., 1 minute or less, could cause undesirable interactions with transport protocols. These undesirable interactions result from providing insufficient time for transport protocol reactions to a prior bandwidth adjustment to settle down before Bandwidth-Samples are taken for the next bandwidth adjustment. ⏱️ tiny sample intervals are a vibe-killer for transport protocols 💀
7. Security Considerations ✨
This document defines AUTO-BANDWIDTH-CAPABILITY TLV and AUTO-BANDWIDTH-ATTRIBUTES sub-TLVs, which do not add any substantial new security concerns beyond those already discussed in [RFC8231] and [RFC8281] for stateful PCE operations. As per [RFC8231], it is RECOMMENDED that these PCEP extensions only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in BCP 195 [RFC7525] (unless explicitly set aside in [RFC8253]). 🔐 this is serious, bestie, no skipping it
Incorrect auto-bandwidth parameters in the AUTO-BANDWIDTH-ATTRIBUTES sub-TLVs could have an adverse effect on the LSP as well as on the network. 🚨
8. IANA Considerations ✨
8.1. PCEP TLV Type Indicators ✨
okay bestie, IANA said yes to two shiny new PCEP TLVs 🎀 this document defines them, and they got numbers from the "PCEP TLV Type Indicators" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry 💅
+-------+---------------------------+-----------+
| Value | Description | Reference |
+=======+===========================+===========+
| 36 | AUTO-BANDWIDTH-CAPABILITY | [RFC8733] |
+-------+---------------------------+-----------+
| 37 | AUTO-BANDWIDTH-ATTRIBUTES | [RFC8733] |
+-------+---------------------------+-----------+
Table 3: PCEP TLV Type Indicators8.2. AUTO-BANDWIDTH-CAPABILITY TLV Flag Field 🚩
so the flag field inside the AUTO-BANDWIDTH-CAPABILITY TLV gets its very own subregistry, living inside the "Path Computation Element Protocol (PCEP) Numbers" registry 🗂️
new bit numbers are handed out by Standards Action [RFC8126]. every bit should be tracked with three things: its bit number (counting from bit 0 as the most significant bit), a capability description, and the RFC that defined it 🧠
the subregistry starts out totally empty, with every single bit marked unassigned. clean slate, no drama yet 🌸
8.3. AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV 🦋
this document is where the AUTO-BANDWIDTH-ATTRIBUTES sub-TLVs get defined 🧚 IANA made an "AUTO-BANDWIDTH-ATTRIBUTES Sub-TLV Types" subregistry inside the "Path Computation Element Protocol (PCEP) Numbers" registry, and its job is to manage the type indicator space for those sub-TLVs. the valid range is 0-65535 🔢
IANA seeded the registry with the values you'll see below. anything else in the registry should be marked as "Unassigned" 🫧
IANA also set the Registration Procedure for this registry like this:
+-------------+------------------------+
| Range | Registration Procedure |
+=============+========================+
| 0-65503 | IETF Review |
+-------------+------------------------+
| 65504-65535 | Experimental Use |
+-------------+------------------------+
Table 4: Registration Procedure for
the "AUTO-BANDWIDTH-ATTRIBUTES Sub-
TLV" Registryand this document defines the following types 🎀
+----------+--------------------------------------+-----------+
| Type | Name | Reference |
+==========+======================================+===========+
| 0 | Reserved | [RFC8733] |
+----------+--------------------------------------+-----------+
| 1 | Sample-Interval | [RFC8733] |
+----------+--------------------------------------+-----------+
| 2 | Adjustment-Interval | [RFC8733] |
+----------+--------------------------------------+-----------+
| 3 | Down-Adjustment-Interval | [RFC8733] |
+----------+--------------------------------------+-----------+
| 4 | Adjustment-Threshold | [RFC8733] |
+----------+--------------------------------------+-----------+
| 5 | Adjustment-Threshold-Percentage | [RFC8733] |
+----------+--------------------------------------+-----------+
| 6 | Down-Adjustment-Threshold | [RFC8733] |
+----------+--------------------------------------+-----------+
| 7 | Down-Adjustment-Threshold-Percentage | [RFC8733] |
+----------+--------------------------------------+-----------+
| 8 | Minimum-Bandwidth | [RFC8733] |
+----------+--------------------------------------+-----------+
| 9 | Maximum-Bandwidth | [RFC8733] |
+----------+--------------------------------------+-----------+
| 10 | Overflow-Threshold | [RFC8733] |
+----------+--------------------------------------+-----------+
| 11 | Overflow-Threshold-Percentage | [RFC8733] |
+----------+--------------------------------------+-----------+
| 12 | Underflow-Threshold | [RFC8733] |
+----------+--------------------------------------+-----------+
| 13 | Underflow-Threshold-Percentage | [RFC8733] |
+----------+--------------------------------------+-----------+
| 14-65503 | Unassigned | [RFC8733] |
+----------+--------------------------------------+-----------+
Table 5: Initial Contents of the "AUTO-BANDWIDTH-ATTRIBUTES
Sub-TLV" Registry8.4. Error Object 🚨
this document adds a brand-new Error-value for PCErr messages with Error-Type 19 (Invalid Operation) [RFC8231] 😤 IANA gave it a spot in the "PCEP-ERROR Object Error Types and Values" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry, like so:
+------------+-----------+--------------------+-----------+
| Error-Type | Meaning | Error-value | Reference |
+============+===========+====================+===========+
| 19 | Invalid | 14: Auto-Bandwidth | [RFC8733] |
| | Operation | capability was not | |
| | | advertised | |
+------------+-----------+--------------------+-----------+
Table 6: Addition to the "PCEP-ERROR Object Error Types
and Values" Registry8.5. Notification Object 🔔
IANA also allocated a new Notification-type and Notification-values inside the "Notification Object" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry 🫶
+-------------------+----------------+--------------------+---------+
| Notification-type | Name | Notification-value |Reference|
+===================+================+====================+=========+
| 5 | Auto-Bandwidth | 0: Unassigned |[RFC8733]|
| |Overwhelm State | | |
+-------------------+----------------+--------------------+---------+
| | | 1: Entering Auto- |[RFC8733]|
| | |Bandwidth Overwhelm | |
| | | State | |
+-------------------+----------------+--------------------+---------+
| | | 2: Clearing Auto- |[RFC8733]|
| | |Bandwidth Overwhelm | |
| | | State | |
+-------------------+----------------+--------------------+---------+
Table 7: Additions to the "Notification Object" Registry9. References 📚
9.1. Normative References 🔥
[IEEE.754.1985]
IEEE, "Standard for Binary Floating-Point Arithmetic",
DOI 10.1109/IEEESTD.1985.82928, IEEE Standard 754, October
1985, <https://doi.org/10.1109/IEEESTD.1985.82928>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.9.2. Informative References 💜
[PCE-PCEP-YANG]
Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-yang-13, 31 October
2019,
<https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-13>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, DOI 10.17487/RFC3471, January 2003,
<https://www.rfc-editor.org/info/rfc3471>.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
Hardwick, "Path Computation Element Communication Protocol
(PCEP) Management Information Base (MIB) Module",
RFC 7420, DOI 10.17487/RFC7420, December 2014,
<https://www.rfc-editor.org/info/rfc7420>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017,
<https://www.rfc-editor.org/info/rfc8051>.Acknowledgments 🫶
the authors want to thank Robert Varga, Venugopal Reddy, Reeja Paul, Sandeep Boina, Avantika, JP Vasseur, Himanshu Shah, Jonathan Hardwick, and Adrian Farrel for their useful comments and suggestions 💖
thanks to Daniel Franke, Joe Clarke, David Black, and Erik Kline for the directorate reviews 🌈
thanks to Mirja Kühlewind, Barry Leiba, Benjamin Kaduk, and Roman Danyliw for the IESG review ✨
Contributors 🧚
He Zekun
Tencent Holdings Ltd.
Shenzhen
China
Email: kinghe@tencent.com
Xian Zhang
Huawei Technologies
Research Area F3-1B
Huawei Industrial Base,
Shenzhen
518129
China
Phone: +86-755-28972645
Email: zhang.xian@huawei.com
Young Lee
Samsung
Email: younglee.tx@gmail.comAuthors' Addresses 🫶✨
Meet the squad who wrote this one, bestie 💖
Dhruv Dhody (editor) 🎀 Huawei Technologies Divyashree Techno Park, Whitefield Bangalore 560066 Karnataka India
Email: dhruv.ietf@gmail.com
Rakesh Gandhi (editor) 🦋 Cisco Systems, Inc. Canada
Email: rgandhi@cisco.com
Udayasree Palle 🌸 Individual Contributor
Email: udayasreereddy@gmail.com
Ravi Singh 🧚 Individual Contributor
Email: ravi.singh.ietf@gmail.com
Luyuan Fang 👑 Expedia Group, Inc. United States of America
Email: luyuanf@gmail.com
Okay that's the whole crew, the end of the doc! 🌈💅 Iconic work, all of them. 😭🔥
📦 where this page comes from
- ietf: rfc8733 2020-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms