



hpwan                                                           Q. Xiong
Internet-Draft                                                    X. Zhu
Intended status: Standards Track                         ZTE Corporation
Expires: 8 January 2026                                           C. Lin
                                                    New H3C Technologies
                                                             7 July 2025


                     Signaling Solution for HP-WAN
                draft-xiong-hpwan-signaling-solution-00

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 8 January 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.



Xiong, et al.            Expires 8 January 2026                 [Page 1]

Internet-Draft        Signaling Solution for HP-WAN            July 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  The Rate Negotiation Policy for Host-network Collaboration  .   3
     3.1.  Minimum Rate Negotiation  . . . . . . . . . . . . . . . .   4
     3.2.  Maximum Rate Negotiation  . . . . . . . . . . . . . . . .   4
     3.3.  Constant Rate Negotiation . . . . . . . . . . . . . . . .   5
   4.  Host-network Collaboration signaling  . . . . . . . . . . . .   5
     4.1.  Stitching signaling . . . . . . . . . . . . . . . . . . .   5
     4.2.  Hop-by-hop signaling  . . . . . . . . . . . . . . . . . .   6
     4.3.  Overlay signaling . . . . . . . . . . . . . . . . . . . .   7
   5.  Instantiation with RSVP Extensions  . . . . . . . . . . . . .   8
     5.1.  Objects Extensions  . . . . . . . . . . . . . . . . . . .   9
       5.1.1.  Traffic Pattern Object  . . . . . . . . . . . . . . .   9
       5.1.2.  Rate Object . . . . . . . . . . . . . . . . . . . . .   9
       5.1.3.  Quota Object  . . . . . . . . . . . . . . . . . . . .  10
       5.1.4.  Quotaconf Object  . . . . . . . . . . . . . . . . . .  11
     5.2.  Messages Extensions . . . . . . . . . . . . . . . . . . .  12
       5.2.1.  JobRequest Message  . . . . . . . . . . . . . . . . .  12
       5.2.2.  JobResponse Message . . . . . . . . . . . . . . . . .  13
       5.2.3.  JobUpdate Message . . . . . . . . . . . . . . . . . .  13
       5.2.4.  JobNotify Message . . . . . . . . . . . . . . . . . .  13
       5.2.5.  JobCancle Message . . . . . . . . . . . . . . . . . .  13
   6.  Considerations for the Centralized Solution . . . . . . . . .  13
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   Data-intensive applications always demand high-speed data
   transmission over WANs such as scientific research, academia,
   education as discussed in [I-D.kcrh-hpwan-state-of-art] and other
   applications in public networks as per
   [I-D.yx-hpwan-uc-requirements-public-operator].  The specific HP-WANs
   applications mainly focus on job-based timely transmission over long-
   distance WANs and high-throughput with efficient use of capacity is
   the fundamental requirement for HP-WAN.  But it faces the challenges
   such as poor convergence speed, long feedback loop, and unscheduled
   traffic as per [I-D.xiong-hpwan-problem-statement].
   [I-D.xhy-hpwan-framework] defined a framework to enable the host-and-
   network collaboration for the high-speed and high-throughput data



Xiong, et al.            Expires 8 January 2026                 [Page 2]

Internet-Draft        Signaling Solution for HP-WAN            July 2025


   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.  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 the different rate policy.
   The host-network collaboration includes:

   *  The host needs to send job-based requests to the network to
      negotiate the sending rate before data transmission;

   *  The network needs to schedule the requests and perform the
      admission control based on available capacity.  The network
      performs dynamic resources reservation upon different time frames
      defined by quota.  The nodes need to subtract the resource quota
      within the time frames, but not reserve it while the traffic in
      the network are still sharing the resources.  The subtraction
      result will be viewed as the resources constraints for the
      admission control.  The request will be accepted when the rate-
      based resource quota reservation is succeed, otherwise, it will be
      rejected.

   *  After the acknowledgement of the rate negotiation, the client
      could transmit the job-based flows at a sending rate based on the
      rate policy.




