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

in Index   Prev   Next
in Index   Prev   Next  Group: LIME

RFC 8532

Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications

Pages: 59
Proposed STD
Part 1 of 3 – Pages 1 to 15
None   None   Next

Top   ToC   RFC8532 - Page 1
Internet Engineering Task Force (IETF)                          D. Kumar
Request for Comments: 8532                                         Cisco
Category: Standards Track                                        M. Wang
ISSN: 2070-1721                                               Q. Wu, Ed.
                                                                  Huawei
                                                               R. Rahman
                                                             S. Raghavan
                                                                   Cisco
                                                              April 2019


             Generic YANG Data Model for the Management of
      Operations, Administration, and Maintenance (OAM) Protocols
                 That Use Connectionless Communications

Abstract

   This document presents a base YANG Data model for the management of
   Operations, Administration, and Maintenance (OAM) protocols that use
   connectionless communications.  The data model is defined using the
   YANG data modeling language, as specified in RFC 7950.  It provides a
   technology-independent abstraction of key OAM constructs for OAM
   protocols that use connectionless communication.  The base model
   presented here can be extended to include technology-specific
   details.

   There are two key benefits of this approach: First, it leads to
   uniformity between OAM protocols.  Second, it supports both nested
   OAM workflows (i.e., performing OAM functions at the same level or
   different levels through a unified interface) as well as interactive
   OAM workflows (i.e., performing OAM functions at the same level
   through a unified interface).

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/rfc8532.
Top   ToC   RFC8532 - 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   4
     2.1.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  Tree Diagrams . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Overview of the Connectionless OAM Model  . . . . . . . . . .   5
     3.1.  TP Address  . . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Tools . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.3.  OAM Neighboring Test Points . . . . . . . . . . . . . . .   7
     3.4.  Test Point Location Information . . . . . . . . . . . . .   8
     3.5.  Test Point Locations  . . . . . . . . . . . . . . . . . .   8
     3.6.  Path Discovery Data . . . . . . . . . . . . . . . . . . .   8
     3.7.  Continuity Check Data . . . . . . . . . . . . . . . . . .   9
     3.8.  OAM Data Hierarchy  . . . . . . . . . . . . . . . . . . .   9
   4.  LIME Time Types YANG Module . . . . . . . . . . . . . . . . .  12
   5.  Connectionless OAM YANG Module  . . . . . . . . . . . . . . .  15
   6.  Connectionless Model Applicability  . . . . . . . . . . . . .  44
     6.1.  BFD Extension . . . . . . . . . . . . . . . . . . . . . .  45
       6.1.1.  Augment Method  . . . . . . . . . . . . . . . . . . .  45
       6.1.2.  Schema Mount  . . . . . . . . . . . . . . . . . . . .  47
     6.2.  LSP Ping Extension  . . . . . . . . . . . . . . . . . . .  49
       6.2.1.  Augment Method  . . . . . . . . . . . . . . . . . . .  49
       6.2.2.  Schema Mount  . . . . . . . . . . . . . . . . . . . .  50
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  52
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  54
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  54
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  54
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  56
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  58
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  59
Top   ToC   RFC8532 - Page 3
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].

   Ping and Traceroute (see [RFC792] and [RFC4443]) are respectively
   well-known fault verification and isolation tools for IP networks.
   Over the years, different technologies have developed similar
   toolsets for equivalent purposes.

   The different sets of OAM tools may support both connection-oriented
   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] and [RFC7276]).  The YANG data model for
   OAM protocols using connection-oriented communications is specified
   in [RFC8531].

   This document defines a base YANG data model for OAM protocols that
   use connectionless communications.  The data model is defined using
   the YANG data modeling language [RFC7950].  This generic YANG data
   model for connectionless OAM includes only configuration and state
   data.  It can be used in conjunction with the data retrieval method
   model described in [RFC8533], which focuses on the data retrieval
   procedures such as RPC, or it can be used independently of this data
   retrieval method model.
Top   ToC   RFC8532 - Page 4
2.  Conventions Used in This Document

   The following terms are defined in [RFC6241] and are used in this
   specification:

   o  client

   o  configuration data

   o  server

   o  state data

   The following terms are defined in [RFC7950] and are used in this
   specification:

   o  augment

   o  data model

   o  data node

   The terminology for describing YANG data models is found in
   [RFC7950].

