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


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

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, 2018.

Copyright Notice

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



Mizrahi, et al.          Expires April 29, 2018                 [Page 1]


Internet-Draft              Packet Timestamps               October 2017


   (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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Packet Timestamp Format Specification . . . . . . . . . . . .   3
   4.  Recommended Timestamp Formats . . . . . . . . . . . . . . . .   4
     4.1.  Using a Recommended Timestamp Format  . . . . . . . . . .   5
     4.2.  NTP Timestamp Formats . . . . . . . . . . . . . . . . . .   5
       4.2.1.  NTP 64-bit Timestamp Format . . . . . . . . . . . . .   5
       4.2.2.  NTP 32-bit Timestamp Format . . . . . . . . . . . . .   6
     4.3.  The PTP Truncated Timestamp Format  . . . . . . . . . . .   8
   5.  Timestamp Use Cases . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Example 1 . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.2.  Example 2 . . . . . . . . . . . . . . . . . . . . . . . .  10
   6.  Packet Timestamp Control Field  . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     10.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  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




Mizrahi, et al.          Expires April 29, 2018                 [Page 2]


Internet-Draft              Packet Timestamps               October 2017


   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]

3.  Packet Timestamp Format Specification

   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.

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

   Timestamp field format:

      The format of the timestamp field consists of:

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

      + Units: The units used to represent the timestamp.



Mizrahi, et al.          Expires April 29, 2018                 [Page 3]


Internet-Draft              Packet Timestamps               October 2017


      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 the timestamp; the moment in
      time used as a reference for the timestamp value.

   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.

4.  Recommended Timestamp Formats

   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 may allow a large
      timestamp fields, in other 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.  Similarly, the
      wraparound periodicity of the timestamp may also affect the
      selected format.

   o  Wraparound period: the length of the time interval in which the
      timestamp is unique may also be an important factor in choosing
      the timestamp format.  Along with the timestamp resolution, these
      two factors determine the required number of bits in the
      timestamp.





Mizrahi, et al.          Expires April 29, 2018                 [Page 4]


Internet-Draft              Packet Timestamps               October 2017


   o  Common format for multiple protocols: if there are two or more
      network protocols that use timestamps and are often used together
      in typical systems, using a common timestamp format should be
      preferred if possible.  Specifically, if the network protocol that
      is being defined typically runs on a PC, then an NTP-based
      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 Timestamp Format

   A specification that uses one of the recommended timestamp formats
   should specify explicitly that this is a recommended timestamp
   format, and point to the relevant section in the current memo.

   A specification that uses one of the recommended timestamp formats
   should also include a section on Synchronization Aspects.  Any
   assumptions or requirements related to synchronization should be
   specified in this section.  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 required accuracy, or leap
   second handling.

4.2.  NTP Timestamp Formats

4.2.1.  NTP 64-bit Timestamp Format

   The Network Time Protocol (NTP) 64-bit timestamp format is defined in
   [RFC5905].  This timestamp format is used in several network
   protocols, including [RFC6374], [RFC4656], and [RFC5357].  Since this
   timestamp format is used in NTP, this timestamp format should be
   preferred in network protocols that are typically deployed in concert
   with NTP.

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









Mizrahi, et al.          Expires April 29, 2018                 [Page 5]


Internet-Draft              Packet Timestamps               October 2017


        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 the integer portion of the number of seconds
      since the epoch.

      + Size: 32 bits.

      + Units: seconds.

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

      + Size: 32 bits.

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

   Epoch:

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

   Resolution:

      The resolution is 2^(-32) seconds.

   Wraparound:

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

4.2.2.  NTP 32-bit Timestamp Format

   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 network protocols that are typically deployed in concert
   with NTP.  The 32-bit format can be used either when space




Mizrahi, et al.          Expires April 29, 2018                 [Page 6]


Internet-Draft              Packet Timestamps               October 2017


   constraints do not allow the use of the 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 the number of seconds
      since the epoch.

      + Size: 16 bits.

      + Units: seconds.

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

      + Size: 16 bits.

      + Units: the unit is 2^(-16) seconds, which is roughly equal to
      15.3 microseconds.

   Epoch:

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

   Resolution:

      The resolution is 2^(-16) seconds.

   Wraparound:

      This time format wraps around every 2^16 seconds, which is roughly
      18 hours.







Mizrahi, et al.          Expires April 29, 2018                 [Page 7]


Internet-Draft              Packet Timestamps               October 2017


4.3.  The PTP Truncated Timestamp Format

   The Precision Time Protocol (PTP) [IEEE1588] uses an 80-bit timestamp
   format.  The truncated timestamp format is a 64-bit field, which is
   the 64 least significant bits of the 80-bit PTP timestamp.  Since
   this timestamp format is similar to the one used in PTP, this
   timestamp format should be preferred in network protocols that are
   typically deployed in PTP-capable devices.

   The PTP truncated timestamp format is 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

   Timestamp field format:

      Seconds: specifies the integer portion of the 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 in the 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.

   Resolution:

      The resolution is 1 nanosecond.



Mizrahi, et al.          Expires April 29, 2018                 [Page 8]


Internet-Draft              Packet Timestamps               October 2017


   Wraparound:

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

5.  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
   timestamp formats used in each 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 that use Packet Timestamps

   The rest of this section presents two hypothetic examples of network
   protocol specifications that use one of the recommended timestamp
   formats.  The examples include the text that specifies the
   information related to the timestamp format.

5.1.  Example 1

   Timestamp:






Mizrahi, et al.          Expires April 29, 2018                 [Page 9]


Internet-Draft              Packet Timestamps               October 2017


      The timestamp format used in this specification is the NTP
      [RFC5905] 64-bit format, as specified in Section 4.2.1 of
      [I-D.mizrahi-intarea-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 scope
      of this document.  In typical deployments this protocol will be
      run on a machine that uses NTP [RFC5905] for synchronization.
      Thus, the timestamp may be derived from the NTP-synchronized
      clock, allowing the timestamp to be measured with respect to the
      clock of an NTP server.

5.2.  Example 2

   Timestamp:

      The timestamp format used in this specification is the PTP
      [IEEE1588] Truncated format, as specified in Section 4.2.3 of
      [I-D.mizrahi-intarea-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] 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 PTP Grandmaster clock.

6.  Packet Timestamp Control Field

   In some cases it is desirable to have a control field that includes
   information about 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 control field includes the following sub-fields:

   o  Timestamp format.

   o  Precision - the resolution or granularity of the system clock.

   o  Epoch.





Mizrahi, et al.          Expires April 29, 2018                [Page 10]


Internet-Draft              Packet Timestamps               October 2017


   o  Era - the number of times the time has wrapped around since the
      epoch.

7.  IANA Considerations

   This memo includes no request to IANA.

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





Mizrahi, et al.          Expires April 29, 2018                [Page 11]


Internet-Draft              Packet Timestamps               October 2017


9.  Acknowledgments

   The authors thank Yaakov Stein and other members of the TICTOC and
   NTP working groups for many helpful comments.

10.  References

10.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.  Informative References

   [I-D.mizrahi-intarea-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 (work in progress), March 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>.




Mizrahi, et al.          Expires April 29, 2018                [Page 12]


Internet-Draft              Packet Timestamps               October 2017


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





Mizrahi, et al.          Expires April 29, 2018                [Page 13]


Internet-Draft              Packet Timestamps               October 2017


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/


















Mizrahi, et al.          Expires April 29, 2018                [Page 14]