Integration of Network Management Agent (NMA) into ACTN-Based Optical Network

Integration of Network Management Agent (NMA) into ACTN-Based Optical Network CAICT

Beijing China zhaoxing@caict.ac.cn

Huawei

Canada henry.yu1@huawei.com

China Unicom

China lia12@chinaunicom.cn

CAICT

China xuyunbin@caict.ac.cn

Routing Common Control and Measurement Plane Optical Network Network Management Abstraction and Control of TE Networks ACTN Autonomous Network Network Intelligence AI Agent Large Language Model LLM With the growth of optical network scale, the complexity of network operation and maintenance has increased dramatically. Enhancing the intelligence level of optical network operation and management and building high-level autonomous optical networks have become the common vision of global operators. The development of AI, especially large AI model technologies, provides a feasible technical path for realizing autonomous perception, decision-making, analysis, and execution. The existing ACTN architecture provides network abstraction and control functions for optical networks but lacks higher-level autonomous capabilities. This document explores the introduction of AI based Network Management Agent(NMA) functions into ACTN-based optical networks to achieve high-level autonomy of optical networks. It discusses the ACTN-enhanced architecture of optical networks after the introduction of NMAs, including key components, interaction relationships, new interface requirements in the enhanced architecture, as well as typical use cases of agent-based autonomous operation and maintenance for optical networks. The document aims to improve the autonomy level of optical networks and promote the realization of autonomous optical networks by extending the original ACTN architecture. Discussion Venues Discussion of this document takes place on the Network Management Operations Working Group mailing list (nmop@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction With the emergence and popularization of the SDN concept, proposed the ACTN architecture, which provides network abstraction, service and connection control functions for optical networks and has been deployed in multiple operators' networks. Currently, as the scale of optical networks continues to grow, the complexity of network Operations and Maintenance (O&M) has increased dramatically. Existing optical network O&M management systems are complex; scenarios such as optical network service provisioning and fault handling require extensive manual involvement, leading to complicated collaboration processes among O&M personnel and long processing durations. Therefore, further enhancing the intelligence level of optical network operation and management, building high-level autonomous optical networks, and achieving the service experience of "Zero-X" (zero waiting, zero failure, zero touch) and "Self-X" (self-configuration, self-healing, self-optimization) have become the common vision of global operators. The development of AI, especially large AI model technologies, provides a feasible technical path for realizing autonomous perception, decision-making, analysis, and execution. As one of the important forms of AI application implementation, the concept of AI Agent has gained extensive attention and recognition in the industry. An AI Agent is defined as an intelligent entity capable of perceiving the environment, making autonomous decisions, and executing actions, which can gradually achieve set goals through independent thinking and tool invocation. The four core elements of an AI Agent include planning, tools, execution, and memory. Most current AI Agents are based on Large Language Models (LLMs), i.e., LLM-based Agents. The relationship between an AI Agent and a large model can be summarized as: Agent = large model + memory + planning + tool use. Currently, the IETF document has proposed an AI Agent for network O&M management, which can automatically perform network state perception, task intent parsing, task planning, decision-making, and task execution. Based on user task intent or preset goals, it enables closed-loop processing of scenario-oriented network O&M management tasks. This document, building on the Network Management Agent (NMA) concept proposed in , explores the introduction of NMA into the ACTN-based optical network architecture. By enhancing the capabilities of the agent, it aims to improve the intelligent O&M management capabilities of optical networks and drive the realization of high-level autonomy in optical networks. This document will first discuss the enhanced ACTN architecture of optical networks after the introduction of NMA, analyze in detail the key components, interaction relationships, and new interface requirements in the new architecture, and provide examples of typical agent-based autonomous O&M use cases for optical networks.

Terminology

Acronyms and Abbreviations AI: Artificial Intelligence LLM: Large Language Model NMA: Network Management Agent Agent: Specifically refers to NMA A2A: Agent-to-Agent. In this document, A2A refers to a general agent-to-agent communication interface or interaction model between NMAs. It is not limited to any specific protocol realization. A2U: Agent-to-User. An interface used when a non-agent upper-layer system or user invokes NMA capabilities as defined in MCP: Model Context Protocol. In this document, MCP is discussed as a possible capability or tool invocation mechanism and is not mandated as the protocol for enhanced CMI or enhanced MPI.

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.

NMA-based enhanced ACTN architecture

Enhanced ACTN architecture The enhanced ACTN architecture for optical networks after the introduction of NMA is illustrated in below. The AI agents (i.e., NMAs) are introduced within the ACTN architectural framework as auxiliary components intended to augment and assist existing ACTN functional entities, rather than to replace them. In alignment with this design principle, the NMAs are conceptually implemented as design components within the MDSC, PNC, or CNC, rather than as independent entities external to these controllers. The introduction of NMAs does not change the original ACTN hierarchical architecture, nor does it replace the existing ACTN interfaces and functional modules. Instead, NMAs reuse and orchestrate existing controller capabilities to improve the intelligence of service provisioning, service assurance, fault management, and other O&M tasks. The agents may interact with existing ACTN functional modules through internal APIs, private interfaces, the Model Context Protocol (MCP), or other capability/tool invocation mechanisms. This integrated design approach ensures backward compatibility with the established ACTN framework and enables smooth evolution of existing ACTN deployments toward higher levels of automation and intelligence.

NMA-based enhanced ACTN architecture | NMA2 |<---+ | | | | | | | Existing | | +------+ | | |Enhanced | |Enhanced | | | Function | |(5) (5)| | | PNC2 | | PNC3 | | | Modules | (4) +--v---+ (5) +---v--+ | | | | | | | |<--->| NMA1 |<------>| NMA3 | | | | | | | +----------+ +------+ +------+ | | | | | +----------------------^--------------------+ +----^----+ +----^----+ | | | |(3)Extended SBI | | | | | +----------------------v--------------------+ +----v----+ +----v----+ | Network domain 1 | | Domain2 | | Domain3 | +-------------------------------------------+ +---------+ +---------+ ]]> The enhanced ACTN architecture includes the following key entities:

NMA-enhanced CNC (Customer Network Controller):: As defined in , the CNC is responsible for transmitting the customer’s Virtual Network Service (VNS) requirements to the network operator via the CNC-MDSC Interface (CMI). By integrating NMA entities related to service scenarios at the CNC layer, it can address operation and management needs specific to the service domain, enhance the intelligence level of end-to-end service operation and management, and enable intelligent service-domain capabilities such as automated service provisioning and automated work order flow.
NMA-enhanced MDSC (Multi-Domain Service Coordinator):: As defined in , the MDSC undertakes core functions including multi-domain service coordination and network virtualization/abstraction. By introducing NMA entities for cross-domain scenarios at the MDSC layer, it can meet cross-domain O&M management requirements, strengthen closed-loop task processing capabilities in typical scenarios, and improve the efficiency of optical network management and control.
NMA-enhanced PNC (Provisioning Network Controller):: As defined in , the Provisioning Network Controller (PNC) oversees configuring the network elements, monitoring the topology (physical or virtual) of the network, and collecting information about the topology (either raw or abstracted). By integrating NMA entities for single-domain scenarios (e.g., Fault Management NMA, Service Assurance NMA) at the PNC layer, it can address single-domain O&M management needs and enhance the ability to handle various network O&M tasks within the domain.

The number of NMAs within a controller is deployment-specific. However, when multiple NMA instances are deployed on a single controller, an agent proxy may be deployed to manage agent-related interactions with external controllers or external agents, as shown in . The agent proxy may aggregate the capabilities of multiple NMAs, allow NMAs within the controller to register their capabilities, and expose these capabilities on their behalf to external entities. It may also act as a gateway for NMAs within the controller to communicate with external agents through a general agent-to-agent communication interface. In this document, A2A denotes such a general agent-to-agent communication interface or interaction model and is not limited to any specific protocol realization. This mechanism standardizes the access mode of lower-layer NMAs to the upper layer, avoids multi-NMA access conflicts, and improves the manageability and scalability of inter-layer NMA communication. For simplicity, the agent proxy is not depicted in all diagrams in this document. However, the architectural diagrams defined herein assume the presence of an agent proxy in controllers containing multiple NMA instances.