2.1.  Abbreviations

   BFD - Bidirectional Forwarding Detection [RFC5880].

   RPC - Remote Procedure Call [RFC1831].

   DSCP - Differentiated Services Code Point.

   VRF - Virtual Routing and Forwarding [RFC4382].

   OWAMP - One-Way Active Measurement Protocol [RFC4656].

   TWAMP - Two-Way Active Measurement Protocol [RFC5357].

   AS - Autonomous System.

   LSP - Label Switched Path.

   TE - Traffic Engineering.

   MPLS - Multiprotocol Label Switching.

   NI - Network Instance.
Top   ToC   RFC8532 - Page 5
   PTP - Precision Time Protocol [IEEE.1588v2].

   NTP - Network Time Protocol [RFC5905].

2.2.  Terminology

   MAC - Media Access Control.

   MAC address - Address for the data-link layer interface.

   TP - Test Point.  The TP is a functional entity that is defined at a
   node in the network and can initiate and/or react to OAM diagnostic
   tests.  This document focuses on the data-plane functionality of TPs.

   RPC operation - A specific Remote Procedure Call.

   CC - A Continuity Check [RFC7276] is used to verify that a
   destination is reachable and therefore also referred to as
   reachability verification.

2.3.  Tree Diagrams

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

3.  Overview of the Connectionless OAM Model

   The YANG data model for OAM protocols that use connectionless
   communications has been split into two modules:

   o  The "ietf-lime-time-types" module provides common definitions such
      as Time-related data types and Timestamp-related data types.

   o  The "ietf-connectionless-oam" module defines technology-
      independent abstraction of key OAM constructs for OAM protocols
      that use connectionless communication.

   The "ietf-connectionless-oam" module augments the "/networks/network/
   node" path defined in the "ietf-network" module [RFC8345] with the
   'test-point-locations' grouping defined in Section 3.5.  The network
   nodes in the "/networks/network/node" path are used to describe the
   network hierarchies and the inventory of nodes contained in a
   network.

   Under the 'test-point-locations' grouping, each test point location
   is chosen based on the 'tp-location-type' leaf, which, when chosen,
   leads to a container that includes a list of 'test-point-locations'.
Top   ToC   RFC8532 - Page 6
   Each 'test-point-locations' list includes a 'test-point-location-
   info' grouping.  The 'test-point-location-info' grouping includes:

   o  'tp-technology' grouping,

   o  'tp-tools' grouping, and

   o  'connectionless-oam-tps' grouping.

   The groupings of 'tp-address' and 'tp-address-ni' are kept out of the
   'test-point-location-info' grouping to make it addressing agnostic
   and allow varied composition.  Depending upon the choice of the
   'tp-location-type' (determined by the 'tp-address-ni'), each
   container differs in its composition of 'test-point-locations', while
   the 'test-point-location-info' is a common aspect of every
   'test-point-locations'.

   The 'tp-address-ni' grouping is used to describe the corresponding
   network instance.  The 'tp-technology' grouping indicates OAM
   technology details.  The 'connectionless-oam-tps' grouping is used to
   describe the relationship of one test point with other test points.
   The 'tp-tools' grouping describes the OAM tools supported.

   In addition, at the top of the model, there is an 'cc-oper-data'
   container for session statistics.  A grouping is also defined for
   common session statistics, and these are only applicable for
   proactive OAM sessions (see Section 3.2).

3.1.  TP Address

   With connectionless OAM protocols, the TP address can be one of the
   following types:

   o  MAC address [RFC6136] at the data-link layer for TPs

   o  IPv4 or IPv6 address at the IP layer for TPs

   o  TP-attribute identifying a TP associated with an application-layer
      function

   o  Router-id to represent the device or node, which is commonly used
      to identify nodes in routing and other control-plane protocols
      [RFC8294].

   To define a forwarding treatment of a test packet, the 'tp-address'
   grouping needs to be associated with additional parameters, e.g.,
   DSCP for IP or Traffic Class [RFC5462] for MPLS.  In the generic
Top   ToC   RFC8532 - Page 7
   connectionless OAM YANG data model, these parameters are not
   explicitly configured.  The model user can add corresponding
   parameters according to their requirements.

3.2.  Tools

   The different OAM tools may be used in one of two basic types of
   activation: proactive and on-demand.  Proactive OAM refers to OAM
   actions that are carried out continuously to permit proactive
   reporting of faults.  The proactive OAM method requires persistent
   configuration.  On-demand OAM refers to OAM actions that are
   initiated via manual intervention for a limited time to carry out
   specific diagnostics.  The on-demand OAM method requires only
   transient configuration (e.g., [RFC7276] and [G.8013]).  In
   connectionless OAM, the 'session-type' grouping is defined to
   indicate which kind of activation will be used by the current
   session.

   In connectionless OAM, the tools attribute is used to describe a
   toolset for fault detection and isolation.  In addition, it can serve
   as a constraint condition when the base model is extended to a
   specific OAM technology.  For example, to fulfill the ICMP PING
   configuration, the "../coam:continuity-check" leaf should be set to
   "true", and then the LIME base model should be augmented with details
   specific to ICMP PING.

