A YANG Data Model for Client Signal Performance Monitoring

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 and . Client-layers are modeled as client signals according to the client-signal identities specified in . 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.

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.

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 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), as described in .

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.

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"; contact " WG List: 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."; } 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 { type identityref { base te-types:tunnel-state-type; } description "The operational status of the services."; } } } } }

]]>


  

 
   
    
  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: 

      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 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.";
        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.";
        }
      }
    }
  }
}



]]>


 


 
 
  It is proposed that IANA should assign new URIs from the "IETF XML Registry"  as follows:
  
  
    
      
    
    
      
    
      
    
    
   
   This document registers following YANG modules in the YANG Module Names registry .
    
    
    
      
    
    
    
    
      
    
    

 
 

 
  
  TBD.
  
 
 

 
  
  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 . 
  

 
 


 

 

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