CAICT

Beijing China zhaoxing@caict.ac.cn

China Mobile

Beijing China wangminxue@chinamobile.com

Huawei

China lana.wubo@huawei.com

Cisco

dceccare@cisco.com

Huawei

China zhenghaomian@huawei.com

ZTE

China zhou.jin6@zte.com.cn

Operations and Management Network Management Operations Network Management Autonomic Networking AI Intent-based Networking Autonomous Network Network Intelligence AI Agent Large language model LLM The evolution from Level 3 (assisted automation) to Level 4 (closed-loop autonomy) in Autonomous Networks (AN) introduces requirements for agentic capabilities, including intent-based reasoning, autonomous planning, and context-aware decision-making, and execution coordination, which transcend the static, rule-based logic of traditional network controllers. This document defines the concept of the Network Management Agent (NMA), a network management entity with autonomous task processing capabilities designed to bridge the gap between service intent and network operations. This document describes the role of NMA in network management and control architectures, and specifies how the NMA collaborates with existing network controllers to achieve Autonomous L4 without replacing or duplicating their functions. It further defines the reference architecture, deployment modes, and logical interfaces of the NMA, including Agent-to-User (A2U), Agent-to-Agent (A2A), Agent-to-Controller (A2C), and Agent-to-Network (A2N) interactions.

Introduction

Introduction of Network Management Agent (NMA) The Autonomous Networks (AN) framework defines a series of evolution stages from Level 0 (manual) to Level 5 (fully autonomous), as listed in . Current operator networks typically operate at Level 2 or 3, where automation is primarily policy-driven and reactive. Achieving Level 4 (L4) requires evolving from static execution to dynamic assurance and closed-loop management. In this document, the Network Management Agent (NMA) refers to a new network management entity with autonomous task processing capabilities. It is not a conventional device-side management agent or a protocol endpoint. Instead, it is introduced to support intent-based network management tasks, including intent interpretation, network context awareness, analysis, task planning, decision-making, execution coordination, and result reporting. The initial journey towards L4 could target pragmatic, high-value scenarios, such as automated Root Cause Analysis (RCA), SLA assurance, and service restoration. These use cases allow operators to introduce agent-based management capabilities for observability, recommendation, planning, and controlled execution, while maintaining operational control. Traditional network controllers excel at deterministic configuration but lack the analytical depth required for these complex assurance tasks. They execute instructions but cannot autonomously diagnose the “why” behind a failure, predict SLA violations, or generate adaptive task plans from high-level operational goals. Therefore, the NMA is needed to integrate intent-based reasoning and task processing capabilities with existing network control functions, starting with assurance use cases and gradually evolving towards full closed-loop autonomy. The key issues to be clarified include:

1. The application architecture and deployment methods of agent-based network management are still unclear, that is, in what form an NMA can help network management.
2. The relationship between the NMA and existing network controllers is not clear.
3. The interfaces after introducing the NMA are not clear either.

Therefore, it is necessary to define the general architecture of the NMA in network management, and describe related new interfaces to be defined.

Why NMA is Required for Autonomous L4 Achieving L4 autonomy requires a cognitive loop of Intent Interpretation, Perception Analysis, and Dynamic Decision-making–capabilities that extend beyond the native design of traditional network controllers:

• Intent Translation (The “Why”): L4 moves beyond simple API commands to handling fuzzy, high-level operational intents. Unlike network controllers, which require precise, low-level technical parameters (e.g., specific bandwidth values or queue IDs), the NMA acts as an agentic interpreter. It automatically decomposes abstract goals (e.g., “Ensure optimal experience for VPN users”) into concrete, verifiable technical specifications, handling the ambiguity and context that traditional controllers cannot resolve.
• Perception and Contextual Analysis (The “Sense”): L4 requires holistic observability, not just raw data collection. Network controllers excel at gathering telemetry but lack the ability to fuse multi-dimensional data (metrics, logs, traces, alarms) to understand the “state of the network” in a service context. The NMA combines its own knowledge base and memory, using AI models or other reasoning mechanisms to perform Root Cause Analysis (RCA), detect anomalies, and correlate events across the network to build a comprehensive operational picture.
• Autonomous Decision-making and Task Planning (The “Think”): L4 demands the ability to make non-deterministic decisions in response to unforeseen scenarios. Traditional controllers operate on deterministic, reactive logic (e.g., “If X, then Y”), which cannot handle novel failures or complex optimization trade-offs. The NMA embodies the Decision function, utilizing reasoning capabilities to synthesize possible action strategies, evaluate potential outcomes, decide on the optimal course of action when standard procedures do not apply, organize the selected strategy into executable tasks.