3.3.  OAM Neighboring Test Points

   Given that typical network communication stacks have a multi-layer
   architecture, the set of associated OAM protocols has also a multi-
   layer structure; each communication layer in the stack may have its
   own OAM protocol [RFC7276] that may also be linked to a specific
   administrative domain.  Management of these OAM protocols will
   necessitate associated test points in the nodes accessible by
   appropriate management domains.  Accordingly, a given network
   interface may actually present several test points.

   Each OAM test point may have an associated list of neighboring test
   points that are in other layers up and down the protocol stack for
   the same interface and are therefore related to the current test
   point.  This allows users to easily navigate between related
   neighboring layers to efficiently troubleshoot a defect.  In this
   model, the 'position' leaf defines the relative position of the
   neighboring test point corresponding to the current test point, and
   it is provided to allow correlation of faults at different locations.
   If there is one neighboring test point placed before the current test
   point, the 'position' leaf is set to -1.  If there is one neighboring
Top   ToC   RFC8532 - Page 8
   test point placed after the current test point, the 'position' leaf
   is set to 1.  If there is no neighboring test point placed before or
   after the current test point, the 'position' leaf is set to 0.

     +-- oam-neighboring-tps* [index]
        +-- index?                         uint16
        +-- position?                      int8
        +-- (tp-location)?
           +--:(mac-address)
           |  +-- mac-address-location?    yang:mac-address
           +--:(ipv4-address)
           |  +-- ipv4-address-location?   inet:ipv4-address
           +--:(ipv6-address)
           |  +-- ipv6-address-location?   inet:ipv6-address
           +--:(as-number)
           |  +-- as-number-location?      inet:as-number
           +--:(router-id)
              +-- router-id-location?      rt:router-id

3.4.  Test Point Location Information

   This is a generic grouping for Test Point Location Information (i.e.,
   'test-point-location-info' grouping).  It provides details of Test
   Point Location using the 'tp-technology', 'tp-tools', and
   'oam-neighboring-tps' groupings, all of which are defined above.

3.5.  Test Point Locations

   This is a generic grouping for Test Point Locations.  'tp-location-
   type' leaf is used to define location types -- for example,
   'ipv4-location-type', 'ipv6-location-type', etc.  Container is
   defined under each location type containing a list keyed to a test
   point address, Test Point Location Information defined in the section
   above, and network instance name (e.g., VRF instance name) if
   required.

3.6.  Path Discovery Data

   This is a generic grouping for the path discovery data model that can
   be retrieved by any data retrieval method, including RPC operations.
   Path discovery data output from methods, includes 'src-test-point'
   container, 'dst-test-point' container, 'sequence-number' leaf,
   'hop-cnt' leaf, session statistics of various kinds, and information
   related to path verification and path trace.  Path discovery includes
   data to be retrieved on a 'per-hop' basis via a list of 'path-trace-
   info-list' items which includes information such as 'timestamp'
   grouping, 'ingress-intf-name', 'egress-intf-name', and 'app-meta-
   data'.  The path discovery data model is made generic enough to allow
Top   ToC   RFC8532 - Page 9
   different methods of data retrieval.  None of the fields are made
   mandatory for that reason.  Note that a set of retrieval methods are
   defined in [RFC8533].

3.7.  Continuity Check Data

   This is a generic grouping for the Continuity Check data model that
   can be retrieved by any data retrieval methods including RPC
   operations.  Continuity Check data output from methods, includes
   'src-test-point' container, 'dst-test-point' container,
   'sequence-number' leaf, 'hop-cnt' leaf, and session statistics of
   various kinds.  The Continuity Check data model is made generic
   enough to allow different methods of data retrieval.  None of the
   fields are made mandatory for that reason.  Noted that a set of
   retrieval methods are defined in [RFC8533].

