An Intent-based Framework of Network Services Autonomic Deployment and Management
draft-ietf-anima-network-service-auto-deployment-08
| Document | Type | Active Internet-Draft (anima WG) | |
|---|---|---|---|
| Authors | Sheng Jiang , Zongpeng Du | ||
| Last updated | 2026-10-21 | ||
| Replaces | draft-dang-anima-network-service-auto-deployment | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Parked WG Document | |
| Document shepherd | Toerless Eckert | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | tte@cs.fau.de |
draft-ietf-anima-network-service-auto-deployment-08
ANIMA S. Jiang, Ed.
Internet-Draft BUPT
Intended status: Standards Track Z. Du
Expires: 24 April 2027 China Mobile
21 October 2026
An Intent-based Framework of Network Services Autonomic Deployment and
Management
draft-ietf-anima-network-service-auto-deployment-08
Abstract
This document introduces an intent-based framework for network
services autonomic deployment and management. It autonomically
deploys network services that require customized combinations of
network resources and dynamically manages these resources throughout
their lifecycle. The framework leverages the GeneRic Autonomic
Signaling Protocol (GRASP) to facilitate the dynamic exchange of
resource management signals among autonomic nodes, thereby enabling
coordinated and consistent operations within an autonomic network
domain. This framework is generic and applicable to most types of
network resources.
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 24 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Jiang & Du Expires 24 April 2027 [Page 1]
Internet-Draft Auto-Deployment of Network Services October 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology & Abbreviations . . . . . . . . . . . . . . . . . 4
4. A Generic Auto-deployment Mechanism of Resource-based Network
Services . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Service Intent initiates RM ASA for Service Deployment . 6
4.2. Discover RM ASAs on Proper Service Responders . . . . . . 7
4.3. Authentication and Authorization . . . . . . . . . . . . 7
4.4. Negotiate Resource with Service Responder . . . . . . . . 7
4.5. Change Reserved Resources . . . . . . . . . . . . . . . . 8
4.6. Releasing Resources during Service Ending . . . . . . . . 9
5. Autonomic Resource Management Objectives . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. Service type . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Resource Type . . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
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 [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
Jiang & Du Expires 24 April 2027 [Page 2]
Internet-Draft Auto-Deployment of Network Services October 2026
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) [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 is 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 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.
Jiang & Du Expires 24 April 2027 [Page 3]
Internet-Draft Auto-Deployment of Network Services October 2026
* 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 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].
Jiang & Du Expires 24 April 2027 [Page 4]
Internet-Draft Auto-Deployment of Network Services October 2026
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.
4. A Generic Auto-deployment Mechanism of Resource-based Network
Services
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.
Jiang & Du Expires 24 April 2027 [Page 5]
Internet-Draft Auto-Deployment of Network Services October 2026
+--------------+
|Service Intent|
+--------------+
||
+-----------------+ +-----------------+
| RM ASA | | RM ASA |
|Service Initiator| |Service Responder|
+-----------------+ 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
4.1. Service Intent initiates RM ASA for Service Deployment
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.
Jiang & Du Expires 24 April 2027 [Page 6]
Internet-Draft Auto-Deployment of Network Services October 2026
4.2. Discover RM ASAs on Proper Service Responders
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 Section 5, 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 [RFC8990], 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.
4.3. Authentication and Authorization
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) [RFC8994] and the
Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] has
provided the secure environment for this mechanism.
4.4. Negotiate Resource with Service Responder
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
Jiang & Du Expires 24 April 2027 [Page 7]
Internet-Draft Auto-Deployment of Network Services October 2026
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.
4.5. Change 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.
Jiang & Du Expires 24 April 2027 [Page 8]
Internet-Draft Auto-Deployment of Network Services October 2026
4.6. Releasing Resources during Service Ending
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.
5. Autonomic Resource Management Objectives
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 [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 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.
Jiang & Du Expires 24 April 2027 [Page 9]
Internet-Draft Auto-Deployment of Network Services October 2026
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 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.
Jiang & Du Expires 24 April 2027 [Page 10]
Internet-Draft Auto-Deployment of Network Services October 2026
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 name: "Resource
Manager", which needs to be added to the "GRASP Objective Names"
registry defined by [RFC8990]. 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.
7.1. Service type
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
7.2. Resource Type
IANA has set up the "resource-type" registry, which contains 4-bit
value.
* 0 : bandwidth
* 1 : queue
Jiang & Du Expires 24 April 2027 [Page 11]
Internet-Draft Auto-Deployment of Network Services October 2026
* 2 : memery
* 3 : priority
* 4 : cache
* 5 : computing
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.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
Autonomic Signaling Protocol (GRASP)", RFC 8990,
DOI 10.17487/RFC8990, May 2021,
<https://www.rfc-editor.org/info/rfc8990>.
Jiang & Du Expires 24 April 2027 [Page 12]
Internet-Draft Auto-Deployment of Network Services October 2026
[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
Autonomic Control Plane (ACP)", RFC 8994,
DOI 10.17487/RFC8994, May 2021,
<https://www.rfc-editor.org/info/rfc8994>.
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/info/rfc8995>.
9.2. Informative References
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking: Definitions and Design Goals", RFC 7575,
DOI 10.17487/RFC7575, June 2015,
<https://www.rfc-editor.org/info/rfc7575>.
[RFC8993] Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia,
L., and J. Nobre, "A Reference Model for Autonomic
Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021,
<https://www.rfc-editor.org/info/rfc8993>.
Authors' Addresses
Sheng Jiang (editor)
Beijing University of Posts and Telecommunications
No. 10 Xitucheng Road
Beijing
Haidian District, 100083
China
Email: shengjiang@bupt.edu.cn
Zongpeng Du
China Mobile
32 Xuanwumen West Street
Beijing
P.R. China, 100053
China
Email: duzongpeng@chinamobile.com
Jiang & Du Expires 24 April 2027 [Page 13]