draft-ietf-ntp-packet-timestamps-05.txt   draft-ietf-ntp-packet-timestamps-06.txt 
NTP Working Group T. Mizrahi NTP Working Group T. Mizrahi
Internet-Draft Huawei Network.IO Innovation Lab Internet-Draft Huawei Network.IO Innovation Lab
Intended status: Informational J. Fabini Intended status: Informational J. Fabini
Expires: June 12, 2019 TU Wien Expires: August 15, 2019 TU Wien
A. Morton A. Morton
AT&T Labs AT&T Labs
December 9, 2018 February 11, 2019
Guidelines for Defining Packet Timestamps Guidelines for Defining Packet Timestamps
draft-ietf-ntp-packet-timestamps-05 draft-ietf-ntp-packet-timestamps-06
Abstract Abstract
This document specifies guidelines for defining binary packet Various network protocols make use of binary-encoded timestamps that
timestamp formats in networking protocols at various layers. It also are incorporated in the protocol packet format, referred to as packet
presents three recommended timestamp formats. The target audience of timestamps for short. This document specifies guidelines for
this memo includes network protocol designers. It is expected that a defining packet timestamp formats in networking protocols at various
new network protocol that requires a packet timestamp will, in most layers. It also presents three recommended timestamp formats. The
cases, use one of the recommended timestamp formats. If none of the target audience of this memo includes network protocol designers. It
recommended formats fits the protocol requirements, the new protocol is expected that a new network protocol that requires a packet
specification should specify the format of the packet timestamp timestamp will, in most cases, use one of the recommended timestamp
according to the guidelines in this document. formats. If none of the recommended formats fits the protocol
requirements, the new protocol specification should specify the
format of the packet timestamp according to the guidelines in this
document.
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 June 12, 2019. This Internet-Draft will expire on August 15, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
2.3. Terms used in this Document . . . . . . . . . . . . . . . 3 2.3. Terms used in this Document . . . . . . . . . . . . . . . 4
3. Packet Timestamp Specification Template . . . . . . . . . . . 4 3. Packet Timestamp Specification Template . . . . . . . . . . . 4
4. Recommended Timestamp Formats . . . . . . . . . . . . . . . . 5 4. Recommended Timestamp Formats . . . . . . . . . . . . . . . . 5
4.1. Using a Recommended Timestamp Format . . . . . . . . . . 6 4.1. Using a Recommended Timestamp Format . . . . . . . . . . 6
4.2. NTP Timestamp Formats . . . . . . . . . . . . . . . . . . 6 4.2. NTP Timestamp Formats . . . . . . . . . . . . . . . . . . 6
4.2.1. NTP 64-bit Timestamp Format . . . . . . . . . . . . . 6 4.2.1. NTP 64-bit Timestamp Format . . . . . . . . . . . . . 6
4.2.2. NTP 32-bit Timestamp Format . . . . . . . . . . . . . 7 4.2.2. NTP 32-bit Timestamp Format . . . . . . . . . . . . . 8
4.3. The PTP Truncated Timestamp Format . . . . . . . . . . . 9 4.3. The PTP Truncated Timestamp Format . . . . . . . . . . . 9
5. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 10 5. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 11
6. Timestamp Use Cases . . . . . . . . . . . . . . . . . . . . . 11 6. Timestamp Use Cases . . . . . . . . . . . . . . . . . . . . . 12
6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Packet Timestamp Control Field . . . . . . . . . . . . . . . 13 7. Packet Timestamp Control Field . . . . . . . . . . . . . . . 13
7.1. High-level Control Field Requirements . . . . . . . . . . 14 7.1. High-level Control Field Requirements . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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
skipping to change at page 3, line 12 skipping to change at page 3, line 27
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 [RFC1323].
This memo presents guidelines for defining a packet timestamp format This memo presents guidelines for defining a packet timestamp format
in network protocols. Three recommended timestamp formats are 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 the recommended a packet timestamp will, in most cases, use one of these recommended
timestamp formats. If none of the recommended formats fits the timestamp formats. In some cases a network protocol may use more
protocol requirements, the new protocol specification should specify than one of the recommended timestamp formats. However, if none of
the format of the packet timestamp according to the guidelines in the recommended formats fits the protocol requirements, the new
this document. protocol specification should specify the format of the packet
timestamp according to the guidelines in this document.
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", "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
skipping to change at page 5, line 13 skipping to change at page 5, line 31
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:
The specification of a network protocol that makes use of a packet
timestamp is expected to include the synchronization aspects of
using the timestamp. While the synchronization aspects are not
strictly part of the timestamp format specification, these aspects
provide the necessary context for using the timestamp within the
scope of the protocol. Further details about synchronization
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 memo defines a set of recommended timestamp formats. Defining a
relatively small set of recommended formats enables significant relatively small set of recommended formats enables significant
reuse; for example, a network protocol may reuse the NTP or PTP reuse; for example, a network protocol may reuse the NTP or PTP
timestamp format, allowing a straightforward integration with an NTP timestamp format, allowing a straightforward integration with an NTP
or a PTP-based timer. Moreover, since accurate timestamping 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 memo
skipping to change at page 10, line 29 skipping to change at page 11, line 9
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. Synchronization Aspects 5. Synchronization Aspects
A specification that defines a new timestamp format or uses one of A specification that defines a new timestamp format or uses one of
the recommended timestamp formats should include a section on the recommended timestamp formats should include a section on
Synchronization Aspects. Examples of such a section can be found in Synchronization Aspects. Note that the recommended timestamp formats
Section 6). defined in this document (Section 4) do not include the
synchronization aspects of these timestamp formats, but it is
expected that specifications of network protocols that make use of
these formats should include the synchronization aspects. Examples
of a Synchronization Aspects section can be found in Section 6.
The Synchronization Aspects section should specify all the The Synchronization Aspects section should specify all the
assumptions and requirements related to synchronization. For assumptions and requirements related to synchronization. For
example, the synchronization aspects may specify whether nodes example, the synchronization aspects may specify whether nodes
populating the timestamps should be synchronized among themselves, populating the timestamps should be synchronized among themselves,
and whether the timestamp is measured with respect to a central and whether the timestamp is measured with respect to a central
reference clock such as an NTP server. If time is assumed to be 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 synchronized to a time standard such as UTC or TAI, it should be
specified in this section. Further considerations may be discussed specified in this section. Further considerations may be discussed
in this section, such as the required timestamp accuracy. in this section, such as the required timestamp accuracy and
precision.
Another aspect that should be discussed in this section is leap Another aspect that should be discussed in this section is leap
second [RFC5905] considerations. The timestamp specification second [RFC5905] considerations. The timestamp specification
template (Section 3) specifies whether the timestamp is affected by template (Section 3) specifies whether the timestamp is affected by
leap seconds. It is often the case that further details about leap leap seconds. It is often the case that further details about leap
seconds will need to be defined in the Synchronization Aspects seconds will need to be defined in the Synchronization Aspects
section. Generally speaking, a leap second is a one-second section. Generally speaking, a leap second is a one-second
adjustment that is occasionally applied to UTC in order to keep it adjustment that is occasionally applied to UTC in order to keep it
aligned to the solar time. A leap second may be either positive or aligned to the solar time. A leap second may be either positive or
negative, i.e., the clock may either be shifted one second forwards negative, i.e., the clock may either be shifted one second forwards
skipping to change at page 12, line 15 skipping to change at page 12, line 31
+------------------+-----------------------------------+-----------+ +------------------+-----------------------------------+-----------+
| | Recommended formats | Other | | | Recommended formats | Other |
+------------------+-----------+-----------+-----------+ format | +------------------+-----------+-----------+-----------+ 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 [RFC1323] | | | | + |
+------------------+-----------+-----------+-----------+-----------+ +------------------+-----------+-----------+-----------+-----------+
| RTP [RFC3550] | + | | | + | | RTP [RFC3550] | + | | | + |
+------------------+-----------+-----------+-----------+-----------+ +------------------+-----------+-----------+-----------+-----------+
| IPFIX [RFC7011] | | | | + | | IPFIX [RFC7011] | | | | + |
skipping to change at page 16, line 8 skipping to change at page 16, line 15
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 Yaakov Stein, Greg Mirsky, Warner Losh, Rodney
Cummings, Miroslav Lichvar, Denis Reilly, and other members of the Cummings, Miroslav Lichvar, Denis Reilly, Daniel Franke, Watson Ladd,
NTP working group for many helpful comments. The authors gratefully and other members of the NTP working group for many helpful comments.
acknowledge Harlan Stenn and the people from the Network Time The authors gratefully acknowledge Harlan Stenn and the people from
Foundation for sharing their thoughts and ideas. 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>.
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 Metric Registry Entries", draft-ietf- "Initial Performance Metric Registry Entries", draft-ietf-
ippm-initial-registry-08 (work in progress), October 2018. ippm-initial-registry-09 (work in progress), December
2018.
[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-04 (work in progress), October 2018. timestamps-05 (work in progress), December 2018.
[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
 End of changes. 19 change blocks. 
35 lines changed or deleted 66 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/