Therefore, the NMA serves as the cognitive layer that defines what needs to happen and why, orchestrating network controllers, which act as the execution function that handles how to enforce those decisions on the network infrastructure.

Collaboration with Existing Network Controllers The NMA leverages the mature, stable functions already present in network controllers rather than reinventing them. One important function of the NMA is to translate intent into a series of actionable tasks and issue the final configurations on the network by invoking existing network controllers. To summary, the NMA is compatible with the YANG-based automation framework described in , and utilizes the network controller as its primary execution engine:

• Model-Based Abstraction: The NMA interacts with the controller through standard YANG Service and Network Models, bridging the gap between high-level intent and concrete network resources.
• Telemetry and State Access: The NMA consumes real-time operational data and topology information provided by the controller to maintain an accurate perception of the network state.
• Policy Enforcement: The NMA invokes the controller’s configuration interfaces to apply changes, relying on the controller’s built-in validation and transaction capabilities to ensure stability.

By integrating agent-based task processing capabilities with existing controller functions, the NMA helps evolve network management from policy-driven automation towards intent-based and closed-loop management, without replacing existing network controllers.

Scope This document defines the concept and reference architecture of the Network Management Agent (NMA). It clarifies how an NMA can be positioned in existing management architectures, how it collaborates with existing network controllers, and what logical interfaces are required to support agent-based network management operations. This document does not define specific implementation mechanism of NMA as well as detailed protocol mechanisms, information models, and data models for NMA-related interfaces. This document also does not replace existing YANG-based service and network management frameworks, network controllers, orchestrators, or device management protocols. Instead, it describes how the NMA can reuse and coordinate with these existing components to support higher-level network management capabilities.

Terminology

Acronyms and Abbreviations AI: Artificial Intelligence LLM: Large Language Model NMA: Network Management Agent

Definitions The document defines the following terms:

Network Management Agent (NMA):

A network management entity with autonomous task processing capabilities, which can automatically carry out task intent interpretation, network context awareness, analysis, task planning, decision-making and executions based on user task intentions or preset goals, so as to achieve closed-loop processing of intent-based network management tasks. These capabilities may be implemented using AI models, knowledge-based reasoning, knowledge graph, rule engines, planning algorithms, digital twins, workflow engines, etc., or a combination of such techniques. In this document, the term NMA does not refer to a conventional device-side management agent or protocol endpoint.

Reference architecture of NMA and Deployment Modes

Intelligent Network Management and Control Framework Based on NMA proposed the framework for automating service and network management with YANG. Building on the architecture proposed in , higher-level intelligent network management and control can be achieved by adding NMA components. Based on the Figure 3 of , the layered architecture of intelligent network management and control after the introduction of NMA is shown in . NMA can exist at both the Controller and Orchestrator levels; for the device layer, due to the constraints on the computing power of network elements, some end-side intelligence components may be added on the device side, whether it is unlikely to deploy a complete NMA is not discussed in this document.

Enhanced intelligent network management and control framework based on NMA NMA2 | +---------------------------+ | Intra-layer | | Network Orchestration | | A2A communication | +---------------------------+ | +-------------------------------+ ----------------------------------------------------------------- +-------------------------------+ | Device | | +---------------------------+ | | | End-side Intelligence | | | +---------------------------+ | | +---------------------------+ | | | Device Modeling | | | +---------------------------+ | +-------------------------------+ ]]>

