CCAMP Working Group H. Zheng
Internet-Draft I. Busi
Intended status: Standards Track Huawei Technologies
Expires: January 14, 2021 Y. Zheng
China Unicom
July 13, 2020

A YANG Data Model for Client Signal Performance Monitoring
draft-zheng-ccamp-client-pm-yang-02

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.

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 January 14, 2021.

Copyright Notice

Copyright (c) 2020 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 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

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]. 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 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. The OAM mechanism, can be configured together with the performance monitoring model.

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.

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. 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).

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. OAM Configuration

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.

6. YANG Model for Performance Monitoring

6.1. YANG Tree for Performance Monitoring


module: ietf-service-pm
  +--rw performance-monitoring
     +--rw service-pm* [service-name]
        +--rw service-name               union
        +--rw task-pm-enable?            boolean
        +--rw granularity?               identityref
        +--rw performance-data-config* [parameter-name]
        |  +--rw parameter-name    identityref
        |  +--rw measure-method?   identityref
        +--ro service-pm-state
           +--ro oam-state
           |  +--ro cc-state    enumeration
           |  +--ro lm-state?   enumeration
           |  +--ro dm-state?   enumeration
           +--ro performance-data* [parameter-name]
           |  +--ro parameter-name     identityref
           |  +--ro parameter-value* [index]
           |     +--ro index                uint64
           |     +--ro value                performance-parameter-value
           |     +--ro value-unit           string
           |     +--ro value-description?   string
           |     +--ro start-time?          yang:date-and-time
           |     +--ro end-time?            yang:date-and-time
           +--ro monitor-state       identityref
           +--ro error-info
           |  +--ro error-code?      uint32
           |  +--ro error-message?   string
           +--ro alarm
              +--ro status?   identityref

 
    

6.2. YANG Tree for OAM Configuration


module: ietf-eth-service-oam
  augment /svc-pm:performance-monitoring/svc-pm:service-pm:
    +--rw oam-config
       +--rw source
       |  +--rw md-name?         string
       |  +--rw ma-name?         string
       |  +--rw ma-level?        string
       |  +--rw meg-id?          string
       |  +--rw meg-level?       string
       |  +--rw mep-id?          uint8
       |  +--rw remote-mep-id?   uint8
       +--rw destination
       |  +--rw md-name?         string
       |  +--rw ma-name?         string
       |  +--rw ma-level?        string
       |  +--rw meg-id?          string
       |  +--rw meg-level?       string
       |  +--rw mep-id?          uint8
       |  +--rw remote-mep-id?   uint8
       +--rw cc-interval?   identityref
       +--rw lm-interval?   identityref
       +--rw dm-interval?   identityref
 
    

7. YANG Code for Performance Monitoring

7.1. The Performance Monitoring YANG Code

  
<CODE BEGINS> file "ietf-service-pm@2020-07-13.yang"
module ietf-service-pm {
  yang-version 1.1;

  namespace "urn:ietf:params:xml:ns:yang:ietf-service-pm";
  prefix "svc-pm";

  import ietf-eth-tran-service {
    prefix "ethtsvc";
  }

  import ietf-yang-types {
    prefix "yang";
  }
  
  import ietf-trans-client-service {
    prefix "clntsvc";
  }

  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);
    ";

  description
    "This module defines the performance monitoring for Ethernet
     services. The model fully conforms to the Network Management
     Datastore Architecture (NMDA).

     Copyright (c) 2020 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 2020-07-13 {
    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 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 {
        mandatory true;
        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";
          } 
        }
      
        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;
          }
        }
      }

      container service-pm-state {
        config false;
        description
          "The state of service performance monitoring.";

        container oam-state {
          leaf cc-state {
            mandatory true;
            type enumeration {
              enum up;
              enum down;
            } 
          }
          leaf lm-state {
            type enumeration {
              enum up;
              enum down;
            } 
          }
          leaf dm-state {
            type enumeration {
              enum up;
              enum down;
            } 
          }
        }

        list performance-data{
          key parameter-name;
          description "The list of performance under monitor.";
          uses service-performance-monitor-set;
        }
        
        leaf monitor-state {
          mandatory true;
          type identityref {
            base monitoring-state;
          }
          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. ";
          }
        }
        
      }
    }
  }
  
}

