]> ZTE Corporation

xiong.quan@zte.com.cn

HPE

kireeti.ietf@gmail.com

Lancaster University

d.king@lancaster.ac.uk

teas This document defines a common service intent model for High Performance Computing (HPC) and AI workloads over High Performance Wide Area Networks (HP-WANs). The model allows heterogeneous workload managers and orchestration platforms to express endpoint, communication pattern, timing, performance, data movement, policy, and admission requirements for network services without exposing technology-specific tunnel realization details.

Introduction HPC and AI workloads increasingly depend on coordinated compute, storage, and network resources across data center domains and geographically distributed sites. Workload managers and orchestration systems often know when a workload should run, which systems need to communicate, how much data is expected to move, and what performance characteristics are needed for the workload to complete successfully. The HP-WAN environment, including data-intensive applications, high-throughput transmission, completion-time objectives, admission control, traffic scheduling, and host-network collaboration, is described in and . Related work on machine learning cluster scheduling, including , describes environments in which workload timing and network behavior affect job completion time and predictability. This document defines a common way for workload-facing systems to express the desired network outcome without directly configuring network mechanisms. Existing scheduler and orchestration models are platform-specific and primarily describe compute resources, accelerator resources, job placement, queues, and lifecycle state. They do not provide a common, technology-independent model for expressing the network service intent associated with a scheduled workload. The service intent requirements in this document are informed by the information available from widely deployed workload schedulers and AI orchestration platforms, while the interface is intended for use by data center and inter-data-center network controllers, orchestrators, and brokers. This separation allows workload-facing systems to expose network-relevant intent without becoming responsible for network realization. This document defines the common service intent model. It is intended to consume scheduler and job metadata defined separately in and to provide a northbound service abstraction for network controllers or orchestrators. The mapping from accepted service intent to tunnels, paths, policy, and resource allocation is defined separately by a tunnel realization model.

Conventions Used in This Document

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 when, and only when, they appear in all capitals, as shown here.

Terminology The terms Workload, Job, Task, Scheduler, Scheduler Job Metadata, Service Intent, Tunnel Realization, and Correlation Identifier are defined in . This document uses those terms with the meanings defined there. This document defines following terms:

Service Intent Instance:

A network service request associated with scheduler job metadata, containing endpoint, performance, and policy requirements. It is identified by an intent identifier and can reference workload, job, and correlation identifiers from the scheduler job metadata model.

Admission State:

The network controller's response indicating whether a service intent can be fulfilled, including any modifications or constraints.

Model Scope The service intent model expresses what network service is requested by a workload. It includes workload correlation, endpoints, endpoint groups, communication pattern, requested timing, data movement requirements, performance objectives, policy preferences, and admission state. The model intentionally excludes low-level path computation, label programming, tunnel configuration, and technology-specific traffic engineering parameters. Those details are part of network realization. The model is intended to be usable at the boundary between workload management domains and network orchestration domains, including data center and inter-data-center environments.

Model Structure

Relationship to Other Models The service intent model can refer to scheduler and job metadata using workload identifiers, job identifiers, or correlation identifiers. This allows a service request to remain independent of the originating scheduler while preserving traceability to the workload. Once an intent is admitted, one or more realization references can be returned. These references point to network realization state, such as tunnels or controller-managed service instances, without requiring the workload manager to configure those resources directly.

Open Issues and Design Considerations Future revisions need to refine the identity values for workload roles, communication patterns, resilience levels, data volume units, rate units, latency units, loss units, and admission status. The model also needs to define whether admission alternatives are represented inline or as separate candidate service intent instances. The model needs to clarify which workload-level attributes are essential to service intent and which are only correlation metadata provided by the scheduler or orchestration system. Additional requirements such as cost and fairness also need to be considered and, if in scope, defined in a form that is actionable by a controller. The lifecycle handling for create, update, activation, completion, suspension, and cancellation of requested HPC or AI services needs further definition. The model also needs to clarify how endpoint groups and communication patterns such as unicast, multicast, point-to-multipoint, and multipoint service requests are represented. Admission outcomes need further definition, including how accepted, modified, rejected, provisioned, completed, and failed states are returned to the requesting workload manager.

