| Internet-Draft | NMA enhanced actn framework | February 2026 |
| Zhao, et al. | Expires 1 September 2026 | [Page] |
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.¶
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/.¶
Source for this draft and an issue tracker can be found at https://datatracker.ietf.org/doc/draft-zhao-ccamp-actn-optical-network-agent/.¶
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 (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.¶
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.¶
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.¶
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.¶
The document defines the following terms:¶
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.¶
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 |
+-------------------------------------------+ +---------+ +---------+
The enhanced ACTN architecture includes the following key entities:¶
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 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 | | ... | |
| +---+---+ +---+---+ +---+---+ +--+--+ |
+--------------------------------------------+
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 | | | | | | |
| | +-------------+ +------------+ +--------+ +----------+ | |
| | ... | |
| +--------------------------------------------------------+ |
+------------------------------------------------------------+
As shown in Figure 1, 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).¶
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).¶
+---------------------+ +----------------------+ +----------------------+
| 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)
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.¶
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.¶
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 |
+-------+ +--------------+----------+---+-----+----+ +----+
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.¶
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 |
+-------+ +-------+----------+----------+----------+ +----+
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.¶
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 |
+-------+ +---------------+------------+---+----------+ +----+
This document has no requests for IANA action.¶