]> Huawei Technologies

yuchaode@huawei.com

CCAMP Working Group This document defines a YANG data model for performance Monitoring in optical networks which provides the functionalities of performance monitoring task management, TCA (Threshold Crossing Alert) configuration and performance data retrieval.

Introduction Performance monitoring is a basic function of optical networks management. With it, operators can proactively detect the running state of devices, identify major risks in advanced and avoid users' complaints. As before, TMF has defined interfaces for performance management through traditional protocols, such as CORBA and MTOSI. With the development of SDN technologies and the using of RESTCONF interfaces, it becomes a widespread requirement to use RESTCONF protocol to support performance monitoring. Using RESTCONF does not mean changing existing performance monitoring requirements or scenarios. On the contrary, since O&M is very important, many operators' O&M departments tend to be conservative. They are fear of introducing issues into their network due to the protocol changes and O&M habits changes. Therefore, our document prefers to use the new protocol to support legacy functionality. Traditional performance management involves control of performance monitoring, setting collectors on monitored objects, and obtaining performance data in different periods. The data can be real-time data on devices, quasi-real-time data processed by domain controllers, and historical performance data. TCA can be also configured by performance monitoring tasks. The explanation of performance monitoring indicator would also be an important part of this document, especially the missing optical-specific indicators of TMF. Currently, there are some existing documents related to performance monitoring in IETF, but there is no overlap with our current work. For example: provides a YANG data model that describes performance monitoring and scaling intent mechanisms for TE-Tunnels and Virtual Networks(VNs). VN is determinate to be used in CMI (CNC-MDSC Interface) level and TE tunnel is more service or connection related. Our data model is proposed to be used in MPI (MDSC-PNC Interface) level and performance monitoring is performed on physical network resources, such as network element, board, fiber, port or ODUk channels, which are not included in . defines a YANG data model for performance monitoring of both network topology layer and overlay VPN service topology layer. VPN service is more IP-specific and not adopted in Optical domain. And the data model in this document is augmenting network model. If the client wants to retrieve performance data of a link by RESTCONF, the URL would be probably same with the URL of topology retrieval. This may need some special mechanisms to make the client and server differentiate the using scenarios. This is not quite compliance with the O&M habits of Optical technology. provides a performance monitoring YANG data model on client signal level. It is also not operated on resource level which is not compliance with the existing O&M habits. This performance monitoring solution is more user-oriented and can be used for more automatic O&M scenarios in the future. However, although there is no complete closed-loop O&M solution at the service layer and is not accepted by all operators' O&M departments, resource-based performance monitoring is still required. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA).

Terminology and Notations Refer to and for the key terms used in this document. The following terms are defined in and are not redefined here: client server augment data model data node The following terms are defined in and are not redefined here: configuration data state data The following terms are defined in and are not redefined here: CMI MPI MDSC CNC PNC //To Be Added: some explanation of performance indicator

Tree Diagram A simplified graphical representation of the data model is used in Section 3 of this document. The meaning of the symbols in these diagrams are defined in .

Prefix in Data Node Names In this document, names of data nodes and other data model objects are prefixed using the standard prefix associated with the corresponding YANG imported modules, as shown in the following table. Prefix Yang Module Reference pm ietf-performance-monitoring RFCXXXX pm-types ietf-performance-monitoring-types RFCXXXX yang ietf-yang-types RFC Editor Note: Please replace XXXX with the RFC number assigned to this document.

YANG Data Model for Optical Performance Monitoring According to the business requirements stated in , resource performance management requirements include: The Interface shall support the control of performance monitoring (PM) in the network. This includes PM control, e.g., the enabling and disabling of PM collection and Threshold Crossing Alerts (TCAs) control, e.g., the enabling and disabling of TCA generation. The Interface shall support the retrieval of current and historical performance measurements for network resources. The Interface shall support the distribution of TCAs to subscribed OSs. For these requirements of PM, there are three group of interfaces are defined in TMF, including PerformanceManagementControl, PerformanceManagementRetrieval and ThresholdCrossingAlertControlm.

PerformanceManagementControl The functionalities of this group of interfaces are: clearPerformanceMonitoringData: The NML-EML Interface shall allow the NMS ability to clear (reset) the PM Data for a list of TPs or for a list of Network Element (NE)s. disablePerformanceMonitoringData: The NML-EML Interface shall allow the NMS to disable the collection of PM data on a list of TP names basis or for a list of Managed Element (ME)s. enablePerformanceMonitoringData: The NML-EML Interface shall allow the NMS to enable the collection of PM data on a list of TP names basis or for a list of Managed Element (ME)s.

