Integration of Network Management Agent (NMA) into ACTN-Based Optical Network
draft-zhao-ccamp-actn-optical-network-agent-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | XingZhao , Henry Yu , Ao Li , Yunbin Xu | ||
| Last updated | 2026-02-27 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zhao-ccamp-actn-optical-network-agent-01
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]