Network Working Group                                         T. Mizrahi
Internet-Draft                                                   Marvell
Intended status: Informational                                 J. Fabini
Expires: April 29, September 6, 2018               Vienna University of Technology
                                                               A. Morton
                                                               AT&T Labs
                                                        October 26, 2017
                                                           March 5, 2018

               Guidelines for Defining Packet Timestamps
                  draft-ietf-ntp-packet-timestamps-00
                  draft-ietf-ntp-packet-timestamps-01

Abstract

   This document specifies guidelines for defining binary packet
   timestamp formats in networking protocols at various layers.  It also
   presents three recommended timestamp formats.  The target audience of
   this memo includes network protocol designers.  It is expected that a
   new network protocol that requires a packet timestamp will, in most
   cases, use one of the recommended timestamp formats.  If none of the
   recommended formats fits the protocol requirements, the new protocol
   specification should specify the format of the packet timestamp
   according to the guidelines in this document.

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 April 29, September 6, 2018.

Copyright Notice

   Copyright (c) 2017 2018 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  . . . . . . . . . . . . . . . . . . . . . . . .   2   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Terms used in this Document . . . . . . . . . . . . . . .   4
   3.  Packet Timestamp Format Specification Template . . . . . . . . . . . .   3   4
   4.  Recommended Timestamp Formats . . . . . . . . . . . . . . . .   4   5
     4.1.  Using a Recommended Timestamp Format  . . . . . . . . . .   5   6
     4.2.  NTP Timestamp Formats . . . . . . . . . . . . . . . . . .   5   6
       4.2.1.  NTP 64-bit Timestamp Format . . . . . . . . . . . . .   5   6
       4.2.2.  NTP 32-bit Timestamp Format . . . . . . . . . . . . .   6   8
     4.3.  The PTP Truncated Timestamp Format  . . . . . . . . . . .   8   9
   5.  Synchronization Aspects . . . . . . . . . . . . . . . . . . .  10
   6.  Timestamp Use Cases . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  11
     6.1.  Example 1 . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.2.  12
     6.2.  Example 2 . . . . . . . . . . . . . . . . . . . . . . . .  10
   6.  12
   7.  Packet Timestamp Control Field  . . . . . . . . . . . . . . .  10
   7.  IANA Considerations  12
     7.1.  High-level Control Field Requirements . . . . . . . . . .  13
     7.2.  Control Field Categories  . . . . . . . . . . .  11
   8.  Security Considerations . . . . .  14
     7.3.  Control Field Features and Elements . . . . . . . . . . .  15
       7.3.1.  Timestamp Format  . . .  11
   9.  Acknowledgments . . . . . . . . . . . . . . .  16
       7.3.2.  Timestamp Format Specification  . . . . . . . .  12
   10. References . . .  16
       7.3.3.  Timestamp Precision . . . . . . . . . . . . . . . . .  17
       7.3.4.  Timestamp Timescale . . . . .  12
     10.1.  Normative References . . . . . . . . . . . .  17
       7.3.5.  Timestamp Leap Second . . . . . .  12
     10.2.  Informative References . . . . . . . . . .  17
       7.3.6.  Reference Clock . . . . . . .  12
   Authors' Addresses . . . . . . . . . . . .  18
       7.3.7.  Provable Signature  . . . . . . . . . . .  14

1.  Introduction

   Timestamps are widely used in network protocols for various purposes,
   including delay measurement, clock synchronization, and logging or
   reporting the time of an event.

   Timestamps are represented in the RFC series in one of two forms:
   text-based timestamps, and packet timestamps.  Text-based timestamps
   [RFC3339] are represented as user-friendly strings, and are widely
   used in the RFC series, for example in information objects and data
   models, e.g., [RFC5646], [RFC6991], and [RFC7493].  Packet
   timestamps, on the other hand, are represented by a compact binary
   field that has a fixed size, and are not intended to have a human-
   friendly format.  Packet timestamps are also very common in the RFC
   series, and are used for example for measuring delay and for
   synchronizing clocks, e.g., [RFC5905], [RFC4656], and [RFC1323].

   This memo presents guidelines for defining a packet timestamp format . . . . . .  18
       7.3.8.  Custom Extension  . . . . . . . . . . . . . . . . . .  18
     7.4.  Control Field Payload Definition  . . . . . . . . . . . .  19
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  20
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  20
     11.2.  Informative References . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   Timestamps are widely used in network protocols for various purposes,
   including delay measurement, clock synchronization, and logging or
   reporting the time of an event.

   Timestamps are represented in the RFC series in one of two forms:
   text-based timestamps, and packet timestamps.  Text-based timestamps
   [RFC3339] are represented as user-friendly strings, and are widely
   used in the RFC series, for example in information objects and data
   models, e.g., [RFC5646], [RFC6991], and [RFC7493].  Packet
   timestamps, on the other hand, are represented by a compact binary
   field that has a fixed size, and are not intended to have a human-
   friendly format.  Packet timestamps are also very common in the RFC
   series, and are used for example for measuring delay and for
   synchronizing clocks, e.g., [RFC5905], [RFC4656], and [RFC1323].

   This memo presents guidelines for defining a packet timestamp format
   in network protocols.  Three recommended timestamp formats are
   presented.  It is expected that a new network protocol that requires
   a packet timestamp will, in most cases, use one of the recommended
   timestamp formats.  If none of the recommended formats fits the
   protocol requirements, the new protocol specification should specify
   the format of the packet timestamp according to the guidelines in
   this document.