3.8.  OAM Data Hierarchy

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

  module: ietf-connectionless-oam
      +--ro cc-session-statistics-data {continuity-check}?
         +--ro cc-session-statistics* [type]
            +--ro type                           identityref
            +--ro cc-ipv4-sessions-statistics
            |  +--ro cc-session-statistics
            |     +--ro session-count?              uint32
            |     +--ro session-up-count?           uint32
            |     +--ro session-down-count?         uint32
            |     +--ro session-admin-down-count?   uint32
            +--ro cc-ipv6-sessions-statistics
               +--ro cc-session-statistics
                  +--ro session-count?              uint32
                  +--ro session-up-count?           uint32
                  +--ro session-down-count?         uint32
                  +--ro session-admin-down-count?   uint32
    augment /nd:networks/nd:network/nd:node:
      +--rw tp-location-type?                identityref
      +--rw ipv4-location-type
      |  +--rw test-point-ipv4-location-list
      |     +--rw test-point-locations* [ipv4-location ni]
      |        +--rw ipv4-location          inet:ipv4-address
      |        +--rw ni                     routing-instance-ref
      |        +--rw (technology)?
      |        |  +--:(technology-null)
      |        |     +--rw tech-null?             empty
      |        +--rw tp-tools
Top   ToC   RFC8532 - Page 10
      |        |  +--rw continuity-check    boolean
      |        |  +--rw path-discovery      boolean
      |        +--rw root?                  <anydata>
      |        +--rw oam-neighboring-tps* [index]
      |           +--rw index                    uint16
      |           +--rw position?                int8
      |           +--rw (tp-location)?
      |              +--:(mac-address)
      |              |  +--rw mac-address-location?    yang:mac-address
      |              +--:(ipv4-address)
      |              |  +--rw ipv4-address-location?   inet:ipv4-address
      |              +--:(ipv6-address)
      |              |  +--rw ipv6-address-location?   inet:ipv6-address
      |              +--:(as-number)
      |              |  +--rw as-number-location?      inet:as-number
      |              +--:(router-id)
      |                 +--rw router-id-location?      rt:router-id
      +--rw ipv6-location-type
      |  +--rw test-point-ipv6-location-list
      |     +--rw test-point-locations* [ipv6-location ni]
      |        +--rw ipv6-location          inet:ipv6-address
      |        +--rw ni                     routing-instance-ref
      |        +--rw (technology)?
      |        |  +--:(technology-null)
      |        |     +--rw tech-null?             empty
      |        +--rw tp-tools
      |        |  +--rw continuity-check    boolean
      |        |  +--rw path-discovery      boolean
      |        +--rw root?                  <anydata>
      |        +--rw oam-neighboring-tps* [index]
      |           +--rw index                    uint16
      |           +--rw position?                int8
      |           +--rw (tp-location)?
      |              +--:(mac-address)
      |              |  +--rw mac-address-location?    yang:mac-address
      |              +--:(ipv4-address)
      |              |  +--rw ipv4-address-location?   inet:ipv4-address
      |              +--:(ipv6-address)
      |              |  +--rw ipv6-address-location?   inet:ipv6-address
      |              +--:(as-number)
      |              |  +--rw as-number-location?      inet:as-number
      |              +--:(router-id)
      |                 +--rw router-id-location?      rt:router-id
      +--rw mac-location-type
      |  +--rw test-point-mac-address-location-list
      |     +--rw test-point-locations* [mac-address-location]
      |        +--rw mac-address-location    yang:mac-address
      |        +--rw (technology)?
Top   ToC   RFC8532 - Page 11
      |        |  +--:(technology-null)
      |        |     +--rw tech-null?              empty
      |        +--rw tp-tools
      |        |  +--rw continuity-check    boolean
      |        |  +--rw path-discovery      boolean
      |        +--rw root?                   <anydata>
      |        +--rw oam-neighboring-tps* [index]
      |           +--rw index                    uint16
      |           +--rw position?                int8
      |           +--rw (tp-location)?
      |              +--:(mac-address)
      |              |  +--rw mac-address-location?    yang:mac-address
      |              +--:(ipv4-address)
      |              |  +--rw ipv4-address-location?   inet:ipv4-address
      |              +--:(ipv6-address)
      |              |  +--rw ipv6-address-location?   inet:ipv6-address
      |              +--:(as-number)
      |              |  +--rw as-number-location?      inet:as-number
      |              +--:(router-id)
      |                 +--rw router-id-location?      rt:router-id
      +--rw group-as-number-location-type
      |  +--rw test-point-as-number-location-list
      |     +--rw test-point-locations* [as-number-location]
      |        +--rw as-number-location     inet:as-number
      |        +--rw ni?                    routing-instance-ref
      |        +--rw (technology)?
      |        |  +--:(technology-null)
      |        |     +--rw tech-null?             empty
      |        +--rw tp-tools
      |        |  +--rw continuity-check    boolean
      |        |  +--rw path-discovery      boolean
      |        +--rw root?                  <anydata>
      |        +--rw oam-neighboring-tps* [index]
      |           +--rw index                    uint16
      |           +--rw position?                int8
      |           +--rw (tp-location)?
      |              +--:(mac-address)
      |              |  +--rw mac-address-location?    yang:mac-address
      |              +--:(ipv4-address)
      |              |  +--rw ipv4-address-location?   inet:ipv4-address
      |              +--:(ipv6-address)
      |              |  +--rw ipv6-address-location?   inet:ipv6-address
      |              +--:(as-number)
      |              |  +--rw as-number-location?      inet:as-number
      |              +--:(router-id)
      |                 +--rw router-id-location?      rt:router-id
      +--rw group-router-id-location-type
         +--rw test-point-system-info-location-list
