An Intent-based Framework of Network Services Autonomic Deployment and Management

Traditionally, IP networks are based on the best-effort 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 support from steady network resources, such as bandwidth, queues, memory, priority, computational resources, etc. These network applications are strongly based on the availability and stability of network resources. To enable these resource-based applications and services, the IETF have developed many resource reservation mechanisms, such as RSVP that is mainly to reserve bandwidth only and path-oriented. 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. However, the requirements for network resources from various end users are highly diverse and dynamic. Mechanisms that enable trustworthy users or user nodes, not only rigid network management plane, to dynamically and autonomically deploy and manage their customized network services are urgently needed. Yet, designing such mechanisms in wide networks is quite challenging due to their architecture and inherent complexity. It is much more feasible to design such mechanisms within autonomic networks, giving more secured and extensible autonomic network infrastructure. This document introduces an intent-based framework for network services autonomic deployment and management. Within autonomic networks, every node are secured and trustworthy, giving the secure precondition provided by the Autonomic Control Plane (ACP) and the Bootstrapping Remote Secure Key Infrastructure (BRSKI) . These nodes, representing the applications or end users on them, can describe their customized requirements for network resources into a service intent, which is described in . Then, the RM ASAs, defined in this document, would breakdown these requirements and dynamically dispatches network resources, by using the GeneRic Autonomic Signaling Protocol (GRASP) to dynamically negotiate among the autonomic nodes. This framework is generic and applicable to most, if not all, of types of network resources. It can be easily extended to support any newly-appear network resources. It can be used, but not limited, in the following network scenarios: Quality transmission. The quality could mean guaranteed bandwidth, or jitter, etc. In order to guarantee the quality of network transmission, the network should reserve transmission resources, particularly bandwidth or queues, on a selected path from the ingress to the egress node. The dynamic resource dispatching mechanism should ensure the consistency of reserved resources on all the nodes along this path, particularly when dynamic changes are made on this path. Differentiated transmission. The network may provide differentiated transmission by putting the user packets into different processes that have different resources, such as bandwidth, queue lengths, priorities, etc. The result would be different user experience in delay and jitter, or even packet-loss rate. In-network cache/storage. The network may provide in-network cache or storage via memory within the network devices or attached devices. The idle memory space is a resource that needs to be requested and managed. The location or distance of the memory is also relevant to user experience. Computing offload or in-network computing. More and more spare computational resources are available from network providers. They may be idle computational cycles on the network devices or deployed computational servers. The consumption of these computational resources is time-sensitive. Also, the location or distance of the computational resources is relevant to user experience. Computing resources in the transmission path can also execute computational tasks within network elements during data transmission. Information provision. In some scenarios, the network may be the best information provider. It may be the information from or generated by the network itself. Or the network has the best location to provide the information. Multiple resource management in data centers. Within data centers, autonomic resource management shall integrate traffic, storage, and computing power to optimize performance and efficiency. It shall dynamically allocate network bandwidth, computational CPU/GPU cores, and storage I/O based on real-time demand, ensuring balanced workloads and minimal latency. This holistic approach prevents bottlenecks, maximizes hardware utilization, and supports scalable, reliable cloud services. This document defines a new Autonomic Resource Management Objective in . Three new corresponding registries are defined in .

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.

This document builds upon and extends the previous terminology defined in and . Network Service: a customizable composite of network resources, defined by trustworthy users or the network management plane to fulfill specific operational requirements through the orchestrated combination of underlying infrastructure elements. Service Intent: the declarative expression of requirements that specifies the desired characteristics, constraints, and objectives for a network service, serving as the input for resource dispatching without detailing implementation mechanisms. RM ASA: the Resource Manager ASA on autonomic nodes. It manages the local resources on the node, such as bandwidth, queues, memory, priority, computational resources, etc. The RM ASA communicates with other counterpart RM ASAs in order to dynamically dispatch network resources within the autonomic network domain. This document assumes all autonomic nodes have an RM ASA. Service Initiator: the autonomic node that initiates and manages a network service. It receives and processes a Service Intent by parsing the intent into discrete resource requests with associated constraints. It subsequently initiates resource requests and dynamically adjusts the resources for this network service through its RM ASA by negotiating with relevant network elements. Service Responder: the autonomic node that responds to requests from the Service Initiator. It receives the requests through its RM ASA, checks or operates on its local resources, and responds with the results to the Service Initiator. Typically, a network service MAY involve multiple Service Responders. Ensuring consistency among them is the responsibility of the Service Initiator.

This section describes the generic procedures of autonomic deployment and management of the resource-based network services, as Figure-1 shows. The format of service intent is defined in [draft-zhu-anima-service-intent]. The prepositive operation that inputs/setup/initiates the service intent is out of the scope of this document. The detailed implementation or internal algorithms of the Resource Manager ASAs are out of scope. The specific details that depend on certain network services or certain type of network resources are also out of scope. Modifications on a service intent may trigger the dynamic service changes.

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