Among them, there may be interaction requirements between NMAs at different layers and between different NMAs at the same layer. Cross-layer NMAs interact through inter-layer Agent-to-Agent (A2A) communication, while different NMAs within the same layer interact through intra-layer A2A communication. This document can be regarded as an enhancement of the intelligent capabilities of , and subsequent discussions will mainly focus on the NMAs at the controller layer.

Deployment modes of NMA It should be noted that although NMA is depicted inside the controller in , in practice, NMA can also be deployed as an independent component outside the controller. This document does not impose mandatory restrictions on the deployment location of NMA. The two deployment modes can be called: Independent deployment mode and Integrated deployment mode and are shown in , where the NMA can be part of an existing network controller, or can be an independent system deployed separately and interacting both with the controller and the network.

Deployment mode of network management agent (NMA) Network management | | | | Modules | Interface | Agent(NMA) | | | +--------------------+ +--------------------+ | | | +------------------------------^-----------------------------+ | Extended SBI(including A2N capability) | +------------------------------v-----------------------------+ | Physical Network | +------------------------------------------------------------+ (a) Integrated Mode ^ ^ | | Northbound Interface(NBI) Agent-to-User/Agent Interface | (A2U/A2A) | | +--------------v------------+ +----------v---------+ | | | | | Network <----A2C----> Network Management | | Controller | Interface | Agent(NMA) | | | | | +--------------^------------+ +----------^---------+ | | Southbound Interface(SBI) Agent-to-Network Interface(A2N) | | +--------------v-----------------------------------v---------+ | Physical Network | +------------------------------------------------------------+ (b) Independent Mode ]]>

Integrated deployment mode: As shown in (a), NMA is integrated and deployed with the original network controller, and the NMA serves as a function of the controller. NMA interacts with original function modules through internal A2C interface. The enhanced controller interacts with the underlay physical network through extended SBI satisfying the A2N interaction requirements. Integrated mode is targeted at network scenarios with single-vendor network controller infrastructure and high requirements for service real-time performance. This mode features deep coupling between the NMA and the network controller, low decision-making and execution latency, and simple deployment and operation & maintenance (O&M), making it suitable for autonomous network management in single-vendor domains. At the same time, since it is extended on the basis of an existing network controller, the changes and impacts on the live network are also smaller, which facilitates the application and evolution of NMA in the live network. Independent deployment mode: As shown in (b), NMA is independently deployed from the original network controller. NMA and controller are independent systems. A new east-west interface needs to be added between the NMA and the controller to achieve capability calling and result feedback operations. This interface can be called “Agent-to-Controller Interface”(A2C). In this deployment mode, controller uses southbound interface (SBI) to interact with physical network, while an Agent-to-Network interface (abbreviated as “A2N”) needs to be added between NMA and the underlying physical network. Independent mode is applicable to multi-domain, multi-vendor heterogeneous network environments. Boasting high flexibility and scalability, this mode enables the NMA to act as a centralized cognitive brain that orchestrates multiple network controllers to achieve closed-loop execution of end-to-end service intents. While the independent deployment mode brings significant flexibility to the management of large-scale and complex networks, its decoupled architecture between the NMA and network controllers introduces a series of potential issues in practical deployment, including management and O & M conflicts between the two entities, which are mainly reflected in the following aspects:

• Configuration and policy conflicts: Concurrent delivery of configurations to network devices by the NMA and the Controller may result in configuration conflicts on the devices. In addition, the NMA generates dynamic control policies based on AI-driven intent reasoning and real-time network context analysis, whereas controllers maintain pre-configured static rule sets and traditional deterministic automation policies. Inconsistencies between these two types of policies may lead to policy execution failures and even service interruptions.
• Inconsistent network state synchronization: The autonomous decision-making of the NMA relies on real-time and accurate network state data (telemetry, alarms, topology) provided by controllers. In the independent mode, network transmission latency and data processing delays between the NMA and controllers may compromise the accuracy of the NMA's decision-making.

This document does not mandate a specific deployment mode for the NMA. When the independent deployment mode is adopted, it is advised to follow the principle of separation of cognitive decision-making and execution enforcement: the NMA is responsible for intent interpretation, context analysis and autonomous decision-making, while network controllers retain the authorities of policy validation, resource enforcement and network state management. This ensures the consistency and effectiveness of the collaborative operation between the NMA and network controllers.

