Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   None   Next  Group: LIME

RFC 8531

Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols

Pages: 54
Proposed STD
Errata
Part 1 of 3 – Pages 1 to 18
None   None   Next

Top   ToC   Page 1
Internet Engineering Task Force (IETF)                          D. Kumar
Request for Comments: 8531                                         Cisco
Category: Standards Track                                          Q. Wu
ISSN: 2070-1721                                                  M. Wang
                                                                  Huawei
                                                              April 2019


                      Generic YANG Data Model for
 Connection-Oriented Operations, Administration, and Maintenance (OAM)
                               Protocols

Abstract

   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.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8531.
Top   ToC   Page 2
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
   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.
Top   ToC   Page 3
Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   5
     2.1.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   6
     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   7
     2.3.  Tree Diagrams . . . . . . . . . . . . . . . . . . . . . .   7
   3.  Architecture of Generic YANG Data Model for Connection-
       Oriented OAM  . . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Overview of the Connection-Oriented OAM YANG Data Model . . .   8
     4.1.  Maintenance Domain (MD) Configuration . . . . . . . . . .   9
     4.2.  Maintenance Association (MA) Configuration  . . . . . . .  10
     4.3.  Maintenance End Point (MEP) Configuration . . . . . . . .  11
     4.4.  RPC Definitions . . . . . . . . . . . . . . . . . . . . .  11
     4.5.  Notifications . . . . . . . . . . . . . . . . . . . . . .  14
     4.6.  Monitor Statistics  . . . . . . . . . . . . . . . . . . .  14
     4.7.  OAM Data Hierarchy  . . . . . . . . . . . . . . . . . . .  14
   5.  OAM YANG Module . . . . . . . . . . . . . . . . . . . . . . .  19
   6.  Base Mode . . . . . . . . . . . . . . . . . . . . . . . . . .  42
     6.1.  MEP Address . . . . . . . . . . . . . . . . . . . . . . .  42
     6.2.  MEP ID for Base Mode  . . . . . . . . . . . . . . . . . .  42
     6.3.  Maintenance Association . . . . . . . . . . . . . . . . .  42
   7.  Connection-Oriented OAM YANG Data Model Applicability . . . .  43
     7.1.  Generic YANG Data Model Extension for TRILL OAM . . . . .  43
       7.1.1.  MD Configuration Extension  . . . . . . . . . . . . .  43
       7.1.2.  MA Configuration Extension  . . . . . . . . . . . . .  44
       7.1.3.  MEP Configuration Extension . . . . . . . . . . . . .  45
       7.1.4.  RPC Extension . . . . . . . . . . . . . . . . . . . .  46
     7.2.  Generic YANG Data Model Extension for MPLS-TP OAM . . . .  46
       7.2.1.  MD Configuration Extension  . . . . . . . . . . . . .  47
       7.2.2.  MA Configuration Extension  . . . . . . . . . . . . .  48
       7.2.3.  MEP Configuration Extension . . . . . . . . . . . . .  48
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  49
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  50
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  50
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  50
     10.2.  Informative References . . . . . . . . . . . . . . . . .  51
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  53
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  53
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  54
Top   ToC   Page 4
1.  Introduction

   Operations, Administration, and Maintenance (OAM) are important
   networking functions that allow operators to:

   1.  monitor network communications (i.e., reachability verification
       and Continuity Check)

   2.  troubleshoot failures (i.e., fault verification and localization)

   3.  monitor service-level agreements and performance (i.e.,
       performance management)

   An overview of OAM tools is presented in [RFC7276].  Over the years,
   many technologies have developed similar tools for fault and
   performance management.

   The different sets of OAM tools may support both connection-oriented
   technologies or connectionless technologies.  In connection-oriented
   technologies, a connection is established prior to the transmission
   of data.  After the connection is established, no additional control
   information such as signaling or operations and maintenance
   information is required to transmit the actual user data.  In
   connectionless technologies, data is typically sent between
   communicating endpoints without prior arrangement, but control
   information is required to identify the destination (e.g., [G.800]).
   The YANG data model for OAM protocols using connectionless
   communications is specified in [RFC8532] and [IEEE802.1Q].

   Connectivity Fault Management as specified in [IEEE802.1Q] is a well-
   established OAM standard that is widely adopted for Ethernet
   networks.  ITU-T [G.8013], MEF Forum (MEF) Service OAM [MEF-17], MPLS
   Transport Profile (MPLS-TP) [RFC6371], and Transparent
   Interconnection of Lots of Links (TRILL) [RFC7455] all define OAM
   mechanisms based on the manageability framework of Connectivity Fault
   Management (CFM) [IEEE802.1Q].

   Given the wide adoption of the underlying OAM concepts defined in CFM
   [IEEE802.1Q], it is a reasonable choice to develop the unified
   management framework for connection-oriented OAM based on those
   concepts.  In this document, we take the CFM [IEEE802.1Q] model and
   extend it to a technology-independent framework and define the
   corresponding YANG data model accordingly.  The YANG data model
   presented in this document is the base model for connection-oriented
   OAM protocols and supports generic continuity check, connectivity
   verification, and path discovery (traceroute).  The generic YANG data
   model for connection-oriented OAM is designed to be extensible to
   other connection-oriented technologies.  Technology-dependent nodes
