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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 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, . [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, . [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, . [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, . [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, DOI 10.17487/RFC2747, January 2000, . [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, DOI 10.17487/RFC3097, April 2001, . [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security Properties", RFC 4230, DOI 10.17487/RFC4230, December 2005, . 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, . [RFC6411] Behringer, M., Le Faucheur, F., and B. Weis, "Applicability of Keying Methods for RSVP Security", RFC 6411, DOI 10.17487/RFC6411, October 2011, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . 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]