| Internet-Draft | FCAPS with Optical ACTN | November 2024 |
| Tan, et al. | Expires 1 June 2025 | [Page] |
Many network technologies are operated as Traffic Engineered (TE) networks. Optical networks are a particular case, and have complex technology-specific details.¶
Abstraction and Control of TE Networks (ACTN) is a management architecture that abstracts TE network resources to provide a limited network view for customers to request and self-manage connectivity services. It also provides functional components to orchestrate and operate the network.¶
Management of legacy optical networks is often provided via Fault, Configuration, Accounting, Performance, and Security (known as FCAPS) using mechanisms such as the Multi-Technology Operations System Interface (MTOSI) and the Common Object Request Broker Architecture (CORBA). FCAPS can form a critical part of configuration management and service assurance for network operations. However, the ACTN architecture as described in RFC 8453 does not include consideration of FCAPS.¶
This document enhances the ACTN architecture as applied to optical networks by introducing support for FCAPS. It considers which elements of existing IETF YANG work can be used to solve existing scenarios and emerging technologies, and what new work may be needed. In doing so, this document adds rich-detail network management to the ACTN architecture. This enhanced architecture may then be used to evolve networks from CORBA and MTOSI FCAPS interfaces to IETF-based YANG and RESTful APIs.¶
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 June 2025.¶
Copyright (c) 2024 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.¶
Abstraction and Control of Traffic Engineering Networks (ACTN) [RFC8453] is an architecture that simplifies and optimises the management and control of network resources to deliver connectivity services in Traffic Engineering (TE) networks, including optical networks. ACTN abstracts and controls TE resources to enable end-to-end service provisioning and management across multiple network domains. It provides a way to orchestrate and automate the management of network resources, including connectivity and bandwidth, to meet the requirements of specific services or applications.¶
ACTN in an optical network leverages Software Defined Networking (SDN) concepts to achieve its objectives. By applying SDN principles, such as centralised control and programmability, to the transport (i.e., sub-IP) layer, ACTN enables efficient orchestration and service provisioning in a multi-domain environment. ACTN adds a higher-level framework and management capabilities specifically tailored for TE transport networks, including the abstraction of network resources, service provisioning, and resource optimisation.¶
The term FCAPS [M-3060] is used in network management and stands for Fault, Configuration, Accounting, Performance, and Security. FCAPS is a widely accepted framework that categorises different aspects of network management and provides a structured approach to managing and maintaining networks, addressing various operational and maintenance areas.¶
Although FCAPS provides a structured framework for key functions required for managing networks, the level of granularity depends on how it is implemented; therefore, it does not inherently guarantee rich detail (rich-detail) control and observation.¶
While ACTN primarily deals with the abstraction and control of TE networks for service provisioning, FCAPS covers broader aspects of network management. In practice, while ACTN provides a suitable architecture for requesting and monitoring connectivity services in optical networks, operators would also like to leverage the FCAPS framework for specific operational tasks and management activities.¶
ACTN and FCAPS are not mutually exclusive, and this document explains how FCAPS can be integrated into the ACTN architecture as applied to optical networks. It considers which elements of IETF work can be used, and what new work is needed.¶
This enhanced ACTN architecture is known as ACTN Rich-Detail Network Management (ACTN RDNM). It provides an evolution path for FCAPS Operational Support System (OSS) functions from Common Object Request Broker Architecture (CORBA) [CORBA] interfaces and the Multi-Technology Operations System Interface (MTOSI) architecture [MTOSI], to IETF YANG-based models and RESTful APIs.¶
It should be noted that optical networks have a lot of details that are specific to the transmission medium (i.e., the physical and optical components and mechanisms used to send data on optical fibers). Different networks contain different physical transmission components that need to be managed in very specific ways. This can make generalisation of configuration and management hard, and means that the nature of ACTN RDNM is different in an optical network than it might be in a more general (and specifically, packet-based) TE network.¶
ITU-T G.805 [G-805] specifies the architecture and framework for the management of transport networks. G.805 provides guidelines and principles for managing network resources and services in a coordinated and efficient manner.¶
TMForum has developed its own set of standards and frameworks for managing telecommunications networks and services. Specifically, TMForum developed the Telecommunications Management Network (TMN) model and informed ITU-T M.3060 [M-3060] to align with G.805. TMN is a framework that defines a comprehensive set of management functions and interfaces for network operations and service management, that is, FCAPS.¶
More recently, ITU-T M.3041 [M-3041] introduced a framework for smart operation, management, and maintenance (SOMM). M.3041 provides the characteristics, scenarios, and the functional architecture of SOMM to support service operation, network management, and infrastructure maintenance for both traditional physical networks and for software-defined networking. It is applicable to network function virtualisation (non-SDN/NFV) and to SDN/NFV aware networks.¶
This document shows how the ACTN architecture can accommodate the principles of G.805 and M.3041 to include FCAPS capabilities. It outlines existing IETF mechanisms, protocols and data models, and indicates requirements where gaps exist.¶
MTOSI [MTOSI] is a standard in the telecommunications industry that provides a common framework for operations support systems (OSSes) to interact with various network elements and technologies. It defines a set of standardised interfaces and protocols to enable the integration of different OSS components.¶
It contains several capabilities and key features:¶
Service Management: MTOSI focuses on service management, allowing operators to efficiently provision, activate, and manage services on the network.¶
Interoperability: MTOSI promotes interoperability between different vendors' OSS components, reducing the complexity of integrating heterogeneous network elements.¶
Common Data Model: MTOSI defines a common data model for information exchanged between OSS components, ensuring consistency and accuracy in operations.¶
To enable automation of operations, which is crucial for managing large, multi-technology, complex, telecommunications networks, these features must be introduced into ACTN as ACTN RDNM.¶
Increasingly, network OSSes will require atomic-level views of network devices and interfaces, instead of only abstracted views and interactions. This will allow ACTN-based systems to leverage inventory management, device-level and interface-level views, and network configuration operations, via RESTful APIs instead of legacy CORBA-based APIs.¶
Service Assurance refers to the activities and processes that ensure the quality, availability, and performance of services delivered by a network. Those processes monitor and manage the end-to-end service experience, and ensure that Service Level Agreements (SLAs) and customer expectations are met.¶
By applying RESTful FCAPS functions through the ACTN framework, network operators and service providers can address different aspects of network management to support Service Assurance. This helps them detect and resolve faults, manage configurations, track resource usage, optimise performance, and enhance security, all of which contribute to delivering reliable and high-quality services to customers.¶
Not all Service Assurance requirements can be provided via existing ACTN YANG models. Rich-detail management may also be required, supplementing abstract resource models with inventory-based models such as [I-D.ietf-ivy-network-inventory-yang]. This would provide an atomic-level view of network devices and components, instead of only abstracted views. Note that not all FCAPS functions require rich-detail views and control: a mix of abstracted and detailed views will sometimes be needed.¶
Operators who manage optical transport networks can leverage ACTN for resource abstraction and service provisioning. At the same time, they can utilise the G.805 architecture and the TMN model to establish effective network management practices, which will facilitate service assurance. Combining the two management approaches aligns with best-practice industry standards and allows adoption of emerging ACTN-based abstraction and control techniques.¶
This document studies the FCAPS requirements in the context of ACTN functional components. It analyses the ACTN interfaces from a management operations perspective. It identifies suitable IETF data models that meet FCAPS requirements that can be utilised in the ACTN architecture to support optical transport networks. Gaps and requirements are identified where necessary so additional models may be developed.¶
Figure 1 shows the ACTN architecture from [RFC8453] enhanced to provide FCAPS support. The Customer Network Controller (CNC), Multi-Domain Service Coordinator (MDSC), and Provisioning Network Controller (PNC) are functional components of ACTN, as described in RFC 8453. There are two ACTN interfaces between the components: the CNC-MDSC Interface (CMI) and the MDSC-PNC Interface (MPI). In ACTN, the CMI and MPI are realised using a combination of IETF YANG data models.¶
+--------------------------------------+
| OSS |
| |
| +------+ +------+ +------+ |
| | FM | | PM | | RM | |
| | ...|....|......|.....|.. | |
| | : | | | | : | |
| | : | | | CNC | : | |
| | :..|....|......|.....|.: | |
| | | | | | | | |
| +------+ +------+ | +------+ |
| | | | | | |
+----|---|----------|-----|-------|----+
| | | | |
Boundary | | | | CMI |
between | | | | |
Customer & ======|===|==========|=====|=======|======
Network | | | | |
Operator | | | | |
| +------------------------+ |
| | MSDC | |
| +------------------------+ |
| | |
| MPI | |
| (ACTN/RDNM) | |
| | |
+-----------------------------------+
| Domain |
| Controller |
| |
| +------------+ |
| | NMS/EMS | |
| | ............. |
| | : | : |
| | : | PNC : |
| | :...|.......: |
| | | |
| +------------+ |
| |
+-----------------------------------+
/ |
/ |
--------- |
( ) |
( Physical ) |
( Network ) ---------
--------- ( )
( Physical )
( Network )
---------
Figure 1 shows the ACTN functional components as described in [RFC8453], but also introduces some common management system components. The OSS is the overarching management component that the operator uses to coordinate customers, services, and the network, and to apply policies across the network. It contains a Fault Management (FM) component, a Policy Management (PM) component, and a Resource Management (RM) component. The Network Management System (NMS) allows an operator to manage a network or set of network elements as a single unit. At the same time, the Element Management System (EMS) applies configuration and management to individual network elements.¶
As described in [RFC8453], the function of the PNC may be provided by an NMS or an EMS. Thus, Figure 1 shows the PNC overlapping with the NMS/EMS. To avoid confusion between the three possible components (NMS, EMS, PNC) that might all be used to operate the devices in the network, this document groups all of their function together and uses the term Domain Controller (a term used in [RFC7426] and [RFC8309]).¶
In a conventional management system, the OSS uses an interface with the Domain Controller to exchange FCAPS information. This interface has previously been based on CORBA, MTOSI, and XML. Furthermore, in an ACTN system, the OSS is likely the point of origin for policy instructions that guide the MDSC in orchestrating customer service requests and configuring the network. Thus, the CNC functions form part of the OSS, overlapping with the FM, PM, and RM functional components.¶
In [RFC8453] the MPI is used by the MDSC to instruct the PNCs about how the network must be configured to deliver the customers' services. The MPI also reports to the MDSC on the status of provisioning commands and the availability of network resources. However, up to now, the MDSC has had no visibility into the majority of the FCAPS functions and has, therefore, had limited reactive and proactive abilities.¶
Instead of only using abstracted Tunnel and Topology YANG models, the capability to support network inventory and device models is required, facilitating more detailed modeling and configuration management of network resource information.¶
This document examines how the MPI may be enhanced with extensions that utilise current YANG models, such as inventory, as well as with future YANG-based data models to deliver extensions that provide RESTful FCAPS support.¶
This section describes the MPI as specified before the addition of FCAPS capabilities.¶
Figure 2 lists the data models that can be used at the MPI for abstraction and control of underlying optical networks.¶
Category | Data Model | Document
---------+---------------------------+----------------------------------
Topology | ietf-network | RFC 8345
+---------------------------+----------------------------------
| ietf-network-topology | RFC 8345
+---------------------------+----------------------------------
| ietf-te-topology | RFC 8795
+---------------------------+----------------------------------
| ietf-wson-topology | RFC 9094
+---------------------------+----------------------------------
| ietf-otn-topology | draft-ietf-ccamp-otn-topo-yang
+---------------------------+----------------------------------
| ietf-flex-grid-topology | draft-ietf-ccamp-flexigrid-yang
+---------------------------+----------------------------------
| ietf-optical-impairement- | draft-ietf-ccamp-optical-
| topology | impairment-topology-yang
---------+---------------------------+----------------------------------
Tunnel | ietf-te | draft-ietf-teas-yang-te
+---------------------------+----------------------------------
| ietf-wson-tunnel | draft-ietf-ccamp-wson-tunnel-
| | model
+---------------------------+----------------------------------
| ietf-otn-tunnel | draft-ietf-ccamp-otn-tunnel-model
+---------------------------+----------------------------------
| ietf-flexi-grid-media- | draft-ietf-ccamp-flexigrid-
| channel | media-channel-yang
---------+---------------------------+----------------------------------
The abstraction of TE modeling is described in Section 3 of [RFC8795]. The major objects that are modeled include TE topology, TE node, TE link, TE Link Termination Point (LTP), TE Tunnel Termination Point (TTP). Also included in the modeling are transitional TE link, TE node connectivity matrix, and TTP Local Link Connectivity List to describe the multiplexing relationship of links. These TE concepts are generic, but they are also applicable within an optical network. The MPI deals in abstracted TE network concepts and so can be realised using the YANG models listed in Section 3.1 to expose the TE modeled objects that can be enhanced using YANG model augmentations to make them specific to optical technologies.¶
Generic TE topology models are defined in [RFC8345] and [RFC8795]. Specific extensions to the abstract TE model for optical networks are provided in a series of documents ([RFC9094], [I-D.ietf-ccamp-otn-topo-yang], [I-D.ietf-ccamp-flexigrid-yang], and [I-D.ietf-ccamp-optical-impairment-topology-yang]). This list of documents arises because the different optical network technologies demand different models for the varying characteristics of the equipment.¶
Tunnels are a fundamental component of TE, and a generic TE tunnel YANG model is found in [I-D.ietf-teas-yang-te]. Specific extensions to the generic TE tunnel model for optical networks are provided in a series of documents ( [I-D.ietf-ccamp-wson-tunnel-model], [I-D.ietf-ccamp-otn-tunnel-model], and [I-D.ietf-ccamp-flexigrid-media-channel-yang]). Again, there are multiple documents because of the different optical network technologies.¶
Although the building blocks of FCAPS are Fault, Configuration, Accounting, Performance, and Security, the important functions for integration within an ACTN system are Configuration, Alarm Management, and Performance Management. All three of these functions are underpinned by Inventory Management.¶
Abstract Control represents the high-level strategic view and objectives, while Rich-Detail Network Management represents the detailed operational tasks and activities that support the strategic objectives. Both levels are important for effective management and control within the operator network.¶
Abstract Control is often mapped to G.805 [G-805] objects. An Abstract Control object can also be mapped to multiple Rich-Detail Network Management objects that enable the Abstract Control object. Therefore, we should not see these concepts as mutually exclusive, but instead as necessary approaches to be combined for holistic control and operational management of ACTN-based network infrastructures.¶
In the context of ACTN, the MPI is both a concept and a set of mechanisms within ACTN that enable the interconnection of services across multiple domains or administrative boundaries. The MPI addresses the challenge of interconnecting services across multiple administrative domains. It provides a mechanism to coordinate and manage the service delivery between domains while ensuring end-to-end service continuity and quality.¶
Section 2 emphasises the importance of finely configuring FCAPS capabilities for the efficient operation and troubleshooting of ACTN-based services. It is anticipated that these capabilities will necessitate detailed and precise network management functions.¶
The Rich-Detail Network Management Functions can be categorised as follows. Several aspects of their functions already exist in the MDSC in the ACTN architecture, and are accessed via the MPI. Other functions may be added to the MPI in the future by enhancing or augmenting existing optical network YANG models or by creating new models.¶
Several legacy Rich-Detail Network Management interfaces, such as CORBA, exist to facilitate the precise control and management of network elements and services. These interfaces enable communication and interaction between different systems, devices, and management platforms:¶
Command Line Interface (CLI)¶
Simple Network Management Protocol (SNMP)¶
Management system approaches such as CORBA, MTOSI, and XML¶
New interfaces and data models have been developed that support Rich-Detail Network Management functions. These models are written in YANG, and the interfaces use NETCONF and RESTCONF, the latter also providing RESTful API functions.¶
As noted in Section 5.1, new or enhanced data models may be required for Rich-Detail Network Management in ACTN-based optical networks. Figure 3 shows a functional architecture for YANG control in an ACTN system enhanced with RDNM. The existing ACTN YANG models provide access to network devices through topology models that map to inventory and thus to configuration of network devices. The old MTOSI approach provides access to inventory and device configuration.¶
The RDNM additions to ACTN retrieve information from the inventory including performance information viewed through the lens of topology. It also allows direct manipulation of devices through configuration of inventory items in a mirror of the MTOSI function. Lastly, fault and alarm information that is generated in respect of the inventory may be delivered direct to the FdDM system or may be correlated before being reported as incidents.¶
------------------------------
| ACTN wth RDNM |
------------------------------
: ^ : ^
: : : :
: : : :
----------:----:- : :
| : : | : :
MTOSI | Topology : : | : :
\ | : : | : :
\ ----------:----:- : :
\ : : : :
\ v : v :
------------- \--------------------- -------------
| | | | | |
| Performance |---| Inventory |---| Fault/Alarm |
| | | | | |
------------- ---------------------\ -------------
| \
| \----------
--------------- | |
| Configuration | | Security |
--------------- | |
| ----------
|
Devices
[I-D.yu-ccamp-te-fgnm-yang] proposes a generic RDNM extension model, which augments the TE topology model for RDNM-specific purposes. It is expected that layer-specific RDNM extensions will also be required in the future.¶
Additional work in the IETF exists to provide optical resource monitoring, telemetry data, alarm and incident monitoring, inventory, life cycle management, service assurance, and asset management. This existing IETF work includes:¶
A YANG Data Model for Network Incident Management [I-D.ietf-nmop-network-incident-yang]¶
A YANG Data Model for Network Inventory [I-D.ietf-ivy-network-inventory-yang]¶
A Network Inventory Topology Model [I-D.ietf-ivy-network-inventory-topology]¶
Service Assurance for Intent-based Networking Architecture [RFC9417]¶
A Data Manifest for Contextualized Telemetry Data [I-D.ietf-opsawg-collected-data-manifest]¶
Asset Lifecycle Management and Operations Problem Statement [I-D.palmero-ivy-ps-almo]¶
Data Model for Asset Lifecycle Management and Operations [I-D.palmero-ivy-dmalmo]¶
A YANG Data Model for Optical Resource Performance Monitoring [I-D.yu-ccamp-optical-resource-pm-yang]¶
A YANG model to manage the optical interface parameters for an external transponder in a WDM network [I-D.ietf-ccamp-dwdm-if-param-yang]¶
A YANG Data Model for Client Signal Performance Monitoring [I-D.zheng-ccamp-client-pm-yang]¶
Further work on this document will add to this list of IETF YANG data models that could provide Rich-Detail Network Management functionality, in the context of ACTN, specifically for optical networks and with particular attention to the MPI.¶
Editors note: An example of Rich-Detail Network Management of an optical network using the ACTN architecture will be provided in a future version of this document.¶
[Editors Note] This section will discuss the coexistence of ACTN and legacy FCAPS systems. It will also consider how legacy systems might be smoothly migrated to an ACTN RDNM system.¶
A conventional approach to management of optical networks using MTOSI typically employs inventory and device configuration models. However, the current ACTN YANG models offer an innovative pathway to interact with network devices. They achieve this by employing topology models that correlate directly with both inventory and device configurations. To fully leverage the management infrastructure through RDNM interfaces, it is essential to develop additional resource data models. These enhancements to ACTN, specifically for optical RDNM, are anticipated to be crucial for extracting comprehensive information from the inventory, including performance metrics. Such integration would enable a comprehensive perspective on network performance and facilitate direct device manipulations by aligning inventory configurations with the foundational principles of MTOSI.¶
In addressing network fault issues, the system will leverage alarm data produced by the network inventory assets. This information might be directly fed into the RDNM system or undergo correlation before being flagged as incidents. This process ensures efficient troubleshooting by pinpointing the exact nature and location of network anomalies.¶
Moreover, security remains a paramount concern in any network setup. As such, this document dedicates Section 8 to security considerations, outlining several critical security requirements. These guidelines are designed to safeguard the network environment, ensuring robust protection against potential threats and vulnerabilities.¶
Security measures and protocol security must be applied to ensure the confidentiality, integrity, and availability of information and resources within the context of an ACTN RDNM-based system.¶
Key aspects of ACTN RDNM security will require:¶
Authentication: The process of verifying the identity of an ACTN user, system, or device. Includes mechanisms to authenticate users and systems before allowing them to access sensitive resources or perform certain operations.¶
Authorisation: Once a user or system is authenticated, authorisation determines what actions or resources they are allowed to access. MTOSI security mechanisms define roles, permissions, and access controls to ensure that only authorized entities can perform specific tasks.¶
Data Encryption: Encryption techniques may be used to protect sensitive data as it is transmitted over the management network. This prevents unauthorised access to or interception of information.¶
Secure Communication Protocols: The use of secure communication protocols, such as HTTPS (HTTP over SSL/TLS) or other cryptographic protocols, ensures that data exchanged between ACTN components remains confidential and unmodified.¶
Secure Data Storage: Security measures are put in place to protect data stored within the ACTN environment. This includes encryption of stored inventory, device, and service data, access controls, and regular security audits.¶
Auditing and Logging: This includes the capability to record and monitor ACTN-based activities within the management system. Audit logs provide a record of who accessed what resources and when, which is crucial for investigating security incidents or compliance with regulations.¶
Intrusion Detection and Prevention: Software systems and hardware devices may have mechanisms in place to detect and respond to unauthorized access attempts or suspicious activities. Intrusion detection systems (IDS) and intrusion prevention systems (IPS) can play a role in ACTN-based security.¶
Vulnerability Management: Regular security assessments and vulnerability scans help identify and address potential weaknesses in the ACTN environment.¶
Security Policies and Procedures: Clear security policies and procedures should be established and communicated to all stakeholders. This ensures that everyone understands their responsibilities in maintaining the security of the ACTN system.¶
Incident Response: Security should include plans and procedures for responding to security incidents, including steps for containment, investigation, mitigation, and recovery.¶
Overall, security is crucial for maintaining the integrity and reliability of ACTN RDNM operations and support systems, especially in an environment where sensitive customer data and critical network resources are involved. It is expected that all IETF YANG documents include clear analysis of the security vulnerabilities associated with the YANG models they describe.¶
This document makes no requests for IANA action.¶
Thank you to Daniele Ceccarelli and Victor Lopez for their observations and suggestions regarding this document.¶