]> Huawei Technologies

yuchaode@huawei.com

Huawei Technologies

H1, Huawei Xiliu Beipo Village, Songshan Lake Dongguan Guangdong 523808 China zhenghaomian@huawei.com

Huawei Technologies

Italy italo.busi@huawei.com

China Unicom

China zhengyanlei@chinaunicom.cn

Nokia

Spain victor.lopez@nokia.com

Telefonica

Spain oscar.gonzalezdedios@telefonica.com

Routing CCAMP Working Group 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. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Common Control and Measurement Plane Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Client-layer network and server-layer network have been respectively modeled to allow the tunnels carrying the client traffic. Server-layers are modeled as tunnels with various switching technologies, such as OTN in and WDM in . Client-layers are modeled as client signals according to the client-signal identities specified in . These client signals can be configured to existing tunnels via the client signal configuration model specified in . In the network operation, the operator is interested in monitoring their instantiated client signal over tunnels. The objective of such monitoring is to complete timely adjustment once there is abnormal statistic which may result in failure of the client signal. The parameters specified in the performance monitoring model can be collected for the operation need. The OAM mechanism, can be configured together with the performance monitoring model.

Terminology and Notations A simplified graphical representation of the data model is used in this document. The meaning of the symbols in the YANG data tree presented later in this document is defined in . They are provided below for reference.

• Brackets "[" and "]" enclose list keys.
• Abbreviations before data node names: "rw" means configuration (read-write) and "ro" state data (read-only).
• Symbols after data node names: "?" means an optional node, "!" means a presence container, and "*" denotes a list and leaf-list.
• Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":").
• Ellipsis ("...") stands for contents of subtrees that are not shown.

Model Relationship has specified the two models for the client signal configuration, module ietf-trans-client-service for transparent client service and module ietf-eth-tran-service for Ethernet service. Basically the client signal types in this document is consistent with ietf-eth-tran-types, and focus on different functionality. On the perspective of operator, the modules in can be used to configure the service given any underlay tunnels, while the operation about monitoring the performance on given service can be achieved by using the model in this document. Consideration on Key Performance Information (KPI) monitoring for Virtual Network (VN) and tunnels has been specified in . Usually the monitoring on the tunnels are the VNs should be separately deployed for the network operation, but it is possible to have common parameters that are both needed for the VN/TE and the configured services. Common types are imported in both modules. VPN-level parameters and their monitoring have been defined in . This module focus on the performance on the topology at different layer or the overlay topology between VPN sites. On the other hand, this document is focusing on the performance of the service configured between Customer Ends (CE). is aimed to provide a performance management approach on the resource level in a traditional way. This resource stands for physical resource, such as board, port etc., or logical resource, e.g. TTP etc. The management object is different with this document. But there is some relationship between these two documents. The PM data of client signal can be collected on some specific resources. And usually there would be some additional calculation needed for client signal PM data. This collection mechanism, including which resource should be adopted, when these resource PM data should be collected and the calculation method are the focus of this document.

Use Cases of Performance Management of Client Signal

Automatic Service Acceptance Test After the private line service is provisioned on the network, usually it needs to take an acceptance test before it is delivered to the user. This acceptance test includes some connectivity validation, such as traffic test, to make sure that it's reachable from the source access port to the destination access port. The engineers need to take tester onsite and run it manually. It is time consuming especially when the private line service is an inter-domain service which the source and destination could be in different cities. It is excellent if this acceptance test can be operated automatically by interface instead of being done manually. For some scenarios, it is feasible to achieve this target. For example, we can test the latency of private line service to replace the connectivity test. The section of 15.8.2.1.6 in defines the mechanism of delay (latency) measurement mechanism of ODU path. If the latency value could be returned successfully through the ODU path, then there will not be interruption on the ODU path.

Private Line Service SLA Assurance SLA (Service Level Agreement) is an agreement aligned by the service provider and the user. This agreement defines service type, quality of service etc. which the service provider guarantees to the user. Transport private line service has got the advantage of hard isolation, large bandwidth, low latency and high reliability. So usually it is more expensive than the other fixed broadband services. From the user's perspective, they also have some special demand for the private line service. For example, some industry customers, e.g. stock and futures industry customers who have a lot of high-frequency trading requirement, have extremely high requirement on latency. The customers from government and security assurance department have extremely high requirement on service reliability. The Private line service users expect to monitor service performance indicators to ensure that their private line services are cost-effective and meet SLA requirements. And for the service provider, continuous monitoring of key services' performance and proactive O&M can reduce customers' complaint and ensure SLA delivery. The performance data can even be used for precision marketing. For example, if the bandwidth usage of a user's private line is too high for a long time, the system can remind the user to adjust the bandwidth in a timely manner.

