TEAS M. Sadhana Internet-Draft M. K. Jai Hari Intended status: Informational HPE Expires: 6 May 2027 2 November 2026 An Architecture for Distributed Bandwidth Management Using TE Tunnels and Policies draft-smjh-teas-dist-bw-mgmt-arch-00 Abstract Traffic Engineering (TE) deployments steer traffic over provisioned TE constructs and associate bandwidth with them. Examples include point-to-point and point-to-multipoint (P2MP) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) tunnels, Segment Routing (SR) Policies, and Multipath TE (MPTE) constructs that are provisioned as directed acyclic graphs (DAGs). As demand changes, operators automatically resize the bandwidth allocated to each construct based on measured traffic, a function commonly called auto- bandwidth, but no common description of this practice exists across TE technologies. This document defines an architecture for distributed bandwidth management, in which the originator of each TE construct evaluates and adjusts its bandwidth without central coordination, and can offload computation and bandwidth estimation to an external entity. The architecture is independent of the forwarding plane and assumes a signaling plane, such as RSVP-TE, that provides per-link bandwidth accounting, admission control, and preemption. It covers traffic measurement, bandwidth estimation, adjustment, periodic and event- driven evaluation, and the management of a service carried by multiple concurrently usable tunnels (Container Tunnel management). Technology-specific signaling, data models, path computation, and estimation algorithms are outside its scope. This document defines no new protocol extension or wire encoding. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Sadhana & Jai Hari Expires 6 May 2027 [Page 1] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 May 2027. Copyright Notice Copyright (c) 2026 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 of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Relationship to Existing Work . . . . . . . . . . . . . . 8 1.5. Conventions and Terminology . . . . . . . . . . . . . . . 8 2. Architecture Overview . . . . . . . . . . . . . . . . . . . . 10 2.1. Distributed Bandwidth-Management Functions . . . . . . . 11 2.1.1. Measurement Function . . . . . . . . . . . . . . . . 11 2.1.2. Estimation and Evaluation Function . . . . . . . . . 12 2.1.3. Adjustment and Admission Function . . . . . . . . . . 12 2.2. Evaluation Triggers, Control Loops, and Timescales . . . 12 2.3. Managed TE Constructs . . . . . . . . . . . . . . . . . . 15 2.4. Assumptions and Non-Goals . . . . . . . . . . . . . . . . 16 3. Admission Control and Priorities . . . . . . . . . . . . . . 17 3.1. Admission Control . . . . . . . . . . . . . . . . . . . . 17 3.2. Bandwidth Accounting . . . . . . . . . . . . . . . . . . 17 3.3. Priority-Based Preemption . . . . . . . . . . . . . . . . 18 4. Auto-Bandwidth Management . . . . . . . . . . . . . . . . . . 18 4.1. Traffic Measurement . . . . . . . . . . . . . . . . . . . 18 4.1.1. Customized Polling Profiles . . . . . . . . . . . . . 19 4.1.2. Measurement Windows . . . . . . . . . . . . . . . . . 20 4.1.3. Measurement Validation . . . . . . . . . . . . . . . 21 4.2. Bandwidth Estimation . . . . . . . . . . . . . . . . . . 21 4.2.1. Adjustment Interval . . . . . . . . . . . . . . . . . 21 Sadhana & Jai Hari Expires 6 May 2027 [Page 2] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 4.2.2. Bandwidth-Requirement Estimation . . . . . . . . . . 22 4.2.3. Dampening, Thresholds, and Hysteresis . . . . . . . . 23 4.3. TE Adjustment . . . . . . . . . . . . . . . . . . . . . . 23 4.3.1. Path Computation and Optimization Objectives . . . . 24 4.3.2. In-Place Bandwidth Adjustment . . . . . . . . . . . . 24 4.3.3. Path Replacement and Reoptimization . . . . . . . . . 25 4.3.4. Failed or Deferred Adjustments . . . . . . . . . . . 25 4.4. Monitor Bandwidth Without Adjustment . . . . . . . . . . 26 5. Container Tunnels . . . . . . . . . . . . . . . . . . . . . . 26 5.1. Model and Terminology . . . . . . . . . . . . . . . . . . 26 5.2. Container Tunnel Normalization . . . . . . . . . . . . . 27 5.3. Static and Adaptive Member Tunnels . . . . . . . . . . . 29 5.4. Aggregate Bandwidth Management . . . . . . . . . . . . . 30 5.4.1. Aggregate Bandwidth Requirement . . . . . . . . . . . 30 5.4.2. Overflow and Underflow Handling . . . . . . . . . . . 32 5.5. Failover Normalization . . . . . . . . . . . . . . . . . 33 5.6. Unequal-Bandwidth Member Tunnels . . . . . . . . . . . . 34 6. P2MP TE Tunnel Applicability . . . . . . . . . . . . . . . . 34 7. MPTE Applicability . . . . . . . . . . . . . . . . . . . . . 35 8. SR Policy Applicability . . . . . . . . . . . . . . . . . . . 36 9. Best-Effort Backup Path Placement . . . . . . . . . . . . . . 36 9.1. Interaction with Auto-Bandwidth Management . . . . . . . 37 9.2. Reoptimization . . . . . . . . . . . . . . . . . . . . . 37 9.3. Activation and Shortfall . . . . . . . . . . . . . . . . 38 10. Path-Selection Tie-Breakers . . . . . . . . . . . . . . . . . 38 10.1. Least-Fill Selection . . . . . . . . . . . . . . . . . . 38 10.2. Most-Fill Selection . . . . . . . . . . . . . . . . . . 38 10.3. Greatest-Headroom Selection . . . . . . . . . . . . . . 38 11. Congestion Mitigation . . . . . . . . . . . . . . . . . . . . 39 11.1. Recognizing Congestion . . . . . . . . . . . . . . . . . 39 11.2. Tactical Congestion Mitigation . . . . . . . . . . . . . 39 11.3. Strategic Congestion Mitigation . . . . . . . . . . . . 40 11.4. Coordination and Stability . . . . . . . . . . . . . . . 40 12. Operational Considerations . . . . . . . . . . . . . . . . . 41 12.1. Configuration and Policy . . . . . . . . . . . . . . . . 41 12.2. Telemetry and Observability . . . . . . . . . . . . . . 42 12.3. Scaling Considerations . . . . . . . . . . . . . . . . . 43 12.4. Failure Handling . . . . . . . . . . . . . . . . . . . . 43 12.5. Management Interfaces . . . . . . . . . . . . . . . . . 44 13. Stability of Distributed Control Loops . . . . . . . . . . . 44 13.1. Sources of Instability . . . . . . . . . . . . . . . . . 44 13.2. Concurrency and Coordination . . . . . . . . . . . . . . 44 13.2.1. Concurrent Evaluations . . . . . . . . . . . . . . . 45 13.2.2. Resource Changes During Evaluation . . . . . . . . . 45 13.2.3. Overlapping Adjustment Actions . . . . . . . . . . . 45 13.2.4. Measurement and Adjustment Races . . . . . . . . . . 46 13.2.5. Restart and State Reconciliation . . . . . . . . . . 46 13.3. Preemption and Retries . . . . . . . . . . . . . . . . . 46 Sadhana & Jai Hari Expires 6 May 2027 [Page 3] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 13.4. Stability Controls . . . . . . . . . . . . . . . . . . . 46 14. Security Considerations . . . . . . . . . . . . . . . . . . . 47 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 16. Informative References . . . . . . . . . . . . . . . . . . . 48 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 50 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 51 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 1. Introduction Traffic Engineering (TE) is concerned with the measurement, characterization, modeling, and control of traffic in operational networks (Section 1.1 of [RFC9522]). Section 1.2 of [RFC9522] identifies policy, path steering, and resource management as the key elements of a TE solution. Bandwidth is the resource addressed by this document. Depending on the technology, the bandwidth of a TE construct is represented by distributed reservation state signaled with the Resource Reservation Protocol - Traffic Engineering (RSVP- TE) [RFC3209] for point-to-point tunnels or [RFC4875] for point-to- multipoint tunnels, by logical accounting rather than signaled reservations, as is typical today for Segment Routing (SR) Policy [RFC9256] (Section 8 of [RFC9522]), or by the mapping of ingress bandwidth and traffic distribution onto the resources of a multipath construct such as a Multipath TE (MPTE) directed acyclic graph (DAG) [I-D.kompella-teas-mpte]. This document assumes that a signaling plane provides per-link accounting and admission, as RSVP-TE does for Multiprotocol Label Switching (MPLS) and as work underway in the IETF aims to do for Segment Routing. Demand, topology, and resource availability change after a TE construct is established, so an allocation that was suitable can become insufficient or can hold resources that are no longer needed. Operators address this with a continual loop of measuring traffic, deriving a requirement, evaluating it against available resources, and adjusting the allocation. The loop is the iterative TE process of Section 3 of [RFC9522], operated as closed-loop control (Section 4.6 of [RFC9522]). Section 8 of [RFC9522] describes the practice for MPLS-TE: Label Switched Path (LSP) bandwidth is modified to accommodate persistent shifts in demand, and LSP statistics are used to estimate a traffic matrix. When applied to an LSP, this function is commonly referred to as auto-bandwidth: the head-end monitors the traffic carried by the LSP and automatically adjusts its bandwidth reservation [RFC8733] (see also Section 3.2 of [RFC8051]). It is specified only for MPLS-TE LSPs, and the specification centers on its encoding in the Path Computation Element Communication Protocol (PCEP). This document Sadhana & Jai Hari Expires 6 May 2027 [Page 4] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 describes the function independently of the forwarding plane, and extends it to constructs composed of multiple tunnels. It also outlines its application to P2MP tunnels, SR Policies, and MPTE DAGs. In this architecture, each Tunnel Originator (the entity that originates a TE construct and owns its bandwidth-management decisions) evaluates and adjusts the bandwidth of the TE constructs it originates, using its own measurements and its view of resource state; no central coordination is required. This is the distributed control described in Section 4.3 of [RFC9522]. Computation, such as path computation or bandwidth estimation, can be offloaded to an external entity such as a Path Computation Element (PCE), as in the hybrid systems of Section 4.3.1 of [RFC9522], but the decision to adjust remains with the entity that owns the TE construct. Because Tunnel Originators react independently, their decisions can conflict (Section 4.3.1 of [RFC9522]), and [RFC9522] recommends favoring stability over responsiveness when the two conflict (Section 6.1 of [RFC9522]). Existing TE mechanisms define how to establish and modify TE constructs, but not a common architecture for aligning bandwidth allocation with changing demand. This document describes such an architecture. It separates measurement, estimation and evaluation, and adjustment and admission, and shows how they interact with policy, resource state, and the effective state of a managed TE construct. It applies regardless of how the construct is represented, such as an RSVP-TE tunnel, an SR Policy, or an MPTE DAG, provided that its demand, effective allocation, resource state, and adjustment outcome can be determined. It defines no new signaling protocol, forwarding mechanism, path- computation algorithm, or configuration model. This document is useful for three reasons. It gives operators and implementors a common vocabulary and functional model for automatic bandwidth resizing that applies to RSVP-TE tunnels, SR Policies, and MPTE DAGs. It describes the interactions that make resizing safe in a distributed setting, namely admission, preemption, make-before- break, in-place bandwidth updates, and stability controls. It also extends the practice to services carried by multiple tunnels. The architecture is a common reference for future technology-specific specifications; it does not define protocol extensions or data models. Applicability to SR Policies and MPTE is outlined in this revision and expected to be developed in future revisions. The remainder of this document is organized as follows. Section 2 gives an architectural overview. Section 3 covers admission control and priorities, Section 4 covers auto-bandwidth management of individual constructs, and Section 5 covers Container Tunnels. Sections 6, 7, and 8 describe applicability to P2MP, MPTE, and SR Sadhana & Jai Hari Expires 6 May 2027 [Page 5] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 Policy constructs. Section 9 covers best-effort backup path placement, Section 10 covers path-selection tie-breakers, Section 11 covers congestion mitigation, Section 12 covers operational considerations, and Section 13 covers the stability of distributed control loops. 1.1. Motivation The bandwidth that a TE construct needs changes over time, and [RFC9522] recommends automating TE functions wherever feasible (Section 6.1). Automatic resizing, however, has to balance several concerns. Adjusting bandwidth directly in response to individual measurements can cause unnecessary control activity and instability. Measurements may contain transient variation, and the resource or topology information used to make a decision may become outdated before the resulting action is applied. Bandwidth management therefore needs to balance responsiveness, stability, and efficient resource use. With a signaling plane, each adjustment has a cost: a bandwidth change can require resignaling and can trigger preemption of lower-priority constructs (Section 4.3 of [RFC8733]), so keeping the churn caused by adjustments low is a design goal. In-place bandwidth updates [I-D.ietf-teas-rsvp-inplace-lsp-bw-update] change the bandwidth of an existing LSP instance without establishing a new one. A service may also use multiple tunnels that collectively provide the required capacity, a recognized TE practice (Section 6.3 of [RFC9522]). In such cases, bandwidth management applies to both the aggregate requirement and its distribution across the Member Tunnels of a Container Tunnel. Changes in demand, path availability, or admitted resources may require bandwidth adjustment, path adjustment, normalization of the Member Tunnel set, or no action. Different conditions may require evaluation at different timescales. [RFC9522] places the adjustment of explicitly routed LSPs in the medium timescale of minutes to days (Section 2.4.1) and classifies TE methods as time-dependent, state-dependent, or event-dependent (Section 4.1); the evaluations described here can follow any of these. A periodic evaluation can respond to sustained changes in demand, while an event-driven evaluation can respond earlier to persistent threshold conditions, path events, membership changes, or congestion indications. Both forms of evaluation use the same architectural functions and effective-state model. Sadhana & Jai Hari Expires 6 May 2027 [Page 6] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 1.2. Scope This document describes the architectural functions and relationships used to: * collect and validate traffic measurements; * derive a bandwidth requirement from the measurements and effective policy; * perform periodic and event-driven evaluation; * interact with admission control, resource accounting, priority, and preemption; * apply bandwidth or path changes; * manage Container Tunnels, including aggregate demand and bandwidth across their Member Tunnels; * describe how the lifecycle applies to P2MP, MPTE, and SR Policy constructs; * limit instability caused by stale resource information and concurrent distributed decisions; and * consider backup capacity, path-selection tie-breakers, and congestion mitigation. 1.3. Applicability This architecture applies to environments where a Tunnel Originator, or an entity acting on its behalf, can obtain the information necessary to evaluate and adjust resource allocations, including traffic measurements, policy inputs, topology information, resource availability, and the outcome of previous actions. These functions may be implemented within a single system or distributed across multiple cooperating systems. The architecture applies where the bandwidth allocated to a managed TE construct is evaluated or adjusted over time. The managed construct may be represented by a single tunnel or SR Policy, multiple paths, a hierarchical set of tunnels, a point-to-multipoint structure, or a multipath TE realization. Sadhana & Jai Hari Expires 6 May 2027 [Page 7] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 The architecture assumes a signaling plane (see Section 2.4). It assumes that a realization can obtain measurements, determine the effective allocation, evaluate relevant resource information, and report the outcome of an adjustment. The source, distribution, and consistency model of that information are realization-specific. The architecture applies a common functional model across different managed TE constructs, while allowing construct-specific handling of traffic distribution, resource accounting, and adjustment. Nodes and systems that do not implement this architecture continue to operate according to the specifications of the underlying TE technologies. Such nodes are not required to understand the policies, evaluations, or decisions that resulted in a bandwidth or path adjustment. 1.4. Relationship to Existing Work This document builds on the TE framework of [RFC9522], which describes TE practice in general and, in Section 8, the modification of LSP bandwidth in operational MPLS-TE networks. Auto-bandwidth for MPLS-TE LSPs is described in [RFC8733], which defines PCEP extensions for the parameters of the function and describes its operation in Section 4. [RFC8051] presents it as a use case of a stateful PCE. This document generalizes the operation described there beyond MPLS-TE LSPs and the PCEP encoding. [I-D.ietf-teas-rsvp-inplace-lsp-bw-update] specifies one way for an RSVP-TE ingress to apply a bandwidth change without first establishing a replacement LSP instance, which keeps churn low when bandwidth is adjusted often; see Section 4.3.2. [I-D.kompella-teas-mpte] defines the multipath constructs to which Section 7 applies. [I-D.li-rtgwg-tte] describes a tactical mechanism that complements the strategic bandwidth management described here (see Section 11). 1.5. Conventions and Terminology This document is informational and does not specify protocol requirements. It does not use the key words defined by BCP 14. Managed TE construct: The generic object to which the bandwidth- management lifecycle is applied. A realization can expose it as a TE tunnel, an SR Policy, a Container Tunnel, an MPTE construct, or another object with equivalent measurement, allocation, resource, and action state. The object need not be represented as one end- to-end path. Sadhana & Jai Hari Expires 6 May 2027 [Page 8] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 Realization: A specific TE technology and its mechanisms for representing, establishing, and adjusting a managed TE construct, for example RSVP-TE, SR Policy, or an MPTE implementation. Tunnel Originator: The entity that originates a managed TE construct (a tunnel, an SR Policy, or an MPTE DAG) and owns its bandwidth- management decisions. It is typically the head-end node. It can offload computation and bandwidth estimation to an external entity, but the decision to adjust remains with it. TE tunnel: A traffic-engineered construct between its Tunnel Originator and its egress that has path state, allocated bandwidth, and applicable TE constraints. Container Tunnel: A logical TE service composed of one or more concurrently usable Member Tunnels. The group is managed as one bandwidth-management entity. Member Tunnel: A TE tunnel that belongs to a Container Tunnel and is eligible to carry group traffic. Allocated bandwidth: The bandwidth recorded or enforced for TE resource allocation and admission. The underlying realization determines how this value is represented. Managed-object state: The measurement, allocation, resource, path, membership, and action state associated with a managed TE construct. Effective state: The allocation, path, membership, and resource state actually established for a managed TE construct, as distinct from the state that was requested. Evaluation Cycle: An instance of measurement analysis, resource evaluation, and action determination. Bandwidth requirement: The bandwidth derived from valid traffic measurements and policy. It is an input to a decision; it is not a reservation or evidence that capacity is available. Traffic measurement: The function that obtains and validates traffic information for a TE tunnel, Container Tunnel, or another explicitly identified managed TE construct. Resource evaluation: The function that evaluates a bandwidth requirement against policy, topology, current allocation, and available resources. Sadhana & Jai Hari Expires 6 May 2027 [Page 9] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 Periodic bandwidth evaluation: A scheduled evaluation intended to align allocated bandwidth with sustained demand. It commonly supports strategic behavior. Event-driven bandwidth evaluation: An evaluation initiated before the next periodic cycle by a persistent threshold condition, path event, membership event, or congestion indication. It commonly supports tactical behavior. Container Tunnel normalization: A coordinated operation that changes the Member Tunnel set and may also change Member Tunnel bandwidth or path state. Policy: The effective administrative parameters used by measurement, bandwidth determination, resource evaluation, adjustment, and Container Tunnel behavior. This document does not prescribe how policy is stored, inherited, named, or referenced. Point-to-multipoint TE construct: A managed TE construct that carries traffic from one origin toward a set of leaves over a structure that can include shared and leaf-specific resources. The same offered traffic can be replicated onto multiple downstream branches. Leaf: An endpoint that receives traffic from a point-to-multipoint TE construct. Branch: The portion of a point-to-multipoint TE construct associated with reaching one or more leaves. Branches can share resources before they diverge. MPTE construct: A multipath traffic-engineered construct described by an applicable MPTE realization [I-D.kompella-teas-mpte]. An MPTE construct can accept traffic at one or more ingresses, deliver traffic through one or more egresses, and distribute traffic at multiple junctions. This document discusses bandwidth- management applicability without defining MPTE computation, signaling, resource mapping, or forwarding procedures. TTE: Tactical Traffic Engineering, used in this document as an example of a shorter-timescale mechanism that can react to congestion without necessarily using the same managed-object state as periodic bandwidth management. [I-D.li-rtgwg-tte] 2. Architecture Overview Sadhana & Jai Hari Expires 6 May 2027 [Page 10] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 2.1. Distributed Bandwidth-Management Functions Distributed bandwidth management continuously aligns the bandwidth allocated to a managed TE construct with changing traffic demand and network conditions. It uses measurements and operational state to identify a bandwidth requirement, determine whether the current allocation remains suitable, and initiate an adjustment when appropriate. The process may operate across multiple control and realization components. These components exchange measurements, policy, resource information, adjustment requests, and action results without requiring a central component to coordinate the process; the Tunnel Originator retains the decision to adjust. Updated measurements and action results provide feedback for subsequent evaluations, forming a distributed closed-loop process (Sections 3 and 4.6 of [RFC9522]). This architecture separates the process into measurement, estimation and evaluation, and adjustment and admission functions. Figure 1 shows these functions and their relationships. +-------------------+ | Policy | +---------+---------+ | v +-------------+ +--------------------+ +--------------------+ | Measurement | -> | Estimation and | -> | Adjustment and | | Function | | Evaluation Function| | Admission Function | +------+------+ +---------+----------+ +---------+----------+ ^ | | | v v | +------------------+ +------------------+ +--------------| Effective State |<---| Action Result | +------------------+ +------------------+ Figure 1: Distributed bandwidth-management functions 2.1.1. Measurement Function Responsible for obtaining traffic and utilization information. Examples include telemetry systems, protocol statistics, management instrumentation, sensor-based statistics or implementation-specific mechanisms. Sadhana & Jai Hari Expires 6 May 2027 [Page 11] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 2.1.2. Estimation and Evaluation Function Derives a bandwidth requirement from validated measurements and evaluates it against the effective allocation, policy, available resources, and operational state. The result identifies whether to retain the current state or request a bandwidth, path, placement, or composition adjustment. 2.1.3. Adjustment and Admission Function Determines whether a requested adjustment is feasible and initiates an admitted bandwidth, path, placement, or composition change. The function reports whether the adjustment completed, failed, was deferred, or was superseded by another adjustment. 2.2. Evaluation Triggers, Control Loops, and Timescales This section distinguishes evaluation triggers from the purpose and scope of the resulting actions. The bandwidth-management lifecycle can be initiated by different triggers and can operate at different timescales. In the taxonomy of Section 4.1 of [RFC9522], an evaluation can be: * time-dependent, when it starts according to a schedule or known temporal pattern; * state-dependent, when it uses current or recently observed traffic, allocation, topology, or resource state; or * event-dependent, when it starts after a qualifying event or state transition, such as a persistent threshold condition, failure, admission result, or congestion indication. These categories describe when and why an evaluation starts. They do not prescribe the statistics source, estimation technique, optimization objective, or action mechanism. An evaluation can also belong to more than one category. For example, a scheduled evaluation can use current state and a predictive estimator. Periodic evaluation commonly supports strategic bandwidth management. It uses a configured schedule and normally considers sustained demand, stable bandwidth adjustment, longer-term placement, and Container Tunnel normalization. Sadhana & Jai Hari Expires 6 May 2027 [Page 12] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 Event-driven evaluation starts before the next periodic cycle when a persistent condition or operational event satisfies policy. A trigger starts a complete evaluation; it does not predetermine whether the result is an increase, decrease, path change, normalization action, or no change. Strategic and tactical behavior describe the purpose and scope of an action, not its trigger. Strategic behavior considers sustained demand and longer-term placement. Tactical behavior addresses a specific current or anticipated condition and favors timely, bounded mitigation. Thus, periodic does not necessarily mean strategic, and event-driven does not necessarily mean tactical. This distinction follows the separate taxonomies in Sections 4.1 and 4.7 of [RFC9522]. Figure 2 summarizes how evaluation triggers lead to strategic and tactical actions. Sadhana & Jai Hari Expires 6 May 2027 [Page 13] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 statistics, policy, and current state | +--------------+--------------+ | | v v +----------------------+ +----------------------+ | periodic evaluation | | event-driven | | - schedule or known | | evaluation | | temporal pattern | | - persistent state | | - sustained demand | | - failure or change | | - longer-term view | | - congestion or | +----------+-----------+ | admission event | | +----------+-----------+ +--------------+--------------+ | v +-----------+------------+ | decision, sequencing, | | and revalidation | +-----------+------------+ | +-----------+------------+ | | v v +----------------------+ +----------------------+ | strategic action | | tactical action | | sustained resource | | timely mitigation | | and placement goals | | of a specific | | | | condition | +----------+-----------+ +----------+-----------+ +--------------+--------------+ | v effective state and feedback Figure 2: Evaluation triggers and action timescales Evaluations that modify the same managed state are sequenced and revalidated against current policy, resources, path state, allocation, and membership. Their results become input to subsequent evaluations. A separate tactical mechanism, like TTE [I-D.li-rtgwg-tte], can use local state and action authority to temporarily redirect eligible traffic without changing the managed service's allocation or membership. Tactical action can be local or externally computed and can favor timely, bounded mitigation over global optimality. Sadhana & Jai Hari Expires 6 May 2027 [Page 14] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 Persistence, hysteresis, clearing conditions, and action-rate limits reduce oscillation. Tactical action also bounds the traffic moved because mitigation of one resource can increase utilization elsewhere. Statistics collected during tactical redirection are interpreted with the active forwarding state and are not treated by themselves as evidence of a sustained demand reduction. 2.3. Managed TE Constructs A managed TE construct is the object to which bandwidth management is applied. It may be realized as a single tunnel, an SR Policy, a multi-tunnel construct, a P2MP TE construct, an MPTE construct, or another technology-specific structure. The generic architecture does not require every managed TE construct to be represented as one end- to-end path. A TE tunnel is one kind of managed TE construct and has placement state, allocated bandwidth, and applicable constraints. A Container Tunnel is a multi-tunnel construct that represents one aggregate bandwidth requirement across one or more concurrently usable Member Tunnels. Each Member Tunnel retains its own path, allocated bandwidth, admission-control state, and resource-accounting state. Figure 3 illustrates a Container Tunnel and its Member Tunnels. Container Tunnel +-------------------------------------+ | Aggregate traffic measurement | | Aggregate bandwidth requirement | | group policy and member set | +------------------+------------------+ | +--------------+--------------+ | | | v v v +-----------+ +-----------+ +-----------+ | member | | member | | member | | tunnel A | | tunnel B | | tunnel C | +-----------+ +-----------+ +-----------+ Figure 3: Container Tunnel abstraction Other managed TE constructs may organize traffic and resources differently. The architecture applies when a construct exposes sufficient measurement, allocation, resource, and action state. Construct-specific accounting, optimization, signaling, and forwarding procedures are outside the scope of this document. Sadhana & Jai Hari Expires 6 May 2027 [Page 15] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 Policy provides the constraints, objectives, bounds, priorities, and stability controls used during evaluation and adjustment. Resource availability and action feasibility are determined from current operational and resource state, not from policy alone. 2.4. Assumptions and Non-Goals The architecture assumes that the Tunnel Originator can obtain traffic measurements, effective policy and bandwidth resource information across the network. It also assumes that the underlying TE technology can apply a bandwidth or path change. The architecture assumes a signaling plane that establishes TE constructs and provides per-link bandwidth accounting, admission control, and preemption, as RSVP-TE [RFC3209] does. This is what allows each Tunnel Originator to act on its own: admission is decided hop by hop against the actual state of each link, so no central accounting authority is needed. The signaling procedures are not specific to one forwarding plane: RSVP-TE can signal constructs over a shared MPLS forwarding plane [RFC8577], and work is underway in the IETF to provide it for Segment Routing data planes. Realizations without a signaling plane can apply the lifecycle described here, but where their per-link accounting, admission control, and preemption reside is outside the scope of this document. The signaling plane contributes the functions that make the Tunnel Originator's view of per-link resource availability current and authoritative: it admits or rejects each change hop by hop, applies preemption, applies the change without disruption (Section 4.3), and its reservation state is what the Interior Gateway Protocol (IGP) or BGP Link State (BGP-LS) advertises as available bandwidth (Sections 5.1.3.9 and 5.1.3.10 of [RFC9522]). The architecture does not provide packet-scale congestion control and does not claim to react to microbursts. Its response time is bounded by measurement collection, evaluation, path computation, and realization-specific actuation. The architecture does not guarantee global optimality or convergence to one unique allocation. Section 13 describes controls intended to bound repeated distributed activity. This document does not define new signaling or routing extensions, a configuration data model, a statistics algorithm, an estimator, a path-computation algorithm, a packet-distribution algorithm, or an internal software architecture. Sadhana & Jai Hari Expires 6 May 2027 [Page 16] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 3. Admission Control and Priorities 3.1. Admission Control Admission control determines whether the bandwidth requested for a managed TE construct can be allocated on its selected placement under the applicable constraints and priority. A bandwidth requirement is an input to admission control and does not indicate that resources are available. Before committing an action, the accounting authority can evaluate the request against its current resource state. A successful computation does not guarantee admission because resource availability or managed state can change before commitment. The accounting authority is the distributed signaling state. The Tunnel Originator decides whether to request an adjustment; the signaling plane decides whether the adjustment is admitted. Delegating computation does not, by itself, transfer admission authority. If a request is rejected or deferred, the implementation does not remove existing usable forwarding state solely because the requested change could not be admitted. The result can identify the effective allocation, the unsatisfied requirement, and the reason for the outcome. 3.2. Bandwidth Accounting Bandwidth accounting records the allocated bandwidth associated with managed TE constructs and makes that information available to admission control and path selection. The accounting model is that of the signaling protocol. The accounting granularity and representation are realization- specific. Resources may be associated with a path, a set of paths, a member set, a forwarding graph, or another managed structure. The realization can expose enough state to identify the effective allocation and prevent incompatible or duplicate allocations. Resources represented at more than one scope are not double counted. State being established is not included in the effective allocation before the required resources are committed. State being withdrawn can remain part of the effective allocation until withdrawal completes or an explicitly permitted partial result is committed. For a point-to-multipoint TE construct, accounting reflects replication and shared-resource semantics so that traffic carried once on a shared resource is not counted once for every downstream leaf. For an MPTE construct, the applicable realization maps ingress Sadhana & Jai Hari Expires 6 May 2027 [Page 17] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 bandwidth and traffic-distribution state to resource use within the construct. The generic architecture does not infer either model from a set of end-to-end paths. 3.3. Priority-Based Preemption Policy may assign relative priority to managed TE constructs. When resources are scarce, a higher-priority request may displace lower- priority allocations if the underlying realization and deployment policy support preemption. Repeated increases can create preemption and restoration cycles. Thresholds, persistence, action-rate limits, and observability are used to bound this behavior. This architecture does not define a fairness algorithm, and persistent starvation remains an operational condition that can be detected and addressed by policy. 4. Auto-Bandwidth Management Auto-bandwidth management is the repeated process of measuring traffic carried by a TE construct, deriving a bandwidth requirement, and evaluating whether its allocated bandwidth or path can change. It participates in both periodic and event-driven bandwidth evaluation. It acts on an individual TE tunnel or equivalent construct. It does not, by itself, change the Member Tunnel set of a Container Tunnel. Membership change is Container Tunnel normalization and is described in Section 5.2. The terminology and parameters in this section follow [RFC8733] where the concepts coincide, such as sampling, adjustment intervals, thresholds, overflow and underflow, and minimum and maximum bounds. This document generalizes them beyond MPLS-TE LSPs and does not restate the PCEP encodings. 4.1. Traffic Measurement Bandwidth statistics may be collected by the bandwidth-management function or supplied by another authorized component, such as a device, telemetry collector, controller, or analytics platform. The supplied value may be a raw observation, normalized rate, or aggregate measurement. Delegating collection does not transfer responsibility for bandwidth-management decisions. The measuring function supplies the measurement and its metadata in a form understood by the bandwidth-requirement determination function. Measurement is a key component of the TE process model (Section 3.1 of [RFC9522]), and Section 6.4 of [RFC9522] gives recommendations for Sadhana & Jai Hari Expires 6 May 2027 [Page 18] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 it. Statistics may apply to an individual TE tunnel, a Member Tunnel, a Container Tunnel, or another explicitly identified aggregate. Member measurements are combined only when their scope, units, observation intervals, and effective membership are compatible. Also, the aggregate statistics for a Container Tunnel can be derived by aggregating the statistics across all of its Member Tunnels for the same collection round. Each statistic includes enough metadata to identify its scope, units, observation interval, source, and validity. Policy identifies acceptable sources, freshness requirements, and fallback behavior. When multiple instances of a tunnel exist, as in make-before-break (MBB), policy selects the instance whose traffic is measured. The bandwidth-management function validates the statistic before use and determines how missing, unsuitable, or conflicting values are handled. For a point-to-multipoint TE construct, measurement scope indicates whether traffic is observed before or after replication. For an MPTE construct, a measurement used to estimate offered demand is associated with a traffic trunk and an ingress. Measurements taken on downstream branches or at internal junctions are interpreted using the applicable replication or traffic-distribution state and are not summed unless duplicate counting is excluded. 4.1.1. Customized Polling Profiles A customized polling profile defines the schedule used to collect traffic measurements for one or more TE tunnels. It separates the frequency and scope of measurement collection from the estimation and adjustment functions that consume the resulting measurements. A deployment may realize a polling profile as a named, reusable configuration, but this document does not require a particular configuration model. A polling profile may specify: * the interval at which traffic is measured; * the TE tunnels or policy scope to which the schedule applies; and * schedule-dependent variations in the measurement interval, such as variations based on time or tunnel role. Sadhana & Jai Hari Expires 6 May 2027 [Page 19] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 A polling profile controls measurement collection only. It does not define how measurements are converted into a bandwidth requirement or which TE path adjustment is selected. The collected traffic measurements may be used by periodic bandwidth evaluation over a measurement window, as described in Section 4.1.2, and by event- driven bandwidth evaluation for persistent threshold conditions, as described in Sections 4.2.3 and 5.4. Different polling profiles allow a deployment to balance responsiveness against measurement and processing cost. A shorter interval can identify traffic changes earlier but increases collection and processing load. A longer interval reduces that load but can delay detection of a sustained change. Section 12.3 discusses the associated scaling considerations. The architecture does not standardize polling-profile configuration, measurement intervals, or profile-assignment procedures. These remain implementation and operational choices. 4.1.2. Measurement Windows Polling interval = P Time --------------------------------------------------------------> t0 t1 t2 t3 t4 t5 t6 t7 |-------|-------|-------|-------|-------|-------|-------| S0 S1 S2 S3 S4 S5 S6 S7 <--------------- Measurement Window W1 ----------------> <--------------- Measurement Window W2 ----> Sx = statistic collected at a polling event P = time between polling events The polling interval controls collection frequency. The measurement window identifies the statistics used for one bandwidth-requirement estimation. Figure 4: Polling interval and measurement windows Sadhana & Jai Hari Expires 6 May 2027 [Page 20] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 A measurement window contains the valid traffic measurements used to derive one bandwidth requirement. The measurement window is independent of the polling interval: multiple measurements collected according to a polling profile may contribute to one window. A shorter window can expose changes earlier but can increase sensitivity to short-lived variation. A longer window can improve stability but can delay detection of a sustained change. Figure 4 illustrates the relationship between the polling interval and measurement windows. Periodic and event-driven bandwidth evaluation may use different measurement windows. Both evaluations preserve compatible measurement scope, units, interval information, and validity semantics. 4.1.3. Measurement Validation Before a traffic measurement is used, the measurement function determines whether it is suitable for the evaluation. A measurement that is unavailable, stale, incomplete, affected by a counter reset, or otherwise unsuitable is handled by the implementation and is not assumed to represent zero traffic. The traffic statistics sample may be deferred, another valid source may be used, the prior bandwidth requirement may be retained, or the bandwidth requirement may be reported as unavailable. A counter reset, path change, measurement-source change, or Container Tunnel membership change is treated as a discontinuity unless the realization can account for it. Invalid input does not silently satisfy an upper or lower threshold condition. 4.2. Bandwidth Estimation 4.2.1. Adjustment Interval The adjustment interval controls how often periodic bandwidth evaluation occurs. It is independent of the measurement interval; multiple measurements can contribute to one periodic evaluation. Policy may define separate adjustment intervals for increases and decreases of the allocation. Policy defines scheduling after no change, failure, deferral, and partial completion. The architecture does not assume that every attempted action restarts the interval. The implementation may choose to enforce the policy in such a way that enough traffic samples are available in every adjustment interval to arrive at a decision. Sadhana & Jai Hari Expires 6 May 2027 [Page 21] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 At each adjustment interval, the Tunnel Originator evaluates the TE tunnel using the valid traffic samples collected during that interval. 4.2.2. Bandwidth-Requirement Estimation The bandwidth-management function may derive the bandwidth requirement from observed traffic or predicted demand. Policy selects the estimation technique and any applicable margin, rounding rule, or bandwidth bounds. If insufficient valid input is available, policy determines whether to use a fallback technique, retain the previous bandwidth requirement, or defer the evaluation. The resulting bandwidth requirement remains subject to thresholds, path feasibility, and admission control. The initial allocation of a TE construct can be an arbitrary value, including zero, and is then adjusted by the process described here (see Section 4.1 of [RFC8733]). Estimation can be performed by the Tunnel Originator or offloaded to an external entity. The decision to adjust remains with the Tunnel Originator. 4.2.2.1. Historical Estimation Historical estimation derives a requirement from observations already collected. The selected history and window determine responsiveness and sensitivity to short-lived variation. Examples of estimation techniques include the following. * Peak-based estimation: Uses the highest valid sample observed during the adjustment interval. This technique responds to observed peaks but can be sensitive to short-lived traffic bursts. * Mean-based estimation: Uses the arithmetic mean of all valid samples in the adjustment interval. This technique smooths short- term variation but can underrepresent periods of high demand. * Percentile-based estimation: Uses a configured percentile of the valid samples, such as the 95th percentile. This technique reduces the influence of isolated peaks while retaining evidence of sustained high demand. 4.2.2.2. Predictive and Model-Based Estimation Predictive estimation attempts to determine a requirement for a future interval. It can use statistical forecasting, analytical models, machine learning, or a hybrid technique. Inputs can include historical traffic, recent measurements, calendar information, topology or resource state, and previous action results when permitted by policy. Sadhana & Jai Hari Expires 6 May 2027 [Page 22] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 A predictive output is associated with its prediction interval and the inputs or model version used to produce it. A change to the measurement source, managed path, member set, policy, or estimator can make a pending prediction unsuitable or stale. The architecture does not assume that a predictive method is more accurate than a historical method. Implementations can compare predicted and observed values, expose prediction error, and use a deterministic fallback when model quality is insufficient. 4.2.3. Dampening, Thresholds, and Hysteresis An adjustment threshold identifies the minimum difference between the bandwidth requirement and allocated bandwidth that merits evaluation. Policy may define separate thresholds for increases and decreases. Dampening limits the frequency or magnitude of change. Hysteresis uses different conditions for entering and leaving a state so that repeated actions near a boundary are reduced. An overflow condition occurs when the bandwidth requirement exceeds the allocated bandwidth by more than a configured overflow threshold, and an underflow condition occurs when it falls below the allocated bandwidth by more than a configured underflow threshold, in each case for a configured number of consecutive evaluations. Such a condition starts an event-driven bandwidth evaluation without waiting for the adjustment interval to expire, so that a sudden change in demand is not masked by a long adjustment interval. The overflow threshold is not smaller than the adjustment threshold for increases, and the underflow threshold is not smaller than the adjustment threshold for decreases. Thresholds can be absolute values, percentages, or both. When percentages are used, a minimum absolute difference avoids frequent adjustments at very low bandwidth values (see Section 4.2 of [RFC8733]). Section 5.4.2 describes the application of overflow and underflow to Container Tunnels. A persistence condition can require a specified number of valid measurements or a duration before an event-driven bandwidth evaluation starts. Policy defines whether invalid input pauses, resets, or leaves pending persistence state unchanged. 4.3. TE Adjustment TE adjustment applies the estimated bandwidth requirement and the placement decision to a managed TE construct. Depending on the construct and applicable realization, an adjustment may update the current bandwidth, select another path or realization, or retain the current state. Sadhana & Jai Hari Expires 6 May 2027 [Page 23] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 The applicable realization defines how an adjustment is admitted, applied, confirmed, and reported. The realization can update bandwidth on the current path or establish replacement state before old state is removed. 4.3.1. Path Computation and Optimization Objectives Computation may be performed locally or delegated to an external computation entity. The request identifies the bandwidth requirement, endpoints, applicable constraints, priority, protection or diversity requirements, and optimization objectives. The computed result may provide: * a path for a TE tunnel or Member Tunnel; * a set of member paths for a Container Tunnel; or * a result defined by an applicable MPTE realization. Optimization objectives may include lower link utilization or path cost, fewer Member Tunnels, greater diversity, reduced operational churn, fewer network changes, or greater residual capacity for expected growth. These objectives may conflict. Policy determines which objectives apply and how they are balanced. Before requesting an action, the Tunnel Originator revalidates the result against current policy, topology, resource information, allocation, and managed state. Delegating computation does not, by itself, transfer decision ownership. Path computation does not count the bandwidth of the existing instance twice when it computes a replacement for the same construct. 4.3.2. In-Place Bandwidth Adjustment A realization can apply a bandwidth change without interrupting forwarding when its underlying technology supports that behavior. In-place updates are the preferred way to apply the frequent, small bandwidth changes that auto-bandwidth produces, because they avoid the signaling and state churn of establishing a replacement instance. Sadhana & Jai Hari Expires 6 May 2027 [Page 24] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 In an RSVP-TE realization, an in-place bandwidth update requests a different bandwidth for the existing LSP instance without first establishing a replacement LSP instance. The ingress signals the updated bandwidth using the applicable RSVP-TE procedure. Transit nodes and the egress process the signaling, perform admission as applicable, and update reservation state [I-D.ietf-teas-rsvp-inplace-lsp-bw-update]. The procedure in [I-D.ietf-teas-rsvp-inplace-lsp-bw-update] retains the same LSP instance and LSP identifier. A successful sequence is confirmed by corresponding Resv state carrying the updated flow specification. An increase can fail admission and produce a PathErr. A decrease can release resources on the current path. This architecture does not redefine those protocol procedures. 4.3.3. Path Replacement and Reoptimization If the current path cannot support an approved bandwidth requirement, resource evaluation may identify another feasible path. Path reallocation applies the new path while preserving forwarding continuity to the extent supported by the underlying TE technology. A path change is not required for every bandwidth change. A decrease or an increase that fits the current path can be applied without another path selection. During the transition, previous and replacement state can coexist, as in make-before-break (Section 2.5 of [RFC3209]). When a bandwidth change requires a new path, the replacement state is established before the previous state is released, so that traffic is not disrupted. RSVP-TE tunnel identification and reservation-style procedures determine how the instances are signaled and how shared resources are treated. Reoptimization can also reconsider the path after topology, resource, or policy changes [RFC4736]. 4.3.4. Failed or Deferred Adjustments An adjustment can fail because the required resources or path are unavailable, because the resource view changed, or because the underlying realization rejected the action. An adjustment can be deferred by policy, dampening, maintenance state, or another pending action. Failure or deferral of a bandwidth-management action alone does not remove the last usable forwarding state for the affected service. This requirement does not prevent administrative withdrawal, removal required by an independent path failure, or action required by an explicit safety policy. Sadhana & Jai Hari Expires 6 May 2027 [Page 25] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 The implementation records the actual allocated bandwidth, unsatisfied requirement, action status, failure reason, and next eligible evaluation. A retry uses refreshed or revalidated state or policy-controlled backoff rather than immediately repeating the same action from unchanged stale input. 4.4. Monitor Bandwidth Without Adjustment In some scenarios, a deployment may observe traffic without automatically adjusting bandwidth. An implementation can monitor traffic for each TE tunnel and record the derived bandwidth requirement. Another entity, such as a controller or Container Tunnel management function, can use that information when requesting an adjustment from the Tunnel Originator. 5. Container Tunnels 5.1. Model and Terminology A Container Tunnel manages one or more Member Tunnels as a single bandwidth-managed service. It derives an aggregate bandwidth requirement, coordinates Member Tunnel allocations, and determines whether the effective member set can change. For example, a Container Tunnel with a 30 Gbit/s requirement may use three Member Tunnels allocated 10 Gbit/s each. If the requirement increases to 50 Gbit/s, the Container Tunnel may increase existing allocations (for adaptive Member Tunnels), add one or more Member Tunnels, or combine both actions, subject to policy and resource availability. The Container Tunnel remains the management object when the number, paths, or bandwidth allocations of its Member Tunnels change. Each Member Tunnel retains its own path state and allocated bandwidth. Traffic may be distributed among active Member Tunnels using Equal- Cost Multipath (ECMP), bandwidth-aware load balancing, or another mechanism supported by the realization. Traffic distribution and bandwidth allocation are separate functions; the traffic carried by a Member Tunnel need not equal its allocated bandwidth. The Container Tunnel management function evaluates aggregate demand across the effective member set using the statistics and estimation procedures described in Section 5.4. Evaluation may be time- dependent, state-dependent, event-dependent, or a combination of these. A change to the member set or its bandwidth allocations is referred to as normalization. Sadhana & Jai Hari Expires 6 May 2027 [Page 26] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 5.2. Container Tunnel Normalization Container Tunnel normalization adjusts the Member Tunnel set and associated bandwidth allocations so that the Container Tunnel can carry its aggregate bandwidth requirement in accordance with policy. Normalization can result in: * a split, which increases the number of Member Tunnels; * a Member Tunnel reduction, which decreases the number of Member Tunnels; or * an adjustment to the bandwidth of existing Member Tunnels without changing the member set. Figure 5 shows how statistics collected over a normalization window are combined into an aggregate requirement and compared with the aggregate allocated bandwidth. Sadhana & Jai Hari Expires 6 May 2027 [Page 27] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 Normalization Window (Interval T) t0 S1 S2 S3 S4 Sk t0+T | | | | | ... | | | A1 A2 A3 A4 ... Ak | | | | | | | | | +-------+-------+-------+------...-----+ | | | | | v | | +-------------------------------------+ | | | Aggregate Measurement History | | | | | | | | [ A1, A2, A3, A4, ... , Ak ] | | | +------------------+------------------+ | | | | | v | | Derive Aggregate Requirement G | | G = estimator(A1, A2, A3, ... , Ak) | | estimator = mean, peak, percentile, or | | another policy-selected method | | | | | v | | Compare G with Aggregate Allocated Bandwidth | | | | | +------------+------------+ | | | | | | threshold condition threshold condition | | not satisfied satisfied | | | | | | v v | | Retain Current Evaluate Bandwidth | | State Adjustment or | | Normalization | +-------------------------------------------------------+ S_k = statistics collection round k. A_k = aggregate traffic measurement for round k. G = aggregate bandwidth requirement derived at the end of the normalization window. Figure 5: Container Tunnel normalization window The term Member Tunnel reduction describes only the decrease in member-count. It does not prescribe how traffic is redistributed, how many members are removed, whether surviving members are resized, or which signaling procedures are used. The normalization procedures can accommodate a graceful switchover to the new member set without any negative effect on the traffic. Policy may define: Sadhana & Jai Hari Expires 6 May 2027 [Page 28] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 * minimum, maximum, and initial member-counts; * static Member Tunnel bandwidth or auto-bandwidth bounds; * thresholds and persistence conditions for normalization; * path and diversity constraints; * conditions or delays for Member Tunnel reduction; and * limits on the frequency of member-set changes. A maximum member-count may prevent the aggregate bandwidth requirement from being fully satisfied, while a minimum member-count may retain more members than current demand requires. Member Tunnel reduction may be delayed to avoid repeated removal and recreation. Because normalization changes the set of tunnels carrying the service, it is generally performed less frequently than a bandwidth adjustment to an existing Member Tunnel. The Container Tunnel management function determines the target member set and bandwidth allocations. Establishment, bandwidth adjustment, or removal of individual Member Tunnels may be delegated to another entity. The Container Tunnel management function remains responsible for coordinating these actions and reporting the effective state. Member-level functions may collect statistics or recommend changes, but one effective decision owner sequences changes to each Member Tunnel. Before normalization is applied, the proposed result is evaluated against the aggregate bandwidth requirement, policy, path feasibility, and available resources. The effective member set remains identifiable throughout the transition. A new member joins the effective set only after it is ready to carry traffic. A retiring member remains in the effective set until traffic no longer depends on it and removal is complete. If normalization cannot be completed, the implementation may continue the remaining actions, restore the previous working state, or retain a partial state when permitted by policy. The reported result identifies the effective member set, member allocations, aggregate allocation, partial-completion status, and any unsatisfied bandwidth requirement. A partial result is not reported as complete success. 5.3. Static and Adaptive Member Tunnels A Container Tunnel may use static or adaptive Member Tunnels. Sadhana & Jai Hari Expires 6 May 2027 [Page 29] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 With static Member Tunnels, each member is assigned a configured bandwidth and comes up with that bandwidth. A common member bandwidth may be used, with members added until the aggregate bandwidth requirement is satisfied or the maximum member-count is reached. When a common member bandwidth is used, normalization changes only the number of members. A static member may still monitor traffic as described in Section 4.4 without changing its bandwidth, and its traffic remains part of the aggregate demand. With adaptive Member Tunnels, each member may adjust its bandwidth within policy-defined minimum and maximum bounds. Adaptation may be performed independently by the member or coordinated by the Container Tunnel management function. Member allocations need not be equal. The selected mode identifies the effective decision owner so that Member-level and Container-level actions do not conflict. 5.4. Aggregate Bandwidth Management 5.4.1. Aggregate Bandwidth Requirement A Container Tunnel may obtain its aggregate traffic measurement directly at the Container-level or derive it from traffic measurements collected for its Member Tunnels. The selected measurement scope is determined by policy and the capabilities of the realization. When measurements are collected at the Member Tunnel level, only measurements with compatible direction, units, traffic classification, observation period, and effective member set are combined. Missing or unsuitable measurements are not treated as zero traffic. Figure 6 shows how Member Tunnel measurements for one statistics collection round are combined into an aggregate measurement. Sadhana & Jai Hari Expires 6 May 2027 [Page 30] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 Statistics Collection Round S_k +------------------------------------------------+ | | | Member Tunnel Measurements | | | | M1 ----> d(1,k) ----+ | | | | | M2 ----> d(2,k) ----+ | | | | | M3 ----> d(3,k) ----+----> Sum ----> A_k | | | | | . . | Aggregate | | . . | Measurement | | | for Round k | | MN ----> d(N,k) ----+ | | | +------------------------------------------------+ N --- \ A_k = > d(i,k) / --- i=1 where: d(i,k) is the measured demand for Member Tunnel i during Statistics Collection Round k. A_k is the aggregate demand for the Container Tunnel during Statistics Collection Round k. Figure 6: Aggregate measurement for a Container Tunnel A realization may support counters at both Container-level and Member-level. When the same traffic is visible at both levels, the counter hierarchy identifies which level is authoritative so that traffic is neither omitted nor counted more than once. Member-level auto-bandwidth management requires Member Tunnel measurements, while Container-level evaluation may use a direct aggregate measurement or a compatible aggregation of the member measurements. If the member set changes during the observation period, or if the required measurements are unavailable or unsuitable, policy determines whether to defer evaluation, use an authoritative Container-level measurement, or apply another explicitly defined method. Sadhana & Jai Hari Expires 6 May 2027 [Page 31] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 A Container Tunnel aggregate can be determined from the traffic sample using similar methods as described in Section 4.2.2. An implementation ensures that enough suitable traffic samples are collected before each normalization so as to act on a valid aggregate demand. 5.4.2. Overflow and Underflow Handling Each bandwidth evaluation compares the measured aggregate bandwidth requirement of a Container Tunnel against its aggregate allocated bandwidth (the bandwidth currently signaled across its Member Tunnels). Two conditions may result: * An overflow condition, where sustained demand exceeds the aggregate allocated bandwidth by more than the configured threshold, or where any single Member Tunnel carries more than its permitted per-member maximum, or where aggregate demand exceeds what the current membership can hold at its per-member maxima. * An underflow condition, where sustained demand falls below the aggregate allocated bandwidth by more than the configured threshold, or where any Member Tunnel falls below its permitted per-member minimum, or where aggregate demand falls below what the current membership holds at its per-member minima. The comparison is made relative to the currently signaled allocation, so that the threshold provides hysteresis and a change is requested only when the deviation is material. Measurement history, outlier trimming, and a persistence requirement (a condition must persist across consecutive measurement intervals before it is acted on) are applied so that a transient spike or dip does not by itself cause a change. Neither condition, on its own, mandates a specific action. Each condition starts an evaluation against policy, the current membership, and the per-member and member-count bounds, which then selects at most one of the actions described below. An underflow condition is never allowed to drive a Container Tunnel below its floor -- the minimum member-count at the minimum per-member bandwidth. A Container Tunnel already resting at that floor with no traffic, or already at its maximum membership with every member at its per-member maximum, raises no condition, because no corrective action is available. Sadhana & Jai Hari Expires 6 May 2027 [Page 32] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 5.4.2.1. Member Tunnel Actions When a condition is confined to a single Member Tunnel and the corrective change keeps that member within its per-member bounds and consistent with the aggregate policy, bandwidth evaluation may request a bandwidth or path change for that member alone. The Member Tunnel is resignaled at an adjusted bandwidth, or replaced on a different path, within its permitted range; the Member-Tunnel set is unchanged. This applies to adaptive Member Tunnels. A member-level change is validated against aggregate state before it is applied, so that a local adjustment cannot push the group past an aggregate bound or conflict with a group-wide requirement. Where a Member-level adjustment is sufficient to absorb the change, it is preferred over any change to membership. 5.4.2.2. Container-Level Actions When a condition reflects the aggregate rather than a single member -- sustained aggregate overflow or underflow, a membership that no longer matches demand, or a Member Tunnel that can no longer carry its share within its per-member bounds -- bandwidth evaluation requests a Container-level action. The required member-count is re- derived from the target aggregate bandwidth, bounded by the configured minimum and maximum member-count and by the per-member bandwidth bounds, and Member Tunnels are added or removed to reach it. Surplus members beyond the maximum count are removed, and a membership below the minimum count is padded back up to it. A Container-level action uses the same policy, resource evaluation, and normalization procedure regardless of whether it was started by a periodic or an event-driven evaluation; it does not introduce a second set of membership rules. Where the re-derived membership and per-member allocation would be identical to the current state, no action is taken. 5.5. Failover Normalization A Member Tunnel path failure can start an event-driven bandwidth evaluation before the next periodic evaluation. The evaluation determines the resulting capacity shortfall from current demand, policy, the effective Member Tunnel set, and available resources. A failover-initiated evaluation is coordinated with the periodic control loop. Policy determines the scheduling of the next periodic evaluation and whether measurement history remains suitable after the path and membership change. Sadhana & Jai Hari Expires 6 May 2027 [Page 33] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 If normalization cannot be completed, the effective Member Tunnel set and any remaining bandwidth shortfall are reported. Recovery follows the failure-handling and state-reconciliation procedures described in Sections 12.4 and 13.2.5. 5.6. Unequal-Bandwidth Member Tunnels A Container Tunnel can allocate different bandwidth values to its Member Tunnels rather than dividing the aggregate bandwidth requirement equally. Unequal allocation allows the Container Tunnel to account for differences in path capacity, constraints, and available resources. Unequal allocation can improve use of heterogeneous paths, reduce unused capacity caused by equal sizing, and satisfy an aggregate bandwidth requirement with fewer Member Tunnels when larger allocations are feasible on some paths. The allocation method is realization-specific. Unequal-bandwidth Member Tunnels use the same aggregate requirement, policy bounds, admission control, normalization, observability, and failure-handling principles as other Container Tunnels. 6. P2MP TE Tunnel Applicability A P2MP TE tunnel carries traffic from one origin toward a set of leaves. Its forwarding structure can contain resources shared by multiple leaves and resources used by individual branches. Traffic can traverse a shared resource before being replicated onto downstream branches. The bandwidth-management lifecycle applies to the P2MP TE tunnel as one managed TE construct. The bandwidth requirement represents traffic offered to the tunnel before replication. It does not represent the sum of traffic observed on downstream branches. Bandwidth evaluation uses the effective leaf set, forwarding structure, current allocation, applicable policy and constraints, and available resource information. The effective leaf set is provided by the applicable P2MP realization and is not changed by the bandwidth-management function. A change to the leaf set or forwarding structure may trigger revalidation because it can change the resources required to carry the same traffic demand. Sadhana & Jai Hari Expires 6 May 2027 [Page 34] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 The P2MP realization maps the tunnel-level bandwidth requirement to the effective forwarding structure. Shared resources account for traffic before replication, while branch-specific resources account for traffic carried after replication. Resource consumption is therefore not derived by multiplying the tunnel-level bandwidth requirement by the number of leaves. Path computation may be performed locally or by a separate path- computation entity. Admission, adjustment, completion, and recovery follow the common procedures defined by this architecture. P2MP tree computation, replication, signaling, forwarding, and branch-specific resource mapping remain realization-specific. 7. MPTE Applicability An MPTE construct may carry traffic through multiple paths, with one or more ingresses and egresses and traffic distribution at intermediate junctions. Applying bandwidth management to an MPTE construct may need to consider: * traffic offered at each ingress; * the effective ingress and egress sets; * how traffic is distributed within the construct; * the relationship between ingress requirements and resource use; * changes to the construct or its traffic-distribution state; and * coordination between bandwidth evaluation and the applicable MPTE realization. Ingress-specific requirements may need to remain identifiable because the location at which traffic enters the construct can affect traffic distribution and resource use. Measurements within the construct are not necessarily equivalent to ingress demand. An MPTE construct is not a Container Tunnel. A Container Tunnel distributes aggregate demand among separately identifiable Member Tunnels. An MPTE construct can distribute a traffic trunk at multiple internal junctions and does not need to expose each alternative as an independently managed end-to-end Member Tunnel. Sadhana & Jai Hari Expires 6 May 2027 [Page 35] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 An MPTE construct with one ingress and multiple egresses is not automatically a P2MP TE tunnel. P2MP bandwidth management derives one pre-replication offered-traffic requirement and maps it onto shared and leaf-specific resources. MPTE bandwidth management derives ingress-specific bandwidth requirements and relies on realization-defined traffic distribution at junctions. The applicable realization defines any additional relationship between the two models. The applicability models in Sections 6, 7, and 8 reuse the generic bandwidth-management lifecycle while retaining the measurement, resource-accounting, and computation semantics of each managed TE construct. This document does not define MPTE measurement, bandwidth aggregation, computation, admission, resource mapping, traffic distribution, signaling, adjustment, or recovery procedures. Applying bandwidth management to MPTE constructs requires further work and discussion, which a future revision or a separate document may provide. 8. SR Policy Applicability This section is a placeholder. A Segment Routing (SR) Policy [RFC9256] is identified by a head-end, a color, and an endpoint, and has one or more candidate paths. For bandwidth management, an SR Policy is a managed TE construct. Per- link accounting, admission control, and preemption for an SR Policy follow the signaling plane assumed in Section 2.4; how such a signaling plane is added to the SR Policy architecture is outside the scope of this document. A future revision is expected to describe measurement of the traffic carried by an SR Policy, adjustment through changes to its candidate paths, and the use of multiple SR Policies or candidate paths as Member Tunnels of a Container Tunnel. 9. Best-Effort Backup Path Placement A protected managed TE construct may be associated with backup placement that carries its traffic when the active placement fails. A backup may reserve protected bandwidth or may be selected without reserving bandwidth. This section describes the latter as best- effort backup path placement. The recovery terminology used here is consistent with [RFC4427]. Sadhana & Jai Hari Expires 6 May 2027 [Page 36] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 Best-effort backup path placement uses available bandwidth in the current resource view as a path-selection objective. It may prefer the feasible path with the greatest available bandwidth at its path- limiting resource. The selected backup does not reserve that bandwidth and is not admitted against the capacity it might use after activation. Its placement therefore indicates where capacity appears available at computation time, not a guarantee that the capacity will remain available when the backup is activated. 9.1. Interaction with Auto-Bandwidth Management Under auto-bandwidth management, the allocation of a protected construct can change as demand rises and falls. A reservation-based backup may need reevaluation when the protected allocation changes so that reserved protection remains aligned with policy. A best-effort backup has no reserved bandwidth to resize; a change in protected allocation therefore does not, by itself, require immediate recomputation. This decouples routine backup maintenance from each active-allocation adjustment. Protection is associated with the applicable protected construct. For a Container Tunnel, a realization may protect Member Tunnels individually or apply another supported protection model. A backup may also provide local repair for traffic associated with several constructs that share a protected resource. Resource accounting follows the applicable failure model and does not assume simultaneous activation beyond that model. RSVP-TE local protection is one example of a realization-specific recovery mechanism [RFC4090]. 9.2. Reoptimization Because best-effort backup placement does not reserve the selected capacity, its suitability can change as network utilization changes. Policy may periodically reevaluate the backup against the current resource view and replace it when a materially better eligible placement exists. Thresholds and dampening can limit movement caused by transient or marginal changes. When the realization supports non- disruptive replacement, new backup state is established before previous state is released so that protection is not intentionally withdrawn during reoptimization. Sadhana & Jai Hari Expires 6 May 2027 [Page 37] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 9.3. Activation and Shortfall When the active placement fails, traffic may be moved onto the backup according to the applicable recovery procedure. Because the backup carries no reservation, activation can place load on resources whose previously available capacity has been consumed. The realization reports the effective protection obtained and any shortfall. Policy may use that result to request another computation, revert after recovery, or select a reservation-based protection method when stronger guarantees are required. Subsequent bandwidth evaluations use the resulting active placement and allocation state. 10. Path-Selection Tie-Breakers When path computation identifies multiple feasible paths with equal primary cost, policy may apply a tie-breaker. These examples are not architectural requirements. A deployment may instead use random selection, administrative preference, diversity, latency, or external optimization. Tie-breakers remain independent of the bandwidth- management lifecycle. 10.1. Least-Fill Selection Least-fill prefers the feasible path with the lowest utilization according to the metric selected by policy. It can distribute TE state across more resources and may preserve headroom on the selected path for a later increase. 10.2. Most-Fill Selection Most-fill prefers a more-utilized feasible path that can still admit the request. It can consolidate allocations and preserve larger free-capacity blocks elsewhere, but a later increase on the selected path may be less likely to fit. 10.3. Greatest-Headroom Selection Greatest-headroom selection prefers the feasible path that can accommodate the largest additional bandwidth, measured at its path- limiting resource. Unlike least-fill, which compares utilization according to a policy-selected metric, greatest-headroom selection compares absolute remaining capacity. This tie-breaker can be useful when a Container Tunnel uses unequal- bandwidth Member Tunnels. Selecting paths with greater headroom can permit larger member allocations and reduce the number of members needed to satisfy the aggregate bandwidth requirement. Sadhana & Jai Hari Expires 6 May 2027 [Page 38] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 The selected path remains subject to applicable constraints and admission control. Greater headroom does not, by itself, make a path preferable when other objectives, such as path cost, delay, diversity, or residual-capacity preservation, take precedence. 11. Congestion Mitigation Congestion mitigation includes congestion avoidance and congestion response. Bandwidth management, path optimization, Container Tunnel normalization, or optimization of another managed TE construct can reduce the likelihood of congestion. Tactical mitigation addresses a specific current or anticipated condition; strategic mitigation addresses sustained demand and longer-term placement (Section 4.7 of [RFC9522]). The two are complementary and may use different measurement, computation, and control functions. 11.1. Recognizing Congestion A congestion indication identifies an affected resource and provides sufficient information to determine the observed utilization or severity, observation time, validity, and clearing condition. The indication may be obtained from periodic measurement, a state transition, or another realization-specific source. Policy may define high and low utilization thresholds. The high threshold identifies when congestion mitigation can be considered, while the low threshold identifies when the congestion condition has cleared. Requiring either condition to persist for a number of valid measurements or for a minimum duration reduces reactions to transient variation. Separation between the high and low thresholds provides hysteresis and reduces repeated activation and clearing near one boundary. Before selecting an action, the congestion indication is correlated with the traffic and TE constructs using the affected resource. Satisfying an activation condition starts an evaluation; it does not by itself require a bandwidth increase, path change, or traffic redistribution. 11.2. Tactical Congestion Mitigation Tactical mitigation provides a timely and bounded response to an active or anticipated congestion condition. It may use local resource state or a fast external computation to move eligible traffic away from the affected resource while broader optimization is pending or unnecessary. Sadhana & Jai Hari Expires 6 May 2027 [Page 39] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 The action may redirect selected traffic over an available alternative, adjust traffic distribution within the TE construct, or request another realization-specific change. TTE [I-D.li-rtgwg-tte] is an example of such a mechanism. It samples link utilization against high and low thresholds and, when a link is congested, activates existing backup paths (for example TI-LFA, RSVP- TE fast reroute, or Unequal Cost Multi-Path (UCMP) paths) in parallel with the primary path so that selected flows are shared across them. It deactivates those paths when the congestion clears. Policy can identify: * traffic eligible for mitigation; * permitted alternatives; * activation and clearing conditions; * limits on the traffic moved; and * limits on action frequency or duration. The selected alternative can be evaluated using available resource information because relieving one resource can create congestion elsewhere. The amount of traffic moved can therefore be bounded, and the result can be observed before additional traffic is redirected. When the clearing condition persists, the tactical state may be removed or reevaluated. Immediate removal after a single uncongested observation can cause oscillation, while retaining the state indefinitely can obscure the normal traffic pattern. 11.3. Strategic Congestion Mitigation Strategic evaluation may use longer measurement history and broader topology and resource information than tactical mitigation. It may retain the current state when no sufficiently beneficial or feasible alternative is available. The specific global optimization and path- selection algorithms are outside the scope of this document. 11.4. Coordination and Stability Tactical redirection can reduce traffic on the original path without reducing the offered demand. Statistics collected while redirection is active are therefore associated with the active traffic placement so that bandwidth estimation does not incorrectly interpret redirected traffic as a sustained demand decrease. Sadhana & Jai Hari Expires 6 May 2027 [Page 40] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 Strategic and tactical actions are coordinated when both affect the same traffic or resources. Before applying an action, the responsible function checks the current congestion condition, traffic placement, allocation, and available alternative capacity. Implementations can sequence conflicting actions and use persistence, hysteresis, rate limits, and retry backoff to reduce repeated traffic movement and oscillation. These controls bound control activity but do not guarantee global convergence. 12. Operational Considerations The operational requirements in this section apply to all managed TE constructs. The scope of statistics, accounting, optimization actions, and signaling remains specific to the applicable realization. 12.1. Configuration and Policy Policy may define: * statistics sources, polling profiles, and measurement windows; * bandwidth-evaluation and normalization intervals; * estimation methods and fallback behavior; * thresholds, persistence, hysteresis, and dampening; * bandwidth and member-count bounds; * priorities, path constraints, and protection objectives; * action-rate limits and retry behavior; and * failure handling behavior. When policy is obtained from multiple configuration levels, the implementation derives one unambiguous effective value for each parameter used by an evaluation. The implementation can reevaluate the TE construct when policy changes or defer the change until the next bandwidth evaluation. The change is applied with the disruption controls supported by the realization. Sadhana & Jai Hari Expires 6 May 2027 [Page 41] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 12.2. Telemetry and Observability Telemetry exposes the state needed to understand each bandwidth- management decision, including: * the latest usable statistics and their scope; * the estimated bandwidth requirement; * the current allocation and effective policy; * the effective path, member, or realization state; * pending and completed actions; * failure or deferral reasons; * any unsatisfied bandwidth requirement; and * the next eligible evaluation. For grouped constructs, the effective member set, per-member allocation and path state, aggregate allocation, and normalization status are observable. Action records identify whether an action was initiated periodically, by an event, by failover, by congestion, or by an operator. When model-based estimation is used, telemetry identifies the estimator version, input interval, result, and available quality information. Replacement or material retraining of the estimator is treated as a discontinuity, and pending state based on the previous estimator is revalidated. Action records use stable identifiers to correlate delegated computation, signaling, and retries. A record identifies the target, initiating condition, requested result, and final effective state. Retries are deduplicated so that a timeout does not apply the same action more than once. For a point-to-multipoint construct, observable state can include the effective leaf set, measurement scope, requested and effective bandwidth, and leaves affected by an incomplete action. For an MPTE construct, observable state can include ingress-specific requirements, the effective construct or version, junction bandwidths, next-hop shares, and unsatisfied ingress demand, when those concepts are exposed by the applicable realization. Sadhana & Jai Hari Expires 6 May 2027 [Page 42] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 12.3. Scaling Considerations Statistics collection, estimation, path computation, signaling, action queues, and telemetry have finite capacity. Their load increases with the number of managed objects, Member Tunnels, statistics sources, and the frequency of evaluation. Polling profiles, batching, thresholds, action-rate limits, and retry backoff may be used to control this load. In-place bandwidth updates (see Section 4.3.2) reduce the signaling load of each adjustment. The implementation reports unsuitable or dropped statistics, unavailable computation capacity, full action queues, configured bandwidth or member-count limits, and persistent unsatisfied requirements. Rate limiting or overload handling does not silently discard an unsatisfied requirement. 12.4. Failure Handling Failures may occur during statistics collection, estimation, computation, admission, or application of an action. Relevant failures include unavailable or invalid statistics, counter resets, stale resource information, inability to compute or admit a change, signaling rejection or timeout, loss of managed state, restart, duplicate actions, and incomplete multi-step actions. An action can be selected, pending, applying, completed, deferred, failed, partially completed, cancelled, or superseded; these are conceptual outcome states rather than a required implementation state machine. Missing statistics are not treated as zero traffic. An implementation can use policy-defined fallback behavior so that missing statistics neither stall evaluation indefinitely nor appear as a decrease in demand. When an action fails, recovery may retain the current usable state, refresh resource information, compute another result, retry, or restore previous state, as supported by the applicable realization. A timeout leaves the outcome unknown rather than proving failure. The Tunnel Originator reconciles the effective state before retrying and uses stable correlation information so that a delayed response or retry does not apply the same action twice. After restart, pending evaluations and actions are reconstructed or invalidated before new actions are applied. If a multi-step action completes only partially, the implementation may continue the remaining steps, restore the previous working state, or retain a policy-permitted partial state. Sadhana & Jai Hari Expires 6 May 2027 [Page 43] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 The observable result reflects the allocation, path, member set, and other managed state actually established, together with any unsatisfied bandwidth requirement. 12.5. Management Interfaces This section is a placeholder. A future revision is expected to describe how the state and policy described in this document relate to TE data models and management interfaces. 13. Stability of Distributed Control Loops Multiple Tunnel Originators, controllers, or local functions may react to the same traffic, congestion, topology, or resource event. Independent reactions can conflict, invalidate assumptions made during evaluation, shift congestion elsewhere, or trigger repeated adjustment attempts. The mechanisms described in this section are intended to reduce sustained instability and unnecessary control activity. They do not guarantee network-wide optimality or global convergence. [RFC9522] recommends that a trade-off between responsiveness and stability be made in favor of stability (Section 6.1 of [RFC9522]). 13.1. Sources of Instability Instability may result from: * measurement noise and short-lived traffic variation; * stale or inconsistent resource information; * simultaneous periodic or event-driven evaluations; * overlapping Container-level, Member-level, or tactical actions; * concurrent changes affecting shared resources; * preemption, restoration, or failover cascades; and * retries based on unchanged information. 13.2. Concurrency and Coordination Multiple evaluation cycles, controllers, or operational events may generate concurrent adjustment requests affecting the same managed construct. A realization can apply adjustment decisions in a consistent manner and can avoid committing actions based on information that is no longer valid. Sadhana & Jai Hari Expires 6 May 2027 [Page 44] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 13.2.1. Concurrent Evaluations A realization can execute multiple evaluation cycles simultaneously. When concurrent evaluations produce conflicting outcomes for the same managed construct, only one outcome can be committed. The selection method is implementation-specific and may be based on evaluation recency, policy priority, operational role, or other deployment- defined criteria. 13.2.2. Resource Changes During Evaluation Resource availability may change between evaluation and commitment. Before an adjustment is applied, the measurements, policy, allocation, topology, membership, and resource information used to select the adjustment can be revalidated when material changes may have occurred. If revalidation indicates that the original action is no longer appropriate, the realization may: * recompute the adjustment; * select an alternate adjustment; * defer the adjustment; or * abandon the adjustment. 13.2.3. Overlapping Adjustment Actions A new adjustment may target a managed construct that is already undergoing modification. A realization can: * allow compatible actions to proceed concurrently; * serialize actions; * merge compatible actions; or * supersede a pending action with a newer action. The selected behavior can avoid inconsistent allocation accounting and can prevent actions from repeatedly undoing one another. Sadhana & Jai Hari Expires 6 May 2027 [Page 45] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 13.2.4. Measurement and Adjustment Races Measurements collected during or immediately after an adjustment may reflect a mixture of pre-adjustment and post-adjustment conditions. Realizations can account for recently initiated actions so that measurements are interpreted against the effective pre-action, transitional, or post-action state. 13.2.5. Restart and State Reconciliation Following restart, loss of state, or transfer of responsibility between Tunnel Originators or other decision-making entities, a realization can reconcile the observed network state before initiating new adjustments affecting the same managed construct. Actions whose assumptions can no longer be validated may be deferred, recomputed, or discarded. 13.3. Preemption and Retries A higher-priority request can displace existing allocations and trigger additional path-selection or bandwidth-adjustment activity. This architecture does not define fairness among priority levels. A failed or deferred action is generally not retried solely on the basis of unchanged information. Retries are generally performed after measurements, topology information, policy inputs, or resource availability have been refreshed or revalidated. When action correlation is supported, delayed responses or timeouts can be associated with the original request, reducing the risk of duplicate action execution. 13.4. Stability Controls Policy may employ one or more of the following mechanisms: * thresholds; * persistence requirements; * hysteresis; * dampening; * sequencing; Sadhana & Jai Hari Expires 6 May 2027 [Page 46] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 * revalidation; * rate limiting; and * backoff. The selected controls can reflect the scope and timescale of the adjustment. For example, Container-level normalization may employ stronger persistence or dampening than adjustments to an existing Member Tunnel, while tactical congestion mitigation may use shorter reaction intervals together with stricter limits on traffic movement. To avoid conflicting outcomes, deployments are generally encouraged to perform bandwidth control for a given managed traffic flow at a single level of hierarchy, such as either the Member Tunnel or the Container Tunnel, rather than allowing multiple control loops to independently adjust the same bandwidth objective. 14. Security Considerations This architecture defines no protocol and introduces no security issues beyond those of the TE technologies, signaling protocols, and management interfaces used to realize it. The general security considerations of TE are discussed in Section 9 of [RFC9522] and apply here. The security considerations of the protocols and mechanisms used for statistics collection, path computation, signaling, and TE control continue to apply. In particular, an RSVP- TE realization inherits the security considerations of RSVP-TE [RFC3209] and the MPLS/GMPLS security framework [RFC5920]. Measurements, policy, resource state, and action requests are trusted control inputs. Modification, replay, suppression, or delay of these inputs can cause incorrect bandwidth allocation, unauthorized path changes, resource exhaustion, repeated actions, or denial of service. Interfaces carrying such information can provide authentication, integrity protection, authorization, freshness checking, and auditability appropriate to the deployment. These protections address active attacks such as replay, insertion, deletion, and modification described in [RFC3552]. Authorization can limit each entity to its assigned TE constructs and permitted actions. Delegated statistics collection or computation does not grant authority to modify bandwidth, paths, membership, or traffic distribution. Traffic measurements, traffic matrices, and per-construct allocations reveal the load on the network and its remaining capacity. They can expose commercially sensitive information or help an attacker select Sadhana & Jai Hari Expires 6 May 2027 [Page 47] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 targets (Section 9 of [RFC9522]). Interfaces that carry measurements, policy, or adjustment requests, including those to an offloaded estimation or computation entity, need protection against disclosure as well as modification. When PCEP is used, the recommendation to use authenticated and encrypted sessions applies [RFC8253]. Automatic resizing can be abused to create control-plane load. Forged or manipulated measurements, or poorly chosen policy parameters, can cause repeated resignaling, preemption cascades, or oscillation (Sections 4.3 and 7 of [RFC8733]). The stability controls in Section 13 limit the impact, and the policy that sets them needs the same integrity protection as other TE configuration. An external entity that performs computation or estimation for a Tunnel Originator is a trusted input. The Tunnel Originator authenticates it, authorizes it for the constructs it serves, and revalidates its results before acting on them, as described in Section 4.3.1. False high measurements can cause excessive resource allocation, while false or stale low measurements can cause unsafe reductions. Implementations can validate statistics sources and use policy bounds, persistence, rate limits, and anomaly detection. Missing or invalid statistics are not interpreted as zero demand. Multi-step or grouped actions can affect several tunnels or resources. Stable action identifiers, current-state validation, effective-state reporting, and audit records reduce the risk of replayed, duplicated, or partially applied changes. Realization-specific procedures use the authentication, authorization, integrity, and confidentiality mechanisms defined by their applicable signaling and control specifications. Where an applicable specification has incomplete security considerations, this document does not infer protections that the realization has not defined. 15. IANA Considerations This document has no IANA actions. 16. Informative References [I-D.ietf-teas-rsvp-inplace-lsp-bw-update] Ali, Z., Beeram, V. P., and P. Schoenmaker, "In-Place Bandwidth Update for MPLS RSVP-TE LSPs", Work in Progress, Internet-Draft, draft-ietf-teas-rsvp-inplace-lsp-bw- Sadhana & Jai Hari Expires 6 May 2027 [Page 48] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 update-01, 5 July 2026, . [I-D.kompella-teas-mpte] Kompella, K., Jalil, L., Khaddam, M., Geyer, N., and A. Smith, "Multipath Traffic Engineering", Work in Progress, Internet-Draft, draft-kompella-teas-mpte-04, 8 October 2026, . [I-D.li-rtgwg-tte] Barth, C., Li, T., Smith, A., Wen, B., and L. Jalil, "Tactical Traffic Engineering (TTE)", Work in Progress, Internet-Draft, draft-li-rtgwg-tte-02, 3 December 2024, . [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, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, May 2005, . [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, DOI 10.17487/RFC4427, March 2006, . [RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, DOI 10.17487/RFC4736, November 2006, . [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Sadhana & Jai Hari Expires 6 May 2027 [Page 49] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, . [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, . [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, January 2017, . [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, . [RFC8577] Sitaraman, H., Beeram, V., Parikh, T., and T. Saad, "Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane", RFC 8577, DOI 10.17487/RFC8577, April 2019, . [RFC8733] Dhody, D., Ed., Gandhi, R., Ed., Palle, U., Singh, R., and L. Fang, "Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE", RFC 8733, DOI 10.17487/RFC8733, February 2020, . [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, . [RFC9522] Farrel, A., Ed., "Overview and Principles of Internet Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522, January 2024, . Appendix A. Examples This appendix is a placeholder. A future revision is expected to include examples such as the following: * auto-bandwidth for an RSVP-TE tunnel, including make-before-break; Sadhana & Jai Hari Expires 6 May 2027 [Page 50] Internet-Draft Distributed Bandwidth Mgmt Arch November 2026 * splitting and reducing the Member Tunnels of a Container Tunnel; and * bandwidth management for an SR Policy. Acknowledgements The authors thank Sudharsana Venkatraman for providing feedback on the concepts discussed in this document. Contributors Vishnu Pavan Beeram HPE Email: vishnupavan.ietf@gmail.com Colby Barth HPE Email: jonathan.barth@hpe.com Authors' Addresses Sadhana Mani Arasu HPE Email: sadhana.mani-arasu@hpe.com Jai Hari M K HPE Email: jaihari.mk@hpe.com Sadhana & Jai Hari Expires 6 May 2027 [Page 51]