2.  Terminology

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.2.  Abbreviations

   NTP         Network Time Protocol [RFC5905]

   PTP         Precision Time Protocol [IEEE1588]

   TAI         International Atomic Time

   UTC         Coordinated Universal Time

2.3.  Terms used in this Document

   Timestamp error:       The difference between the timestamp value at
                          the device under test and the value of a
                          reference clock at the same time instant.

   Timestamp format:      The specification of a timestamp, which is
                          represented by a set of attributes that
                          unambiguously define the syntax and semantics
                          of a timestamp.

   Timestamp accuracy:    The mean over an ensemble of measurements of
                          the timestamp error.

   Timestamp precision:   The variation over an ensemble of measurements
                          of the timestamp error.

   Timestamp resolution:  The minimal time unit used for representing
                          the timestamp.

3.  Packet Timestamp Specification Template

   This memo recommends to use the timestamp formats defined in
   Section 4.  In cases where these timestamp formats do not satisfy the
   protocol requirements, the timestamp specification should clearly
   state the reasons for defining a new format.  Moreover, it is
   recommended to derive the new timestamp format from an existing
   timestamp format, either a timestamp format from this memo, or any
   other previously defined timestamp format.

   The timestamp specification must unambiguously define the syntax and
   the semantics of the timestamp.  The current section defines the
   minimum set of attributes, but it should be noted that in some cases
   additional attributes or aspects will need to be defined in the
   timestamp specification.

   This section defines a template for specifying packet timestamps.  A
   timestamp format specification MUST include at least the following
   aspects:

   Timestamp syntax:

      The structure of the timestamp field consists of:

      + Size: The number of bits (or octets) used to represent the
      packet timestamp field.  If the timestamp is comprised of more
      than one field, the size of each field is specified.

   Timestamp semantics:

      + Units: The units used to represent the timestamp.  If the
      timestamp is comprised of more than one field, the units of each
      field are specified.

      + Resolution: The timestamp resolution; the resolution is equal to
      the timestamp field unit.  If the timestamp consists of two or
      more fields using different time units, then the resolution is the
      smallest time unit.

      + Wraparound: The wraparound period of the timestamp; any further
      wraparound-related considerations should be described here.

      + Epoch: The origin of the timescale used for the timestamp; the
      moment in network protocols.  Three time used as a reference for the timestamp value.  For
      example, the epoch may be based on a standard time scale, such as
      UTC.  Another example is a relative timestamp, in which the epoch
      is the time at which the device using the timestamp was powered
      up, and is not affected by leap seconds (see the next attribute).

      + Leap seconds: This subsection specifies whether the timestamp is
      affected by leap seconds.  If the timestamp is affected by leap
      seconds, then it represents the time elapsed since the epoch minus
      the number of leap seconds that have occurred since the epoch.

4.  Recommended Timestamp Formats

   This memo defines a set of recommended timestamp formats.  Defining a
   relatively small set of recommended formats enables significant
   reuse; for example, a network protocol may reuse the NTP or PTP
   timestamp format, allowing a straightforward integration with an NTP
   or a PTP-based timer.  Moreover, since accurate timestamping
   mechanisms are
   presented.  It is expected that often implemented in hardware, a new network protocol
   that requires reuses an existing timestamp format can be quickly deployed
   using existing hardware timestamping capabilities.  This memo
   recommends to use one of the timestamp formats specified below.

   Clearly, different network protocols may have different requirements
   and constraints, and consequently may use different timestamp
   formats.  The choice of the specific timestamp format for a given
   protocol may depend on a various factors.  A few examples of factors
   that may affect the choice of the timestamp format:

   o  Timestamp size: while some network protocols use a large timestamp
      field, in some cases there may be constraints with respect to the
      timestamp size, affecting the choice of the timestamp format.

   o  Resolution: the time resolution is another factor that may
      directly affect the selected timestamp format.  A potentially
      important factor in this context is extensibility; it may be
      desirable to allow a packet timestamp will, in most cases, use one format to be extensible to a higher
      resolution by extending the field.  For example, the resolution of
      the recommended NTP 32-bit timestamp formats.  If none of format can be improved by extending it to
      the recommended formats fits NTP 64-bit timestamp format in a straightforward way.

   o  Wraparound period: the
   protocol requirements, length of the new protocol specification should specify time interval in which the format of
      timestamp is unique may also be an important factor in choosing
      the packet timestamp according to format.  Along with the guidelines timestamp resolution, these
      two factors determine the required number of bits in
   this document.

2.  Terminology

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", the
      timestamp.

   o  Common format for multiple protocols: if there are two or more
      network protocols that use timestamps and "OPTIONAL" in this
   document are to be interpreted as described often used together
      in RFC 2119 [RFC2119].

2.2.  Abbreviations

   NTP         Network Time Protocol [RFC5905]

   PTP         Precision Time Protocol [IEEE1588]

3.  Packet Timestamp Format Specification

   This memo recommends to use the typical systems, using a common timestamp formats format should be
      preferred if possible.  Specifically, if the network protocol that
      is being defined in
   Section 4.  In cases where these typically runs on a PC, then an NTP-based
      timestamp formats do not satisfy the format may allow easier integration with an NTP-
      synchronized timer.  In contrast, a protocol requirements, that is typically
      deployed on a hardware-based platform, may make better use of a
      PTP-based timestamp, allowing more efficient integration with a
      PTP-synchronized timer.

4.1.  Using a Recommended Timestamp Format

   A specification that uses one of the recommended timestamp specification formats
   should clearly
   state the reasons for defining a new format.  Moreover, it specify explicitly that this is a recommended timestamp
   format, and point to derive the new relevant section in the current memo.