Xiong, et al.            Expires 8 January 2026                 [Page 3]

Internet-Draft        Signaling Solution for HP-WAN            July 2025


3.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 following:

   *  Min-rate = Flowsize/(CompletionTime-StartTime)

   For example, the client requests to transfer the job with 10G data
   volume from 10s to 20s.  The minimum rate will be 10G/(20s-
   10s)=1Gbps.  The network will subtract 1G bandwidth quota from 10s to
   20s and the admission of this job is accepted.  The client could
   transfer this job with rate no less than 1Gbps.

3.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 quota reservation at the bottleneck
   nodes along the path.  The acknowledgement of the maximum rate
   negotiation, the client could transmit the job-based flows at a
   sending rate not greater than the maximum rate.

   The maximum rate of a flow on a specific link is related to the link
   bandwidth and the number of aggregated traffic flows.  When more
   flows are aggregated, the maximum rate of each individual flow
   decreases.  Conversely, with fewer aggregated flows, each flow can
   achieve a higher maximum rate, ensuring the buffer does not overflow
   and congestion is mitigated.  Multiple hops along the path could
   calculate a set of maximum rates, the negotiated maximum rate for a
   flow transmitting along the path is the minimum value within the
   maximum rates.

   The maximum rate can be computed as following:

   *  Max-rate = a*Bandwidth/FlowNumber

   a is an expansion coefficient which is set based on network buffer
   information.





Xiong, et al.            Expires 8 January 2026                 [Page 4]

Internet-Draft        Signaling Solution for HP-WAN            July 2025


   For example, if the the bandwidth of the bottleneck node is 10G, a is
   1.5, and two flows aggregates through this node, the maximum rate
   will be 1.5*10G/2=7.5Gbps.  The client could transfer this job with
   rate no greater than 7.5Gbps within the time frame.

3.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.  The
   acknowledgement of the constant rate negotiation, the client could
   transmit the job-based flows at a sending rate according to the
   negotiated constant rate or optimal rate range.

   The constant rate can be computed as the minimum rate or the
   controller could perform high-level resources planning and allocate
   optimal rates for the time frames with multiple intervals.

   For example, the constant rates could be like {(10s~20s,10Gbps),
   (20s~30s,2Gbps)}.

4.  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
   following sections.

4.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 resources quota reservation
   signaling along network nodes can be achieved within the network.
   The workflow is shown in Figure 1.

   *  The requests of scheduled traffic will be signaled through P2P
      signaling from the client to the edge node carrying the traffic
      pattern and job-based requirements.









Xiong, et al.            Expires 8 January 2026                 [Page 5]

Internet-Draft        Signaling Solution for HP-WAN            July 2025


   *  The edge node will configure the rate policy, compute the
      negotiated rate and resource quota, and perform traffic
      scheduling.  And it will also initial the resources quota
      reservation signaling in the network to perform the admission
      control at the nodes along the path.  The edge node will send the
      negotiated rate after the traffic is acknowledged or updated.

   *  The client will notify the edge node when the data transmission is
      completed.  The resources quota will be released and
      acknowledgement is canceled.

 +--------+               +-----------+       +------------+         +-----------+
 | Client |               | Edge Node |       |Transit Node|         | Edge Node |
 +----+---+               +-----+-----+       +-----+------+         +-----+-----+
      |                         |                   |                      |
      |Request(traffic pattern) |                   |                      |
      |------------------------>|*Rate negotiation  |                      |
      |                         |*Traffic scheduling|                      |
      |                         |        *Admission control                |
      |                         |        *Reserve resource quota           |
      |Acknowledgement          |<.................>|<....................>|
      |(negotiated rate)        |                   |                      |
      |<------------------------|                   |                      |
      |New Request              |                   |                      |
      |------------------------>|                   |                      |
      |Update(negotiated rate)  |                   |                      |
      |<------------------------|                   |                      |
      |Notification(completion) |                   |                      |
      |------------------------>|        *Release resource quota           |
      |Acknowledgement(cancel)  |<.................>|<....................>|
      |<------------------------|                   |                      |
      |                         |                   |                      |
      V                         V                   V                      V

      |<----------------------->|<........................................>|
    P2P signaling between client     Quato Reservation signaling
           and network edge node                 along network nodes

                       Figure 1 Stitching signaling