Top   ToC   Page 5
   and remote procedure call (RPC) commands are defined in technology-
   specific YANG data models, which use and extend the base model
   defined here.  As an example, Virtual eXtensible Local Area Network
   (VXLAN) uses the source UDP port number for flow entropy, while TRILL
   uses either (a) MAC addresses, (b) the VLAN tag or Fine-Grained
   Label, and/or (c) IP addresses for flow entropy in the hashing for
   multipath selection.  To capture this variation, corresponding YANG
   data models would define the applicable structures as augmentation to
   the generic base model presented here.  This accomplishes three
   goals: First, it keeps each YANG data model smaller and more
   manageable.  Second, it allows independent development of
   corresponding YANG data models.  Third, implementations can limit
   support to only the applicable set of YANG data models (e.g., TRILL
   RBridge may only need to implement the generic model and the TRILL
   YANG data model).

   The YANG data model presented in this document is generated at the
   management layer.  Encapsulations and state machines may differ
   according to each OAM protocol.  A user who wishes to issue a
   Continuity Check command or a Loopback or initiate a performance
   monitoring session can do so in the same manner, regardless of the
   underlying protocol or technology or specific vendor implementation.

   As an example, consider a scenario where connectivity from device A
   loopback to device B fails.  Between device A and B there are IEEE
   802.1 bridges a, b, and c.  Let's assume a, b, and c are using CFM
   [IEEE802.1Q].  A user, upon detecting the loopback failure, may
   decide to drill down to the lower level at different segments of the
   path and issue the corresponding fault verification (Loopback
   Message) and fault isolation (Looktrace Message) tools, using the
   same API.  This ability to drill down to a lower layer of the
   protocol stack at a specific segment within a path for fault
   localization and troubleshooting is referred to as "nested OAM
   workflow".  It is a useful concept that leads to efficient network
   troubleshooting and maintenance workflows.  The connection-oriented
   OAM YANG data model presented in this document facilitates that
   without needing changes to the underlying protocols.

   The YANG data model in this document conforms to the Network
   Management Datastore Architecture defined in [RFC8342].

2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.
Top   ToC   Page 6
   Many of the terms used in this document (including those set out in
   Sections Section 2.1 and Section 2.2) are specific to the world of
   OAM.  This document does not attempt to explain the terms but does
   assume that the reader is familiar with the concepts.  For a good
   overview, read [IEEE802.1Q].  For an example of how these OAM terms
   appear in IETF work, see [RFC6371].

