| Internet-Draft | Signaling Solution for HP-WAN | July 2025 |
| Xiong, et al. | Expires 8 January 2026 | [Page] |
This document proposes a technical solution for the host-network collaboration signaling to enhance the congestion control in High-Performance Wide Area Networks (HP-WAN). It also describes the RSVP extensions as an instantiation of this signaling solution.¶
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 8 January 2026.¶
Copyright (c) 2025 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.¶
Data-intensive applications always demand high-speed data transmission over WANs such as scientific research, academia, education as discussed in [I-D.kcrh-hpwan-state-of-art] and other applications in public networks as per [I-D.yx-hpwan-uc-requirements-public-operator]. The specific HP-WANs applications mainly focus on job-based timely transmission over long-distance WANs and high-throughput with efficient use of capacity is the fundamental requirement for HP-WAN. But it faces the challenges such as poor convergence speed, long feedback loop, and unscheduled traffic as per [I-D.xiong-hpwan-problem-statement]. [I-D.xhy-hpwan-framework] defined a framework to enable the host-and-network collaboration for the high-speed and high-throughput data transmission.¶
This document proposes a technical solution for the host-network collaboration signaling to enhance the congestion control in HP-WAN. It also describes the RSVP extensions as an instantiation of the signaling solution.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses the terms defined in [I-D.kcrh-hpwan-state-of-art] and [I-D.xiong-hpwan-problem-statement].¶
As per [I-D.xhy-hpwan-framework], HP-WAN framework proposes to enhance the congestion control for the host and network collaboration especially the rate negotiation. It is required to guarantee the completion time of the traffic based on the different rate policy. The host-network collaboration includes:¶
The host needs to send job-based requests to the network to negotiate the sending rate before data transmission;¶
The network needs to schedule the requests and perform the admission control based on available capacity. The network performs dynamic resources reservation upon different time frames defined by quota. The nodes need to subtract the resource quota within the time frames, but not reserve it while the traffic in the network are still sharing the resources. The subtraction result will be viewed as the resources constraints for the admission control. The request will be accepted when the rate-based resource quota reservation is succeed, otherwise, it will be rejected.¶
After the acknowledgement of the rate negotiation, the client could transmit the job-based flows at a sending rate based on the rate policy.¶
As per [I-D.xhy-hpwan-framework], the host will request the network to provide the minimum resource guarantee in minimum rate negotiation policy. The network implements the admission control based on the minimum resource quota reservation at the nodes along the path. After the acknowledgement of the minimum rate negotiation, the client could transmit the job-based flows at a sending rate not less than the minimum rate.¶
The minimum rate can be computed as following:¶
Min-rate = Flowsize/(CompletionTime-StartTime)¶
For example, the client requests to transfer the job with 10G data volume from 10s to 20s. The minimum rate will be 10G/(20s-10s)=1Gbps. The network will subtract 1G bandwidth quota from 10s to 20s and the admission of this job is accepted. The client could transfer this job with rate no less than 1Gbps.¶
As per [I-D.xhy-hpwan-framework], the host will request the network to provide an upper limit for resource guarantee in maximum rate negotiation policy. The network implements the admission control based on the maximum resource quota reservation at the bottleneck nodes along the path. The acknowledgement of the maximum rate negotiation, the client could transmit the job-based flows at a sending rate not greater than the maximum rate.¶
The maximum rate of a flow on a specific link is related to the link bandwidth and the number of aggregated traffic flows. When more flows are aggregated, the maximum rate of each individual flow decreases. Conversely, with fewer aggregated flows, each flow can achieve a higher maximum rate, ensuring the buffer does not overflow and congestion is mitigated. Multiple hops along the path could calculate a set of maximum rates, the negotiated maximum rate for a flow transmitting along the path is the minimum value within the maximum rates.¶
The maximum rate can be computed as following:¶
Max-rate = a*Bandwidth/FlowNumber¶
a is an expansion coefficient which is set based on network buffer information.¶
For example, if the the bandwidth of the bottleneck node is 10G, a is 1.5, and two flows aggregates through this node, the maximum rate will be 1.5*10G/2=7.5Gbps. The client could transfer this job with rate no greater than 7.5Gbps within the time frame.¶
As per [I-D.xhy-hpwan-framework], the host will request the network to provide constant resource reservation for high-speed data to guarantee optimal rate transmission in constant rate negotiation policy. The network implements the admission control based on the constant resource quota reservation at the nodes along the path. The acknowledgement of the constant rate negotiation, the client could transmit the job-based flows at a sending rate according to the negotiated constant rate or optimal rate range.¶
The constant rate can be computed as the minimum rate or the controller could perform high-level resources planning and allocate optimal rates for the time frames with multiple intervals.¶
For example, the constant rates could be like {(10s~20s,10Gbps), (20s~30s,2Gbps)}.¶
As per [I-D.xhy-hpwan-framework], the negotiated rate-based congestion control can be enabled through host-network collaboration signaling. There are several options for the signaling procedures as following sections.¶
The host-network collaboration signaling can be implemented as stitching signaling between host-network and in-network. The P2P signaling (e.g GRASP and RSVP) can be provisioned between the client and the network edge node. Dynamic resources quota reservation signaling along network nodes can be achieved within the network. The workflow is shown in Figure 1.¶
The requests of scheduled traffic will be signaled through P2P signaling from the client to the edge node carrying the traffic pattern and job-based requirements.¶
The edge node will configure the rate policy, compute the negotiated rate and resource quota, and perform traffic scheduling. And it will also initial the resources quota reservation signaling in the network to perform the admission control at the nodes along the path. The edge node will send the negotiated rate after the traffic is acknowledged or updated.¶
The client will notify the edge node when the data transmission is completed. The resources quota will be released and acknowledgement is canceled.¶
+--------+ +-----------+ +------------+ +-----------+
| Client | | Edge Node | |Transit Node| | Edge Node |
+----+---+ +-----+-----+ +-----+------+ +-----+-----+
| | | |
|Request(traffic pattern) | | |
|------------------------>|*Rate negotiation | |
| |*Traffic scheduling| |
| | *Admission control |
| | *Reserve resource quota |
|Acknowledgement |<.................>|<....................>|
|(negotiated rate) | | |
|<------------------------| | |
|New Request | | |
|------------------------>| | |
|Update(negotiated rate) | | |
|<------------------------| | |
|Notification(completion) | | |
|------------------------>| *Release resource quota |
|Acknowledgement(cancel) |<.................>|<....................>|
|<------------------------| | |
| | | |
V V V V
|<----------------------->|<........................................>|
P2P signaling between client Quato Reservation signaling
and network edge node along network nodes
Figure 1 Stitching signaling
¶
The host-network collaboration signaling can be implemented as hop-by-hop signaling (e.g.RSVP). It can be end-to-end provisioned along the path from client, edge nodes, network nodes and server. The workflow is shown in Figure 2.¶
The client configures the rate policy and computes the negotiated rate and the resource quota based on the traffic requirements of the job. And it will also initial the resources quota reservation signaling to perform the admission control hop-by-hop along the path.¶
The client will release resources quota when the data transmission is completed.¶
+--------+ +-----------+ +---------------+ +-----------+ +--------+
| Client | | Edge Node | | Transit Node | | Edge Node | | Server |
+----+---+ +-----+-----+ +-------+-------+ +-----+-----+ +----+---+
|*Rate negotiation | | | |
| *Admission control |
| *Reserve resource quota |
|<----------------------->|<----------------->|<-------------------->|<---------------->|
| | | | |
| *Release resource quota |
|------------------------>|<----------------->|<-------------------->|<---------------->|
| | | | |
V V V V V
|<------------------------------------------------------------------------------------->|
Hop-by-hop signaling along the client, network nodes and server
Figure 2 Hop-by-hop signaling
¶
The host-network collaboration signaling can be implemented as overlay signaling to alleviate the operational and scalability issues. It can be end-to-end signaling (e.g. RSVP-TE) provisioned along the path from client, bottleneck nodes, and server. It will largely improve the hop-by-hop signaling through TE technologies such as Segment Routing (SR), network slicing and RSVP-TE approaches. It only needs to perform resource quota reservation-based admission control at ingress and egress edge nodes and bottleneck nodes. The workflow is shown in Figure 3.¶
The requests of scheduled traffic will be signaled through overlay signaling from the client to the edge node carrying the traffic pattern and job-based requirements.¶
The edge node will configure the rate policy, compute the negotiated rate and resource quota, and perform traffic scheduling. And it will also initial the negotiated rate-based traffic engineering to establish the TE tunnels. And the overlay signaling will be replaced to the resources quota reservation signaling in the network to perform the admission control at the edge nodes and bottleneck nodes along the path. The edge node will send the negotiated rate after the traffic is acknowledged or updated (when new requests are received).¶
The client will notify the edge node when the data transmission is completed. The resources quota will be released and acknowledgement is canceled.¶
+--------+ +-----------+ +---------------+ +-----------+ +--------+
| Client | | Edge Node | |Bottleneck Node| | Edge Node | | Server |
+----+---+ +-----+-----+ +-------+-------+ +-----+-----+ +----+---+
| | | | |
|Request(traffic pattern) | | | |
|------------------------>|*Rate negotiation | | |
| |*Traffic scheduling| | |
| | *Admission control | |
| | *Reserve resource quota | Request |
|Acknowledgement |<----------------->|<-------------------->|<---------------->|
|(negotiated rate) | | | Acknowledgement | Acknowledgement
|<------------------------|*Negotiated rate-based traffic engineering| |
| |<########################################>| |
|New Request | | | |
|------------------------>| | | |
|Update(negotiated rate) | | | |
|<------------------------| | | |
|Notification(completion) | | | |
|------------------------>| *Release resource quota | Notification |
|Acknowledgement(cancel) |<----------------->|<-------------------->|<---------------->|
|<------------------------| | | Acknowledgement |
| | | | |
V V V V V
|<------------------------------------------------------------------------------------->|
Overlay signaling along the client, edge nodes, bottleneck nodes and server
Figure 3 Overlay signaling
¶
RSVP protocols can be instantiated to implement the host-network collaboration signaling. This document proposes the RSVP extensions to achieve the provisioning of the job-based request and acknowledgement, resource quota reservation and release.¶
This document proposes the Traffic Pattern Object to carry the traffic pattern and job-based requirements, such as traffic characteristic parameters.¶
The format of Traffic Pattern Object is shown in Figure 4.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Job ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Time(s/ms) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Completion Time(s/ms) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Volume (GB) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 Traffic Pattern Object
¶
Job ID: 32bits, indicates the identifier of the Job.¶
Start Time: 32bits, indicates the time when it starts to transmit the flows.¶
Completion Time: 32bits, indicates the deadline time when it requires to complete the transmission.¶
Data Volume: 32bits, indicates the data volume of the job which needs to transfer.¶
This document proposes the Rate Object to carry the negotiated rate which is acknowledged. The format of Rate Object is shown in Figure 5.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Job ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rate Policy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 Rate Object
¶
Job ID: 32bits, indicates the identifier of the Job.¶
Rate Policy: 32bits, indicates the type of the rate policy such as minimum, maximum and optimal rate policy.¶
optional TLVs: variable length and multiple TLVs can be carried when multiple intervals are computed. The Time frame TLV is shown in Figure 6.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rate(bit/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Time(s/ms) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Time(s/ms) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 Time frame TLV
¶
Rate: 32bits, indicates the value of negotiated rate.¶
Start Time: 32bits, indicates the start time of the time frame.¶
End Time: 32bits, indicates the end time of the time frame.¶
This document proposes the Quota Object to carry the resources quota information. The format of Quota Object is shownin Figure 7.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Job ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rate Policy | Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Quota Type | Time Unit Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 Quota Object
¶
Job ID: 32bits, indicates the identifier of the Job.¶
Rate Policy: 16bits, indicates the type of the rate policy such as minimum, maximum and optimal rate policy.¶
Rate: 16bits, indicates the value of negotiated rate.¶
Quota Type: 16bits, indicates the type of resource quota, including the bandwidth, buffer, queue, CPU size etc.¶
Time Unit Type: 16bits, indicates the type of time unit, including second, microsecond, millisecond and minute.¶
Start Time: 32bits, indicates the start time of the time frame.¶
End Time: 32bits, indicates the end time of the time frame.¶
optional TLVs: variable length and multiple TLVs can be carried to indicate the resource quota.¶
This document proposes the Quotaconf Object to carry the configuration and notification of quota information. The format of Quotaconf Object is shownin Figure 8.¶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |C|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Receiver IP list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 Quotaconf Object
¶
R: 1bit, when it is set to 0, it indicates the succeed of quota reservation, otherwise indicates failure.¶
C: 1bit, when it is set to 0, it indicates releasing the quota, otherwise it is not required. Receiver IP list: variable, it indicates the IP addresses of the nodes which should configure to.¶
This document proposes the new messages or reuse the existing messages to achieve the communication of signaling. The format of the new messages is shown in Figure 9.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |Flags | Message Type | RSVP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send_TTL | Reserved | RSVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9 RSVP Message Header
¶
The JobRequest message with new Message Type (TBD1) can be used for job-based request and quota reservation request. The client can send the JobRequest message and the Traffic Pattern Object must be included. The edge node can send quota reservation request and the Quota Object must be included.¶
The quota reservation response message adds a Response message conveying success or failure status. The quota release request message introduces a Cancel message containing quota release details, while the quota release response message incorporates a Response message indicating success or failure acknowledgment.¶
The JobResponse message with new Message Type (TBD2) can be used for job-based acknowledgement and quota reservation response. The edge node can send JobResponse message with the Rate object included when the traffic is acknowledged. The transit nodes can send JobResponse message to the upstream node with the Quotaconf object included when the admission the rejected. And the edge node can send JobResponse message when the admission the accepted.¶
The JobResponse message with new Message Type (TBD3) can be used for job-based update with the Rate object included with new rate related parameters.¶
The JobResponse message with new Message Type (TBD4) can be used for job-based notification to indicate the traffic transmission is completed.¶
The JobResponse message with new Message Type (TBD5) can be used for job-based cancelation to indicate the acknowledgement is canceled.¶
As per [I-D.xhy-hpwan-framework], the host and the network could interact and negotiate the sending rate due to the predictability of jobs. The client will send the request with the traffic patterns of high-speed flows and the network will reserve the corresponding resource quota and perform the admission control based on the capacity of network nodes.¶
If the network deployment is Software-Defined Network (SDN) centralized architecture, the controller will perform resource quota reservation and admission control. For instance, for the SDN for End-to-end Networked Science at Exascale (SENSE) system in Research and Education (R&E) networks, the orchestrator and resource Manager (RM) have the capability of hierarchical planning and resource reservation in the network. The orchestrator communicates the requests from applications and interacts with the RM for resource reservation.¶
The security considerations specified in [RFC2205] and [RFC4860] apply to this document. In addition, [RFC4230] and [RFC6411] provide useful guidance on RSVP security mechanisms.¶
It is also required to create the trusted relationship between the clients and the network. The network needs to perform quota-based resource computation and reservation based on authentication (e.g.[RFC2747] and [RFC3097]) and authorization (e.g.[RFC6749]).¶
TBA.¶