| Internet-Draft | An Autonomic Mechanism for Resource-base | October 2021 |
| Dang, et al. | Expires 12 April 2022 | [Page] |
This document specifies an autonomic mechanism for resource-based network services deployment through the Autonomic Control Plane (ACP) in an Autonomic Network. This mechanism uses the GRASP in [RFC8990] to exchange the information among the autonomic nodes so that the resource among 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 12 April 2022.¶
Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
With the network development, a class of services with resource requirements (such as bandwidth, latency, and jitter) are already emerging, such as video, LR, VR and so on. From network perspective, this kind of service clearly has a source IP address and a destination IP address. Therefore, once the kind of service is delivered by a network, this network service clearly has an access node and a departure node in the network. Here, the access node is called APE, and the departure node is called DPE. Actually there may be multiple Transmit nodes between APE and DPE in a network domain, and even cross multiple network domains through ASBRs. Then, the deployment of network services needs to negotiate network resources.¶
As is surveyed, the resource in campus network are more uneven than in the operator's network, such as wireless connections. Ideally, as a centralized system, the controller can automatically perform resource discovery and overall allocation. Actually, all devices in the campus network cannot be conveniently, availably communicated with one controller, such as, some sensors with complex installation environment, the network devices from different vendors. Therefore, a new distributed mechanism in network is required to negotiate the resource information for network service auto-deployment.¶
The original purpose of this document was to validate the design of the Autonomic Networking Infrastructure (ANI) for a realistic use case. It shows how the ANI can be applied to negotiate the resource information for network service auto-deployment.¶
This document defines an autonomic technical objectives for Resource-based Network Services Auto-deployment. 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. An important purpose of the present document is to use it for validation of the design of GRASP and other components of the ANI as described in [RFC8993].¶
The goal of this document is to complete the resource-based self-adaptation among service and network nodes via GRASP. And this document is not a complete functional specification of an autonomic system of Resource-based Network Services Auto-deployment, and it does not describe all detailed aspects of the GRASP objective parameters and Autonomic Service Agent (ASA) procedures necessary to build a complete system. Instead, it describes the architectural framework utilizing the components of the ANI, outlines the different deployment options and aspects, and defines GRASP objectives for use in building the system. It also provides some basic parameter examples.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.¶
Service Initiator(SI): It may be an end user, a Customer Edge (CE), or a controller that initiates a path-dependent and resource-based network service.¶
Provider Edge (PE): Provider Edge node where the network service starts or ends.¶
Access PE (APE): A first provider edge where the service initiator connects to the network or where the path-dependent and resource-based network service starts.¶
Departure PE (DPE): A last provider edge where the path-dependent and resource-based network service ends.¶
Transmit node: A transmit node between APE and DPE.¶
AS Border Router (ASBR): AS Border Router which 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.¶
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 which is used up its resource, it can request more resource 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.¶
A ResourceManager ASA that needs additional resource should firstly discover peers that may be able to provide extra resource. The ASA should send out a GRASP Discovery message that contains a ResourceManager Objective option in order to discover peers also supporting that option. Then, it should choose one such peer, most likely the first to respond.¶
A 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 ResourceManager ASA, the device ignore this message. Further details of the discovery process are described in [RFC8990].¶
After discover step, the requesting ResourceManager ASA will act as a GRASP negotiation initiator by sending a GRASP Request message with a ResourceManager Objective option. The requesting ResourceManager ASA indicates in this option the value of the requested resource. This starts a GRASP negotiation process.¶
When the 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 requesting ResourceManager ASA will decide at each step how large resource need to offer. That decision, and the decision to end the negotiation, are implementation choices. As to the provider ResourceManager ASA responses how large resource they can offer and reserve enough resource during this negotiation step. A resource shortage may cause a device to indicate the existing available value within a ResourceManager Objective option to the requesting ASA. The requesting ASA compares whether the resource data received is the same locally. If they are not the same, the requesting ASA might decide whether to accept the resource. If not, the requesting ASA might terminate the negotiation via Negotiation End messages with an error code string.¶
As described in [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 remove the acceptable resource from its resource pool and the requesting device may use the negotiated resource 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, [restype, resval]]¶
loop-count = 0..255 ; as in the GRASP specification¶
objective-flags /= ; as in the GRASP¶
resourcetype /= 0...4; requested or offered resource type, such as bandwidth, latency or jitter.¶
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, APE, DPE, and even ASBR.¶
The network service clearly has a APE and a DPE in the network. Actually there may be multiple Transmit nodes between APE and DPE in a single network domain, or even cross multiple network domains through ASBRs. In a single network domain, APE holds all resource information to DPE. In multiple domain network domains, APE holds all resource information to ASBR, and ASBR holds all resource information to DPE.¶
The Service Initiator initiates resource negotiation for a certain network service to APE. If in one single domain, APE should respond to the message with the resource valued offered. If in multiple domain network domains, APE should initiates resource negotiation to ASBR, and respond to the message with the resource valued offered until receiving ASBR's response.¶
The Service Initiator containing a ResourceManager ASA should send out a GRASP Discovery message that contains a ResourceManager Objective option in order to discover APE also supporting that option. The APE that receives a Discovery message with a ResourceManager Objective option should respond with a GRASP Response message if it contains a ResourceManager ASA.¶
The ASA in the Service Initiator will act as a GRASP negotiation initiator by sending a GRASP Request message with a ResourceManager Objective option. The ASA indicates in this option the value of the requested resource.¶
When this ASA in the APE 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 requesting ASA.¶
If in a single network domain, this ASA in the APE check whether the local resource data meets the requirements of the request. If it meets the requested requirement, the APE should respond with a GRASP Negotiate messages with the resource type and the resource value requested. If it doesn't meet the requested requirement, the APE should respond with a GRASP Negotiate messages with the resource value offered.¶
If in the multiple network domain, this ASA in the APE should act a GRASP negotiation initiator described in Section 6.2.¶
When the ASA in the Service Initiator receives a Negotiate message, it should check whether the resource value within the Negotiate message is the same as the resource value requested. If it is same, the Service Initiator should send GRASP Negotiation End messages indicating that the negotiation was successful. If it is not same, the Service Initiator should decide whether to accept this negotiation. If accepting this negotiation, it send 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.¶
The ASA in the APE should send a Confirm Waiting message to the Service Initiator, to extend its timeout. When the new resource becomes available confirmed by ASBR, the APE responds with a GRASP Negotiate message with a resource value offered.¶
Other processes between APE and ASBR are the same as between Service Initiator and APE.¶
A gateway device gateway device is adopted between the GRASP network and the MPLS network. As is known, the RSVP belong to the distributed 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.¶