



Common Control and Measurement Plane                             X. Zhao
Internet-Draft                                                     CAICT
Intended status: Informational                                     H. Yu
Expires: 1 September 2026                                         Huawei
                                                                   A. Li
                                                            China Unicom
                                                                   Y. Xu
                                                                   CAICT
                                                        28 February 2026


 Integration of Network Management Agent (NMA) into ACTN-Based Optical
                                Network
             draft-zhao-ccamp-actn-optical-network-agent-01

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 1 September 2026                [Page 1]

Internet-Draft         NMA enhanced actn framework         February 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 1 September 2026.

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  . . . . . . . . . . . .   4
     3.1.  Enhanced ACTN architecture  . . . . . . . . . . . . . . .   5
     3.2.  Enhanced ACTN interfaces  . . . . . . . . . . . . . . . .   8
   4.  Use cases . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     4.1.  Service Provisioning  . . . . . . . . . . . . . . . . . .  12
     4.2.  Service Assurance . . . . . . . . . . . . . . . . . . . .  14
     4.3.  Fault Handling  . . . . . . . . . . . . . . . . . . . . .  16



Zhao, et al.            Expires 1 September 2026                [Page 2]

Internet-Draft         NMA enhanced actn framework         February 2026


   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

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 1 September 2026                [Page 3]

Internet-Draft         NMA enhanced actn framework         February 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, refers to AI based network management
   agent

   Agent: Specifically refers to NMA, i.e., the AI Agent for network
   management.

2.2.  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.

3.  NMA-based enhanced ACTN architecture










Zhao, et al.            Expires 1 September 2026                [Page 4]

Internet-Draft         NMA enhanced actn framework         February 2026


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. 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.

            +----------------------------------+
            |           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 domain1             |  | Domain2 | | Domain3 |
  +-------------------------------------------+  +---------+ +---------+





Zhao, et al.            Expires 1 September 2026                [Page 5]

Internet-Draft         NMA enhanced actn framework         February 2026


              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,
      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, a agent proxy shall be deployed to manage Agent-to-Agent
   (A2A) communication with agents external to the controller as shown
   in Figure 2.  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



Zhao, et al.            Expires 1 September 2026                [Page 6]

Internet-Draft         NMA enhanced actn framework         February 2026


   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.

              +--------------------------------------------+
              |                     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













Zhao, et al.            Expires 1 September 2026                [Page 7]

Internet-Draft         NMA enhanced actn framework         February 2026


   The agents can interact with existing ACTN functional components
   through standardized protocols, for example but not limited to the
   Management Control Protocol (MCP).  Figure 3 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.

                            ^                             ^
                            | Enhanced MPI                | MPI
      +---------------------+-----------------------------+--------+
      | PNC                 |                             |        |
      | +-------------------v-----------------------+     |        |
      | |                 Agent Proxy               |     |        |
      | +-------+--------------+--------------+-----+     |        |
      |         |              |              |           |        |
      | +-------+------+ +-----+-----+ +------+-----+     |        |
      | |   Service    | |  Service  | |   Fault    |     |        |
      | | Provisioning | | Assurance | | Management |     |        |
      | |    Agent     | |   Agent   | |   Agent    |     |        |
      | +-------+------+ +-----+-----+ +------+-----+     |        |
      |         |              |              |           |        |
      | +-------+--------------+--------------+-----+     |        |
      | |                 MCP Server                |     |        |
      | +----------------------^--------------^-----+     |        |
      |                        | Internal API             |        |
      | +----------------------v--------------------------v------+ |
      | |             Existing ACTN Function Modules             | |
      | | +-------------+ +------------+ +--------+ +----------+ | |
      | | |             | |            | |        | |          | | |
      | | | TE Topology | |  OTN&DWDM  | |  PCE   | | Restconf | | |
      | | |  Management | |   Tunnel   | | Module | |  Module  | | |
      | | |             | | Management | |        | |          | | |
      | | +-------------+ +------------+ +--------+ +----------+ | |
      | |                           ...                          | |
      | +--------------------------------------------------------+ |
      +------------------------------------------------------------+

                Figure 3: Sample illustration of NMAs in PNC

3.2.  Enhanced ACTN interfaces

   As shown in Figure 1, the architecture includes 5 types of
   interfaces:



Zhao, et al.            Expires 1 September 2026                [Page 8]

Internet-Draft         NMA enhanced actn framework         February 2026


   1.  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.

   2.  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.

   3.  SBI: The interface between PNC and physical network devices,
       which is out of scope of ACTN discussions.

   4.  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.

   5.  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).






Zhao, et al.            Expires 1 September 2026                [Page 9]

Internet-Draft         NMA enhanced actn framework         February 2026


   Figure 4 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 Figure 4 (b)&(c).

   (2) The MCP protocol marked in Figure 4 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 Figure 4 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 Figure 4 b) and c).  To avoid excessive
   complexity in the figure, this is not separately depicted in Figure 4
   a).



















Zhao, et al.            Expires 1 September 2026               [Page 10]

Internet-Draft         NMA enhanced actn framework         February 2026


+---------------------+ +----------------------+ +----------------------+
|         MDSC        | |          MDSC        | |          MDSC        |
|                     | |          +----------+| |                      |
|+-----------+   +---+| |+---+  MCP| Existing || |+----------++--------+|
|| Existing  |MCP|   || ||   | +--->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)


    Figure 4: Inter-controller NMA communication scenarios between
                             MDSC and PNC

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.



Zhao, et al.            Expires 1 September 2026               [Page 11]

Internet-Draft         NMA enhanced actn framework         February 2026


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
   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 Figure 5 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.

















Zhao, et al.            Expires 1 September 2026               [Page 12]

Internet-Draft         NMA enhanced actn framework         February 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 5: Sequence diagram of Service Provisioning Agent Use-case






Zhao, et al.            Expires 1 September 2026               [Page 13]

Internet-Draft         NMA enhanced actn framework         February 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 6 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 1 September 2026               [Page 14]

Internet-Draft         NMA enhanced actn framework         February 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 6: Sequence diagram of Service Assurance Agent use-case on
                           OTN service assurance




Zhao, et al.            Expires 1 September 2026               [Page 15]

Internet-Draft         NMA enhanced actn framework         February 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 7 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 1 September 2026               [Page 16]

Internet-Draft         NMA enhanced actn framework         February 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 7: Sequence diagram of Fault Handling Agent use-case on
                            OTN link fault

5.  Security Considerations

   TBD




Zhao, et al.            Expires 1 September 2026               [Page 17]

Internet-Draft         NMA enhanced actn framework         February 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, <https://datatracker.ietf.org/doc/html/draft-zhao-
              nmop-network-management-agent-00>.

   [RFC8453]  Ceccarelli, D. and Y. Lee, "Framework for Abstraction and
              Control of TE Networks (ACTN)", RFC 8453,
              DOI 10.17487/RFC8453, August 2018,
              <https://www.rfc-editor.org/rfc/rfc8453>.

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 1 September 2026               [Page 18]
