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

Status of This Memo

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 2 September 2026.¶

Copyright Notice

Copyright (c) 2026 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.¶

Table of Contents

1. Introduction

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. These network applications are strongly based on the availability and stability 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. 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 challenge 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 nodes are secured and trustworthy, giving the secure precondition provided by the Autonomic Control Plane (ACP) [RFC8994] and the Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995]. These nodes, representing the applications or end users on them, can describe their customized requirements for network resources into a service intent, which are described in [RFC7575]. Then, the RM ASAs, defined in Section 3 this document, would breakdown these requirements and dynamically dispatches network resources, by using the GeneRic Autonomic Signaling Protocol (GRASP) [RFC8990] 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 no limited, in below network scenarios:¶

• Quality transmission. The quality could means guaranteed bandwidth, or jitter, etc. In order guarantee the quality of network transmission, the network should reserve transmission resource, particularly bandwidth or queues, on a selected path from the ingress to the egress node. The dynamic resource dispatching mechanism should ensure the consistent of reserved resources on all the nodes in this path, particularly, when dynamic changes are operated on this path.¶

• Difference transmission. The network may provide different transmission by putting the user packets into different processes that have different resources, such as bandwidth, queue length, priority, etc. The results would be different user experience in delay and jitter, or even packet lose rate.¶

• In-network cache/storage. The network may provide in-network cache or storage by memory in the network devices or attached devices. The idle memory space is the resource that need to be request 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 from network providers. They may be idle computational cycles on the network devices or deployed computational servers. The occupation of these computational resources is time-sensitive. Also, the location or distance of the computational resource is relevant to user experience. Computing resource in the transmission path can also executes computational tasks within network elements during data transmission.¶

• Information provision. In some scenarios, network may be the best information provider. It may be the information are from or generated by 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 an Autonomic Resource Management Objective in Section 5. Three new corresponding registries are defined in Section 7.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Terminology & Abbreviations

This document builds upon and extends the previous terminology defined in [RFC7575] and [RFC8993].¶

Network Service: a customizable composite of network resources, defined by trustworthy users or 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, 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 receives and processing a Service Intent by parsing the intent into discrete resource requests with associated constraints. It subsequently initiates resource requests and dynamically adjusts these resources of this network service through its RM ASA by negotiating with relevant network elements.¶

Service Responder: 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 Responders. The consistency among them is the responsibility of the Service Initiator.¶

5. Autonomic Resource Management Objectives

This section defines the GRASP technical objective options that are used to support autonomic resource management. 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 [RFC8990]. 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) [RFC8949], the format of the Resource Manager Objective option is described in the Concise Data Definition Language (CDDL) [RFC8610] 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 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¶

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

resource-requirement-pair =
     [
      resource-type,
      resource-value
     ]

Figure-3: Format of resource-requirement-pair¶

resource-type = 0..7¶

resource-value = uint¶

6. Security Considerations

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

7. IANA Considerations

This document defines a new GRASP Objective option names: "Resource Manager" 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 "Resource Manager" GRASP Objective. The following subsections describe the new parameters.¶

8. Acknowledgements

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

Authors' Addresses