Diagram of Agent Proxy in each layer depicts an example in which NMA functions are introduced into the MDSC and the PNC. The purpose of this figure is to show how NMAs can be integrated with existing ACTN controller functions and how different inter-layer interaction models may coexist during incremental deployment. Two types of interactions between the MDSC and the PNC are shown in . The left side of the figure represents a logical A2A interaction. This applies when both the upper-layer controller and the lower-layer controller contain NMAs. In this case, the upper-layer NMA and the lower-layer NMA may exchange agent-level information, such as high-level intent, context, constraints, candidate actions, risk information, and execution feedback. In this document, A2A is used as a generic term for agent-to-agent communication interfaces and is not limited to any specific A2A protocol. The detailed protocol design and standardization of the A2A interaction are outside the scope of this document at this stage. The right side of the figure represents an extended MPI interaction. The extended MPI preserves the original ACTN MPI capabilities and supports the existing ACTN MPI interactions. In addition, it may be enhanced to support capability exposure and invocation related to NMAs. For example, when the upper-layer controller does not contain an NMA but the lower-layer controller contains NMAs, the extended MPI can be used to expose and invoke the capabilities of the lower-layer NMAs. This can be considered as an enhancement of the original MPI. When the upper-layer controller contains an NMA but the lower-layer controller does not contain NMAs, the upper-layer NMA may still invoke the existing ACTN MPI capabilities exposed by the lower-layer controller without requiring additional NMA-related extensions on the lower layer. Therefore, the extended MPI provides a smooth evolution path for deployments where NMAs are introduced incrementally and where a complete cross-layer agent environment is not available. The extended CMI between the CNC and the MDSC may follow a similar interaction model, although this document mainly focuses on the enhanced MPI between the MDSC and the PNC. Within the PNC, the interaction between NMAs and existing controller functions is considered an internal implementation matter of the PNC. Existing controller functions may include topology management, tunnel management, PCE, configuration functions, telemetry collection, assurance functions, and other implementation-specific modules. These functions may expose their capabilities to NMAs through internal APIs, private interfaces, MCP-based mechanisms, or other tool invocation mechanisms. This document does not impose any standard requirement on such internal interactions. The purpose of is to show that NMAs can reuse and orchestrate the existing controller capabilities rather than replacing them.

Enhanced ACTN interfaces As shown in and , the NMA-enhanced ACTN architecture includes both original ACTN interfaces and additional interaction mechanisms introduced for agent-based enhancement. The introduction of NMAs is intended to preserve the original ACTN architecture and interface model while enabling additional intelligent capabilities. Therefore, the existing CMI, MPI, and SBI roles are not changed. The enhanced interfaces are designed to be backward compatible and to support incremental deployment of NMAs. The following types of interactions are considered in this document:

Extended CMI: The interface between the CNC and the MDSC. The extended CMI preserves the original ACTN CMI capabilities and may be enhanced to support NMA-related capability exposure and invocation. Similar to the extended MPI, it can support incremental deployment scenarios where an NMA exists only on one side of the CNC-MDSC relationship. The extended CMI may evolve from a purely transactional request-response interface to an interface that also supports intent expression, context exchange, clarification, recommendation, negotiation, and execution feedback.
Extended MPI: The interface between the MDSC and the PNC. The extended MPI preserves the original ACTN MPI capabilities, including RESTCONF/YANG-based interactions, and provides a smooth enhancement path for NMA-enabled deployments. When both the MDSC and the PNC contain NMAs, the inter-layer agent-level interaction may be realized by a general agent-to-agent communication interface, MCP-based capability invocation, or a combination of both. When only the lower-layer PNC contains NMAs, the extended MPI may be used by the MDSC to discover, expose, and invoke lower-layer NMA capabilities. When only the upper-layer MDSC contains NMAs, the MDSC NMA may invoke the original MPI capabilities exposed by the PNC without requiring NMA-related extensions on the PNC side.
Logical A2A interaction: This refers to agent-level interaction between an upper-layer NMA and a lower-layer NMA, for example between an NMA in the MDSC and an NMA in the PNC. A2A interaction is suitable for conversational and goal-oriented exchanges, including high-level intent delivery, constraint exchange, candidate solution recommendation, risk feedback, strategy negotiation, and execution status reporting. In this document, A2A is used as a generic term for agent-to-agent communication interfaces and is not limited to any specific protocol realization. The detailed protocol design of A2A interaction is outside the scope of this document.
Internal interactions between NMAs and existing controller functions: These interactions occur inside a controller, such as inside a PNC. They allow NMAs to invoke existing controller functions, including topology management, tunnel management, PCE, RESTCONF/YANG functions, telemetry functions, and other implementation-specific modules. Such interactions are internal implementation choices and may use private APIs, MCP-based mechanisms, or other tool/capability invocation mechanisms. They are not subject to standardization requirements in this document.
SBI: The interface between the PNC and physical network devices. This interface is not changed by the introduction of NMAs and is outside the scope of this document.

Compared with the original ACTN MPI, the enhanced MPI is intended to support a broader interaction model. The original ACTN MPI is mainly a transactional interface, where the MDSC sends requests to the PNC and the PNC responds according to predefined YANG models and protocol operations. The enhanced MPI keeps this capability, but may additionally support more conversational and intent-oriented interactions. For example, the MDSC may express a high-level objective or intent, and the PNC may respond with constraints, alternative candidate paths, feasibility information, risk feedback, requests for clarification, or recommended actions. In this sense, the enhanced MPI evolves from a pure transaction-oriented interface to an interface that can also support multi-domain coordination and agent-assisted negotiation. The enhanced MPI/CMI does not mandate a single protocol mechanism for all deployment scenarios. Instead, it identifies the architectural interface position where additional NMA-related capabilities may be exposed and invoked while preserving the original ACTN interface semantics. Depending on the deployment scenario, the enhanced MPI/CMI may be realized using different interaction models.

Case 1) When both the upper-layer and lower-layer controllers contain NMAs: the inter-layer agent-level interaction may be realized by a general agent-to-agent communication interface, MCP-based capability invocation, or a combination of both. A general agent-to-agent communication interface is suitable for conversational and goal-oriented exchanges, while MCP-based capability invocation is suitable for exposing and invoking specific tools, APIs, controller functions, or NMA capabilities.
Case 2) When only the lower-layer controller contains NMAs: an A2U-based interaction may be used by a non-agent upper-layer controller function to discover the lower-layer NMA capabilities, submit intents, monitor tasks, resolve confirmations, and receive notifications. For example, the A2U interface defined in provides capability discovery, intent submission, task lifecycle management, confirmation, notification, and error reporting functions for a non-agent upper-layer system or user to invoke NMA capabilities.
Case 3) When only the upper-layer controller contains NMAs: the upper-layer NMA may invoke the original ACTN MPI/CMI capabilities exposed by the lower-layer controller without requiring NMA-related extensions on the lower layer.

These mechanisms describe different aspects of NMA-enhanced ACTN deployments and are not mutually exclusive. A logical agent-to-agent interaction describes the agent-level relationship between NMAs, while MCP-based capability invocation is one possible mechanism for exposing and invoking tools, APIs, controller functions, or NMA capabilities. A2U applies to the specific case where a non-agent upper-layer system or controller function invokes NMA capabilities exposed by a lower-layer controller. This document does not mandate any single mechanism as the only realization of the enhanced MPI/CMI. An example deployment using MCP-based capability invocation is provided in . This example is non-normative and is intended only to illustrate how controller capabilities may be exposed and invoked after NMAs are introduced.