4.2.  NTP Timestamp Formats

4.2.1.  NTP 64-bit Timestamp Format

   The Network Time Protocol (NTP) 64-bit timestamp format from an existing
   timestamp format, either a is defined in
   [RFC5905].  This timestamp format from is used in several network
   protocols, including [RFC6374], [RFC4656], and [RFC5357].  Since this memo, or any
   other previously defined timestamp format.

   This section defines a template for specifying packet
   timestamp
   formats.  A format is used in NTP, this timestamp format specification MUST include should be
   preferred in network protocols that are typically deployed in concert
   with NTP.

   The format is presented in this section according to the following
   aspects: template
   defined in Section 3.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            Seconds                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            Fraction                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 1: NTP [RFC5905] 64-bit Timestamp Format

   Timestamp field format:

      The format

      Seconds: specifies the integer portion of the timestamp field consists of:

      + Size: The number of bits (or octets) used to represent seconds
      since the
      packet timestamp field. epoch.

      + Size: 32 bits.

      + Units: The units used to represent the timestamp.

      If the timestamp is comprised of more than one field, the format
      of each field is specified.

   Epoch:

      The origin of the timescale used for seconds.

      Fraction: specifies the timestamp; fractional portion of the moment in
      time used as a reference for number of
      seconds since the timestamp value.

   Resolution:

      The timestamp resolution; epoch.

      + Size: 32 bits.

      + Units: the resolution unit is 2^(-32) seconds, which is roughly equal to the
      233 picoseconds.

   Epoch:

      The epoch is 1 January 1900 at 00:00 UTC.

   Leap seconds:

      This timestamp
      field unit.  If the format is affected by leap seconds.  The timestamp consists
      represents the number of two or more fields using
      different time units, then seconds elapsed since the epoch minus the
      number of leap seconds.

   Resolution:

      The resolution is the smallest time
      unit. 2^(-32) seconds.

   Wraparound:

      This time format wraps around every 2^32 seconds, which is roughly
      136 years.  The next wraparound period of will occur in the timestamp; any further wraparound-
      related considerations should be described here.

4.  Recommended year 2036.

4.2.2.  NTP 32-bit Timestamp Formats Format

   The Network Time Protocol (NTP) 32-bit timestamp format is defined in
   [RFC5905].  This memo recommends to use one of the timestamp formats specified
   below.

   Clearly, different format is used in
   [I-D.ietf-ippm-initial-registry].  This timestamp format should be
   preferred in network protocols may have different requirements
   and constraints, and consequently may use different timestamp
   formats. that are typically deployed in concert
   with NTP.  The choice 32-bit format can be used either when space
   constraints do not allow the use of the specific timestamp format for a given
   protocol may depend on a various factors.  A few examples 64-bit format, or when the
   32-bit format satisfies the resolution and wraparound requirements.

   The format is presented in this section according to the template
   defined in Section 3.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Seconds              |           Fraction            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 2: NTP [RFC5905] 32-bit Timestamp Format

   Timestamp field format:

      Seconds: specifies the integer portion of factors
   that may affect the choice number of seconds
      since the timestamp format:

   o  Timestamp size: while some network protocols may allow a large
      timestamp fields, in other cases there may be constraints with
      respect to epoch.

      + Size: 16 bits.

      + Units: seconds.

      Fraction: specifies the timestamp size, affecting fractional portion of the choice number of
      seconds since the
      timestamp format.

   o  Resolution: epoch.

      + Size: 16 bits.

      + Units: the time resolution unit is another factor that may
      directly affect the selected 2^(-16) seconds, which is roughly equal to
      15.3 microseconds.

   Epoch:

      The epoch is 1 January 1900 at 00:00 UTC.

   Leap seconds:

      This timestamp format.  Similarly, format is affected by leap seconds.  The timestamp
      represents the
      wraparound periodicity number of seconds elapsed since the timestamp may also affect the
      selected format.

   o  Wraparound period: epoch minus the length
      number of the leap seconds.

   Resolution:

      The resolution is 2^(-16) seconds.

   Wraparound:

      This time interval in format wraps around every 2^16 seconds, which the
      timestamp is unique may also be roughly
      18 hours.

4.3.  The PTP Truncated Timestamp Format

   The Precision Time Protocol (PTP) [IEEE1588] uses an important factor in choosing
      the 80-bit timestamp
   format.  Along with the  The truncated timestamp resolution, these
      two factors determine format is a 64-bit field, which is
   the required number of 64 least significant bits in the
      timestamp.

   o  Common format for multiple protocols: if there are two or more
      network protocols that use timestamps and are often of the 80-bit PTP timestamp.  Since
   this timestamp format is similar to the one used together in typical systems, using a common PTP, this
   timestamp format should be preferred if possible.  Specifically, if the in network protocol protocols that
      is being defined are
   typically runs on a PC, then an NTP-based deployed in PTP-capable devices.

   The PTP truncated timestamp format may allow easier integration with an NTP-
      synchronized timer.  In contrast, a protocol that is typically
      deployed on a hardware-based platform, may make better use of a
      PTP-based timestamp, allowing more efficient integration with a
      PTP-synchronized timer.