Architecture of Private Line SLA Assurance

Consideration on Monitoring Parameters For the mechanism of performance monitoring, there have been a lot of discussion in , , , , , and . This document would like to reference the definition of ITU-T instead of restarting new discussion. But for the service level's performance parameter, there is not enough definition both in ITU-T and IETF, this document will focus on how to define a service level performance parameter. Considering there could be a lot of new service performance parameters in the future, it is also suggested to define a generic data model to conduct the service performance parameters.

Service Latency Measurement According to the description of section 15.8.2.1.6 in , PM overhead can be used to measure the delay (latency) of ODU path. Simply speaking, in the latency measurement process, the PM overhead is generated and delivered on the source port and looped back at the sink port. By observing the 0-1 change of PM overhead on the source port, it is able to obtain latency data of E2E ODU path. For intra-domain services, the domain controller can differentiate who is the source port and who is the sink port, and orchestrate the whole measurement process. But for inter-domain service, it is hard for the domain controller to know the access port in its domain is a source or sink port. Therefore an orchestrator above is needed to do this orchestration. The orchestrator specify one of the domain's access port performs as the sink port and the other domain's access port performs as a source port. To be noted that, it is important specify the source and sink ports. Especially the sink port should be specified at first. It is not allowed to launch latency measurement from the source port until the sink port has finished its configuration (loop-back operation). Otherwise the overhead will not be transmitted back to the source port, so that no latency data will be obtained.

Inter-domain service latency measurement

OAM Configuration The operation, administration and maintenance protocols and data models have been specified in for the connection-oriented network. The model is referenced in this work to develop an Ethernet-specific OAM models, which is augmenting the service performance monitoring data model. The definitions of OAM terminologies, such as Maintenance Domain (MD), Maintenance Association (MA), and Maintenance End Points (MEP), can be found in as well.

YANG Model for Performance Monitoring

YANG Tree for Performance Monitoring

YANG Tree for Performance Monitoring

YANG Tree for OAM Configuration

YANG Tree for OAM Configuration /nw:networks/network/node/node-id +--ro output +--ro oam-list* [] +--ro node-id? | -> /nw:networks/network/node/node-id +--ro mep-config-list* [md-name ma-name meg-id mep-id] +--ro md-name string +--ro ma-name string +--ro ma-level? string +--ro meg-id string +--ro meg-level? string +--ro mep-id uint8 +--ro remote-mep-id? uint8 ]]>

YANG Code for Performance Monitoring

The Performance Monitoring YANG Code