4.2.  Hop-by-hop signaling

   The host-network collaboration signaling can be implemented as hop-
   by-hop signaling (e.g.RSVP).  It can be end-to-end provisioned along
   the path from client, edge nodes, network nodes and server.  The
   workflow is shown in Figure 2.





Xiong, et al.            Expires 8 January 2026                 [Page 6]

Internet-Draft        Signaling Solution for HP-WAN            July 2025


   *  The client configures the rate policy and computes the negotiated
      rate and the resource quota based on the traffic requirements of
      the job.  And it will also initial the resources quota reservation
      signaling to perform the admission control hop-by-hop along the
      path.

   *  The client will release resources quota when the data transmission
      is completed.

 +--------+               +-----------+     +---------------+        +-----------+       +--------+
 | Client |               | Edge Node |     |  Transit Node |        | Edge Node |       | Server |
 +----+---+               +-----+-----+     +-------+-------+        +-----+-----+       +----+---+
      |*Rate negotiation        |                   |                      |                  |
      |                                 *Admission control                                    |
      |                                 *Reserve resource quota                               |
      |<----------------------->|<----------------->|<-------------------->|<---------------->|
      |                         |                   |                      |                  |
      |                                 *Release resource quota                               |
      |------------------------>|<----------------->|<-------------------->|<---------------->|
      |                         |                   |                      |                  |
      V                         V                   V                      V                  V

     |<------------------------------------------------------------------------------------->|
                 Hop-by-hop signaling along the client, network nodes and server

                                                 Figure 2 Hop-by-hop signaling

4.3.  Overlay signaling

   The host-network collaboration signaling can be implemented as
   overlay signaling to alleviate the operational and scalability
   issues.  It can be end-to-end signaling (e.g. RSVP-TE) provisioned
   along the path from client, bottleneck nodes, and server.  It will
   largely improve the hop-by-hop signaling through TE technologies such
   as Segment Routing (SR), network slicing and RSVP-TE approaches.  It
   only needs to perform resource quota reservation-based admission
   control at ingress and egress edge nodes and bottleneck nodes.  The
   workflow is shown in Figure 3.

   *  The requests of scheduled traffic will be signaled through overlay
      signaling from the client to the edge node carrying the traffic
      pattern and job-based requirements.

   *  The edge node will configure the rate policy, compute the
      negotiated rate and resource quota, and perform traffic
      scheduling.  And it will also initial the negotiated rate-based
      traffic engineering to establish the TE tunnels.  And the overlay
      signaling will be replaced to the resources quota reservation



Xiong, et al.            Expires 8 January 2026                 [Page 7]

Internet-Draft        Signaling Solution for HP-WAN            July 2025


      signaling in the network to perform the admission control at the
      edge nodes and bottleneck nodes along the path.  The edge node
      will send the negotiated rate after the traffic is acknowledged or
      updated (when new requests are received).

   *  The client will notify the edge node when the data transmission is
      completed.  The resources quota will be released and
      acknowledgement is canceled.

 +--------+               +-----------+     +---------------+        +-----------+       +--------+
 | Client |               | Edge Node |     |Bottleneck Node|        | Edge Node |       | Server |
 +----+---+               +-----+-----+     +-------+-------+        +-----+-----+       +----+---+
      |                         |                   |                      |                  |
      |Request(traffic pattern) |                   |                      |                  |
      |------------------------>|*Rate negotiation  |                      |                  |
      |                         |*Traffic scheduling|                      |                  |
      |                         |        *Admission control                |                  |
      |                         |        *Reserve resource quota           |   Request        |
      |Acknowledgement          |<----------------->|<-------------------->|<---------------->|
      |(negotiated rate)        |                   |                      | Acknowledgement  |                                                                         Acknowledgement
      |<------------------------|*Negotiated rate-based traffic engineering|                  |
      |                         |<########################################>|                  |
      |New Request              |                   |                      |                  |
      |------------------------>|                   |                      |                  |
      |Update(negotiated rate)  |                   |                      |                  |
      |<------------------------|                   |                      |                  |
      |Notification(completion) |                   |                      |                  |
      |------------------------>|        *Release resource quota           |  Notification    |
      |Acknowledgement(cancel)  |<----------------->|<-------------------->|<---------------->|
      |<------------------------|                   |                      | Acknowledgement  |
      |                         |                   |                      |                  |
      V                         V                   V                      V                  V

      |<------------------------------------------------------------------------------------->|
         Overlay signaling along the client, edge nodes, bottleneck nodes and server

                                                 Figure 3 Overlay signaling

