Common Control and Measurement Plane X. Zhao Internet-Draft CAICT Intended status: Informational H. Yu Expires: 7 January 2027 Huawei A. Li China Unicom Y. Xu CAICT 6 July 2026 Integration of Network Management Agent (NMA) into ACTN-Based Optical Network draft-zhao-ccamp-actn-optical-network-agent-02 Abstract 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 This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Network Management Operations Working Group mailing list (nmop@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ccamp/. Zhao, et al. Expires 7 January 2027 [Page 1] Internet-Draft NMA enhanced actn framework July 2026 Source for this draft and an issue tracker can be found at https://datatracker.ietf.org/doc/draft-zhao-ccamp-actn-optical- network-agent/. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . 4 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 3. NMA-based enhanced ACTN architecture . . . . . . . . . . . . 5 3.1. Enhanced ACTN architecture . . . . . . . . . . . . . . . 5 3.2. Enhanced ACTN interfaces . . . . . . . . . . . . . . . . 10 4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Service Provisioning . . . . . . . . . . . . . . . . . . 13 4.2. Service Assurance . . . . . . . . . . . . . . . . . . . . 16 4.3. Fault Handling . . . . . . . . . . . . . . . . . . . . . 18 Zhao, et al. Expires 7 January 2027 [Page 2] Internet-Draft NMA enhanced actn framework July 2026 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.1. Normative References . . . . . . . . . . . . . . . . . . 20 7.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. Example Deployment Using MCP-based Capability Invocation . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction With the emergence and popularization of the SDN concept, [RFC8453] 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 [I-D.zhao-nmop-network-management-agent] 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. Zhao, et al. Expires 7 January 2027 [Page 3] Internet-Draft NMA enhanced actn framework July 2026 This document, building on the Network Management Agent (NMA) concept proposed in [I-D.zhao-nmop-network-management-agent], 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. 2. Terminology 2.1. 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 [I-D.zhao-nmop-nma-a2u-interface] 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. 2.2. 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, Zhao, et al. Expires 7 January 2027 [Page 4] Internet-Draft NMA enhanced actn framework July 2026 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. 3. NMA-based enhanced ACTN architecture 3.1. Enhanced ACTN architecture The enhanced ACTN architecture for optical networks after the introduction of NMA is illustrated in Figure 1 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. Zhao, et al. Expires 7 January 2027 [Page 5] Internet-Draft NMA enhanced actn framework July 2026 +----------------------------------+ | Enhanced CNC | | +--------+ +--------+ +--------+ | | | NMA1 | | NMA2 | | NMA3 | | | +--------+ +--------+ +--------+ | +-----------------^----------------+ | |(1)Extended CMI | +-----------------v----------------+ | Enhanced MDSC | | +--------+ +--------+ +--------+ | | | NMA1 | | NMA2 | | NMA3 | | | +--------+ +--------+ +--------+ | +-----------------^----------------+ | |(2)Extended MPI | +----+-----------------------+-----------+ | | | +----------------------v--------------------+ +----v----+ +----v----+ | Enhanced PNC1 | | | | | | +----------+ +------+ | | | | | | | | +--->| 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 | +-------------------------------------------+ +---------+ +---------+ Figure 1: NMA-based enhanced ACTN architecture The enhanced ACTN architecture includes the following key entities: NMA-enhanced CNC (Customer Network Controller): As defined in [RFC8453], 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, Zhao, et al. Expires 7 January 2027 [Page 6] Internet-Draft NMA enhanced actn framework July 2026 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 [RFC8453], 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 [RFC8453], 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 Figure 2. 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. Zhao, et al. Expires 7 January 2027 [Page 7] Internet-Draft NMA enhanced actn framework July 2026 +--------------------------------------------+ | CNC | | +-------+ +-------+ +-------+ +-----+ | | | NMA1 | | NMA2 | | NMA3 | | ... | | | +---+---+ +---+---+ +---+---+ +--+--+ | | | | | | | | +---+----------+----------+---------+--+ | | | Agent Proxy | | | +------------------^-------------------+ | +---------------------|----------------------+ | | Extended CMI | +---------------------v----------------------+ | MDSC | | +--------------------------------------+ | | | Agent Proxy | | | +-^----+--------+--------+--------+----+ | | | | | | | | | | +--+---+ +--+---+ +--+---+ +--+--+ | | | | NMA1 | | NMA2 | | NMA3 | | ... | | | | +------+ +------+ +------+ +-----+ | +----|---------------------------------------+ | | Extended MPI | +----|----------------+----------------------+ | | PNC | | +-v------------------------------------+ | | | Agent Proxy | | | +---+----------+----------+---------+--+ | | | | | | | | +---+---+ +---+---+ +---+---+ +--+--+ | | | NMA1 | | NMA2 | | NMA3 | | ... | | | +---+---+ +---+---+ +---+---+ +--+--+ | +--------------------------------------------+ Figure 2: Diagram of Agent Proxy in each layer Figure 3 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 Figure 3. The left side of the figure represents a logical A2A interaction. This applies when both the upper-layer controller and Zhao, et al. Expires 7 January 2027 [Page 8] Internet-Draft NMA enhanced actn framework July 2026 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 Figure 3 is to show that NMAs can reuse and orchestrate the existing controller capabilities rather than replacing them. Zhao, et al. Expires 7 January 2027 [Page 9] Internet-Draft NMA enhanced actn framework July 2026 MDSC +-----------------------------------------------------------------+ | +------+------+------+-----+ +-------------------------+ | | | NMA1 | NMA2 | NMA3 | ... | | | | | +--+---+--+---+--+---+--+--+ | Existing | | | | | | | | function | | | +--+------+------+------+--+ | modules | | | | Agent Proxy | | | | | +-------------^------------+ +-------------------------+ | +---------------:-----------------^-------------------------------+ : | : Logical | Extended : A2A | MPI PNC : | +---------------:-----------------v-------------------------------+ | : | | +-------------v--------------------+ +------------------+ | | | Agent functions | | ACTN NBI | | | | +------------------------------+ | | | | | | | Agent Proxy | | | - topology | | | | +-------+-----------------+----+ | | - tunnel | | | | | | | Inter | - service | | | | +-------+-------+ +-------+----+ |<----->| - inventory | | | | | Svc Assurance | | Fault Mgmt | | API | - incident | | | | | Agent | | Agent | | | - SLA assurance | | | | +---------------+ +------------+ | | - to be extended | | | | ... | | - ... | | | +------------------^---------------+ +---------^--------+ | | | Internal API | | | +------------------v---------------------------------v--------+ | | | Existing function mudules | | | | +-----------+ +-----------+ +------+ +----------+ | | | | |TE Topology| |OTN&DWDM | | PCE | |Restconf | ... | | | | |Management | |Tunnel Mgmt| |Module| |Module | | | | | +-----------+ +-----------+ +------+ +----------+ | | | +-------------------------------------------------------------+ | +-----------------------------------------------------------------+ Figure 3: Sample illustration of NMAs in PNC 3.2. Enhanced ACTN interfaces As shown in Figure 1 and Figure 3, 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 Zhao, et al. Expires 7 January 2027 [Page 10] Internet-Draft NMA enhanced actn framework July 2026 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: 1. 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. 2. 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. 3. 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. 4. 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 Zhao, et al. Expires 7 January 2027 [Page 11] Internet-Draft NMA enhanced actn framework July 2026 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. 5. 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 [I-D.zhao-nmop-nma-a2u-interface] 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. Zhao, et al. Expires 7 January 2027 [Page 12] Internet-Draft NMA enhanced actn framework July 2026 * 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 Appendix A. This example is non-normative and is intended only to illustrate how controller capabilities may be exposed and invoked after NMAs are introduced. 4. 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. 4.1. 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 Zhao, et al. Expires 7 January 2027 [Page 13] Internet-Draft NMA enhanced actn framework July 2026 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 Figure 4 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. Zhao, et al. Expires 7 January 2027 [Page 14] Internet-Draft NMA enhanced actn framework July 2026 MDSC ----------------------PNC----------------- +-------+ +--------------+----------+---+----------+ +----+ | Agent | | Agent | Topo Mgr|PCE|Tunnel Mgr| | NE | +---+---+ +------+-------+-----+----+-+-+-----+----+ +-+--+ | 1.request TE topology | | | | | |------------------------>|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 | +-------+ +--------------+----------+---+-----+----+ +----+ Figure 4: Sequence diagram of Service Provisioning Agent Use-case Zhao, et al. Expires 7 January 2027 [Page 15] Internet-Draft NMA enhanced actn framework July 2026 4.2. 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 Figure 5 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. Zhao, et al. Expires 7 January 2027 [Page 16] Internet-Draft NMA enhanced actn framework July 2026 MDSC --------------------PNC------------------- +-------+ +-------+----------+----------+----------+ +----+ | Agent | | Agent | PCE | Topo Mgr |Tunnel Mgr| | NE | +-------+ +---+---+-----+----+----+-----+-----+----+ +-+--+ | | 1.call getOTNtunnel() to get | | | | deployed OTN svcs' SLAs | | | |------------------------------>| | | | 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 | +-------+ +-------+----------+----------+----------+ +----+ Figure 5: Sequence diagram of Service Assurance Agent use-case on OTN service assurance Zhao, et al. Expires 7 January 2027 [Page 17] Internet-Draft NMA enhanced actn framework July 2026 4.3. 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 Figure 6 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. Zhao, et al. Expires 7 January 2027 [Page 18] Internet-Draft NMA enhanced actn framework July 2026 MDSC ------------------------PNC------------------ +-------+ +---------------+------------+---+----------+ +----+ | Agent | | Agent | Topo Mgr |PCE|Tunnel Mgr| | NE | +---+---+ +------+--------+------+-----+-+-+-----+----+ +--+-+ | | 1.fault notification (OTN link failure) | | |<-----------------------------------------| | |2.call getTeTopo() | | | | | to get latest | | | | | | network topo | | | | | |-------------->| | | | | |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 | +-------+ +---------------+------------+---+----------+ +----+ Figure 6: Sequence diagram of Fault Handling Agent use-case on OTN link fault 5. Security Considerations TBD Zhao, et al. Expires 7 January 2027 [Page 19] Internet-Draft NMA enhanced actn framework July 2026 6. IANA Considerations This document has no requests for IANA action. 7. References 7.1. Normative References 7.2. Informative References [I-D.zhao-nmop-network-management-agent] Zhao, X., Wang, M., Wu, B., Ceccarelli, D., Zheng, H., and J. Zhou, "AI based Network Management Agent(NMA): Concepts and Architecture", Work in Progress, Internet-Draft, draft-zhao-nmop-network-management-agent-00, 17 October 2025, . [I-D.zhao-nmop-nma-a2u-interface] Zhao, X., Wang, M., and D. Ceccarelli, "Framework and YANG Data Model for the NMA A2U Interface", Work in Progress, Internet-Draft, draft-zhao-nmop-nma-a2u-interface-00, 6 July 2026, . [RFC8453] Ceccarelli, D. and Y. Lee, "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, . Appendix A. 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. Figure 7 shows two possible MCP-based deployment patterns. Zhao, et al. Expires 7 January 2027 [Page 20] Internet-Draft NMA enhanced actn framework July 2026 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. Zhao, et al. Expires 7 January 2027 [Page 21] Internet-Draft NMA enhanced actn framework July 2026 +-----------------------------+ +-----------------------------+ | Pattern 1: Upper-layer MCP | | Pattern 2: Lower-layer MCP | | adaptation | | capability exposure | +-----------------------------+ +-----------------------------+ MDSC MDSC +----------------------------+ +----------------------------+ | M-Agent / LLM | | M-Agent / LLM | | +----------------------+ | | +----------------------+ | | | MCP Client | | | | MCP Client | | | +----------^-----------+ | | +----------^-----------+ | | | | | | | | +----------v-----------+ | | | | | | MCP Server | | | | | | | capability adaptation| | | | | | +----------^-----------+ | +-------------|--------------+ +-------------|--------------+ | | Enhanced MPI | MCP Call | | +-------------v--------------+ +-------------|--------------+ | PNC | | PNC | | | +----------------------+ | | +----------v-----------+ | | | ACTN NBI / | | | | MCP Server | | | | controller functions | | | | capability exposure | | | +----------------------+ | | +----------^-----------+ | | +----------------------+ | | | | | | P-Agent | | | +----------v-----------+ | | | | | | | P-Agent or controller| | | +----------------------+ | | | functions / tools | | +----------------------------+ | +----------------------+ + +----------------------------+ Figure 7: 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 Figure 7 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. Zhao, et al. Expires 7 January 2027 [Page 22] Internet-Draft NMA enhanced actn framework July 2026 Authors' Addresses Xing Zhao CAICT Beijing China Email: zhaoxing@caict.ac.cn Henry Yu Huawei Canada Email: henry.yu1@huawei.com Ao Li China Unicom China Email: lia12@chinaunicom.cn Yunbin Xu CAICT China Email: xuyunbin@caict.ac.cn Zhao, et al. Expires 7 January 2027 [Page 23]