2.1.  Abbreviations

   CCM   - Continuity Check Message [IEEE802.1Q]

   ECMP  - Equal-Cost Multipath

   LBM   - Loopback Message [IEEE802.1Q]

   LTM   - Linktrace Message [IEEE802.1Q]

   MP    - Maintenance Point [IEEE802.1Q]

   MEP   - Maintenance End Point [RFC7174] (also known as Maintenance
         association End Point [IEEE802.1Q] and MEG End Point [RFC6371])

   MIP   - Maintenance Intermediate Point [RFC7174] (also known as
         Maintenance domain Intermediate Point [IEEE802.1Q] and MEG
         Intermediate Point [RFC6371])

   MA    - Maintenance Association [IEEE802.1Q] [RFC7174]

   MD    - Maintenance Domain [IEEE802.1Q]

   MEG   - Maintenance Entity Group [RFC6371]

   MTV   - Multi-destination Tree Verification Message

   OAM   - Operations, Administration, and Maintenance [RFC6291]

   TRILL - Transparent Interconnection of Lots of Links [RFC6325]

   CFM   - Connectivity Fault Management [RFC7174] [IEEE802.1Q]

   RPC   - Remote Procedure Call

   CC    - Continuity Check [RFC7276]

   CV    - Connectivity Verification [RFC7276]
Top   ToC   Page 7
2.2.  Terminology

   Continuity Checks  - Continuity Checks are used to verify that a
      destination is reachable and therefore also are referred to as
      "reachability verification".

   Connectivity Verification  - Connectivity Verification is used to
      verify that a destination is connected.  It is also referred to as
      "path verification" and used to verify not only that the two MPs
      are connected, but also that they are connected through the
      expected path, allowing detection of unexpected topology changes.

   Proactive OAM  - Proactive OAM refers to OAM actions that are carried
      out continuously to permit proactive reporting of fault.  A
      proactive OAM method requires persistent configuration.

   On-demand OAM  - On-demand OAM refers to OAM actions that are
      initiated via manual intervention for a limited time to carry out
      diagnostics.  An on-demand OAM method requires only transient
      configuration.

2.3.  Tree Diagrams

   Tree diagrams used in this document follow the notation defined in
   [RFC8340].

3.  Architecture of Generic YANG Data Model for Connection-Oriented OAM

   In this document, we define a generic YANG data model for connection-
   oriented OAM protocols.  The YANG data model defined here is generic
   in a sense that other technologies can extend it for technology-
   specific needs.  The generic YANG data model for connection-oriented
   OAM acts as the root for other OAM YANG data models.  This allows
   users to traverse between different OAM protocols with ease through a
   uniform API set.  This also enables a nested OAM workflow.  Figure 1
   depicts the relationship of different OAM YANG data models to the
   Generic YANG Data Model for connection-oriented OAM.  The Generic
   YANG data model for connection-oriented OAM provides a framework
   where technology-specific YANG data models can inherit constructs
   from the base YANG data models without needing to redefine them
   within the sub-technology.
Top   ToC   Page 8
                            +-----------+
                            |Connection-|
                            | Oriented  |
                            |  generic  |
                            | OAM YANG  |
                            +-+-+-+-+-+-+
                                 |
                                 |
                                 |
         +------------------------------------------+
         |                       |                  |
     +-+-+-+-+-+          +-+-+-+-+-+          +-+-+-+-+-+
     | TRILL   |          | MPLS-TP |     . . .|  foo    |
     |OAM YANG |          |OAM YANG |          |OAM YANG |
     +-+-+-+-+-+          +-+-+-+-+-+          +-+-+-+-+-+
           |                    |                  |
           |                    |              +-+-+-+-+-+
           |                    |         . . .|  foo    |
           |                    |              |sub tech |
           |                    |              +-+-+-+-+-+
           |                    |                  |
           |                    |                  |
    +-------------------------------------------------------+
    |                      Uniform API                      |
    +-------------------------------------------------------+

   Figure 1: Relationship of OAM YANG Data Model to Generic (Base) YANG
                                Data Model