On the node where a service intent is provided, the service intent that describes the customized network resource requirements as stipulated by trustworthy users or network management systems, undergoes a comprehensive decomposition process. This process translates the high-level intent into granular, specific requirements across various categories of network resources, including but not limited to transmission bandwidth, data storage capacity, computational power, and information accessibility/provision. Following this decomposition, the RM ASA on the Service Initiator node is activated. The primary function of this RM ASA is to dynamically orchestrate, allocate, and dispatch the required network resources in real-time, ensuring that the service intent is fulfilled efficiently and adaptively throughout its lifecycle.

The Service Initiator MAY first discover the relevant network nodes according to the resource requirements described in the service intent in order to reduce the node range of sending GRASP Discovery message. It may be all the nodes on a given path or nodes that have idle resources available for given service condition, etc. The node discovery methods can be pre-configured, outbound discovery, path detection, etc. The Service Initiator SHOULD send out a GRASP Discovery message that contains a Resource Manager Objective option defined in , in which the network service is described. The Discovery message SHOULD be sended to the reduced range nodes, by the abovementioned mechanism, or all nodes within the AN domain. A RM ASA that receives the Discovery message with the Resource Manager Objective option SHOULD check its satisfaction against the service description. If it meets the requirements, the node is a proper Service Responder. It SHOULD respond with a GRASP Response message back to the Service Initiator. Defined in the section 2.5.5.1 of , the Discovery message MAY be combined 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 SHOULD fall back to the normal discovery-only process.

In principle, any operations on resources MUST be authorized. The Service Responder 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, since the Autonomic Control Plane (ACP) and the Bootstrapping Remote Secure Key Infrastructure (BRSKI) 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 Resource Manager Objective option, in which the value of the requested resource is indicated. When the RM ASA on a Service Responder 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 Resource Manager 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 Responder 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 Responder may cause it to indicate the existing available value within a Resource Manager 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 Responder reserves its local resources. The Service Initiator may use the negotiated resource after receiving the 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 Responders to ensure the consistency of reserved resources.

After the process of automatic resource management mechanism, the 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. The Resource Manager ASA needs to be able to handle resource changes in a timely manner to meet service requirements. During the renegotiation process, the RM ASA on the Service Initiator resends the service's resource requirements by using the Resource Manager GRASP Objective. The RM ASA on the Service Responder receives the resource negotiation message and makes the determination. If the resource requirements are lower than those allocated or/and shorter lifetime than previous, the Service Responder SHOULD directly confirm the information and release the excess resources. If more resources or lifetime are required, the RM ASA on the Service Responder SHOULD treat it as a brand-new request and make a decision or further negotiation. The bottom line is the Service Responder MUST allow the Service Initiator to fall back to previous allocated resource, both in volume and lifetime. RM ASAs on the Service Responders 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 Responder 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 Responders to request the network resources to be changed to zero. Upon completion of the negotiation, the Service Responder releases the resources occupied by the service.

This section defines the GRASP technical objective options that are used to support autonomic resource management. The Resource Manager GRASP Objective allows multiple types of resources to be requested simultaneously. The Resource Manager Objective option is a GRASP Objective option conforming to the GRASP specification . Its name is "Resource Manager", and it carries the following data items as its value: the resource value. Since GRASP is based on CBOR (Concise Binary Object Representation) , the format of the Resource Manager Objective option is described in the Concise Data Definition Language (CDDL) as follows: objective = ["Resource Manager", objective-flags, loop-count, ?objective-value] objective-name = "Resource Manager" objective-flags = uint .bits objective-flag ; as in the GRASP specification loop-count = 0..255 ; as in the GRASP specification The 'objective-value' field represents 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.

Figure-2: Format of autonomic-network-service-value service-type = 0..7 service-id = uint service-lifetime = 0..4294967295 ; in milliseconds service-tag = [ *service-tag-info] The combination of 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 the scope of this document. Every resource allocation MUST specify a 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 optional, but will affect the policy for the 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 Resource Manager objective option supports multi-faceted resource requirements and negotiation. These resource requirements are all in pairs, described by resource type and resource value.

Figure-3: Format of resource-requirement-pair resource-type = 0..7 resource-value = uint

It complies with GRASP security considerations. Relevant security issues are discussed in . The preferred security model is that devices are trusted following the secure bootstrap procedure and that a secure Autonomic Control Plane (ACP) is in place.

This document defines a new GRASP Objective option name: "Resource Manager", which needs to be added to the "GRASP Objective Names" registry defined by . This document defines a new registry tables "service-type" and "resource-type" under the "Resource Manager" 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. 0 : Transmission Service 1 : Computing Service

IANA has set up the "resource-type" registry, which contains 4-bit value. 0 : bandwidth 1 : queue 2 : memery 3 : priority 4 : cache 5 : computing

Valuable comments were received from Michael Richardson and Brian Carpenter. Contributions to early versions of this document was made by Yujing Zhou, Joanna Dang.