Signaling Solution for HP-WAN
draft-xiong-hpwan-signaling-solution-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Quan Xiong , Xiangyang Zhu , Changwang Lin | ||
| Last updated | 2026-03-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-xiong-hpwan-signaling-solution-01
hpwan Q. Xiong
Internet-Draft X. Zhu
Intended status: Standards Track ZTE Corporation
Expires: 3 September 2026 C. Lin
New H3C Technologies
2 March 2026
Signaling Solution for HP-WAN
draft-xiong-hpwan-signaling-solution-01
Abstract
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.
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.
Xiong, et al. Expires 3 September 2026 [Page 1]
Internet-Draft Signaling Solution for HP-WAN March 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Job-based Host-network Collaboration . . . . . . . . . . . . 3
4. The Rate Negotiation Policy for Host-network Collaboration . 4
4.1. Minimum Rate Negotiation . . . . . . . . . . . . . . . . 4
4.2. Maximum Rate Negotiation . . . . . . . . . . . . . . . . 5
4.3. Constant Rate Negotiation . . . . . . . . . . . . . . . . 5
5. Host-network Collaboration signaling . . . . . . . . . . . . 6
5.1. Stitching signaling . . . . . . . . . . . . . . . . . . . 6
5.2. Overlay signaling . . . . . . . . . . . . . . . . . . . . 7
6. Instantiation with RSVP Extensions . . . . . . . . . . . . . 8
6.1. Objects Extensions . . . . . . . . . . . . . . . . . . . 9
6.1.1. Job Object . . . . . . . . . . . . . . . . . . . . . 9
6.1.2. Traffic Pattern Object . . . . . . . . . . . . . . . 9
6.1.3. Rate Object . . . . . . . . . . . . . . . . . . . . . 10
6.2. Message Extensions . . . . . . . . . . . . . . . . . . . 12
6.2.1. JobRequest Message . . . . . . . . . . . . . . . . . 12
6.2.2. JobAcknowledgement Message . . . . . . . . . . . . . 12
6.2.3. TaskRequest Message . . . . . . . . . . . . . . . . . 13
6.2.4. TaskResponse Message . . . . . . . . . . . . . . . . 13
6.2.5. TaskUpdate Message . . . . . . . . . . . . . . . . . 13
6.2.6. JobNotify Message . . . . . . . . . . . . . . . . . . 13
6.2.7. JobCancel Message . . . . . . . . . . . . . . . . . . 13
7. Considerations for the Centralized Solution . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
Data-intensive applications, such as scientific research, academia,
and education, always demand high-speed data transmission over WANs,
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]. HP-WAN applications
mainly focus on job-based timely transmission over long-distance
WANs. High throughput with efficient use of capacity is the
fundamental requirement for HP-WAN. However, HP-WAN faces challenges
such as poor convergence speed, long feedback loop, unscheduled
traffic and multi-flow concurrent transmission as per
[I-D.xiong-hpwan-problem-statement]. [I-D.xhy-hpwan-framework]
Xiong, et al. Expires 3 September 2026 [Page 2]
Internet-Draft Signaling Solution for HP-WAN March 2026
defines a framework to enable the host-and-network collaboration for
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.
2. Conventions used in this document
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.2. Terminology
This document uses the terms defined in [I-D.kcrh-hpwan-state-of-art]
and [I-D.xiong-hpwan-problem-statement].
3. Job-based Host-network Collaboration
The requirement for Host-network collaboration originates from the
transmission demands of intelligent computing jobs over WANs. The
network can establish the tunnels based on hosts' demands, reserve
resources, and ensure high-throughput transmission of jobs' workloads
within their completion deadlines. The definitions of Job and Task
are as follows.
* Job: An intelligent computing service and a single Job is
decomposed into multiple tasks for parallel transmission over the
WAN.
* Task: A peer-to-peer (P2P) network transmission task triggered by
intelligent computing or data transmission. Each task corresponds
to a long-lived traffic flow.
Xiong, et al. Expires 3 September 2026 [Page 3]
Internet-Draft Signaling Solution for HP-WAN March 2026
For HP-WAN, the host-network collaboration can be divided into two
phases: job-based tunnel establishment and task-based resource
scheduling. Job-based tunnel establishment indicates that the per-
job traffic engineering (TE) tunnel setup is triggered by the
intelligent computing Job from the hosts. For example, a Job
scheduler triggers one or more hosts to initiate tunnel establishment
toward the network based on job's requirements. Task-based resource
scheduling refers to the dynamic tunnel resource utilization for
concurrent tasks based on rate control.
4. The Rate Negotiation Policy for Host-network Collaboration
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 different rate policies. 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 resource reservation across different time frames
defined by quota. For example, the nodes need to subtract the
resource quota within the time frames, but not allocate it while
traffic in the network is still sharing the resources.
The subtraction result will be viewed as the resource constraints
for admission control. The request will be accepted when the
rate-based resource quota reservation succeeds; 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.
4.1. Minimum Rate Negotiation
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 follows:
Xiong, et al. Expires 3 September 2026 [Page 4]
Internet-Draft Signaling Solution for HP-WAN March 2026
* 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.
4.2. Maximum Rate Negotiation
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 scheduling at the edge node of the
path. After 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 follows:
* Max-rate = a*Bandwidth/FlowNumber
a is an expansion coefficient which is set based on network buffer
information.
For example, if the the output bandwidth of the edge node is 10G, a
is 1.5, and two flows aggregate 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.
4.3. Constant Rate Negotiation
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.
After the acknowledgement of the constant rate negotiation, the
Xiong, et al. Expires 3 September 2026 [Page 5]
Internet-Draft Signaling Solution for HP-WAN March 2026
client could transmit the job-based flows at a sending rate according
to the multiple negotiated constant rates within corresponding time
frames.
The constant rates 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)}.
5. Host-network Collaboration signaling
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
described in the following sections.
5.1. Stitching signaling
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 resource
quota reservation signaling along network nodes can be achieved
within the network. The workflow is shown in Figure 1.
* The requests of jobs will be signaled through P2P signaling from
the client to the edge node carrying the job-based requirements.
* The edge node and perform admission control while triggering the
network to establish the TE tunnel for the job. The edge node
will send the success or failure for the acknowledgement result.
* The requests of scheduled traffic will be signaled through P2P
signaling from the client to the edge node carrying the traffic
requirements of tasks.
* The edge node will configure the rate policy, compute the
negotiated rate, and initiate the rate control and resource
scheduling based on the resources of the established TE tunnel and
the edge nodes. It will reply with the rate information for the
task when the resource quota is successfully reserved. It will
also notify the client when the resource quota is updated.
* The client will notify the edge node when the data transmission is
completed. The network resources will be released and the
acknowledgement is cancelled.
Xiong, et al. Expires 3 September 2026 [Page 6]
Internet-Draft Signaling Solution for HP-WAN March 2026
+--------+ +-----------+ +-----------+
| Client | | Edge Node | | Edge Node |
+----+---+ +-----+-----+ +-----+-----+
|JobRequest | |
|(job parameters) | |
|-------------------->|*Admission control |
|<--------------------|<...*Job-based traffic engineering...>|
|JobAcknowledgement | |
|(success or failure) | |
| | |
|TaskRequest | |
|(traffic pattern) | |
|-------------------->|*Rate negotiation |
|TaskResponse |*Rate control and resource scheduling |
|(negotiated rate) |<...*Reserve the resource quota......>|
|<--------------------| |
|TaskUpdate | |
|(negotiated rate) |<...*Update the resource quota.......>|
|<--------------------| |
| | |
|JobNotify(completion)| |
|-------------------->| |
|JobCancel(cancel) |<...*Release the network resources...>|
|<--------------------| |
| | |
V V V
|<------------------->|<....................................>|
P2P signaling between client Rate-based traffic engineering
and network edge node along network nodes
Figure 1 Stitching signaling
5.2. Overlay signaling
The host-network collaboration signaling can be implemented as
overlay signaling. It can be end-to-end signaling (e.g., RSVP)
provisioned along the path from client, network nodes, and server.
The rate-based traffic engineering along network nodes will be
triggered as underlay signaling. The workflow is shown in Figure 2.
Xiong, et al. Expires 3 September 2026 [Page 7]
Internet-Draft Signaling Solution for HP-WAN March 2026
+--------+ +-----------+ +-----------+ +--------+
| Client | | Edge Node | | Edge Node | | Server |
+----+---+ +-----+-----+ +-----+-----+ +----+---+
|JobRequest | | |
|(job parameters) | | |
|-------------------->|*Admission control | |
| |<...*Job-based traffic engineering...>| |
|JobAcknowledgement | |JobRequest |
|(success or failure) | |<---------------->|
|<--------------------| |JobAcknowledgement|
| | | |
|TaskRequest | | |
|(traffic pattern) | | |
|-------------------->|*Rate negotiation | |
|TaskResponse |*Rate control and resource scheduling | |
|(negotiated rate) |<...*Reserve the resource quota......>|<---------------->| |TaskResponse |
|<--------------------| |TaskRequest |
|TaskUpdate | | |
|(negotiated rate) |<...*Update the resource quota.......>| |
|<--------------------| | |
| | | |
|JobNotify(completion)| | |
|-------------------->| | JobNotify |
|JobCancel(cancel) |<...*Release the network resources...>|<---------------->|
|<--------------------| | JobCancel |
| | | |
V V V V
|<....................................>|
Rate-based traffic engineering along network nodes
|<------------------------------------------------------------------------------>|
Overlay signaling along the client, edge nodes and server
Figure 2 Overlay signaling
6. Instantiation with RSVP Extensions
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, task-based request and response, task-based update
and job-based notification and cancellation. This document focuses
on the host-network collaboration signaling including the P2P
signaling between client and network edge node and the overlay
signaling along the client, edge nodes, and server. The procedures
and extensions for rate-based traffic engineering within the network
will be in a separate document as per
[I-D.xiong-teas-rsvp-resource-quota].
Xiong, et al. Expires 3 September 2026 [Page 8]
Internet-Draft Signaling Solution for HP-WAN March 2026
6.1. Objects Extensions
6.1.1. Job Object
This document proposes the Job Object to carry the job-based
parameters and requirements, such as job ID, job size, job type, job
models and other parameters.
The format of Job Object is shown in Figure 3.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Job Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Job Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Job Model ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Job Object
Job ID: 32 bits, indicates the identifier of the job.
Job Type: 32 bits, indicates the type of the job.
Job Size: 32 bits, indicates the data size of the job.
Job Model: variable length, indicates the job model parameters such
as model type, model complexity and so on.
6.1.2. Traffic Pattern Object
This document proposes the Traffic Pattern Object to carry the
traffic pattern and task-based requirements, such as traffic
characteristic parameters.
The format of Traffic Pattern Object is shown in Figure 4.
Xiong, et al. Expires 3 September 2026 [Page 9]
Internet-Draft Signaling Solution for HP-WAN March 2026
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Task ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Time(s/ms) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Completion Time(s/ms) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Volume (GB) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 Traffic Pattern Object
Job ID: 32 bits, indicates the identifier of the job.
Task ID: 32 bits, indicates the identifier of the task.
Start Time: 32 bits, indicates the time when it starts to transmit
the flows.
Completion Time: 32 bits, indicates the deadline time when it
requires to complete the transmission.
Data Volume: 32 bits, indicates the data volume of the job which
needs to transfer.
6.1.3. Rate Object
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Task ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rate Policy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 Rate Object
Job ID: 32 bits, indicates the identifier of the Job and the task.
Xiong, et al. Expires 3 September 2026 [Page 10]
Internet-Draft Signaling Solution for HP-WAN March 2026
Task ID: 32 bits, indicates the identifier of the task.
Rate Policy: 32 bits, indicates the type of the rate policy such as
minimum, maximum, optimal rate policy and range of minimum and
maximum.
optional TLVs: variable length and multiple TLVs can be carried based
on the value of rate policy.
When the optimal rate policy is selected, Time-Frame TLV is carried
and shown in Figure 6. Multiple Time-Frame TLVs can be carried when
multiple intervals are computed with some particular rates.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rate(bit/s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Unit Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 Time-Frame TLV
Rate: 32 bits, indicates the optimal rate for the job or task to
transmit flows.
Time Unit Type: 32 bits, indicates the type of time unit, including
second, microsecond, millisecond and minute.
Start Time: 32 bits, indicates the start time of the time frame.
End Time: 32 bits, indicates the end time of the time frame.
When the minimum rate policy is selected, Min-Rate TLV is carried and
shown in Figure 7.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min-Rate/Min-Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 Min-Rate TLV
Xiong, et al. Expires 3 September 2026 [Page 11]
Internet-Draft Signaling Solution for HP-WAN March 2026
Min-Rate/Min-Bandwidth: 32 bits, indicates the minimum rate or
bandwidth for the job.
When the maximum rate policy is selected, Max-Rate TLV is carried and
shown in Figure 8.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-Rate/Max-Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 Max-Rate TLV
Max-Rate/Max-Bandwidth: 32 bits, indicates the maximum rate or
bandwidth for the job.
When the range of minimum and maximum rate policy is selected, Min-
Rate TLV and Max-Rate TLV should be both carried.
6.2. Message Extensions
This document proposes new messages or reuses the existing messages
to achieve the signaling communication. 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
6.2.1. JobRequest Message
The JobRequest message with new Message Type (TBD1) can be used for
job-based request. The client can send the JobRequest message and
the Job Object must be included. It will trigger the edge node to
perform the job-based traffic engineering within the network such as
establishing the TE tunnel and reserving the TE resources.
6.2.2. JobAcknowledgement Message
The JobAcknowledgement message with new Message Type (TBD2) can be
used for job-based acknowledgement. The edge node can send
JobAcknowledgement message with successful result when the job is
acknowledged.
Xiong, et al. Expires 3 September 2026 [Page 12]
Internet-Draft Signaling Solution for HP-WAN March 2026
6.2.3. TaskRequest Message
The TaskRequest message with new Message Type (TBD3) can be used for
task-based request. The client can send the TaskRequest message and
the Traffic Pattern Object must be included. It will trigger the
edge node to perform the rate control and resource scheduling based
on the TE tunnel.
6.2.4. TaskResponse Message
The TaskResponse message with new Message Type (TBD4) can be used for
task-based response. The edge node can send the TaskResponse message
conveying success when the network reserves the resource quota for
the task. The Rate Object must be included to control the rate of
the traffic.
6.2.5. TaskUpdate Message
The TaskUpdate message with new Message Type (TBD5) can be used for
task-based update with the Rate Object included with new rate related
parameters.
6.2.6. JobNotify Message
The JobNotify message with new Message Type (TBD6) can be used for
job-based notification to indicate the job transmission is completed.
6.2.7. JobCancel Message
The JobCancel message with new Message Type (TBD7) can be used for
job-based cancellation to indicate the acknowledgement is cancelled.
7. Considerations for the Centralized Solution
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 job parameters and
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.
Xiong, et al. Expires 3 September 2026 [Page 13]
Internet-Draft Signaling Solution for HP-WAN March 2026
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.
8. 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.
It is also required to create the trusted relationship between the
clients and the network based on authentication (e.g.,[RFC2747] and
[RFC3097]) and authorization (e.g.,[RFC6749]).
9. IANA Considerations
TBA.
10. References
10.1. Normative References
[I-D.xhy-hpwan-framework]
Xiong, Q., Huang, D., Yao, K., and C. Lin, "Framework for
High Performance Wide Area Network (HP-WAN)", Work in
Progress, Internet-Draft, draft-xhy-hpwan-framework-03, 20
October 2025, <https://datatracker.ietf.org/doc/html/
draft-xhy-hpwan-framework-03>.
[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>.
[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>.
Xiong, et al. Expires 3 September 2026 [Page 14]
Internet-Draft Signaling Solution for HP-WAN March 2026
10.2. Informative References
[I-D.kcrh-hpwan-state-of-art]
King, D., Chown, T., Rapier, C., Huang, D., and K. Yao,
"Current State of the Art for High Performance Wide Area
Networks", Work in Progress, Internet-Draft, draft-kcrh-
hpwan-state-of-art-03, 20 October 2025,
<https://datatracker.ietf.org/doc/html/draft-kcrh-hpwan-
state-of-art-03>.
[I-D.xiong-hpwan-problem-statement]
Xiong, Q., Yao, K., Huang, C., Zhengxin, H., and J. Zhao,
"Problem Statement for High Performance Wide Area
Networks", Work in Progress, Internet-Draft, draft-xiong-
hpwan-problem-statement-02, 25 February 2025,
<https://datatracker.ietf.org/doc/html/draft-xiong-hpwan-
problem-statement-02>.
[I-D.xiong-teas-rsvp-resource-quota]
Xiong, Q. and X. Zhu, "RSVP Extensions for Rate-based
Resource Quota", Work in Progress, Internet-Draft, draft-
xiong-teas-rsvp-resource-quota-00, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-xiong-teas-
rsvp-resource-quota-00>.
[I-D.yx-hpwan-uc-requirements-public-operator]
Yao, K. and Q. Xiong, "High Performance Wide Area Network
(HPWAN) Use Cases and Requirements -- From Public
Operator's View", Work in Progress, Internet-Draft, draft-
yx-hpwan-uc-requirements-public-operator-00, 20 February
2025, <https://datatracker.ietf.org/doc/html/draft-yx-
hpwan-uc-requirements-public-operator-00>.
[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>.
Xiong, et al. Expires 3 September 2026 [Page 15]
Internet-Draft Signaling Solution for HP-WAN March 2026
[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>.
Authors' Addresses
Quan Xiong
ZTE Corporation
Email: xiong.quan@zte.com.cn
Xiangyang Zhu
ZTE Corporation
Email: zhu.xiangyang@zte.com.cn
Changwang Lin
New H3C Technologies
Email: linchangwang.04414@h3c.com
Xiong, et al. Expires 3 September 2026 [Page 16]