PerformanceManagementRetrieval The functionalities of this group of interfaces are: getAllCurrentPerformanceMonitoringData: The NML-EML Interface shall allow the NMS to request the current PM measurement for a list of Termination Point (TP)s. getAllPerformanceMonitoringPoints: The NML-EML Interface shall allow the NMS to retrieve the names of all the Performance Monitoring Point (PMP)s supported by a Managed Element (ME) or a Termination Point (TP) for an NMS specified ME or TP name. getHistoryPerformanceMonitoringData: The NML-EML Interface shall allow the NMS to request the delivery of a historical PM data file for a specified set of Termination Point (TP)s and PM parameters to an external data server for further evaluation. getHoldingTime: The NML-EML Interface shall allow the NMS to query the EMS for the number of supported previous or history day-registers and 15minute-registers. getMePerformanceMonitoringCapabilities: The NML-EML Interface shall allow the NMS to retrieve the set of supported PM parameters for an NMS specified Managed Element (ME).

ThresholdCrossingAlertControl The functionalities of this group of interfaces are: createTcaParameterProfile: The NML-EML Interface shall allow the NMS to create an Threshold Crossing Alert (TCA) Parameter Profile in the EMS. deleteTcaParameterProfile: The NML-EML Interface shall allow the NMS to delete an Threshold Crossing Alert (TCA) Parameter Profile given the NMS specified TCA Parameter Profile name from the EMS. enableThresholdCrossingAlert: The NML-EML Interface shall allow the NMS to enable the notification of Threshold Crossed Alerts on a list of TPs or for a list of Managed Element (ME)s. disableThresholdCrossingAlert: The NML-EML Interface shall allow the NMS to disable the notification of Threshold Crossed Alerts on a list of TPs or for a list of Managed Element (ME)s. getAllTcaParameterProfiles: The NML-EML Interface shall allow the NMS to retrieve the attributes of all the Threshold Crossing Alert (TCA) Parameter Profiles that are being managed by the EMS. getTcaParameterProfile: The NML-EML Interface shall allow the NMS to retrieve the attributes of all the Threshold Crossing Alert (TCA) Parameter Profile given an NMS specified TCA Parameter Profile name. setTcaParameterProfile: The NML-EML Interface shall allow the NMS to modify an Threshold Crossing Alert (TCA) Parameter Profile in the EMS.

Performance Indicator Introduction //To Be Added

Optical Performance Monitoring Tree Diagram

YANG Model for Optical Performance Monitoring