Top   ToC   RFC8532 - Page 12
            +--rw test-point-locations* [router-id-location]
               +--rw router-id-location     rt:router-id
               +--rw ni?                    routing-instance-ref
               +--rw (technology)?
               |  +--:(technology-null)
               |     +--rw tech-null?             empty
               +--rw tp-tools
               |  +--rw continuity-check    boolean
               |  +--rw path-discovery      boolean
               +--rw root?                  <anydata>
               +--rw oam-neighboring-tps* [index]
                  +--rw index                    uint16
                  +--rw position?                int8
                  +--rw (tp-location)?
                     +--:(mac-address)
                     |  +--rw mac-address-location?    yang:mac-address
                     +--:(ipv4-address)
                     |  +--rw ipv4-address-location?   inet:ipv4-address
                     +--:(ipv6-address)
                     |  +--rw ipv6-address-location?   inet:ipv6-address
                     +--:(as-number)
                     |  +--rw as-number-location?      inet:as-number
                     +--:(router-id)
                        +--rw router-id-location?      rt:router-id

4.  LIME Time Types YANG Module

   <CODE BEGINS> file "ietf-lime-time-types@2019-04-16.yang"

   module ietf-lime-time-types {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-lime-time-types";
     prefix lime;

     organization
       "IETF LIME Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/lime>
        WG List:  <mailto:lmap@ietf.org>

        Editor:   Qin Wu
                  <bill.wu@huawei.com>";
     description
       "This module provides time-related definitions used by the data
        models written for Layer Independent OAM Management in the
        Multi-Layer Environment (LIME).  This module defines
        identities but no schema tree elements.
Top   ToC   RFC8532 - Page 13
        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
        (http://trustee.ietf.org/license-info).

        This version of this YANG module is part of RFC 8532; see
        the RFC itself for full legal notices.";

     revision 2019-04-16 {
       description
         "Initial version.";
       reference
         "RFC 8532: Generic YANG Data Model for the Management of
          Operations, Administration, and Maintenance (OAM) Protocols
          That Use Connectionless Communications";
     }

     /*** Collection of common types related to time ***/
     /*** Time unit identity ***/

     identity time-unit-type {
       description
         "Time unit type.";
     }

     identity hours {
       base time-unit-type;
       description
         "Time unit in hours.";
     }

     identity minutes {
       base time-unit-type;
       description
         "Time unit in minutes.";
     }

     identity seconds {
       base time-unit-type;
       description
         "Time unit in seconds.";
     }
Top   ToC   RFC8532 - Page 14
     identity milliseconds {
       base time-unit-type;
       description
         "Time unit in milliseconds.";
     }

     identity microseconds {
       base time-unit-type;
       description
         "Time unit in microseconds.";
     }

     identity nanoseconds {
       base time-unit-type;
       description
         "Time unit in nanoseconds.";
     }

     /*** Timestamp format Identity ***/

     identity timestamp-type {
       description
         "Base identity for Timestamp Type.";
     }

     identity truncated-ptp {
       base timestamp-type;
       description
         "Identity for 64-bit short-format PTP timestamp.";
     }

     identity truncated-ntp {
       base timestamp-type;
       description
         "Identity for 32-bit short-format NTP timestamp.";
     }

     identity ntp64 {
       base timestamp-type;
       description
         "Identity for 64-bit NTP timestamp.";
     }

     identity icmp {
       base timestamp-type;
       description
         "Identity for 32-bit ICMP timestamp.";
     }
Top   ToC   RFC8532 - Page 15
     identity ptp80 {
       base timestamp-type;
       description
         "Identity for 80-bit PTP timestamp.";
     }
   }

   <CODE ENDS>



(page 15 continued on part 2)

Next Section