4.1.  Using a Recommended used in several protocols, such
   as [RFC6374], [RFC7456], [RFC8186] and [ITU-T-Y.1731].

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            Seconds                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Nanoseconds                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 3: PTP [IEEE1588] Truncated Timestamp Format

   A specification that uses one

   Timestamp field format:

      Seconds: specifies the integer portion of the recommended timestamp formats
   should specify explicitly that number of seconds
      since the epoch.

      + Size: 32 bits.

      + Units: seconds.

      Nanoseconds: specifies the fractional portion of the number of
      seconds since the epoch.

      + Size: 32 bits.

      + Units: nanoseconds.  The value of this field is a recommended timestamp
   format, and point to in the relevant section range 0
      to (10^9)-1.

   Epoch:

      The PTP [IEEE1588] epoch is 1 January 1970 00:00:00 TAI, which is
      31 December 1969 23:59:51.999918 UTC.

   Leap seconds:

      This timestamp format is not affected by leap seconds.

   Resolution:

      The resolution is 1 nanosecond.

   Wraparound:

      This time format wraps around every 2^32 seconds, which is roughly
      136 years.  The next wraparound will occur in the current memo. year 2106.

5.  Synchronization Aspects

   A specification that defines a new timestamp format or uses one of
   the recommended timestamp formats should also include a section on
   Synchronization Aspects.  Any  Examples of such a section can be found in
   Section 6).

   The Synchronization Aspects section should specify all the
   assumptions or and requirements related to synchronization should be
   specified in this section. synchronization.  For
   example, the synchronization aspects may specify whether nodes
   populating the timestamps should be synchronized among themselves,
   and whether the timestamp is measured with respect to a central
   reference clock such as an NTP server.  If time is assumed to be
   synchronized to a time standard such as UTC or TAI, it should be
   specified in this section.  Further considerations may be discussed
   in this section, such as the required accuracy, or timestamp accuracy.

   Another aspect that should be discussed in this section is leap
   second handling.

4.2.  NTP Timestamp Formats

4.2.1.  NTP 64-bit Timestamp Format [RFC5905] considerations.  The Network Time Protocol (NTP) 64-bit timestamp format is defined in
   [RFC5905].  This specification
   template (Section 3) specifies whether the timestamp format is used in several network
   protocols, including [RFC6374], [RFC4656], and [RFC5357].  Since this
   timestamp format affected by
   leap seconds.  It is used in NTP, this timestamp format should often the case that further details about leap
   seconds will need to be
   preferred defined in network protocols the Synchronization Aspects
   section.  Generally speaking, in a timekeeping system that are typically deployed considers
   leap seconds, the system clock may be affected by a leap second in concert
   with NTP.
   one of three possible ways:

   o  The format clock is presented in this section according to the template
   defined in Section 3.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            Seconds                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            Fraction                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 1: NTP [RFC5905] 64-bit Timestamp Format

   Timestamp field format:

      Seconds: specifies turned backwards one second at the integer portion end of the number leap
      second.

   o  The clock is frozen during the duration of seconds
      since the epoch.

      + Size: 32 bits.

      + Units: seconds.

      Fraction: specifies leap second.

   o  The clock is slowed down during and slightly after the fractional portion duration of
      the number of
      seconds since leap second, until the epoch.

      + Size: 32 bits.

      + Units: new time value catches up.

   The way leap seconds are handled depends on the unit synchronization
   protocol, and is 2^(-32) seconds, which thus not specified in this document.  However, if a
   timestamp format is roughly equal defined with respect to
      233 picoseconds.

   Epoch:

      The epoch is 1 January 1900 at 00:00 UTC.

   Resolution:

      The resolution a timescale that is 2^(-32) seconds.

   Wraparound:

      This time format wraps around every 2^32
   affected by leap seconds, which is roughly
      136 years.  The next wraparound will occur the Synchronization Aspects section should
   specify how the use of leap seconds affects the timestamp usage.

6.  Timestamp Use Cases

   Packet timestamps are used in various network protocols.  Typical
   applications of packet timestamps include delay measurement, clock
   synchronization, and others.  The following table presents a (non-
   exhaustive) list of protocols that use packet timestamps, and the year 2036.

4.2.2.  NTP
   timestamp formats used in each of these protocols.

   +------------------+-----------------------------------+-----------+
   |                  |       Recommended formats         |  Other    |
   +------------------+-----------+-----------+-----------+  format   |
   | Protocol         |NTP 64-bit |NTP 32-bit Timestamp Format |PTP Trunc. |           |
   +------------------+-----------+-----------+-----------+-----------+
   | NTP   [RFC5905]  |     +     |           |           |           |
   +------------------+-----------+-----------+-----------+-----------+
   | OWAMP [RFC4656]  |     +     |           |           |           |
   +------------------+-----------+-----------+-----------+-----------+
   | TWAMP [RFC5357]  |     +     |           |           |           |
   | TWAMP [RFC8186]  |           |           |     +     |           |
   +------------------+-----------+-----------+-----------+-----------+
   | TRILL [RFC7456]  |           |           |     +     |           |
   +------------------+-----------+-----------+-----------+-----------+
   | MPLS  [RFC6374]  |           |           |     +     |           |
   +------------------+-----------+-----------+-----------+-----------+
   | TCP   [RFC1323]  |           |           |           |     +     |
   +------------------+-----------+-----------+-----------+-----------+
   | RTP   [RFC3550]  |     +     |           |           |     +     |
   +------------------+-----------+-----------+-----------+-----------+
   | [I-D.ietf-ippm-  |     +     |     +     |           |           |
   | initial-registry]|           |           |           |           |
   +------------------+-----------+-----------+-----------+-----------+

              Figure 4: Protocols that use Packet Timestamps

   The Network Time Protocol (NTP) 32-bit timestamp format is defined in
   [RFC5905].  This timestamp format is used in
   [I-D.morton-ippm-mbm-registry].  This timestamp format should be
   preferred in rest of this section presents two hypothetic examples of network protocols
   protocol specifications that are typically deployed in concert
   with NTP.  The 32-bit format can be used either when space
   constraints do not allow the use one of the 64-bit format, or when recommended timestamp
   formats.  The examples include the
   32-bit format satisfies text that specifies the resolution and wraparound requirements.
   information related to the timestamp format.