5.  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, resource quota reservation and release.







Xiong, et al.            Expires 8 January 2026                 [Page 8]

Internet-Draft        Signaling Solution for HP-WAN            July 2025


5.1.  Objects Extensions

5.1.1.  Traffic Pattern Object

   This document proposes the Traffic Pattern Object to carry the
   traffic pattern and job-based requirements, such as traffic
   characteristic parameters.

   The format of Traffic Pattern Object is shown in Figure 4.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Job ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Start Time(s/ms)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Completion Time(s/ms)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Data Volume (GB)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          Figure 4  Traffic Pattern Object

   Job ID: 32bits, indicates the identifier of the Job.

   Start Time: 32bits, indicates the time when it starts to transmit the
   flows.

   Completion Time: 32bits, indicates the deadline time when it requires
   to complete the transmission.

   Data Volume: 32bits, indicates the data volume of the job which needs
   to transfer.

5.1.2.  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.












Xiong, et al.            Expires 8 January 2026                 [Page 9]

Internet-Draft        Signaling Solution for HP-WAN            July 2025


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Job ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Rate Policy                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                            optional TLVs                      ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            Figure 5  Rate Object

   Job ID: 32bits, indicates the identifier of the Job.

   Rate Policy: 32bits, indicates the type of the rate policy such as
   minimum, maximum and optimal rate policy.

   optional TLVs: variable length and multiple TLVs can be carried when
   multiple intervals are computed.  The Time frame TLV is shown in
   Figure 6.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Rate(bit/s)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Start Time(s/ms)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           End Time(s/ms)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              Figure 6  Time frame TLV

   Rate: 32bits, indicates the value of negotiated rate.

   Start Time: 32bits, indicates the start time of the time frame.

   End Time: 32bits, indicates the end time of the time frame.

5.1.3.  Quota Object

   This document proposes the Quota Object to carry the resources quota
   information.  The format of Quota Object is shownin Figure 7.










Xiong, et al.            Expires 8 January 2026                [Page 10]

Internet-Draft        Signaling Solution for HP-WAN            July 2025


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

   Job ID: 32bits, indicates the identifier of the Job.

   Rate Policy: 16bits, indicates the type of the rate policy such as
   minimum, maximum and optimal rate policy.

   Rate: 16bits, indicates the value of negotiated rate.

   Quota Type: 16bits, indicates the type of resource quota, including
   the bandwidth, buffer, queue, CPU size etc.

   Time Unit Type: 16bits, indicates the type of time unit, including
   second, microsecond, millisecond and minute.

   Start Time: 32bits, indicates the start time of the time frame.

   End Time: 32bits, indicates the end time of the time frame.

   optional TLVs: variable length and multiple TLVs can be carried to
   indicate the resource quota.

5.1.4.  Quotaconf Object

   This document proposes the Quotaconf Object to carry the
   configuration and notification of quota information.  The format of
   Quotaconf Object is shownin Figure 8.







Xiong, et al.            Expires 8 January 2026                [Page 11]