Use cases The ACTN architecture enhanced by NMA can effectively improve the automation and intelligence levels in typical O&M management scenarios of optical networks by building agents for different scenarios. Compared with the traditional ACTN architecture without NMA, the NMA-enhanced architecture realizes the transformation of O&M mode from manual-driven, passive response to intelligent-driven, active perception and closed-loop processing in each typical scenario. The core advantages are reflected in the automatic parsing of user intent, autonomous task planning and execution, active risk prediction and handling, and the significant reduction of manual participation in the O&M process. Examples of typical application scenarios include service provisioning, service assurance, and fault handling, and the capability enhancement and processing flow optimization of each scenario after adding NMA are described in detail below.

Service Provisioning The service provisioning agent may be deployed on the MDSC and the PNC. One important use-case of this agent is to enhance the existing optical service provisioning capabilities of ACTN by advancing toward fully automated, intent-based networking. The existing MPI, realized via the RESTCONF protocol, provides a transactional interface characterized by request–response interactions between the caller (MDSC) and the callee (PNC). Furthermore, the service creation APIs are defined using pre-modeled YANG modules. While suitable for parameterized service provisioning, this approach is not sufficient to support an intent-based system, as it constrains the expressiveness and abstraction level of service intent. In contrast to a purely transactional interface, agent-assisted inter-layer interaction supports a bidirectional and conversational model. In this model, the MDSC may convey high-level, outcome-oriented service intent to the PNC, and the PNC may respond with status, constraints, alternative proposals, feasibility information, or requests for clarification. This interaction may be realized through a general agent-to-agent communication interface when both layers contain NMAs, through MCP-based capability invocation, through the enhanced MPI when NMA capabilities are exposed through the MDSC-PNC interface, or through a combination of these mechanisms. The following illustrates an example of OTN private leased line service creation through an agent-assisted inter-layer interaction. In this example, the MDSC expresses a high-level OTN service creation intent (step 4), and the PNC responds with several possible routing options for the MDSC to select (step 7). After a successful creation of the OTN tunnel, the MDSC creates a customized abstract TE topology (Step 12) and provides it to the PNC (Step 13) for subsequent orchestration purposes. Such functionality, which is essential for multi-domain service orchestration, is not supported by the current MPI specification.

Sequence diagram of Service Provisioning Agent Use-case |2.call getTeTopo() | | | | 3.native TE topology |------------>| | | | |<------------------------| | | | | |4.OTN leased line service| | | | | |service intent,specifying| | | | | | SLA, src&dst on TE Topo | | | | | |------------------------>| | | | | | +--+ 5.intent | | | | | | | translation | | | | |<-+ | | | | | | 6.call pceAPI() for| | | | | path re-computation | | | 7.provide N possible |------------------->| | | | routes satisfying SLA | | | | | |<------------------------| | | | | | 8.select route | 9.call createOTNtunnel()API| | |------------------------>| for tunnel creation | | | |--------------------------->| 10.OTN | | | | | | tunnel | | 11.return creation result and created OTN |creation| | tunnel instance | | |------->| |<------------------------|<---------------------------| | +--+ | | | | | | |12.create abstract TE | | | | | | |topo using OTN tunnel | | | | | | | as logical TE link | | | | | <--+ | | | | | | | | | | | |13.send abstract TE Topo |14.call saveTopo() | | | |------------------------>|to save abstract | | | | | TE Topo | | | | | |------------>| | | | | **Task finished** | | | | +---+---+ +------+-------+-----+----+-+-+-----+----+ +-+--+ | Agent | | Agent | Topo Mgr|PCE|Tunnel Mgr| | NE | +-------+ +--------------+----------+---+-----+----+ +----+ ]]>