6.1.  Example 1

   Timestamp:

      The timestamp format is presented used in this section according to specification is the template
   defined in Section 3.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Seconds              |           Fraction            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 2: NTP
      [RFC5905] 32-bit Timestamp Format

   Timestamp field format:

      Seconds: specifies the integer portion 64-bit format, as specified in Section 4.2.1 of
      [I-D.ietf-ntp-packet-timestamps].

   Synchronization aspects:

      It is assumed that nodes that run this protocol are synchronized
      to UTC using a synchronization mechanism that is outside the number scope
      of seconds
      since this document.  In typical deployments this protocol will run
      on a machine that uses NTP [RFC5905] for synchronization.  Thus,
      the epoch.

      + Size: 16 bits.

      + Units: seconds.

      Fraction: specifies timestamp may be derived from the fractional portion of NTP-synchronized clock,
      allowing the timestamp to be measured with respect to the number clock of
      seconds since the epoch.

      + Size: 16 bits.

      + Units:
      an NTP server.  Since the unit NTP time format is 2^(-16) affected by leap
      seconds, which is roughly equal to
      15.3 microseconds.

   Epoch:

      The epoch the current timestamp format is 1 January 1900 at 00:00 UTC.

   Resolution: similarly affected.
      Thus, the value of a timestamp during or slightly after a leap
      second may be temporarily inaccurate.

6.2.  Example 2

   Timestamp:

      The resolution is 2^(-16) seconds.

   Wraparound:

      This time timestamp format wraps around every 2^16 seconds, which used in this specification is roughly
      18 hours.

4.3.  The the PTP
      [IEEE1588] Truncated Timestamp Format

   The Precision Time Protocol (PTP) format, as specified in Section 4.2.3 of
      [I-D.ietf-ntp-packet-timestamps].

   Synchronization aspects:

      It is assumed that nodes that run this protocol are synchronized
      among themselves.  Nodes may be synchronized to a global reference
      time.  Note that if PTP [IEEE1588] uses is used for synchronization,
      the timestamp may be derived from the PTP-synchronized clock,
      allowing the timestamp to be measured with respect to the clock of
      an 80-bit PTP Grandmaster clock.

7.  Packet Timestamp Control Field

   In some cases it is desirable to have a control field that includes
   information about the timestamp format.  The truncated  Control information about
   the timestamp format can be conveyed in some protocols using a
   dedicated control plane protocol, or may be made available at the
   management plane, for example using a YANG data model.  The optional
   control field that is defined in this section allows some of the
   control information to be attached to the timestamp.  This section
   defines requirements and a recommended format of a timestamp-related
   control field that is intended for network protocols that can benefit
   from such timestamp-related control information.

7.1.  High-level Control Field Requirements

   A control field for packet timestamps must offer an adequate feature
   set and fulfill a 64-bit field, which is
   the 64 least significant bits series of the 80-bit PTP timestamp.  Since
   this timestamp format is similar requirements to be usable and accepted.
   The following list captures the one used in PTP, this main high-level requirements for
   timestamp format should be preferred in network fields.

   1.  Extensible Feature Set: protocols and applications depend on
       various timestamp characteristics.  A timestamp control field
       must support a variable number of elements (components) that are
   typically deployed in PTP-capable devices.

   The PTP truncated
       either describe or quantify timestamp-specific characteristics or
       parameters.  Examples of potential elements include timestamp format
       accuracy, leap seconds, reference clock identifiers, etc.

   2.  Size: Essential for an efficient use of timestamp control fields
       is used in several protocols, such
   as [RFC6374], [RFC7456], [RFC8186] the trade-off between supported features and [ITU-T-Y.1731].

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            Seconds                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Nanoseconds                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 3: PTP [IEEE1588] Truncated Timestamp Format

   Timestamp control field format:

      Seconds: specifies
       size.  Protocols and applications may select the integer portion of specific control
       field elements that are needed for their operation from the number set
       of seconds
      since the epoch.

      + Size: 32 bits.

      + Units: seconds.

      Nanoseconds: specifies the fractional portion available elements.

   3.  Composition: Applications may depend on specific control field
       elements being present in messages.  The status of these elements
       may be either mandatory, conditional mandatory, or optional,
       depending on the number specific application and context.  This memo
       must support applications in conveying or negotiating (a) the set
       of
      seconds since control field elements along with (b) the epoch.

      + Size: 32 bits.

      + Units: nanoseconds.  The value status of this any
       element (i.e., mandatory, conditional mandatory, or optional) by
       defining appropriate data structures and identity codes.

   4.  Category: Control field is elements can characterize either static
       timestamp information (like, e.g., timestamp size in bytes and
       timestamp semantics: NTP 64 bit format) or runtime timestamp
       information (like, e.g., estimated timestamp accuracy at the range 0 time
       of sampling: 20 microseconds to (10^9)-1.

   Epoch:

      The PTP [IEEE1588] epoch is 1 January 1970 00:00:00 TAI, which is
      31 December 1969 23:59:51.999918 UTC.

   Resolution:

      The resolution UTC).  For efficiency reason it
       is 1 nanosecond.

   Wraparound:

      This time format wraps around every 2^32 seconds, which meaningful to support separation of these two concepts: while
       the former (static) information is roughly
      136 years.  The next wraparound will occur in typically valid throughout a
       protocol session and may be conveyed only once, at session
       establishment time, the year 2106.