4.  Overview of the Connection-Oriented OAM YANG Data Model

   In this document, we adopt the concepts of the CFM [IEEE802.1Q] model
   and structure such that it can be adapted to different connection-
   oriented OAM protocols.

   At the top of the model is the Maintenance Domain.  Each Maintenance
   Domain is associated with a Maintenance Name and a Domain Level.

   Under each Maintenance Domain, there is one or more Maintenance
   Associations (MAs).  In TRILL, the MA can correspond to a Fine-
   Grained Label.

   Under each MA, there can be two or more MEPs (Maintenance End
   Points).  MEPs are addressed by their respective technology-specific
   address identifiers.  The YANG data model presented here provides
   flexibility to accommodate different addressing schemes.
Top   ToC   Page 9
   Commands are presented in the management protocol, which is
   orthogonal to the Maintenance Domain.  These are RPC commands, in
   YANG terms.  They provide uniform APIs for Continuity Check,
   connectivity verification, path discovery (traceroute), and their
   equivalents, as well as other OAM commands.

   The OAM entities in the generic YANG data model defined here will be
   either explicitly or implicitly configured using any of the OAM
   tools.  The OAM tools used here are limited to the OAM toolset
   specified in Section 5.1 of [RFC7276].  In order to facilitate a
   zero-touch experience, this document defines a default mode of OAM.
   The default mode of OAM is referred to as the "Base Mode" and
   specifies default values for each of the model's parameters, such as
   Maintenance Domain Level, Name of the Maintenance Association,
   Addresses of MEPs, and so on.  The default values of these depend on
   the technology.  Base Mode for TRILL is defined in [RFC7455].  Base
   Mode for other technologies and future extensions developed in IETF
   will be defined in their corresponding documents.

   It is important to note that no specific enhancements are needed in
   the YANG data model to support Base Mode.  Implementations that
   comply with this document use, by default, the data nodes of the
   applicable technology.  Data nodes of the Base Mode are read-only
   nodes.

4.1.  Maintenance Domain (MD) Configuration

   The container "domains" is the top-level container within the
   "gen-oam" module.  Within the container "domains", a separate list is
   maintained per MD.  The MD list uses the key "md-name-string" for
   indexing.  The "md-name-string" is a leaf and derived from type
   string.  Additional name formats as defined in [IEEE802.1Q], or other
   standards, can be included by association of the "md-name-format"
   with an identity-ref.  The "md-name-format" indicates the format of
   the augmented "md-name".  The "md-name" is presented as choice/case
   construct.  Thus, it is easily augmentable by derivative work.
Top   ToC   Page 10
       module: ietf-connection-oriented-oam
       +--rw domains
          +--rw domain* [technology md-name-string]
             +--rw technology        identityref
             +--rw md-name-string    md-name-string
             +--rw md-name-format?   identityref
             +--rw (md-name)?
             |  +--:(md-name-null)
             |     +--rw md-name-null? empty
             +--rw md-level?           md-level

             Snippet of Data Hierarchy Related to OAM Domains

4.2.  Maintenance Association (MA) Configuration

   Within a given Maintenance Domain, there can be one or more
   Maintenance Associations (MAs).  MAs are represented as a list and
   indexed by the "ma-name-string".  Similar to "md-name" defined
   previously, additional name formats can be added by augmenting the
   name-format "identity-ref" and adding applicable case statements to
   "ma-name".

      module: ietf-connection-oriented-oam
       +--rw domains
          +--rw domain* [technology md-name-string]
             .
             .
             +--rw mas
                +--rw ma* [ma-name-string]
                   +--rw ma-name-string          ma-name-string
                   +--rw ma-name-format?         identityref
                   +--rw (ma-name)?
                   |  +--:(ma-name-null)
                   |     +--rw ma-name-null?     empty

    Snippet of Data Hierarchy Related to Maintenance Associations (MAs)