Reference Functional Architecture of NMA In order to achieve above capabilities, by referring to the common AI agent framework, this document presents the reference functional architecture of NMA as shown in .

Reference function architecture of NMA

The NMA is structured into two primary layers: the Autonomous Logic Layer, which embodies the autonomous closed-loop from intention to perception, analysis, decision-making, and execution, and the Supporting Function Layer, which provides foundational capabilities to enable autonomous operations.

Autonomous Logic Layer This layer embodies the intelligent loop of L4 autonomy, translating service goals into network actions. It mainly includes the following logical functional modules which are fully consistent with the IAADE-closed loop of autonomous network defined in TMF (see details in ):

Intent Management:

This module serves as the entry point for Intent. It is responsible for receiving high-level goals from users or orchestration systems, interpreting natural language or policy objectives, and normalizing them into structured, verifiable intents that the agent can pursue. It ensures that the autonomous operations remain aligned with service KPIs. After interpreting the target intent and reasoning through the necessary steps to achieve it, this module can orchestrate the sequence of operations required to progress toward that goal. It breaks down complex objectives into a sequence of executable sub-tasks (e.g., awareness -> analysis -> decision -> execution) and handles dynamic planning under uncertainty, ensuring that the chosen course of action aligns with the desired intent.

Awareness:

This module acts as the intent-driven selective sensing hub of the NMA, responsible for orchestrating the targeted query and perception of task-relevant network data. It proactively initiates data acquisition operations across heterogeneous sources such as controllers, physical/virtual network devices, etc., with a core focus on filtering out irrelevant information to collect only the network data pertinent to the current intent. Covering critical dimensions including device operational status, link performance metrics, service traffic statistics, and configuration parameters, this module lays a precise foundational data base for the subsequent analysis, decision-making, and execution processes.

Analysis:

This module serves as the intelligent analytics core, leveraging the reasoning capabilities of the Reasoning and Model Service in the Supporting Function Layer. It orchestrates advanced analytical tasks tailored to the specific task intent, including anomaly detection, root cause analysis (RCA), event correlation, and impact quantification, etc. By combining real-time perceived data with historical insights retrieved from the Memory&Knowledge Base, it transforms raw data into actionable, context-rich network insights and diagnostic conclusions. It can clearly identify the root causes of network issues, evaluates the impact of abnormal states on service objectives, and outputs structured analytical results that directly guide the strategic decision-making.

Decision:

This module functions as the strategic decision-making core of the NMA, responsible for formulating optimal and feasible operation strategies based on the analytical insights from the Analysis Management module and the constraints of the original user intent. It employs reasoning capabilities and draws on the Memory&Knowledge Base to evaluate multiple potential action paths, selecting the strategy that best aligns with service-level objectives and network operation rules. It decomposes complex strategic decisions into a hierarchical, ordered sequence of executable sub-tasks, defines clear trigger conditions and task dependencies for each step, and maps these sub-tasks to specific tools or functions managed by the Tool&Function Manager. This process ensures that the generated decisions are not only logically sound but also fully operationalized for subsequent execution.

Execution:

This module acts as the intent-closed-loop operational execution core, tasked with translating the structured sub-tasks from the Decision Management module into concrete, reliable network operations. It orchestrates the invocation of appropriate network interfaces, management tools, and operational functions via the Tool&Function Manager, executing tasks such as configuration adjustment, fault remediation, resource scheduling, and service provisioning in a sequential and controlled manner. It real-time monitors the execution status of each sub-task, handles execution exceptions and retries according to pre-defined rules, and conducts rigorous result validation against the original user intent and decision criteria. Finally, it feeds back the execution outcomes, status, and validation results to the Memory&Knowledge Base and upper-layer modules, forming a complete closed-loop of autonomous network management driven by intent.

NMA enables the cognitive capabilities on task lifecycle management procedure described in .

Supporting Function Layer This layer provides the foundational capabilities and resources necessary for the Autonomous logic Layer to function effectively.

