draft-ietf-ntp-packet-timestamps-00.txt   draft-ietf-ntp-packet-timestamps-01.txt 
Network Working Group T. Mizrahi Network Working Group T. Mizrahi
Internet-Draft Marvell Internet-Draft Marvell
Intended status: Informational J. Fabini Intended status: Informational J. Fabini
Expires: April 29, 2018 Vienna University of Technology Expires: September 6, 2018 Vienna University of Technology
A. Morton A. Morton
AT&T Labs AT&T Labs
October 26, 2017 March 5, 2018
Guidelines for Defining Packet Timestamps Guidelines for Defining Packet Timestamps
draft-ietf-ntp-packet-timestamps-00 draft-ietf-ntp-packet-timestamps-01
Abstract Abstract
This document specifies guidelines for defining binary packet This document specifies guidelines for defining binary packet
timestamp formats in networking protocols at various layers. It also timestamp formats in networking protocols at various layers. It also
presents three recommended timestamp formats. The target audience of presents three recommended timestamp formats. The target audience of
this memo includes network protocol designers. It is expected that a this memo includes network protocol designers. It is expected that a
new network protocol that requires a packet timestamp will, in most new network protocol that requires a packet timestamp will, in most
cases, use one of the recommended timestamp formats. If none of the cases, use one of the recommended timestamp formats. If none of the
recommended formats fits the protocol requirements, the new protocol recommended formats fits the protocol requirements, the new protocol
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 April 29, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
3. Packet Timestamp Format Specification . . . . . . . . . . . . 3 2.3. Terms used in this Document . . . . . . . . . . . . . . . 4
4. Recommended Timestamp Formats . . . . . . . . . . . . . . . . 4 3. Packet Timestamp Specification Template . . . . . . . . . . . 4
4.1. Using a Recommended Timestamp Format . . . . . . . . . . 5 4. Recommended Timestamp Formats . . . . . . . . . . . . . . . . 5
4.2. NTP Timestamp Formats . . . . . . . . . . . . . . . . . . 5 4.1. Using a Recommended Timestamp Format . . . . . . . . . . 6
4.2.1. NTP 64-bit Timestamp Format . . . . . . . . . . . . . 5 4.2. NTP Timestamp Formats . . . . . . . . . . . . . . . . . . 6
4.2.2. NTP 32-bit Timestamp Format . . . . . . . . . . . . . 6 4.2.1. NTP 64-bit Timestamp Format . . . . . . . . . . . . . 6
4.3. The PTP Truncated Timestamp Format . . . . . . . . . . . 8 4.2.2. NTP 32-bit Timestamp Format . . . . . . . . . . . . . 8
5. Timestamp Use Cases . . . . . . . . . . . . . . . . . . . . . 9 4.3. The PTP Truncated Timestamp Format . . . . . . . . . . . 9
5.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 10
5.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Timestamp Use Cases . . . . . . . . . . . . . . . . . . . . . 11
6. Packet Timestamp Control Field . . . . . . . . . . . . . . . 10 6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Packet Timestamp Control Field . . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. High-level Control Field Requirements . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Control Field Categories . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.3. Control Field Features and Elements . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 12 7.3.1. Timestamp Format . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 7.3.2. Timestamp Format Specification . . . . . . . . . . . 16
7.3.3. Timestamp Precision . . . . . . . . . . . . . . . . . 17
7.3.4. Timestamp Timescale . . . . . . . . . . . . . . . . . 17
7.3.5. Timestamp Leap Second . . . . . . . . . . . . . . . . 17
7.3.6. Reference Clock . . . . . . . . . . . . . . . . . . . 18
7.3.7. Provable Signature . . . . . . . . . . . . . . . . . 18
7.3.8. Custom Extension . . . . . . . . . . . . . . . . . . 18
7.4. Control Field Payload Definition . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Timestamps are widely used in network protocols for various purposes, Timestamps are widely used in network protocols for various purposes,
including delay measurement, clock synchronization, and logging or including delay measurement, clock synchronization, and logging or
reporting the time of an event. reporting the time of an event.
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
skipping to change at page 3, line 30 skipping to change at page 3, line 45
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
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]
3. Packet Timestamp Format Specification TAI International Atomic Time
UTC Coordinated Universal Time
2.3. Terms used in this Document
Timestamp error: The difference between the timestamp value at
the device under test and the value of a
reference clock at the same time instant.
Timestamp format: The specification of a timestamp, which is
represented by a set of attributes that
unambiguously define the syntax and semantics
of a timestamp.
Timestamp accuracy: The mean over an ensemble of measurements of
the timestamp error.
Timestamp precision: The variation over an ensemble of measurements
of the timestamp error.
Timestamp resolution: The minimal time unit used for representing
the timestamp.
3. Packet Timestamp Specification Template
This memo recommends to use the timestamp formats defined in This memo 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 memo, or any
other previously defined timestamp format. other previously defined timestamp format.
This section defines a template for specifying packet timestamp The timestamp specification must unambiguously define the syntax and
formats. A timestamp format specification MUST include the following the semantics of the timestamp. The current section defines the
minimum set of attributes, but it should be noted that in some cases
additional attributes or aspects will need to be defined in the
timestamp specification.
This section defines a template for specifying packet timestamps. A
timestamp format specification MUST include at least the following
aspects: aspects:
Timestamp field format: Timestamp syntax:
The format of the timestamp field consists of: 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. packet timestamp field. If the timestamp is comprised of more
than one field, the size of each field is specified.
+ Units: The units used to represent the timestamp.
If the timestamp is comprised of more than one field, the format
of each field is specified.
Epoch: Timestamp semantics:
The origin of the timescale used for the timestamp; the moment in + Units: The units used to represent the timestamp. If the
time used as a reference for the timestamp value. timestamp is comprised of more than one field, the units of each
field are specified.
Resolution: + 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.
The timestamp resolution; the resolution is equal to the timestamp + Wraparound: The wraparound period of the timestamp; any further
field unit. If the timestamp consists of two or more fields using wraparound-related considerations should be described here.
different time units, then the resolution is the smallest time
unit.
Wraparound: + 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
is the time at which the device using the timestamp was powered
up, and is not affected by leap seconds (see the next attribute).
The wraparound period of the timestamp; any further wraparound- + Leap seconds: This subsection specifies whether the timestamp is
related considerations should be described here. affected by leap seconds. If the timestamp is affected by leap
seconds, then it represents the time elapsed since the epoch minus
the number of leap seconds that have occurred since the epoch.
4. Recommended Timestamp Formats 4. Recommended Timestamp Formats
This memo recommends to use one of the timestamp formats specified This memo defines a set of recommended timestamp formats. Defining a
below. relatively small set of recommended formats enables significant
reuse; for example, a network protocol may reuse the NTP or PTP
timestamp format, allowing a straightforward integration with an NTP
or a PTP-based timer. Moreover, since accurate timestamping
mechanisms are often implemented in hardware, a new network protocol
that reuses an existing timestamp format can be quickly deployed
using existing hardware timestamping capabilities. This memo
recommends to use one of the timestamp formats specified below.
Clearly, different network protocols may have different requirements 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 may allow a large o Timestamp size: while some network protocols use a large timestamp
timestamp fields, in other cases there may be constraints with field, in some cases there may be constraints with respect to the
respect to the timestamp size, affecting the choice of the timestamp size, affecting the choice of the timestamp format.
timestamp format.
o Resolution: the time resolution is another factor that may o Resolution: the time resolution is another factor that may
directly affect the selected timestamp format. Similarly, the directly affect the selected timestamp format. A potentially
wraparound periodicity of the timestamp may also affect the important factor in this context is extensibility; it may be
selected format. 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.
o Wraparound period: the length of the time interval in which the o Wraparound period: the length of the time interval in which the
timestamp is unique may also be an important factor in choosing timestamp is unique may also be an important factor in choosing
the timestamp format. Along with the timestamp resolution, these the timestamp format. Along with the timestamp resolution, these
two factors determine the required number of bits in the two factors determine the required number of bits in the
timestamp. timestamp.
o Common format for multiple protocols: if there are two or more o Common format for multiple protocols: if there are two or more
network protocols that use timestamps and are often used together network protocols that use timestamps and are often used together
in typical systems, using a common timestamp format should be in typical systems, using a common timestamp format should be
skipping to change at page 5, line 22 skipping to change at page 6, line 36
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 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. 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
with NTP. with NTP.
skipping to change at page 6, line 36 skipping to change at page 7, line 36
+ 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.
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.
Resolution: Resolution:
The resolution is 2^(-32) seconds. The resolution is 2^(-32) seconds.
Wraparound: Wraparound:
This time format wraps around every 2^32 seconds, which is roughly This time format wraps around every 2^32 seconds, which is roughly
136 years. The next wraparound will occur in the year 2036. 136 years. The next wraparound will occur in the year 2036.
4.2.2. NTP 32-bit Timestamp Format 4.2.2. NTP 32-bit Timestamp Format
The Network Time Protocol (NTP) 32-bit timestamp format is defined in The Network Time Protocol (NTP) 32-bit timestamp format is defined in
[RFC5905]. This timestamp format is used in [RFC5905]. This timestamp format is used in
[I-D.morton-ippm-mbm-registry]. This timestamp format should be [I-D.ietf-ippm-initial-registry]. 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
with NTP. The 32-bit format can be used either when space 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 constraints do not allow the use of the 64-bit format, or when the
32-bit format satisfies the resolution and wraparound requirements. 32-bit format satisfies the resolution and wraparound requirements.
The format is presented in this section according to the template The format is presented in this section according to the template
defined in Section 3. defined in Section 3.
0 1 2 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 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
skipping to change at page 7, line 39 skipping to change at page 8, line 47
+ 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.
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.
Resolution: Resolution:
The resolution is 2^(-16) seconds. The resolution is 2^(-16) seconds.
Wraparound: Wraparound:
This time format wraps around every 2^16 seconds, which is roughly This time format wraps around every 2^16 seconds, which is roughly
18 hours. 18 hours.
4.3. The PTP Truncated Timestamp Format 4.3. The PTP Truncated Timestamp Format
skipping to change at page 8, line 49 skipping to change at page 10, line 10
+ 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, which is The PTP [IEEE1588] epoch is 1 January 1970 00:00:00 TAI, which is
31 December 1969 23:59:51.999918 UTC. 31 December 1969 23:59:51.999918 UTC.
Leap seconds:
This timestamp format is not affected by leap seconds.
Resolution: Resolution:
The resolution is 1 nanosecond. The resolution is 1 nanosecond.
Wraparound: Wraparound:
This time format wraps around every 2^32 seconds, which is roughly This time format wraps around every 2^32 seconds, which is roughly
136 years. The next wraparound will occur in the year 2106. 136 years. The next wraparound will occur in the year 2106.
5. Timestamp Use Cases 5. Synchronization Aspects
A specification that defines a new timestamp format or uses one of
the recommended timestamp formats should include a section on
Synchronization Aspects. Examples of such a 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.
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, in a timekeeping system that considers
leap seconds, the system clock may be affected by a leap second in
one of three possible ways:
o The clock is turned backwards one second at the end of the leap
second.
o The clock is frozen during the duration of the leap second.
o The clock is slowed down during and slightly after the duration of
the leap second, until the new time value catches up.
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 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 | +------------------+-----------+-----------+-----------+ format |
skipping to change at page 9, line 38 skipping to change at page 11, line 42
| TWAMP [RFC8186] | | | + | | | TWAMP [RFC8186] | | | + | |
+------------------+-----------+-----------+-----------+-----------+ +------------------+-----------+-----------+-----------+-----------+
| TRILL [RFC7456] | | | + | | | TRILL [RFC7456] | | | + | |
+------------------+-----------+-----------+-----------+-----------+ +------------------+-----------+-----------+-----------+-----------+
| MPLS [RFC6374] | | | + | | | MPLS [RFC6374] | | | + | |
+------------------+-----------+-----------+-----------+-----------+ +------------------+-----------+-----------+-----------+-----------+
| TCP [RFC1323] | | | | + | | TCP [RFC1323] | | | | + |
+------------------+-----------+-----------+-----------+-----------+ +------------------+-----------+-----------+-----------+-----------+
| RTP [RFC3550] | + | | | + | | RTP [RFC3550] | + | | | + |
+------------------+-----------+-----------+-----------+-----------+ +------------------+-----------+-----------+-----------+-----------+
| [I-D.ietf-ippm- | + | + | | |
| initial-registry]| | | | |
+------------------+-----------+-----------+-----------+-----------+
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.
5.1. Example 1 6.1. Example 1
Timestamp: Timestamp:
The timestamp format used in this specification is the NTP The timestamp format used in this specification is the NTP
[RFC5905] 64-bit format, as specified in Section 4.2.1 of [RFC5905] 64-bit format, as specified in Section 4.2.1 of
[I-D.mizrahi-intarea-packet-timestamps]. [I-D.ietf-ntp-packet-timestamps].
Synchronization aspects: Synchronization aspects:
It is assumed that nodes that run this protocol are synchronized It is assumed that nodes that run this protocol are synchronized
to UTC using a synchronization mechanism that is outside the scope to UTC using a synchronization mechanism that is outside the scope
of this document. In typical deployments this protocol will be of this document. In typical deployments this protocol will run
run on a machine that uses NTP [RFC5905] for synchronization. on a machine that uses NTP [RFC5905] for synchronization. Thus,
Thus, the timestamp may be derived from the NTP-synchronized the timestamp may be derived from the NTP-synchronized clock,
clock, allowing the timestamp to be measured with respect to the allowing the timestamp to be measured with respect to the clock of
clock of an NTP server. 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 or slightly after a leap
second may be temporarily inaccurate.
5.2. Example 2 6.2. Example 2
Timestamp: Timestamp:
The timestamp format used in this specification is the PTP The timestamp format used in this specification is the PTP
[IEEE1588] Truncated format, as specified in Section 4.2.3 of [IEEE1588] Truncated format, as specified in Section 4.2.3 of
[I-D.mizrahi-intarea-packet-timestamps]. [I-D.ietf-ntp-packet-timestamps].
Synchronization aspects: Synchronization aspects:
It is assumed that nodes that run this protocol are synchronized It is assumed that nodes that run this protocol are synchronized
among themselves. Nodes may be synchronized to a global reference among themselves. Nodes may be synchronized to a global reference
time. Note that if PTP [IEEE1588] is used for synchronization, time. Note that if PTP [IEEE1588] is used for synchronization,
the timestamp may be derived from the PTP-synchronized clock, the timestamp may be derived from the PTP-synchronized clock,
allowing the timestamp to be measured with respect to the clock of allowing the timestamp to be measured with respect to the clock of
an PTP Grandmaster clock. an PTP Grandmaster clock.
6. Packet Timestamp Control Field 7. Packet Timestamp Control Field
In some cases it is desirable to have a control field that includes In some cases it is desirable to have a control field that includes
information about the timestamp format. This section defines a information about the timestamp format. Control information about
recommended format of a timestamp-related control field that is the timestamp format can be conveyed in some protocols using a
intended for network protocols that require such timestamp-related dedicated control plane protocol, or may be made available at the
control information. management plane, for example using a YANG data model. The optional
control field that is defined in this section allows some of the
control information to be attached to the timestamp. This section
defines requirements and a recommended format of a timestamp-related
control field that is intended for network protocols that can benefit
from such timestamp-related control information.
The recommended control field includes the following sub-fields: 7.1. High-level Control Field Requirements
o Timestamp format. 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.
o Precision - the resolution or granularity of the system clock. 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
accuracy, leap seconds, reference clock identifiers, etc.
o Epoch. 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.
o Era - the number of times the time has wrapped around since the 3. Composition: Applications may depend on specific control field
epoch. 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. This memo
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.
7. IANA Considerations 4. Category: Control field elements can characterize either static
timestamp information (like, e.g., timestamp size in bytes and
timestamp semantics: NTP 64 bit format) or runtime timestamp
information (like, e.g., estimated timestamp accuracy at the time
of sampling: 20 microseconds to UTC). For efficiency reason it
is 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.
7.2. Control Field Categories
Depending on their characteristics, the elements or components of a
timestamp control field can be assigned to one of two categories:
Structure (static) or Instance (runtime). Aim of this categorization
is to support minimum overhead of timestamp control fields in
practice. Protocols may use structural elements once, at connection
setup time to define or negotiate the timestamp structure and instace
elements (repeatedly) to identify the quality of timestamp instances
at runtime.
1. <Structure>: static timestamp control field. The static control
field identifies information like timestamp structure, type,
size, or features, that characterize and are common to a set of
related timestamps. Typical use of such a control field is at
connection establishment time when protocols negotiate available
and preferred timestamp types and features to be used for the
lifetime of an association. For instance endpoints can specify
the type, structure and size of the timestamp representation
within protocol messages that will be exchanged as part of a
following protocol session. These can be either standard
timestamp formats like NTP 64 bit as specified by this memo or
specific vendor-defined timestamp formats.
2. <Instance>: runtime timestamp control field. Besides static
information, dynamic (runtime) timestamp information is commonly
available at the sender when sampling a specific timestamp
instance. Typical examples include the ID of a clock that
originated a specific timestamp, the estimated time
synchronization accuracy of the local reference clock when
sampling a specific timestamp, or the correction to apply due to
an ongoing leap smear for a leap second. Moreover, with today's
critical infrastructures depending increasingly on accurate time,
provable signatures may become an essential runtime parameter to
protect the integrity of timestamp and control field values. The
accurate and reliable operation of timestamp receivers can
benefit from this detailed runtime control field information that
augments any single timestamp.
Drawing analogies to programming languages, the static timestamp
control field maps best to concepts like "type", "structure", or
"template", whereas the runtime timestamp control field corresponds
to "variables", i.e., runtime-instantiations of types. Main
consequence is that static timestamp control fields may be exchanged
only once during an ongoing association, saving substantial link
capacity, whereas a runtime timestamp control field accompanies any
single message or timestamp instance. Still, some protocols may
prefer to augment any single timestamp instance with both, a static
and a runtime control field. Example use cases for the latter
variant include potential support for heterogeneity in terms of
timestamps - various clients can decide dynamically which timestamp
format they send as part of the protocol - or to include a maximum of
timestamp context for receivers in the case of sporadic messages.
7.3. Control Field Features and Elements
The timestamp control field is composed of elements that can be
selected from the following set:
o Timestamp format
o Timestamp format specification
o Precision
o Timescale
o Leap second
o Reference clock(s)
o Probable signature
o Custom extension
o ... (tbd)
The following subsections detail on the role of the elements, their
structure and related constraints. Any element is characterized by
the following parameters:
o ID: <IANA identifier for this element>
o Type: Either <structure>: element defines static timestamp
structure that can subsequently be used to describe several
instances of timestamps - typically used once during connection
setup, or <instance>: parameter characteristic to a specific
timestamp instance.
o Status: <mandatory>, <conditional mandatory>, or <optional>.
Note: interpretation of the status field depends on the value of
the type field. If type is <structure>, then status <mandatory>
means that this element must be part of any <structure>-type
timestamp control field. However, it may be part of <instance>-
type timestamp control field, too.
o Size: <the size of this element, including all elements>
o Value: the value or subfields of this element
o Comments: Additions and considerations for this element
7.3.1. Timestamp Format
The timestamp format field defines the size and semantics of the
timestamp that follows this timestamp control field by referencing
appropriate IANA IDs.
o ID: tbd
o Type: <structure>
o Status: <mandatory>
o Size: tbd
o Value: IANA identifier, referencing either a standard format
defined by this memo or an alternate timestamp format (e.g.
vendor-specific extension). In the latter case, a Timestamp
Format Specification field is conditional mandatory.
o Comments:
7.3.2. Timestamp Format Specification
The timestamp format specification field defines the structure and
size of custom timestamps and is needed whenever the use of standard
timestamp formats is inappropriate.
o ID: tbd
o Type: <structure>
o Status: <conditional mandatory>. This field must be included
whenever the "timestamp format" element references non-standard
timestamp formats and must not be included into the control field
otherwise.
o Size: tbd
o Value: Subfields: 1. Timestamp size; 2. User- or vendor-specific
id and 3. Sub-id that allow to uniquely identify this timestamp
type;
o Comments:
7.3.3. Timestamp Precision
The precision field value stores the precision of the clock that
originated the timestamp at the time when the timestamp was sampled
along with attributes that characterize the timestamp quality (like
absolute or relative synchronization, reference clock identifiers,
etc.)
o ID: tbd
o Type: <instance> (optionally: <structure> when the clock
originating the timestamps has maximum limits for precision)?
o Status: <optional>. The local system may or may not know the
precision (or accuracy) of its clock and sampled timestamps.
o Size: tbd
o Value: Subfields: 1. Estimated Precision (in terms of 10^(-x)),
2. Maximum Error, 3. Reference (Absolute: UTC, TAI ...,
Relative: to specific clock, needs reference to clock ID)
o Comments: NTF calls this "error".
7.3.4. Timestamp Timescale
The timescale field denotes Epoch and Era of the timestamp
o ID: tbd
o Type: <instance>
o Status: <optional>
o Size: tbd
o Value: Subfields: 1. epoch 2. era
o Comments:
7.3.5. Timestamp Leap Second
o ID: tbd
o Type: <instance>
o Status: <optional>
o Size: tbd
o Value: Subfields: 1. Leap second ongoing 2. Considered leap
second fraction (during leap smear)
o Comments:
7.3.6. Reference Clock
o ID: tbd
o Type: <instance> (perhaps <structure>, too)
o Status: <optional>
o Size: tbd
o Value: Subfields: 1. Reference clock type 2. Unique reference
clock ID
o Comments:
7.3.7. Provable Signature
o ID: tbd
o Type: <instance>
o Status: <optional>
o Size: tbd
o Value: Signature covering the entire timstamp control field and
the timestamp field, masking out the provable signature field with
0.
o Comments:
7.3.8. Custom Extension
o ID: tbd
o Type: <structure> or <instance>
o Status: <optional>
o Size: tbd
o Value: tbd
o Comments: For future extensions
7.4. Control Field Payload Definition
This section defines the binding format of timestamp control
(sub)fields to be used by protocols. (tbd)
8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. 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
skipping to change at page 12, line 5 skipping to change at page 20, line 12
protection mechanisms. In some cases delay attacks can be mitigated protection mechanisms. In some cases delay attacks can be mitigated
by sending the timestamped information through multiple paths, by sending the timestamped information through multiple paths,
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].
9. Acknowledgments 10. Acknowledgments
The authors thank Yaakov Stein and other members of the TICTOC and The authors thank Yaakov Stein, Greg Mirsky, Warner Losh, Rodney
NTP working groups for many helpful comments. Cummings and other members of the NTP working group for many helpful
comments. The authors gratefully acknowlege Harlan Stenn and the
people from the Network Time Foundation for sharing their thoughts
and ideas.
10. References 11. References
10.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>.
10.2. Informative References 11.2. Informative References
[I-D.mizrahi-intarea-packet-timestamps] [I-D.ietf-ippm-initial-registry]
Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza,
Defining Packet Timestamps", draft-mizrahi-intarea-packet- "Initial Performance Metric Registry Entries", draft-ietf-
timestamps-01 (work in progress), September 2017. ippm-initial-registry-06 (work in progress), March 2018.
[I-D.morton-ippm-mbm-registry] [I-D.ietf-ntp-packet-timestamps]
Morton, A. and M. Mathis, "Initial Performance Metric Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
Registry Entries Part 2: MBM", draft-morton-ippm-mbm- Defining Packet Timestamps", draft-ietf-ntp-packet-
registry-01 (work in progress), March 2017. timestamps-00 (work in progress), October 2017.
[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
Control Systems Version 2", 2008. Control Systems Version 2", 2008.
[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.
skipping to change at page 14, line 18 skipping to change at page 22, line 33
Marvell Marvell
6 Hamada st. 6 Hamada st.
Yokneam Yokneam
Israel Israel
Email: talmi@marvell.com Email: talmi@marvell.com
Joachim Fabini Joachim Fabini
Vienna University of Technology Vienna University of Technology
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
 End of changes. 50 change blocks. 
106 lines changed or deleted 501 lines changed or added

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