Internet-Draft        Signaling Solution for HP-WAN            July 2025


   0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Length (bytes)          |   Class Num   |    C-Type     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 reserved                                  |C|R|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                      Receiver IP list                        ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             Figure 8 Quotaconf Object

   R: 1bit, when it is set to 0, it indicates the succeed of quota
   reservation, otherwise indicates failure.

   C: 1bit, when it is set to 0, it indicates releasing the quota,
   otherwise it is not required.  Receiver IP list: variable, it
   indicates the IP addresses of the nodes which should configure to.

5.2.  Messages Extensions

   This document proposes the new messages or reuse the existing
   messages to achieve the communication of signaling.  The format of
   the new messages is shown in Figure 9.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Ver   |Flags  |  Message Type |    RSVP Checksum              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Send_TTL     |  Reserved     |    RSVP Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           Figure 9 RSVP Message Header

5.2.1.  JobRequest Message

   The JobRequest message with new Message Type (TBD1) can be used for
   job-based request and quota reservation request.  The client can send
   the JobRequest message and the Traffic Pattern Object must be
   included.  The edge node can send quota reservation request and the
   Quota Object must be included.

   The quota reservation response message adds a Response message
   conveying success or failure status.  The quota release request
   message introduces a Cancel message containing quota release details,
   while the quota release response message incorporates a Response
   message indicating success or failure acknowledgment.





Xiong, et al.            Expires 8 January 2026                [Page 12]

Internet-Draft        Signaling Solution for HP-WAN            July 2025


5.2.2.  JobResponse Message

   The JobResponse message with new Message Type (TBD2) can be used for
   job-based acknowledgement and quota reservation response.  The edge
   node can send JobResponse message with the Rate object included when
   the traffic is acknowledged.  The transit nodes can send JobResponse
   message to the upstream node with the Quotaconf object included when
   the admission the rejected.  And the edge node can send JobResponse
   message when the admission the accepted.

5.2.3.  JobUpdate Message

   The JobResponse message with new Message Type (TBD3) can be used for
   job-based update with the Rate object included with new rate related
   parameters.

5.2.4.  JobNotify Message

   The JobResponse message with new Message Type (TBD4) can be used for
   job-based notification to indicate the traffic transmission is
   completed.

5.2.5.  JobCancle Message

   The JobResponse message with new Message Type (TBD5) can be used for
   job-based cancelation to indicate the acknowledgement is canceled.

6.  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 traffic patterns of
   high-speed flows and the network will reserve the corresponding
   resource quota and perform the admission control based on the
   capacity of network nodes.

   If the network deployment is Software-Defined Network (SDN)
   centralized architecture, the controller will perform resource quota
   reservation and admission control.  For instance, for the SDN for
   End-to-end Networked Science at Exascale (SENSE) system in Research
   and Education (R&E) networks, the orchestrator and resource Manager
   (RM) have the capability of hierarchical planning and resource
   reservation in the network.  The orchestrator communicates the
   requests from applications and interacts with the RM for resource
   reservation.






Xiong, et al.            Expires 8 January 2026                [Page 13]

Internet-Draft        Signaling Solution for HP-WAN            July 2025


7.  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.  The network needs to perform quota-based
   resource computation and reservation based on authentication
   (e.g.[RFC2747] and [RFC3097]) and authorization (e.g.[RFC6749]).

8.  IANA Considerations

   TBA.

9.  References

9.1.  Normative References

   [I-D.kcrh-hpwan-state-of-art]
              King, D., Chown, T., Rapier, C., and D. Huang, "Current
              State of the Art for High Performance Wide Area Networks",
              Work in Progress, Internet-Draft, draft-kcrh-hpwan-state-
              of-art-01, 8 January 2025,
              <https://datatracker.ietf.org/doc/html/draft-kcrh-hpwan-
              state-of-art-01>.

   [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-02, 9
              June 2025, <https://datatracker.ietf.org/doc/html/draft-
              xhy-hpwan-framework-02>.

   [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>.










Xiong, et al.            Expires 8 January 2026                [Page 14]

Internet-Draft        Signaling Solution for HP-WAN            July 2025


   [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>.

9.2.  Informative References

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

   [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>.

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

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

Authors' Addresses

   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 8 January 2026                [Page 15]