Performance Monitoring YANG Code ID-draft editor: Chaode Yu (yuchaode@huawei.com) Haomian Zheng (zhenghaomian@huawei.com); Italo Busi (italo.busi@huawei.com); Yanlei Zheng (zhengyanlei@chinaunicom.cn); Victor Lopez (victor.lopez@nokia.com); Oscar Gonzalez de Dios(oscar.gonzalezdedios@telefonica.com); "; description "This module defines the performance monitoring for Ethernet services. The model fully conforms to the Network Management Datastore Architecture (NMDA). Copyright (c) 2021 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 Simplified 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."; revision 2024-03-04 { description "Initial version"; reference "ADD REFERENCE HERE"; } typedef performance-parameter-value { type union { type uint32; type uint64; type decimal64 { fraction-digits 6; } type string; } description "A performance parameter value."; } grouping service-performance-monitor-set{ description "the set of parameter name, value and description."; leaf parameter-name{ type identityref { base performance-parameter-type; } description "The name of parameters to be monitored. For example, latency, Bit Error Rate, Bandwidth and so on."; } list parameter-value { key index; description "The table of values of the performance and their descriptions."; leaf index { type uint64; description "Used for list index"; } leaf value { type performance-parameter-value; mandatory true; description "The value of the parameter. "; } leaf value-unit { type string; mandatory true; description "The value unit of the parameter. For example, second, minute and so on."; } leaf value-description{ type string; description "The description of previous value. "; } leaf start-time { type yang:date-and-time; description "The time stamp when the parameter is started."; } leaf end-time { type yang:date-and-time; description "The time stamp when the parameter is ended."; } } } identity performance-parameter-type { description "Base type of the performance parameter being monitored."; } identity near-frame-loss { base performance-parameter-type; description "Near frame loss, using one-way eth loss measure, the sampling point is the MEP."; } identity far-frame-loss { base performance-parameter-type; description "Far frame loss, using one-way eth loss measure, the sampling point is the MEP."; } identity one-way-delay { base performance-parameter-type; description "One way delay."; } identity two-way-delay { base performance-parameter-type; description "Two way delay."; } identity receive-packets { base performance-parameter-type; description "Total number of received packets."; } identity transmit-packets { base performance-parameter-type; description "Total number of transmitted packets."; } identity ingress-bandwidth { base performance-parameter-type; description "Current bandwidth usage of the ingress traffic."; } identity egress-bandwidth { base performance-parameter-type; description "Current bandwidth usage of the egress traffic."; } identity alarm-status { description "indicates whether there is alarm or not"; } identity alarm { base alarm-status; description "There is one or multiple alarms from the monitor. "; } identity no-alarm { base alarm-status; description "There is no alarms from the monitor. "; } identity monitoring-state { description "The state of performance monitoring. "; } identity monitoring { base monitoring-state; description "The Ethernet client signal is under monitoring. "; } identity monitor-finished { base monitoring-state; description "The monitoring of Ethernet client signal is finished. "; } identity monitor-failed { base monitoring-state; description "The monitoring of Ethernet client signal is failed. "; } identity granularity-type { description "Monitoring granularity"; } identity granularity-1min { base granularity-type; description "1 minute"; } identity granularity-15min { base granularity-type; description "15 minutes"; } identity granularity-24h { base granularity-type; description "24 hours"; } identity measure-method { description "Measure method."; } identity measure-by-loopback { base measure-method; description "Loopback measure method."; } identity measure-at-ingress { base measure-method; description "Ingress measure method."; } container performance-monitoring { description "This part is for performance monitoring. "; list service-pm { key "service-name"; description "The list of service to be monitored."; leaf service-name { type union { type leafref { path "/ethtsvc:etht-svc/ethtsvc:etht-svc-instances" + "/ethtsvc:etht-svc-name"; } type leafref { path "/clntsvc:client-svc/clntsvc:client-svc-instances" + "/clntsvc:client-svc-name"; } } mandatory true; description "The name of service."; } leaf task-pm-enable { type boolean; description "Indicate whether the performance monitoring is enable or not."; } leaf granularity { type identityref { base granularity-type; } description "Monitoring granularity"; } list performance-data-config { key parameter-name; description "Specify the performance parameters to be queried"; leaf parameter-name { type identityref { base performance-parameter-type; } description "The name of parameters to be monitored. For example, latency, BER, Bandwidth and so on."; } leaf measure-method { type identityref { base measure-method; } description "Measure Methods."; } } container service-pm-state { config false; description "The state of service performance monitoring."; container oam-state { description "the state of OAM. "; leaf cc-state { type enumeration { enum up { description "up"; } enum down { description "down"; } } mandatory true; description "The state of continuity check."; } leaf lm-state { type enumeration { enum up { description "up"; } enum down { description "down"; } } description "The state of loss measurement."; } leaf dm-state { type enumeration { enum up { description "up"; } enum down{ description "down"; } } description "The state of delay measurement."; } } list performance-data{ key parameter-name; description "The list of performance under monitor."; uses service-performance-monitor-set; } leaf monitor-state { type identityref { base monitoring-state; } mandatory true; description "The status of performance monitoring. "; } container error-info { description "Describe the error message."; leaf error-code { type uint32; description "The code of error."; } leaf error-message { type string; description "The message of error."; } } container alarm { description "To retrieve the Alarm during performance Monitoring."; leaf status { type identityref { base alarm-status; } description "The status of the alarm. "; } } } } } } ]]>

The OAM Configuration YANG Code

