Internet-Draft | PM YANG for Client Signal | March 2024 |
Yu, et al. | Expires 5 September 2024 | [Page] |
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 note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://haomianzheng.github.io/ccamp-client-pm-yang/draft-zheng-ccamp-client-pm-yang.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-zheng-ccamp-client-pm-yang/.¶
Discussion of this document takes place on the Common Control and Measurement Plane Working Group mailing list (mailto:ccamp@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ccamp/. Subscribe at https://www.ietf.org/mailman/listinfo/ccamp/.¶
Source for this draft and an issue tracker can be found at https://github.com/haomianzheng/ccamp-client-pm-yang.¶
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 5 September 2024.¶
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.¶
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 [I-D.ietf-ccamp-otn-tunnel-model] and WSON in [I-D.ietf-ccamp-wson-tunnel-model]. Client-layers are modeled as client signals according to the client-signal identities specified in [I-D.ietf-ccamp-layer1-types]. These client signals can be configured to existing tunnels via the client signal configuration model specified in [I-D.ietf-ccamp-client-signal-yang].¶
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.¶
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 [RFC8340]. 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.¶
[I-D.ietf-ccamp-client-signal-yang] 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 [I-D.ietf-ccamp-client-signal-yang] 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 [I-D.ietf-teas-actn-pm-telemetry-autonomics]. 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 [I-D.www-bess-yang-vpn-service-pm]. 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).¶
[I-D.draft-yu-ccamp-optical-resource-pm-yang]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.¶
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 [ITU-T_G.709] 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.¶
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.¶
For the mechanism of performance monitoring, there have been a lot of discussion in [ITU-T_G.709], [ITU-T_G.874], [ITU-T_G.875], [ITU-T_G.7710], [ITU-T_G.7718], and [ITU-T_G.7719]. 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.¶
According to the description of section 15.8.2.1.6 in [ITU-T_G.709], 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.¶
The operation, administration and maintenance protocols and data models have been specified in [RFC8531] 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 maintainence Maintenance Domain (MD), Maintenance Association (MA), and Maintenance End Points (MEP), can be found in [RFC8531] as well.¶
This document requests IANA to register the following URIs in the "ns" subregistry within the "IETF XML Registry" [RFC3688]. Following the format in [RFC3688], the following registrations are requested.¶
URI: urn:ietf:params:xml:ns:yang:ietf-service-pm Registrant Contact: The IESG XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-eth-service-oam Registrant Contact: The IESG XML: N/A; the requested URI is an XML namespace.¶
This document requests IANA to register the following YANG modules in the "IANA Module Names" [RFC6020]. Following the format in [RFC6020], the following registrations are requested:¶
name: ietf-service-pm namespace: urn:ietf:params:xml:ns:yang:ietf-service-pm prefix: svc-pm reference: RFC XXXX (This document) name: ietf-eth-service-oam namespace: urn:ietf:params:xml:ns:yang:ietf-eth-service-oam prefix: eth-oam reference: RFC XXXX (This document)¶
RFC Editor: Please replace XXXX with the RFC number assigned to this document.¶
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 [I-D.ietf-ccamp-client-signal-yang] also applies to this document.¶
The YANG module defined in this document can be accessed via the RESTCONF protocol defined in [RFC8040], or maybe via the NETCONF protocol [RFC6241].¶
TODO acknowledge.¶