Integrating YANG Configuration and Management into an Abstraction and Control of TE Networks (ACTN) System for Optical Networks
draft-ietf-ccamp-actn-optical-transport-mgmt-02
| Document | Type | Active Internet-Draft (ccamp WG) | |
|---|---|---|---|
| Authors | Yanxia Tan , XingZhao , Chaode Yu , Daniel King , Adrian Farrel | ||
| Last updated | 2024-11-28 | ||
| Replaces | draft-gstk-ccamp-actn-optical-transport-mgmt | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-ccamp-actn-optical-transport-mgmt-02
CCAMP Working Group Y. Tan
Internet-Draft China Unicom
Intended status: Standards Track X. Zhao
Expires: 1 June 2025 CAICT
C. Yu
Huawei Technologies
D. King, Ed.
A. Farrel, Ed.
Old Dog Consulting
28 November 2024
Integrating YANG Configuration and Management into an Abstraction and
Control of TE Networks (ACTN) System for Optical Networks
draft-ietf-ccamp-actn-optical-transport-mgmt-02
Abstract
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.
Tan, et al. Expires 1 June 2025 [Page 1]
Internet-Draft FCAPS with Optical ACTN November 2024
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 June 2025.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. FCAPS Transport Network Management Approaches . . . . . . 4
1.2. Configuration Management . . . . . . . . . . . . . . . . 5
1.3. Service Assurance . . . . . . . . . . . . . . . . . . . . 6
1.4. Motivation and Scope . . . . . . . . . . . . . . . . . . 6
2. Extending the ACTN Architecture to Include FCAPS . . . . . . 7
3. Functionality at the MPI . . . . . . . . . . . . . . . . . . 9
3.1. Data Models at the MPI . . . . . . . . . . . . . . . . . 9
3.2. Abstraction and Control at the MPI . . . . . . . . . . . 10
4. Introduction to FCAPS . . . . . . . . . . . . . . . . . . . . 11
5. Abstract Control and Rich-Detail Network Management for
ACTN . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Abstract Control and Rich-Detail Network Management
Functions for the MPI . . . . . . . . . . . . . . . . . . 12
5.2. Rich-Detail Network Management Interfaces . . . . . . . . 13
Tan, et al. Expires 1 June 2025 [Page 2]
Internet-Draft FCAPS with Optical ACTN November 2024
5.3. Rich-Detail Network Management Data Models . . . . . . . 14
5.4. Rich-Detail Network Management Example . . . . . . . . . 16
6. Compatiblity and Migration . . . . . . . . . . . . . . . . . 16
7. Manageability Considerations . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
11. Informative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
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.
Tan, et al. Expires 1 June 2025 [Page 3]
Internet-Draft FCAPS with Optical ACTN November 2024
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.
1.1. FCAPS Transport Network Management Approaches
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
Tan, et al. Expires 1 June 2025 [Page 4]
Internet-Draft FCAPS with Optical ACTN November 2024
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.
1.2. Configuration Management
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.
Tan, et al. Expires 1 June 2025 [Page 5]
Internet-Draft FCAPS with Optical ACTN November 2024
1.3. Service Assurance
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.
1.4. Motivation and Scope
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.
Tan, et al. Expires 1 June 2025 [Page 6]
Internet-Draft FCAPS with Optical ACTN November 2024
2. Extending the ACTN Architecture to Include FCAPS
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 : |
| | :...|.......: |
Tan, et al. Expires 1 June 2025 [Page 7]
Internet-Draft FCAPS with Optical ACTN November 2024
| | | |
| +------------+ |
| |
+-----------------------------------+
/ |
/ |
--------- |
( ) |
( Physical ) |
( Network ) ---------
--------- ( )
( Physical )
( Network )
---------
Figure 1: The ACTN Architecture Enhanced for FCAPS
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
Tan, et al. Expires 1 June 2025 [Page 8]
Internet-Draft FCAPS with Optical ACTN November 2024
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.
3. Functionality at the MPI
This section describes the MPI as specified before the addition of
FCAPS capabilities.
3.1. Data Models at the MPI
Figure 2 lists the data models that can be used at the MPI for
abstraction and control of underlying optical networks.
Tan, et al. Expires 1 June 2025 [Page 9]
Internet-Draft FCAPS with Optical ACTN November 2024
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
---------+---------------------------+----------------------------------
Figure 2: ACTN MPI YANG Models
3.2. Abstraction and Control at the MPI
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],
Tan, et al. Expires 1 June 2025 [Page 10]
Internet-Draft FCAPS with Optical ACTN November 2024
[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.
4. Introduction to FCAPS
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.
* Inventory Management describes all objects involved in the
network, including hardware resources (such as network elements,
chassis, slots, boards, ports, optical modules, and cables, etc.)
and logical resource objects used for service provisioning.
* The basic Configuration requirement in ACTN is to configure end-
to- end paths across the transport network based on the
requirements of users.
* Alarm Management refers to how the system enables and disables
alarm reporting, collects alarm information, and processes that
information to relate it to the connections that are managed by
ACTN. When a network is running, the Domain Manager collects
alarm information from devices or processes connection-related
alarms and reports the alarms to the OSS of operator. So that
Operations and Management engineers can detect and rectify network
faults in time. The main functionalities include alarm retrieval,
alarm handling, and alarm control.
* Performance Monitoring enables engineers to collect and monitor
performance data from certain physical devices or logical objects
to identify the status of the network. The interfaces of
Performance Management include performance monitoring control,
performance information retrieval, and threshold crossing alert
control.
Tan, et al. Expires 1 June 2025 [Page 11]
Internet-Draft FCAPS with Optical ACTN November 2024
5. Abstract Control and Rich-Detail Network Management for ACTN
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.
5.1. Abstract Control and Rich-Detail Network Management Functions for
the MPI
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.
* Service Provisioning: This involves the detailed provisioning and
activation of services. This includes path computation,
configuring service parameters, policy management, allocating
resources, and ensuring proper service activation and
deactivation.
Tan, et al. Expires 1 June 2025 [Page 12]
Internet-Draft FCAPS with Optical ACTN November 2024
* Network Performance Monitoring: This encompasses monitoring and
analysing network performance. It involves collecting and
analysing performance metrics such as latency, jitter, packet
loss, and throughput to identify and resolve performance issues
promptly.
* Fault Detection and Alarm Management: This includes advanced fault
detection mechanisms to identify and troubleshoot network issues
quickly. It involves monitoring network elements, analysing
alarms and events, and performing fault localisation and isolation
to expedite problem resolution.
* Security Management: This covers the management of security
measures within the TE network. It involves activities such as
access control, authentication, encryption, intrusion detection,
and vulnerability management to ensure network security and
protect against threats.
* Service Level Agreement (SLA) Management: This involves tracking
service performance against SLA targets, generating SLA reports,
and taking corrective actions to meet or exceed customer
expectations.
* Capacity Planning: This encompasses detailed planning activities
to ensure optimal resource utilisation and to meet future demands.
It involves analysing traffic patterns, forecasting capacity
requirements, and implementing capacity expansion strategies.
5.2. Rich-Detail Network Management Interfaces
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.
Tan, et al. Expires 1 June 2025 [Page 13]
Internet-Draft FCAPS with Optical ACTN November 2024
5.3. Rich-Detail Network Management Data Models
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
Figure 3: Functional Model of ACTN with RDNM
Tan, et al. Expires 1 June 2025 [Page 14]
Internet-Draft FCAPS with Optical ACTN November 2024
[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]
* YANG Modules for Service Assurance [RFC9418]
* 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.
Tan, et al. Expires 1 June 2025 [Page 15]
Internet-Draft FCAPS with Optical ACTN November 2024
5.4. Rich-Detail Network Management Example
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.
6. Compatiblity and Migration
[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.
7. Manageability Considerations
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.
8. Security Considerations
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.
Tan, et al. Expires 1 June 2025 [Page 16]
Internet-Draft FCAPS with Optical ACTN November 2024
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.
Tan, et al. Expires 1 June 2025 [Page 17]
Internet-Draft FCAPS with Optical ACTN November 2024
* 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.
9. IANA Considerations
This document makes no requests for IANA action.
10. Acknowledgements
Thank you to Daniele Ceccarelli and Victor Lopez for their
observations and suggestions regarding this document.
11. Informative References
[CORBA] Object Management Group, "Common Object Request Broker
Architecture (CORBA) Component Model.", Standard OMG,
March 2006, <https://www.omg.org/spec/CCM/>.
[G-805] International Telecommunication Union - Telecommunication
Standardization Sector, "ITU-T G.805, Generic functional
architecture of transport networks.", Recommendation ITU-T
Recommendation G.805, 10 March 2001,
<https://www.itu.int/rec/T-REC-G.805-200003-I/en>.
[I-D.ietf-ccamp-dwdm-if-param-yang]
Galimberti, G., Hiremagalur, D., Grammel, G., Manzotti,
R., and D. Breuer, "A YANG model to manage the optical
interface parameters for an external transponder in a WDM
network", Work in Progress, Internet-Draft, draft-ietf-
ccamp-dwdm-if-param-yang-11, 5 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
dwdm-if-param-yang-11>.
Tan, et al. Expires 1 June 2025 [Page 18]
Internet-Draft FCAPS with Optical ACTN November 2024
[I-D.ietf-ccamp-flexigrid-media-channel-yang]
de Madrid, U. A., Burrero, D. P., King, D., Lopez, V.,
Busi, I., de Dios, O. G., Lee, Y., and G. Galimberti, "A
YANG Data Model for Flexi-Grid Media Channels", Work in
Progress, Internet-Draft, draft-ietf-ccamp-flexigrid-
media-channel-yang-04, 12 July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
flexigrid-media-channel-yang-04>.
[I-D.ietf-ccamp-flexigrid-yang]
de Madrid, U. A., Burrero, D. P., King, D., Lee, Y., and
H. Zheng, "A YANG Data Model for Flexi-Grid Optical
Networks", Work in Progress, Internet-Draft, draft-ietf-
ccamp-flexigrid-yang-17, 12 September 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
flexigrid-yang-17>.
[I-D.ietf-ccamp-optical-impairment-topology-yang]
Beller, D., Le Rouzic, E., Belotti, S., Galimberti, G.,
and I. Busi, "A YANG Data Model for Optical Impairment-
aware Topology", Work in Progress, Internet-Draft, draft-
ietf-ccamp-optical-impairment-topology-yang-17, 21 October
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
ccamp-optical-impairment-topology-yang-17>.
[I-D.ietf-ccamp-otn-topo-yang]
Zheng, H., Busi, I., Liu, X., Belotti, S., and O. G. de
Dios, "A YANG Data Model for Optical Transport Network
Topology", Work in Progress, Internet-Draft, draft-ietf-
ccamp-otn-topo-yang-20, 7 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
otn-topo-yang-20>.
[I-D.ietf-ccamp-otn-tunnel-model]
Zheng, H., Busi, I., Belotti, S., Lopez, V., and Y. Xu,
"OTN Tunnel YANG Model", Work in Progress, Internet-Draft,
draft-ietf-ccamp-otn-tunnel-model-21, 6 June 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
otn-tunnel-model-21>.
[I-D.ietf-ccamp-wson-tunnel-model]
Lee, Y., Zheng, H., Guo, A., Lopez, V., King, D., Yoon, B.
Y., and R. Vilalta, "A Yang Data Model for WSON Tunnel",
Work in Progress, Internet-Draft, draft-ietf-ccamp-wson-
tunnel-model-09, 9 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
wson-tunnel-model-09>.
Tan, et al. Expires 1 June 2025 [Page 19]
Internet-Draft FCAPS with Optical ACTN November 2024
[I-D.ietf-ivy-network-inventory-topology]
Wu, B., Zhou, C., Wu, Q., and M. Boucadair, "A Network
Inventory Topology Model", Work in Progress, Internet-
Draft, draft-ietf-ivy-network-inventory-topology-00, 7
August 2024, <https://datatracker.ietf.org/doc/html/draft-
ietf-ivy-network-inventory-topology-00>.
[I-D.ietf-ivy-network-inventory-yang]
Yu, C., Belotti, S., Bouquier, J., Peruzzini, F., and P.
Bedard, "A Base YANG Data Model for Network Inventory",
Work in Progress, Internet-Draft, draft-ietf-ivy-network-
inventory-yang-04, 5 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-ivy-
network-inventory-yang-04>.
[I-D.ietf-nmop-network-incident-yang]
Hu, T., Contreras, L. M., Wu, Q., Davis, N., and C. Feng,
"A YANG Data Model for Network Incident Management", Work
in Progress, Internet-Draft, draft-ietf-nmop-network-
incident-yang-02, 10 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-nmop-
network-incident-yang-02>.
[I-D.ietf-opsawg-collected-data-manifest]
Claise, B., Quilbeuf, J., Lopez, D., Martinez-Casanueva,
I. D., and T. Graf, "A Data Manifest for Contextualized
Telemetry Data", Work in Progress, Internet-Draft, draft-
ietf-opsawg-collected-data-manifest-05, 21 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
collected-data-manifest-05>.
[I-D.ietf-teas-yang-te]
Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I.
Bryskin, "A YANG Data Model for Traffic Engineering
Tunnels, Label Switched Paths and Interfaces", Work in
Progress, Internet-Draft, draft-ietf-teas-yang-te-37, 9
October 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-teas-yang-te-37>.
[I-D.palmero-ivy-dmalmo]
Palmero, M., Brockners, F., Kumar, S., Cardona, C., and D.
Lopez, "Data Model for Asset Lifecycle Management and
Operations", Work in Progress, Internet-Draft, draft-
palmero-ivy-dmalmo-02, 8 July 2024,
<https://datatracker.ietf.org/doc/html/draft-palmero-ivy-
dmalmo-02>.
Tan, et al. Expires 1 June 2025 [Page 20]
Internet-Draft FCAPS with Optical ACTN November 2024
[I-D.palmero-ivy-ps-almo]
Palmero, M., Brockners, F., Kumar, S., Cardona, C., and D.
Lopez, "Asset Lifecycle Management and Operations: A
Problem Statement", Work in Progress, Internet-Draft,
draft-palmero-ivy-ps-almo-02, 8 July 2024,
<https://datatracker.ietf.org/doc/html/draft-palmero-ivy-
ps-almo-02>.
[I-D.yu-ccamp-optical-resource-pm-yang]
Yu, C., Peruzzini, F., Yanlei, Z., Busi, I., Guo, A.,
Lopez, V., and XingZhao, "A YANG Data Model for Optical
Resource Performance Monitoring", Work in Progress,
Internet-Draft, draft-yu-ccamp-optical-resource-pm-yang-
03, 4 March 2024, <https://datatracker.ietf.org/doc/html/
draft-yu-ccamp-optical-resource-pm-yang-03>.
[I-D.yu-ccamp-te-fgnm-yang]
Yu, C., XingZhao, Tan, Davis, N., and D. King, "YANG Data
Models for Transport TE FGNM Extension Model", Work in
Progress, Internet-Draft, draft-yu-ccamp-te-fgnm-yang-01,
8 July 2024, <https://datatracker.ietf.org/doc/html/draft-
yu-ccamp-te-fgnm-yang-01>.
[I-D.zheng-ccamp-client-pm-yang]
Yu, C., Zheng, H., Busi, I., Yanlei, Z., Lopez, V., and O.
G. de Dios, "A YANG Data Model for Client Signal
Performance Monitoring", Work in Progress, Internet-Draft,
draft-zheng-ccamp-client-pm-yang-11, 4 September 2024,
<https://datatracker.ietf.org/doc/html/draft-zheng-ccamp-
client-pm-yang-11>.
[M-3041] International Telecommunication Union - Telecommunication
Standardization Sector, "ITU-T M.3041, Framework of smart
operation, management and maintenance.",
Recommendation ITU-T Recommendation M.3041, 13 February
2020, <https://www.itu.int/rec/T-REC-M.3041-202002-I/en>.
[M-3060] International Telecommunication Union - Telecommunication
Standardization Sector, "ITU-T M.3060, Principles for the
Management of Next Generation Networks.",
Recommendation ITU-T Recommendation M.3060/Y.2401, 22
March 2006,
<https://www.itu.int/rec/T-REC-M.3060-200603-I/en>.
[MTOSI] TeleManagment Forum (TM Forum), "The Multi-Technology
Operations System Interface.", Web page TM Forum,
<https://www.tmforum.org/mtosi/>.
Tan, et al. Expires 1 June 2025 [Page 21]
Internet-Draft FCAPS with Optical ACTN November 2024
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.
[RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Gonzalez de Dios, "YANG Data Model for Traffic
Engineering (TE) Topologies", RFC 8795,
DOI 10.17487/RFC8795, August 2020,
<https://www.rfc-editor.org/info/rfc8795>.
[RFC9094] Zheng, H., Lee, Y., Guo, A., Lopez, V., and D. King, "A
YANG Data Model for Wavelength Switched Optical Networks
(WSONs)", RFC 9094, DOI 10.17487/RFC9094, August 2021,
<https://www.rfc-editor.org/info/rfc9094>.
[RFC9417] Claise, B., Quilbeuf, J., Lopez, D., Voyer, D., and T.
Arumugam, "Service Assurance for Intent-Based Networking
Architecture", RFC 9417, DOI 10.17487/RFC9417, July 2023,
<https://www.rfc-editor.org/info/rfc9417>.
[RFC9418] Claise, B., Quilbeuf, J., Lucente, P., Fasano, P., and T.
Arumugam, "A YANG Data Model for Service Assurance",
RFC 9418, DOI 10.17487/RFC9418, July 2023,
<https://www.rfc-editor.org/info/rfc9418>.
Authors' Addresses
Yinxia Tan
China Unicom
Email: [email protected]
Tan, et al. Expires 1 June 2025 [Page 22]
Internet-Draft FCAPS with Optical ACTN November 2024
Xing Zhao
CAICT
Email: [email protected]
Chaode Yu
Huawei Technologies
Email: [email protected]
Daniel King (editor)
Old Dog Consulting
Email: [email protected]
Adrian Farrel (editor)
Old Dog Consulting
Email: [email protected]
Tan, et al. Expires 1 June 2025 [Page 23]