Top   ToC   Page 11
4.3.  Maintenance End Point (MEP) Configuration

   Within a given Maintenance Association (MA), there can be one or more
   Maintenance End Points (MEPs).  MEPs are represented as a list within
   the data hierarchy and indexed by the key "mep-name".

      module: ietf-connection-oriented-oam
       +--rw domains
          +--rw domain* [technology md-name-string]
             +--rw technology                  identityref
             .
             .
             +--rw mas
                +--rw ma* [ma-name-string]
                   .
                   .
                   +--rw mep* [mep-name]
                   |  +--rw mep-name         mep-name
                   |  +--rw (mep-id)?
                   |  |  +--:(mep-id-int)
                   |  |     +--rw mep-id-int?      int32
                   |  +--rw mep-id-format?   identityref
                   |  +--rw (mep-address)?
                   |  |  +--:(mac-address)
                   |  |  |  +--rw mac-address?     yang:mac-address
                   |  |  +--:(ip-address)
                   |  |     +--rw ip-address?      inet:ip-address
                     .          .
                     .          .
                     .          .

     Snippet of Data Hierarchy Related to Maintenance End Point (MEP)

4.4.  RPC Definitions

   The RPC model facilitates issuing commands to a "server" (in this
   case, to the device that need to execute the OAM command) and
   obtaining a response.  The RPC model defined here abstracts OAM-
   specific commands in a technology-independent manner.

   There are several RPC commands defined for the purpose of OAM.  In
   this section, we present a snippet of the Continuity Check command
   for illustration purposes.  Please refer to Section 4.5 for the
   complete data hierarchy and Section 5 for the YANG module.
Top   ToC   Page 12
   module: ietf-connection-oriented-oam
       +--rw domains
             +--rw domain* [technology md-name-string]
             +--rw technology        identityref
       .
       .
   rpcs:
     +---x continuity-check {continuity-check}?
     |  +---w input
     |  |  +---w technology?             identityref
     |  |  +---w md-name-string -> /domains/domain/md-name-string
     |  |  +---w md-level?      -> /domains/domain/md-level
     |  |  +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
     |  |  +---w cos-id?                 uint8
     |  |  +---w ttl?                    uint8
     |  |  +---w sub-type?               identityref
     |  |  +---w source-mep?    -> /domains/domain/mas/ma/mep/mep-name
     |  |  +---w destination-mep
     |  |  |  +---w (mep-address)?
     |  |  |  |  +--:(mac-address)
     |  |  |  |  |  +---w mac-address?     yang:mac-address
     |  |  |  |  +--:(ip-address)
     |  |  |  |     +---w ip-address?      inet:ip-address
     |  |  |  +---w (mep-id)?
     |  |  |  |  +--:(mep-id-int)
     |  |  |  |     +---w mep-id-int?      int32
     |  |  |  +---w mep-id-format?   identityref
     |  |  +---w count?                  uint32
     |  |  +---w cc-transmit-interval?   time-interval
     |  |  +---w packet-size?            uint32
     |  +--ro output
     |     +--ro (monitor-stats)?
     |        +--:(monitor-null)
     |           +--ro monitor-null?   empty
     +---x continuity-verification {connectivity-verification}?
     |  +---w input
     |  |  +---w md-name-string -> /domains/domain/md-name-string
     |  |  +---w md-level?      -> /domains/domain/md-level
     |  |  +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
     |  |  +---w cos-id?            uint8
     |  |  +---w ttl?               uint8
     |  |  +---w sub-type?          identityref
     |  |  +---w source-mep?    -> /domains/domain/mas/ma/mep/mep-name
     |  |  +---w destination-mep
     |  |  |  +---w (mep-address)?
     |  |  |  |  +--:(mac-address)
     |  |  |  |  |  +---w mac-address?     yang:mac-address
     |  |  |  |  +--:(ip-address)