Service Assurance Service Assurance ensures that deployed services meet agreed availability and performance objectives. In traditional network operations, assurance mechanisms are largely reactive, responding to fault alarms rather than proactively preventing service degradation. A service assurance agent integrated into the ACTN framework enables a transition toward a closed-loop automation model. In this model, the agent continuously monitors the network's observed state and ensures alignment with the user-defined intent state. The following illustrates a representative use case of the service assurance agent. In this example, the service assurance agent deployed on the PNC retrieves the OTN service SLA (Step 1) from the PCE and obtains network state information (Step 2) from the topology manager. Based on this information, the agent formulates the corresponding network telemetry monitoring policy (Step 3) and subscribes to telemetry event change notifications from the network elements (NEs) accordingly (Step4). The NEs subsequently stream real-time telemetry data to the agent (Step 5). The agent analyzes this data in real time to detect and predict potential network anomalies before they occur (Step 6). In the event that an anomaly is predicted which may impact an existing OTN tunnel service, the agent invokes the PCE to calculate candidate alternative paths for service rerouting (Step 7). These candidate paths are subsequently provided to its peer agent on the MDSC (Step 8), which determines and selects the optimal rerouting option (Step 9). Upon receiving the selected rerouting option from the MDSC, the agent on the PNC invokes the tunnel manager to execute the reroute (Steps 10 and 11), thereby completing the closed-loop operation.

Sequence diagram of Service Assurance Agent use-case on OTN service assurance | | | | 2.callgetTeTopo() | | | | | to retrieve | | | | | network state | | | | |------------------>| | | | +--+ | | | | | | | 3.formulate network | | | | | monitoring policy | | | |<-+ | | | | | | | | | | | | 4.subscribe to telemetry event changes | | | based on monitoring policy | | |--------------------------------------->| | | 5.telemetry event streaming | | |<---------------------------------------| | +--+ | | | | | | |6.network anomaly prediction| | | | |based on telemetry monitoring | | |<-+ | | | | | ===================| | | | | [Anomaly predicted]| | | | | ===================| | | | | |7.call pce() | | | | 8.provide N |to cal alt paths | | | | possible |-------->| | | | |reroute paths | | | | | |<-------------| | | | | |9.select route| | | | | |------------->| 10.call updateOTNtunnel() to | | | | reroute the OTN service | | | |------------------------------>|11.OTN tunnel | | | | |reroute operation | | 12.return operation result |------->| | |<------------------------------| | | **Task finished** | | | | +---+---+ +---+---+-----+----+----+-----+-----+----+ +-+--+ | Agent | | Agent | PCE | Topo Mgr |Tunnel Mgr| | NE | +-------+ +-------+----------+----------+----------+ +----+ ]]>

Fault Handling Fault handling enables the network to automatically detect anomalies, localize faults, perform root cause analysis, and generate targeted repair solutions, thereby accelerating fault resolution and improving overall network reliability. In traditional OTN networks, fault management is often manual and fragmented, relying on operator intervention to diagnose and remediate issues. By integrating a fault handling agent into the ACTN framework, the network can transition to a closed-loop, automated fault management model. This model enables proactive fault detection, rapid root cause identification, and automated repair actions, minimizing service downtime and enhancing user experience. The following illustrates a representative use case of the fault handling agent in an OTN network. In this example, the fault handling agent deployed on the PNC first receives a fault notification (Step 1) from the network elements (NEs) indicating a link failure in the OTN network. The agent then retrieves the latest network topology and service information (Steps 2 and 3) from the topology manager and PCE, respectively. Using this data, the agent performs fault localization and root cause analysis (Step 4) to identify the exact location and nature of the fault. Based on the analysis, the agent generates a fault repair solution (Step 5), which may involve rerouting affected OTN tunnel services. The agent then invokes the PCE to calculate alternative paths for the affected services (Step 6) and provides these paths to its peer agent on the MDSC (Step 7). The MDSC selects the optimal rerouting option (Step 8) and instructs the PNC to execute the repair. The PNC then invokes the tunnel manager to reroute the affected OTN services (Steps 9 and 10), completing the closed-loop fault handling process.

