rfc8877xml2.original.xml   rfc8877.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!-- [
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info"
docName="draft-ietf-ntp-packet-timestamps-09" ipr="trust200902"
obsoletes="" updates="" submissionType="IETF" xml:lang="en"
tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3"
consensus="true" number="8877">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3552.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5226.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-ietf-ntp-packet-timestamps-09"
ipr="trust200902">
<front> <front>
<title abbrev="Packet Timestamps">Guidelines for Defining Packet <title abbrev="Packet Timestamps">Guidelines for Defining Packet
Timestamps</title> Timestamps</title>
<seriesInfo name="RFC" value="8877"/>
<author fullname="Tal Mizrahi" initials="T." surname="Mizrahi"> <author fullname="Tal Mizrahi" initials="T." surname="Mizrahi">
<organization abbrev="">Huawei Smart Platforms iLab</organization> <organization abbrev="">Huawei</organization>
<address> <address>
<postal> <postal>
<street>8-2 Matam</street> <street>8-2 Matam</street>
<city>Haifa</city> <city>Haifa</city>
<code>3190501</code> <code>3190501</code>
<country>Israel</country> <country>Israel</country>
</postal> </postal>
<email>tal.mizrahi.phd@gmail.com</email> <email>tal.mizrahi.phd@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Joachim Fabini" initials="J." surname="Fabini"> <author fullname="Joachim Fabini" initials="J." surname="Fabini">
<organization>TU Wien</organization> <organization>TU Wien</organization>
<address> <address>
<postal> <postal>
<street>Gusshausstrasse 25/E389</street> <street>Gusshausstrasse 25/E389</street>
<city>Vienna</city><code>1040</code>
<city>Vienna 1040</city>
<country>Austria</country> <country>Austria</country>
</postal> </postal>
<phone>+43 1 58801 38813</phone> <phone>+43 1 58801 38813</phone>
<facsimile>+43 1 58801 38898</facsimile>
<email>Joachim.Fabini@tuwien.ac.at</email> <email>Joachim.Fabini@tuwien.ac.at</email>
<uri>http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/</uri> <uri>http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/</uri>
</address> </address>
</author> </author>
<author fullname="Al Morton" initials="A." surname="Morton"> <author fullname="Al Morton" initials="A." surname="Morton">
<organization>AT&amp;T Labs</organization> <organization>AT&amp;T Labs</organization>
<address> <address>
<postal> <postal>
<street>200 Laurel Avenue South</street> <street>200 Laurel Avenue South</street>
<city>Middletown</city>
<city>Middletown,</city>
<region>NJ</region> <region>NJ</region>
<code>07748</code> <code>07748</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<phone>+1 732 420 1571</phone> <phone>+1 732 420 1571</phone>
<facsimile>+1 732 368 1192</facsimile>
<email>acmorton@att.com</email> <email>acmorton@att.com</email>
</address> </address>
</author> </author>
<date month="September" year="2020"/>
<date year="2020"/>
<area>General</area> <area>General</area>
<workgroup>NTP Working Group</workgroup> <workgroup>NTP Working Group</workgroup>
<keyword>Timestamps</keyword> <keyword>Timestamps</keyword>
<abstract> <abstract>
<t>Various network protocols make use of binary-encoded timestamps that <t>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 defining timestamps" for short. This document specifies guidelines for defining
packet timestamp formats in networking protocols at various layers. It packet timestamp formats in networking protocols at various layers. It
also presents three recommended timestamp formats. The target audience also presents three recommended timestamp formats. The target audience
of this document includes network protocol designers. It is expected of this document includes network protocol designers. It is expected
that a new network protocol that requires a packet timestamp will, in that a new network protocol that requires a packet timestamp will, in
most cases, use one of the recommended timestamp formats. If none of the most 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
specification should specify the format of the packet timestamp specification should specify the format of the packet timestamp
according to the guidelines in this document.</t> according to the guidelines in this document.</t>
</abstract> </abstract>
</front> </front>
skipping to change at line 112 skipping to change at line 71
packet timestamp formats in networking protocols at various layers. It packet timestamp formats in networking protocols at various layers. It
also presents three recommended timestamp formats. The target audience also presents three recommended timestamp formats. The target audience
of this document includes network protocol designers. It is expected of this document includes network protocol designers. It is expected
that a new network protocol that requires a packet timestamp will, in that a new network protocol that requires a packet timestamp will, in
most cases, use one of the recommended timestamp formats. If none of the most 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
specification should specify the format of the packet timestamp specification should specify the format of the packet timestamp
according to the guidelines in this document.</t> according to the guidelines in this document.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<section title="Background"> <name>Introduction</name>
<section numbered="true" toc="default">
<name>Background</name>
<t>Timestamps are widely used in network protocols for various <t>Timestamps are widely used in network protocols for various
purposes: timestamps are used for logging or reporting the time of an purposes: for logging or reporting the time of an
event, delay measurement and clock synchronization protocols both make event, for messages in delay measurement and clock synchronization
use of timestamped messages, and in security protocols a timestamp is protocols, and as part of a value that is unlikely to repeat (nonce)
often used as part of a value that is unlikely to repeat (nonce).</t> in security protocols.</t>
<t>Timestamps are represented in the RFC series in one of two forms: <t>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
<xref target="RFC3339"/> are represented as user-friendly strings, and <xref target="RFC3339" format="default"/> are represented as user-friend
are widely used in the RFC series, for example in information objects ly strings and
and data models, e.g., <xref target="RFC5646"/>, <xref are widely used in the RFC series -- for example, in information objects
target="RFC6991"/>, and <xref target="RFC7493"/>. Packet timestamps, and data models, e.g., <xref target="RFC5646" format="default"/>, <xref
target="RFC6991" format="default"/>, and <xref target="RFC7493" format="default"
/>. Packet timestamps,
on the other hand, are represented by a compact binary field that has on the other hand, are represented by a compact binary field that has
a fixed size, and are not intended to have a human-friendly format. a fixed size and are not intended to have a human-friendly format.
Packet timestamps are also very common in the RFC series, and are used Packet timestamps are also very common in the RFC series and are used,
for example for measuring delay and for synchronizing clocks, e.g., for example, for measuring delay and for synchronizing clocks, e.g.,
<xref target="RFC5905"/>, <xref target="RFC4656"/>, and <xref <xref target="RFC5905" format="default"/>, <xref target="RFC4656" format
target="RFC7323"/>.</t> ="default"/>, and <xref target="RFC7323" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Scope of this Document"> <name>Scope of this Document</name>
<t>This document presents guidelines for defining a packet timestamp <t>This document presents guidelines for defining a packet timestamp
format in network protocols. Three recommended timestamp formats are format in network protocols. Three recommended timestamp formats are
presented. It is expected that a new network protocol that requires a presented. It is expected that a new network protocol that requires a
packet timestamp will, in most cases, use one of these recommended packet timestamp will, in most cases, use one of these recommended
timestamp formats. In some cases a network protocol may use more than timestamp formats. In some cases, a network protocol may use more than
one of the recommended timestamp formats. However, if none of the one of the recommended timestamp formats. However, if none of the
recommended formats fits the protocol requirements, the new protocol recommended formats fits the protocol requirements, the new protocol
specification should specify the format of the packet timestamp specification should specify the format of the packet timestamp
according to the guidelines in this document.</t> according to the guidelines in this document.</t>
<t>The rationale behind defining a relatively small set of recommended <t>The rationale behind defining a relatively small set of recommended
formats is that it enables significant reuse; network protocols can formats is that it enables significant reuse; network protocols can
typically reuse the timestamp format of the Network Time Protocol typically reuse the timestamp format of the Network Time Protocol
(NTP) or the Precision Time Protocol (PTP), allowing a straightforward (NTP) <xref target="RFC5905"/> or the Precision Time Protocol (PTP)
integration with an NTP or a PTP-based timer. Moreover, since accurate <xref target="IEEE1588"/>, allowing a straightforward
integration with an NTP- or PTP-based timer. Moreover, since accurate
timestamping mechanisms are often implemented in hardware, a new timestamping mechanisms are often implemented in hardware, a new
network protocol that reuses an existing timestamp format can be network protocol that reuses an existing timestamp format can be
quickly deployed using existing hardware timestamping quickly deployed using existing hardware timestamping
capabilities.</t> capabilities.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="How to Use This Document"> <name>How to Use This Document</name>
<t>This document is intended as a reference for network protocol <t>This document is intended as a reference for network protocol
designers. When defining a network protocol that uses a packet designers. When defining a network protocol that uses a packet
timestamp, the recommended timestamp formats should be considered timestamp, the recommended timestamp formats should be considered
first (<xref target="Recommended"/>). If one of these formats is used, first (<xref target="Recommended" format="default"/>). If one of these f
it should be referenced along the lines of the examples in <xref ormats is used,
target="Ex1Sec"/> and <xref target="Ex2Sec"/>. If none of the it should be referenced along the lines of the examples in Sections <xre
f target="Ex1Sec" format="counter"/> and <xref target="Ex2Sec" format="counter"/
>. If none of the
recommended formats fits the required functionality, then a new recommended formats fits the required functionality, then a new
timestamp format should be defined using the template of <xref timestamp format should be defined using the template in <xref target="f
target="format"/>.</t> ormat" format="default"/>.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Terminology"> <name>Terminology</name>
<section title="Requirements Language"> <section numbered="true" toc="default">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <name>Requirements Language</name>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <t>
"OPTIONAL" in this document are to be interpreted as described in BCP The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
when, they appear in all capitals, as shown here.</t> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Abbreviations"> <name>Abbreviations</name>
<t>NTP &nbsp; &nbsp; &nbsp; &nbsp; Network Time Protocol <xref <dl newline="false" spacing="normal" indent="8">
target="RFC5905"/></t> <dt>NTP</dt>
<dd>Network Time Protocol <xref target="RFC5905" format="default"/></dd>
<t>PTP &nbsp; &nbsp; &nbsp; &nbsp; Precision Time Protocol <xref <dt>PTP</dt>
target="IEEE1588"/></t> <dd>Precision Time Protocol <xref target="IEEE1588" format="default"/></dd>
<dt>TAI</dt>
<t>TAI &nbsp; &nbsp; &nbsp; &nbsp; International Atomic Time</t> <dd>International Atomic Time</dd>
<dt>UTC</dt>
<t>UTC &nbsp; &nbsp; &nbsp; &nbsp; Coordinated Universal Time</t> <dd>Coordinated Universal Time</dd>
</dl>
</section> </section>
<section numbered="true" toc="default">
<section title="Terms used in this Document"> <name>Terms Used in This Document</name>
<t><list hangIndent="23" style="hanging"> <dl newline="false" spacing="normal" indent="23">
<t hangText="Timestamp:">A value that represents a point in time, <dt>Timestamp:</dt>
<dd>A value that represents a point in time,
corresponding to an event that occurred or is scheduled to corresponding to an event that occurred or is scheduled to
occur.</t> occur.</dd>
<dt>Timestamp error:</dt>
<t hangText="Timestamp error:">The difference between the <dd>The difference between the
timestamp value and the value of a reference clock at the time of timestamp value and the value of a reference clock at the time of
the event that the timestamp was intended to indicate.</t> the event that the timestamp was intended to indicate.</dd>
<dt>Timestamp format:</dt>
<t hangText="Timestamp format:">The specification of a timestamp, <dd>The specification of a timestamp,
which is represented by a set of attributes that unambiguously which is represented by a set of attributes that unambiguously
define the syntax and semantics of a timestamp.</t> defines the syntax and semantics of a timestamp.</dd>
<dt>Timestamp accuracy:</dt>
<t hangText="Timestamp accuracy:">The mean over an ensemble of <dd>The mean over an ensemble of
measurements of the timestamp error.</t> measurements of the timestamp error.</dd>
<dt>Timestamp precision:</dt>
<t hangText="Timestamp precision:">The variation over an ensemble <dd>The variation over an ensemble
of measurements of the timestamp error.</t> of measurements of the timestamp error.</dd>
<dt>Timestamp resolution:</dt>
<t hangText="Timestamp resolution:">The minimal time unit used for <dd>The minimal time unit used for
representing the timestamp.</t> representing the timestamp.</dd>
</list></t> </dl>
</section> </section>
</section> </section>
<section anchor="format" numbered="true" toc="default">
<section anchor="format" title="Packet Timestamp Specification Template"> <name>Packet Timestamp Specification Template</name>
<t>This document recommends to use the timestamp formats defined in <t>This document recommends using the timestamp formats defined in
<xref target="Recommended"/>. In cases where these timestamp formats do <xref target="Recommended" format="default"/>. In cases where these timest
amp formats do
not satisfy the protocol requirements, the timestamp specification not satisfy the protocol requirements, the timestamp specification
should clearly state the reasons for defining a new format. Moreover, it should clearly state the reasons for defining a new format. Moreover, it
is recommended to derive the new timestamp format from an existing is recommended to derive the new timestamp format from an existing
timestamp format, either a timestamp format from this document, or any timestamp format, either a timestamp format from this document or any
other previously defined timestamp format.</t> other previously defined timestamp format.</t>
<t>The timestamp specification must unambiguously define the syntax and <t>The timestamp specification must unambiguously define the syntax and
the semantics of the timestamp. The current section defines the minimum semantics of the timestamp. The current section defines the minimum
set of attributes, but it should be noted that in some cases additional set of attributes, but it should be noted that in some cases, additional
attributes or aspects will need to be defined in the timestamp attributes or aspects will need to be defined in the timestamp
specification.</t> specification.</t>
<t>This section defines a template for specifying packet timestamps. A <t>This section defines a template for specifying packet timestamps. A
timestamp format specification MUST include at least the following timestamp format specification <bcp14>MUST</bcp14> include at least the fo llowing
aspects:</t> aspects:</t>
<dl newline="true" spacing="normal">
<t>Timestamp syntax: <list hangIndent="10" style="empty"> <dt>Timestamp syntax:</dt>
<t>- Size: The number of bits (or octets) used to represent the <dd>
packet timestamp field. If the timestamp is comprised of more than <dl newline="false" spacing="normal">
<dt>Size:</dt><dd><t> The number of bits (or octets) used to represent
the packet timestamp field. If the timestamp is comprised of more than
one field, the size of each field is specified. Network order (big one field, the size of each field is specified. Network order (big
endian) is assumed by default; if this is not the case then this endian) is assumed by default; if this is not the case, then this
section explicitly specifies the endianity.</t> section explicitly specifies the endianity.</t></dd></dl></dd></dl>
</list></t>
<t>Timestamp semantics: <list hangIndent="10" style="empty"> <dl newline="true" spacing="normal">
<t>- Units: The units used to represent the timestamp. If the <dt>Timestamp semantics:</dt><dd>
<dl newline="false" spacing="normal">
<dt>Units:</dt><dd><t>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. If a field is limited to a specific range of field are specified. If a field is limited to a specific range of
values, this section specifies the permitted range of values.</t> values, this section specifies the permitted range of values.</t></dd>
<dt>Resolution:</dt><dd><t>The timestamp resolution; the resolution is e
<t>- Resolution: The timestamp resolution; the resolution is equal qual
to the timestamp field unit. If the timestamp consists of two or to 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.</t> smallest time unit.</t></dd>
<dt>Wraparound:</dt><dd><t>The wraparound period of the timestamp; any f
<t>- Wraparound: The wraparound period of the timestamp; any further urther
wraparound-related considerations should be described here.</t> wraparound-related considerations should be described here.</t></dd>
<dt>Epoch:</dt><dd><t>The origin of the timescale used for the timestamp
<t>- Epoch: The origin of the timescale used for the timestamp; the ; 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
could be the time at which the device using the timestamp was could be the time at which the device using the timestamp was
powered up, and is not affected by leap seconds (see the next powered up and is not affected by leap seconds (see the next
attribute).</t> attribute).</t></dd>
<dt>Leap seconds:</dt><dd><t>This subsection specifies whether the times
<t>- Leap seconds: This subsection specifies whether the timestamp tamp
is affected by leap seconds. If the timestamp is affected by leap is 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.</t> the number of leap seconds that have occurred since the epoch.</t></dd
</list></t> >
</dl></dd></dl>
<t>Synchronization aspects: <list hangIndent="10" style="empty"> <dl newline="true" spacing="normal">
<t>The specification of a network protocol that makes use of a <dt>Synchronization aspects:</dt>
<dd>The specification of a network protocol that makes use of a
packet timestamp is expected to include the synchronization aspects packet timestamp is expected to include the synchronization aspects
of using the timestamp. While the synchronization aspects are not of 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. In some cases timestamps are used without scope of the protocol. In some cases, timestamps are used without
synchronization, e.g., a timestamp that indicates the number of synchronization, e.g., a timestamp that indicates the number of
seconds since power up. In such cases the Synchronization Aspects seconds since power-up. In such cases, the Synchronization Aspects
section will specify that the timestamp does not correspond to a section will specify that the timestamp does not correspond to a
synchronized time reference, and may discuss how this affects the synchronized time reference and may discuss how this affects the
usage of the timestamp. Further details about synchronization usage of the timestamp. Further details about synchronization
aspects are discussed in <xref target="SynchSec"/>.</t> aspects are discussed in <xref target="SynchSec" format="default"/>.</
</list></t> dd>
</dl>
</section> </section>
<section anchor="Recommended" numbered="true" toc="default">
<section anchor="Recommended" title="Recommended Timestamp Formats"> <name>Recommended Timestamp Formats</name>
<t>This document defines a set of recommended timestamp formats. <t>This document defines a set of recommended timestamp formats.
Clearly, different network protocols may have different requirements and Clearly, different network protocols may have different requirements and
constraints, and consequently may use different timestamp formats. The constraints; consequently, they may use different timestamp formats. The
choice of the specific timestamp format for a given protocol may depend choice of a specific timestamp format for a given protocol may depend
on a various factors. A few examples of factors that may affect the on various factors. A few examples of factors that may affect the
choice of the timestamp format:</t> choice of the timestamp format include the following:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Timestamp size: While some network protocols use a large
<t>Timestamp size: while some network protocols use a large timestamp field, in some cases, there may be constraints with respect
timestamp field, in some cases there may be constraints with respect
to the timestamp size, affecting the choice of the timestamp to the timestamp size, affecting the choice of the timestamp
format.</t> format.</li>
<li>Resolution: The time resolution is another factor that may
<t>Resolution: the time resolution is another factor that may
directly affect the selected timestamp format. A potentially directly affect the selected timestamp format. A potentially
important factor in this context is extensibility; it may be important factor in this context is extensibility; it may be
desirable to allow a timestamp format to be extensible to a higher desirable to allow a timestamp format to be extensible to a higher
resolution by extending the field. For example, the resolution of 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 32-bit timestamp format can be improved by extending it to
the NTP 64-bit timestamp format in a straightforward way.</t> the NTP 64-bit timestamp format in a straightforward way.</li>
<li>Wraparound period: The length of the time interval in which the
<t>Wraparound period: the length of the time interval in which the
timestamp is unique may also be an important factor in choosing the timestamp is unique may also be an important factor in choosing the
timestamp format. Along with the timestamp resolution, these two timestamp format. Along with the timestamp resolution, these two
factors determine the required number of bits in the timestamp.</t> factors determine the required number of bits in the timestamp.</li>
<li>Common format for multiple protocols: If there are two or more
<t>Common format for multiple protocols: if there are two or more
network protocols that use timestamps and are often used together in network protocols that use timestamps and are often used together in
typical systems, using a common timestamp format should be preferred typical systems, using a common timestamp format should be preferred
if possible. For example, if the network protocol that is being if possible. For example, if the network protocol that is being
defined typically runs on a PC, then an NTP-based timestamp format defined typically runs on a PC, then an NTP-based timestamp format
may allow easier integration with an NTP-synchronized timer. In may allow easier integration with an NTP-synchronized timer. In
contrast, a protocol that is typically deployed on a hardware-based contrast, a protocol that is typically deployed on a hardware-based
platform, may make better use of a PTP-based timestamp, allowing platform may make better use of a PTP-based timestamp, allowing
more efficient integration with a PTP-synchronized timer.</t> more efficient integration with a PTP-synchronized timer.</li>
</list></t> </ul>
<section numbered="true" toc="default">
<section title="Using a Recommended Timestamp Format"> <name>Using a Recommended Timestamp Format</name>
<t>A specification that uses one of the recommended timestamp formats <t>A specification that uses one of the recommended timestamp formats
should specify explicitly that this is a recommended timestamp format, should specify explicitly that this is a recommended timestamp format
and point to the relevant section in the current document.</t> and point to the relevant section in the current document.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="NTP Timestamp Formats"> <name>NTP Timestamp Formats</name>
<section title="NTP 64-bit Timestamp Format"> <section anchor="time-64bit" numbered="true" toc="default">
<name>NTP 64-Bit Timestamp Format</name>
<t>The Network Time Protocol (NTP) 64-bit timestamp format is <t>The Network Time Protocol (NTP) 64-bit timestamp format is
defined in <xref target="RFC5905"/>. This timestamp format is used defined in <xref target="RFC5905" format="default"/>. This timestamp f
in several network protocols, including <xref target="RFC6374"/>, ormat is used
<xref target="RFC4656"/>, and <xref target="RFC5357"/>. Since this in several network protocols, including <xref target="RFC6374" format=
timestamp format is used in NTP, this timestamp format should be "default"/>,
<xref target="RFC4656" format="default"/>, and <xref target="RFC5357"
format="default"/>. Since this
timestamp format is used in NTP, it should be
preferred in network protocols that are typically deployed in preferred in network protocols that are typically deployed in
concert with NTP.</t> concert with NTP.</t>
<t>The format is presented in this section according to the template <t>The format is presented in this section according to the template
defined in <xref target="format"/>.</t> defined in <xref target="format" format="default"/>.</t>
<figure anchor="NTPFormat">
<figure align="center" anchor="NTPFormat" <name>NTP 64-Bit Timestamp Format</name>
title="NTP [RFC5905] 64-bit Timestamp Format"> <artwork align="left" name="" type="" alt=""><![CDATA[
<artwork align="left"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds | | Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fraction | | Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Timestamp field format: <list hangIndent="10" style="empty"> <dl newline="true" spacing="normal">
<t>Seconds: specifies the integer portion of the number of <dt>Timestamp field format:</dt>
seconds since the epoch.</t> <dd>
<dl newline="false" spacing="normal">
<t>- Size: 32 bits.</t> <dt>Seconds:</dt><dd><t>Specifies the integer portion of the
number of seconds since the epoch.</t>
<t>- Units: seconds.</t> <dl newline="false" spacing="normal">
<dt>Size:</dt><dd>32 bits.</dd>
<t>Fraction: specifies the fractional portion of the number of <dt>Units:</dt> <dd>Seconds.</dd>
</dl>
</dd>
<dt>Fraction:</dt><dd><t>Specifies the fractional portion of the num
ber of
seconds since the epoch.</t> seconds since the epoch.</t>
<dl newline="false" spacing="normal">
<t>- Size: 32 bits.</t> <dt>Size:</dt><dd>32 bits.</dd>
<dt>Units:</dt><dd>The unit is 2<sup>-32</sup> seconds, which is rou
<t>- Units: the unit is 2^(-32) seconds, which is roughly equal ghly
to 233 picoseconds.</t> equal to 233 picoseconds.</dd>
</list></t> </dl>
</dd>
<t>Epoch: <list hangIndent="10" style="empty"> </dl>
<t>The epoch is 1 January 1900 at 00:00 UTC.</t> </dd>
<dt>Epoch:</dt><dd>
<t>Note: As pointed out in [RFC5905], strictly speaking, UTC did <t>The epoch is 1 January 1900 at 00:00 UTC.</t>
<t>Note: As pointed out in <xref target="RFC5905"/>, strictly speaki
ng, UTC did
not exist prior to 1 January 1972, but it is convenient to not exist prior to 1 January 1972, but it is convenient to
assume it has existed for all eternity. The current epoch assume it has existed for all eternity. The current epoch
implies that the timestamp specifies the number of seconds since implies that the timestamp specifies the number of seconds since
1 January 1972 at 00:00 UTC plus 2272060800 (which is the number 1 January 1972 at 00:00 UTC plus 2272060800 (which is the number
of seconds between 1 January 1900 and 1 January 1972).</t> of seconds between 1 January 1900 and 1 January 1972).</t>
</list></t> </dd>
<dt>Leap seconds:</dt><dd>
<t>Leap seconds: <list hangIndent="10" style="empty"> <t>This timestamp format is affected by leap seconds. The
<t>This timestamp format is affected by leap seconds. The
timestamp represents the number of seconds elapsed since the timestamp represents the number of seconds elapsed since the
epoch minus the number of leap seconds. Thus, during and epoch minus the number of leap seconds. Thus, during and
possibly before and/or after the occurrence of a leap second, possibly before and/or after the occurrence of a leap second,
the value of the timestamp may temporarily be ambiguous, as the value of the timestamp may temporarily be ambiguous, as
further discussed in <xref target="SynchSec"/>.</t> further discussed in <xref target="SynchSec" format="default"/>.</
</list></t> t>
</dd>
<t>Resolution: <list hangIndent="10" style="empty"> <dt>Resolution: </dt><dd>
<t>The resolution is 2^(-32) seconds.</t> <t>The resolution is 2<sup>-32</sup> seconds.</t>
</list></t> </dd>
<dt>Wraparound:</dt><dd>
<t>Wraparound: <list hangIndent="10" style="empty"> <t>This time format wraps around every 2<sup>32</sup> seconds, which
<t>This time format wraps around every 2^32 seconds, which is is
roughly 136 years. The next wraparound will occur in the year roughly 136 years. The next wraparound will occur in the year
2036.</t> 2036.</t>
</list></t> </dd>
</dl>
</section> </section>
<section numbered="true" toc="default">
<section title="NTP 32-bit Timestamp Format"> <name>NTP 32-Bit Timestamp Format</name>
<t>The Network Time Protocol (NTP) 32-bit timestamp format is <t>The Network Time Protocol (NTP) 32-bit timestamp format is
defined in <xref target="RFC5905"/>. This timestamp format is used defined in <xref target="RFC5905" format="default"/>. This timestamp f
in <xref target="I-D.ietf-ippm-initial-registry"/> and <xref ormat is used
target="I-D.ietf-sfc-nsh-dc-allocation"/>. This timestamp format in <xref target="I-D.ietf-ippm-initial-registry" format="default"/> an
d <xref target="I-D.ietf-sfc-nsh-dc-allocation" format="default"/>. This timesta
mp format
should be preferred in network protocols that are typically deployed should be preferred in network protocols that are typically deployed
in concert with NTP. The 32-bit format can be used either when space in concert with NTP. The 32-bit format can be used either when space
constraints do not allow the use of the 64-bit format, or when the constraints do not allow the use of the 64-bit format or when the
32-bit format satisfies the resolution and wraparound 32-bit format satisfies the resolution and wraparound
requirements.</t> requirements.</t>
<t>The format is presented in this section according to the template <t>The format is presented in this section according to the template
defined in <xref target="format"/>.</t> defined in <xref target="format" format="default"/>.</t>
<figure anchor="NTPShortFormat">
<figure align="center" anchor="NTPShortFormat" <name>NTP 32-Bit Timestamp Format</name>
title="NTP [RFC5905] 32-bit Timestamp Format"> <artwork align="left" name="" type="" alt=""><![CDATA[
<artwork align="left"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds | Fraction | | Seconds | Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<dl newline="true" spacing="normal">
<t>Timestamp field format: <list hangIndent="10" style="empty"> <dt>Timestamp field format:</dt>
<t>Seconds: specifies the integer portion of the number of <dd>
<dl newline="false" spacing="normal">
<dt>Seconds:</dt><dd><t>Specifies the integer portion of the number
of
seconds since the epoch.</t> seconds since the epoch.</t>
<dl newline="false" spacing="normal">
<dt>Size:</dt><dd>16 bits.</dd>
<dt>Units:</dt><dd>Seconds.</dd>
</dl>
</dd>
<t>- Size: 16 bits.</t> <dt>Fraction:</dt><dd><t>Specifies the fractional portion of the num
ber of
<t>- Units: seconds.</t>
<t>Fraction: specifies the fractional portion of the number of
seconds since the epoch.</t> seconds since the epoch.</t>
<dl newline="false" spacing="normal">
<t>- Size: 16 bits.</t> <dt>Size:</dt><dd>16 bits.</dd>
<dt>Units:</dt><dd>The unit is 2<sup>-16</sup> seconds, which is rou
<t>- Units: the unit is 2^(-16) seconds, which is roughly equal ghly equal
to 15.3 microseconds.</t> to 15.3 microseconds.</dd>
</list></t> </dl>
</dd>
<t>Epoch: <list hangIndent="10" style="empty"> </dl>
<t>The epoch is 1 January 1900 at 00:00 UTC.</t> </dd>
<dt>Epoch:</dt><dd>
<t>Note: As pointed out in [RFC5905], strictly speaking, UTC did <t>The epoch is 1 January 1900 at 00:00 UTC.</t>
<t>Note: As pointed out in <xref target="RFC5905"/>, strictly speaki
ng, UTC did
not exist prior to 1 January 1972, but it is convenient to not exist prior to 1 January 1972, but it is convenient to
assume it has existed for all eternity. The current epoch assume it has existed for all eternity. The current epoch
implies that the timestamp specifies the number of seconds since implies that the timestamp specifies the number of seconds since
1 January 1972 at 00:00 UTC plus 2272060800 (which is the number 1 January 1972 at 00:00 UTC plus 2272060800 (which is the number
of seconds between 1 January 1900 and 1 January 1972).</t> of seconds between 1 January 1900 and 1 January 1972).</t></dd>
</list></t> <dt>Leap seconds: </dt><dd><t>
This timestamp format is affected by leap seconds. The
<t>Leap seconds: <list hangIndent="10" style="empty">
<t>This timestamp format is affected by leap seconds. The
timestamp represents the number of seconds elapsed since the timestamp represents the number of seconds elapsed since the
epoch minus the number of leap seconds. Thus, during and epoch minus the number of leap seconds. Thus, during and
possibly after the occurrence of a leap second, the value of the possibly before and/or after the occurrence of a leap second, the value of the
timestamp may temporarily be ambiguous, as further discussed in timestamp may temporarily be ambiguous, as further discussed in
<xref target="SynchSec"/>.</t> <xref target="SynchSec" format="default"/>.</t></dd>
</list></t> <dt>Resolution: </dt><dd><t>
The resolution is 2<sup>-16</sup> seconds.</t></dd>
<t>Resolution: <list hangIndent="10" style="empty"> <dt>Wraparound:</dt><dd><t>
<t>The resolution is 2^(-16) seconds.</t> This time format wraps around every 2<sup>16</sup> seconds, which is
</list></t> roughly 18 hours.</t></dd>
</dl>
<t>Wraparound: <list hangIndent="10" style="empty">
<t>This time format wraps around every 2^16 seconds, which is
roughly 18 hours.</t>
</list></t>
</section> </section>
</section> </section>
<section anchor="ptp-trunc" numbered="true" toc="default">
<section title="The PTP Truncated Timestamp Format"> <name>The PTP Truncated Timestamp Format</name>
<t>The Precision Time Protocol (PTP) <xref target="IEEE1588"/> uses an <t>The Precision Time Protocol (PTP) <xref target="IEEE1588" format="def
ault"/> uses an
80-bit timestamp format. The truncated timestamp format is a 64-bit 80-bit timestamp format. The truncated timestamp format is a 64-bit
field, which is the 64 least significant bits of the 80-bit PTP field, which is the 64 least significant bits of the 80-bit PTP
timestamp. Since this timestamp format is similar to the one used in timestamp. Since this timestamp format is similar to the one used in
PTP, this timestamp format should be preferred in network protocols PTP, this timestamp format should be preferred in network protocols
that are typically deployed in PTP-capable devices.</t> that are typically deployed in PTP-capable devices.</t>
<t>The PTP truncated timestamp format was defined in <xref target="IEEE1
<t>The PTP truncated timestamp format was defined in <xref 588v1" format="default"/> and is used in several protocols, such as <xref target
target="IEEE1588v1"/> and is used in several protocols, such as <xref ="RFC6374" format="default"/>, <xref target="RFC7456" format="default"/>, <xref
target="RFC6374"/>, <xref target="RFC7456"/>, <xref target="RFC8186"/> target="RFC8186" format="default"/>,
and <xref target="ITU-T-Y.1731"/>.</t> and <xref target="ITU-T-Y.1731" format="default"/>.</t>
<figure anchor="PTPFormat">
<figure align="center" anchor="PTPFormat" <name>PTP Truncated Timestamp Format</name>
title="PTP [IEEE1588] Truncated Timestamp Format"> <artwork align="left" name="" type="" alt=""><![CDATA[
<artwork align="left"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds | | Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nanoseconds | | Nanoseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<dl newline="true" spacing="normal">
<t>Timestamp field format: <list hangIndent="10" style="empty"> <dt>Timestamp field format: </dt><dd>
<t>Seconds: specifies the integer portion of the number of seconds <dl newline="false" spacing="normal">
<dt>Seconds:</dt><dd><t> Specifies the integer portion of the number o
f seconds
since the epoch.</t> since the epoch.</t>
<dl newline="false" spacing="normal">
<t>- Size: 32 bits.</t> <dt>Size:</dt><dd>32 bits.</dd>
<dt>Units:</dt><dd>Seconds.</dd></dl></dd>
<t>- Units: seconds.</t> <dt>Nanoseconds:</dt><dd><t>Specifies the fractional portion of the nu
mber of
<t>Nanoseconds: specifies the fractional portion of the number of
seconds since the epoch.</t> seconds since the epoch.</t>
<dl newline="false" spacing="normal">
<dt>Size:</dt><dd>32 bits.</dd>
<dt>Units:</dt><dd>Nanoseconds. The value of this field is in the rang
e 0
to (10<sup>9</sup>)-1.</dd>
</dl></dd></dl></dd>
<t>- Size: 32 bits.</t> <dt>Epoch: </dt><dd>
<t>The PTP <xref target="IEEE1588" format="default"/> epoch is 1 Janua
<t>- Units: nanoseconds. The value of this field is in the range 0 ry 1970
to (10^9)-1.</t> 00:00:00 TAI.</t></dd>
</list></t>
<t>Epoch: <list hangIndent="10" style="empty">
<t>The PTP <xref target="IEEE1588"/> epoch is 1 January 1970
00:00:00 TAI.</t>
</list></t>
<t>Leap seconds: <list hangIndent="10" style="empty"> <dt>Leap seconds:</dt><dd><t>
<t>This timestamp format is not affected by leap seconds.</t> This timestamp format is not affected by leap seconds.</t></dd>
</list></t>
<t>Resolution: <list hangIndent="10" style="empty"> <dt>Resolution:</dt><dd><t>
<t>The resolution is 1 nanosecond.</t> The resolution is 1 nanosecond.</t></dd>
</list></t>
<t>Wraparound: <list hangIndent="10" style="empty"> <dt>Wraparound:</dt><dd><t>
<t>This time format wraps around every 2^32 seconds, which is This time format wraps around every 2<sup>32</sup> seconds, which is
roughly 136 years. The next wraparound will occur in the year roughly 136 years. The next wraparound will occur in the year
2106.</t> 2106.</t></dd>
</list></t> </dl>
</section> </section>
</section> </section>
<section anchor="SynchSec" numbered="true" toc="default">
<section anchor="SynchSec" title="Synchronization Aspects"> <name>Synchronization Aspects</name>
<t>A specification that defines a new timestamp format or uses one of <t>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 Synchronization
Synchronization Aspects. Note that the recommended timestamp formats Aspects section. Note that the recommended timestamp formats
defined in this document (<xref target="Recommended"/>) do not include defined in this document (<xref target="Recommended" format="default"/>) d
o not include
the synchronization aspects of these timestamp formats, but it is the synchronization aspects of these timestamp formats, but it is
expected that specifications of network protocols that make use of these expected that specifications of network protocols that make use of these
formats should include the synchronization aspects. Examples of a formats should include the synchronization aspects. Examples of a
Synchronization Aspects section can be found in <xref Synchronization Aspects section can be found in <xref target="UseCaseSec"
target="UseCaseSec"/>.</t> format="default"/>.</t>
<t>The Synchronization Aspects section should specify all the <t>The Synchronization Aspects section should specify all the
assumptions and requirements related to synchronization. For example, assumptions and requirements related to synchronization. For example,
the synchronization aspects may specify whether nodes populating the the synchronization aspects may specify whether nodes populating the
timestamps should be synchronized among themselves, and whether the timestamps should be synchronized among themselves and whether the
timestamp is measured with respect to a central reference clock such as 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 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 such as UTC or TAI, it should be specified in this section. Further
considerations may be discussed in this section, such as the required considerations may be discussed in this section, such as the required
timestamp accuracy and precision.</t> timestamp accuracy and precision.</t>
<t>Another aspect that should be discussed in this section is leap <t>Another aspect that should be discussed in this section is leap
second <xref target="RFC5905"/> considerations. The timestamp second <xref target="RFC5905" format="default"/> considerations. The times
specification template (<xref target="format"/>) specifies whether the tamp
specification template (<xref target="format" format="default"/>) specifie
s whether the
timestamp is affected by leap seconds. It is often the case that further timestamp is affected by leap seconds. It is often the case that further
details about leap seconds will need to be defined in the details about leap seconds will need to be defined in the
Synchronization Aspects section. Generally speaking, a leap second is a Synchronization Aspects section. Generally speaking, a leap second is a
one-second adjustment that is occasionally applied to UTC in order to one-second adjustment that is occasionally applied to UTC in order to
keep it aligned to the solar time. A leap second may be either positive keep it aligned with solar time. A leap second may be either positive
or negative, i.e., the clock may either be shifted one second forwards or negative, i.e., the clock may either be shifted one second forward
or backwards. All leap seconds that have occurred up to the publication or backward. All leap seconds that have occurred up to the publication
of this document have been in the backwards direction, and although of this document have been in the backward direction, and although
forward leap seconds are theoretically possible, the text throughout forward leap seconds are theoretically possible, the text throughout
this document focuses on the common case, which is the backward leap this document focuses on the common case, which is the backward leap
second. In a timekeeping system that considers leap seconds, the system second. In a timekeeping system that considers leap seconds, the system
clock may be affected by a leap second in one of three possible clock may be affected by a leap second in one of three possible
ways:</t> ways:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The clock is turned backwards one second at the end of the leap
<t>The clock is turned backwards one second at the end of the leap second.</li>
second.</t> <li>The clock is frozen during the duration of the leap second.</li>
<li>The clock is slowed down during the leap second and adjacent time
<t>The clock is frozen during the duration of the leap second.</t>
<t>The clock is slowed down during the leap second and adjacent time
intervals until the new time value catches up. The interval for this intervals until the new time value catches up. The interval for this
process, commonly referred to as leap smear, can range from several process, commonly referred to as "leap smear", can range from several
seconds to several hours before, during, and/or after the occurrence seconds to several hours before, during, and/or after the occurrence
of the leap second.</t> of the leap second.</li>
</list></t> </ul>
<t>The way leap seconds are handled depends on the synchronization <t>The way leap seconds are handled depends on the synchronization
protocol, and is thus not specified in this document. However, if a protocol and is thus not specified in this document. However, if a
timestamp format is defined with respect to a timescale that is affected timestamp format is defined with respect to a timescale that is affected
by leap seconds, the Synchronization Aspects section should specify how by leap seconds, the Synchronization Aspects section should specify how
the use of leap seconds affects the timestamp usage.</t> the use of leap seconds affects the timestamp usage.</t>
</section> </section>
<section anchor="UseCaseSec" numbered="true" toc="default">
<section anchor="UseCaseSec" title="Timestamp Use Cases"> <name>Timestamp Use Cases</name>
<t>Packet timestamps are used in various network protocols. Typical <t>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 synchronization, and others. The following table presents a
(non-exhaustive) list of protocols that use packet timestamps, and the (non-exhaustive) list of protocols that use packet timestamps and the
timestamp formats used in each of these protocols.</t> timestamp formats used in each of these protocols.</t>
<figure align="center" anchor="TimestampExamples" <table anchor="tab-1" align="left">
title="Protocols that use Packet Timestamps"> <name>Protocols That Use Packet Timestamps</name>
<artwork align="left"><![CDATA[ <thead>
<tr>
<th align="center" colspan="1"></th>
<th align="center" colspan="3">Recommended Formats</th>
<th align="center" colspan="1">Other</th>
</tr>
<tr>
<th align="center">Protocol</th>
<th align="center">NTP 64-Bit</th>
<th align="center">NTP 32-Bit</th>
<th align="center">PTP Trunc.</th>
<th align="center"></th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">NTP <xref target="RFC5905"/></td>
<td align="center">+</td>
<td align="center"></td>
<td align="center"></td>
<td align="center"></td>
</tr>
<tr>
<td align="center">OWAMP <xref target="RFC4656"/></td>
<td align="center">+</td>
<td align="center"></td>
<td align="center"></td>
<td align="center"></td>
</tr>
+----------------------+-----------------------------------+-----------+ <tr>
| | Recommended formats | Other | <td align="center">TWAMP <xref target="RFC5357"/><br/>TWAMP <xref ta
+----------------------+-----------+-----------+-----------+-----------+ rget="RFC8186"/></td>
| Protocol |NTP 64-bit |NTP 32-bit |PTP Trunc. | | <td align="center">+<br/>+</td>
+----------------------+-----------+-----------+-----------+-----------+ <td align="center"></td>
| NTP [RFC5905] | + | | | | <td align="center"><br/>+</td>
+----------------------+-----------+-----------+-----------+-----------+ <td align="center"></td>
| OWAMP [RFC4656] | + | | | | </tr>
+----------------------+-----------+-----------+-----------+-----------+ <tr>
| TWAMP [RFC5357] | + | | | | <td align="center">TRILL <xref target="RFC7456"/></td>
| TWAMP [RFC8186] | + | | + | | <td align="center"></td>
+----------------------+-----------+-----------+-----------+-----------+ <td align="center"></td>
| TRILL [RFC7456] | | | + | | <td align="center">+</td>
+----------------------+-----------+-----------+-----------+-----------+ <td align="center"></td>
| MPLS [RFC6374] | | | + | | </tr>
+----------------------+-----------+-----------+-----------+-----------+ <tr>
| TCP [RFC7323] | | | | + | <td align="center">MPLS <xref target="RFC6374"/></td>
+----------------------+-----------+-----------+-----------+-----------+ <td align="center"></td>
| RTP [RFC3550] | + | | | + | <td align="center"></td>
+----------------------+-----------+-----------+-----------+-----------+ <td align="center">+</td>
| IPFIX [RFC7011] | | | | + | <td align="center"></td>
+----------------------+-----------+-----------+-----------+-----------+ </tr>
| BinaryTime [RFC6019] | | | | + | <tr>
+----------------------+-----------+-----------+-----------+-----------+ <td align="center">TCP <xref target="RFC7323"/></td>
| [I-D.ietf-ippm- | + | + | | | <td align="center"></td>
| initial-registry] | | | | | <td align="center"></td>
+----------------------+-----------+-----------+-----------+-----------+ <td align="center"></td>
| [I-D.ietf-sfc-nsh | | + | + | | <td align="center">+</td>
| -dc-allocation] | | | | | </tr>
+----------------------+-----------+-----------+-----------+-----------+ <tr>
]]></artwork> <td align="center">RTP <xref target="RFC3550"/></td>
</figure> <td align="center">+</td>
<td align="center"></td>
<td align="center"></td>
<td align="center">+</td>
</tr>
<tr>
<td align="center">IPFIX <xref target="RFC7011"/></td>
<td align="center"></td>
<td align="center"></td>
<td align="center"></td>
<td align="center">+</td>
</tr>
<tr>
<td align="center">BinaryTime <xref target="RFC6019"/></td>
<td align="center"></td>
<td align="center"></td>
<td align="center"></td>
<td align="center">+</td>
</tr>
<tr>
<td align="center"><xref target="I-D.ietf-ippm-initial-registry"/></
td>
<td align="center">+</td>
<td align="center">+</td>
<td align="center"></td>
<td align="center"></td>
</tr>
<tr>
<td align="center"><xref target="I-D.ietf-sfc-nsh-dc-allocation"/></
td>
<td align="center"></td>
<td align="center">+</td>
<td align="center">+</td>
<td align="center"></td>
</tr>
</tbody>
</table>
<t>The rest of this section presents two hypothetic examples of network <t>The rest of this section presents two hypothetical 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 information formats. The examples include the text that specifies the information
related to the timestamp format.</t> related to the timestamp format.</t>
<section anchor="Ex1Sec" numbered="true" toc="default">
<name>Example 1</name>
<dl spacing="normal" newline="true">
<dt>Timestamp:</dt>
<dd>The timestamp format used in this specification is the NTP
<xref target="RFC5905" format="default"/> 64-bit format, as
described in <xref target="time-64bit"/> of RFC 8877.</dd>
<section anchor="Ex1Sec" title="Example 1"> <dt>Synchronization aspects:</dt>
<t>Timestamp: <list hangIndent="10" style="empty"> <dd>It is assumed that the nodes that run this protocol are
<t>The timestamp format used in this specification is the NTP
<xref target="RFC5905"/> 64-bit format, as specified in Section
4.2.1 of <xref target="I-D.ietf-ntp-packet-timestamps"/>.</t>
</list></t>
<t>Synchronization aspects: <list hangIndent="10" style="empty">
<t>It is assumed that nodes that run this protocol are
synchronized to UTC using a synchronization mechanism that is synchronized to UTC using a synchronization mechanism that is
outside the scope of this document. In typical deployments this outside the scope of this document. In typical deployments, this
protocol will run on a machine that uses NTP <xref protocol will run on a machine that uses NTP <xref target="RFC5905"
target="RFC5905"/> for synchronization. Thus, the timestamp may be format="default"/> for synchronization. Thus, the timestamp may be
derived from the NTP-synchronized clock, allowing the timestamp to derived from the NTP-synchronized clock, allowing the timestamp to
be measured with respect to the clock of an NTP server. Since the be measured with respect to the clock of an NTP server. Since the
NTP time format is affected by leap seconds, the current timestamp NTP time format is affected by leap seconds, the current timestamp
format is similarly affected. Thus, the value of a timestamp format is similarly affected. Thus, the value of a timestamp
during or slightly after a leap second may be temporarily during and possibly before and/or after a leap second may be tempora
inaccurate.</t> rily
</list></t> inaccurate.</dd>
</dl>
</section> </section>
<section anchor="Ex2Sec" numbered="true" toc="default">
<section anchor="Ex2Sec" title="Example 2"> <name>Example 2</name>
<t>Timestamp: <list hangIndent="10" style="empty"> <dl spacing="normal" newline="true">
<t>The timestamp format used in this specification is the PTP <dt>Timestamp: </dt>
<xref target="IEEE1588"/> Truncated format, as specified in <dd>The timestamp format used in this specification is the PTP
Section 4.3 of <xref <xref target="IEEE1588" format="default"/> truncated format, as desc
target="I-D.ietf-ntp-packet-timestamps"/>.</t> ribed in
</list></t> <xref target="ptp-trunc"/> of RFC 8877.</dd>
<dt>Synchronization aspects: </dt>
<t>Synchronization aspects: <list hangIndent="10" style="empty"> <dd>It is assumed that the nodes that run this protocol are
<t>It is assumed that nodes that run this protocol are
synchronized among themselves. Nodes may be synchronized to a synchronized among themselves. Nodes may be synchronized to a
global reference time. Note that if PTP <xref target="IEEE1588"/> global reference time. Note that if PTP <xref target="IEEE1588" form at="default"/>
is used for synchronization, the timestamp may be derived from the is used for synchronization, the timestamp may be derived from the
PTP-synchronized clock, allowing the timestamp to be measured with PTP-synchronized clock, allowing the timestamp to be measured with
respect to the clock of an PTP Grandmaster clock.</t> respect to a PTP grandmaster clock.</dd>
</list></t> </dl>
</section> </section>
</section> </section>
<section anchor="ControlSec" numbered="true" toc="default">
<section anchor="ControlSec" title="Packet Timestamp Control Field"> <name>Packet Timestamp Control Field</name>
<t>In some cases it is desirable to have a control field that describes <t>In some cases, it is desirable to have a control field that describes
structure, format, content, and properties of timestamps. Control the structure, format, content, and properties of timestamps. Control
information about the timestamp format can be conveyed in some protocols information about the timestamp format can be conveyed in some protocols
using a dedicated control plane protocol, or may be made available at using a dedicated control plane protocol or may be made available at
the management plane, for example using a YANG data model. An optional the management plane, for example, using a YANG data model. An optional
control field allows some of the control information to be attached to control field allows some of the control information to be attached to
the timestamp.</t> the timestamp.</t>
<t>An example of a packet timestamp control field is the Error Estimate <t>An example of a packet timestamp control field is the Error Estimate
field, defined by Section 4.1.2 in <xref target="RFC4656"/>, which is field, defined by <xref target="RFC4656"
used in OWAMP <xref target="RFC4656"/> and TWAMP <xref sectionFormat="of" section="4.1.2"/>, which is
target="RFC5357"/>. The Root Dispersion and Root Delay fields in the NTP used in the One-Way Active Measurement Protocol (OWAMP) <xref
header <xref target="RFC5905"/> are two examples of fields that provide target="RFC4656" format="default"/> and Two-Way Active Measurement
Protocol (TWAMP) <xref target="RFC5357" format="default"/>. The Root Dispe
rsion and Root Delay fields in the NTP
header <xref target="RFC5905" format="default"/> are two examples of field
s that provide
information about the timestamp precision. Another example of an information about the timestamp precision. Another example of an
auxiliary field is the Correction Field in the PTP header <xref auxiliary field is the Correction Field in the PTP header <xref target="IE
target="IEEE1588"/>; its value is used as a correction to the timestamp, EE1588" format="default"/>; its value is used as a correction to the timestamp a
and may be assigned by the sender of the PTP message and updated by nd may be assigned by the sender of the PTP message and updated by
transit nodes (Transparent Clocks) in order to account for the delay transit nodes (Transparent Clocks) in order to account for the delay
along the path.</t> along the path.</t>
<t>This section defines high-level guidelines for defining packet <t>This section defines high-level guidelines for defining packet
timestamp control fields in network protocols that can benefit from such timestamp control fields in network protocols that can benefit from such
timestamp-related control information. The word 'requirements' is used timestamp-related control information. The word "requirements" is used
in its informal context in this section.</t> in its informal context in this section.</t>
<section numbered="true" toc="default">
<section title="High-level Control Field Requirements"> <name>High-Level Control Field Requirements</name>
<t>A control field for packet timestamps must offer an adequate <t>A control field for packet timestamps must offer an adequate
feature set and fulfill a series of requirements to be usable and feature set and fulfill a series of requirements to be usable and
accepted. The following list captures the main high-level requirements accepted. The following list captures the main high-level requirements
for timestamp fields.</t> for timestamp fields.</t>
<ol spacing="normal" type="1">
<t><list style="numbers"> <li>Extensible Feature Set: Protocols and applications depend on
<t>Extensible Feature Set: protocols and applications depend on
various timestamp characteristics. A timestamp control field must various timestamp characteristics. A timestamp control field must
support a variable number of elements (components) that either support a variable number of elements (components) that either
describe or quantify timestamp-specific characteristics or describe or quantify timestamp-specific characteristics or
parameters. Examples of potential elements include timestamp size, parameters. Examples of potential elements include timestamp size,
encoding, accuracy, leap seconds, reference clock identifiers, encoding, accuracy, leap seconds, reference clock identifiers,
etc.</t> etc.</li>
<li>Size: Essential for an efficient use of timestamp control
<t>Size: Essential for an efficient use of timestamp control
fields is the trade-off between supported features and control fields is the trade-off between supported features and control
field size. Protocols and applications may select the specific field size. Protocols and applications may select the specific
control field elements that are needed for their operation from control field elements that are needed for their operation from
the set of available elements.</t> the set of available elements.</li>
<li>Composition: Applications may depend on specific control field
<t>Composition: Applications may depend on specific control field
elements being present in messages. The status of these elements elements being present in messages. The status of these elements
may be either mandatory, conditional mandatory, or optional, may be either mandatory, conditional mandatory, or optional,
depending on the specific application and context. A control field depending on the specific application and context. A control field
specification must support applications in conveying or specification must support applications in conveying or
negotiating (a) the set of control field elements along with (b) negotiating (a) the set of control field elements along with (b)
the status of any element (i.e., mandatory, conditional mandatory, the status of any element (i.e., mandatory, conditional mandatory,
or optional) by defining appropriate data structures and identity or optional) by defining appropriate data structures and identity
codes.</t> codes.</li>
<li>Category: Control field elements can characterize either static
<t>Category: Control field elements can characterize either static timestamp information (e.g., timestamp size in bytes and
timestamp information (like, e.g., timestamp size in bytes and timestamp semantics: NTP 64-bit format) or runtime timestamp
timestamp semantics: NTP 64 bit format) or runtime timestamp information (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 reasons, it may
of sampling: 20 microseconds to UTC). For efficiency reason it may
be meaningful to support separation of these two concepts: while be meaningful to support separation of these two concepts: while
the former (static) information is typically valid throughout a the former (static) information is typically valid throughout a
protocol session and may be conveyed only once, at session protocol session and may be conveyed only once, at session
establishment time, the latter (runtime) information augments any establishment time, the latter (runtime) information augments any
timestamp instance and may cause substantial overhead for timestamp instance and may cause substantial overhead for
high-traffic protocols.</t> high-traffic protocols.</li>
</list>Proposals for timestamp control fields will be defined in </ol>
<t>Proposals for timestamp control fields will be defined in
separate documents and are out of scope of this document.</t> separate documents and are out of scope of this document.</t>
</section> </section>
</section> </section>
<!-- Possibly a 'Contributors' section ... --> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="IANA" title="IANA Considerations"> <t>This document has no IANA actions.</t>
<t>This document includes no request to IANA.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>A network protocol that uses a packet timestamp MUST specify the <t>A network protocol that uses a packet timestamp <bcp14>MUST</bcp14> spe
cify 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.</t> considerations of using timestamps.</t>
<t>Any metadata that is attached to control or data packets, and <t>Any metadata that is attached to control or data packets, and
specifically packet timestamps, can facilitate network reconnaissance; specifically packet timestamps, can facilitate network reconnaissance;
by passively eavesdropping to timestamped packets an attacker can gather by passively eavesdropping on timestamped packets, an attacker can gather
information about the network performance, and about the level of information about the network performance and the level of
synchronization between nodes.</t> synchronization between nodes.</t>
<t>In some cases, timestamps could be spoofed or modified by on-path
<t>In some cases timestamps could be spoofed or modified by on-path
attackers, thus attacking the application that uses the timestamps. For attackers, thus attacking the application that uses the timestamps. For
example, if timestamps are used in a delay measurement protocol, an example, if timestamps are used in a delay measurement protocol, an
attacker can modify en route timestamps in a way that manipulates the attacker can modify en route timestamps in a way that manipulates the
measurement results. Integrity protection mechanisms, such as Message measurement results. Integrity protection mechanisms, such as Message
Authentication Codes (MAC), can mitigate such attacks. The specification Authentication Codes (MACs), can mitigate such attacks. The specification
of an integrity protection mechanism is outside the scope of this of an integrity protection mechanism is outside the scope of this
document, as typically integrity protection will be defined on a document as, typically, integrity protection will be defined on a
per-network-protocol basis, and not specifically for the timestamp per-network-protocol basis and not specifically for the timestamp
field.</t> field.</t>
<t>Another potential threat that can have a similar impact is delay <t>Another potential threat that can have a similar impact is delay
attacks. An attacker can maliciously delay some or all of the en route attacks. An attacker can maliciously delay some or all of the en route
messages, with the same harmful implications as described in the messages, with the same harmful implications as described in the
previous paragraph. Mitigating delay attacks is a significant challenge; previous paragraph. Mitigating delay attacks is a significant challenge;
in contrast to spoofing and modification attacks, the delay attack in contrast to spoofing and modification attacks, the delay attack
cannot be prevented by cryptographic integrity protection mechanisms. In cannot be prevented by cryptographic integrity protection mechanisms. In
some cases delay attacks can be mitigated by sending the timestamped some cases, delay attacks can be mitigated by sending the timestamped
information through multiple paths, allowing to detect and to be information through multiple paths, allowing detection of and resistance t
resilient to an attacker that has access to one of the paths.</t> o an attacker that has access to one of the paths.</t>
<t>In many cases, timestamping relies on an underlying synchronization
<t>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. Attacks mechanism can also compromise protocols that use timestamping. Attacks
on time protocols are discussed in detail in <xref on time protocols are discussed in detail in <xref target="RFC7384" format
target="RFC7384"/>.</t> ="default"/>.</t>
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>The authors thank Russ Housley, Yaakov Stein, Greg Mirsky, Warner
Losh, Rodney Cummings, Miroslav Lichvar, Denis Reilly, Daniel Franke,
Eric Vyncke, Ben Kaduk, Ian Swett, Francesca Palombini, Watson Ladd, and
other members of the NTP working group for many helpful comments. The
authors gratefully acknowledge Harlan Stenn and the people from the
Network Time Foundation for sharing their thoughts and ideas.</t>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-ippm-initial-registry" to="METRICS"/>
<?rfc include='reference.RFC.2119'?> <displayreference target="I-D.ietf-sfc-nsh-dc-allocation" to="NSHMD"/>
<references>
<?rfc include='reference.RFC.8174'?> <name>References</name>
<references>
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC. <name>Normative References</name>
2119.xml"?--> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<!--&RFC2119;--> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
</references> </references>
<references>
<references title="Informative References"> <name>Informative References</name>
<!-- Here we use entities that we defined at the beginning. -->
<reference anchor="IEEE1588"> <reference anchor="IEEE1588">
<front> <front>
<title>IEEE 1588 Standard for a Precision Clock Synchronization <title>IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems Version
2</title>
<author>
<organization>IEEE</organization>
</author>
<date year="2008"/>
</front>
</reference>
<reference anchor="IEEE1588v1">
<front>
<title>IEEE 1588 Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems</title> Protocol for Networked Measurement and Control Systems</title>
<seriesInfo name="IEEE Std." value="1588-2008"/>
<author> <seriesInfo name="DOI" value="10.1109/IEEESTD.2008.4579760"/>
<organization>IEEE</organization> <author>
</author> <organization>IEEE</organization>
</author>
<date year="2002"/> <date year="2008" month="July"/>
</front> </front>
</reference> </reference>
<reference anchor="IEEE1588v1">
<reference anchor="ITU-T-Y.1731"> <front>
<front> <title>IEEE Standard for a Precision Clock Synchronization
<title>OAM functions and mechanisms for Ethernet based Protocol for Networked Measurement and Control Systems</title>
Networks</title> <seriesInfo name="IEEE Std." value="1588-2002"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2002.94144"/>
<author> <author>
<organization>ITU-T</organization> <organization>IEEE</organization>
</author> </author>
<date month="October" year="2002"/>
<date year="2013"/> </front>
</front> </reference>
</reference> <reference anchor="ITU-T-Y.1731">
<front>
<?rfc include='reference.RFC.3339'?> <title>Operations, administration and maintenance (OAM) functions
and mechanisms for Ethernet-based networks</title>
<!-- ?rfc include='reference.RFC.5277'? --> <seriesInfo name="ITU-T Recommendation" value="G.8013/Y.1731"/>
<author>
<?rfc include='reference.RFC.7493'?> <organization>ITU-T</organization>
</author>
<?rfc include='reference.RFC.6991'?> <date year="2015" month="August"/>
</front>
<?rfc include='reference.RFC.5646'?> </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<!-- ?rfc include='reference.RFC.7940'? --> FC.3339.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
<?rfc include='reference.RFC.5905'?> .7493.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.7323'?> FC.6991.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.3550'?> FC.5646.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
<?rfc include='reference.RFC.6374'?> .5905.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.5357'?> FC.7323.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.4656'?> FC.3550.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.7011'?> FC.6374.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.6019'?> FC.5357.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.7456'?> FC.4656.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.7384'?> FC.7011.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.8186'?> FC.6019.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.I-D.ietf-ippm-initial-registry'?> FC.7456.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.I-D.ietf-sfc-nsh-dc-allocation'?> FC.7384.xml"/>
<xi:include
<?rfc include='reference.I-D.ietf-ntp-packet-timestamps'?> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8186.x
ml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
I-D.ietf-ippm-initial-registry.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-
sfc-nsh-dc-allocation.xml"/>
</references>
</references> </references>
<section anchor="Acknowledgments" numbered="false" toc="default">
<!-- Change Log <name>Acknowledgments</name>
<t>The authors thank <contact fullname="Russ Housley"/>, <contact
v00 2016-08-02 TM Initial version fullname="Yaakov Stein"/>, <contact fullname="Greg Mirsky"/>, <contact
fullname="Warner Losh"/>, <contact fullname="Rodney Cummings"/>,
v01 2016-08-10 TM Minor updates including: timestamp format change, added Flo <contact fullname="Miroslav Lichvar"/>, <contact fullname="Denis
w ID. Reilly"/>, <contact fullname="Daniel Franke"/>, <contact fullname="Éric
Vyncke"/>, <contact fullname="Ben Kaduk"/>, <contact fullname="Ian
--> Swett"/>, <contact fullname="Francesca Palombini"/>, <contact
fullname="Watson Ladd"/>, and other members of the NTP Working Group for
their many helpful comments. The authors gratefully acknowledge <contact
fullname="Harlan Stenn"/> and the people from the Network Time
Foundation for sharing their thoughts and ideas.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 150 change blocks. 
603 lines changed or deleted 618 lines changed or added

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