Internet-Draft | Performance Monitoring YANG | October 2022 |
Yu | Expires 27 April 2023 | [Page] |
- Workgroup:
- CCAMP Working Group
- Internet-Draft:
- draft-yu-performance-monitoring-yang-00
- Published:
- Intended Status:
- Standards Track
- Expires:
A YANG Data Model for Optical Performance Monitoring
Abstract
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.¶
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 27 April 2023.¶
Copyright Notice
Copyright (c) 2022 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.¶
1. 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:¶
[I-D.ietf-teas-actn-pm-telemetry-autonomics] 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 [I-D.ietf-teas-actn-pm-telemetry-autonomics].¶
[I-D.ietf-opsawg-yang-vpn-service-pm] 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.¶
[I-D.zheng-ccamp-client-pm-yang] 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).¶
1.1. Terminology and Notations
Refer to [RFC7446] and [RFC7581] for the key terms used in this document. The following terms are defined in [RFC7950] and are not redefined here:¶
The following terms are defined in [RFC6241] and are not redefined here:¶
The following terms are defined in [RFC8454] and are not redefined here:¶
//To Be Added: some explanation of performance indicator¶
1.2. 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 [RFC8340].¶
1.3. 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 | [RFC6991] |
RFC Editor Note: Please replace XXXX with the RFC number assigned to this document.¶
2. YANG Data Model for Optical Performance Monitoring
According to the business requirements stated in [TMF-518], 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.¶
2.1. 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.¶
2.2. 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).¶
2.3. 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.¶
3. Performance Indicator Introduction
//To Be Added¶
7. Manageability Considerations
<Add any manageability considerations>¶
8. Security Considerations
<Add any security considerations>¶
9. IANA Considerations
<Add any IANA considerations>¶
10. References
10.1. Normative References
- [RFC6991]
- Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, , <https://www.rfc-editor.org/info/rfc6991>.
- [RFC7950]
- Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, , <https://www.rfc-editor.org/info/rfc7950>.
- [RFC8340]
- Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, , <https://www.rfc-editor.org/info/rfc8340>.
- [TMF-518]
- TM Forum (TMF), "TMF-518_RPM (Resource Performance Management) – DDP BA", TMF 518_RPM (Version 2.1) , , <https://www.tmforum.org/resources/collection/mtosi-4-0/>.
10.2. Informative References
- [I-D.ietf-opsawg-yang-vpn-service-pm]
- Wu, B., Wu, Q., Boucadair, M., de Dios, O. G., and B. Wen, "A YANG Model for Network and VPN Service Performance Monitoring", Work in Progress, Internet-Draft, draft-ietf-opsawg-yang-vpn-service-pm-14, , <https://www.ietf.org/archive/id/draft-ietf-opsawg-yang-vpn-service-pm-14.txt>.
- [I-D.ietf-teas-actn-pm-telemetry-autonomics]
- Lee, Y., Dhody, D., Vilalta, R., King, D., and D. Ceccarelli, "YANG models for Virtual Network (VN)/TE Performance Monitoring Telemetry and Scaling Intent Autonomics", Work in Progress, Internet-Draft, draft-ietf-teas-actn-pm-telemetry-autonomics-09, , <https://www.ietf.org/archive/id/draft-ietf-teas-actn-pm-telemetry-autonomics-09.txt>.
- [I-D.zheng-ccamp-client-pm-yang]
- 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-06, , <https://www.ietf.org/archive/id/draft-zheng-ccamp-client-pm-yang-06.txt>.
- [RFC6241]
- Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, , <https://www.rfc-editor.org/info/rfc6241>.
- [RFC7446]
- Lee, Y., Ed., Bernstein, G., Ed., Li, D., and W. Imajuku, "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks", RFC 7446, DOI 10.17487/RFC7446, , <https://www.rfc-editor.org/info/rfc7446>.
- [RFC7581]
- Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and J. Han, "Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks", RFC 7581, DOI 10.17487/RFC7581, , <https://www.rfc-editor.org/info/rfc7581>.
- [RFC8454]
- Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. Yoon, "Information Model for Abstraction and Control of TE Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, , <https://www.rfc-editor.org/info/rfc8454>.
Acknowledgments
This document was prepared using kramdown.¶