Sequence diagram of Fault Handling Agent use-case on OTN link fault | | | | | |3.call getOTNtunnels() to get | | | | affected OTN service info | | | |------------------------------>| | | +--+ | | | | | | |4.fault localization| | | | | |&root cause analysis| | | | |<-+ | | | | | +--+ | | | | | | |5.generate fault | | | | | | repair solution | | | | | |(reroute affected svc) | | | |<-+ | | | | | | | | | | | |6.call pce()API for alt| | | | 7.provide N alt | path computation | | | | reroute paths |---------------------->| | | |<----------------| | | | | |8.select optimal | | | | | | reroute | 9.call updateOTNtunnel()API | | |---------------->| for reroute execution | | | |------------------------------>| | | |------------------------------>|10.OTN tunnel | | | | |reroute operation | | 11.return operation result |--------->| | |<------------------------------| | | **Task finished** | | | | +---+---+ +------+--------+------+-----+-+-+-----+----+ +--+-+ | Agent | | Agent | Topo Mgr |PCE|Tunnel Mgr| | NE | +-------+ +---------------+------------+---+----------+ +----+ ]]>

Security Considerations TBD

IANA Considerations This document has no requests for IANA action.

References Normative References Informative References Framework for Abstraction and Control of TE Networks (ACTN) This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services. AI based Network Management Agent(NMA): Concepts and Architecture CAICT China Mobile Huawei Cisco Huawei ZTE This document presents the concept of AI based network management agent(NMA), provides the basic definition and reference architecture of NMA, discusses the relationship of NMA with traditional network controller or other network management entity by exploring the deployment mode of NMA, and proposes the common processing flow and typical application scenarios of NMA. Framework and YANG Data Model for the NMA A2U Interface CAICT China Mobile Cisco This document describes a framework and a YANG data model for the Agent-to-User (A2U) interface of a Network Management Agent (NMA).

Example Deployment Using MCP-based Capability Invocation This appendix provides a non-normative example of how MCP-based capability invocation may be used in an NMA-enhanced ACTN deployment. The purpose of this example is to illustrate possible implementation approaches. It does not mandate the use of MCP for enhanced MPI, enhanced CMI, logical agent-to-agent interaction, or internal controller interactions. MCP stands for Model Context Protocol in this document. MCP may be used as a capability or tool invocation mechanism after NMAs are introduced into ACTN controllers. For example, selected controller capabilities, such as topology retrieval, tunnel creation, service assurance, incident analysis, inventory query, NMA skills, or other tool functions, may be exposed through MCP servers and invoked by MCP clients. shows two possible MCP-based deployment patterns. In the first pattern, the MCP server is deployed in the upper-layer MDSC. The MCP server registers or adapts capabilities provided by the lower-layer ACTN interface, such as topology, tunnel, service, inventory, or incident-related capabilities. The MDSC agent acts as an MCP client and invokes the MDSC-local MCP server. The interaction between the MDSC and the PNC is still performed through the enhanced MPI. This pattern is applicable regardless of whether the PNC contains NMAs, because the capabilities exposed to the MDSC agent may be derived from lower-layer NMA capabilities, existing ACTN NBI capabilities, or other controller functions. In the second pattern, the MCP server is deployed in the lower-layer PNC. The MDSC agent acts as an MCP client and invokes the PNC MCP server through MCP calls. The PNC MCP server may expose PNC NMA capabilities, existing ACTN NBI capabilities, controller functions, or other tools. This pattern is also applicable regardless of whether the PNC contains NMAs. It is especially useful for capability exposure across different vendors or heterogeneous controller implementations, because the MCP server can provide a unified capability invocation interface while hiding implementation-specific details inside the PNC.

Example MCP-based deployment patterns In this figure, "M-Agent" is shorthand for the NMA deployed in the MDSC layer, and "P-Agent" is shorthand for the NMA deployed in the PNC layer. The two patterns shown in are examples only. Other deployments are possible. For example, an implementation may expose only existing ACTN controller functions through MCP, or it may expose NMA capabilities, tool functions, and existing ACTN interface capabilities through a unified MCP server. Similarly, an implementation may use A2U-based YANG models, private APIs, or other standard mechanisms instead of MCP to realize capability exposure and invocation.