YANG Data Model The YANG data model is as follows: WG List: Editor: Quan Xiong Editor: Kireeti Kompella Editor: Daniel King "; description "This module defines a common service intent model for High Performance Computing (HPC) and AI workloads over High Performance Wide Area Networks (HP-WANs). The model allows workload managers and orchestration platforms to express network service requirements without exposing technology-specific realization details. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2026-04-23 { description "Initial version of the HPC/AI service intent model."; reference "RFC XXXX: HPC/AI Service Intent Model"; } /* * Identity definitions */ identity endpoint-role { description "Base identity for endpoint roles."; } identity compute-node { base endpoint-role; description "Compute node endpoint role."; } identity storage-node { base endpoint-role; description "Storage node endpoint role."; } identity parameter-server { base endpoint-role; description "Parameter server endpoint role."; } identity communication-pattern { description "Base identity for communication patterns."; } identity unicast { base communication-pattern; description "Unicast communication pattern."; } identity multicast { base communication-pattern; description "Multicast communication pattern."; } identity broadcast { base communication-pattern; description "Broadcast communication pattern."; } identity all-to-all { base communication-pattern; description "All-to-all communication pattern."; } identity flow-direction { description "Base identity for flow directions."; } identity unidirectional { base flow-direction; description "Unidirectional flow."; } identity bidirectional { base flow-direction; description "Bidirectional flow."; } identity symmetric { base flow-direction; description "Symmetric bidirectional flow."; } identity duration-unit { description "Base identity for duration units."; } identity seconds { base duration-unit; description "Duration in seconds."; } identity minutes { base duration-unit; description "Duration in minutes."; } identity hours { base duration-unit; description "Duration in hours."; } identity data-volume-unit { description "Base identity for data volume units."; } identity bytes { base data-volume-unit; description "Data volume in bytes."; } identity kilobytes { base data-volume-unit; description "Data volume in kilobytes."; } identity megabytes { base data-volume-unit; description "Data volume in megabytes."; } identity gigabytes { base data-volume-unit; description "Data volume in gigabytes."; } identity terabytes { base data-volume-unit; description "Data volume in terabytes."; } identity rate-unit { description "Base identity for rate units."; } identity bps { base rate-unit; description "Bits per second."; } identity kbps { base rate-unit; description "Kilobits per second."; } identity mbps { base rate-unit; description "Megabits per second."; } identity gbps { base rate-unit; description "Gigabits per second."; } identity tbps { base rate-unit; description "Terabits per second."; } identity latency-unit { description "Base identity for latency units."; } identity microseconds { base latency-unit; description "Latency in microseconds."; } identity milliseconds { base latency-unit; description "Latency in milliseconds."; } identity loss-unit { description "Base identity for loss units."; } identity percentage { base loss-unit; description "Loss as percentage."; } identity parts-per-million { base loss-unit; description "Loss in parts per million."; } identity throughput-unit { description "Base identity for throughput units."; } identity packets-per-second { base throughput-unit; description "Throughput in packets per second."; } identity bytes-per-second { base throughput-unit; description "Throughput in bytes per second."; } identity resilience-level { description "Base identity for resilience levels."; } identity none { base resilience-level; description "No resilience required."; } identity path-protection { base resilience-level; description "Path protection resilience."; } identity node-protection { base resilience-level; description "Node protection resilience."; } identity link-protection { base resilience-level; description "Link protection resilience."; } identity admission-status { description "Base identity for admission status values."; } identity pending { base admission-status; description "Admission decision pending."; } identity accepted { base admission-status; description "Service intent accepted as requested."; } identity modified { base admission-status; description "Service intent accepted with modifications."; } identity rejected { base admission-status; description "Service intent rejected."; } identity provisioning { base admission-status; description "Service is being provisioned."; } identity active { base admission-status; description "Service is active and operational."; } identity completed { base admission-status; description "Service has completed successfully."; } identity failed { base admission-status; description "Service has failed."; } /* * Typedefs */ typedef priority-type { type uint32 { range "0..1000"; } description "Priority value type, with higher values indicating higher priority."; } /* * Groupings */ grouping workload-reference-grouping { description "Workload reference for correlating with scheduler job metadata."; leaf workload-id { type string; description "Reference to workload identifier from scheduler metadata."; } leaf job-id { type string; description "Reference to job identifier from scheduler metadata."; } leaf correlation-id { type string; description "Correlation identifier for cross-system tracing."; } } grouping endpoint-grouping { description "Endpoint identification and location information."; leaf endpoint-id { type string; mandatory true; description "Unique identifier for the endpoint within the group."; } leaf address { type inet:host; description "Network address of the endpoint."; } leaf site-id { type string; description "Site or data center identifier where the endpoint is located."; } leaf cluster-id { type string; description "Cluster identifier within the site."; } leaf interface-id { type string; description "Network interface identifier."; } } grouping endpoint-group-list-grouping { description "Group of endpoints with common role."; list endpoint-group { key "endpoint-group-id"; description "List of endpoint groups."; leaf endpoint-group-id { type string; description "Unique identifier for the endpoint group."; } leaf role { type identityref { base endpoint-role; } description "Functional role of the endpoints in this group."; } list endpoint { key "endpoint-id"; description "List of endpoints in the group."; uses endpoint-grouping; } } } grouping communication-grouping { description "Communication pattern and flow characteristics."; leaf communication-pattern { type identityref { base communication-pattern; } description "Pattern of communication between endpoints."; } leaf flow-direction { type identityref { base flow-direction; } description "Direction of data flow."; } leaf expected-flow-count { type uint32; description "Expected number of flows in this communication pattern."; } } grouping timing-grouping { description "Timing and scheduling requirements."; leaf requested-start-time { type yang:date-and-time; description "Requested start time for the service."; } leaf latest-start-time { type yang:date-and-time; description "Latest acceptable start time for the service."; } leaf requested-end-time { type yang:date-and-time; description "Requested completion time for the service."; } leaf deadline { type yang:date-and-time; description "Absolute deadline for service completion."; } leaf duration { type uint32; description "Requested duration for the service."; } leaf duration-unit { type identityref { base duration-unit; } description "Unit for the requested duration."; } } grouping bandwidth-grouping { description "Bandwidth rate requirements."; leaf minimum-rate { type uint64; description "Minimum acceptable bandwidth rate."; } leaf maximum-rate { type uint64; description "Maximum allowed bandwidth rate."; } leaf target-rate { type uint64; description "Target or desired bandwidth rate."; } leaf rate-unit { type identityref { base rate-unit; } description "Unit for bandwidth rates."; } } grouping latency-grouping { description "Latency performance requirements."; leaf maximum-latency { type uint32; description "Maximum acceptable latency."; } leaf maximum-latency-variation { type uint32; description "Maximum acceptable latency variation (jitter)."; } leaf latency-unit { type identityref { base latency-unit; } description "Unit for latency values."; } } grouping loss-grouping { description "Loss performance requirements."; leaf maximum-loss { type decimal64 { fraction-digits 6; } description "Maximum acceptable loss rate."; } leaf loss-unit { type identityref { base loss-unit; } description "Unit for loss rate."; } } grouping service-objectives-grouping { description "Service performance objectives."; leaf data-volume { type uint64; description "Expected data volume to be transferred."; } leaf data-volume-unit { type identityref { base data-volume-unit; } description "Unit for data volume."; } container bandwidth { description "Bandwidth rate requirements."; uses bandwidth-grouping; } container latency { description "Latency performance requirements."; uses latency-grouping; } container loss { description "Loss performance requirements."; uses loss-grouping; } leaf throughput { type uint64; description "Required throughput performance."; } leaf throughput-unit { type identityref { base throughput-unit; } description "Unit for throughput values."; } } grouping policy-preferences-grouping { description "Policy preferences for the service."; leaf priority { type priority-type; description "Priority level for the service."; } leaf resilience-level { type identityref { base resilience-level; } description "Required resilience level for the service."; } leaf isolation-required { type boolean; description "Whether traffic isolation is required."; } leaf encryption-required { type boolean; description "Whether encryption is required."; } leaf degrade-allowed { type boolean; description "Whether service degradation is allowed if full requirements cannot be met."; } leaf preemptible { type boolean; description "Whether the service can be preempted by higher priority services."; } } grouping admission-state-grouping { description "Admission control state and decision."; leaf status { type identityref { base admission-status; } description "Current admission status of the service intent."; } leaf decision-time { type yang:date-and-time; description "Time when the admission decision was made."; } leaf reason { type string; description "Reason for the admission decision."; } leaf admitted-start-time { type yang:date-and-time; description "Admitted start time for the service."; } leaf admitted-end-time { type yang:date-and-time; description "Admitted end time for the service."; } leaf admitted-rate { type uint64; description "Admitted bandwidth rate for the service."; } leaf-list realization-ref { type string; description "References to network realization instances fulfilling this service intent."; } } /* * Top-level container */ container hpc-service-intent { description "Top-level container for HPC/AI service intent."; list intent { key "intent-id"; description "List of service intent instances."; leaf intent-id { type string; description "Unique identifier for the service intent instance."; } leaf enable { type boolean; description "Administrative state of the service intent."; } container workload-ref { description "Reference to workload metadata."; uses workload-reference-grouping; } container endpoints { description "Endpoint definitions for the service."; uses endpoint-group-list-grouping; } container communication { description "Communication pattern and flow characteristics."; uses communication-grouping; } container timing { description "Timing and scheduling requirements."; uses timing-grouping; } container service-objectives { description "Service performance objectives."; uses service-objectives-grouping; } container policy-preferences { description "Policy preferences for the service."; uses policy-preferences-grouping; } container admission-state { config false; description "Admission control state and decision (read-only)."; uses admission-state-grouping; } } } } ]]>

Security Considerations Service intent information can reveal endpoint locations, timing, capacity requirements, data movement patterns, and workload sensitivity. Implementations need to authenticate and authorize entities that create, read, modify, or cancel service intent instances. Transport protection and access control are required when this model is used across administrative or trust boundaries.

IANA Considerations IANA is requested to register one URI in the "IETF XML Registry" [RFC3688]. Following the format in [RFC3688], the following registration is requested: IANA is requested to register the following YANG module in the "YANG Module Names" registry [RFC6020].

Acknowledgements The authors acknowledge the related HP-WAN framework and problem statement work that provides the broader context for this service intent model.

References Normative References Informative References HPE HPE Meta Crusoe CoreWeave

Example This section provides an example of a service intent instance for a distributed AI training workload. The example demonstrates how workload requirements are expressed using the service intent model. Consider a scenario where an AI training job requires communication between multiple compute nodes across two data centers. The job involves parameter synchronization between worker nodes and requires guaranteed bandwidth with low latency.