



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]