Memory & Knowledge Base:

This module serves as the long-term and short-term memory of the NMA, storing historical operational data, network topology snapshots, and a comprehensive repository of expert knowledge including technical documents, troubleshooting guidelines, and past incident resolution cases, etc. It provides unified search capabilities across multi-type knowledge sources such as vector knowledge bases, system online help documentation, and operation and maintenance data logs. Based on accurate domain-specific information, this module improves the accuracy and reliability of NMA’s reasoning and decision-making, enables the agent to reuse historical experience and expert logic, and ensures the consistency and effectiveness of autonomous operations.

Reasoning and Model Service:

This module acts as the cognitive engine of the NMA, providing unified access to diversified reasoning and model capabilities. It supports not only Large Language Models (LLM) and other generative AI models, but also knowledge-based reasoning, rule engines, planning algorithms, optimization algorithms, digital twins, workflow engines, classic AI algorithms and lightweight dedicated models, enabling natural language understanding, logical inference, time-series analysis and other intelligent capabilities. It supplies the comprehensive general and domain-specific intelligence required to drive the core processes of intent management, perception and analysis, reasoning and planning, and decision and execution. It should be noted that the Reasoning and Model Service is not limited to being deployed inside the NMA; it can also be located outside the NMA, and the NMA can invoke reasoning, model, or algorithmic capabilities in real time to complete relevant reasoning operations.

Tool & Function Manager:

This module serves as the Gateway to Reality. It manages the connection between the NMA and external systems, primarily the network controllers via the A2C (Agent-to-Controller) interface. It abstracts network functions (e.g., configuration, telemetry, simulation, etc.) as invocable “Tools.” This module ensures that the decisions made by the upper layer are translated into concrete, standard-compliant network operations (e.g., YANG data manipulation).

Interface Architecture for NMA Integration The NMA-related interfaces are logical interaction relationships. Their realization depends on the deployment mode. In the integrated deployment mode, the NMA is part of the enhanced network controller, and the relevant logical interactions may be exposed through the extended northbound interface or implemented as internal interactions within the controller. In the independent deployment mode, the NMA may expose or use separate external interfaces. The interfaces related to the NMA include the following types:

Agent-to-User interface (A2U):

A2U is used when an NMA exposes its capabilities to upper-layer non-agent users and systems, such as human users, OSS/BSS, orchestrators, management portals, and automation systems. The A2U interface is used to receive requests or intents and return task processing results. It may support natural language interaction for human users and structured intent interaction for systems. In the broader architectural sense, an upper-layer user of an NMA may also include an upper-layer agent or NMA. However, when an upper-layer agent or NMA interacts with a lower-layer agent or NMA, the interaction is treated as Agent-to-Agent communication and should use A2A or other agent-to-agent mechanisms. Therefore, A2U and A2A are distinguished by their interaction semantics.

Agent-to-Agent interface (A2A):

A2A is used for interactions between agents or NMAs, including upper-layer NMA to lower-layer NMA communication and communication among NMAs. Such interaction may involve agent capability discovery, task delegation, collaboration, negotiation, commitment, result aggregation, trust establishment, and context exchange, etc. This document does not define a specific A2A protocol. The detailed definition of A2A may refer to related IETF work or other standards development organizations.

Agent-to-Controller interface (A2C):

A2C is the interface between the NMA and the controller or the original functional components of the controller. In the independent mode, this interface is an east-west interface between the controller and NMA. In the integrated mode, this interface is an internal interface of the controller and is not within the scope of this document.

Agent-to-Network interface (A2N):

A2N is the interface between the NMA and the physical network. In the independent mode, this interface is a southbound interface between the NMA and the network. In the integrated mode, it is included in the original or extended southbound interface of the controller.

For the exposure of NMA capabilities to upper-layer non-agent users and systems, the A2U interface can provide capability discovery, unified intent submission, task lifecycle management, execution plan exposure, human-in-the-loop confirmation, event notification, and consistent error reporting. The detailed A2U framework and information model are specified in . When NMAs are deployed in integration with the controller, as shown in , the related interfaces to be extended include the extended northbound interface and the extended southbound interface of the controller.