Top   ToC   Page 13
     |  |  |  |     +---w ip-address?      inet:ip-address
     |  |  |  +---w (mep-id)?
     |  |  |  |  +--:(mep-id-int)
     |  |  |  |     +---w mep-id-int?      int32
     |  |  |  +---w mep-id-format?   identityref
     |  |  +---w count?             uint32
     |  |  +---w interval?          time-interval
     |  |  +---w packet-size?       uint32
     |  +--ro output
     |     +--ro (monitor-stats)?
     |        +--:(monitor-null)
     |           +--ro monitor-null?   empty
     +---x traceroute {traceroute}?
        +---w input
        |  +---w md-name-string -> /domains/domain/md-name-string
        |  +---w md-level?      -> /domains/domain/md-level
        |  +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
        |  +---w cos-id?             uint8
        |  +---w ttl?                uint8
        |  +---w command-sub-type?   identityref
        |  +---w source-mep?    -> /domains/domain/mas/ma/mep/mep-name
        |  +---w destination-mep
        |  |  +---w (mep-address)?
        |  |  |  +--:(mac-address)
        |  |  |  |  +---w mac-address?     yang:mac-address
        |  |  |  +--:(ip-address)
        |  |  |     +---w ip-address?      inet:ip-address
        |  |  +---w (mep-id)?
        |  |  |  +--:(mep-id-int)
        |  |  |     +---w mep-id-int?      int32
        |  |  +---w mep-id-format?   identityref
        |  +---w count?              uint32
        |  +---w interval?           time-interval
        +--ro output
           +--ro response* [response-index]
              +--ro response-index     uint8
              +--ro ttl?               uint8
              +--ro destination-mep
              |  +--ro (mep-address)?
              |  |  +--:(mac-address)
              |  |  |  +--ro mac-address?     yang:mac-address
              |  |  +--:(ip-address)
              |  |     +--ro ip-address?      inet:ip-address
              |  +--ro (mep-id)?
              |  |  +--:(mep-id-int)
              |  |     +--ro mep-id-int?      int32
              |  +--ro mep-id-format?   identityref
              +--ro mip {mip}?
Top   ToC   Page 14
              |  +--ro interface?     if:interface-ref
              |  +--ro (mip-address)?
              |     +--:(mac-address)
              |     |  +--ro mac-address?   yang:mac-address
              |     +--:(ip-address)
              |        +--ro ip-address?    inet:ip-address
              +--ro (monitor-stats)?
                 +--:(monitor-null)
                    +--ro monitor-null?      empty

      Snippet of Data Hierarchy Related to RPC Call Continuity-Check

4.5.  Notifications

   Notification is sent upon detecting a defect condition and upon
   clearing a defect with a Maintenance Domain Name, MA Name, defect-
   type (the currently active defects), generating-mepid, and defect-
   message to indicate more details.

4.6.  Monitor Statistics

   Grouping for monitoring statistics is to be used by technology-
   specific YANG modules that augment the generic YANG data model to
   provide statistics due to proactive OAM-like Continuity Check
   Messages -- for example, CCM transmit, CCM receive, CCM error, etc.

4.7.  OAM Data Hierarchy

   The complete data hierarchy related to the connection-oriented OAM
   YANG data model is presented below.

 module: ietf-connection-oriented-oam
     +--rw domains
        +--rw domain* [technology md-name-string]
           +--rw technology        identityref
           +--rw md-name-string    md-name-string
           +--rw md-name-format?   identityref
           +--rw (md-name)?
           |  +--:(md-name-null)
           |     +--rw md-name-null?     empty
           +--rw md-level?         md-level
           +--rw mas
              +--rw ma* [ma-name-string]
                 +--rw ma-name-string    ma-name-string
                 +--rw ma-name-format?   identityref
                 +--rw (ma-name)?
                 |  +--:(ma-name-null)
                 |     +--rw ma-name-null?     empty