5.  Timestamp Use Cases

   Packet timestamps are used in various network latter (runtime) information augments any
       timestamp instance and may cause substantial overhead for high-
       traffic protocols.  Typical
   applications

7.2.  Control Field Categories

   Depending on their characteristics, the elements or components of packet timestamps include delay measurement, clock
   synchronization, and others.  The following table presents a (non-
   exhaustive) list
   timestamp control field can be assigned to one of protocols that two categories:
   Structure (static) or Instance (runtime).  Aim of this categorization
   is to support minimum overhead of timestamp control fields in
   practice.  Protocols may use packet timestamps, and structural elements once, at connection
   setup time to define or negotiate the timestamp formats used in each structure and instace
   elements (repeatedly) to identify the quality of these protocols.

   +------------------+-----------------------------------+-----------+
   |                  |       Recommended formats         |  Other    |
   +------------------+-----------+-----------+-----------+  format   |
   | Protocol         |NTP 64-bit |NTP 32-bit |PTP Trunc. |           |
   +------------------+-----------+-----------+-----------+-----------+
   | NTP   [RFC5905]  |     +     |           |           |           |
   +------------------+-----------+-----------+-----------+-----------+
   | OWAMP [RFC4656]  |     +     |           |           |           |
   +------------------+-----------+-----------+-----------+-----------+
   | TWAMP [RFC5357]  |     +     |           |           |           |
   | TWAMP [RFC8186]  |           |           |     +     |           |
   +------------------+-----------+-----------+-----------+-----------+
   | TRILL [RFC7456]  |           |           |     +     |           |
   +------------------+-----------+-----------+-----------+-----------+
   | MPLS  [RFC6374]  |           |           |     +     |           |
   +------------------+-----------+-----------+-----------+-----------+
   | TCP   [RFC1323]  |           |           |           |     +     |
   +------------------+-----------+-----------+-----------+-----------+
   | RTP   [RFC3550]  |     +     |           |           |     +     |
   +------------------+-----------+-----------+-----------+-----------+

              Figure 4: Protocols timestamp instances
   at runtime.

   1.  <Structure>: static timestamp control field.  The static control
       field identifies information like timestamp structure, type,
       size, or features, that characterize and are common to a set of
       related timestamps.  Typical use Packet Timestamps

   The rest of this section presents two hypothetic examples such a control field is at
       connection establishment time when protocols negotiate available
       and preferred timestamp types and features to be used for the
       lifetime of network an association.  For instance endpoints can specify
       the type, structure and size of the timestamp representation
       within protocol specifications messages that use one will be exchanged as part of the recommended a
       following protocol session.  These can be either standard
       timestamp formats like NTP 64 bit as specified by this memo or
       specific vendor-defined timestamp formats.  The

   2.  <Instance>: runtime timestamp control field.  Besides static
       information, dynamic (runtime) timestamp information is commonly
       available at the sender when sampling a specific timestamp
       instance.  Typical examples include the text ID of a clock that specifies
       originated a specific timestamp, the estimated time
       synchronization accuracy of the local reference clock when
       sampling a specific timestamp, or the correction to apply due to
       an ongoing leap smear for a leap second.  Moreover, with today's
       critical infrastructures depending increasingly on accurate time,
       provable signatures may become an essential runtime parameter to
       protect the integrity of timestamp and control field values.  The
       accurate and reliable operation of timestamp receivers can
       benefit from this detailed runtime control field information related that
       augments any single timestamp.

   Drawing analogies to programming languages, the static timestamp format.

5.1.
   control field maps best to concepts like "type", "structure", or
   "template", whereas the runtime timestamp control field corresponds
   to "variables", i.e., runtime-instantiations of types.  Main
   consequence is that static timestamp control fields may be exchanged
   only once during an ongoing association, saving substantial link
   capacity, whereas a runtime timestamp control field accompanies any
   single message or timestamp instance.  Still, some protocols may
   prefer to augment any single timestamp instance with both, a static
   and a runtime control field.  Example 1

   Timestamp:

      The use cases for the latter
   variant include potential support for heterogeneity in terms of
   timestamps - various clients can decide dynamically which timestamp
   format used they send as part of the protocol - or to include a maximum of
   timestamp context for receivers in this specification the case of sporadic messages.

7.3.  Control Field Features and Elements

   The timestamp control field is composed of elements that can be
   selected from the following set:

   o  Timestamp format

   o  Timestamp format specification

   o  Precision

   o  Timescale

   o  Leap second

   o  Reference clock(s)

   o  Probable signature

   o  Custom extension

   o  ... (tbd)

   The following subsections detail on the NTP
      [RFC5905] 64-bit format, as specified in Section 4.2.1 role of
      [I-D.mizrahi-intarea-packet-timestamps].

   Synchronization aspects:

      It the elements, their
   structure and related constraints.  Any element is assumed that nodes that run characterized by
   the following parameters:

   o  ID: <IANA identifier for this protocol are synchronized element>

   o  Type: Either <structure>: element defines static timestamp
      structure that can subsequently be used to describe several
      instances of timestamps - typically used once during connection
      setup, or <instance>: parameter characteristic to UTC using a synchronization mechanism that is outside specific
      timestamp instance.

   o  Status: <mandatory>, <conditional mandatory>, or <optional>.
      Note: interpretation of the scope status field depends on the value of
      the type field.  If type is <structure>, then status <mandatory>
      means that this document.  In typical deployments this protocol will element must be
      run on a machine that uses NTP [RFC5905] for synchronization.
      Thus, the part of any <structure>-type
      timestamp control field.  However, it may be derived from the NTP-synchronized
      clock, allowing part of <instance>-
      type timestamp control field, too.

   o  Size: <the size of this element, including all elements>

   o  Value: the value or subfields of this element

   o  Comments: Additions and considerations for this element