<CODE ENDS>
 
    

7.2. The OAM Configuration YANG Code

  
<CODE BEGINS> file "ietf-eth-service-oam@2020-07-13.yang"
module ietf-eth-service-oam {
  yang-version 1.1;

  namespace "urn:ietf:params:xml:ns:yang:ietf-eth-service-oam";
  prefix "etht-oam";

  import ietf-eth-tran-service {
    prefix "ethtsvc";
  }
  
  import ietf-service-pm {
    prefix "svc-pm";
  }
  
  import ietf-trans-client-service {
    prefix "clntsvc";
  }
  
  import ietf-network {
    prefix nw;
  }

  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);
    ";

  description
    "This module defines the performance monitoring for Ethernet
     services OAM. The model fully conforms to the Network Management
     Datastore Architecture (NMDA).

     Copyright (c) 2020 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 2020-07-13 {
    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;
      }
      container destination {
        uses mep-config;
      }
      
      uses interval-config;
  }
  
  grouping interval-config {
    leaf cc-interval {
      description "Continuity check interval";
      type identityref {
        base interval-type;
      }
    }

    leaf lm-interval {
      description "Loss measurement interval";
      type identityref {
        base interval-type;
      }
    }

    leaf dm-interval {
      description "Delay measurement interval";
      type identityref {
        base interval-type;
      }
    }
  }
  
  grouping mep-config {
    leaf md-name {
     type string;
     description
       "maintenance domain";
    } 
    leaf ma-name {
     type string;
     description
       "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;
    }

    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 {
      uses eth-service-oam-config;
    }
  }
  
  grouping errors {
    leaf error-code {
      type uint32;
    }
    
    leaf error-message {
      type string;
    }
  }
<CODE ENDS>
 
    

8. 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-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 registers following YANG modules in the YANG Module Names registry [RFC7950].

      
         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)
      
    

9. Manageability Considerations

TBD.

10. 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].

11. Contributors

Chaode YU
Huawei Technologies,
Email: yuchaode@huawei.com

12. References

12.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", Internet-Draft draft-ietf-ccamp-client-signal-yang-02, May 2020.
[I-D.ietf-ccamp-layer1-types] Zheng, H. and I. Busi, "A YANG Data Model for Layer 1 Types", Internet-Draft draft-ietf-ccamp-layer1-types-06, May 2020.
[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", Internet-Draft draft-ietf-teas-actn-pm-telemetry-autonomics-02, March 2020.
[I-D.www-bess-yang-vpn-service-pm] WU, Q., Boucadair, M., Dios, O., Wen, B., Liu, C. and H. Xu, "A YANG Model for Network and VPN Service Performance Monitoring", Internet-Draft draft-www-bess-yang-vpn-service-pm-06, April 2020.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J. and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011.
[RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016.
[RFC8040] Bierman, A., Bjorklund, M. and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017.
[RFC8531] Kumar, D., Wu, Q. and Z. Wang, "Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols", RFC 8531, DOI 10.17487/RFC8531, April 2019.

12.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", Internet-Draft draft-ietf-ccamp-otn-tunnel-model-10, March 2020.
[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", Internet-Draft draft-ietf-ccamp-wson-tunnel-model-05, March 2020.
[RFC8340] Bjorklund, M. and L. Berger, "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018.

Authors' Addresses

Haomian Zheng Huawei Technologies H1, Xiliu Beipo Village, Songshan Lake, Dongguan, Guangdong 523808 China EMail: zhenghaomian@huawei.com
Italo Busi Huawei Technologies Italy EMail: Italo.Busi@huawei.com
Yanlei Zheng China Unicom China EMail: zhengyanlei@chinaunicom.cn