Signaling Solution for HP-WAN

Introduction Data-intensive applications always demand high-speed data transmission over WANs such as scientific research, academia, education as discussed in and other applications in public networks as per . 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 . 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.

Conventions used in this document

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 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses the terms defined in and .

The Rate Negotiation Policy for Host-network Collaboration As per , 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.

Minimum Rate Negotiation As per , 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.

Maximum Rate Negotiation As per , 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.

Constant Rate Negotiation As per , 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)}.

Host-network Collaboration signaling As per , 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.

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.

|*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 ]]>

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.

|<----------------->|<-------------------->|<---------------->| | | | | | | *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 ]]>

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.

|*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 ]]>

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.

Objects Extensions

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

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

Quota Object This document proposes the Quota Object to carry the resources quota information. The format of Quota Object is shownin Figure 7. 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.

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

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.

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.

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.

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.

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

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

Considerations for the Centralized Solution As per , 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.

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. and ) and authorization (e.g.).

IANA Considerations TBA.