WG List: Editor: Chaode Yu "; description "This module defines a model for optical performance monitoring. The model fully conforms to the Network Management Datastore Architecture (NMDA). Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; revision 2022-10-24 { description "Initial revision."; reference "draft-yu-performance-monitoring-yang-00"; } container monitor-tasks { description "the root node."; list monitor-task { key resource; description "monitoring task list"; uses task-instance-grouping; } } grouping task-instance-grouping { description "none"; leaf resource { type union { type instance-identifier { require-instance false; } type yang:object-identifier; type string; type yang:uuid; } description "the identifier of network resource which is monitored."; } leaf resource-type { type identityref { base pm-types:resource-type; } description "the type of resource, such as NE, board or port"; } leaf task-name { type string; description "the name of monitoring task"; } leaf task-status { type enumeration { enum running; enum suspended; enum abnormal; } config false; description "the status of monitoring task."; } uses task-configuration-grouping; } grouping task-configuration-grouping { description "none"; container task-cfg { description "Configuration of the monitoring task"; leaf period { type identityref { base pm-types:period; } description "this period is used to indicate how long is the monitoring task"; } container indicators { description "performance indicators"; list indicator { key indicator-name; description "none"; uses indicator-grouping; } } } } grouping indicator-grouping { description "none"; leaf indicator-name { type string; description "performance indicator's name"; } container tca { //TO BE ADDED description "configuration of TCA"; } } rpc get-all-current-pm-data { description "This RPC is used to retrieve current PM data."; input { leaf-list resources { type leafref { path "/pm:monitor-tasks/pm:monitor-task/pm:resource"; } description "resouces' identifier"; } } output { container pm-data { description "none"; list pm-data-list { key resource; description "none"; uses pm-data-instance-grouping; } } } } rpc get-history-pm-data { description "This RPC is used to retrieve historic PM data."; input { leaf-list resources { type leafref { path "/pm:monitor-tasks/pm:monitor-task/pm:resource"; } description "identifier of resources"; } leaf start-time { type yang:date-and-time; description "the starttime of performance data needed to be retrieved"; } leaf end-time { type yang:date-and-time; description "the endtime of performance data needed to be retrieved"; } } output { container pm-data { description "none"; list pm-data-list { key resource; description "none"; uses pm-data-instance-grouping; } } } } grouping pm-data-instance-grouping { description "none"; leaf resource { type leafref { path "/pm:monitor-tasks/pm:monitor-task/pm:resource"; } description "the identifier of network resource which is monitored."; } leaf collect-time { type yang:date-and-time; description "the time of this data is collected"; } leaf resource-type { type identityref { base pm-types:resource-type; } description "the type of resource, such as NE, board or port"; } container indicator-data { description "none"; list indicator-data-list { key indicator-name; description "none"; uses indicator-data-instance-grouping; } } } grouping indicator-data-instance-grouping { description "none"; leaf indicator-name { type string; description "name of performance data indicator"; } leaf indicator-value { type string; description "value of performance data"; } leaf indicator-value-unit { type string; description "unit of performance data value"; } } } ]]>

YANG Model for Optical Performance Monitoring Types

WG List: Editor: Chaode Yu "; description "This module defines types model for optical performance monitoring which will be imported by ietf-performance-monitoring data model. The model fully conforms to the Network Management Datastore Architecture (NMDA). Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; revision 2022-10-24 { description "Initial revision."; reference "draft-yu-performance-monitoring-yang-00"; } identity resource-type { description "this is the base type of all the rerource type"; } identity network-element { base resource-type; description "NE resource type"; } identity board { base resource-type; description "board resource type"; } identity port { base resource-type; description "port resource type"; } identity period { description "this is the base type of all the performace monitoring priod type."; } identity period-15-minutes { base period; description "the during of monitoring task will be repeated at every 15 minutes"; } identity period-24-hours { base period; description "the during of monitoring task will be repeated at every 24 hours"; } } ]]>

Manageability Considerations <Add any manageability considerations>

Security Considerations <Add any security considerations>

IANA Considerations <Add any IANA considerations>

TM Forum (TMF) YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. Samsung Electronics Huawei Technologies CTTC Lancaster University Ericsson This document provides YANG data models that describe performance monitoring parameters and scaling intent mechanisms for TE-tunnels and Virtual Networks (VNs). There performance monitoring parameters are exposed as the key telemetry data for tunnels and VN. The models presented in this document allow customers to subscribe to and monitor the key performance data of the TE-tunnel or the VN. The models also provide customers with the ability to program autonomic scaling intent mechanisms on the level of TE-tunnel as well as VN. Huawei Huawei Orange Telefonica Comcast The data model for network topologies defined in RFC 8345 introduces vertical layering relationships between networks that can be augmented to cover network and service topologies. This document defines a YANG module for performance monitoring (PM) of both underlay networks and overlay VPN services that can be used to monitor and manage network performance on the topology of both layers. Huawei Technologies Huawei Technologies China Unicom Nokia Telefonica A transport network is a server-layer network to provide connectivity services to its client. Given the client signal is configured, the followup function for performance monitoring, such as latency and bit error rate, would be needed for network operation. This document describes the data model to support the performance monitoring functionalities. This document provides a model of information needed by the Routing and Wavelength Assignment (RWA) process in Wavelength Switched Optical Networks (WSONs). The purpose of the information described in this model is to facilitate constrained optical path computation in WSONs. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed. A Wavelength Switched Optical Network (WSON) requires certain key information fields be made available to facilitate path computation and the establishment of Label Switched Paths (LSPs). The information model described in "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks" (RFC 7446) shows what information is required at specific points in the WSON. Part of the WSON information model contains aspects that may be of general applicability to other technologies, while other parts are specific to WSONs.This document provides efficient, protocol-agnostic encodings for the WSON-specific information fields. It is intended that protocol- specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition, these encodings could be used by other mechanisms to convey this same information to a Path Computation Element (PCE). The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document provides an information model for Abstraction and Control of TE Networks (ACTN).

Acknowledgments This document was prepared using kramdown.