Definition of Service Intent in Autonomic Networks
draft-zhu-anima-service-intent-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Longwei Zhu , Bizhu Wang , Sheng Jiang | ||
| Last updated | 2026-03-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zhu-anima-service-intent-00
ANIMA L. Zhu
Internet-Draft B. Wang
Intended status: Standards Track S. Jiang
Expires: 3 September 2026 BUPT
2 March 2026
Definition of Service Intent in Autonomic Networks
draft-zhu-anima-service-intent-00
Abstract
While ANIMA Intent enables goal-oriented control within an Autonomic
Domain, emerging services (e.g., AI inference) require a common,
interoperable representation for expressing service-level objectives
and constraints that span network, compute, and storage resources,
rather than connection-centric descriptions. This document defines
Service Intent for Autonomic Networks by specifying a structured
semantic model and a concise format with identification, scope,
versioning, and lifecycle semantics.
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 3 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
Zhu, et al. Expires 3 September 2026 [Page 1]
Internet-Draft service-intent March 2026
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definition of Service Intent . . . . . . . . . . . . . . . . 4
3.1. Overview and Metadata . . . . . . . . . . . . . . . . . . 4
3.2. Resource Requirement Intents . . . . . . . . . . . . . . 6
3.2.1. Network Resource Requirement Intent . . . . . . . . . 6
3.2.2. Compute Resource Requirement Intent . . . . . . . . . 7
3.2.3. Storage Resource Requirement Intent . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Within the ANIMA framework, intent is an abstract, declarative, high-
level policy applicable to an Autonomic Domain. Expressed in terms
of desired goals and constraints, intent steers network operation
rather than acting as device-level configuration commands. It is
distributed across the domain and interpreted by autonomic nodes,
which translate it into target configurations while considering local
state and environmental constraints. This approach enables closed-
loop automation and reduces the operational burden on human operators
by shifting from imperative configuration to goal-oriented
management.
Zhu, et al. Expires 3 September 2026 [Page 2]
Internet-Draft service-intent March 2026
However, emerging services increasingly rely on the coordinated use
of heterogeneous resources beyond simple connectivity. Traditional
connection-centric service descriptions, which primarily specify
endpoints and basic transport characteristics, are insufficient to
represent user-perceived quality objectives for complex tasks such as
AI inference, interactive media processing, and large-scale content
rendering. These services are often constrained not only by network
performance (e.g., bandwidth, latency, and jitter), but also by
compute availability (e.g., processing capacity and placement-induced
request latency) and storage capabilities (e.g., capacity and access
throughput). Moreover, practical deployment decisions frequently
require expressing cross-resource coordination constraints, such as
coupling compute placement with transport path selection, or
accounting for the time cost of data access along selected paths.
This document introduces and defines the concept of Service Intent
for Autonomic Networks by analyzing the characteristics of user
service demand expressed as intent. The aim is to provide a
structured, declarative, semantic framework that enables service-
level requirements and constraints across network, compute, and
storage dimensions to be specified consistently. By enabling the
autonomic interpretation of these requirements within an Autonomic
Domain, the Service Intent model facilitates the automated discovery,
selection, routing, and scheduling of resources, thereby supporting
the automated deployment of services and reducing the complexity of
using heterogeneous resources. The detailed mechanisms for realizing
intent interpretation and automated service deployment are out of
scope for this document and are described in
[I-D.ietf-anima-network-service-auto-deployment] and [draft-du-anima-
service-intent-auto-deployment].
In addition, this document specifies a concrete, machine-readable
format for Service Intent to support interoperable intent exchange
and processing within an Autonomic Domain, including essential fields
for identification, scoping, versioning, and lifecycle management,
and a structured representation of intent content aligned with
network-, compute-, and storage-resource requirement intents.
2. Requirements
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.
Zhu, et al. Expires 3 September 2026 [Page 3]
Internet-Draft service-intent March 2026
3. Definition of Service Intent
This section defines a Service Intent as a structured, machine-
interpretable declaration of the desired service objectives and
associated resource constraints for autonomic service deployment
within Autonomic Networks.
3.1. Overview and Metadata
Unlike traditional connectivity-oriented service descriptions that
primarily specify endpoints and transport parameters, a Service
Intent expresses coordinated, multi-dimensional requirements across
heterogeneous infrastructure resources. These requirements MAY span
compute resources, storage resources, transport resources, and cross-
layer or cross-domain constraints. By abstracting the desired
service outcome rather than specific configuration actions, a Service
Intent enables automated resource discovery, path computation,
compute scheduling, and storage placement, thereby supporting goal-
driven service orchestration and deployment.
The Service Intent model defined herein is outcome-oriented rather
than configuration-oriented. It specifies the intended operational
state of a service without mandating implementation procedures,
device-level configurations, or specific realization mechanisms.
The Service Intent consists of the following fields:
service-intent = {
"intent-id" : uint,
"intent-version" : uint,
"intent-timestamp" : uint, ; Epoch time
"intent-scope" : scope-obj, ; in seconds
"intent-content" : content-obj
}
* Intent Identifier(unsigned integer). The Intent Identifier
uniquely identifies an intent instance within its applicable
scope. It MUST be unique within the defined scope and MUST remain
stable across version updates of the same intent.
* Intent Version(unsigned integer). The Intent Version indicates
the revision of a Service Intent. It MUST increase monotonically
upon modification and MUST enable determination of the most recent
intent state.
* Intent Timestamp(unsigned integer, epoch time). The Intent
Timestamp indicates the time at which a Service Intent instance
was created, issued, or last updated.
Zhu, et al. Expires 3 September 2026 [Page 4]
Internet-Draft service-intent March 2026
* Intent Lifetime(unsigned integer, seconds). The Intent Lifetime
defines the temporal validity period during which a Service Intent
is considered active, observable, and eligible for evaluation or
enforcement within its declared Intent Scope. A Service Intent
instance MUST be considered expired when its defined lifetime
condition is met.
* Intent Scope (object). The Intent Scope defines the applicability
scope of a Service Intent. It MUST identify at least one
Autonomic Domain in which the intent is valid, and MAY further
restrict applicability to specific sub-domains, logical
partitions, tenants, service slices, or topology segments. An
autonomic node MUST only process the Service Intent applicable
within its operational scope.
scope-obj = {
"domain" : tstr,
? "subdomain" : tstr,
? "tenant" : tstr,
? "topology-segment" : tstr
}
* Intent Content (object). A Service Intent MUST be expressed as a
structured object that MAY include one or more of the following
logical components defined in Section 3.2: a) Network resource
requirement intent; b) Compute resource requirement intent; c)
Storage resource requirement intent. Each component declaratively
specifies the desired target state of the corresponding resource
dimension and MAY include inter-resource dependency constraints.
The content-obj MAY include any subset of the three members,
depending on the service scenario. Processing of content-obj MUST
handle each present member independently according to the
semantics defined in Section 3.2, and SHOULD combine multiple
present members to derive a consistent multi-resource provisioning
decision. If none of the three members is present, content-obj is
invalid and MUST be ignored. Any unrecognized additional member
MUST be ignored and MUST NOT cause failure in processing of
recognized members.
content-obj = {
? "network" : network-intent,
? "compute" : compute-intent,
? "storage" : storage-intent
}
Zhu, et al. Expires 3 September 2026 [Page 5]
Internet-Draft service-intent March 2026
3.2. Resource Requirement Intents
3.2.1. Network Resource Requirement Intent
The Network resource requirement intent specifies the required
network resource capabilities necessary to satisfy the service. It
expresses quantitative and qualitative requirements over transport
resources within the declared Intent Scope. These requirements
define the desired performance, availability, and forwarding
characteristics of network resources allocated for the service.
The Network resource requirement intent includes the following
fields:
network-intent = {
"Bandwidth-Requirement" : uint, ; Bandwidth Requirement(bps)
"latency-bound" : uint, ; Latency Bound(ms)
"jitter-bound" : uint, ; Jitter Bound(ms)
"destinations" : 1* tstr, ; non-empty array of text strings
"multipath-permission" : bool, ; TRUE allows multipath
}
* Bandwidth Requirement (unsigned integer, bps). The minimum or
guaranteed bandwidth required. The value MUST be greater than or
equal to 0; if it is specified as zero, no minimum bandwidth
constraint is imposed.
* Latency Bound (unsigned integer, ms). The maximum acceptable end-
to-end delay. The value MUST be greater than or equal to 0; if it
is specified as zero, no latency constraint is imposed.
* Jitter Bound (unsigned integer, ms). The maximum acceptable delay
variation. The value MUST be greater than or equal to 0; if it is
specified as zero, no jitter constraint is imposed.
* Destinations (array of text strings, non-empty). Target endpoint
or location identifiers; MUST contain at least one element.
* Multipath Permission (boolean). A boolean indicator specifying
whether multipath transport MAY be used; TRUE allows multipath,
FALSE forbids multipath.
Zhu, et al. Expires 3 September 2026 [Page 6]
Internet-Draft service-intent March 2026
3.2.2. Compute Resource Requirement Intent
The Compute resource requirement intent specifies the required
computational resource capabilities necessary to satisfy the service.
It expresses quantitative and qualitative requirements over compute
resources within the declared Intent Scope. These requirements
define the desired processing capacity, placement constraints, and
latency characteristics of compute resources allocated for the
service.
The Compute resource requirement intent includes the following
fields.
compute-intent = {
; Request Latency Bound(ms)
"request-latency" : uint,
; TRUE allows concurrent transport/compute
"transport-coordination" : bool,
; Compute Capacity Requirement
"compute-capacity" : 1* compute-capa
}
compute-capa = {
; "cpu" or "gpu"
"type" : ("cpu" / "gpu"),
; Compute capacity value(GFLOPS)
"capacity" : uint
}
* Request Latency Bound (unsigned integer, ms). The maximum
acceptable request-to-response latency between the service and the
compute resource. The value MUST be greater than or equal to 0;
if it is specified as zero, no latency constraint is imposed.
* Transport Coordination (boolean). A boolean indicator that
specifies whether compute processing and data transport are
permitted to proceed concurrently.
- TRUE: Compute processing and data transport MAY proceed
concurrently (i.e., streaming or pipelined execution). Data
MAY be transmitted incrementally during processing.
- FALSE: Compute processing and data transport MUST be executed
in separate phases. Data MUST be fully processed before
transmission, or fully transmitted before processing begins.
Zhu, et al. Expires 3 September 2026 [Page 7]
Internet-Draft service-intent March 2026
* Compute Capacity Requirement (array). Contains at leaset one
compute-capacity element. Each compute-capacity element is a
structured requirement that specifies the minimum compute capacity
needed to satisfy the service for a given type of computing
resource. The compute-capacity is as follows.
- Type (text). Indicates the type of compute resource. The
values "cpu" and "gpu" are defined by this document.
- Capacity (unsigned integer, GFLOPS). The minimum compute
capacity required for the specified type. The value MUST be
greater than or equal to 0; if it is specified as zero, no
minimum compute capacity constraint is imposed for that type.
3.2.3. Storage Resource Requirement Intent
The Storage resource requirement intent specifies the required
storage resource capabilities necessary to satisfy the service. It
expresses quantitative and qualitative requirements over storage
resources within the declared Intent Scope. These requirements
define the desired capacity, performance, locality, and persistence
characteristics of storage resources allocated for the service.
The Storage resource requirement intent includes the following
fields:
storage-intent = {
; Storage Capacity Requirement(GB)
"storage-capacity" : uint,
; Throughput numeric value
"storage-throughput" : uint,
? "storage-throughput-unit" : ("MB/s" / "GB/s"),
}
* Storage Capacity Requirement (unsigned integer, GB). The required
storage capacity representing the temporary or persistent space
necessary to satisfy the service. The value MUST be greater than
or equal to 0; if it is specified as zero, no minimum storage
capacity constraint is imposed.
* Storage Throughput Requirement (unsigned integer, MB/s or GB/s).
The required data access throughput representing the read and
write rate necessary to satisfy the workload. The value MUST be
greater than or equal to 0; if it is specified as zero, no minimum
storage throughput constraint is imposed.
Zhu, et al. Expires 3 September 2026 [Page 8]
Internet-Draft service-intent March 2026
4. IANA Considerations
There is currently no IANA consideration.
5. Security Considerations
A strong security environment is required for the Service Intent,
since malicious injection or tampering would pose a significant risk
to automated resource selection and service deployment. If a Service
Intent is disseminated and synchronized across an autonomic domain,
the signaling channel must provide mutual authentication and
integrity protection consistent with the Autonomic Domain security
environment. In addition, an intent instance should employ an
explicit signature to provide object-level authentication, integrity,
and non-repudiation.
TODO more security considerations.
6. References
6.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>.
[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>.
[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>.
6.2. Informative References
[I-D.ietf-anima-network-service-auto-deployment]
Jiang, S. and Z. Du, "An Intent-based Framework of Network
Services Autonomic Deployment and Management", Work in
Progress, Internet-Draft, draft-ietf-anima-network-
service-auto-deployment-07, 1 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-anima-
network-service-auto-deployment-07>.
Zhu, et al. Expires 3 September 2026 [Page 9]
Internet-Draft service-intent March 2026
[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
Longwei Zhu
Beijing University of Posts and Telecommunications
No. 10 Xitucheng Road
Haidian District, Beijing
China
Email: lwzhu@bupt.edu.cn
Bizhu Wang
Beijing University of Posts and Telecommunications
No. 10 Xitucheng Road
Haidian District, Beijing
China
Email: wangbizhu_7@bupt.edu.cn
Sheng Jiang
Beijing University of Posts and Telecommunications
No. 10 Xitucheng Road
Haidian District, Beijing
China
Email: shengjiang@bupt.edu.cn
Zhu, et al. Expires 3 September 2026 [Page 10]