]> ZTE Corporation

yan.jinjie@zte.com.cn

ZTE Corporation

miao.chuanyang@zte.com.cn

ZTE Corporation

chen.ran@zte.com.cn

AREA nmrg Autonomous network management using agents is maturing in single-domain deployments. However, end-to-end services spanning multiple domains expose a lack of systematic support for cross-domain coordination, roles, and interfaces in current architectures. This document defines a cross-domain network agent architecture that enables coordinated operation across autonomous domains through standardized agent roles, layered coordination mechanisms, and unified interface specifications.

Introduction Modern network infrastructures are inherently multi-domain. A single end-to-end service — such as an enterprise VPN, cloud interconnect, or critical IoT telemetry path — typically traverses access networks, aggregation layers, backbone networks, and potentially multiple operator administrative boundaries. Each domain may employ different technologies (IP, optical, wireless), different management systems, and different operational policies. Current agent-based approaches to network autonomy focus predominantly on the scope of a single domain. They define intelligent entities that perform perception, analysis, decision-making, and execution all within the boundary of one administrative domain. While effective for localized autonomy, these approaches leave a critical gap: there is no standardized architectural framework for coordinating autonomous actions across domain boundaries to fulfill end-to-end operational intents. This gap manifests in three key challenges:

• Intent fragmentation: End-to-end intents must be manually decomposed into domain-specific objectives, with no standardized mechanism for automated decomposition or cross-domain result aggregation.
• Coordination silos: When a service spans multiple domains, each domain’s autonomous system operates independently. Cross-domain fault correlation, resource optimization, and policy enforcement rely on ad-hoc integrations rather than standardized agent-to-agent coordination.
• Unclear risk boundaries: Cross-domain operations lack unified lifecycle management and exception handling mechanisms, leading to ambiguous responsibility boundaries and elevated risk of cascading failures.

This document defines a reference architecture for cross-domain coordination of autonomous network agents. Specifically, it specifies:

• Four core agent roles and their responsibilities within a layered architecture
• Two optional deployment patterns for the cross-domain orchestration layer
• Interface classification and interaction specifications across layers and domains
• Core cross-domain coordination mechanisms

Conventions and Definitions

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.

Cross-Domain Network Agent Architecture The cross-domain network agent architecture is organized into three layers, which serve as the common foundation for both deployment patterns. Each layer has clear responsibility boundaries, and interactions across layers follow unified specifications. Layers may evolve independently.

• Cross-Domain Orchestration Layer: The topmost layer, serving as the unified entry point for end-to-end operational intents. It is responsible for global task scheduling, state management, and result aggregation across domains.
• Autonomous Domain Layer: The middle execution layer, composed of multiple autonomous domains. Each domain independently completes its internal operation closed loop and exposes standardized interfaces externally.
• Network Element Layer: The bottom resource layer, containing physical and virtual network elements. It is the final execution target and data source for operation actions.

Core Agent Roles Four core agent roles are defined across the architecture. Their responsibilities are consistent across both deployment patterns; only their topological position and interaction paths differ.

• Service Agent: An agent purpose-built for multi-scenario and multi-domain autonomy of a specific telecom service. It supports cross-domain scenarios and assumes full-lifecycle closed-loop self-operation of the corresponding service.
• Orchestrator Agent: An agent within the cross-domain orchestration layer, positioned as a centralized scheduling enhancement entity entrusted by the Service Agent. It performs transactional multi-domain scheduling and state synchronization.
• Supervisor Agent: An agent within an autonomous domain, designated as the logical external representative of the domain. It is responsible for intra-domain task orchestration and cross-domain interaction, and presents a unified domain boundary externally.
• Expert Agent: An agent within an autonomous domain, specialized in a specific network management function (e.g., fault management, configuration, optimization, security).

Direct Interaction Pattern

Direct Interaction Pattern Cross-Domain Agent Architecture │ supervisor agent │ │ │ │ │ └────────────────────┘ │ │ └────────────────────┘ │ │ │ │ ^ ^ │ │ ^ ^ │ │ │ │ │ │ │ │ │ │ │ │ │ │ v v │ │ v v │ │ ▼ │ │ ┌──────┐ ┌──────┐ │ │ ┌──────┐ ┌──────┐ │ │ │ │ │Expert│ ... │Expert│ │ │ │Expert│ ... │Expert│ │ │ │ │ │Agent │ │Agent │ │ │ │Agent │ │Agent │ │ │ │ │ └──────┘ └──────┘ │ │ └──────┘ └──────┘ │ │ │ └─────────────────────────┘ └─────────────────────────┘ │ │ ^ ^ │ └─────────────┼─────────────────────────────────────────┼─────────────┘ v v ┌─────────────────────────┐ ┌─────────────────────────┐ │Domain A │ │Domain B │ │ │ │ │ │ Network Elements │ │ Network Elements │ └─────────────────────────┘ └─────────────────────────┘ ]]>

