Definition of Service Intent in Autonomic Networks

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

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:

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.

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 : 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 , 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.

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:

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.

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