7.3.1.  Timestamp Format

   The timestamp to be measured with respect to format field defines the
      clock size and semantics of the
   timestamp that follows this timestamp control field by referencing
   appropriate IANA IDs.

   o  ID: tbd

   o  Type: <structure>

   o  Status: <mandatory>

   o  Size: tbd

   o  Value: IANA identifier, referencing either a standard format
      defined by this memo or an NTP server.

5.2.  Example 2

   Timestamp: alternate timestamp format (e.g.
      vendor-specific extension).  In the latter case, a Timestamp
      Format Specification field is conditional mandatory.

   o  Comments:

7.3.2.  Timestamp Format Specification

   The timestamp format used in this specification field defines the structure and
   size of custom timestamps and is needed whenever the PTP
      [IEEE1588] Truncated format, as specified in Section 4.2.3 use of
      [I-D.mizrahi-intarea-packet-timestamps].

   Synchronization aspects:

      It standard
   timestamp formats is assumed that nodes that run this protocol are synchronized
      among themselves.  Nodes may inappropriate.

   o  ID: tbd

   o  Type: <structure>

   o  Status: <conditional mandatory>.  This field must be synchronized included
      whenever the "timestamp format" element references non-standard
      timestamp formats and must not be included into the control field
      otherwise.

   o  Size: tbd

   o  Value: Subfields: 1.  Timestamp size; 2.  User- or vendor-specific
      id and 3.  Sub-id that allow to a global reference
      time.  Note uniquely identify this timestamp
      type;

   o  Comments:

7.3.3.  Timestamp Precision

   The precision field value stores the precision of the clock that if PTP [IEEE1588] is used for synchronization,
   originated the timestamp may be derived from at the PTP-synchronized clock,
      allowing time when the timestamp to be measured was sampled
   along with respect to attributes that characterize the timestamp quality (like
   absolute or relative synchronization, reference clock identifiers,
   etc.)

   o  ID: tbd

   o  Type: <instance> (optionally: <structure> when the clock
      originating the timestamps has maximum limits for precision)?

   o  Status: <optional>.  The local system may or may not know the
      precision (or accuracy) of
      an PTP Grandmaster clock.

6.  Packet Timestamp Control Field

   In some cases it is desirable its clock and sampled timestamps.

   o  Size: tbd

   o  Value: Subfields: 1.  Estimated Precision (in terms of 10^(-x)),
      2.  Maximum Error, 3.  Reference (Absolute: UTC, TAI ...,
      Relative: to have a control specific clock, needs reference to clock ID)

   o  Comments: NTF calls this "error".

7.3.4.  Timestamp Timescale

   The timescale field that includes
   information about denotes Epoch and Era of the timestamp format.  This section defines a
   recommended format of a timestamp-related control field that is
   intended for network protocols that require such timestamp-related
   control information.

   The recommended

   o  ID: tbd

   o  Type: <instance>

   o  Status: <optional>

   o  Size: tbd

   o  Value: Subfields: 1. epoch 2. era

   o  Comments:

7.3.5.  Timestamp Leap Second

   o  ID: tbd

   o  Type: <instance>
   o  Status: <optional>

   o  Size: tbd

   o  Value: Subfields: 1.  Leap second ongoing 2.  Considered leap
      second fraction (during leap smear)

   o  Comments:

7.3.6.  Reference Clock

   o  ID: tbd

   o  Type: <instance> (perhaps <structure>, too)

   o  Status: <optional>

   o  Size: tbd

   o  Value: Subfields: 1.  Reference clock type 2.  Unique reference
      clock ID

   o  Comments:

7.3.7.  Provable Signature

   o  ID: tbd

   o  Type: <instance>

   o  Status: <optional>

   o  Size: tbd

   o  Value: Signature covering the entire timstamp control field includes and
      the following sub-fields: timestamp field, masking out the provable signature field with
      0.

   o  Timestamp format.  Comments:

7.3.8.  Custom Extension

   o  Precision - the resolution  ID: tbd

   o  Type: <structure> or granularity of the system clock. <instance>

   o  Epoch.  Status: <optional>
   o  Era -  Size: tbd

   o  Value: tbd

   o  Comments: For future extensions

7.4.  Control Field Payload Definition

   This section defines the number binding format of times the time has wrapped around since the
      epoch.

7. timestamp control
   (sub)fields to be used by protocols. (tbd)

8.  IANA Considerations

   This memo includes no request to IANA.

8.