In the Direct Interaction pattern, no independent Orchestrator Agent is deployed in the cross-domain orchestration layer. Service Agents establish point-to-point A2A connections directly with Supervisor Agents in each autonomous domain. Intent decomposition, task distribution, and result aggregation are all performed by the Service Agent itself. Between domains, temporary peer-to-peer direct channels may be established between Supervisor Agents of two parties after coordination and authorization by the Service Agent, for high-frequency interaction scenarios.

End-to-End Interaction Flow

1. The intent submitter sends an end-to-end operational intent to the Service Agent via the northbound interface.
2. The Service Agent normalizes and decomposes the intent, generating sub-tasks for each corresponding domain.
3. The Service Agent delivers sub-tasks directly to the Supervisor Agents of target autonomous domains via A2A interfaces.
4. Each Supervisor Agent adapts the task and dispatches it to local Expert Agents for execution.
5. Expert Agents interact with network elements in the Network Element Layer to complete configuration and data collection.
6. Execution results are returned layer by layer, and finally aggregated by the Service Agent and fed back to the intent submitter.

Pattern Characteristics

• Fewer forwarding hops, lower interaction latency, and lightweight deployment.
• No central single point of failure; failure of a single service does not affect other cross-domain capabilities.
• Suitable for scenarios with a small number of autonomous domains, low latency requirements, and pilot deployment within the same administrative entity.

Hub-and-Spoke Pattern

Hub-and-Spoke Pattern Cross-Domain Agent Architecture │ supervisor agent │ │ │ │ │ └────────────────────┘ │ │ └────────────────────┘ │ │ │ │ ^ ^ │ │ ^ ^ │ │ │ │ │ │ │ │ │ │ │ │ │ │ v v │ │ v v │ │ │ │ ┌──────┐ ┌──────┐ │ │ ┌──────┐ ┌──────┐ │ │ │ │ │Expert│ ... │Expert│ │ │ │Expert│ ... │Expert│ │ │ │ │ │Agent │ │Agent │ │ │ │Agent │ │Agent │ │ │ │ │ └──────┘ └──────┘ │ │ └──────┘ └──────┘ │ │ │ └─────────────────────────┘ └─────────────────────────┘ │ │ ^ ^ │ └─────────────┼─────────────────────────────────────────┼─────────────┘ v v ┌─────────────────────────┐ ┌─────────────────────────┐ │Domain A │ │Domain B │ │ │ │ │ │ Network Elements │ │ Network Elements │ └─────────────────────────┘ └─────────────────────────┘ ]]>

In the Hub-and-Spoke pattern, the Orchestrator Agent serves as a centralized scheduling enhancement component within the cross-domain orchestration layer, entrusted by the Service Agent. It acts as the central hub to uniformly connect with Supervisor Agents of all autonomous domains, and undertakes transactional work including multi-domain task distribution, state synchronization, and process scheduling. Each autonomous domain retains independent closed-loop management capabilities. The Supervisor Agent acts as the unified logical interaction boundary of the domain externally, and accepts unified scheduling from the Orchestrator Agent on behalf of the domain. Peer-to-peer direct channels between domains may only be established after authorization by the Orchestrator Agent, and the channel lifecycle is managed by the Orchestrator Agent.

End-to-End Interaction Flow

1. The intent submitter sends an end-to-end operational intent to the Service Agent.
2. The Service Agent forwards the normalized intent to the Orchestrator Agent.
3. Based on advertised domain information, the Orchestrator Agent decomposes the intent, generates a set of sub-tasks with dependency relationships, and dispatches them to the corresponding autonomous domains in a unified manner.
4. Each domain Supervisor Agent receives the sub-task, dispatches local Expert Agents for execution, and reports status to the Orchestrator Agent.
5. Expert Agents interact with network elements in the Network Element Layer to complete operational actions.
6. The Orchestrator Agent aggregates execution results from all domains, performs global validation, and feeds back to the Service Agent.
7. The Service Agent returns the final result to the intent submitter.

