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

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, refers to AI based network management agent Agent: Specifically refers to NMA, i.e., the AI Agent for network management.

Definitions The document defines the following terms:

Network Management Agent (NMA):: A network management entity built based on ML/AI and equipped with the autonomous task processing capabilities. It can automatically carry out network status perception, task intent interpretation, task planning, decision-making and task execution operations based on user task intentions or preset goals, so as to achieve closed-loop processing of scenarios-oriented network management tasks. For different application scenarios, NMA can be subdivided into multiple scenario-oriented agents.

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. NMA) 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 agents can interact with existing ACTN functional modules through standardized protocols such as the Management Control Protocol (MCP). This integrated design approach ensures backward compatibility with the established ACTN framework and enables seamless interaction with the existing ACTN interfaces and control logic.

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 domain1 | | 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, a agent proxy shall be deployed to manage Agent-to-Agent (A2A) communication with agents external to the controller as shown in . The agent proxy is responsible for implementing the enhanced CMI on the MDSC and the enhanced MPI on the PNC respectively. In addition, it allows other NMAs within the controller to register their capabilities and advertises those capabilities on their behalf to external agents. It acts as a gateway for other NMAs within the controller to communicate with external agents. 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 assumes the presence of a agent proxy in all controllers which containing multiple NMA instances.

Diagram of Agent Proxy in each layer The agents can interact with existing ACTN functional components through standardized protocols, for example but not limited to the Management Control Protocol (MCP). depicts an example in which NMA instances on the PNC interact with existing ACTN functional modules. These functional modules may expose their capabilities (e.g., TE Topology retrieval and OTN tunnel service creation) as APIs internal to the PNC. NMA instances, such as a service provisioning agent, can invoke and consume these APIs via MCP. This integrated design approach ensures backward compatibility with the established ACTN framework and enables seamless interaction with the existing ACTN interfaces and control logic.

Sample illustration of NMAs in PNC

Enhanced ACTN interfaces As shown in , the architecture includes 5 types of interfaces:

Extended CMI: The interface between CNC and MDSC. After introducing NMA entities at each layer, the communication requirements between the original CMI interfaces will be enhanced from traditional transactional communication to include agent-oriented conversational communication. The CMI interface needs to be extended to meet the requirements of agent capability invocation and interaction between upper and lower layers. The extended CMI maintains forward compatibility and fully supports all functional capabilities of the original CMI interface, ensuring that existing CNC/MDSC devices and interaction logic without NMA deployment can still work normally based on the extended CMI.
Extended MPI: The interface between MDSC and PNC. Similar to CMI, after introducing NMA entities into MDSC and PNC, the original MPI also needs to be extended to support agent capability invocation and interaction between upper and lower layers. The extended MPI maintains forward compatibility and fully supports all functional capabilities of the original MPI interface, ensuring that existing MDSC/PNC devices and interaction logic without NMA deployment can still work normally based on the extended MPI.
SBI: The interface between PNC and physical network devices, which is out of scope of ACTN discussions.
Interfaces between NMAs and existing ACTN functional modules at each layer: These are internal system interfaces, which can be implemented through private interfaces or interface solutions such as MCP, and are not within the scope of discussion in this document.
Interfaces between NMAs within same layers: These are internal system interfaces that can use private interfaces or general agent communication interfaces (e.g., A2A, ACP, etc.), and are out of scope of this document.

Since NMAs can be deployed on different controllers within the ACTN hierarchy, two possible inter-controller AI-agent communication scenarios can be identified. For example, when there is a need for direct communication between NMAs in the upper-layer MDSC and those in the lower-layer PNC (A2A Communication), it will manifest as a single communication channel physically but multiple communication processes logically (i.e.including multiple A2A communication processes). illustrates these scenarios between the MDSC and PNC (The case between the MDSC and CNC is similar and omitted here for simplicity).It should be noted that: (1) The inter-controller NMA communication architecture based on extended ACTN interfaces is forward compatible: when an ACTN controller at a certain layer has no NMA deployed, the NMA at the peer layer can still realize upper and lower layer interaction with the peer controller through the original Restconf interaction mechanism based on extended CMI/MPI, without additional modification to the existing interface logic, as shown in (b)&(c). (2) The MCP protocol marked in is only for schematic illustration of the interface type between the NMA and other functional modules/tools in the controller. The document does not limit the mandatory use of the MCP protocol for this type of interface; other standard or private protocols that meet the inter-module interaction requirements are all applicable. All original functional modules in the ACTN controller are regarded as tool components that can be invoked by the NMA, and the NMA can complete autonomous task processing by calling the corresponding functional modules according to the task requirements. (3) In a), when NMAs are deployed in both the MDSC and PNC layers, conversational interaction between Agents can be directly completed through A2A communication between the two NMAs. However, the original Restconf based MPI interface is still supported; that is, the upper and lower NMAs can also issue and reply to instructions via the original MPI interface using the Restconf server/client mechanism, similar to b) and c). To avoid excessive complexity in the figure, this is not separately depicted in a).

Inter-controller NMA communication scenarios between MDSC and PNC functional|| || Existing ||Restconf|| ||functional <--->NMA|| || | | | modules || ||functional|| Client || || modules | | || ||NMA<-+ +----------+| || modules || || |+-----------+ +-^-+| || | | +----------+| |+----------++---^----+| | | | || | |MCP| Restconf || | | | | | | |+---+ +---> Client || | | | | | | | +-----^----+| | | | +------------------|--+ +----------------|-----+ +----------------|-----+ |A2A(Extended MPI) | MPI | MPI +------------------|--+ +----------------|-----+ +----------------|-----+ | PNC | | | PNC | | | PNC | | | | | | | | | +-----v----+| |+-----------+ +-v-+| |+----------++---v----+| |+---+ MCP| Restconf || || Existing |MCP| || || Existing ||Restconf|| || | +---> Server || ||functional <--->NMA|| ||functional|| Server || || | | +----------+| || modules | | || || modules || || ||NMA<-+ +----------+| |+-----------+ +---+| |+----------++--------+| || | | | Existing || | | | | || | |MCP|functional|| | | | | |+---+ +---> modules || | | | | | +----------+| +---------------------+ +----------------------+ +----------------------+ (a) (b) (c) ]]>

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 transactional interface, agent-to-agent (A2A) communication supports a bidirectional, conversational interaction 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, or requests for clarification. Furthermore, the MDSC is not constrained to invoke only the APIs pre-defined by the PNC. The A2A interface provides the flexibility to express service requirements that are not explicitly modeled in the existing MPI. The following illustrates an example of an OTN private leased line service creation via an A2A conversional interface. 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.