Interface view of the enhanced network controller with logical A2U and A2A channels A2U Service | | | | Functions | | A2A Adapter | | | | | | A2C/A2N Adapters | | | +-------------+ +---------------------------------------------------+ | | | +--------------------------------------^------------------------------------+ | | Extended SBI / A2N capability | +--------------------------------------v------------------------------------+ | Physical network | +---------------------------------------------------------------------------+ ]]>

In , interactions with non-agent users and systems are realized through the logical A2U channel, while interactions between upper-layer NMAs and lower-layer NMAs are realized through the logical A2A channel. These logical channels are exposed through the extended northbound interface of the enhanced network controller. On the southbound side, the enhanced controller may also provide extended SBI and A2N-related capabilities for interaction with the physical network. Besides, there are several internal interfaces within the controller, which include the interaction interfaces between NMAs within the controller and the original functional modules of the controller, as well as the interaction interfaces between multiple NMAs within the controller. Since the above are internal implementations of the controller, they are not expected to be standardized in this document. The specific implementation methods, related protocols, and data models of each interface are to be defined subsequently in other documents.

Operational Agent Example

NMA Closed-loop Task Workflow This section provides an example common workflow showing how the Network Management Agent (NMA) collaborates with existing network controller functions to accomplish a closed-loop task driven by user intent. As shown in , the user first submits an NMA intent, which may be expressed in natural language or structured form. The NMA performs intent translation internally and converts the user intent into internal goals, constraints, and verification criteria. This step is performed by the NMA itself and does not require the controller to interpret the intent. In the awareness stage, the NMA queries existing controller functions for required network and service data, such as topology, inventory, telemetry, alarms, performance data, and service state. Based on the collected context, the NMA performs analysis internally, and then conducts decision-making and task generation to produce an execution plan. Before execution, the NMA sends the execution plan to the user for confirmation. The plan may include the intended actions, affected resources, expected results, and potential risks, etc. After the user approves the plan, the NMA invokes existing controller functions to carry out the requested operations. The controller performs validation and enforcement according to its existing capabilities and returns the execution result to the NMA. After execution, the NMA analyzes the execution result, verifies whether the original intent has been satisfied, and updates the task context if needed. Finally, the NMA reports the task execution status and result to the user. The workflow may iterate when the objective is not achieved, additional user confirmation is required, or further corrective actions are needed. This workflow highlights the separation of roles between the NMA and the network controller: the NMA performs intent interpretation, context reasoning, analysis, decision-making, task generation, confirmation handling, and result analysis, while the existing controller functions provide data access, validation, transaction handling, and execution capabilities.

NMA Closed-loop Task Workflow | | | |--+ 1.1 Intent translation | | | | *understand intent, | | | | goals and constraints | | |<-+ | | | | ---+----------------------------+----------------------------------+--- Awareness | | 2. Data request | | | *topology, telemetry, alarms, | | | service state,etc. | | |--------------------------------->| | | 2.1 Data response | | |<---------------------------------| | | | ---+----------------------------+----------------------------------+--- Analysis | |--+ 3. Analysis | | | | *correlate data, RCA, | | | | impact evaluation, etc. | | |<-+ | | | | ---+----------------------------+----------------------------------+--- Decision | |--+ 4. Decision and task | | | | generation | | | | *select strategy and | | | | generate execution plan | | |<-+ | | | | ---+----------------------------+----------------------------------+--- Execution | 5. Execution plan | | | for confirmation | | |<---------------------------| | | 5.1 User confirmation | | |--------------------------->| | | | 5.2 Execution request | | |--------------------------------->| | | 5.3 Execution result | | |<---------------------------------| | | | ---+----------------------------+----------------------------------+--- Feedback | |--+ 6. Result analysis | | | | verify intent and | | | | update context | | |<-+ | | 6.1 Task execution | | | feedback | | |<---------------------------| | | | | | Task completed | | | | +------+ +--------------------------+ +---------------------+ | User | | Network Management Agent | | Existing Controller | | | | (NMA) | | Functions | +------+ +--------------------------+ +---------------------+ ]]>