9.  Security Considerations

   A network protocol that uses a packet timestamp MUST specify the
   security considerations that result from using the timestamp.  This
   section provides an overview of some of the common security
   considerations of using timestamps.

   Any metadata that is attached to control or data packets, and
   specifically packet timestamps, can facilitate network
   reconnaissance; by passively eavesdropping to timestamped packets an
   attacker can gather information about the network performance, and
   about the level of synchronization between nodes.

   Timestamps can be spoofed or modified by on-path attackers, thus
   attacking the application that uses the timestamps.  For example, if
   timestamps are used in a delay measurement protocol, an attacker can
   modify en route timestamps in a way that manipulates the measurement
   results.  Integrity protection mechanisms, such as Hashed Message
   Authentication Codes (HMAC), can mitigate such attacks.  The
   specification of an integrity protection mechanism is outside the
   scope of this document, as typically integrity protection will be
   defined on a per-network-protocol basis, and not specifically for the
   timestamp field.

   Another potential threat that can have a similar impact is delay
   attacks.  An attacker can maliciously delay some or all of the en
   route messages, with the same harmful implications as described in
   the previous paragraph.  Mitigating delay attacks is a significant
   challenge; in contrast to spoofing and modification attacks, the
   delay attack cannot be prevented by cryptographic integrity
   protection mechanisms.  In some cases delay attacks can be mitigated
   by sending the timestamped information through multiple paths,
   allowing to detect and to be resilient to an attacker that has access
   to one of the paths.

   In many cases timestamping relies on an underlying synchronization
   mechanism.  Thus, any attack that compromises the synchronization
   mechanism can also compromise protocols that use timestamping.
   Attacks on time protocols are discussed in detail in [RFC7384].

9.

10.  Acknowledgments

   The authors thank Yaakov Stein Stein, Greg Mirsky, Warner Losh, Rodney
   Cummings and other members of the TICTOC and NTP working groups group for many helpful
   comments.

10.  The authors gratefully acknowlege Harlan Stenn and the
   people from the Network Time Foundation for sharing their thoughts
   and ideas.

11.  References

10.1.

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

10.2.

11.2.  Informative References

   [I-D.mizrahi-intarea-packet-timestamps]

   [I-D.ietf-ippm-initial-registry]
              Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza,
              "Initial Performance Metric Registry Entries", draft-ietf-
              ippm-initial-registry-06 (work in progress), March 2018.

   [I-D.ietf-ntp-packet-timestamps]
              Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
              Defining Packet Timestamps", draft-mizrahi-intarea-packet-
              timestamps-01 (work in progress), September 2017.

   [I-D.morton-ippm-mbm-registry]
              Morton, A. and M. Mathis, "Initial Performance Metric
              Registry Entries Part 2: MBM", draft-morton-ippm-mbm-
              registry-01 draft-ietf-ntp-packet-
              timestamps-00 (work in progress), March October 2017.

   [IEEE1588]
              IEEE, "IEEE 1588 Standard for a Precision Clock
              Synchronization Protocol for Networked Measurement and
              Control Systems Version 2", 2008.

   [ITU-T-Y.1731]
              ITU-T, "OAM functions and mechanisms for Ethernet based
              Networks", 2013.

   [RFC1323]  Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
              for High Performance", RFC 1323, DOI 10.17487/RFC1323, May
              1992, <https://www.rfc-editor.org/info/rfc1323>.

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
              <https://www.rfc-editor.org/info/rfc3339>.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <https://www.rfc-editor.org/info/rfc3550>.

   [RFC4656]  Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
              Zekauskas, "A One-way Active Measurement Protocol
              (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
              <https://www.rfc-editor.org/info/rfc4656>.

   [RFC5357]  Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
              Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
              RFC 5357, DOI 10.17487/RFC5357, October 2008,
              <https://www.rfc-editor.org/info/rfc5357>.

   [RFC5646]  Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
              Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
              September 2009, <https://www.rfc-editor.org/info/rfc5646>.

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/info/rfc5905>.

   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", RFC 6374,
              DOI 10.17487/RFC6374, September 2011,
              <https://www.rfc-editor.org/info/rfc6374>.

   [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
              RFC 6991, DOI 10.17487/RFC6991, July 2013,
              <https://www.rfc-editor.org/info/rfc6991>.

   [RFC7384]  Mizrahi, T., "Security Requirements of Time Protocols in
              Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
              October 2014, <https://www.rfc-editor.org/info/rfc7384>.

   [RFC7456]  Mizrahi, T., Senevirathne, T., Salam, S., Kumar, D., and
              D. Eastlake 3rd, "Loss and Delay Measurement in
              Transparent Interconnection of Lots of Links (TRILL)",
              RFC 7456, DOI 10.17487/RFC7456, March 2015,
              <https://www.rfc-editor.org/info/rfc7456>.

   [RFC7493]  Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
              DOI 10.17487/RFC7493, March 2015,
              <https://www.rfc-editor.org/info/rfc7493>.

   [RFC8186]  Mirsky, G. and I. Meilik, "Support of the IEEE 1588
              Timestamp Format in a Two-Way Active Measurement Protocol
              (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017,
              <https://www.rfc-editor.org/info/rfc8186>.

Authors' Addresses

   Tal Mizrahi
   Marvell
   6 Hamada st.
   Yokneam
   Israel

   Email: talmi@marvell.com

   Joachim Fabini
   Vienna University of Technology
   Gusshausstrasse 25/E389
   Vienna 1040
   Austria

   Phone: +43 1 58801 38813
   Fax:   +43 1 58801 38898
   Email: Joachim.Fabini@tuwien.ac.at
   URI:   http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/

   Al Morton
   AT&T Labs
   200 Laurel Avenue South
   Middletown,, NJ  07748
   USA

   Phone: +1 732 420 1571
   Fax:   +1 732 368 1192
   Email: acmorton@att.com
   URI:   http://home.comcast.net/~acmacm/