doc: Add RFC documents

1 files changed, 893 insertions, 0 deletions

diff --git a/doc/rfc/rfc8877.txt b/doc/rfc/rfc8877.txt
new file mode 100644
index 0000000..4412c51
--- /dev/null
+++ b/doc/rfc/rfc8877.txt
@@ -0,0 +1,893 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                        T. Mizrahi
+Request for Comments: 8877                                        Huawei
+Category: Informational                                        J. Fabini
+ISSN: 2070-1721                                                  TU Wien
+                                                               A. Morton
+                                                               AT&T Labs
+                                                          September 2020
+
+
+               Guidelines for Defining Packet Timestamps
+
+Abstract
+
+   Various network protocols make use of binary-encoded timestamps that
+   are incorporated in the protocol packet format, referred to as
+   "packet timestamps" for short.  This document specifies guidelines
+   for defining packet timestamp formats in networking protocols at
+   various layers.  It also presents three recommended timestamp
+   formats.  The target audience of this document 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 document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see 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/rfc8877.
+
+Copyright Notice
+
+   Copyright (c) 2020 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
+     1.1.  Background
+     1.2.  Scope of this Document
+     1.3.  How to Use This Document
+   2.  Terminology
+     2.1.  Requirements Language
+     2.2.  Abbreviations
+     2.3.  Terms Used in This Document
+   3.  Packet Timestamp Specification Template
+   4.  Recommended Timestamp Formats
+     4.1.  Using a Recommended Timestamp Format
+     4.2.  NTP Timestamp Formats
+       4.2.1.  NTP 64-Bit Timestamp Format
+       4.2.2.  NTP 32-Bit Timestamp Format
+     4.3.  The PTP Truncated Timestamp Format
+   5.  Synchronization Aspects
+   6.  Timestamp Use Cases
+     6.1.  Example 1
+     6.2.  Example 2
+   7.  Packet Timestamp Control Field
+     7.1.  High-Level Control Field Requirements
+   8.  IANA Considerations
+   9.  Security Considerations
+   10. References
+     10.1.  Normative References
+     10.2.  Informative References
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+1.1.  Background
+
+   Timestamps are widely used in network protocols for various purposes:
+   for logging or reporting the time of an event, for messages in delay
+   measurement and clock synchronization protocols, and as part of a
+   value that is unlikely to repeat (nonce) in security protocols.
+
+   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 [RFC7323].
+
+1.2.  Scope of this Document
+
+   This document 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 these recommended
+   timestamp formats.  In some cases, a network protocol may use more
+   than one of the recommended timestamp formats.  However, 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.
+
+   The rationale behind defining a relatively small set of recommended
+   formats is that it enables significant reuse; network protocols can
+   typically reuse the timestamp format of the Network Time Protocol
+   (NTP) [RFC5905] or the Precision Time Protocol (PTP) [IEEE1588],
+   allowing a straightforward integration with an NTP- or PTP-based
+   timer.  Moreover, since accurate timestamping mechanisms are often
+   implemented in hardware, a new network protocol that reuses an
+   existing timestamp format can be quickly deployed using existing
+   hardware timestamping capabilities.
+
+1.3.  How to Use This Document
+
+   This document is intended as a reference for network protocol
+   designers.  When defining a network protocol that uses a packet
+   timestamp, the recommended timestamp formats should be considered
+   first (Section 4).  If one of these formats is used, it should be
+   referenced along the lines of the examples in Sections 6.1 and 6.2.
+   If none of the recommended formats fits the required functionality,
+   then a new timestamp format should be defined using the template in
+   Section 3.
+
+2.  Terminology
+
+2.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+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:             A value that represents a point in time,
+                          corresponding to an event that occurred or is
+                          scheduled to occur.
+
+   Timestamp error:       The difference between the timestamp value and
+                          the value of a reference clock at the time of
+                          the event that the timestamp was intended to
+                          indicate.
+
+   Timestamp format:      The specification of a timestamp, which is
+                          represented by a set of attributes that
+                          unambiguously defines 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 document recommends using 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 document or any
+   other previously defined timestamp format.
+
+   The timestamp specification must unambiguously define the syntax and
+   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:
+      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.  Network order
+         (big endian) is assumed by default; if this is not the case,
+         then this section explicitly specifies the endianity.
+
+   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.  If a field is limited to a specific
+         range of values, this section specifies the permitted range of
+         values.
+
+      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 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 could be 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.
+
+   Synchronization aspects:
+      The specification of a network protocol that makes use of a packet
+      timestamp is expected to include the synchronization aspects of
+      using the timestamp.  While the synchronization aspects are not
+      strictly part of the timestamp format specification, these aspects
+      provide the necessary context for using the timestamp within the
+      scope of the protocol.  In some cases, timestamps are used without
+      synchronization, e.g., a timestamp that indicates the number of
+      seconds since power-up.  In such cases, the Synchronization
+      Aspects section will specify that the timestamp does not
+      correspond to a synchronized time reference and may discuss how
+      this affects the usage of the timestamp.  Further details about
+      synchronization aspects are discussed in Section 5.
+
+4.  Recommended Timestamp Formats
+
+   This document defines a set of recommended timestamp formats.
+   Clearly, different network protocols may have different requirements
+   and constraints; consequently, they may use different timestamp
+   formats.  The choice of a specific timestamp format for a given
+   protocol may depend on various factors.  A few examples of factors
+   that may affect the choice of the timestamp format include the
+   following:
+
+   *  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.
+
+   *  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 timestamp format to be extensible to a higher
+      resolution by extending the field.  For example, the resolution of
+      the NTP 32-bit timestamp format can be improved by extending it to
+      the NTP 64-bit timestamp format in a straightforward way.
+
+   *  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.
+
+   *  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.  For example, 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 document.
+
+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, it 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.
+
+        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 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.
+
+      Note: As pointed out in [RFC5905], strictly speaking, UTC did not
+      exist prior to 1 January 1972, but it is convenient to assume it
+      has existed for all eternity.  The current epoch implies that the
+      timestamp specifies the number of seconds since 1 January 1972 at
+      00:00 UTC plus 2272060800 (which is the number of seconds between
+      1 January 1900 and 1 January 1972).
+
+   Leap seconds:
+      This timestamp format is affected by leap seconds.  The timestamp
+      represents the number of seconds elapsed since the epoch minus the
+      number of leap seconds.  Thus, during and possibly before and/or
+      after the occurrence of a leap second, the value of the timestamp
+      may temporarily be ambiguous, as further discussed in Section 5.
+
+   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 [METRICS] and [NSHMD].
+   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 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 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.
+
+      Note: As pointed out in [RFC5905], strictly speaking, UTC did not
+      exist prior to 1 January 1972, but it is convenient to assume it
+      has existed for all eternity.  The current epoch implies that the
+      timestamp specifies the number of seconds since 1 January 1972 at
+      00:00 UTC plus 2272060800 (which is the number of seconds between
+      1 January 1900 and 1 January 1972).
+
+   Leap seconds:
+      This timestamp format is affected by leap seconds.  The timestamp
+      represents the number of seconds elapsed since the epoch minus the
+      number of leap seconds.  Thus, during and possibly before and/or
+      after the occurrence of a leap second, the value of the timestamp
+      may temporarily be ambiguous, as further discussed in Section 5.
+
+   Resolution:
+      The resolution is 2^(-16) seconds.
+
+   Wraparound:
+      This time format wraps around every 2^(16) seconds, which is
+      roughly 18 hours.
+
+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 was defined in [IEEE1588v1] and 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 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.
+
+   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 year
+      2106.
+
+5.  Synchronization Aspects
+
+   A specification that defines a new timestamp format or uses one of
+   the recommended timestamp formats should include a Synchronization
+   Aspects section.  Note that the recommended timestamp formats defined
+   in this document (Section 4) do not include the synchronization
+   aspects of these timestamp formats, but it is expected that
+   specifications of network protocols that make use of these formats
+   should include the synchronization aspects.  Examples of a
+   Synchronization Aspects section can be found in Section 6.
+
+   The Synchronization Aspects section should specify all the
+   assumptions and requirements related to 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 timestamp accuracy and precision.
+
+   Another aspect that should be discussed in this section is leap
+   second [RFC5905] considerations.  The timestamp specification
+   template (Section 3) specifies whether the timestamp is affected by
+   leap seconds.  It is often the case that further details about leap
+   seconds will need to be defined in the Synchronization Aspects
+   section.  Generally speaking, a leap second is a one-second
+   adjustment that is occasionally applied to UTC in order to keep it
+   aligned with solar time.  A leap second may be either positive or
+   negative, i.e., the clock may either be shifted one second forward or
+   backward.  All leap seconds that have occurred up to the publication
+   of this document have been in the backward direction, and although
+   forward leap seconds are theoretically possible, the text throughout
+   this document focuses on the common case, which is the backward leap
+   second.  In a timekeeping system that considers leap seconds, the
+   system clock may be affected by a leap second in one of three
+   possible ways:
+
+   *  The clock is turned backwards one second at the end of the leap
+      second.
+
+   *  The clock is frozen during the duration of the leap second.
+
+   *  The clock is slowed down during the leap second and adjacent time
+      intervals until the new time value catches up.  The interval for
+      this process, commonly referred to as "leap smear", can range from
+      several seconds to several hours before, during, and/or after the
+      occurrence of the leap second.
+
+   The way leap seconds are handled depends on the synchronization
+   protocol and is thus not specified in this document.  However, if a
+   timestamp format is defined with respect to a timescale that is
+   affected by leap seconds, 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
+   timestamp formats used in each of these protocols.
+
+   +=================+======================================+=======+
+   |                 |         Recommended Formats          | Other |
+   +=================+============+============+============+=======+
+   |     Protocol    | NTP 64-Bit | NTP 32-Bit | PTP Trunc. |       |
+   +=================+============+============+============+=======+
+   |  NTP [RFC5905]  |     +      |            |            |       |
+   +-----------------+------------+------------+------------+-------+
+   | OWAMP [RFC4656] |     +      |            |            |       |
+   +-----------------+------------+------------+------------+-------+
+   | TWAMP [RFC5357] |     +      |            |            |       |
+   | TWAMP [RFC8186] |     +      |            |     +      |       |
+   +-----------------+------------+------------+------------+-------+
+   | TRILL [RFC7456] |            |            |     +      |       |
+   +-----------------+------------+------------+------------+-------+
+   |  MPLS [RFC6374] |            |            |     +      |       |
+   +-----------------+------------+------------+------------+-------+
+   |  TCP [RFC7323]  |            |            |            |   +   |
+   +-----------------+------------+------------+------------+-------+
+   |  RTP [RFC3550]  |     +      |            |            |   +   |
+   +-----------------+------------+------------+------------+-------+
+   | IPFIX [RFC7011] |            |            |            |   +   |
+   +-----------------+------------+------------+------------+-------+
+   |    BinaryTime   |            |            |            |   +   |
+   |    [RFC6019]    |            |            |            |       |
+   +-----------------+------------+------------+------------+-------+
+   |    [METRICS]    |     +      |     +      |            |       |
+   +-----------------+------------+------------+------------+-------+
+   |     [NSHMD]     |            |     +      |     +      |       |
+   +-----------------+------------+------------+------------+-------+
+
+             Table 1: Protocols That Use Packet Timestamps
+
+   The rest of this section presents two hypothetical 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.
+
+6.1.  Example 1
+
+   Timestamp:
+      The timestamp format used in this specification is the NTP
+      [RFC5905] 64-bit format, as described in Section 4.2.1 of RFC
+      8877.
+
+   Synchronization aspects:
+      It is assumed that the 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 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.  Since the NTP time format
+      is affected by leap seconds, the current timestamp format is
+      similarly affected.  Thus, the value of a timestamp during and
+      possibly before and/or after a leap second may be temporarily
+      inaccurate.
+
+6.2.  Example 2
+
+   Timestamp:
+      The timestamp format used in this specification is the PTP
+      [IEEE1588] truncated format, as described in Section 4.3 of RFC
+      8877.
+
+   Synchronization aspects:
+      It is assumed that the 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 a PTP grandmaster clock.
+
+7.  Packet Timestamp Control Field
+
+   In some cases, it is desirable to have a control field that describes
+   the structure, format, content, and properties of timestamps.
+   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.  An optional control field allows some of the control
+   information to be attached to the timestamp.
+
+   An example of a packet timestamp control field is the Error Estimate
+   field, defined by Section 4.1.2 of [RFC4656], which is used in the
+   One-Way Active Measurement Protocol (OWAMP) [RFC4656] and Two-Way
+   Active Measurement Protocol (TWAMP) [RFC5357].  The Root Dispersion
+   and Root Delay fields in the NTP header [RFC5905] are two examples of
+   fields that provide information about the timestamp precision.
+   Another example of an auxiliary field is the Correction Field in the
+   PTP header [IEEE1588]; its value is used as a correction to the
+   timestamp and may be assigned by the sender of the PTP message and
+   updated by transit nodes (Transparent Clocks) in order to account for
+   the delay along the path.
+
+   This section defines high-level guidelines for defining packet
+   timestamp control fields in network protocols that can benefit from
+   such timestamp-related control information.  The word "requirements"
+   is used in its informal context in this section.
+
+7.1.  High-Level Control Field Requirements
+
+   A control field for packet timestamps must offer an adequate feature
+   set and fulfill a series of requirements to be usable and accepted.
+   The following list captures the main high-level requirements for
+   timestamp 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
+       either describe or quantify timestamp-specific characteristics or
+       parameters.  Examples of potential elements include timestamp
+       size, encoding, accuracy, leap seconds, reference clock
+       identifiers, etc.
+
+   2.  Size: Essential for an efficient use of timestamp control fields
+       is the trade-off between supported features and control field
+       size.  Protocols and applications may select the specific control
+       field elements that are needed for their operation from the set
+       of 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 specific application and context.  A control
+       field specification must support applications in conveying or
+       negotiating (a) the set of control field elements along with (b)
+       the status of any element (i.e., mandatory, conditional
+       mandatory, or optional) by defining appropriate data structures
+       and identity codes.
+
+   4.  Category: Control field elements can characterize either static
+       timestamp information (e.g., timestamp size in bytes and
+       timestamp semantics: NTP 64-bit format) or runtime timestamp
+       information (e.g., estimated timestamp accuracy at the time of
+       sampling: 20 microseconds to UTC).  For efficiency reasons, it
+       may be meaningful to support separation of these two concepts:
+       while the former (static) information is typically valid
+       throughout a protocol session and may be conveyed only once, at
+       session establishment time, the latter (runtime) information
+       augments any timestamp instance and may cause substantial
+       overhead for high-traffic protocols.
+
+   Proposals for timestamp control fields will be defined in separate
+   documents and are out of scope of this document.
+
+8.  IANA Considerations
+
+   This document has no IANA actions.
+
+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 on timestamped packets, an
+   attacker can gather information about the network performance and the
+   level of synchronization between nodes.
+
+   In some cases, timestamps could 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
+   Message Authentication Codes (MACs), 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 detection of and resistance 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].
+
+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>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+10.2.  Informative References
+
+   [IEEE1588] IEEE, "IEEE Standard for a Precision Clock Synchronization
+              Protocol for Networked Measurement and Control Systems",
+              DOI 10.1109/IEEESTD.2008.4579760, IEEE Std. 1588-2008,
+              July 2008, <https://doi.org/10.1109/IEEESTD.2008.4579760>.
+
+   [IEEE1588v1]
+              IEEE, "IEEE Standard for a Precision Clock Synchronization
+              Protocol for Networked Measurement and Control Systems",
+              DOI 10.1109/IEEESTD.2002.94144, IEEE Std. 1588-2002,
+              October 2002,
+              <https://doi.org/10.1109/IEEESTD.2002.94144>.
+
+   [ITU-T-Y.1731]
+              ITU-T, "Operations, administration and maintenance (OAM)
+              functions and mechanisms for Ethernet-based networks",
+              ITU-T Recommendation G.8013/Y.1731, August 2015.
+
+   [METRICS]  Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza,
+              "Initial Performance Metrics Registry Entries", Work in
+              Progress, Internet-Draft, draft-ietf-ippm-initial-
+              registry-16, 9 March 2020, <https://tools.ietf.org/html/
+              draft-ietf-ippm-initial-registry-16>.
+
+   [NSHMD]    Guichard, J., Smith, M., Kumar, S., Majee, S., and T.
+              Mizrahi, "Network Service Header (NSH) MD Type 1: Context
+              Header Allocation (Data Center)", Work in Progress,
+              Internet-Draft, draft-ietf-sfc-nsh-dc-allocation-02, 25
+              September 2018, <https://tools.ietf.org/html/draft-ietf-
+              sfc-nsh-dc-allocation-02>.
+
+   [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>.
+
+   [RFC6019]  Housley, R., "BinaryTime: An Alternate Format for
+              Representing Date and Time in ASN.1", RFC 6019,
+              DOI 10.17487/RFC6019, September 2010,
+              <https://www.rfc-editor.org/info/rfc6019>.
+
+   [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>.
+
+   [RFC7011]  Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
+              "Specification of the IP Flow Information Export (IPFIX)
+              Protocol for the Exchange of Flow Information", STD 77,
+              RFC 7011, DOI 10.17487/RFC7011, September 2013,
+              <https://www.rfc-editor.org/info/rfc7011>.
+
+   [RFC7323]  Borman, D., Braden, B., Jacobson, V., and R.
+              Scheffenegger, Ed., "TCP Extensions for High Performance",
+              RFC 7323, DOI 10.17487/RFC7323, September 2014,
+              <https://www.rfc-editor.org/info/rfc7323>.
+
+   [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>.
+
+Acknowledgments
+
+   The authors thank Russ Housley, Yaakov Stein, Greg Mirsky, Warner
+   Losh, Rodney Cummings, Miroslav Lichvar, Denis Reilly, Daniel Franke,
+   Éric Vyncke, Ben Kaduk, Ian Swett, Francesca Palombini, Watson Ladd,
+   and other members of the NTP Working Group for their many helpful
+   comments.  The authors gratefully acknowledge Harlan Stenn and the
+   people from the Network Time Foundation for sharing their thoughts
+   and ideas.
+
+Authors' Addresses
+
+   Tal Mizrahi
+   Huawei
+   8-2 Matam
+   Haifa 3190501
+   Israel
+
+   Email: tal.mizrahi.phd@gmail.com
+
+
+   Joachim Fabini
+   TU Wien
+   Gusshausstrasse 25/E389
+   1040 Vienna
+   Austria
+
+   Phone: +43 1 58801 38813
+   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
+   United States of America
+
+   Phone: +1 732 420 1571
+   Email: acmorton@att.com