Examples of Specialized Agents To address specific operational needs, the NMA architecture supports multiple specialized agents. These agents function as modular entities, with the Intelligent Assistant Agent serving as the primary entry point for interaction, followed by specialized agents such as Fault Management Agent and Optimization Agent:

• Intelligent Assistant Agent: Serving as the primary interface for human operators, this agent leverages LLMs to provide natural language Q&A and conversational capabilities. It enables users to perform "one-click" queries for fault descriptions or resource status. By automatically translating human intent into precise data retrieval commands, it significantly enhances the efficiency of knowledge retrieval and daily maintenance support.
• Network Fault Management Agent: Focused on service assurance, this agent leverages comprehensive troubleshooting guides and expert knowledge bases to support intelligent fault handling. It implements automated root cause analysis (RCA) and fault impact analysis. In addition to fault diagnosis, it invokes controller capabilities to execute self-healing operations and integrates with external work order systems to enable closed-loop incident resolution.
• Network Optimization Agent: Focused on performance and efficiency, this agent translates high-level optimization goals into technical constraints, such as load thresholds or routing policies. Leveraging prediction and reasoning capabilities, it anticipates network congestion and generates strategies for traffic engineering and dynamic energy saving. It operates in a closed-loop manner to support autonomous execution decisions and maintain network performance.

Security Considerations Since networks are critical infrastructure, misoperations can have a significant impact on them. Therefore, NMAs shall meet the following security and reliability requirements:

1. Support multi-factor authentication mechanism for sensitive operations. For operations involving network configuration changes or those that pose significant risks to network operation security, a manual confirmation mechanism must be introduced, and multiple authentication methods such as passwords and dynamic tokens shall be used to ensure operation security.
2. Support circuit breaker mechanism. When abnormal results occur during the execution of an NMA task, it shall provide error prompts and transfer the task directly to manual control for handling.
3. Support rollback mechanism. After the execution of an NMA task is completed, it shall support operation rollback to restore the network configuration.
4. Support data security and privacy protection mechanism. It shall support the encryption of sensitive data such as network configurations and user behavior logs; support user permission division, and set differentiated data access permissions for different users.
5. Support operation permission control mechanism. For different application scenarios, the minimum permissions required to perform tasks in the scenario shall be set. For example, a fault handling NMA may query data such as topology resources and performance, but shall not have permission to perform service configuration operations.

IANA Considerations This document has no requests for IANA action.