Top   ToC   Page 15
                 +--rw (connectivity-context)?
                 |  +--:(context-null)
                 |     +--rw context-null?     empty
                 +--rw cos-id?           uint8
                 +--rw cc-enable?        boolean
                 +--rw mep* [mep-name]
                 |  +--rw mep-name         mep-name
                 |  +--rw (mep-id)?
                 |  |  +--:(mep-id-int)
                 |  |     +--rw mep-id-int?      int32
                 |  +--rw mep-id-format?   identityref
                 |  +--rw (mep-address)?
                 |  |  +--:(mac-address)
                 |  |  |  +--rw mac-address?     yang:mac-address
                 |  |  +--:(ip-address)
                 |  |     +--rw ip-address?      inet:ip-address
                 |  +--rw cos-id?          uint8
                 |  +--rw cc-enable?       boolean
                 |  +--rw session* [session-cookie]
                 |     +--rw session-cookie             uint32
                 |     +--rw destination-mep
                 |     |  +--rw (mep-id)?
                 |     |  |  +--:(mep-id-int)
                 |     |  |     +--rw mep-id-int?      int32
                 |     |  +--rw mep-id-format?   identityref
                 |     +--rw destination-mep-address
                 |     |  +--rw (mep-address)?
                 |     |     +--:(mac-address)
                 |     |     |  +--rw mac-address?   yang:mac-address
                 |     |     +--:(ip-address)
                 |     |        +--rw ip-address?    inet:ip-address
                 |     +--rw cos-id?                    uint8
                 +--rw mip* [name] {mip}?
                    +--rw name           string
                    +--rw interface?     if:interface-ref
                    +--rw (mip-address)?
                       +--:(mac-address)
                       |  +--rw mac-address?   yang:mac-address
                       +--:(ip-address)
                          +--rw ip-address?    inet:ip-address

   rpcs:
     +---x continuity-check {continuity-check}?
     |  +---w input
     |  |  +---w technology?             identityref
     |  |  +---w md-name-string -> /domains/domain/md-name-string
     |  |  +---w md-level?      -> /domains/domain/md-level
     |  |  +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
Top   ToC   Page 16
     |  |  +---w cos-id?                 uint8
     |  |  +---w ttl?                    uint8
     |  |  +---w sub-type?               identityref
     |  |  +---w source-mep?    -> /domains/domain/mas/ma/mep/mep-name
     |  |  +---w destination-mep
     |  |  |  +---w (mep-address)?
     |  |  |  |  +--:(mac-address)
     |  |  |  |  |  +---w mac-address?     yang:mac-address
     |  |  |  |  +--:(ip-address)
     |  |  |  |     +---w ip-address?      inet:ip-address
     |  |  |  +---w (mep-id)?
     |  |  |  |  +--:(mep-id-int)
     |  |  |  |     +---w mep-id-int?      int32
     |  |  |  +---w mep-id-format?   identityref
     |  |  +---w count?                  uint32
     |  |  +---w cc-transmit-interval?   time-interval
     |  |  +---w packet-size?            uint32
     |  +--ro output
     |     +--ro (monitor-stats)?
     |        +--:(monitor-null)
     |           +--ro monitor-null?   empty
     +---x continuity-verification {connectivity-verification}?
     |  +---w input
     |  |  +---w md-name-string -> /domains/domain/md-name-string
     |  |  +---w md-level?      -> /domains/domain/md-level
     |  |  +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
     |  |  +---w cos-id?            uint8
     |  |  +---w ttl?               uint8
     |  |  +---w sub-type?          identityref
     |  |  +---w source-mep?    -> /domains/domain/mas/ma/mep/mep-name
     |  |  +---w destination-mep
     |  |  |  +---w (mep-address)?
     |  |  |  |  +--:(mac-address)
     |  |  |  |  |  +---w mac-address?     yang:mac-address
     |  |  |  |  +--:(ip-address)
     |  |  |  |     +---w ip-address?      inet:ip-address
     |  |  |  +---w (mep-id)?
     |  |  |  |  +--:(mep-id-int)
     |  |  |  |     +---w mep-id-int?      int32
     |  |  |  +---w mep-id-format?   identityref
     |  |  +---w count?             uint32
     |  |  +---w interval?          time-interval
     |  |  +---w packet-size?       uint32
     |  +--ro output
     |     +--ro (monitor-stats)?
     |        +--:(monitor-null)
     |           +--ro monitor-null?   empty
     +---x traceroute {traceroute}?
