| Internet-Draft | A Generic Autonomic Deployment and Manag | September 2023 |
| Jiang, et al. | Expires 27 March 2024 | [Page] |
This document specifies an autonomic mechanism for resource-based network services deployment and management, using the GeneRic Autonomic Signaling Protocol (GRASP) to dynamically exchange the information among the autonomic nodes. It supports the coordination and consistently operations within an autonomic network domain. This mechanism is generic for most, if not all, of kinds of network resources, although this document only defines the process of quality transmission service deployment and management. It can be easily extended to support network services deployment and management that is based on other types ofnetwork resources.¶
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 27 March 2024.¶
Copyright (c) 2023 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.¶
Traditionally, IP networks are based on the best-efforts model. The IP layer does not reserve resources for upper-layer applications. However, more and more emerging applications that require quality services, such as video, VR, AR, and so on. They need supports from steady network resources, such as bandwidth, queue, memory, priority, computational resources, etc. On another side, from network side, more and more generic services, such as quality transmission services, in-network data cache services and computing services, etc., are starting to be deployed so that networks can serve these resource-consumption applications well. These network services are strongly based on the availibility and steadibility of network resources.¶
To enable these resource-based applications and services, IETF have developed many resource reservation mechanisms, such as RSVP [RFC2205] that is mainly to reserve bandwidth only and path-oriented, etc. However, most of them are mainly for reservation during the deployment only and are rigid for dynamic adjustment. Furthermore, most of them are dedicated for a certain type of network resources.¶
This document introduces an enhanced and extensible mechanism that supports dynamically dispatching of network resources, using the GeneRic Autonomic Signaling Protocol (GRASP) defined in [RFC8990] to dynamically exchange the information among the autonomic nodes. Its dynamic adjust ability is mainly enabled by the negotiation ability defined by [RFC8990].¶
This mechanism is generic for most, if not all, of kinds of network resources. It can be easily extended to support network services deployment and management that is based on other network resources. It can be used, but no limited, in below network services scenarios:¶
The Autonomic Control Plane (ACP) [RFC8994] and the Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] provide the secure precondition for this mechanism.¶
This document defines an Autonomic Resource Management Objective in Section 5. Three new corresponding registries are defined in Section 8. This document defines the process of quality transmission service deployment and management in Section 6.¶
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.¶
This document uses terminology defined in [RFC7575].¶
RM ASA: the Resource Manager ASA on an autonomic nodes. It manages the local resources on the node, such as bandwidth, queue, memory, priority, computational resources, etc. The RM ASA communicate with other counterpart RM ASAs in order to dynamically dispatch network resources within the autonomic network domain. This document assumes all autonomic nodes have a RM ASA.¶
Service Initiator: the autonomic node that initiates and manages a network service. It requests and dynamically adjusts the resources of this network service through its RM ASA. Normally, a network service SHALL have one service initiator within an autonomic network domain. However, multiple Service Initiators model MAY also operational if there were good synchronous or coordinate mechanisms among them.¶
Service Responser: the autonomic node that responses to the requests from the Service Initiator. It receives the requests through its RM ASA, checks or operates on its local resources, and responds the results to the Service Initiator. Typically, a network service MAY involve multiple Service Responser. The consistency among them are the responsibility of the Service Initiator.¶
This section describes the generic procedures of autonomic deployment and management of the resource-based network services, as Figure1 shows. The detailed implementation or internal algorithms of the ResourceManager ASAs are out of scope of this document. This section does not cover the specific details that depend on certain network services or certain type of network resources. The prepositive operation that indicates the Service Initiator to start the service deployment are out of scope. The information or reasons that trigger the dynamic service changes are also out of scope.¶
| Node Discovery |
|- - - - - - - - - - - - - - - - - ->|
+-----------------+ +-----------------+
| RM ASA | | RM ASA |
|Service Initiator| |Service Responser|
+-----------------+ ASA Discovery +-----------------+
|----------------------------------->|
| Authentication and Authorization |
|----------------------------------->|
| M_RESPONSE |
|<-----------------------------------|
| |
| Multiple rounds Negotiation |
|<---------------------------------->|
| on Resource Availability |
| |
| reserve the local resource
| |
... ...
| Coordination with other RM ASAs |
|<---------------------------------->|
... ...
| Service Ending |
|<---------------------------------->|
| release resources
¶
Figure-1: generic procedures of autonomic deployment and management¶
The Service Initiator MAY first discover the relevant newwork nodes according to the service setup in order to reduce the node range of sending GRASP Discovery message . It may be all the nodes on a giving path or nodes that have idle resource avaible for giving service condition, etc. The node discover methods can be pre-configed, outband discover, path detection, etc.¶
The Service Initiator SHOULD send out a GRASP Discovery message that contains a ResourceManager Objective option defined in Section 5, in which the network service is described. The Discovery message SHOULD send to the reduced range nodes, by abovementioned mechanism, or all nodes within the AN domain.¶
A RM ASA that receives the Discovery message with the ResourceManager Objective option SHOULD check its satification against the service description. If meet, the node is a proper Service Responser. It SHOULD respond a GRASP Response message back to the Service Initiator.¶
Defined in the section 2.5.5.1 of [RFC8990], the Discovery message MAY combine with the below negotiation process, if the rapid negotiation function has been enabled network wide. If the rapid negotiation function has been disabled, the process would fall back to the normal discovery-only process.¶
In principle, any operations on resources MUST be authoried. The Service Responser SHOULD check the authentication of the Service Initiator and the authorization information for the operation it requests. This document assumes all autonomic nodes within the AN domain have been authenticated and their requested operations are authorized, giving the Autonomic Control Plane (ACP) [RFC8994] and the Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] has provided the secure environment for this mechanism.¶
After the discovery step, the RM ASA on the Service Initiator sends a GRASP Request message with a ResourceManager Objective option, in which the value of the requested resource is indicated.¶
When the RM ASA on a Service Responser 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 RM ASA.¶
During the negotiation, the RM ASA on the Service Responser will decide at each step how much resource can be offered. That decision, and the decision to end the negotiation, are implementation choices. A resource shortage on the Service Responser may cause it to indicate the existing available value within a ResourceManager Objective option back to the Service Initiator. The Service Initiator might decide whether to accept the request of the resource. If not, the RM ASA on the Service Initiator MAY terminate the negotiation via Negotiation End messages.¶
Upon completion of the negotiation, the Service Responser reserves its local resources. The Service Initiator may use the negotiated resource after receiving synchronization message without further messages.¶
Normally, a network service SHALL have one service initiator within an autonomic network domain. It is the Service Initiator's responsibility to manage the service and coordinate among multiple Service Responsers to ensure the consistent of reserved resources.¶
After the process of automatic resource management mechanism, RM ASAs are allowed to change and negotiate the resource requirements. In the lifetime of network services, there may be many reasons that the service has to be changed upon with its reserved resources. ResourceManager ASA needs to be able to handle resource changes in a timely manner to meet service requirements.¶
During the renegotiation process, RM ASA on the Service Initiator resends the service's resource requirements by using ResourceManager GRASP Objective. RM ASA on the Service Responser receives the resource negotiation message and makes the determination. If the resource requirements are lower than those allocated or/and less lifetime than previous, the Service Responser SHOULD directly confirm the information and release the excess resources. If more resources or lifetime are required, RM ASA on the Service Responser SHOULD treat it as a brand-new request and make decision or further negotiation. The bottom line is the Service Responser MUST allow the Service Initiator fall back to previous allocated resource, both on volume and lifetime.¶
RM ASAs on the Service Responsers MUST NOT change existing resource allocation until the new negotiation on resource changes is complete.¶
After the service is completed or expired, the reserved network resources MUST be released so that network resources can be used more efficiently. If the service lifetime expires, the Service Responser MUST release its local resources and MAY send a Synchronization message to the Service Initiator to notify the state change of its local resources. If the Service Initiator wants to end the service before the service lifetime expires, the Service Initiator MUST send a negotiation message to the Service Responsers to request the network resource to be changed to zero. Upon completion of the negotiation, the Service Responser releases the resources occupied by the service.¶
This section defines the GRASP technical objective options that are used to support autonomic resource management. ResourceManager GRASP Objective allows multiple types of resources to be requested simultaneously.¶
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 autonomic-network-service-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 = autonomic-network-service-value; An autonomic-network-service-value is defined as Figure-2.¶
autonomic-network-service-value =
[
[
service-type,
service-id,
service-lifetime,
service-tag
],[
*resource-requirement-pair
]
]
¶
Figure-2: Format of autonomic-network-service-value-value¶
service-type = 0..7¶
service-id = uint¶
service-lifetime = 0..4294967295 ; in milliseconds¶
service-tag = [ *service-tag-info]¶
The combination service-type and the service-id MUST uniquely represent a network service within the network. The uniqueness of the combination service-type and the service-id SHOULD be guaranteed by an allocation mechanism that is out of scope of this document.¶
The allocation of resources MUST specify the lifetime. The service-lifetime represents the usage time of the resources required by the service.¶
The service-tag contains other information that describes the service. This information is not necessary, but will affect the policy for RM ASA resource reservation.¶
The resource-requirement-pair describes the resource requirements and it is defined as Figure-3. Resource requirements of different types can be described in an objective option. The ResourceManager objective option supports multi-faceted resource requirements and negotiation. These resource requirements are all in pairs, described by resource type and resource value.¶
resource-requirement-pair =
[
resource-type,
resource-value
]
¶
Figure-3: Format of resource-requirement-pair¶
resource-type = 0..7¶
resource-value = uint¶
The quality transmission service scenario is the most important resource negotiation scenario. In this scenario, RM ASAs negotiate the resource that will affect the transmission quality. The basic resource is bandwidth and other types of resources such as queue can be required at the same time.¶
The autonomic deployment and management of the quality transmission service includes the Service Initiator and the Service Resopnsers all have RM ASA. The Service Initiator is the resource demander, which ensures the connection of services through negotiation resources with RM ASAs in the domain network. Service Responsers are the nodes which packets are forwarded in the transmission scenario and Service Initiator asks resource from them. These nodes can be discovered through RM ASA discovery precess or path discovery methods.¶
Negotiation Resource +-------------------------------------------------------------+ | Negotiation Resource | | +--------------------------------------------+ | | | | | +--------+ Negotiation Resource +---------+ +---------+ +---------+ | RM ASA |<-------------------->| RM ASA | | RM ASA | | RM ASA | +--------+ +---------+ +---------+ +---------+ | SI | -------------------->| SR Node |-->| SR Node |-->| SR Node | +--------+ Transmit data +---------+ +---------+ +---------+¶
Figure-3 shows how RM ASAs negotiate resources and how Service Initiator forwards packages. The RM ASA on the Service Initiator negotiates resources with the RM ASAs on the Service Responsers one by one.¶
Figure-3: An Transimision Service¶
In the process of negotiation, Service Initiator negotiates resources with Service Responsers and ensures resources enough. RM ASAs are allowed to negotiate resources for multiple rounds. It often happens that the network resources on one node cannot 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 RM ASAs on the Service Responsers feedback the maximum available resources using Resource Management Objectives in the response message. The RM ASA on the Service Initiator changes the resource requirements according to the specific requirements of the received resources and services, to carry out the next round of service negotiation.¶
+----------+ +---------+
| RM ASA | | RM ASA |
+----------+ +---------+
| SI | | SR Node |
+----------+ [[0,36732,3600000,[]][[0,10]]] +---------+
|------------------------------------------->|
| [[0,36732,3600000,[]][[0,8]]] |
|<-------------------------------------------|
| [[0,36732,3600000,[]][[0,8]]] |
|------------------------------------------->|
| Negotiation End (ACCEPT) |
|<-------------------------------------------|
¶
Figure-4 shows an example of negotiation process. In the first negotiation round, RM ASA on the Service Initiator wants to get resource from RM ASA on the Service Responsers. In this example, the service type is TransimisionService and service-id is 36732. The service will last 3600 seconds and only ask for one kind of resource 10 Mbit/s bandwith. So, the autonomic-network-service-value is [[0,36732,3600000,[]][[0,10]]].¶
Figure-4: Negotiation Process¶
When RM ASA on the Service Responser Node receives the message, if the RM ASA thinks the network can offer this required resource, it will response the ACCEPT. But if it does not meet the request, it will give how much resource it can offer. In this example, the Service Responser can offer 8 Mbit/s. The next step, RM ASA on the Service Initiator needs to decide whether to change its resource requirements according to the reply, and sends a next round negotiation. Then, RM ASA on the Service Responser finds the new resource requirement, it can meet. So, it will response ACCEPT. This is an example how ASAs negotiate resources.¶
The Service Initiator decides a coordinated value of resource and negotiates with multiple Service Responsers that need to reduce the locked resource. The Service Responsers reserve resources for service according to the negotiation results. If the operation is successful, the Service Responser reply success message to the Service Initiator. If it fails, reply failure message to the Service Initiator. And the Service Initiator will restart negotiation step.¶
When the Service Initiator receives the success message from all the Service Responsers, the service can start to transmit the message.¶
When the service is ended, it is the responsibility of Service Initiator to release all reserved resources through the dialogue with the RM ASA on the Service Responser. And if the service lifetime is exceeded, the Service Initiator SHOULD also release reserved resource although the Service Responsers may release the reserved resource by themselves.¶
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 need to be added to the "GRASP Objective Names" registry defined by [RFC8990]. And this document defines a new registry tables "service-type" and "resource-type" under the "ResourceManager" GRASP Objective. The following subsections describe the new parameters.¶
IANA has set up the "service-type" registry, which contains 4-bit value. The service-type defines the type of service which is used to describe the type of resource requirements.¶
IANA has set up the "resource-type" registry, which contains 4-bit value.¶
Valuable comments were received from Michael Richardson and Brian Carpenter.¶