References Normative References Informative References Data models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle (e.g., service instantiation, service provisioning, service optimization, service monitoring, service diagnosing, and service assurance). Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance. This document describes a framework for service and network management automation that takes advantage of YANG modeling technologies. This framework is drawn from a network operator perspective irrespective of the origin of a data model; thus, it can accommodate YANG modules that are developed outside the IETF. Autonomic systems were first described in 2001. The fundamental goal is self-management, including self-configuration, self-optimization, self-healing, and self-protection. This is achieved by an autonomic function having minimal dependencies on human administrators or centralized management systems. It usually implies distribution across network elements. This document defines common language and outlines design goals (and what are not design goals) for autonomic functions. A high-level reference model illustrates how functional elements in an Autonomic Network interact. This document is a product of the IRTF's Network Management Research Group. This document provides a problem statement and general gap analysis for an IP-based Autonomic Network that is mainly based on distributed network devices. The document provides background by reviewing the current status of autonomic aspects of IP networks and the extent to which current network management depends on centralization and human administrators. Finally, the document outlines the general features that are missing from current network abilities and are needed in the ideal Autonomic Network concept. Intent and Intent-Based Networking are taking the industry by storm. At the same time, terms related to Intent-Based Networking are often used loosely and inconsistently, in many cases overlapping and confused with other concepts such as "policy." This document clarifies the concept of "intent" and provides an overview of the functionality that is associated with it. The goal is to contribute towards a common and shared understanding of terms, concepts, and functionality that can be used as the foundation to guide further definition of associated research and engineering problems and their solutions. This document is a product of the IRTF Network Management Research Group (NMRG). It reflects the consensus of the research group, having received many detailed and positive reviews by research group participants. It is published for informational purposes. University of Luxembourg and Inria Futurewei 3NLab Belgium Reseach Center Central Bank of Canada Digital Railway (DSD) at Deutsche Bahn This document is intended to introduce the challenges to overcome when Network Management (NM) problems may require to couple with Artificial Intelligence (AI) solutions. On the one hand, there are many difficult problems in NM that to this date have no good solutions, or where any solutions come with significant limitations and constraints. Artificial Intelligence may help produce novel solutions to those problems. On the other hand, for several reasons (computational costs of AI solutions, privacy of data), distribution of AI tasks became primordial. It is thus also expected that network are operated efficiently to support those tasks. To identify the right set of challenges, the document defines a method based on the evolution and nature of NM problems. This will be done in parallel with advances and the nature of existing solutions in AI in order to highlight where AI and NM have been already coupled together or could benefit from a higher integration. So, the method aims at evaluating the gap between NM problems and AI solutions. Challenges are derived accordingly, assuming solving these challenges will help to reduce the gap between NM and AI. China Mobile China Mobile Sungkyunkwan University Huawei Xidian University Telefonica This document proposes several use cases of Intent-Based Networking (IBN) and the methodologies to differ each use case by following the lifecycle of a real IBN system. It includes the initial system awareness and data collection for the IBN system and the construction of the IBN system, which consists of intent translation, deployment, verification, evaluation, and optimization. Practice learnings are also summarized to instruct the construction of next generation network management systems with the integration of IBN techniques. OpenAI Building agents with LLM (large language model) as its core controller is a cool concept. Several proof-of-concepts demos, such as AutoGPT, GPT-Engineer and BabyAGI, serve as inspiring examples. The potentiality of LLM extends beyond generating well-written copies, stories, essays and programs; it can be framed as a powerful general problem solver. AIS Null IETF

Definition of L0-L5 Levels in Autonomous Networks summarizes the Autonomous Network (AN) levels defined in TM Forum IG1230 . It illustrates that current IETF automation frameworks, such as , primarily enable Level 3 (Partial Autonomy) by utilizing data models (YANG) to enforce pre-defined policies. Autonomous Network Levels (L0-L5)

LEVEL	NAME	DESCRIPTION (CORE CHARACTERISTICS)	HUMAN VS. MACHINE ROLE
L0	Manual	Fully manual processes. No automation.	Human does everytding.
L1	Assisted	System provides tools (dashboards, alarms).	Human makes all decisions; tools assist.
L2	System-assisted	Automation of single tasks/scripts.	Human initiates tasks; system executes.
L3	Partial Autonomy	Partial automation based on pre-defined policies/models.	"Human-in-the-Loop": Humans define rules/models and monitor; system executes and reports exceptions.
L4	High Autonomy	Closed-loop context analysis, decision-making and execution based on Intents.	"Human-in-the-Loop": Humans define high-level intents; system self-configures and heals. Human only intervenes on system failure.
L5	Full Autonomy	Self-evolving, self-optimizing, fully driverless operations.	"Human-out-of-the-Loop": System requires no human intervention for business goals.

depicts the ‘Intent-Awareness-Analysis-Decision-Execution (IAADE)’ control loop AN architecture, highlighting the evolution from the rule-based automation of Level 3 to the intent-driven, AI-powered autonomy of Level 4, which is the focus of this document. Network Management Agent can serve as an augmentation layer, enhancing network management automation and orchestration capabilities through natural language intent translation, cross-vendor semantic bridging, and knowledge codification. In this context, Agents focus on decision support and workflow orchestration, while critical configuration changes continue to follow manual approval and transactional execution mechanisms via existing deterministic protocols (e.g., NETCONF), striking a balance between automation efficiency and operational certainty.

IAADE Control Loop for Autonomous Networks | | -> | | -> | | | (Awareness) | | (Analysis) | | (Decision) | | (Execution) | +------+------+ +------+-----+ +------+-----+ +------+------+ | | | | +------------------+-----------------+-----------------+ | v +--------------+ | NETWORK | +--------------+ ]]>