CCAMP Working Group H. Zheng
Internet-Draft I. Busi
Intended status: Standards Track Huawei Technologies
Expires: May 7, 2020 Y. Zheng
China Unicom
November 4, 2019
A YANG Data Model for Client Signal Performance Monitoring
draft-zheng-ccamp-client-pm-yang-00
Abstract
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. The module carefully maps to relevant
performance monitoring standards.
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 May 7, 2020.
Copyright Notice
Copyright (c) 2019 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
Zheng, et al. Expires May 7, 2020 [Page 1]
Internet-Draft PM YANG for Client Signal November 2019
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Notations . . . . . . . . . . . . . . . . . . 3
3. Model Relationship . . . . . . . . . . . . . . . . . . . . . 3
4. Consideration on Monitoring Parameters . . . . . . . . . . . 4
5. YANG Model for Client Signal Performance Monitoring . . . . . 4
5.1. YANG Tree for Ethernet Performance Monitoring . . . . . . 4
5.2. YANG Tree for Transparent Client Signal Performance
Monitoring . . . . . . . . . . . . . . . . . . . . . . . 4
6. YANG Code for Performance Monitoring . . . . . . . . . . . . 5
6.1. The ETH Service Performance Monitoring YANG Code . . . . 5
6.2. The Transparent Client Signals Performance Monitoring
YANG Code . . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Manageability Considerations . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. 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 [I-D.ietf-ccamp-otn-tunnel-model] and
[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].
In the network operation, the operator is interested in monitoring
for their instantiated client signal over tunnels. The objective for
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.
Zheng, et al. Expires May 7, 2020 [Page 2]
Internet-Draft PM YANG for Client Signal November 2019
2. 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 [RFC8340]. They are
provided below for reference.
o Brackets "[" and "]" enclose list keys.
o Abbreviations before data node names: "rw" means configuration
(read-write) and "ro" state data (read-only).
o Symbols after data node names: "?" means an optional node, "!"
means a presence container, and "*" denotes a list and leaf-list.
o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not
shown.
3. Model Relationship
[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. A common types module, ietf-eth-tran-types, has
also been defined for the common use for service configuration.
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
Zheng, et al. Expires May 7, 2020 [Page 3]
Internet-Draft PM YANG for Client Signal November 2019
focusing on the performance of the service configured between
Customer Ends (CE), as described in
[I-D.ietf-ccamp-client-signal-yang].
4. Consideration on Monitoring Parameters
There can be multiple groups of parameters for monitoring, such as
latency, bit error rate (BER). Some of these parameters are layer-
dependent, for example, packet loss is only applicable in packet
networks are won't be neede for layer 1 OTN and layer 0 WSON.
This document starts with the specification of the latency
measurement for both Ethernet service and client signal service. In
the future version additional parameters would be added into the data
model in the same approach as the latency in the current version. A
candidate list of parameters to be monitored include: Latency, Packet
Loss, Bit Error Rate (BER), Jitter, Bandwidth, Byte/Packet number and
so on.
5. YANG Model for Client Signal Performance Monitoring
5.1. YANG Tree for Ethernet Performance Monitoring
module: ietf-eth-service-pm
+--rw performance-monitoring
+--rw service-pm* [service-name]
+--rw service-name leafref
+--rw pm-enable? boolean
+--rw latency-monitoring
| +--rw latency-measure-enable? boolean
+--ro service-pm-state
+--ro start-time? yang:date-and-time
+--ro last-update-time? yang:date-and-time
+--ro latency? uint32
+--ro error-message? string
+--ro service-oper-status? identityref
5.2. YANG Tree for Transparent Client Signal Performance Monitoring
Zheng, et al. Expires May 7, 2020 [Page 4]
Internet-Draft PM YANG for Client Signal November 2019
module: ietf-trans-client-svc-pm
+--rw performance-monitoring
+--rw service-pm* [service-name]
+--rw service-name leafref
+--rw pm-enable? boolean
+--rw latency-monitoring
| +--rw latency-measure-enable? boolean
+--ro service-pm-state
+--ro start-time? yang:date-and-time
+--ro last-update-time? yang:date-and-time
+--ro latency? uint32
+--ro error-message? string
+--ro service-oper-status? identityref
6. YANG Code for Performance Monitoring
6.1. The ETH Service Performance Monitoring YANG Code
<CODE BEGINS> file "ietf-eth-service-pm@2019-11-04.yang"
module ietf-eth-service-pm {
/* TODO: FIXME */
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-eth-service-pm";
prefix "ethsvc-pm";
import ietf-eth-tran-service {
prefix "ethtsvc";
}
import ietf-eth-tran-types {
prefix "etht-types";
}
import ietf-yang-types {
prefix "yang";
}
import ietf-te-types {
prefix "te-types";
}
organization
"Internet Engineering Task Force (IETF) CCAMP WG";
Zheng, et al. Expires May 7, 2020 [Page 5]
Internet-Draft PM YANG for Client Signal November 2019
contact
"
WG List: <mailto:ccamp@ietf.org>
ID-draft editor:
Haomian Zheng (zhenghaomian@huawei.com);
Italo Busi (italo.busi@huawei.com);
Yanlei Zheng (zhengyanlei@chinaunicom.cn);
";
description
"This module defines the performance monitoring for Ethernet
services. The model fully conforms to the Network Management
Datastore Architecture (NMDA).
Copyright (c) 2019 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 2019-11-04 {
description
"Initial version";
reference
"ADD REFERENCE HERE";
}
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 leafref {
path "/ethtsvc:etht-svc/ethtsvc:etht-svc-instances/ethtsvc:etht-svc-name";
}
description "The name of service.";
}
Zheng, et al. Expires May 7, 2020 [Page 6]
Internet-Draft PM YANG for Client Signal November 2019
leaf pm-enable {
type boolean;
description
"Indicate whether the performance monitoring
is enable or not.";
}
container latency-monitoring {
description
"To monitor the latency of service.";
leaf latency-measure-enable {
type boolean;
description
"Indicate whether the latency measurement
is enable or not.";
}
}
container service-pm-state {
config false;
description
"The state of service performance monitoring.";
leaf start-time {
type yang:date-and-time;
description
"The time stamp when the service is started.";
}
leaf last-update-time {
type yang:date-and-time;
description
"The time stamp when the service is last updated.";
}
leaf latency {
type uint32;
units microsecond;
description
"The latency of service.";
}
leaf error-message {
type string;
description
"The message of error.";
}
leaf service-oper-status {
Zheng, et al. Expires May 7, 2020 [Page 7]
Internet-Draft PM YANG for Client Signal November 2019
type identityref {
base te-types:tunnel-state-type;
}
description
"The operational status of the services.";
}
}
}
}
}
<CODE ENDS>
6.2. The Transparent Client Signals Performance Monitoring YANG Code
<CODE BEGINS> file "ietf-trans-client-svc-pm@2019-11-04.yang"
module ietf-trans-client-svc-pm {
/* TODO: FIXME */
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-trans-client-svc-pm";
prefix "clntsvc-pm";
import ietf-trans-client-service {
prefix "clntsvc";
}
import ietf-yang-types {
prefix "yang";
}
import ietf-te-types {
prefix "te-types";
}
organization
"Internet Engineering Task Force (IETF) CCAMP WG";
contact
"
WG List: <mailto:ccamp@ietf.org>
ID-draft editor:
Haomian Zheng (zhenghaomian@huawei.com);
Italo Busi (italo.busi@huawei.com);
Yanlei Zheng (zhengyanlei@chinaunicom.cn);
";
Zheng, et al. Expires May 7, 2020 [Page 8]
Internet-Draft PM YANG for Client Signal November 2019
description
"This module defines the performance monitoring for transparent
client signals. The model fully conforms to the Network Management
Datastore Architecture (NMDA).
Copyright (c) 2019 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 2019-11-04 {
description
"Initial version";
reference
"ADD REFERENCE HERE";
}
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 leafref {
path "/clntsvc:client-svc/clntsvc:client-svc-instances/clntsvc:client-svc-name";
}
description "The name of service.";
}
leaf pm-enable {
type boolean;
description
"Indicate whether the performance monitoring
is enable or not.";
}
container latency-monitoring {
description
"To monitor the latency of service.";
Zheng, et al. Expires May 7, 2020 [Page 9]
Internet-Draft PM YANG for Client Signal November 2019
leaf latency-measure-enable {
type boolean;
description
"Indicate whether the latency measurement
is enable or not.";
}
}
container service-pm-state {
config false;
description
"The state of service performance monitoring.";
leaf start-time {
type yang:date-and-time;
description
"The time stamp when the service is started.";
}
leaf last-update-time {
type yang:date-and-time;
description
"The time stamp when the service is last updated.";
}
leaf latency {
type uint32;
units microsecond;
description
"The latency of service.";
}
leaf error-message {
type string;
description
"The message of error.";
}
leaf service-oper-status {
type identityref {
base te-types:tunnel-state-type;
}
description
"The operational status of the services.";
}
Zheng, et al. Expires May 7, 2020 [Page 10]
Internet-Draft PM YANG for Client Signal November 2019
}
}
}
}
<CODE ENDS>
7. IANA Considerations
It is proposed that IANA should assign new URIs from the "IETF XML
Registry" [RFC3688] as follows:
URI: urn:ietf:params:xml:ns:yang:ietf-eth-service-pm
Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-trans-client-svc-pm
Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace.
This document registers following YANG modules in the YANG Module
Names registry [RFC7950].
name: ietf-eth-service-pm
namespace: urn:ietf:params:xml:ns:yang:ietf-eth-service-pm
prefix: ethsvc-pm
reference: RFC XXXX (This document)
name: ietf-trans-client-svc-pm
namespace: urn:ietf:params:xml:ns:yang:ietf-trans-client-svc-pm
prefix: clntsvc-pm
reference: RFC XXXX (This document)
8. Manageability Considerations
TBD.
Zheng, et al. Expires May 7, 2020 [Page 11]
Internet-Draft PM YANG for Client Signal November 2019
9. 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
[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].
10. Contributors
Chaode YU
Huawei Technologies,
Email: yuchaode@huawei.com
11. References
11.1. Normative References
[I-D.ietf-ccamp-client-signal-yang]
Zheng, H., Guo, A., Busi, I., Snitser, A., Lazzeri, F.,
Xu, Y., Zhao, Y., Liu, X., and G. Fioccola, "A YANG Data
Model for Transport Network Client Signals", draft-ietf-
ccamp-client-signal-yang-01 (work in progress), November
2019.
[I-D.ietf-ccamp-layer1-types]
Zheng, H. and I. Busi, "A YANG Data Model for Layer 1
Types", draft-ietf-ccamp-layer1-types-03 (work in
progress), November 2019.
[I-D.ietf-teas-actn-pm-telemetry-autonomics]
Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D.,
and D. Ceccarelli, "YANG models for VN/TE Performance
Monitoring Telemetry and Scaling Intent Autonomics",
draft-ietf-teas-actn-pm-telemetry-autonomics-01 (work in
progress), October 2019.
[I-D.www-bess-yang-vpn-service-pm]
Wang, Z., WU, Q., Even, R., Wen, B., Liu, C., and H. Xu,
"A YANG Model for Network and VPN Service Performance
Monitoring", draft-www-bess-yang-vpn-service-pm-04 (work
in progress), November 2019.
Zheng, et al. Expires May 7, 2020 [Page 12]
Internet-Draft PM YANG for Client Signal November 2019
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
11.2. Informative References
[I-D.ietf-ccamp-otn-tunnel-model]
Zheng, H., Busi, I., Belotti, S., Lopezalvarez, V., and Y.
Xu, "OTN Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel-
model-09 (work in progress), November 2019.
[I-D.ietf-ccamp-wson-tunnel-model]
Lee, Y., Zheng, H., Guo, A., Lopezalvarez, V., King, D.,
Yoon, B., and R. Vilata, "A Yang Data Model for WSON
Tunnel", draft-ietf-ccamp-wson-tunnel-model-04 (work in
progress), September 2019.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
Authors' Addresses
Haomian Zheng
Huawei Technologies
H1-1-A043S Huawei Industrial Base, Songshanhu
Dongguan, Guangdong 523808
China
Email: zhenghaomian@huawei.com
Zheng, et al. Expires May 7, 2020 [Page 13]
Internet-Draft PM YANG for Client Signal November 2019
Italo Busi
Huawei Technologies
Email: Italo.Busi@huawei.com
Yanlei Zheng
China Unicom
Email: zhengyanlei@chinaunicom.cn
Zheng, et al. Expires May 7, 2020 [Page 14]