| Internet-Draft | An Autonomic Mechanism for Resource-base | July 2022 |
| Dang, et al. | Expires 9 January 2023 | [Page] |
This document specifies an autonomic mechanism for resource-based network services deployment through the Autonomic Control Plane (ACP) in a network. This mechanism uses the GeneRic Autonomic Signaling Protocol (GRASP) in [RFC8990] to exchange the information among the autonomic nodes so that the resource along the service path can be coordinated.¶
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 9 January 2023.¶
Copyright (c) 2022 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.¶
With network development, a class of services with resource requirements (such as bandwidth, queue, and priority) are already emerging, such as video, VR, AR, and so on. To ensure the proper operation of these services, the network needs to allocate sufficient resources for the services in advance. An autonomous network SHOULD have an appropriate mechanism to negotiate the network resources.¶
From the network perspective, this kind of service has a source IP address and a destination IP address. Therefore, once the kind of service is delivered by a domain network, this service clearly has an access node and a departure node in the network. In an autonomic resource negotiation mechanism, the resources are negotiated between the access node and departure node.¶
The core goal of this document is to establish an automatic negotiation mechanism to achieve the negotiation and distribution of network resources in the domain network between the service client and the network. That is, the server client negotiates with the network how many resources can be provided for specific services in the domain network to support the transmission of network services. The benefits of doing so mainly include the following aspects:¶
The resource information negotiated in this document is more extensive. Not only negotiation bandwidth resources but also includes and is not limited to queue, priority and other resources. On the one hand, in recent years, the requirements of services for the network have become more complex. Services usually require the network to ensure not only the deterministic bandwidth but also the deterministic end-to-end delay and jitter, so as to deliver the data message to the destination "in time" and "on time". For example, in the telemedicine scenario, in order to ensure that doctors do not feel obvious delay and jitter, it is required that the end-to-end delay should not exceed 20ms. On the other hand, with the development of technology, the network has more refined the scheduling of transmission capacity, and also hopes to open its own capacity to the service clients. The negotiation resources established in this document should support not only negotiating the existing supported resources but also to retain some scalability for the negotiation ability in the future.¶
This document completes the resource-based self-adaptation among service and network nodes via GRASP. This document defines an autonomic technical objective for resource-based network services auto-deployment. It shows how the ANI can be applied to negotiate resource information for network service auto-deployment. This document reduces the difficulty of manual operation, avoids the problems of specification limitation and slow response speed in the centralized system, improves the efficiency of service deployment and makes more rational use of network resources. The GeneRic Autonomic Signaling Protocol (GRASP) is specified by [RFC8990] and can make use of the technical objective to provide a solution for resource-based network services auto-deployment.¶
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] .¶
This document uses terminology defined in [RFC7575].¶
RRM ASA: Requester ResourceManager ASA. A kind of ResourceManager ASA which starts to request resource in the network.¶
PRM ASA: Provider ResourceManager ASA. A kind of ResourceManager ASA which provides resource in the network.¶
APE: Access Provider Edge is the first access provider edge where the service initiator connects to the network or where the path-dependent and resource-based network service starts.¶
DPE: Departure PE is the last provider edge where the path-dependent and resource-based network service ends.¶
Transmit node: A transmit node in the domain network.¶
ASBR: AS Border Router is an edge node of the domain in the cross-domain scenario. It may also be a PE node.¶
This section describes the internal architecture of resource-based network services auto-deployment. As noted in Section 1, this is not a complete description of a solution, which will depend on the detailed design of the relevant Autonomic Service Agents (ASAs). It uses the generic discovery and negotiation protocol defined by [RFC8990] and the relevant GRASP objectives are defined in Section 5.¶
Figure1 shows the process of the auto deployment mechanism. And the procedures described below are carried out by an ASA in each device that participates in the solution. We will refer to this as the ResourceManager ASA. If a device containing a ResourceManager ASA needs reserve resources for specific, it can request more resources according to its requirements. It should decide the type and value of the requested resource and request it via the mechanism described in Section 6.¶
+----------+ +---------+
| RRM ASA | | PRM ASA |
+----------+ Discovery +---------+
Discovery |----------------------------------->|
| M_RESPONSE |
|<-----------------------------------|
Negotiation | |
+----------------+ +----------------+
| Decide each | Multiple rounds | responses how |
|round how large |<------------------>| large resource |
| response need | Negotiation | can offer |
+----------------+ +----------------+
| |
After | +---------------------------------+
Negotiation | | Removes the acceptable resource |
| | from its resource pool |
| +---------------------------------+
| synchronize to other ASAs |
|<------------------------------------|
+----------------+ |
| Send packets | |
+----------------+ |
| |
¶
Figure-1: Auto-deployment Process¶
A ResourceManager ASA that needs additional resources should first discover peers that may be able to provide extra resources. The ASA should send out a GRASP Discovery message that contains a ResourceManager Objective option to discover peers also supporting that option.¶
A GRASP device that receives a Discovery message with a ResourceManager Objective option should respond with a GRASP Response message if it contains a ResourceManager ASA. If it does not contain a ResourceManager ASA, the device ignores this message. Further details of the discovery process are described in Section 2.5.4 of [RFC8990].¶
After the discovery step, the RRM ASA (Requesting ResourceManager ASA) will act as a GRASP negotiation initiator by sending a GRASP Request message with a ResourceManager Objective option. The RRM ASA indicates in this option the value of the requested resource. ResourceManager GRASP Objective allows multiple types of resources to be requested simultaneously.¶
When the PRM ASA (Provider ResourceManager ASA) receives a subsequent Request message, it should conduct a GRASP negotiation sequence, using Negotiate, Confirm Waiting, and Negotiation End messages as appropriate. The Negotiate messages carry a ResourceManager Objective option, which will indicate the resource type and value offered to the requesting ASA.¶
During the negotiation, the RRM ASA will decide at each step how large a resource needs to offer. That decision, and the decision to end the negotiation, are implementation choices. As to the PRM ASA responses how large resources they can offer and reserve enough resources during this negotiation step. A resource shortage may cause a device to indicate the existing available value within a ResourceManager Objective option to the RRM ASA. The RRM ASA compares whether the resource data received is the same locally. If they are not the same, the RRM ASA might decide whether to accept the request of the resource. If not, the RRM ASA might terminate the negotiation via Negotiation End messages with an error code string.¶
As described in Section 2.8.8 of [RFC8990], negotiation will continue until either end stops it with a Negotiation End message. If the negotiation succeeds, the ASA that provides the resource will remove the negotiated resource from its pool, and the requesting ASA will add it. If the negotiation fails, the party sending the Negotiation End message may include an error code string.¶
Upon receiving a GRASP Negotiation End message that indicates that the acceptable resource is available. The resource-providing device removes the acceptable resource from its resource pool and synchronizes to other RRM ASAs and PRM ASAs. The requesting device may use the negotiated resource after receiving synchronization message without further messages.¶
This section defines the GRASP technical objective options that are used to support autonomic resource management.¶
The ResourceManager Objective option is a GRASP Objective option conforming to the GRASP specification [RFC8990]. Its name is "ResourceManager", and it carries the following data items as its value: the resource value. Since GRASP is based on CBOR (Concise Binary Object Representation) [RFC8949], the format of the ResourceManager Objective option is described in the Concise Data Definition Language (CDDL) [RFC8610] as follows:¶
objective = ["ResourceManager", objective-flags, loop-count, ?objective-value]¶
objective-name = "ResourceManager"¶
objective-flags = uint .bits objective-flag ; as in the GRASP specification¶
loop-count = 0..255 ; as in the GRASP specification¶
The 'objective-value' field expresses the actual value of a negotiation or synchronization objective. So a new objective-value named n-s-deployment-value is defined for Network Service Auto-deployment as follows. The autonomic node can know that it is serving Network Service Auto-deployment according to the objective-value after receiving the GRASP message. The 'objective value' contains two parts, one represents the information of the service itself, and the other represents the requirements of resources.¶
objective-value = n-s-deployment-value ; An n-s-deployment-value is defined as Figure-2.¶
n-s-deployment-value
+ service-information
+ source-ip-address
+ destination-ip-address
+ service-tag
+ resource-information
+ resource-requirement-pair
+ resource-type
+ resource-value
¶
Figure-2: Format of n-s-deployment-value¶
service-information = [ source-ip-address, destination-ip-address, service-tag ]¶
The source-ip-address and the destination-ip-address represent the source address and destination address. IPv4 and IPv6 addresses are allowed.¶
resource-information = [ resource-requirement-pair 1, resource-requirement-pair 2, ... , resource-requirement-pair n ]¶
Resource requirements of different types can be described in an objective option. The ResourceManager objective option supports multi-faceted resource requirements and negotiation.¶
resource-requirement-pair = [ resourcetype, resval ]¶
resourcetype /= 0...16; requested or offered resource type, such as bandwidth, queue, and priority.¶
resval /= 1...1000000; If the restype is bandwidth, the value ranges in Mbit/s; If the restype is latency, the value ranges in microsecond; If the restype is jitter, the value ranges in microsecond.¶
The network service auto-deployment system includes Service Initiator(SI), Service Terminator(ST), RRM ASA, PRM ASA and even ASBR.¶
The service initiator is the resource demander, which ensures the connection of services through negotiation resources with ResourceManager ASA in the domain network. Service Terminator is the end of service. APE represents the first access provider edge where the service initiator connects to the network or where the path-dependent and resource-based network service starts. There may be multiple Transmit nodes between APE and Service Terminator in the network or even cross multiple network domains through ASBRs. RRM ASA starts a negotiation process to get enough resources in the network. After RRM ASA gets the result about the resource, it sends a response message to the Service Initiator. And PRM ASA manages resources from APE to ST hop-by-hop.¶
In an End-to-End service, Service Initiator is a kind of access terminal of the network. And the End-to-End service initiator uses ResourceManager ASA to negotiate resources with the ResourceManager ASA in the APE. Figure 3 shows the architecture of the End-to-End service. In the figure, the RRM ASA in SI will act as a GRASP negotiation initiator by sending a GRASP Request message with a ResourceManager Objective option. The RRM ASA indicates in this option the value of the requested resource. When this RRM ASA receives a subsequent Request message, it should conduct a GRASP negotiation sequence, using Negotiate, Confirm Waiting, and Negotiation End messages as appropriate. The Negotiate messages carry a ResourceManager Objective option with the resource value offered to the PRM ASA.¶
+---------+ Negotiation Resource +---------+ | RRM ASA |<--------------------->| PRM ASA | +---------+ +---------+ +------+ +------+ | SI | --------------------->| APE |--->| Node |--->| ST | +---------+ Transmit data +---------+ +------+ +------+¶
Figure-3: An example of End-to-End Service¶
PRM ASA processes receive resource requests and ensure the nodes resource it can manage. When the RRM ASA receives a Negotiation response message, it should check whether the resource value in the Negotiate message is the same as the resource value requested. If it is the same, the RRM ASA should send GRASP Negotiation End messages indicating that the negotiation was successful. If it is not the same, the RRM ASA should communicate with the Service Initiator about the result and decide whether to accept this negotiation. If accepting this negotiation, RRM ASA should send GRASP Negotiation End messages indicating that the negotiation was successful. If not accepting this negotiation, it should send GRASP Negotiation End messages indicating that the negotiation fails.¶
+----------+ +---------+
| RRM ASA | | PRM ASA |
+----------+ [[IP_A,IP_B,Service_tag][[0,10]]] +---------+
|------------------------------------------->|
| [[IP_A,IP_B,Service_tag][[0,8]]] |
|<-------------------------------------------|
| [[IP_A,IP_B,Service_tag][[0,8]]] |
|------------------------------------------->|
| Negotiation End (ACCEPT) |
|<-------------------------------------------|
¶
Figure 4 shows an example of negotiation process. In the first negotiation round, RRM ASA want to get 10 Mbit/s bandwidth from IP_A to IP_B, so the resource value is [0,10]. Zero means the resource type is bandwidth and ten is the value. The message also include source and target IP and some service information. PRM ASA can use service_tag to decide whether to provide these resources to services in the case of resource constraints. When PRM ASA receives the message, if the PRM ASA think the network can offer this message to RRM ASA, it will response the ACCEPT. But if it not response, it will give the RRM ASA request about how much resource it can offer. In this example, PRM ASA can offer 8 Mbit/s to RRM ASA. The next step, RRM ASA needs to decide whether to change its resource requirements according to the reply. And sends a next round negotiation. And then PRM ASA deal the new resource requirement, it then the requirement it can offer. So it will response ACCEPT. This is an example about how ASAs negotiation resource. And after negotiation, PRM ASA will build a hop-by-hop resource path for service. And Service send data packet through this path.¶
Figure-4: Example of Negotiation Process¶
In the process of automatic resource management mechanism, RRM ASA and PRM ASA are allowed to negotiate resources for multiple rounds. A very common situation is that the network resources can not meet the resources required by the service, but the service is willing to reduce its resource requirements to ensure the successful deployment of the service. The PRM ASA using Resource Management Objectives contains the resources that the network can provide to the service present in the response message. The RRM ASA changes the resource requirements according to the specific requirements of the received resources and services, to carry out the next round of service negotiation.¶
In a multiple network, PRM ASA doesn't have the resource status of other domains. So PRM ASA should negotiate with ASBR PRM ASA before response RRM ASA. The PRM ASA should send a Confirm Waiting message to the RRM ASA, to extend its timeout. When the new resource becomes available confirmed by ASBR, the PRM ASA responds with a GRASP Negotiate message with a resource value offered. The process shows in Figure 5. The Confirm Waiting message is described in Section 2.8.9 of [RFC8990].¶
+----------+ +---------+
| RRM ASA |<--------->| PRM ASA |
+----------+ +---------+ +--------------+
| | RRM ASA |<------>| ASBR PRM ASA |
| +---------+ +--------------+
|Request Negotiation Message |
|---------------------->| |
|Waiting message | |
|<----------------------| |
| | Request Negotiation Message
| |------------------->|
| | Negotiation message|
| |<------------------ |
| Negotiation message |
|<----------------------|¶
Other processes between APE and ASBR are the same as between Service Initiator and APE.¶
Figure-5: An example of a path-based resource negotiation¶
After the process of automatic resource management mechanism, RRM ASA and PRM ASA are allowed to change and negotiate the resource requirements. In the course of using network services, there will be service requirement change which will lead to the problem of network resource requirement change. ResourceManager ASA needs to be able to handle resource changes in a timely manner to meet service requirements.¶
During the renegotiation process, RRM ASA resends the service's resource requirements by using ResourceManager GRASP Objective. And the resource renegotiation process does not require the use of the same PRM ASA as at the last negotiation on the mission. PRM ASA receives the resource negotiation message and makes the determination. If the resource requirements are lower than those allocated, the response confirms the information and releases the excess resources. If more resources are required than have been allocated, the resource negotiation process follows Section 6.1.¶
PRM ASA does not change existing resource allocation until negotiation on resource changes is complete. After negotiation, PRM ASA makes changes to the resource pool by using response to the negotiated resource requirements and synchronizes them with other ASA nodes.¶
After the service is completed, a mechanism is needed to release network resources so that network resources can be used more efficiently. This process can be seen as a change in resource requirements negotiation, where the resource requirements of the service to the network become zero. A negotiation with PRM ASA was initiated by RRM ASA in SI to reduce the resource footprint of the service. Upon completion of the negotiation, PRM ASA released the resources occupied by the service.¶
This auto deployment mechanism support multi-round negotiation mechanim which improves the deployment success rate. This mechanism is not available in other protocols¶
A gateway device is used between the GRASP network and the MPLS network. As is known, the RSVP belongs to the distribution mechanism for resource reservation, but it is only coupled with MPLS. Then this device uses the GRASP protocol in the GRASP network, and the MPLS protocol in the MPLS network, so that resource information can be shared.¶
It complies with GRASP security considerations. Relevant security issues are discussed in [RFC8990]. The preferred security model is that devices are trusted following the secure bootstrap procedure [RFC8995] and that a secure Autonomic Control Plane (ACP) [RFC8994] is in place.¶
This document defines a new GRASP Objective option names: "ResourceManager" which is need to be added to the "GRASP Objective Names" registry.¶
Valuable comments were received from Michael Richardson and Brian Carpenter.¶