OAM Configuration YANG Code ID-draft editor: Chaode Yu (yuchaode@huawei.com) Haomian Zheng (zhenghaomian@huawei.com); Italo Busi (italo.busi@huawei.com); Yanlei Zheng (zhengyanlei@chinaunicom.cn); Victor Lopez (victor.lopez@nokia.com); Oscar Gonzalez de Dios(oscar.gonzalezdedios@telefonica.com); "; description "This module defines the performance monitoring for Ethernet services OAM. The model fully conforms to the Network Management Datastore Architecture (NMDA). Copyright (c) 2021 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 Simplified 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."; revision 2024-03-04 { description "Initial version"; reference "ADD REFERENCE HERE"; } identity interval-type { description "Time interval"; } identity interval-3p33ms { base interval-type; description "3.33 milliseconds"; } identity interval-10ms { base interval-type; description "10 milliseconds"; } identity interval-100ms { base interval-type; description "100 milliseconds"; } identity interval-1s { base interval-type; description "1 second"; } identity interval-10s { base interval-type; description "10 seconds"; } identity interval-1m { base interval-type; description "1 minute"; } identity interval-10m { base interval-type; description "10 minutes"; } grouping eth-service-oam-config { container source { uses mep-config; description "OAM MEP configuration on source node."; } container destination { uses mep-config; description "OAM MEP configuration on destination node."; } uses interval-config; description "OAM configuration on Eth services."; } grouping interval-config { description "OAM Interval Configuration."; leaf cc-interval { type identityref { base interval-type; } description "Continuity check interval."; } leaf lm-interval { type identityref { base interval-type; } description "Loss measurement interval."; } leaf dm-interval { type identityref { base interval-type; } description "Delay measurement interval."; } } grouping mep-config { description "OAM MEP Configuration."; leaf md-name { type string; description "Name of Maintenance Domain."; } leaf ma-name { type string; description "Name of Maintenance Domain. An maintenance association(MA) is a part of an MD. An MD can be divided into one or more MAs. "; } leaf ma-level { type string; description "Maintenance Association Level."; } leaf meg-id { type string; description "Comply with Y.1731 term, mapping with 802.lag MA name."; } leaf meg-level { type string; description "Mapping with 802.lag MA level."; } leaf mep-id { type uint8; description "0 if Abnormal"; } leaf remote-mep-id { type uint8; description "The remote MEP ID must be specified."; } } augment "/svc-pm:performance-monitoring/svc-pm:service-pm" { description "Augment with additional parameters required for Ethernet OAM"; container oam-config { description "OAM configuration container."; uses eth-service-oam-config; } } grouping errors { description "The grouping of error information."; leaf error-code { type uint32; description "The error code."; } leaf error-message { type string; description "The error message."; } } /* * Operations */ rpc configure-oam { description "Deliver OAM configurations. "; input { list oam-config-list { key "service-name"; description "The request list of service oam to be configured."; leaf service-name { type union { type leafref { path "/ethtsvc:etht-svc/ethtsvc:etht-svc-instances" + "/ethtsvc:etht-svc-name"; } type leafref { path "/clntsvc:client-svc/clntsvc:client-svc-instances" + "/clntsvc:client-svc-name"; } } mandatory true; description "The name of service."; } uses eth-service-oam-config; } } output { list oam-config-list { key "service-name"; description "The OAM configuration list. "; leaf service-name { type union { type leafref { path "/ethtsvc:etht-svc/ethtsvc:etht-svc-instances" + "/ethtsvc:etht-svc-name"; } type leafref { path "/clntsvc:client-svc/clntsvc:client-svc-instances" + "/clntsvc:client-svc-name"; } } mandatory true; description "The name of service."; } } leaf result { type enumeration { enum success { description "success"; } enum failure { description "failure"; } } description "Result of OAM configuration."; } uses errors; } } rpc delete-oam-configurations { description "Delete OAM configurations. "; input { list service-list { key "service-name"; leaf service-name { type union { type leafref { path "/ethtsvc:etht-svc/ethtsvc:etht-svc-instances" + "/ethtsvc:etht-svc-name"; } type leafref { path "/clntsvc:client-svc/clntsvc:client-svc-instances" + "/clntsvc:client-svc-name"; } } mandatory true; description "The name of service."; } description "The list of service."; } } output { list oam-config-list { key "service-name"; leaf service-name { type union { type leafref { path "/ethtsvc:etht-svc/ethtsvc:etht-svc-instances" + "/ethtsvc:etht-svc-name"; } type leafref { path "/clntsvc:client-svc/clntsvc:client-svc-instances" + "/clntsvc:client-svc-name"; } } mandatory true; description "The name of service."; } leaf result { type enumeration { enum success { description "success"; } enum failure { description "failure"; } } description "The result of OAM deletion."; } uses errors; description "The list of service."; } } } rpc get-node-eth-oam-configurations { description "Get the Eth node OAM configuration info."; input { leaf-list te-node-list { type leafref { path "/nw:networks/nw:network/nw:node/nw:node-id"; } description "Node identifier. Must be same in the topology."; } } output { list oam-list { leaf node-id { type leafref { path "/nw:networks/nw:network/nw:node/nw:node-id"; } description "The node identifier."; } list mep-config-list { key "md-name ma-name meg-id mep-id"; uses mep-config; description "The list of MEP configuration."; } description "The list of OAM."; } } } } ]]>

