| Internet-Draft | service-intent | March 2026 |
| Zhu, et al. | Expires 3 September 2026 | [Page] |
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.¶
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 (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.¶
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.¶
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.¶
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.¶
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 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.¶
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.¶
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
}
¶
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.¶
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.¶
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.¶
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.¶
There is currently no IANA consideration.¶
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.¶