Pattern Characteristics

• Centralized governance; security policies, audit logs, and access control can be implemented uniformly.
• Low domain-side access cost; new autonomous domains only need to connect to the Orchestrator Agent.
• Suitable for production-grade scenarios with a large number of autonomous domains, high security and compliance requirements, and mixed deployment of multiple scenarios.

Interface Specifications Cross-layer and cross-domain interaction interfaces are targeted for standardization to ensure interoperability. Intra-domain and intra-layer interfaces may be implemented independently by each domain or vendor. Interface Classification

• Intra-Orchestration Interface: Operates between Service Agent and Orchestrator Agent within the same layer. Its core purpose is intent handover and result feedback.
• Cross-Domain Scheduling Interface: Operates from Service / Orchestrator Agent to Supervisor Agent across layers. Its core purpose is sub-task delivery and status synchronization.
• Inter-Domain Peer Interface: Operates between Supervisor Agent and Supervisor Agent across domains. Its core purpose is coordination negotiation, state synchronization, and data exchange.
• Intra-Domain Scheduling Interface: Operates from Supervisor Agent to Expert Agent within a domain. Its core purpose is task assignment and result collection.
• Southbound Control Interface: Operates from Expert Agent to Network Element across layers. Its core purpose is configuration delivery and telemetry collection.

Cross-domain interfaces are targeted for standardization, and the protocol framework is RECOMMENDED as the carrier. It is a loosely coupled inter-agent interaction framework supporting request-response and event push modes. Intra-layer and intra-domain interfaces have no mandatory requirements; reusing the stack is recommended. For southbound connectivity to network elements, standard network management protocols apply to conventional devices, while agent-native interaction protocols MAY be employed for intelligent network elements.

Cross-Domain Coordination This chapter defines the architectural principles and boundary constraints for collaboration across autonomous domains, to support end-to-end delivery and closed-loop operation of telecom services spanning multiple administrative domains.

• Cross-domain collaboration abides by the following core architectural principles:
• Domain autonomy: Collaboration respects the administrative boundary of each autonomous domain. Each domain retains ultimate control over its internal resources and operations, with all inter-domain interactions conducted via standardized boundary interfaces.
• Unified orchestration: Service intents are uniformly decomposed, scheduled and executed across domain boundaries for end-to-end service delivery.
• State consistency: Global service state consistency is maintained throughout the full collaboration lifecycle.
• Controllability: All cross-domain interactions are subject to authorization and lifecycle governance with clear scope boundaries.
• Loose coupling: Collaboration relies only on standardized boundary contracts and capability semantics, independent of each domain’s internal implementation.
• Fault isolation: Failures in a single domain are confined within its boundary, preventing cascading impacts on the overall cross-domain process.

The primary orchestration path serves as the primary reference for end-to-end task execution and persistent service state changes. Auxiliary peer-to-peer interactions may be established between domains to optimize operational efficiency. These auxiliary interactions are not designed to introduce persistent modifications to the global final service state; state-modifying operations are expected to be performed through the primary orchestration path. Cross-domain collaboration is architected to preserve eventual consistency of the global service state. When exception-triggered rollback is required, the dependency-first principle acts as a guiding constraint: dependency references are expected to be resolved before corresponding resources are released, to help prevent invalid resource references and state divergence.

Security Considerations As an architecture involving multiple administrative entities and cross-network boundaries, the following security requirements MUST be implemented in design and deployment:

1. All cross-domain interaction interfaces MUST use TLS 1.3 or later for encrypted transmission.
2. Cross-domain agent identities MUST be verified via X.509 certificates. Fine-grained token-based access control is RECOMMENDED.
3. Domain boundaries MUST enforce the principle of least privilege, only exposing capabilities and data necessary for the task.
4. All cross-domain operations MUST retain complete audit logs, including request source, operation target, execution content, result, and timestamp. Logs MUST be tamper-proof.
5. High-risk cross-domain operations (e.g., network configuration changes, service cutovers) SHOULD support appropriate human review mechanisms before execution.
6. Anomaly interception mechanisms SHOULD be deployed at domain boundaries to prevent malicious requests from impacting internal domain systems.

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References

Acknowledgments TODO acknowledge.