IANA Considerations This document requests IANA to register the following URIs in the "ns" subregistry within the "IETF XML Registry" . Following the format in , the following registrations are requested. This document requests IANA to register the following YANG modules in the "IANA Module Names" . Following the format in , the following registrations are requested: RFC Editor: Please replace XXXX with the RFC number assigned to this document.

Manageability Considerations TBD.

Security Considerations The data following the model defined in this document is exchanged via, for example, the interface between an orchestrator and a transport network controller. The security concerns mentioned in also applies to this document. The YANG module defined in this document can be accessed via the RESTCONF protocol defined in , or maybe via the NETCONF protocol .

References Normative References International Telecommunication Union International Telecommunication Union International Telecommunication Union International Telecommunication Union International Telecommunication Union International Telecommunication Union Huawei Technologies Huawei Technologies This document defines a collection of common common data types, identities, and groupings in the YANG data modeling language. These derived common common data types, identities, and groupings are intended to be imported by modules that model Layer 1 configuration and state capabilities. The Layer 1 types are representative of Layer 1 client signals applicable to transport networks, such as Optical Transport Networks (OTN). The Optical Transport Network (OTN) data structures are included in this document as Layer 1 types. Huawei Technologies Futurewei Huawei Technologies Cisco Huawei Technologies A transport network is a server-layer network to provide connectivity services to its client. The topology and tunnel information in the transport layer has already been defined by generic Traffic- engineered models and technology-specific models (e.g., OTN, WSON). However, how the client signals are accessing to the network has not been described. These information is necessary to both client and provider. This draft describes how the client signals are carried over transport network and defines YANG data models which are required during configuration procedure. More specifically, several client signal (of transport network) models including ETH, STM-n, FC and so on, are defined in this draft. Huawei Lancaster University CTTC Huawei Technologies Cisco This document provides YANG data models that describe the performance monitoring parameters and scaling intent mechanisms for Traffic Engineering (TE) tunnels and Virtual Networks (VNs). Their performance monitoring parameters are exposed as the key telemetry data for tunnels and VNs. 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 Orange Telefonica Comcast China Unicom China Telecom The data model defined in RFC8345 introduces vertical layering relationships between networks that can be augmented to cover network/service topologies. This document defines a YANG model for both Network Performance Monitoring and VPN Service Performance Monitoring that can be used to monitor and manage network performance on the topology at higher layer or the service topology between VPN sites. This model is designed as an augmentation to the network topology YANG data model defined in RFC8345. Huawei Technologies TIM China Unicom Huawei Technologies Futurewei Technologies Nokia CAICT 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 current or historic performance data retrieval. This data model should be used in the northbound of PNC. This document presents a base YANG data model for connection-oriented Operations, Administration, and Maintenance (OAM) protocols. It provides a technology-independent abstraction of key OAM constructs for such protocols. The model presented here can be extended to include technology-specific details. This guarantees uniformity in the management of OAM protocols and provides support for nested OAM workflows (i.e., performing OAM functions at different levels through a unified interface). The YANG data model in this document conforms to the Network Management Datastore Architecture. This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). 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] Informative References Huawei Technologies Huawei Technologies Nokia Nokia CAICT This document describes the YANG data model for tunnels in OTN TE networks. The model can be used to do the configuration in order to establish the tunnel in OTN network. This work is independent with the control plane protocols. Futurewei Technologies Nokia Individual Naudit HPCN Universidad Autonoma de Madrid This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels and Label Switched Paths (LSPs) in Optical Networks (Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks). The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). 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.

Acknowledgments TODO acknowledge.