draft-ietf-ntp-packet-timestamps-07.txt   draft-ietf-ntp-packet-timestamps-08.txt 
NTP Working Group T. Mizrahi NTP Working Group T. Mizrahi
Internet-Draft Huawei Network.IO Innovation Lab Internet-Draft Huawei Smart Platforms iLab
Intended status: Informational J. Fabini Intended status: Informational J. Fabini
Expires: February 21, 2020 TU Wien Expires: August 27, 2020 TU Wien
A. Morton A. Morton
AT&T Labs AT&T Labs
August 20, 2019 February 24, 2020
Guidelines for Defining Packet Timestamps Guidelines for Defining Packet Timestamps
draft-ietf-ntp-packet-timestamps-07 draft-ietf-ntp-packet-timestamps-08
Abstract Abstract
Various network protocols make use of binary-encoded timestamps that Various network protocols make use of binary-encoded timestamps that
are incorporated in the protocol packet format, referred to as packet are incorporated in the protocol packet format, referred to as packet
timestamps for short. This document specifies guidelines for timestamps for short. This document specifies guidelines for
defining packet timestamp formats in networking protocols at various defining packet timestamp formats in networking protocols at various
layers. It also presents three recommended timestamp formats. The layers. It also presents three recommended timestamp formats. The
target audience of this memo includes network protocol designers. It target audience of this document includes network protocol designers.
is expected that a new network protocol that requires a packet It is expected that a new network protocol that requires a packet
timestamp will, in most cases, use one of the recommended timestamp timestamp will, in most cases, use one of the recommended timestamp
formats. If none of the recommended formats fits the protocol formats. If none of the recommended formats fits the protocol
requirements, the new protocol specification should specify the requirements, the new protocol specification should specify the
format of the packet timestamp according to the guidelines in this format of the packet timestamp according to the guidelines in this
document. 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) or the Precision Time Protocol (PTP), allowing a
straightforward integration with an NTP or a 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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 21, 2020. This Internet-Draft will expire on August 27, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Scope of this Document . . . . . . . . . . . . . . . . . 3
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 1.3. How to Use This Document . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Terms used in this Document . . . . . . . . . . . . . . . 4 2.3. Terms used in this Document . . . . . . . . . . . . . . . 4
3. Packet Timestamp Specification Template . . . . . . . . . . . 4 3. Packet Timestamp Specification Template . . . . . . . . . . . 5
4. Recommended Timestamp Formats . . . . . . . . . . . . . . . . 5 4. Recommended Timestamp Formats . . . . . . . . . . . . . . . . 6
4.1. Using a Recommended Timestamp Format . . . . . . . . . . 6 4.1. Using a Recommended Timestamp Format . . . . . . . . . . 7
4.2. NTP Timestamp Formats . . . . . . . . . . . . . . . . . . 6 4.2. NTP Timestamp Formats . . . . . . . . . . . . . . . . . . 7
4.2.1. NTP 64-bit Timestamp Format . . . . . . . . . . . . . 6 4.2.1. NTP 64-bit Timestamp Format . . . . . . . . . . . . . 7
4.2.2. NTP 32-bit Timestamp Format . . . . . . . . . . . . . 8 4.2.2. NTP 32-bit Timestamp Format . . . . . . . . . . . . . 9
4.3. The PTP Truncated Timestamp Format . . . . . . . . . . . 9 4.3. The PTP Truncated Timestamp Format . . . . . . . . . . . 10
5. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 11 5. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 12
6. Timestamp Use Cases . . . . . . . . . . . . . . . . . . . . . 12 6. Timestamp Use Cases . . . . . . . . . . . . . . . . . . . . . 13
6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Packet Timestamp Control Field . . . . . . . . . . . . . . . 13 7. Packet Timestamp Control Field . . . . . . . . . . . . . . . 15
7.1. High-level Control Field Requirements . . . . . . . . . . 14 7.1. High-level Control Field Requirements . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Timestamps are widely used in network protocols for various purposes, 1.1. Background
including delay measurement, clock synchronization, and logging or
reporting the time of an event. Timestamps are widely used in network protocols for various purposes:
timestamps are used for logging or reporting the time of an event,
delay measurement and clock synchronization protocols both make use
of timestamped messages, and in security protocols a timestamp is
often used as a value that is unlikely to repeat (nonce).
Timestamps are represented in the RFC series in one of two forms: Timestamps are represented in the RFC series in one of two forms:
text-based timestamps, and packet timestamps. Text-based timestamps text-based timestamps, and packet timestamps. Text-based timestamps
[RFC3339] are represented as user-friendly strings, and are widely [RFC3339] are represented as user-friendly strings, and are widely
used in the RFC series, for example in information objects and data used in the RFC series, for example in information objects and data
models, e.g., [RFC5646], [RFC6991], and [RFC7493]. Packet models, e.g., [RFC5646], [RFC6991], and [RFC7493]. Packet
timestamps, on the other hand, are represented by a compact binary 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- 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 friendly format. Packet timestamps are also very common in the RFC
series, and are used for example for measuring delay and for series, and are used for example for measuring delay and for
synchronizing clocks, e.g., [RFC5905], [RFC4656], and [RFC1323]. synchronizing clocks, e.g., [RFC5905], [RFC4656], and [RFC7323].
This memo presents guidelines for defining a packet timestamp format 1.2. Scope of this Document
in network protocols. Three recommended timestamp formats are
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 presented. It is expected that a new network protocol that requires
a packet timestamp will, in most cases, use one of these recommended a packet timestamp will, in most cases, use one of these recommended
timestamp formats. In some cases a network protocol may use more timestamp formats. In some cases a network protocol may use more
than one of the recommended timestamp formats. However, if none of than one of the recommended timestamp formats. However, if none of
the recommended formats fits the protocol requirements, the new the recommended formats fits the protocol requirements, the new
protocol specification should specify the format of the packet protocol specification should specify the format of the packet
timestamp according to the guidelines in this document. 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) or the Precision Time Protocol (PTP), allowing a
straightforward integration with an NTP or a 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 Section 6.1 and
Section 6.2. If none of the recommended formats fits the required
functionality, then a new timestamp format should be defined using
the template of Section 3.
2. Terminology 2. Terminology
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they
appear in all capitals, as shown here.
2.2. Abbreviations 2.2. Abbreviations
NTP Network Time Protocol [RFC5905] NTP Network Time Protocol [RFC5905]
PTP Precision Time Protocol [IEEE1588] PTP Precision Time Protocol [IEEE1588]
TAI International Atomic Time TAI International Atomic Time
UTC Coordinated Universal Time UTC Coordinated Universal Time
2.3. Terms used in this Document 2.3. Terms used in this Document
Timestamp error: The difference between the timestamp value at Timestamp: A value that represents a point in time,
the device under test and the value of a corresponding to an event that occurred or is
reference clock at the same time instant. 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 Timestamp format: The specification of a timestamp, which is
represented by a set of attributes that represented by a set of attributes that
unambiguously define the syntax and semantics unambiguously define the syntax and semantics
of a timestamp. of a timestamp.
Timestamp accuracy: The mean over an ensemble of measurements of Timestamp accuracy: The mean over an ensemble of measurements of
the timestamp error. the timestamp error.
Timestamp precision: The variation over an ensemble of measurements Timestamp precision: The variation over an ensemble of measurements
of the timestamp error. of the timestamp error.
Timestamp resolution: The minimal time unit used for representing Timestamp resolution: The minimal time unit used for representing
the timestamp. the timestamp.
3. Packet Timestamp Specification Template 3. Packet Timestamp Specification Template
This memo recommends to use the timestamp formats defined in This document recommends to use the timestamp formats defined in
Section 4. In cases where these timestamp formats do not satisfy the Section 4. In cases where these timestamp formats do not satisfy the
protocol requirements, the timestamp specification should clearly protocol requirements, the timestamp specification should clearly
state the reasons for defining a new format. Moreover, it is state the reasons for defining a new format. Moreover, it is
recommended to derive the new timestamp format from an existing recommended to derive the new timestamp format from an existing
timestamp format, either a timestamp format from this memo, or any timestamp format, either a timestamp format from this document, or
other previously defined timestamp format. any other previously defined timestamp format.
The timestamp specification must unambiguously define the syntax and The timestamp specification must unambiguously define the syntax and
the semantics of the timestamp. The current section defines the the semantics of the timestamp. The current section defines the
minimum set of attributes, but it should be noted that in some cases minimum set of attributes, but it should be noted that in some cases
additional attributes or aspects will need to be defined in the additional attributes or aspects will need to be defined in the
timestamp specification. timestamp specification.
This section defines a template for specifying packet timestamps. A This section defines a template for specifying packet timestamps. A
timestamp format specification MUST include at least the following timestamp format specification MUST include at least the following
aspects: aspects:
Timestamp syntax: Timestamp syntax:
The structure of the timestamp field consists of: - Size: The number of bits (or octets) used to represent the
+ Size: The number of bits (or octets) used to represent the
packet timestamp field. If the timestamp is comprised of more packet timestamp field. If the timestamp is comprised of more
than one field, the size of each field is specified. than one field, the size of each field is specified.
Timestamp semantics: Timestamp semantics:
+ Units: The units used to represent the timestamp. If the - Units: The units used to represent the timestamp. If the
timestamp is comprised of more than one field, the units of each timestamp is comprised of more than one field, the units of each
field are specified. field are specified.
+ Resolution: The timestamp resolution; the resolution is equal to - Resolution: The timestamp resolution; the resolution is equal to
the timestamp field unit. If the timestamp consists of two or the timestamp field unit. If the timestamp consists of two or
more fields using different time units, then the resolution is the more fields using different time units, then the resolution is the
smallest time unit. smallest time unit.
+ Wraparound: The wraparound period of the timestamp; any further - Wraparound: The wraparound period of the timestamp; any further
wraparound-related considerations should be described here. wraparound-related considerations should be described here.
+ Epoch: The origin of the timescale used for the timestamp; the - Epoch: The origin of the timescale used for the timestamp; the
moment in time used as a reference for the timestamp value. For 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 example, the epoch may be based on a standard time scale, such as
UTC. Another example is a relative timestamp, in which the epoch UTC. Another example is a relative timestamp, in which the epoch
is the time at which the device using the timestamp was powered is the time at which the device using the timestamp was powered
up, and is not affected by leap seconds (see the next attribute). up, and is not affected by leap seconds (see the next attribute).
+ Leap seconds: This subsection specifies whether the timestamp is - Leap seconds: This subsection specifies whether the timestamp is
affected by leap seconds. If the timestamp is affected by leap affected by leap seconds. If the timestamp is affected by leap
seconds, then it represents the time elapsed since the epoch minus seconds, then it represents the time elapsed since the epoch minus
the number of leap seconds that have occurred since the epoch. the number of leap seconds that have occurred since the epoch.
Synchronization aspects: Synchronization aspects:
The specification of a network protocol that makes use of a packet The specification of a network protocol that makes use of a packet
timestamp is expected to include the synchronization aspects of timestamp is expected to include the synchronization aspects of
using the timestamp. While the synchronization aspects are not using the timestamp. While the synchronization aspects are not
strictly part of the timestamp format specification, these aspects strictly part of the timestamp format specification, these aspects
provide the necessary context for using the timestamp within the provide the necessary context for using the timestamp within the
scope of the protocol. Further details about synchronization 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. aspects are discussed in Section 5.
4. Recommended Timestamp Formats 4. Recommended Timestamp Formats
This memo defines a set of recommended timestamp formats. Defining a This document defines a set of recommended timestamp formats.
relatively small set of recommended formats enables significant Defining a relatively small set of recommended formats enables
reuse; for example, a network protocol may reuse the NTP or PTP significant reuse; for example, a network protocol may reuse the NTP
timestamp format, allowing a straightforward integration with an NTP or PTP timestamp format, allowing a straightforward integration with
or a PTP-based timer. Moreover, since accurate timestamping an NTP or a PTP-based timer. Moreover, since accurate timestamping
mechanisms are often implemented in hardware, a new network protocol mechanisms are often implemented in hardware, a new network protocol
that reuses an existing timestamp format can be quickly deployed that reuses an existing timestamp format can be quickly deployed
using existing hardware timestamping capabilities. This memo using existing hardware timestamping capabilities. This document
recommends to use one of the timestamp formats specified below. recommends to use one of the timestamp formats specified below.
Clearly, different network protocols may have different requirements Clearly, different network protocols may have different requirements
and constraints, and consequently may use different timestamp and constraints, and consequently may use different timestamp
formats. The choice of the specific timestamp format for a given formats. The choice of the specific timestamp format for a given
protocol may depend on a various factors. A few examples of factors protocol may depend on a various factors. A few examples of factors
that may affect the choice of the timestamp format: that may affect the choice of the timestamp format:
o Timestamp size: while some network protocols use a large timestamp o Timestamp size: while some network protocols use a large timestamp
field, in some cases there may be constraints with respect to the field, in some cases there may be constraints with respect to the
skipping to change at page 6, line 44 skipping to change at page 7, line 30
timestamp format may allow easier integration with an NTP- timestamp format may allow easier integration with an NTP-
synchronized timer. In contrast, a protocol that is typically synchronized timer. In contrast, a protocol that is typically
deployed on a hardware-based platform, may make better use of a deployed on a hardware-based platform, may make better use of a
PTP-based timestamp, allowing more efficient integration with a PTP-based timestamp, allowing more efficient integration with a
PTP-synchronized timer. PTP-synchronized timer.
4.1. Using a Recommended Timestamp Format 4.1. Using a Recommended Timestamp Format
A specification that uses one of the recommended timestamp formats A specification that uses one of the recommended timestamp formats
should specify explicitly that this is a recommended timestamp should specify explicitly that this is a recommended timestamp
format, and point to the relevant section in the current memo. format, and point to the relevant section in the current document.
4.2. NTP Timestamp Formats 4.2. NTP Timestamp Formats
4.2.1. NTP 64-bit Timestamp Format 4.2.1. NTP 64-bit Timestamp Format
The Network Time Protocol (NTP) 64-bit timestamp format is defined in The Network Time Protocol (NTP) 64-bit timestamp format is defined in
[RFC5905]. This timestamp format is used in several network [RFC5905]. This timestamp format is used in several network
protocols, including [RFC6374], [RFC4656], and [RFC5357]. Since this protocols, including [RFC6374], [RFC4656], and [RFC5357]. Since this
timestamp format is used in NTP, this timestamp format should be timestamp format is used in NTP, this timestamp format should be
preferred in network protocols that are typically deployed in concert preferred in network protocols that are typically deployed in concert
skipping to change at page 7, line 26 skipping to change at page 8, line 20
| Fraction | | Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: NTP [RFC5905] 64-bit Timestamp Format Figure 1: NTP [RFC5905] 64-bit Timestamp Format
Timestamp field format: Timestamp field format:
Seconds: specifies the integer portion of the number of seconds Seconds: specifies the integer portion of the number of seconds
since the epoch. since the epoch.
+ Size: 32 bits. - Size: 32 bits.
+ Units: seconds. - Units: seconds.
Fraction: specifies the fractional portion of the number of Fraction: specifies the fractional portion of the number of
seconds since the epoch. seconds since the epoch.
+ Size: 32 bits. - Size: 32 bits.
+ Units: the unit is 2^(-32) seconds, which is roughly equal to - Units: the unit is 2^(-32) seconds, which is roughly equal to
233 picoseconds. 233 picoseconds.
Epoch: Epoch:
The epoch is 1 January 1900 at 00:00 UTC. The epoch is 1 January 1900 at 00:00 UTC.
Note: As pointed out in [RFC5905], strictly speaking, UTC did not Note: As pointed out in [RFC5905], strictly speaking, UTC did not
exist prior to 1 January 1972, but it is convenient to assume it exist prior to 1 January 1972, but it is convenient to assume it
has existed for all eternity. The current epoch implies that the has existed for all eternity. The current epoch implies that the
timestamp specifies the number of seconds since 1 January 1972 at timestamp specifies the number of seconds since 1 January 1972 at
skipping to change at page 8, line 47 skipping to change at page 9, line 39
| Seconds | Fraction | | Seconds | Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: NTP [RFC5905] 32-bit Timestamp Format Figure 2: NTP [RFC5905] 32-bit Timestamp Format
Timestamp field format: Timestamp field format:
Seconds: specifies the integer portion of the number of seconds Seconds: specifies the integer portion of the number of seconds
since the epoch. since the epoch.
+ Size: 16 bits. - Size: 16 bits.
+ Units: seconds. - Units: seconds.
Fraction: specifies the fractional portion of the number of Fraction: specifies the fractional portion of the number of
seconds since the epoch. seconds since the epoch.
+ Size: 16 bits. - Size: 16 bits.
+ Units: the unit is 2^(-16) seconds, which is roughly equal to - Units: the unit is 2^(-16) seconds, which is roughly equal to
15.3 microseconds. 15.3 microseconds.
Epoch: Epoch:
The epoch is 1 January 1900 at 00:00 UTC. The epoch is 1 January 1900 at 00:00 UTC.
Note: As pointed out in [RFC5905], strictly speaking, UTC did not Note: As pointed out in [RFC5905], strictly speaking, UTC did not
exist prior to 1 January 1972, but it is convenient to assume it exist prior to 1 January 1972, but it is convenient to assume it
has existed for all eternity. The current epoch implies that the has existed for all eternity. The current epoch implies that the
timestamp specifies the number of seconds since 1 January 1972 at timestamp specifies the number of seconds since 1 January 1972 at
skipping to change at page 10, line 20 skipping to change at page 11, line 20
| Nanoseconds | | Nanoseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PTP [IEEE1588] Truncated Timestamp Format Figure 3: PTP [IEEE1588] Truncated Timestamp Format
Timestamp field format: Timestamp field format:
Seconds: specifies the integer portion of the number of seconds Seconds: specifies the integer portion of the number of seconds
since the epoch. since the epoch.
+ Size: 32 bits. - Size: 32 bits.
+ Units: seconds. - Units: seconds.
Nanoseconds: specifies the fractional portion of the number of Nanoseconds: specifies the fractional portion of the number of
seconds since the epoch. seconds since the epoch.
+ Size: 32 bits. - Size: 32 bits.
+ Units: nanoseconds. The value of this field is in the range 0 - Units: nanoseconds. The value of this field is in the range 0
to (10^9)-1. to (10^9)-1.
Epoch: Epoch:
The PTP [IEEE1588] epoch is 1 January 1970 00:00:00 TAI. The PTP [IEEE1588] epoch is 1 January 1970 00:00:00 TAI.
Leap seconds: Leap seconds:
This timestamp format is not affected by leap seconds. This timestamp format is not affected by leap seconds.
skipping to change at page 12, line 21 skipping to change at page 14, line 5
specify how the use of leap seconds affects the timestamp usage. specify how the use of leap seconds affects the timestamp usage.
6. Timestamp Use Cases 6. Timestamp Use Cases
Packet timestamps are used in various network protocols. Typical Packet timestamps are used in various network protocols. Typical
applications of packet timestamps include delay measurement, clock applications of packet timestamps include delay measurement, clock
synchronization, and others. The following table presents a (non- synchronization, and others. The following table presents a (non-
exhaustive) list of protocols that use packet timestamps, and the exhaustive) list of protocols that use packet timestamps, and the
timestamp formats used in each of these protocols. timestamp formats used in each of these protocols.
+------------------+-----------------------------------+-----------+ +----------------------+-----------------------------------+-----------+
| | Recommended formats | Other | | | Recommended formats | Other |
+------------------+-----------+-----------+-----------+ format | +----------------------+-----------+-----------+-----------+-----------+
| Protocol |NTP 64-bit |NTP 32-bit |PTP Trunc. | | | Protocol |NTP 64-bit |NTP 32-bit |PTP Trunc. | |
+------------------+-----------+-----------+-----------+-----------+ +----------------------+-----------+-----------+-----------+-----------+
| NTP [RFC5905] | + | | | | | NTP [RFC5905] | + | | | |
+------------------+-----------+-----------+-----------+-----------+ +----------------------+-----------+-----------+-----------+-----------+
| OWAMP [RFC4656] | + | | | | | OWAMP [RFC4656] | + | | | |
+------------------+-----------+-----------+-----------+-----------+ +----------------------+-----------+-----------+-----------+-----------+
| TWAMP [RFC5357] | + | | | | | TWAMP [RFC5357] | + | | | |
| TWAMP [RFC8186] | + | | + | | | TWAMP [RFC8186] | + | | + | |
+------------------+-----------+-----------+-----------+-----------+ +----------------------+-----------+-----------+-----------+-----------+
| TRILL [RFC7456] | | | + | | | TRILL [RFC7456] | | | + | |
+------------------+-----------+-----------+-----------+-----------+ +----------------------+-----------+-----------+-----------+-----------+
| MPLS [RFC6374] | | | + | | | MPLS [RFC6374] | | | + | |
+------------------+-----------+-----------+-----------+-----------+ +----------------------+-----------+-----------+-----------+-----------+
| TCP [RFC1323] | | | | + | | TCP [RFC7323] | | | | + |
+------------------+-----------+-----------+-----------+-----------+ +----------------------+-----------+-----------+-----------+-----------+
| RTP [RFC3550] | + | | | + | | RTP [RFC3550] | + | | | + |
+------------------+-----------+-----------+-----------+-----------+ +----------------------+-----------+-----------+-----------+-----------+
| IPFIX [RFC7011] | | | | + | | IPFIX [RFC7011] | | | | + |
+------------------+-----------+-----------+-----------+-----------+ +----------------------+-----------+-----------+-----------+-----------+
| [I-D.ietf-ippm- | + | + | | | | BinaryTime [RFC6019] | | | | + |
| initial-registry]| | | | | +----------------------+-----------+-----------+-----------+-----------+
+------------------+-----------+-----------+-----------+-----------+ | [I-D.ietf-ippm- | + | + | | |
| [I-D.ietf-sfc-nsh| | + | + | | | initial-registry] | | | | |
| -dc-allocation] | | | | | +----------------------+-----------+-----------+-----------+-----------+
+------------------+-----------+-----------+-----------+-----------+ | [I-D.ietf-sfc-nsh | | + | + | |
| -dc-allocation] | | | | |
+----------------------+-----------+-----------+-----------+-----------+
Figure 4: Protocols that use Packet Timestamps Figure 4: Protocols that use Packet Timestamps
The rest of this section presents two hypothetic examples of network The rest of this section presents two hypothetic examples of network
protocol specifications that use one of the recommended timestamp protocol specifications that use one of the recommended timestamp
formats. The examples include the text that specifies the formats. The examples include the text that specifies the
information related to the timestamp format. information related to the timestamp format.
6.1. Example 1 6.1. Example 1
skipping to change at page 15, line 14 skipping to change at page 16, line 49
information (like, e.g., estimated timestamp accuracy at the time information (like, e.g., estimated timestamp accuracy at the time
of sampling: 20 microseconds to UTC). For efficiency reason it of sampling: 20 microseconds to UTC). For efficiency reason it
may be meaningful to support separation of these two concepts: may be meaningful to support separation of these two concepts:
while the former (static) information is typically valid while the former (static) information is typically valid
throughout a protocol session and may be conveyed only once, at throughout a protocol session and may be conveyed only once, at
session establishment time, the latter (runtime) information session establishment time, the latter (runtime) information
augments any timestamp instance and may cause substantial augments any timestamp instance and may cause substantial
overhead for high-traffic protocols. overhead for high-traffic protocols.
Proposals for timestamp control fields will be defined in separate Proposals for timestamp control fields will be defined in separate
documents and are out of scope of this memo. documents and are out of scope of this document.
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This document includes no request to IANA.
9. Security Considerations 9. Security Considerations
A network protocol that uses a packet timestamp MUST specify the A network protocol that uses a packet timestamp MUST specify the
security considerations that result from using the timestamp. This security considerations that result from using the timestamp. This
section provides an overview of some of the common security section provides an overview of some of the common security
considerations of using timestamps. considerations of using timestamps.
Any metadata that is attached to control or data packets, and Any metadata that is attached to control or data packets, and
specifically packet timestamps, can facilitate network specifically packet timestamps, can facilitate network
reconnaissance; by passively eavesdropping to timestamped packets an reconnaissance; by passively eavesdropping to timestamped packets an
attacker can gather information about the network performance, and attacker can gather information about the network performance, and
about the level of synchronization between nodes. about the level of synchronization between nodes.
Timestamps can be spoofed or modified by on-path attackers, thus Timestamps can be spoofed or modified by on-path attackers, thus
attacking the application that uses the timestamps. For example, if attacking the application that uses the timestamps. For example, if
timestamps are used in a delay measurement protocol, an attacker can timestamps are used in a delay measurement protocol, an attacker can
modify en route timestamps in a way that manipulates the measurement modify en route timestamps in a way that manipulates the measurement
results. Integrity protection mechanisms, such as Hashed Message results. Integrity protection mechanisms, such as Message
Authentication Codes (HMAC), can mitigate such attacks. The Authentication Codes (MAC), can mitigate such attacks. The
specification of an integrity protection mechanism is outside the specification of an integrity protection mechanism is outside the
scope of this document, as typically integrity protection will be scope of this document, as typically integrity protection will be
defined on a per-network-protocol basis, and not specifically for the defined on a per-network-protocol basis, and not specifically for the
timestamp field. timestamp field.
Another potential threat that can have a similar impact is delay Another potential threat that can have a similar impact is delay
attacks. An attacker can maliciously delay some or all of the en attacks. An attacker can maliciously delay some or all of the en
route messages, with the same harmful implications as described in route messages, with the same harmful implications as described in
the previous paragraph. Mitigating delay attacks is a significant the previous paragraph. Mitigating delay attacks is a significant
challenge; in contrast to spoofing and modification attacks, the challenge; in contrast to spoofing and modification attacks, the
skipping to change at page 16, line 14 skipping to change at page 18, line 7
allowing to detect and to be resilient to an attacker that has access allowing to detect and to be resilient to an attacker that has access
to one of the paths. to one of the paths.
In many cases timestamping relies on an underlying synchronization In many cases timestamping relies on an underlying synchronization
mechanism. Thus, any attack that compromises the synchronization mechanism. Thus, any attack that compromises the synchronization
mechanism can also compromise protocols that use timestamping. mechanism can also compromise protocols that use timestamping.
Attacks on time protocols are discussed in detail in [RFC7384]. Attacks on time protocols are discussed in detail in [RFC7384].
10. Acknowledgments 10. Acknowledgments
The authors thank Yaakov Stein, Greg Mirsky, Warner Losh, Rodney The authors thank Russ Housley, Yaakov Stein, Greg Mirsky, Warner
Cummings, Miroslav Lichvar, Denis Reilly, Daniel Franke, Watson Ladd, Losh, Rodney Cummings, Miroslav Lichvar, Denis Reilly, Daniel Franke,
and other members of the NTP working group for many helpful comments. Watson Ladd, and other members of the NTP working group for many
The authors gratefully acknowledge Harlan Stenn and the people from helpful comments. The authors gratefully acknowledge Harlan Stenn
the Network Time Foundation for sharing their thoughts and ideas. and the people from the Network Time Foundation for sharing their
thoughts and ideas.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <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>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-ippm-initial-registry] [I-D.ietf-ippm-initial-registry]
Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza, Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza,
"Initial Performance Metrics Registry Entries", draft- "Initial Performance Metrics Registry Entries", draft-
ietf-ippm-initial-registry-11 (work in progress), March ietf-ippm-initial-registry-15 (work in progress), December
2019. 2019.
[I-D.ietf-ntp-packet-timestamps] [I-D.ietf-ntp-packet-timestamps]
Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
Defining Packet Timestamps", draft-ietf-ntp-packet- Defining Packet Timestamps", draft-ietf-ntp-packet-
timestamps-06 (work in progress), February 2019. timestamps-07 (work in progress), August 2019.
[I-D.ietf-sfc-nsh-dc-allocation] [I-D.ietf-sfc-nsh-dc-allocation]
Guichard, J., Smith, M., Kumar, S., Majee, S., and T. Guichard, J., Smith, M., Kumar, S., Majee, S., and T.
Mizrahi, "Network Service Header (NSH) MD Type 1: Context Mizrahi, "Network Service Header (NSH) MD Type 1: Context
Header Allocation (Data Center)", draft-ietf-sfc-nsh-dc- Header Allocation (Data Center)", draft-ietf-sfc-nsh-dc-
allocation-02 (work in progress), September 2018. allocation-02 (work in progress), September 2018.
[IEEE1588] [IEEE1588]
IEEE, "IEEE 1588 Standard for a Precision Clock IEEE, "IEEE 1588 Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
skipping to change at page 17, line 14 skipping to change at page 19, line 14
[IEEE1588v1] [IEEE1588v1]
IEEE, "IEEE 1588 Standard for a Precision Clock IEEE, "IEEE 1588 Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
Control Systems", 2002. Control Systems", 2002.
[ITU-T-Y.1731] [ITU-T-Y.1731]
ITU-T, "OAM functions and mechanisms for Ethernet based ITU-T, "OAM functions and mechanisms for Ethernet based
Networks", 2013. 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: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
skipping to change at page 17, line 46 skipping to change at page 19, line 42
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <https://www.rfc-editor.org/info/rfc5646>. September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <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 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, Measurement for MPLS Networks", RFC 6374,
DOI 10.17487/RFC6374, September 2011, DOI 10.17487/RFC6374, September 2011,
<https://www.rfc-editor.org/info/rfc6374>. <https://www.rfc-editor.org/info/rfc6374>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX) "Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77, Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013, RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>. <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 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>. October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC7456] Mizrahi, T., Senevirathne, T., Salam, S., Kumar, D., and [RFC7456] Mizrahi, T., Senevirathne, T., Salam, S., Kumar, D., and
D. Eastlake 3rd, "Loss and Delay Measurement in D. Eastlake 3rd, "Loss and Delay Measurement in
Transparent Interconnection of Lots of Links (TRILL)", Transparent Interconnection of Lots of Links (TRILL)",
RFC 7456, DOI 10.17487/RFC7456, March 2015, RFC 7456, DOI 10.17487/RFC7456, March 2015,
<https://www.rfc-editor.org/info/rfc7456>. <https://www.rfc-editor.org/info/rfc7456>.
skipping to change at page 18, line 37 skipping to change at page 20, line 42
<https://www.rfc-editor.org/info/rfc7493>. <https://www.rfc-editor.org/info/rfc7493>.
[RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588 [RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588
Timestamp Format in a Two-Way Active Measurement Protocol Timestamp Format in a Two-Way Active Measurement Protocol
(TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017, (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017,
<https://www.rfc-editor.org/info/rfc8186>. <https://www.rfc-editor.org/info/rfc8186>.
Authors' Addresses Authors' Addresses
Tal Mizrahi Tal Mizrahi
Huawei Network.IO Innovation Lab Huawei Smart Platforms iLab
8-2 Matam
Haifa 3190501
Israel Israel
Email: tal.mizrahi.phd@gmail.com Email: tal.mizrahi.phd@gmail.com
Joachim Fabini Joachim Fabini
TU Wien TU Wien
Gusshausstrasse 25/E389 Gusshausstrasse 25/E389
Vienna 1040 Vienna 1040
Austria Austria
Phone: +43 1 58801 38813 Phone: +43 1 58801 38813
Fax: +43 1 58801 38898 Fax: +43 1 58801 38898
Email: Joachim.Fabini@tuwien.ac.at Email: Joachim.Fabini@tuwien.ac.at
URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/ URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/
skipping to change at page 19, line 4 skipping to change at page 21, line 14
Joachim Fabini Joachim Fabini
TU Wien TU Wien
Gusshausstrasse 25/E389 Gusshausstrasse 25/E389
Vienna 1040 Vienna 1040
Austria Austria
Phone: +43 1 58801 38813 Phone: +43 1 58801 38813
Fax: +43 1 58801 38898 Fax: +43 1 58801 38898
Email: Joachim.Fabini@tuwien.ac.at Email: Joachim.Fabini@tuwien.ac.at
URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/ URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/
Al Morton Al Morton
AT&T Labs AT&T Labs
200 Laurel Avenue South 200 Laurel Avenue South
Middletown,, NJ 07748 Middletown,, NJ 07748
USA USA
Phone: +1 732 420 1571 Phone: +1 732 420 1571
Fax: +1 732 368 1192 Fax: +1 732 368 1192
Email: acmorton@att.com Email: acmorton@att.com
URI: http://home.comcast.net/~acmacm/
 End of changes. 55 change blocks. 
129 lines changed or deleted 173 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/