<?xmlversion="1.0" encoding="US-ASCII"?>version='1.0' encoding='utf-8'?> <!DOCTYPE rfc SYSTEM"rfc2629.dtd"> <!-- [ <!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" ?>"rfc2629-xhtml.ent"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-ietf-ntp-packet-timestamps-09"ipr="trust200902">ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3" consensus="true" number="8877"> <front> <title abbrev="Packet Timestamps">Guidelines for Defining Packet Timestamps</title> <seriesInfo name="RFC" value="8877"/> <author fullname="Tal Mizrahi" initials="T." surname="Mizrahi"> <organizationabbrev="">Huawei Smart Platforms iLab</organization>abbrev="">Huawei</organization> <address> <postal> <street>8-2 Matam</street> <city>Haifa</city> <code>3190501</code> <country>Israel</country> </postal> <email>tal.mizrahi.phd@gmail.com</email> </address> </author> <author fullname="Joachim Fabini" initials="J." surname="Fabini"> <organization>TU Wien</organization> <address> <postal> <street>Gusshausstrasse 25/E389</street><city>Vienna 1040</city><city>Vienna</city><code>1040</code> <country>Austria</country> </postal> <phone>+43 1 58801 38813</phone><facsimile>+43 1 58801 38898</facsimile><email>Joachim.Fabini@tuwien.ac.at</email> <uri>http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/</uri> </address> </author> <author fullname="Al Morton" initials="A." surname="Morton"> <organization>AT&T Labs</organization> <address> <postal> <street>200 Laurel Avenue South</street><city>Middletown,</city><city>Middletown</city> <region>NJ</region> <code>07748</code><country>USA</country><country>United States of America</country> </postal> <phone>+1 732 420 1571</phone><facsimile>+1 732 368 1192</facsimile><email>acmorton@att.com</email> </address> </author> <date month="September" year="2020"/> <area>General</area> <workgroup>NTP Working Group</workgroup> <keyword>Timestamps</keyword> <abstract> <t>Various network protocols make use of binary-encoded timestamps that are incorporated in the protocol packet format, referred to aspacket timestamps"packet timestamps" for short. This document specifies guidelines for defining packet timestamp formats in networking protocols at various layers. It also presents three recommended timestamp formats. The target audience of this document includes network protocol designers. It is expected that a new network protocol that requires a packet timestamp will, in most cases, use one of the recommended timestamp formats. If none of the recommended formats fits the protocol requirements, the new protocol specification should specify the format of the packet timestamp according to the guidelines in this document.</t> </abstract> </front> <middle> <sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <sectiontitle="Background">numbered="true" toc="default"> <name>Background</name> <t>Timestamps are widely used in network protocols for various purposes:timestamps are usedfor logging or reporting the time of an event, for messages in delay measurement and clock synchronizationprotocols both make use of timestamped messages,protocols, andin security protocols a timestamp is often usedas part of a value that is unlikely to repeat(nonce).</t>(nonce) in security protocols.</t> <t>Timestamps are represented in the RFC series in one of two forms: text-basedtimestamps,timestamps and packet timestamps. Text-based timestamps <xreftarget="RFC3339"/>target="RFC3339" format="default"/> are represented as user-friendlystrings,strings and are widely used in the RFCseries,series -- forexampleexample, in information objects and data models, e.g., <xreftarget="RFC5646"/>,target="RFC5646" format="default"/>, <xreftarget="RFC6991"/>,target="RFC6991" format="default"/>, and <xreftarget="RFC7493"/>.target="RFC7493" format="default"/>. Packet timestamps, on the other hand, are represented by a compact binary field that has a fixedsize,size and are not intended to have a human-friendly format. Packet timestamps are also very common in the RFCseries,series and areusedused, forexampleexample, for measuring delay and for synchronizing clocks, e.g., <xreftarget="RFC5905"/>,target="RFC5905" format="default"/>, <xreftarget="RFC4656"/>,target="RFC4656" format="default"/>, and <xreftarget="RFC7323"/>.</t>target="RFC7323" format="default"/>.</t> </section> <sectiontitle="Scopenumbered="true" toc="default"> <name>Scope of thisDocument">Document</name> <t>This document presents guidelines for defining a packet timestamp format in network protocols. Three recommended timestamp formats are presented. It is expected that a new network protocol that requires a packet timestamp will, in most cases, use one of these recommended timestamp formats. In somecasescases, a network protocol may use more than one of the recommended timestamp formats. However, if none of the recommended formats fits the protocol requirements, the new protocol specification should specify the format of the packet timestamp according to the guidelines in this document.</t> <t>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) <xref target="RFC5905"/> or the Precision Time Protocol(PTP),(PTP) <xref target="IEEE1588"/>, allowing a straightforward integration with anNTPNTP- oraPTP-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.</t> </section> <sectiontitle="Hownumbered="true" toc="default"> <name>How to Use ThisDocument">Document</name> <t>This document is intended as a reference for network protocol designers. When defining a network protocol that uses a packet timestamp, the recommended timestamp formats should be considered first (<xreftarget="Recommended"/>).target="Recommended" format="default"/>). If one of these formats is used, it should be referenced along the lines of the examples in Sections <xreftarget="Ex1Sec"/>target="Ex1Sec" format="counter"/> and <xreftarget="Ex2Sec"/>.target="Ex2Sec" format="counter"/>. If none of the recommended formats fits the required functionality, then a new timestamp format should be defined using the templateofin <xreftarget="format"/>.</t>target="format" format="default"/>.</t> </section> </section> <sectiontitle="Terminology">numbered="true" toc="default"> <name>Terminology</name> <sectiontitle="Requirements Language"> <t>Thenumbered="true" toc="default"> <name>Requirements Language</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <sectiontitle="Abbreviations"> <t>NTP Networknumbered="true" toc="default"> <name>Abbreviations</name> <dl newline="false" spacing="normal" indent="8"> <dt>NTP</dt> <dd>Network Time Protocol <xreftarget="RFC5905"/></t> <t>PTP Precisiontarget="RFC5905" format="default"/></dd> <dt>PTP</dt> <dd>Precision Time Protocol <xreftarget="IEEE1588"/></t> <t>TAI Internationaltarget="IEEE1588" format="default"/></dd> <dt>TAI</dt> <dd>International AtomicTime</t> <t>UTC CoordinatedTime</dd> <dt>UTC</dt> <dd>Coordinated UniversalTime</t>Time</dd> </dl> </section> <sectiontitle="Terms usednumbered="true" toc="default"> <name>Terms Used inthis Document"> <t><list hangIndent="23" style="hanging"> <t hangText="Timestamp:">AThis Document</name> <dl newline="false" spacing="normal" indent="23"> <dt>Timestamp:</dt> <dd>A value that represents a point in time, corresponding to an event that occurred or is scheduled tooccur.</t> <t hangText="Timestamp error:">Theoccur.</dd> <dt>Timestamp error:</dt> <dd>The difference between the timestamp value and the value of a reference clock at the time of the event that the timestamp was intended toindicate.</t> <t hangText="Timestamp format:">Theindicate.</dd> <dt>Timestamp format:</dt> <dd>The specification of a timestamp, which is represented by a set of attributes that unambiguouslydefinedefines the syntax and semantics of atimestamp.</t> <t hangText="Timestamp accuracy:">Thetimestamp.</dd> <dt>Timestamp accuracy:</dt> <dd>The mean over an ensemble of measurements of the timestamperror.</t> <t hangText="Timestamp precision:">Theerror.</dd> <dt>Timestamp precision:</dt> <dd>The variation over an ensemble of measurements of the timestamperror.</t> <t hangText="Timestamp resolution:">Theerror.</dd> <dt>Timestamp resolution:</dt> <dd>The minimal time unit used for representing thetimestamp.</t> </list></t>timestamp.</dd> </dl> </section> </section> <section anchor="format"title="Packetnumbered="true" toc="default"> <name>Packet Timestamp SpecificationTemplate">Template</name> <t>This document recommendsto useusing the timestamp formats defined in <xreftarget="Recommended"/>.target="Recommended" format="default"/>. In cases where these timestamp formats do not satisfy the protocol requirements, the timestamp specification should clearly state the reasons for defining a new format. Moreover, it is recommended to derive the new timestamp format from an existing timestamp format, either a timestamp format from thisdocument,document or any other previously defined timestamp format.</t> <t>The timestamp specification must unambiguously define the syntax andthesemantics of the timestamp. The current section defines the minimum set of attributes, but it should be noted that in somecasescases, additional attributes or aspects will need to be defined in the timestamp specification.</t> <t>This section defines a template for specifying packet timestamps. A timestamp format specificationMUST<bcp14>MUST</bcp14> include at least the following aspects:</t><t>Timestamp syntax: <list hangIndent="10" style="empty"> <t>- Size:<dl newline="true" spacing="normal"> <dt>Timestamp syntax:</dt> <dd> <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 endian) is assumed by default; if this is not thecasecase, then this section explicitly specifies theendianity.</t> </list></t> <t>Timestamp semantics: <list hangIndent="10" style="empty"> <t>- Units: Theendianity.</t></dd></dl></dd></dl> <dl newline="true" spacing="normal"> <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 field are specified. If a field is limited to a specific range of values, this section specifies the permitted range ofvalues.</t> <t>- Resolution: Thevalues.</t></dd> <dt>Resolution:</dt><dd><t>The timestamp resolution; the resolution is equal to the timestamp field unit. If the timestamp consists of two or more fields using different time units, then the resolution is the smallest timeunit.</t> <t>- Wraparound: Theunit.</t></dd> <dt>Wraparound:</dt><dd><t>The wraparound period of the timestamp; any further wraparound-related considerations should be describedhere.</t> <t>- Epoch: Thehere.</t></dd> <dt>Epoch:</dt><dd><t>The origin of the timescale used for the timestamp; the moment in time used as a reference for the timestamp value. For example, the epoch may be based on a standard time scale, such as UTC. Another example is a relative timestamp, in which the epoch could be the time at which the device using the timestamp was poweredup,up and is not affected by leap seconds (see the nextattribute).</t> <t>- Leap seconds: Thisattribute).</t></dd> <dt>Leap seconds:</dt><dd><t>This subsection specifies whether the timestamp is affected by leap seconds. If the timestamp is affected by leap seconds, then it represents the time elapsed since the epoch minus the number of leap seconds that have occurred since theepoch.</t> </list></t> <t>Synchronization aspects: <list hangIndent="10" style="empty"> <t>Theepoch.</t></dd> </dl></dd></dl> <dl newline="true" spacing="normal"> <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 of using the timestamp. While the synchronization aspects are not strictly part of the timestamp format specification, these aspects provide the necessary context for using the timestamp within the scope of the protocol. In somecasescases, timestamps are used without synchronization, e.g., a timestamp that indicates the number of seconds sincepower up.power-up. In suchcasescases, the Synchronization Aspects section will specify that the timestamp does not correspond to a synchronized timereference,reference and may discuss how this affects the usage of the timestamp. Further details about synchronization aspects are discussed in <xreftarget="SynchSec"/>.</t> </list></t>target="SynchSec" format="default"/>.</dd> </dl> </section> <section anchor="Recommended"title="Recommendednumbered="true" toc="default"> <name>Recommended TimestampFormats">Formats</name> <t>This document defines a set of recommended timestamp formats. Clearly, different network protocols may have different requirements andconstraints, and consequentlyconstraints; consequently, they may use different timestamp formats. The choice ofthea specific timestamp format for a given protocol may depend onavarious factors. A few examples of factors that may affect the choice of the timestampformat:</t> <t><list style="symbols"> <t>Timestampformat include the following:</t> <ul spacing="normal"> <li>Timestamp size:whileWhile some network protocols use a large timestamp field, in somecasescases, there may be constraints with respect to the timestamp size, affecting the choice of the timestampformat.</t> <t>Resolution: theformat.</li> <li>Resolution: The time resolution is another factor that may directly affect the selected timestamp format. A potentially important factor in this context is extensibility; it may be desirable to allow a timestamp format to be extensible to a higher resolution by extending the field. For example, the resolution of the NTP 32-bit timestamp format can be improved by extending it to the NTP 64-bit timestamp format in a straightforwardway.</t> <t>Wraparoundway.</li> <li>Wraparound period:theThe length of the time interval in which the timestamp is unique may also be an important factor in choosing the timestamp format. Along with the timestamp resolution, these two factors determine the required number of bits in thetimestamp.</t> <t>Commontimestamp.</li> <li>Common format for multiple protocols:ifIf there are two or more network protocols that use timestamps and are often used together in typical systems, using a common timestamp format should be preferred if possible. For example, if the network protocol that is being defined typically runs on a PC, then an NTP-based timestamp format may allow easier integration with an NTP-synchronized timer. In contrast, a protocol that is typically deployed on a hardware-basedplatform,platform may make better use of a PTP-based timestamp, allowing more efficient integration with a PTP-synchronizedtimer.</t> </list></t>timer.</li> </ul> <sectiontitle="Usingnumbered="true" toc="default"> <name>Using a Recommended TimestampFormat">Format</name> <t>A specification that uses one of the recommended timestamp formats should specify explicitly that this is a recommended timestampformat,format and point to the relevant section in the current document.</t> </section> <sectiontitle="NTPnumbered="true" toc="default"> <name>NTP TimestampFormats">Formats</name> <sectiontitle="NTP 64-bitanchor="time-64bit" numbered="true" toc="default"> <name>NTP 64-Bit TimestampFormat">Format</name> <t>The Network Time Protocol (NTP) 64-bit timestamp format is defined in <xreftarget="RFC5905"/>.target="RFC5905" format="default"/>. This timestamp format is used in several network protocols, including <xreftarget="RFC6374"/>,target="RFC6374" format="default"/>, <xreftarget="RFC4656"/>,target="RFC4656" format="default"/>, and <xreftarget="RFC5357"/>.target="RFC5357" format="default"/>. Since this timestamp format is used in NTP,this timestamp formatit should be preferred in network protocols that are typically deployed in concert with NTP.</t> <t>The format is presented in this section according to the template defined in <xreftarget="format"/>.</t>target="format" format="default"/>.</t> <figurealign="center" anchor="NTPFormat" title="NTP [RFC5905] 64-bitanchor="NTPFormat"> <name>NTP 64-Bit TimestampFormat">Format</name> <artworkalign="left"><![CDATA[align="left" name="" type="" alt=""><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fraction | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure><t>Timestamp<dl newline="true" spacing="normal"> <dt>Timestamp fieldformat: <list hangIndent="10" style="empty"> <t>Seconds: specifiesformat:</dt> <dd> <dl newline="false" spacing="normal"> <dt>Seconds:</dt><dd><t>Specifies the integer portion of the number of seconds since the epoch.</t><t>- Size: 32 bits.</t> <t>- Units: seconds.</t> <t>Fraction: specifies<dl newline="false" spacing="normal"> <dt>Size:</dt><dd>32 bits.</dd> <dt>Units:</dt> <dd>Seconds.</dd> </dl> </dd> <dt>Fraction:</dt><dd><t>Specifies the fractional portion of the number of seconds since the epoch.</t><t>- Size: 32 bits.</t> <t>- Units: the<dl newline="false" spacing="normal"> <dt>Size:</dt><dd>32 bits.</dd> <dt>Units:</dt><dd>The unit is2^(-32)2<sup>-32</sup> seconds, which is roughly equal to 233picoseconds.</t> </list></t> <t>Epoch: <list hangIndent="10" style="empty">picoseconds.</dd> </dl> </dd> </dl> </dd> <dt>Epoch:</dt><dd> <t>The epoch is 1 January 1900 at 00:00 UTC.</t> <t>Note: As pointed out in[RFC5905],<xref target="RFC5905"/>, strictly speaking, UTC did not exist prior to 1 January 1972, but it is convenient to assume it has existed for all eternity. The current epoch implies that the timestamp specifies the number of seconds since 1 January 1972 at 00:00 UTC plus 2272060800 (which is the number of seconds between 1 January 1900 and 1 January 1972).</t></list></t> <t>Leap seconds: <list hangIndent="10" style="empty"></dd> <dt>Leap seconds:</dt><dd> <t>This timestamp format is affected by leap seconds. The timestamp represents the number of seconds elapsed since the epoch minus the number of leap seconds. Thus, during and possibly before and/or after the occurrence of a leap second, the value of the timestamp may temporarily be ambiguous, as further discussed in <xreftarget="SynchSec"/>.</t> </list></t> <t>Resolution: <list hangIndent="10" style="empty">target="SynchSec" format="default"/>.</t> </dd> <dt>Resolution: </dt><dd> <t>The resolution is2^(-32)2<sup>-32</sup> seconds.</t></list></t> <t>Wraparound: <list hangIndent="10" style="empty"></dd> <dt>Wraparound:</dt><dd> <t>This time format wraps around every2^322<sup>32</sup> seconds, which is roughly 136 years. The next wraparound will occur in the year 2036.</t></list></t></dd> </dl> </section> <sectiontitle="NTP 32-bitnumbered="true" toc="default"> <name>NTP 32-Bit TimestampFormat">Format</name> <t>The Network Time Protocol (NTP) 32-bit timestamp format is defined in <xreftarget="RFC5905"/>.target="RFC5905" format="default"/>. This timestamp format is used in <xreftarget="I-D.ietf-ippm-initial-registry"/>target="I-D.ietf-ippm-initial-registry" format="default"/> and <xreftarget="I-D.ietf-sfc-nsh-dc-allocation"/>.target="I-D.ietf-sfc-nsh-dc-allocation" format="default"/>. This timestamp format should be preferred in network protocols that are typically deployed in concert with NTP. The 32-bit format can be used either when space constraints do not allow the use of the 64-bitformat,format or when the 32-bit format satisfies the resolution and wraparound requirements.</t> <t>The format is presented in this section according to the template defined in <xreftarget="format"/>.</t>target="format" format="default"/>.</t> <figurealign="center" anchor="NTPShortFormat" title="NTP [RFC5905] 32-bitanchor="NTPShortFormat"> <name>NTP 32-Bit TimestampFormat">Format</name> <artworkalign="left"><![CDATA[align="left" name="" type="" alt=""><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seconds | Fraction | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure><t>Timestamp<dl newline="true" spacing="normal"> <dt>Timestamp fieldformat: <list hangIndent="10" style="empty"> <t>Seconds: specifiesformat:</dt> <dd> <dl newline="false" spacing="normal"> <dt>Seconds:</dt><dd><t>Specifies the integer portion of the number of seconds since the epoch.</t><t>- Size: 16 bits.</t> <t>- Units: seconds.</t> <t>Fraction: specifies<dl newline="false" spacing="normal"> <dt>Size:</dt><dd>16 bits.</dd> <dt>Units:</dt><dd>Seconds.</dd> </dl> </dd> <dt>Fraction:</dt><dd><t>Specifies the fractional portion of the number of seconds since the epoch.</t><t>- Size: 16 bits.</t> <t>- Units: the<dl newline="false" spacing="normal"> <dt>Size:</dt><dd>16 bits.</dd> <dt>Units:</dt><dd>The unit is2^(-16)2<sup>-16</sup> seconds, which is roughly equal to 15.3microseconds.</t> </list></t> <t>Epoch: <list hangIndent="10" style="empty">microseconds.</dd> </dl> </dd> </dl> </dd> <dt>Epoch:</dt><dd> <t>The epoch is 1 January 1900 at 00:00 UTC.</t> <t>Note: As pointed out in[RFC5905],<xref target="RFC5905"/>, strictly speaking, UTC did not exist prior to 1 January 1972, but it is convenient to assume it has existed for all eternity. The current epoch implies that the timestamp specifies the number of seconds since 1 January 1972 at 00:00 UTC plus 2272060800 (which is the number of seconds between 1 January 1900 and 1 January1972).</t> </list></t> <t>Leap1972).</t></dd> <dt>Leap seconds:<list hangIndent="10" style="empty"> <t>This</dt><dd><t> This timestamp format is affected by leap seconds. The timestamp represents the number of seconds elapsed since the epoch minus the number of leap seconds. Thus, during and possibly before and/or after the occurrence of a leap second, the value of the timestamp may temporarily be ambiguous, as further discussed in <xreftarget="SynchSec"/>.</t> </list></t> <t>Resolution: <list hangIndent="10" style="empty"> <t>Thetarget="SynchSec" format="default"/>.</t></dd> <dt>Resolution: </dt><dd><t> The resolution is2^(-16) seconds.</t> </list></t> <t>Wraparound: <list hangIndent="10" style="empty"> <t>This2<sup>-16</sup> seconds.</t></dd> <dt>Wraparound:</dt><dd><t> This time format wraps around every2^162<sup>16</sup> seconds, which is roughly 18hours.</t> </list></t>hours.</t></dd> </dl> </section> </section> <sectiontitle="Theanchor="ptp-trunc" numbered="true" toc="default"> <name>The PTP Truncated TimestampFormat">Format</name> <t>The Precision Time Protocol (PTP) <xreftarget="IEEE1588"/>target="IEEE1588" format="default"/> uses an 80-bit timestamp format. The truncated timestamp format is a 64-bit field, which is the 64 least significant bits of the 80-bit PTP timestamp. Since this timestamp format is similar to the one used in PTP, this timestamp format should be preferred in network protocols that are typically deployed in PTP-capable devices.</t> <t>The PTP truncated timestamp format was defined in <xreftarget="IEEE1588v1"/>target="IEEE1588v1" format="default"/> and is used in several protocols, such as <xreftarget="RFC6374"/>,target="RFC6374" format="default"/>, <xreftarget="RFC7456"/>,target="RFC7456" format="default"/>, <xreftarget="RFC8186"/>target="RFC8186" format="default"/>, and <xreftarget="ITU-T-Y.1731"/>.</t>target="ITU-T-Y.1731" format="default"/>.</t> <figurealign="center" anchor="PTPFormat" title="PTP [IEEE1588]anchor="PTPFormat"> <name>PTP Truncated TimestampFormat">Format</name> <artworkalign="left"><![CDATA[align="left" name="" type="" alt=""><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nanoseconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure><t>Timestamp<dl newline="true" spacing="normal"> <dt>Timestamp field format:<list hangIndent="10" style="empty"> <t>Seconds: specifies</dt><dd> <dl newline="false" spacing="normal"> <dt>Seconds:</dt><dd><t> Specifies the integer portion of the number of seconds since the epoch.</t><t>- Size: 32 bits.</t> <t>- Units: seconds.</t> <t>Nanoseconds: specifies<dl newline="false" spacing="normal"> <dt>Size:</dt><dd>32 bits.</dd> <dt>Units:</dt><dd>Seconds.</dd></dl></dd> <dt>Nanoseconds:</dt><dd><t>Specifies the fractional portion of the number of seconds since the epoch.</t><t>- Size: 32 bits.</t> <t>- Units: nanoseconds.<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 range 0 to(10^9)-1.</t> </list></t> <t>Epoch: <list hangIndent="10" style="empty">(10<sup>9</sup>)-1.</dd> </dl></dd></dl></dd> <dt>Epoch: </dt><dd> <t>The PTP <xreftarget="IEEE1588"/>target="IEEE1588" format="default"/> epoch is 1 January 1970 00:00:00TAI.</t> </list></t> <t>Leap seconds: <list hangIndent="10" style="empty"> <t>ThisTAI.</t></dd> <dt>Leap seconds:</dt><dd><t> This timestamp format is not affected by leapseconds.</t> </list></t> <t>Resolution: <list hangIndent="10" style="empty"> <t>Theseconds.</t></dd> <dt>Resolution:</dt><dd><t> The resolution is 1nanosecond.</t> </list></t> <t>Wraparound: <list hangIndent="10" style="empty"> <t>Thisnanosecond.</t></dd> <dt>Wraparound:</dt><dd><t> This time format wraps around every2^322<sup>32</sup> seconds, which is roughly 136 years. The next wraparound will occur in the year2106.</t> </list></t>2106.</t></dd> </dl> </section> </section> <section anchor="SynchSec"title="Synchronization Aspects">numbered="true" toc="default"> <name>Synchronization Aspects</name> <t>A specification that defines a new timestamp format or uses one of the recommended timestamp formats should include asection onSynchronizationAspects.Aspects section. Note that the recommended timestamp formats defined in this document (<xreftarget="Recommended"/>)target="Recommended" format="default"/>) 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 <xreftarget="UseCaseSec"/>.</t>target="UseCaseSec" format="default"/>.</t> <t>The Synchronization Aspects section should specify all the assumptions and requirements related to synchronization. For example, the synchronization aspects may specify whether nodes populating the timestamps should be synchronized amongthemselves,themselves and whether the timestamp is measured with respect to a central reference clock such as an NTP server. If time is assumed to be synchronized to a time standard such as UTC or TAI, it should be specified in this section. Further considerations may be discussed in this section, such as the required timestamp accuracy and precision.</t> <t>Another aspect that should be discussed in this section is leap second <xreftarget="RFC5905"/>target="RFC5905" format="default"/> considerations. The timestamp specification template (<xreftarget="format"/>)target="format" format="default"/>) specifies whether the timestamp is affected by leap seconds. It is often the case that further details about leap seconds will need to be defined in the Synchronization Aspects section. Generally speaking, a leap second is a one-second adjustment that is occasionally applied to UTC in order to keep it alignedto thewith solar time. A leap second may be either positive or negative, i.e., the clock may either be shifted one secondforwardsforward orbackwards.backward. All leap seconds that have occurred up to the publication of this document have been in thebackwardsbackward direction, and although forward leap seconds are theoretically possible, the text throughout this document focuses on the common case, which is the backward leap second. In a timekeeping system that considers leap seconds, the system clock may be affected by a leap second in one of three possible ways:</t><t><list style="symbols"> <t>The<ul spacing="normal"> <li>The clock is turned backwards one second at the end of the leapsecond.</t> <t>Thesecond.</li> <li>The clock is frozen during the duration of the leapsecond.</t> <t>Thesecond.</li> <li>The clock is slowed down during the leap second and adjacent time intervals until the new time value catches up. The interval for this process, commonly referred to asleap smear,"leap smear", can range from several seconds to several hours before, during, and/or after the occurrence of the leapsecond.</t> </list></t>second.</li> </ul> <t>The way leap seconds are handled depends on the synchronizationprotocol,protocol and is thus not specified in this document. However, if a timestamp format is defined with respect to a timescale that is affected by leap seconds, the Synchronization Aspects section should specify how the use of leap seconds affects the timestamp usage.</t> </section> <section anchor="UseCaseSec"title="Timestampnumbered="true" toc="default"> <name>Timestamp UseCases">Cases</name> <t>Packet timestamps are used in various network protocols. Typical applications of packet timestamps include delay measurement, clock synchronization, and others. The following table presents a (non-exhaustive) list of protocols that use packettimestamps,timestamps and the timestamp formats used in each of these protocols.</t><figure align="center" anchor="TimestampExamples" title="Protocols that use<table anchor="tab-1" align="left"> <name>Protocols That Use PacketTimestamps"> <artwork align="left"><![CDATA[ +----------------------+-----------------------------------+-----------+ | | Recommended formats | Other | +----------------------+-----------+-----------+-----------+-----------+ | Protocol |NTP 64-bit |NTP 32-bit |PTP Trunc. | | +----------------------+-----------+-----------+-----------+-----------+ | NTP [RFC5905] | + | | | | +----------------------+-----------+-----------+-----------+-----------+ | OWAMP [RFC4656] | + | | | | +----------------------+-----------+-----------+-----------+-----------+ | TWAMP [RFC5357] | + | | | | | TWAMP [RFC8186] | + | | + | | +----------------------+-----------+-----------+-----------+-----------+ | TRILL [RFC7456] | | | + | | +----------------------+-----------+-----------+-----------+-----------+ | MPLS [RFC6374] | | | + | | +----------------------+-----------+-----------+-----------+-----------+ | TCP [RFC7323] | | | | + | +----------------------+-----------+-----------+-----------+-----------+ | RTP [RFC3550] | + | | | + | +----------------------+-----------+-----------+-----------+-----------+ | IPFIX [RFC7011] | | | | + | +----------------------+-----------+-----------+-----------+-----------+ | BinaryTime [RFC6019] | | | | + | +----------------------+-----------+-----------+-----------+-----------+ | [I-D.ietf-ippm- | + | + | | | | initial-registry] | | | | | +----------------------+-----------+-----------+-----------+-----------+ | [I-D.ietf-sfc-nsh | | + | + | | | -dc-allocation] | | | | | +----------------------+-----------+-----------+-----------+-----------+ ]]></artwork> </figure>Timestamps</name> <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> <td align="center">TWAMP <xref target="RFC5357"/><br/>TWAMP <xref target="RFC8186"/></td> <td align="center">+<br/>+</td> <td align="center"></td> <td align="center"><br/>+</td> <td align="center"></td> </tr> <tr> <td align="center">TRILL <xref target="RFC7456"/></td> <td align="center"></td> <td align="center"></td> <td align="center">+</td> <td align="center"></td> </tr> <tr> <td align="center">MPLS <xref target="RFC6374"/></td> <td align="center"></td> <td align="center"></td> <td align="center">+</td> <td align="center"></td> </tr> <tr> <td align="center">TCP <xref target="RFC7323"/></td> <td align="center"></td> <td align="center"></td> <td align="center"></td> <td align="center">+</td> </tr> <tr> <td align="center">RTP <xref target="RFC3550"/></td> <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 twohypothetichypothetical examples of network protocol specifications that use one of the recommended timestamp formats. The examples include the text that specifies the information related to the timestamp format.</t> <section anchor="Ex1Sec"title="Example 1"> <t>Timestamp: <list hangIndent="10" style="empty"> <t>Thenumbered="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 <xreftarget="RFC5905"/>target="RFC5905" format="default"/> 64-bit format, asspecifieddescribed inSection 4.2.1 of<xreftarget="I-D.ietf-ntp-packet-timestamps"/>.</t> </list></t> <t>Synchronization aspects: <list hangIndent="10" style="empty"> <t>Ittarget="time-64bit"/> of RFC 8877.</dd> <dt>Synchronization aspects:</dt> <dd>It is assumed that the nodes that run this protocol are synchronized to UTC using a synchronization mechanism that is outside the scope of this document. In typicaldeploymentsdeployments, this protocol will run on a machine that uses NTP <xreftarget="RFC5905"/>target="RFC5905" format="default"/> for synchronization. Thus, the timestamp may be derived from the NTP-synchronized clock, allowing the timestamp to be measured with respect to the clock of an NTP server. Since the NTP time format is affected by leap seconds, the current timestamp format is similarly affected. Thus, the value of a timestamp duringor slightlyand possibly before and/or after a leap second may be temporarilyinaccurate.</t> </list></t>inaccurate.</dd> </dl> </section> <section anchor="Ex2Sec"title="Example 2"> <t>Timestamp: <list hangIndent="10" style="empty"> <t>Thenumbered="true" toc="default"> <name>Example 2</name> <dl spacing="normal" newline="true"> <dt>Timestamp: </dt> <dd>The timestamp format used in this specification is the PTP <xreftarget="IEEE1588"/> Truncatedtarget="IEEE1588" format="default"/> truncated format, asspecifieddescribed inSection 4.3 of<xreftarget="I-D.ietf-ntp-packet-timestamps"/>.</t> </list></t> <t>Synchronizationtarget="ptp-trunc"/> of RFC 8877.</dd> <dt>Synchronization aspects:<list hangIndent="10" style="empty"> <t>It</dt> <dd>It is assumed that the nodes that run this protocol are synchronized among themselves. Nodes may be synchronized to a global reference time. Note that if PTP <xreftarget="IEEE1588"/>target="IEEE1588" format="default"/> is used for synchronization, the timestamp may be derived from the PTP-synchronized clock, allowing the timestamp to be measured with respect tothe clock of ana PTPGrandmaster clock.</t> </list></t>grandmaster clock.</dd> </dl> </section> </section> <section anchor="ControlSec"title="Packetnumbered="true" toc="default"> <name>Packet Timestamp ControlField">Field</name> <t>In somecasescases, it is desirable to have a control field that describes the structure, format, content, and properties of timestamps. Control information about the timestamp format can be conveyed in some protocols using a dedicated control planeprotocol,protocol or may be made available at the management plane, forexampleexample, using a YANG data model. An optional control field allows some of the control information to be attached to the timestamp.</t> <t>An example of a packet timestamp control field is the Error Estimate field, defined bySection 4.1.2 in<xreftarget="RFC4656"/>,target="RFC4656" sectionFormat="of" section="4.1.2"/>, which is used inOWAMPthe One-Way Active Measurement Protocol (OWAMP) <xreftarget="RFC4656"/>target="RFC4656" format="default"/> andTWAMPTwo-Way Active Measurement Protocol (TWAMP) <xreftarget="RFC5357"/>.target="RFC5357" format="default"/>. The Root Dispersion and Root Delay fields in the NTP header <xreftarget="RFC5905"/>target="RFC5905" format="default"/> are two examples of fields that provide information about the timestamp precision. Another example of an auxiliary field is the Correction Field in the PTP header <xreftarget="IEEE1588"/>;target="IEEE1588" format="default"/>; its value is used as a correction to thetimestamp,timestamp and may be assigned by the sender of the PTP message and updated by transit nodes (Transparent Clocks) in order to account for the delay along the path.</t> <t>This section defines high-level guidelines for defining packet timestamp control fields in network protocols that can benefit from such timestamp-related control information. The word'requirements'"requirements" is used in its informal context in this section.</t> <sectiontitle="High-levelnumbered="true" toc="default"> <name>High-Level Control FieldRequirements">Requirements</name> <t>A control field for packet timestamps must offer an adequate feature set and fulfill a series of requirements to be usable and accepted. The following list captures the main high-level requirements for timestamp fields.</t><t><list style="numbers"> <t>Extensible<ol spacing="normal" type="1"> <li>Extensible Feature Set:protocolsProtocols and applications depend on various timestamp characteristics. A timestamp control field must support a variable number of elements (components) that either describe or quantify timestamp-specific characteristics or parameters. Examples of potential elements include timestamp size, encoding, accuracy, leap seconds, reference clock identifiers,etc.</t> <t>Size:etc.</li> <li>Size: Essential for an efficient use of timestamp control fields is the trade-off between supported features and control field size. Protocols and applications may select the specific control field elements that are needed for their operation from the set of availableelements.</t> <t>Composition:elements.</li> <li>Composition: Applications may depend on specific control field elements being present in messages. The status of these elements may be either mandatory, conditional mandatory, or optional, depending on the specific application and context. A control field specification must support applications in conveying or negotiating (a) the set of control field elements along with (b) the status of any element (i.e., mandatory, conditional mandatory, or optional) by defining appropriate data structures and identitycodes.</t> <t>Category:codes.</li> <li>Category: Control field elements can characterize either static timestamp information(like, e.g.,(e.g., timestamp size in bytes and timestamp semantics: NTP64 bit64-bit format) or runtime timestamp information(like, e.g.,(e.g., estimated timestamp accuracy at the time of sampling: 20 microseconds to UTC). For efficiencyreasonreasons, it may be meaningful to support separation of these two concepts: while the former (static) information is typically valid throughout a protocol session and may be conveyed only once, at session establishment time, the latter (runtime) information augments any timestamp instance and may cause substantial overhead for high-trafficprotocols.</t> </list>Proposalsprotocols.</li> </ol> <t>Proposals for timestamp control fields will be defined in separate documents and are out of scope of this document.</t> </section> </section><!-- Possibly a 'Contributors' section ... --><section anchor="IANA"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>This documentincludeshas norequest to IANA.</t>IANA actions.</t> </section> <section anchor="Security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>A network protocol that uses a packet timestampMUST<bcp14>MUST</bcp14> specify the security considerations that result from using the timestamp. This section provides an overview of some of the common security considerations of using timestamps.</t> <t>Any metadata that is attached to control or data packets, and specifically packet timestamps, can facilitate network reconnaissance; by passively eavesdroppingtoon timestampedpacketspackets, an attacker can gather information about the networkperformance,performance andaboutthe level of synchronization between nodes.</t> <t>In somecasescases, timestamps could be spoofed or modified by on-path attackers, thus attacking the application that uses the timestamps. For example, if timestamps are used in a delay measurement protocol, an attacker can modify en route timestamps in a way that manipulates the measurement results. Integrity protection mechanisms, such as Message Authentication Codes(MAC),(MACs), can mitigate such attacks. The specification of an integrity protection mechanism is outside the scope of thisdocument, as typicallydocument as, typically, integrity protection will be defined on a per-network-protocolbasis,basis and not specifically for the timestamp field.</t> <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 messages, with the same harmful implications as described in the previous paragraph. Mitigating delay attacks is a significant challenge; in contrast to spoofing and modification attacks, the delay attack cannot be prevented by cryptographic integrity protection mechanisms. In somecasescases, delay attacks can be mitigated by sending the timestamped information through multiple paths, allowingto detectdetection of andto be resilientresistance to an attacker that has access to one of the paths.</t> <t>In manycasescases, timestamping relies on an underlying synchronization mechanism. Thus, any attack that compromises the synchronization mechanism can also compromise protocols that use timestamping. Attacks on time protocols are discussed in detail in <xreftarget="RFC7384"/>.</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>target="RFC7384" format="default"/>.</t> </section> </middle><!-- *****BACK MATTER ***** --><back><references title="Normative References"> <?rfc include='reference.RFC.2119'?> <?rfc include='reference.RFC.8174'?> <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?--> <!--&RFC2119;--><displayreference target="I-D.ietf-ippm-initial-registry" to="METRICS"/> <displayreference target="I-D.ietf-sfc-nsh-dc-allocation" to="NSHMD"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references><references title="Informative References"> <!-- Here we use entities that we defined at the beginning. --><references> <name>Informative References</name> <reference anchor="IEEE1588"> <front> <title>IEEE1588Standard for a Precision Clock Synchronization Protocol for Networked Measurement and ControlSystems Version 2</title>Systems</title> <seriesInfo name="IEEE Std." value="1588-2008"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2008.4579760"/> <author> <organization>IEEE</organization> </author> <dateyear="2008"/>year="2008" month="July"/> </front> </reference> <reference anchor="IEEE1588v1"> <front> <title>IEEE1588Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems</title> <seriesInfo name="IEEE Std." value="1588-2002"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2002.94144"/> <author> <organization>IEEE</organization> </author> <date month="October" year="2002"/> </front> </reference> <reference anchor="ITU-T-Y.1731"> <front><title>OAM<title>Operations, administration and maintenance (OAM) functions and mechanisms forEthernet based Networks</title>Ethernet-based networks</title> <seriesInfo name="ITU-T Recommendation" value="G.8013/Y.1731"/> <author> <organization>ITU-T</organization> </author> <dateyear="2013"/>year="2015" month="August"/> </front> </reference><?rfc include='reference.RFC.3339'?> <!-- ?rfc include='reference.RFC.5277'? --> <?rfc include='reference.RFC.7493'?> <?rfc include='reference.RFC.6991'?> <?rfc include='reference.RFC.5646'?> <!-- ?rfc include='reference.RFC.7940'? --> <?rfc include='reference.RFC.5905'?> <?rfc include='reference.RFC.7323'?> <?rfc include='reference.RFC.3550'?> <?rfc include='reference.RFC.6374'?> <?rfc include='reference.RFC.5357'?> <?rfc include='reference.RFC.4656'?> <?rfc include='reference.RFC.7011'?> <?rfc include='reference.RFC.6019'?> <?rfc include='reference.RFC.7456'?> <?rfc include='reference.RFC.7384'?> <?rfc include='reference.RFC.8186'?> <?rfc include='reference.I-D.ietf-ippm-initial-registry'?> <?rfc include='reference.I-D.ietf-sfc-nsh-dc-allocation'?> <?rfc include='reference.I-D.ietf-ntp-packet-timestamps'?><xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3339.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7493.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5646.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7323.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6374.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5357.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4656.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7011.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6019.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7456.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7384.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8186.xml"/> <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><!-- Change Log v00 2016-08-02 TM Initial version v01 2016-08-10 TM Minor updates including: timestamp format change, added Flow ID. --></references> <section anchor="Acknowledgments" numbered="false" toc="default"> <name>Acknowledgments</name> <t>The authors thank <contact fullname="Russ Housley"/>, <contact fullname="Yaakov Stein"/>, <contact fullname="Greg Mirsky"/>, <contact fullname="Warner Losh"/>, <contact fullname="Rodney Cummings"/>, <contact fullname="Miroslav Lichvar"/>, <contact fullname="Denis 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> </rfc>