Internet-Draft Signaling Solution for HP-WAN July 2025
Xiong, et al. Expires 8 January 2026 [Page]
Workgroup:
hpwan
Internet-Draft:
draft-xiong-hpwan-signaling-solution-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
Q. Xiong
ZTE Corporation
X. Zhu
ZTE Corporation
C. Lin
New H3C Technologies

Signaling Solution for HP-WAN

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.

Table of Contents

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 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:

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.

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.

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

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

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.

 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.

 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.

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.

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.

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, , <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, , <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, , <https://datatracker.ietf.org/doc/html/draft-xiong-hpwan-problem-statement-02>.
[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, , <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, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC2747]
Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, DOI 10.17487/RFC2747, , <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, , <https://www.rfc-editor.org/rfc/rfc3097>.
[RFC6749]
Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, , <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, , <https://www.rfc-editor.org/rfc/rfc8174>.

Authors' Addresses

Quan Xiong
ZTE Corporation
Xiangyang Zhu
ZTE Corporation
Changwang Lin
New H3C Technologies