RSVP Extensions for Rate-based Resource Quota

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/.¶

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 3 September 2026.¶

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

The increasing number of job-based applications (e.g., AI/HPC, video conferencing, cloud gaming) demand for high-throughput, low-latency communications over WANs. To ensure efficient transmission of these services in the network and avoid congestion, the network can establish tunnels and reserve resources based on the requirements, guaranteeing high-throughput transmission within the job's completion time.¶

A job decomposed into multiple tasks for parallel transmission results in the concurrent transmission of multiple flows. Traditional congestion control mechanisms implemented on hosts lack rate controls, resulting in unbounded rate adjustments. The static resource allocation methods can provide QoS guarantee to imigrate the congestion for the job. But in multi-flow communications, network bandwidth is shared among multiple flows, leading to suboptimal performance, including slow-flow (tailing) and throughput degradation as follows.¶

*Slow-flow tailing: when one flow experiences congestion, it can delay others.¶

*Throughput inefficiency: static bandwidth allocation for multi-flows may over/under-utilize resources.¶

*Lack of synchronization: multi-flows may arrive with different delays, disrupting the synchronization of group communication.¶

The network should provide efficient resource reservation mechanisms at nodes along the path. This is not bandwidth allocation but rather quota reservation, which can be used for admission control. Quota is expressed as a vector of resource quantities (bandwidth, buffer, queue, etc.) for a given time frame. The network can make dynamic resource reservation for different time frames defined by quota. The network nodes can reserve resource quota based on rate control for each flow. For example, it could reserve the minimum bandwidth quota to guarantee the minimum rate of multiple flows and schedule dynamic resources to achieve the maximum rate.¶

This document proposes RSVP extensions for rate-based resource quota to enable dynamic resource reservation, achieving effective rate control in multi-flow data transmission.¶

2. Conventions Used in This Document

3. RSVP Signalling for Rate-based Resource Quota Reservation

The network needs to perform the admission control based on available capacity after receiving the flow transmission request. The request will be accepted when the rate-based resource quota reservation succeeds; otherwise, it will be rejected. When the network reserves the resource quota based on the minimum rate of the flow and scheduled the resource based on the maximum rate, the traffic can be transmitted within the controlled range of rates to guarantee the completion time and the throughput among multiple flows.¶

The network performs dynamic resource reservation for different time frames defined by quota as follows.¶

• The ingress node sends Path message to request the resource quota while carrying the Quota Object (Section 4.1.1) to indicate the required resource (e.g., bandwidth, buffer, queue) within a time frame. The resource quota can be computed based on the minimum rate of the flow.¶

• The transit node receiving a Path message needs to check the resources allocated for the service and transfer it to the next node. When the remaining resources are not enough for the requested quota, it needs to reply with a PathErr message.¶

• The egress node receiving the Path message needs to check the output resources and return a Resv message carrying the Quota Object (Section 4.1.1) and RateControl Object (Section 4.1.2) to indicate the maximum rate of the flow.¶

• The network nodes receiving the Resv message need to reserve the resource quota within a time frame, but not allocate it while the traffic in the network is still sharing the resources. For example, the nodes need to subtract the resource quota within the time frames and the subtraction result will be viewed as the resource constraints for admission control.¶

• The egress node may send a Notify message carrying RateControl Object to update the maximum rate of the flow.¶

• When the data transmission is completed, the resource quota will be released with PathTear and ResvTear messages.¶

 +------------+             +------------+             +-----------+
 |Ingress Node|             |Transit Node|             |Egress Node|
 +-----+------+             +-----+------+             +-----+-----+
       |                          |                          |
       |Path message              |Path message              |
       |(request resource quota)  |(request resource quota)  |
       |------------------------->|------------------------->|
       |<-------------------------|<-------------------------|
       |Resv message              |Resv message              |
       |(reserve rate-based quota)|(reserve rate-based quota)|
       |                          |                          |
       |Notify message            |                          |
       |(update dynamic resource and rate)                   |
       |<----------------------------------------------------|
       |                          |                          |
       |PathTear message          |PathTear message          |
       |(request resource quota)  |(request resource quota)  |
       |------------------------->|------------------------->|
       |<-------------------------|<-------------------------|
       |ResvTear message          |ResvTear message          |
       |(release rate-based quota)|(release rate-based quota)|
       |                          |                          |
       |                          |                          |
       V                          V                          V

      Figure 1 RSVP Signaling for Rate-based Resource Quota Reservation

4. RSVP Extensions

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Length (bytes)          |   Class Num   |    C-Type     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Min-Rate                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Max-Rate                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         Figure 2  RateControl Object

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Length (bytes)          |   Class Num   |    C-Type     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Quota Type              |        Time Unit Type         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Start Time                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         End Time                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                      optional TLVs                            ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            Figure 3 Quota Object

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Bandwidth                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Figure 4 Bandwidth Quota TLV

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Timeslot/Cycle                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        Figure 5 Time-based Quota TLV

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Queue ID                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        Figure 6 Queue Quota TLV

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Buffer                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 7 Buffer Quota TLV

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         CPU size                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Figure 8 CPU Quota TLV

5. Security Considerations

The security considerations specified in [RFC2205] and [RFC4860] apply to this document. In addition, [RFC4230] and [RFC6411] provide useful guidance on RSVP security mechanisms.¶

The network nodes need to perform quota-based resource computation and reservation based on authentication (e.g.,[RFC2747] and [RFC3097]) and authorization (e.g.,[RFC6749]).¶

6. IANA Considerations

TBA.¶

7. Informative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC2205]

Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/rfc/rfc2205>.

[RFC2747]

Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, DOI 10.17487/RFC2747, January 2000, <https://www.rfc-editor.org/rfc/rfc2747>.

[RFC3097]

Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, DOI 10.17487/RFC3097, April 2001, <https://www.rfc-editor.org/rfc/rfc3097>.

[RFC4230]

Tschofenig, H. and R. Graveman, "RSVP Security Properties", RFC 4230, DOI 10.17487/RFC4230, December 2005, <https://www.rfc-editor.org/rfc/rfc4230>.

[RFC4860]

Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M. Davenport, "Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations", RFC 4860, DOI 10.17487/RFC4860, May 2007, <https://www.rfc-editor.org/rfc/rfc4860>.

[RFC6411]

Behringer, M., Le Faucheur, F., and B. Weis, "Applicability of Keying Methods for RSVP Security", RFC 6411, DOI 10.17487/RFC6411, October 2011, <https://www.rfc-editor.org/rfc/rfc6411>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

Authors' Addresses