Top   ToC   Page 17
        +---w input
        |  +---w md-name-string -> /domains/domain/md-name-string
        |  +---w md-level?      -> /domains/domain/md-level
        |  +---w ma-name-string -> /domains/domain/mas/ma/ma-name-string
        |  +---w cos-id?             uint8
        |  +---w ttl?                uint8
        |  +---w command-sub-type?   identityref
        |  +---w source-mep?    -> /domains/domain/mas/ma/mep/mep-name
        |  +---w destination-mep
        |  |  +---w (mep-address)?
        |  |  |  +--:(mac-address)
        |  |  |  |  +---w mac-address?     yang:mac-address
        |  |  |  +--:(ip-address)
        |  |  |     +---w ip-address?      inet:ip-address
        |  |  +---w (mep-id)?
        |  |  |  +--:(mep-id-int)
        |  |  |     +---w mep-id-int?      int32
        |  |  +---w mep-id-format?   identityref
        |  +---w count?              uint32
        |  +---w interval?           time-interval
        +--ro output
           +--ro response* [response-index]
              +--ro response-index     uint8
              +--ro ttl?               uint8
              +--ro destination-mep
              |  +--ro (mep-address)?
              |  |  +--:(mac-address)
              |  |  |  +--ro mac-address?     yang:mac-address
              |  |  +--:(ip-address)
              |  |     +--ro ip-address?      inet:ip-address
              |  +--ro (mep-id)?
              |  |  +--:(mep-id-int)
              |  |     +--ro mep-id-int?      int32
              |  +--ro mep-id-format?   identityref
              +--ro mip {mip}?
              |  +--ro interface?     if:interface-ref
              |  +--ro (mip-address)?
              |     +--:(mac-address)
              |     |  +--ro mac-address?   yang:mac-address
              |     +--:(ip-address)
              |        +--ro ip-address?    inet:ip-address
              +--ro (monitor-stats)?
                 +--:(monitor-null)
                    +--ro monitor-null?      empty
Top   ToC   Page 18
   notifications:
     +---n defect-condition-notification
     |  +--ro technology?         identityref
     |  +--ro md-name-string -> /domains/domain/md-name-string
     |  +--ro ma-name-string -> /domains/domain/mas/ma/ma-name-string
     |  +--ro mep-name?      -> /domains/domain/mas/ma/mep/mep-name
     |  +--ro defect-type?        identityref
     |  +--ro generating-mepid
     |  |  +--ro (mep-id)?
     |  |  |  +--:(mep-id-int)
     |  |  |     +--ro mep-id-int?      int32
     |  |  +--ro mep-id-format?   identityref
     |  +--ro (defect)?
     |     +--:(defect-null)
     |     |  +--ro defect-null?        empty
     |     +--:(defect-code)
     |        +--ro defect-code?        int32
     +---n defect-cleared-notification
        +--ro technology?         identityref
        +--ro md-name-string -> /domains/domain/md-name-string
        +--ro ma-name-string -> /domains/domain/mas/ma/ma-name-string
        +--ro mep-name?      -> /domains/domain/mas/ma/mep/mep-name
        +--ro defect-type?        identityref
        +--ro generating-mepid
        |  +--ro (mep-id)?
        |  |  +--:(mep-id-int)
        |  |     +--ro mep-id-int?      int32
        |  +--ro mep-id-format?   identityref
        +--ro (defect)?
           +--:(defect-null)
           |  +--ro defect-null?        empty
           +--:(defect-code)
              +--ro defect-code?        int32

                           Data Hierarchy of OAM


Next Section