rfc9760.original.xml   rfc9760.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC8174] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
tf-tictoc-ptp-enterprise-profile-28" ipr="trust200902" obsoletes="" updates="" s
ubmissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true"
sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.12.3 -->
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
tf-tictoc-ptp-enterprise-profile-28"
number="9760" consensus="true" ipr="trust200902" obsoletes="" updates="" submiss
ionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortR
efs="true" version="3">
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary <title abbrev="Enterprise Profile for PTP">Enterprise Profile for the
if the Precision Time Protocol with Mixed Multicast and Unicast Messages</title>
full title is longer than 39 characters --> <seriesInfo name="RFC" value="9760"/>
<title abbrev="Enterprise Profile for PTP">Enterprise Profile for the Precisi
on Time Protocol With Mixed Multicast and Unicast messages</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-tictoc-ptp-enterprise-pr
ofile-28"/>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Doug Arnold" initials="D.A." surname="Arnold"> <author fullname="Doug Arnold" initials="D." surname="Arnold">
<organization>Meinberg-USA</organization> <organization>Meinberg-USA</organization>
<address> <address>
<postal> <postal>
<street>3 Concord Rd</street> <street>3 Concord Rd</street>
<!-- Reorder these if your country does things differently --> <city>Shrewsbury</city>
<city>Shrewsbury</city>
<region>Massachusetts</region> <region>Massachusetts</region>
<code>01545</code> <code>01545</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<phone/>
<email>doug.arnold@meinberg-usa.com</email> <email>doug.arnold@meinberg-usa.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Heiko Gerstung" initials="H.G." surname="Gerstung"> <author fullname="Heiko Gerstung" initials="H." surname="Gerstung">
<organization>Meinberg</organization> <organization>Meinberg</organization>
<address> <address>
<postal> <postal>
<street>Lange Wand 9</street> <street>Lange Wand 9</street>
<!-- Reorder these if your country does things differently --> <city>Bad Pyrmont</city>
<city>Bad Pyrmont</city>
<region/>
<code>31812</code> <code>31812</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<phone/>
<email>heiko.gerstung@meinberg.de</email> <email>heiko.gerstung@meinberg.de</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<date year="2024"/>
<!-- If the month and year are both specified and are the current ones, xml2
rfc will fill
in the current day for you. If only the current year is specified, xml2r
fc will fill
in the current day and month for you. If the year is not the current one
, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not sp
ecified for the
purpose of calculating the expiry date). With drafts it is normally suf
ficient to
specify just the year. -->
<!-- Meta-data Declarations --> <date year="2025" month="May"/>
<area>INT</area>
<workgroup>tictoc</workgroup>
<area>General</area>
<workgroup>TICTOC Working Group</workgroup>
<keyword>PTP</keyword> <keyword>PTP</keyword>
<keyword>Enterprise Profile</keyword> <keyword>Enterprise Profile</keyword>
<abstract> <abstract>
<t>This document describes a Precision Time Protocol (PTP) Profile <t>This document describes a Precision Time Protocol (PTP) Profile
<xref target="IEEE1588" format="default">IEEE 1588-2019</xref> (IEEE Standard 1588-2019)
for use in an IPv4 or IPv6 Enterprise information system for use in an IPv4 or IPv6 enterprise information system
environment. The PTP Profile uses the End-to-End delay measurement environment. The PTP Profile uses the End-to-End delay measurement
mechanism, allows both multicast and unicast Delay Request and Delay mechanism, allowing both multicast and unicast Delay Request and Delay
Response messages.</t> Response messages.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>The Precision Time Protocol ("PTP"), standardized in IEEE 1588, <t>The Precision Time Protocol (PTP), standardized in IEEE 1588, has
has been designed in its first version (IEEE 1588-2002) with the been designed in its first version (IEEE 1588-2002) with the goal of
goal to minimize configuration on the participating nodes. Network minimizing configuration on the participating nodes. Network communication
communication was based solely on multicast messages, which unlike was based solely on multicast messages, which, unlike NTP, did not require
NTP did not require that a receiving node in that a receiving node as discussed in <xref target="IEEE1588-2019" format=
<xref target="IEEE1588" format="default">IEEE 1588-2019</xref> need to know "default">IEEE 1588-2019</xref> need to know the identities of the
the identity time sources in the network. This document describes clock roles and
of the time sources in the network. PTP Port states using the optional alternative terms "timeTransmitter"
This document describes clock roles and PTP Port states using the optional instead of "master" and "timeReceiver" instead of "slave", as defined in t
alternative terms timeTransmitter, instead of master, he
and timeReceiver, instead of slave, as defined in the <xref target="IEEE158 <xref target="IEEE1588g" format="default">IEEE 1588g amendment</xref> to
8g" format="default">IEEE 1588g</xref> amendment to <xref target="IEEE1588" <xref target="IEEE1588-2019" format="default"></xref>.</t>
format="default">IEEE 1588-2019</xref> . </t> <t>The "Best TimeTransmitter Clock Algorithm" (<xref target="IEEE1588-2019
<t>The "Best TimeTransmitter Clock Algorithm" (<xref target="IEEE1588" for " format="default"></xref>, Subclause 9.3), a mechanism that
mat="default">IEEE 1588-2019</xref> Subclause 9.3), a all participating PTP Nodes <bcp14>MUST</bcp14> follow, sets up strict rul
mechanism that all participating PTP nodes MUST follow, set up es for all
strict rules for all members of a PTP domain to determine which members of a PTP domain to determine which node <bcp14>MUST</bcp14> be the
node MUST be the active reference time source (Grandmaster). active
Although the multicast communication model has advantages in reference time source (Grandmaster). Although the multicast
smaller networks, it complicated the application of PTP in larger communication model has advantages in smaller networks, it complicated
networks, for example in environments like IP based the application of PTP in larger networks -- for example, in environments
telecommunication networks or financial data centers. It is like IP-based telecommunication networks or financial data centers. It
considered inefficient that, even if the content of a message is considered inefficient that, even if the content of a message applies
applies only to one receiver, it is forwarded by the underlying only to one receiver, the message is forwarded by the underlying network (
network (IP) to all nodes, requiring them to spend network IP) to
bandwidth and other resources, such as CPU cycles, to drop the all nodes, requiring them to spend network bandwidth and other
message.</t> resources, such as CPU cycles, to drop it.</t>
<t>The third edition of the standard (IEEE 1588-2019) defines <t>The third edition of the standard (IEEE 1588-2019) defines
PTPv2.1 and includes the PTPv2.1 and includes the
possibility to use unicast communication between the PTP nodes in possibility of using unicast communication between the PTP Nodes in
order to overcome the limitation of using multicast messages for order to overcome the limitation of using multicast messages for
the bi-directional information exchange between PTP nodes. The the bidirectional information exchange between PTP Nodes. The
unicast approach avoided that. In PTP domains with a lot of nodes, unicast approach avoided that. In PTP domains with a lot of nodes,
devices had to throw away most of the received multicast devices had to throw away most of the received multicast
messages because they carried information for some other node. messages because they carried information for some other node.
The percent of PTP message that are discarded as irrelevant to the receving The percent of PTP messages that are discarded as irrelevant to the receivi
node can exceded 99% ng node can exceed 99%
(<xref target="Estrela_and_Bonebakker" format="default">Estrela and Bonebak <xref target="Estrela_and_Bonebakker" format="default"/>.</t>
ker</xref>).</t> <t>PTPv2.1 also includes PTP Profiles (<xref target="IEEE1588-2019" format
<t>PTPv2.1 also includes PTP Profiles (<xref target="IEEE1588" format="def ="default"></xref>, Subclause 20.3).
ault">IEEE 1588-2019</xref> subclause 20.3). These constructs allow organizations to specify selections of
This construct allows organizations to specify selections of
attribute values and optional features, simplifying the attribute values and optional features, simplifying the
configuration of PTP nodes for a specific application. Instead of configuration of PTP Nodes for a specific application. Instead of
having to go through all possible parameters and configuration having to go through all possible parameters and configuration
options and individually set them up, selecting a PTP Profile on a PTP options and individually set them up, selecting a PTP Profile on a PTP
node will set all the parameters that are specified in the PTP Profile Node will set all the parameters that are specified in the PTP Profile
to a defined value. If a PTP Profile definition allows multiple to a defined value. If a PTP Profile definition allows multiple
values for a parameter, selection of the PTP Profile will set the values for a parameter, selection of the PTP Profile will set the
profile-specific default value for this parameter. Parameters not profile-specific default value for this parameter. Parameters not
allowing multiple values are set to the value defined in the PTP allowing multiple values are set to the value defined in the PTP
Profile. Many PTP features and functions are optional, and a Profile. Many PTP features and functions are optional, and a
PTP Profile should also define which optional features of PTP are PTP Profile should also define which optional features of PTP are
required, permitted, and prohibited. It is possible to extend the required, permitted, and prohibited. It is possible to extend the
PTP standard with a PTP Profile by using the TLV mechanism of PTP PTP standard with a PTP Profile by using the TLV mechanism of PTP
(see <xref target="IEEE1588" format="default">IEEE 1588-2019</xref> subclau (see <xref target="IEEE1588-2019" format="default"></xref>, Subclause 13.4)
se 13.4), or
defining an optional Best TimeTransmitter Clock Algorithm and a few other w defining an optional Best TimeTransmitter Clock Algorithm, among other
ays. techniques (which are beyond the scope of this document).
PTP has its own management protocol (defined in PTP has its own management protocol (defined in
<xref target="IEEE1588" format="default">IEEE 1588-2019</xref> subclause 15 <xref target="IEEE1588-2019" format="default"></xref>, Subclause 15.2) but
.2) but allows a PTP Profile to specify an alternative management mechanism --
allows a PTP Profile to specify an alternative management mechanism, for example, the Network Configuration Protocol (NETCONF).</t>
for example NETCONF.</t> <t> In this document, the term "PTP Port" refers to a logical access point
<t> In this document the term PTP Port refers to a logical access point of of a PTP instantiation for PTP communication in a network.</t>
a PTP instantiation for PTP communincation in a network. </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Requirements Language</name> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"MAY", and "OPTIONAL" in this document are to be interpreted as "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
described in BCP 14 <xref target="RFC2119" format="default">RFC 2119 </xref> "<bcp14>SHOULD NOT</bcp14>",
<xref target="RFC8174" format="default">RFC 8174</xref> when, and only when, th "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
ey "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
appear in all capitals, as shown here.</t> 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 anchor="technical_terms" numbered="true" toc="default"> <section anchor="technical_terms" numbered="true" toc="default">
<name>Technical Terms</name> <name>Technical Terms</name>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li>Acceptable TimeTransmitter Table: A PTP timeReceiver Clock may maint <dt>Acceptable TimeTransmitter Table:</dt><dd>A list of timeTransmitters
ain a list of that
timeTransmitters which it is willing to synchronize to.</li> may be maintained by a PTP timeReceiver Clock. The PTP timeReceiver Clock would
<li>Alternate timeTransmitter: A PTP timeTransmitter Clock, which is not be willing to synchronize to timeTransmitters in this list.</dd>
the Best <dt>Alternate timeTransmitter:</dt><dd>A PTP timeTransmitter Clock that
timeTransmitter, may act as a timeTransmitter with the Alternate timeT is not the Best
ransmitter flag set on timeTransmitter and therefore is used as an alternative clock. It may
the messages it sends.</li> act as a timeTransmitter with the Alternate timeTransmitter flag set on
<li>Announce message: Contains the timeTransmitter Clock properties of a the messages it sends.</dd>
timeTransmitter <dt>Announce message:</dt><dd>Contains the properties of a given timeTra
Clock. Used to determine the Best TimeTransmitter.</li> nsmitter Clock. The information is used to determine the Best timeTransmitter.</
<li>Best timeTransmitter: A clock with a PTP Port in the timeTransmitte dd>
r state, operating <dt>Best timeTransmitter:</dt><dd>A clock with a PTP Port in the timeTra
as the Grandmaster of a PTP domain.</li> nsmitter state, operating
<li>Best TimeTransmitter Clock Algorithm: A method for determining which as the Grandmaster of a PTP domain.</dd>
state <dt>Best TimeTransmitter Clock Algorithm:</dt><dd>A method for determini
ng which state
a PTP Port of a PTP clock should be in. The state decisions lead to t he formation of a clock spanning tree a PTP Port of a PTP clock should be in. The state decisions lead to t he formation of a clock spanning tree
for a PTP domain. </li> for a PTP domain.</dd>
<li>Boundary Clock: A device with more than one PTP Port. Generally <dt>Boundary Clock:</dt><dd>A device with more than one PTP Port. Gener
Boundary Clocks will have one PTP Port in timeReceiver state to receiv ally,
e Boundary Clocks will have one PTP Port in the timeReceiver state to re
timing and other PTP Ports in timeTransmitter state to re-distribute t ceive
he timing and other PTP Ports in the timeTransmitter state to redistribut
timing.</li> e the
<li>Clock Identity: In IEEE 1588-2019 this is a 64-bit number timing.</dd>
assigned to each PTP clock which MUST be globally unique. Often it is <dt>Clock Identity:</dt><dd>In <xref target="IEEE1588-2019"/>, a 64-bit
derived from the Ethernet MAC address.</li> number
<li>Domain: Every PTP message contains a domain number. Domains are assigned to each PTP clock. This number <bcp14>MUST</bcp14> be global
treated as separate PTP systems in the network. Clocks, however, ly unique. Often, it is
can combine the timing information derived from multiple domains.</li> derived from the Ethernet Media Access Control (MAC) address.</dd>
<li>End-to-End delay measurement mechanism: A network delay <dt>Domain:</dt><dd>Treated as a separate PTP system in a network. Every
PTP message contains a domain number. Clocks, however,
can combine the timing information derived from multiple domains.</dd>
<dt>End-to-End delay measurement mechanism:</dt><dd>A network delay
measurement mechanism in PTP facilitated by an exchange of measurement mechanism in PTP facilitated by an exchange of
messages between a timeTransmitter Clock and a timeReceiver Clock. messages between a timeTransmitter Clock and a timeReceiver Clock.
These messages might traverse Transparent Clocks and PTP unaware switc These messages might traverse Transparent Clocks and PTP-unaware switc
hes. hes.
This mechanism might not work properly if the Sync and Delay Request m This mechanism might not work properly if the Sync and Delay Request m
essages traverse different network paths.</li> essages traverse different network paths.</dd>
<li>Grandmaster: the timeTransmitter Clock that is currently acting as t <dt>Grandmaster:</dt><dd>The timeTransmitter Clock that is currently act
he reference time source of the PTP domain</li> ing as the reference time source of the PTP domain.</dd>
<li>IEEE 1588: The timing and synchronization standard which defines <dt>IEEE 1588:</dt><dd>The timing and synchronization standard that defi
PTP, and describes the node, system, and communication properties nes
necessary to support PTP.</li> PTP and describes the node, system, and communication properties
<li>TimeTransmitter Clock: a clock with at least one PTP Port in the tim necessary to support PTP.</dd>
eTransmitter state.</li> <dt>NTP:</dt><dd>Network Time Protocol, defined by <xref target="RFC5905
<li>NTP: Network Time Protocol, defined by RFC 5905, see <xref target="R " format="default"/>.</dd>
FC5905" format="default">RFC 5905</xref></li> <dt>Ordinary Clock:</dt><dd>A clock that has a single
<li>Ordinary Clock: A clock that has a single Precision Time Protocol
PTP Port in a domain and maintains the timescale used in the PTP Port in a domain and maintains the timescale used in the
domain. It may serve as a timeTransmitter Clock, or be a timeReceiver domain. It may serve as a timeTransmitter Clock or may be a timeReceiv
Clock.</li> er Clock.</dd>
<li>Peer-to-Peer delay measurement mechanism: A network delay <dt>Peer-to-Peer delay measurement mechanism:</dt><dd>A network delay
measurement mechanism in PTP facilitated by an exchange of measurement mechanism in PTP facilitated by an exchange of
messages over the link between adjacent devices in a network. messages over the link between adjacent devices in a network.
This mechanism might not work properly unless all devices in the netwo This mechanism might not work properly unless all devices in the netwo
rk support PTP and the Peer-to-peer measurement mechanism.</li> rk support PTP and the Peer-to-Peer delay measurement mechanism.</dd>
<li>Preferred timeTransmitter: A device intended to act primarily as the <dt>Preferred timeTransmitter:</dt><dd>A device intended to act primaril
Grandmaster of a PTP system, or as a back up to a Grandmaster.</li> y as the
<li>PTP: The Precision Time Protocol: The timing and synchronization Grandmaster of a PTP system or as a backup to a Grandmaster.</dd>
protocol defined by IEEE 1588.</li> <dt>PTP:</dt><dd>The Precision Time Protocol -- the timing and synchroni
<li>PTP Port: An interface of a PTP clock with the network. Note that zation
there may be multiple PTP Ports running on one physical interface, protocol defined by IEEE 1588.</dd>
for example, mulitple unicast timeReceivers which talk to several Gran <dt>PTP Port:</dt><dd>An interface of a PTP clock with the network. Not
dmaster e that
Clocks in different PTP Domains.</li> there may be multiple PTP Ports running on one physical interface --
<li>PTP Profile: A set of constraints on the options and features of P for example, multiple unicast timeReceivers that talk to several Grand
TP, master
Clocks in different PTP domains.</dd>
<dt>PTP Profile:</dt><dd>A set of constraints on the options and featu
res of PTP,
designed to optimize PTP for a specific use case or industry. designed to optimize PTP for a specific use case or industry.
The profile specifies what is required, allowed and forbidden among op The profile specifies what is required, allowed, and forbidden among o
tions and attribute values of PTP.</li> ptions and attribute values of PTP.</dd>
<li>PTPv2.1: Refers specifically to the version of PTP defined by <dt>PTPv2.1:</dt><dd>Refers specifically to the version of PTP defined b
IEEE 1588-2019.</li> y
<li>Rogue timeTransmitter: A clock with a PTP Port in the timeTransmitte <xref target="IEEE1588-2019"/>.</dd>
r state, even though <dt>Rogue timeTransmitter:</dt><dd>A clock that has a PTP Port in the ti
meTransmitter state -- even though
it should not be in the timeTransmitter state according to the Best Ti meTransmitter it should not be in the timeTransmitter state according to the Best Ti meTransmitter
Clock Algorithm, and does not set the Alternate timeTransmitter flag.< Clock Algorithm -- and that does not set the Alternate timeTransmitter
/li> flag.</dd>
<li>TimeReceiver Clock: a clock with at least one PTP Port in the timeRe <dt>TimeReceiver Clock:</dt><dd>A clock with at least one PTP Port in th
ceiver state, e timeReceiver state
and no PTP Ports in the timeTransmitter state.</li> and no PTP Ports in the timeTransmitter state.</dd>
<li>TimeReceiver Only clock: An Ordinary Clock which cannot become a tim <dt>TimeReceiver Only Clock:</dt><dd>An Ordinary Clock that cannot becom
eTransmitter e a timeTransmitter
Clock.</li> Clock.</dd>
<li>TLV: Type Length Value, a mechanism for extending messages in <dt>TimeTransmitter Clock:</dt><dd>A clock with at least one PTP Port in
networked communications.</li> the timeTransmitter state.</dd>
<li>Transparent Clock. A device that measures the time taken for a <dt>TLV:</dt><dd>Type Length Value -- a mechanism for extending messages
in
networked communications.</dd>
<dt>Transparent Clock:</dt><dd>A device that measures the time taken for
a
PTP event message to transit the device and then updates the PTP event message to transit the device and then updates the
message with a correction for this transit time.</li> message with a correction for this transit time.</dd>
<li>Unicast Discovery: A mechanism for PTP timeReceivers to establish a <dt>Unicast discovery:</dt><dd>A mechanism for PTP timeReceivers to esta
blish a
unicast communication with PTP timeTransmitters using a configured tab le of unicast communication with PTP timeTransmitters using a configured tab le of
timeTransmitter IP addresses and Unicast Message Negotiation.</li> timeTransmitter IP addresses and unicast message negotiation.</dd>
<li>Unicast Negotiation: A mechanism in PTP for timeReceiver Clocks to <dt>Unicast message negotiation:</dt><dd>A mechanism in PTP for timeRece
negotiate unicast Sync, Announce and Delay Request message transmissio iver Clocks to
n rates negotiate unicast Sync, Announce, and Delay Request message transmissi
from timeTransmitters.</li> on rates
</ul> from timeTransmitters.</dd>
</dl>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Problem Statement</name> <name>Problem Statement</name>
<t>This document describes how PTP can be applied to work in large <t>This document describes how PTP can be applied to work in large
enterprise networks. See <xref target="RFC2026" format="default">ISPCS</x ref> for information on IETF applicability statements. enterprise networks.
Such large networks are deployed, for example, in Such large networks are deployed, for example, in
financial corporations. It is becoming increasingly common in such financial corporations. It is becoming increasingly common in such
networks to perform distributed time tagged measurements, such as networks to perform distributed time-tagged measurements, such as
one-way packet latencies and cumulative delays on software one-way packet latencies and cumulative delays on software
systems spread across multiple computers. Furthermore, there is systems spread across multiple computers. Furthermore, there is
often a desire to check the age of information time tagged by a often a desire to check the age of information time-tagged by a
different machine. To perform these measurements, it is necessary different machine. To perform these measurements, it is necessary
to deliver a common precise time to multiple devices on a network. to deliver a common precise time to multiple devices on a network.
Accuracy currently required in the Financial Industry range from Accuracy currently required in the financial industry ranges from
100 microseconds to 1 nanoseconds to the Grandmaster. This 100 microseconds to 1 nanosecond to the Grandmaster. This
PTP Profile does not specify timing performance requirements, but such PTP Profile does not specify timing performance requirements, but such
requirements explain why the needs cannot always be met by NTP, as requirements explain why the needs cannot always be met by NTP as
commonly implemented. Such accuracy cannot usually be achieved with commonly implemented. Such accuracy cannot usually be achieved with
a traditional time transfer such as NTP, without adding NTP, without adding
non-standard customizations such as on-path support, similar to what is do ne in PTP with Transparent Clocks and Boundary Clocks. non-standard customizations such as on-path support, similar to what is do ne in PTP with Transparent Clocks and Boundary Clocks.
Such PTP support is commonly available in switches and routers, and many s uch devices have already been deployed in networks. Such PTP support is commonly available in switches and routers, and many s uch devices have already been deployed in networks.
Because PTP has a complex range of features and Because PTP has a complex range of features and
options it is necessary to create a PTP Profile for enterprise options, it is necessary to create a PTP Profile for enterprise
networks to achieve interoperability between equipment networks to achieve interoperability among equipment
manufactured by different vendors.</t> manufactured by different vendors.</t>
<t>Although enterprise networks can be large, it is becoming <t>Although enterprise networks can be large, it is becoming
increasingly common to deploy multicast protocols, even across increasingly common to deploy multicast protocols, even across
multiple subnets. For this reason, it is desired to make use of multiple subnets. For this reason, it is desirable to make use of
multicast whenever the information going to many destinations is multicast whenever the information going to many destinations is
the same. It is also advantageous to send information which is the same. It is also advantageous to send information that is
only relevant to one device as a unicast message. The latter can be only relevant to one device as a unicast message. The latter can be
essential as the number of PTP timeReceivers becomes hundreds or essential as the number of PTP timeReceivers becomes hundreds or
thousands.</t> thousands.</t>
<t>PTP devices operating in these networks need to be robust. This <t>PTP devices operating in these networks need to be robust. This
includes the ability to ignore PTP messages which can be includes the ability to ignore PTP messages that can be
identified as improper, and to have redundant sources of time.</t> identified as improper and to have redundant sources of time.</t>
<t>Interoperability among independent implementations of this PTP <t>Interoperability among independent implementations of this PTP
Profile has been demonstrated at the ISPCS Plugfest <xref target="ISPCS" f ormat="default">ISPCS</xref>.</t> Profile has been demonstrated at the <xref target="ISPCS" format="default" >International Symposium on Precision Clock Synchronization (ISPCS) Plugfest</xr ef>.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Network Technology</name> <name>Network Technology</name>
<t>This PTP Profile MUST operate only in networks characterized by <t>This PTP Profile <bcp14>MUST</bcp14> operate only in networks character
UDP <xref target="RFC0768" format="default">RFC 768</xref> over either IPv ized by
4 UDP <xref target="RFC0768" format="default"></xref> over either IPv4
<xref target="RFC0791" format="default">RFC 791</xref> or IPv6 <xref targe <xref target="RFC0791" format="default"></xref> or IPv6 <xref target="RFC8
t="RFC8200" format="default">RFC 8200</xref>, 200" format="default"></xref>,
as described by Annexes C and D in <xref target="IEEE1588" format="default as described by Annexes C and D of <xref target="IEEE1588-2019" format="de
">IEEE 1588</xref> respectively. fault"></xref>, respectively.
A network node MAY include multiple PTP instances running simultaneously. A network node <bcp14>MAY</bcp14> include multiple PTP instances running s
IPv4 and IPv6 instances in the same network node MUST operate in different imultaneously.
PTP Domains. IPv4 and IPv6 instances in the same network node <bcp14>MUST</bcp14> opera
PTP Clocks which communicate using IPv4 te in different PTP domains.
can transfer time to PTP Clocks using IPv6, or the reverse, if and only if PTP clocks that communicate using IPv4
, there is a network node can transfer time to PTP clocks using IPv6, or the reverse, if and only if
which simultaneously communicates with both PTP domains in the different I there is a network node
P versions.</t> that simultaneously communicates with both PTP domains in the different IP
<t> The PTP system MAY include switches and routers. versions.</t>
These devices MAY be Transparent Clocks, Boundary Clocks, or <t> The PTP system <bcp14>MAY</bcp14> include switches and routers.
neither, in any combination. PTP Clocks MAY be Preferred timeTransmitters These devices <bcp14>MAY</bcp14> be Transparent Clocks, Boundary Clocks, o
, r
neither, in any combination. PTP clocks <bcp14>MAY</bcp14> be Preferred t
imeTransmitters,
Ordinary Clocks, or Boundary Clocks. The Ordinary Clocks may be Ordinary Clocks, or Boundary Clocks. The Ordinary Clocks may be
TimeReceiver Only Clocks, or be timeTransmitter capable.</t> timeReceiver Only Clocks or may be timeTransmitter capable.</t>
<t>Note that PTP Ports will need to keep tack of the Clock ID of received <t>Note that PTP Ports will need to keep track of the Clock ID of received
messages and messages and
not just the IP or Layer 2 addresses in any network that includes Transpar not just the IP or Layer 2 addresses in any network that includes Transpar
ent Clocks, or might include them in the future. ent Clocks or that might include them in the future.
This is important This is important,
since Transparent Clocks might treat PTP messages that are altered at the PTP application layer since Transparent Clocks might treat PTP messages that are altered at the PTP application layer
as new IP packets and new Layer 2 frames when the PTP messages are retranm as new IP packets and new Layer 2 frames when the PTP messages are retrans
itted. mitted.
In IPv4 networks some clocks In IPv4 networks, some clocks
might be hidden behind a NAT, which hides their IP addresses from might be hidden behind a NAT, which hides their IP addresses from
the rest of the network. Note also that the use of NATs may place the rest of the network. Note also that the use of NATs may place
limitations on the topology of PTP networks, depending on the port limitations on the topology of PTP Networks, depending on the port
forwarding scheme employed. Details of implementing PTP with NATs forwarding scheme employed. Details of implementing PTP with NATs
are out of scope of this document.</t> are out of scope for this document.</t>
<t>PTP, similar to NTP, assumes that the one-way network delay for Sync <t>PTP, similar to NTP, assumes that the one-way network delay for Sync
messages and Delay Response messages are the same. When this is messages and Delay Response messages is the same. When this is
not true it can cause errors in the transfer of time from the not true, it can cause errors in the transfer of time from the
timeTransmitter to the timeReceiver. It is up to the system integrator to design timeTransmitter to the timeReceiver. It is up to the system integrator to design
the network so that such effects do not prevent the PTP system the network so that such effects do not prevent the PTP system
from meeting the timing requirements. The details of network asymmetry from meeting the timing requirements. The details of network asymmetry
are outside the scope of this document. See for are outside the scope of this document. See, for
example, <xref target="G8271" format="default">ITU-T G.8271</xref>.</t> example, <xref target="G8271" format="default">ITU-T G.8271</xref>.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Time Transfer and Delay Measurement</name> <name>Time Transfer and Delay Measurement</name>
<t>TimeTransmitter Clocks, Transparent Clocks and Boundary Clocks MAY be <t>TimeTransmitter Clocks, Transparent Clocks, and Boundary Clocks <bcp14>
either one-step clocks or two-step clocks. TimeReceiver Clocks MUST MAY</bcp14> be
support both behaviors. The End-to-End Delay measurement method either one-step clocks or two-step clocks. TimeReceiver Clocks <bcp14>MUST<
MUST be used.</t> /bcp14>
support both behaviors. The End-to-End delay measurement method
<bcp14>MUST</bcp14> be used.</t>
<t>Note that, in IP networks, Sync messages and Delay Request <t>Note that, in IP networks, Sync messages and Delay Request
messages exchanged between a timeTransmitter and timeReceiver do not necessa rily messages exchanged between a timeTransmitter and timeReceiver do not necessa rily
traverse the same physical path. Thus, wherever possible, the traverse the same physical path. Thus, wherever possible, the
network SHOULD be engineered so that the forward and network <bcp14>SHOULD</bcp14> be engineered so that the forward and
reverse routes traverse the same physical path. Traffic reverse routes traverse the same physical path. Traffic
engineering techniques for path consistency are out of scope of engineering techniques for path consistency are out of scope for
this document.</t> this document.</t>
<t>Sync messages MUST be sent as PTP event multicast messages (UDP <t>Sync messages <bcp14>MUST</bcp14> be sent as PTP event multicast messag
port 319) to the PTP primary IP address. Two step clocks MUST es (UDP
port 319) to the PTP primary IP address. Two-step clocks <bcp14>MUST</bcp1
4>
send Follow-up messages as PTP general multicast messages (UDP port 320). send Follow-up messages as PTP general multicast messages (UDP port 320).
Announce messages MUST be sent as multicast messages (UDP port 320) Announce messages <bcp14>MUST</bcp14> be sent as PTP general multicast messa ges (UDP port 320)
to the PTP primary address. The PTP primary IP address is to the PTP primary address. The PTP primary IP address is
224.0.1.129 for IPv4 and FF0X:0:0:0:0:0:0:181 for IPv6, where X can 224.0.1.129 for IPv4 and FF0X:0:0:0:0:0:0:181 for IPv6, where "X" can
be a value between 0x0 and 0xF. The different IPv6 address options are expla be a value between 0x0 and 0xF. The different IPv6 address options are expla
ined in IEEE 1588 ined in
<xref target="IEEE1588" format="default">IEEE 1588</xref> Annex D, Section D <xref target="IEEE1588-2019" format="default"></xref>, Annex D, Section D.3.
.3. These addresses are allotted by IANA; see the <xref target="IPv6Registry" fo
These addresses are aloted by IANA, see the <xref target="IPv6Registry" form rmat="default">"IPv6 Multicast Address Space Registry"</xref>.</t>
at="default">Ipv6 Multicast Address Space Registry</xref></t> <t>Delay Request messages <bcp14>MAY</bcp14> be sent as either multicast o
<t>Delay Request messages MAY be sent as either multicast or unicast r unicast
PTP event messages. TimeTransmitter Clocks MUST respond to multicast Delay PTP event messages. TimeTransmitter Clocks <bcp14>MUST</bcp14> respond to mu
lticast Delay
Request messages with multicast Delay Response PTP general Request messages with multicast Delay Response PTP general
messages. TimeTransmitter Clocks MUST respond to unicast Delay Request PTP messages. TimeTransmitter Clocks <bcp14>MUST</bcp14> respond to unicast Dela y Request PTP
event messages with unicast Delay Response PTP general messages. event messages with unicast Delay Response PTP general messages.
This allows for the use of Ordinary Clocks which do not support the This allows for the use of Ordinary Clocks that do not support the
Enterprise Profile, if they are timeReceiver Only Clocks.</t> Enterprise Profile, if they are timeReceiver Only Clocks.</t>
<t>Clocks SHOULD include support for multiple domains. The purpose is <t>Clocks <bcp14>SHOULD</bcp14> include support for multiple domains. The purpose is
to support multiple simultaneous timeTransmitters for redundancy. Leaf to support multiple simultaneous timeTransmitters for redundancy. Leaf
devices (non-forwarding devices) can use timing information from devices (non-forwarding devices) can use timing information from
multiple timeTransmitters by combining information from multiple multiple timeTransmitters by combining information from multiple
instantiations of a PTP stack, each operating in a different instantiations of a PTP stack, each operating in a different
PTP Domain. Redundant sources of timing can be ensembled, and/or PTP domain. To check for faulty timeTransmitter Clocks, redundant sources of
compared to check for faulty timeTransmitter Clocks. The use of multiple timing can be evaluated as an ensemble and/or compared individually. The use of
multiple
simultaneous timeTransmitters will help mitigate faulty timeTransmitters rep orting as simultaneous timeTransmitters will help mitigate faulty timeTransmitters rep orting as
healthy, network delay asymmetry, and security problems. Security healthy, network delay asymmetry, and security problems. Security
problems include on-path attacks such as delay attacks, problems include on-path attacks such as delay attacks,
packet interception / manipulation attacks. Assuming the path to packet interception attacks, and packet manipulation attacks. Assuming that
each timeTransmitter is different, failures malicious or otherwise would the path to
each timeTransmitter is different, failures -- malicious or otherwise -- wou
ld
have to happen at more than one path simultaneously. Whenever have to happen at more than one path simultaneously. Whenever
feasible, the underlying network transport technology SHOULD be feasible, the underlying network transport technology <bcp14>SHOULD</bcp14> be
configured so that timing messages in different domains traverse configured so that timing messages in different domains traverse
different network paths.</t> different network paths.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Default Message Rates</name> <name>Default Message Rates</name>
<t>The Sync, Announce, and Delay Request default message rates MUST <t>The Sync, Announce, and Delay Request default message rates <bcp14>MUST </bcp14>
each be once per second. The Sync and Delay Request message rates each be once per second. The Sync and Delay Request message rates
MAY be set to other values, but not less than once every 128 <bcp14>MAY</bcp14> be set to other values, but not less than once every 128
seconds, and not more than 128 messages per second. The Announce seconds and not more than 128 messages per second. The Announce
message rate MUST NOT be changed from the default value. The message rate <bcp14>MUST NOT</bcp14> be changed from the default value. The
Announce Receipt Timeout Interval MUST be three Announce Announce Receipt Timeout Interval <bcp14>MUST</bcp14> be three Announce
Intervals for Preferred TimeTransmitters, and four Announce Intervals for Intervals for Preferred timeTransmitters and four Announce Intervals for
all other timeTransmitters.</t> all other timeTransmitters.</t>
<t>The logMessageInterval carried in the unicast Delay Response <t>The logMessageInterval carried in the unicast Delay Response
message MAY be set to correspond to the timeTransmitter ports preferred message <bcp14>MAY</bcp14> be set to correspond to the timeTransmitter ports
message period, rather than 7F, which indicates message periods ' preferred
message period, rather than 7F, which indicates that message periods
are to be negotiated. Note that negotiated message periods are not are to be negotiated. Note that negotiated message periods are not
allowed, see <xref target="forbidden_ptp_options" format="default">forbidden allowed; see <xref target="forbidden_ptp_options"/> ("<xref target="forbidde
PTP n_ptp_options" format="title"/>").</t>
options</xref>.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Requirements for TimeTransmitter Clocks</name> <name>Requirements for TimeTransmitter Clocks</name>
<t>TimeTransmitter Clocks MUST obey the standard Best TimeTransmitter Cloc <t>TimeTransmitter Clocks <bcp14>MUST</bcp14> obey the standard Best TimeT
k Algorithm ransmitter Clock Algorithm
from <xref target="IEEE1588" format="default">IEEE 1588</xref>. PTP systems as defined in <xref target="IEEE1588-2019" format="default"></xref>. PTP sy
using this PTP Profile MAY support stems using this PTP Profile <bcp14>MAY</bcp14> support
multiple simultaneous Grandmasters if each active Grandmaster is multiple simultaneous Grandmasters if each active Grandmaster is
operating in a different PTP domain.</t> operating in a different PTP domain.</t>
<t>A PTP Port of a clock MUST NOT be in the timeTransmitter state unless t he <t>A PTP Port of a clock <bcp14>MUST NOT</bcp14> be in the timeTransmitter state unless the
clock has a current value for the number of UTC leap clock has a current value for the number of UTC leap
seconds.</t> seconds.</t>
<t>If a unicast negotiation signaling message is received it MUST <t>If a unicast negotiation signaling message is received, it <bcp14>MUST< /bcp14>
be ignored.</t> be ignored.</t>
<t>In PTP Networks that contain Transparent Clocks, timeTransmitters might r eceive Delay Request messages that no longer contains the IP Addresses of the ti meReceivers. <t>In PTP Networks that contain Transparent Clocks, timeTransmitters might r eceive Delay Request messages that no longer contain the IP addresses of the tim eReceivers.
This is because Transparent Clocks might replace the IP address of Delay Req uests This is because Transparent Clocks might replace the IP address of Delay Req uests
with their own IP address after updating the Correction Fields. For this de ployment scenario timeTransmitters will need to have configured tables of timeRe ceivers' IP addresses with their own IP address after updating the Correction Fields. For this de ployment scenario, timeTransmitters will need to have configured tables of timeR eceivers' IP addresses
and associated Clock Identities in order to send Delay Responses to the corr ect PTP Nodes.</t> and associated Clock Identities in order to send Delay Responses to the corr ect PTP Nodes.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default" anchor="req-timereceiver-clocks">
<name>Requirements for TimeReceiver Clocks</name> <name>Requirements for TimeReceiver Clocks</name>
<t>In a network which contains multiple timeTransmitters in multiple domains <t>In a network that contains multiple timeTransmitters in multiple domains,
, timeReceivers <bcp14>SHOULD</bcp14> make use of information from all the tim
TimeReceivers SHOULD make use of information from all the timeTransmitters i eTransmitters in their clock control subsystems.
n their clock control subsystems. TimeReceiver Clocks <bcp14>MUST</bcp14> be able to function in such networks
TimeReceiver Clocks MUST be able to function in such networks even if they u even if they use time from only one of the domains.
se time from only one of the domains. TimeReceiver Clocks <bcp14>MUST</bcp14> be able to operate properly in the
TimeReceiver Clocks MUST be able to operate properly in the presence of a rogue timeTransmitter. TimeReceivers <bcp14>SHOULD NOT</bcp14>
presence of a rogue timeTransmitter. TimeReceivers SHOULD NOT Synchronize to synchronize to a
a timeTransmitter that is not the Best timeTransmitter in its domain. TimeRece
timeTransmitter which is not the Best TimeTransmitter in its domain. TimeRec ivers will
eivers will continue to recognize a Best timeTransmitter for the duration of the
continue to recognize a Best TimeTransmitter for the duration of the Announce Receipt Timeout Interval. TimeReceivers <bcp14>MAY</bcp14> use an A
Announce Time Out Interval. TimeReceivers MAY use an Acceptable TimeTransmit cceptable TimeTransmitter
ter
Table. If a timeTransmitter is not an Acceptable timeTransmitter, then the timeReceiver Table. If a timeTransmitter is not an Acceptable timeTransmitter, then the timeReceiver
MUST NOT synchronize to it. Note that IEEE 1588-2019 requires <bcp14>MUST NOT</bcp14> synchronize to it. Note that IEEE 1588-2019 requires
timeReceiver Clocks to support both two-step or one-step timeTransmitter Clo timeReceiver Clocks to support both two-step and one-step timeTransmitter Cl
cks. ocks.
See <xref target="IEEE1588" format="default">IEEE 1588</xref>, subClause 11. See <xref target="IEEE1588-2019" format="default"></xref>, Subclause 11.2.</
2.</t> t>
<t>Since Announce messages are sent as multicast messages timeReceivers ca <t>Since Announce messages are sent as multicast messages, timeReceivers c
n an
obtain the IP addresses of a timeTransmitter from the Announce messages. obtain the IP addresses of a timeTransmitter from the Announce messages.
Note that the IP source addresses of Sync and Follow-up messages Note that the IP source addresses of Sync and Follow-up messages
might have been replaced by the source addresses of a Transparent might have been replaced by the source addresses of a Transparent
Clock, so, timeReceivers MUST send Delay Request messages to the IP Clock; therefore, timeReceivers <bcp14>MUST</bcp14> send Delay Request messa ges to the IP
address in the Announce message. Sync and Follow-up messages can address in the Announce message. Sync and Follow-up messages can
be correlated with the Announce message using the Clock ID, which be correlated with the Announce message using the Clock ID, which
is never altered by Transparent Clocks in this PTP Profile.</t> is never altered by Transparent Clocks in this PTP Profile.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default" anchor="req-transparent-clocks">
<name>Requirements for Transparent Clocks</name> <name>Requirements for Transparent Clocks</name>
<t>Transparent Clocks MUST NOT change the transmission mode of an <t>Transparent Clocks <bcp14>MUST NOT</bcp14> change the transmission mode of an
Enterprise Profile PTP message. For example, a Transparent Clock Enterprise Profile PTP message. For example, a Transparent Clock
MUST NOT change a unicast message to a multicast message. <bcp14>MUST NOT</bcp14> change a unicast message to a multicast message.
Transparent Clocks which syntonize to the timeTransmitter Clock might need t Transparent Clocks that syntonize to the timeTransmitter Clock might need to
o maintain maintain
separate clock rate offsets for each of the supported domains.</t> separate clock rate offsets for each of the supported domains.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Requirements for Boundary Clocks</name> <name>Requirements for Boundary Clocks</name>
<t>Boundary Clocks SHOULD support multiple simultaneous PTP domains. <t>Boundary Clocks <bcp14>SHOULD</bcp14> support multiple simultaneous PTP domains.
This will require them to maintain separate clocks for each of the This will require them to maintain separate clocks for each of the
domains supported, at least in software. Boundary Clocks MUST NOT domains supported, at least in software. Boundary Clocks <bcp14>MUST NOT</b cp14>
combine timing information from different domains.</t> combine timing information from different domains.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Management and Signaling Messages</name> <name>Management and Signaling Messages</name>
<t>PTP Management messages MAY be used. Management <t>PTP management messages <bcp14>MAY</bcp14> be used. Management
messages intended for a specific clock, i.e. the <xref target="IEEE1588" for messages intended for a specific clock, i.e., where the targetPortIdentity.c
mat="default">IEEE 1588</xref> defined lockIdentity attribute (defined in <xref target="IEEE1588-2019" format="default"
attribute targetPortIdentity.clockIdentity is not set to All 1s, ></xref>) does not have all bits set to 1,
MUST be sent as a unicast message. Similarly, if any signaling <bcp14>MUST</bcp14> be sent as a unicast message. Similarly, if any signali
messages are used they MUST also be sent as unicast messages ng
whenever the message is intended soley for a specific PTP Node.</t> messages are used, they <bcp14>MUST</bcp14> also be sent as unicast messages
whenever the message is intended solely for a specific PTP Node.</t>
</section> </section>
<section anchor="forbidden_ptp_options" numbered="true" toc="default"> <section anchor="forbidden_ptp_options" numbered="true" toc="default">
<name>Forbidden PTP Options</name> <name>Forbidden PTP Options</name>
<t>Clocks operating in the Enterprise Profile MUST NOT use: <t>Clocks operating in the Enterprise Profile <bcp14>MUST NOT</bcp14> use
Peer-to-Peer timing for delay measurement, Grandmaster Clusters, The Alterna the following:</t>
te TimeTransmitter option, Alternate Timescales. <ul spacing="normal">
Unicast discovery, or unicast negotiation. <li>Peer-to-Peer timing for delay measurement</li>
Clocks operating in the Enterprise Profile MUST avoid any optional feature t <li>Grandmaster Clusters</li>
hat requires Announce messages to be altered by Transparent Clocks, <li>The Alternate timeTransmitter option</li>
<li>Alternate Timescales</li>
<li>Unicast discovery</li>
<li>Unicast message negotiation</li>
</ul>
<t>Clocks operating in the Enterprise Profile <bcp14>MUST</bcp14> avoid any
optional feature that requires Announce messages to be altered by Transparent Cl
ocks,
as this would require the Transparent Clock to change the source address and prevent the timeReceiver nodes as this would require the Transparent Clock to change the source address and prevent the timeReceiver nodes
from discovering the protocol address of the timeTransmitter.</t> from discovering the protocol address of the timeTransmitter.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Interoperation with IEEE 1588 Default Profile</name> <name>Interoperation with IEEE 1588 Default Profile</name>
<t>Clocks operating in the Enterprise Profile will interoperate with <t>Clocks operating in the Enterprise Profile will interoperate with
clocks operating in the Default Profile described in <xref target="IEEE1588" format="default">IEEE 1588</xref> clocks operating in the Default Profile described in <xref target="IEEE1588- 2019" format="default"></xref>,
Annex I.3. This variant of the Default Profile uses the End-to-End Annex I.3. This variant of the Default Profile uses the End-to-End
delay measurement mechanism. In addition, the Default Profile delay measurement mechanism. In addition, the Default Profile
would have to operate over IPv4 or IPv6 networks, and use would have to operate over IPv4 or IPv6 networks and use
management messages in unicast when those messages are directed at management messages in unicast when those messages are directed at
a specific clock. If either of these requirements are not met than a specific clock. If neither of these requirements is met, then
Enterprise Profile clocks will not interoperate with Annex I.3 Enterprise Profile clocks will not interoperate with
Default Profile Clocks. The Enterprise Profile will not Default Profile clocks as defined in <xref target="IEEE1588-2019" format="de
interoperate with the Annex I.4 variant of the Default Profile fault"></xref>, Annex I.3. The Enterprise Profile will not
which requires use of the Peer-to-Peer delay measurement mechanism.</t> interoperate with the variant of the Default Profile defined in
<t>Enterprise Profile Clocks will interoperate with clocks operating <xref target="IEEE1588-2019" format="default"></xref>, Annex I.4,
which requires the use of the Peer-to-Peer delay measurement mechanism.</t>
<t>Enterprise Profile clocks will interoperate with clocks operating
in other PTP Profiles if the clocks in the other PTP Profiles obey the in other PTP Profiles if the clocks in the other PTP Profiles obey the
rules of the Enterprise Profile. These rules MUST NOT be changed rules of the Enterprise Profile. These rules <bcp14>MUST NOT</bcp14> be cha nged
to achieve interoperability with other PTP Profiles.</t> to achieve interoperability with other PTP Profiles.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Profile Identification</name> <name>Profile Identification</name>
<t keepWithNext="true">The IEEE 1588 standard requires that all PTP Profil es provide the <t>The IEEE 1588 standard requires that all PTP Profiles provide the
following identifying information.</t> following identifying information.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
PTP Profile:
Enterprise Profile
Profile number: 1
Version: 1.0
Profile identifier: 00-00-5E-01-01-00
This PTP Profile was specified by the IETF <dl newline="false" spacing="compact">
<dt>PTP Profile:</dt><dd>Enterprise Profile</dd>
<dt>Profile number:</dt><dd>1</dd>
<dt>Version:</dt><dd>1.0</dd>
<dt>Profile identifier:</dt><dd>00-00-5E-01-01-00</dd>
</dl>
<t>This PTP Profile was specified by the IETF.</t>
<t>A copy may be obtained at
<eref target="https://datatracker.ietf.org/wg/tictoc/documents" brackets
="angle"/>.</t>
A copy may be obtained at
https://datatracker.ietf.org/wg/tictoc/documents
]]></artwork>
</section>
<section anchor="Acknowledgements" numbered="true" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank Richard Cochran, Kevin Gross, John Flet
cher, Laurent Montini
and many other members of IETF for reviewing and providing feedback on thi
s draft.</t>
<t>This document was initially prepared using 2-Word-v2.0.template.dot
and has later been converted manually into xml format using an xml2rfc
template.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default"> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>There are no IANA requirements in this specification.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default"> <section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>Protocols used to transfer time, such as PTP and NTP can be <t>Protocols used to transfer time, such as PTP and NTP, can be
important to security mechanisms which use time windows for keys important to security mechanisms that use time windows for keys
and authorization. Passing time through the networks poses a and authorization. Passing time through the networks poses a
security risk since time can potentially be manipulated. security risk, since time can potentially be manipulated.
The use of multiple simultaneous timeTransmitters, using multiple PTP The use of multiple simultaneous timeTransmitters, using multiple PTP
domains can mitigate problems from rogue timeTransmitters and domains, can mitigate problems from rogue timeTransmitters and
on-path attacks. Note that Transparent Clocks alter PTP content on-path, on-path attacks. Note that Transparent Clocks alter PTP content on-path,
but in a manner specified in <xref target="IEEE1588" format="default">IEEE 1588 but in a manner specified in <xref target="IEEE1588-2019" format="default"></xr
-2019</xref> ef>
that helps with time transfer accuracy. See sections 9 and 10. Additional that helps with time transfer accuracy. See Sections <xref target="req-ti
mereceiver-clocks" format="counter"/> and <xref target="req-transparent-clocks"
format="counter"/>. Additional
security mechanisms are outside the scope of this document.</t> security mechanisms are outside the scope of this document.</t>
<t>PTP native management messages SHOULD NOT be used, due to the lack <t>PTP management messages <bcp14>SHOULD NOT</bcp14> be used, due to the l ack
of a security mechanism for this option. Secure management can be of a security mechanism for this option. Secure management can be
obtained using standard management mechanisms which include obtained using standard management mechanisms that include
security, for example NETCONF <xref target="RFC6241" format="default">NET security -- for example, <xref target="RFC6241" format="default">NETCONF<
CONF</xref>.</t> /xref>.</t>
<t>General security considerations of time protocols are discussed in <t>General security considerations related to time protocols are discussed
<xref target="RFC7384" format="default">RFC 7384</xref>.</t> in
<xref target="RFC7384" format="default"></xref>.</t>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries
:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (
as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.8174.xml
"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.x
ml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included fil
es in the same
directory as the including file. You can also define the XML_LIBRARY environ
ment variable
with a value containing a set of directories to search. These can be either
in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RF
C.8174.xml"?-->
<reference anchor="IEEE1588" target="https://www.ieee.org">
<!-- the following is the minimum to make xml2rfc happy -->
<reference anchor="IEEE1588-2019" target="https://ieeexplore.ieee.org/docum ent/9120376">
<front> <front>
<title>IEEE std. 1588-2019, "IEEE Standard for a <title>IEEE Standard for a
Precision Clock Synchronization for Networked Precision Clock Synchronization for Networked
Measurement and Control Systems."</title> Measurement and Control Systems</title>
<author> <author>
<organization>Institute of Electrical and Electronics Engineers</o rganization> <organization>IEEE</organization>
</author> </author>
<date month="11" year="2019"/> <date month="June" year="2020"/>
</front> </front>
<seriesInfo name="IEEE Std" value="1588-2019"/>
</reference> <seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9120376"/>
<reference anchor="IEEE1588g" target="https://www.ieee.org"> </reference>
<!-- the following is the minimum to make xml2rfc happy --> <reference anchor="IEEE1588g" target="https://ieeexplore.ieee.org/documen
t/10070440">
<front> <front>
<title>IEEE std. 1588g-2022, "IEEE Standard for a Precision Clock Sy <title>IEEE Standard for a Precision Clock Synchronization Protocol
nchronization Protocol for Networked Measurement and Control Systems Amendment 2 for Networked Measurement and Control Systems Amendment 2: Master-Slave Optional
: Master-Slave Optional Alternative Terminology"</title> Alternative Terminology</title>
<author> <author>
<organization>Institute of Electrical and Electronics Engineers</o <organization>IEEE</organization>
rganization>
</author>
<date month="12" year="2022"/>
</front>
</reference>
<reference anchor="RFC0768" target="https://www.rfc-editor.org/info/rfc7
68" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.076
8.xml">
<front>
<title>User Datagram Protocol</title>
<author initials="J." surname="Postel" fullname="J. Postel">
<organization/>
</author>
<date year="1980" month="August"/>
</front>
<seriesInfo name="STD" value="6"/>
<seriesInfo name="RFC" value="768"/>
<seriesInfo name="DOI" value="10.17487/RFC0768"/>
</reference>
<reference anchor="RFC0791" target="https://www.rfc-editor.org/info/rfc7
91" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.079
1.xml">
<front>
<title>Internet Protocol</title>
<author initials="J." surname="Postel" fullname="J. Postel">
<organization/>
</author>
<date year="1981" month="September"/>
</front>
<seriesInfo name="STD" value="5"/>
<seriesInfo name="RFC" value="791"/>
<seriesInfo name="DOI" value="10.17487/RFC0791"/>
</reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.21
19.xml">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization/>
</author>
<date year="1997" month="March"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.81
74.xml">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization/>
</author>
<date year="2017" month="May"/>
<abstract>
<t> RFC 2119 specifies common key words that may be used in prot
ocol specifications. This document aims to reduce the ambiguity by clarifying t
hat only UPPERCASE usage of the key words have the defined special meanings..</t
>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8200" target="https://www.rfc-editor.org/info/rfc8
200" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.82
00.xml">
<front>
<title>Internet Protocol, Version 6 (IPv6) Specification</title>
<author initials="S." surname="Deering" fullname="S. Deering">
<organization/>
</author>
<author initials="R." surname="Hinden" fullname="R. Hinden">
<organization/>
</author> </author>
<date year="2017" month="July"/> <date month="March" year="2023"/>
<abstract>
<t>This document specifies version 6 of the Internet Protocol (IPv
6). It obsoletes RFC 2460.</t>
</abstract>
</front> </front>
<seriesInfo name="STD" value="86"/> <seriesInfo name="IEEE Std" value="1588g-2022"/>
<seriesInfo name="RFC" value="8200"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2023.10070440"/>
<seriesInfo name="DOI" value="10.17487/RFC8200"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
768.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
791.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
200.xml"/>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="G8271" target="https://www.itu.int"> <reference anchor="G8271" target="https://www.itu.int/rec/T-REC-G.8271-2 02003-I/en">
<front> <front>
<title>ITU-T G.8271/Y.1366, "Time and Phase Synchronization Aspects of Packet Networks"</title> <title>Time and phase synchronization aspects of telecommunication n etworks</title>
<author> <author>
<organization>International Telecommunication Union</organization> <organization>ITU-T</organization>
</author> </author>
<date month="3" year="2020"/> <date month="March" year="2020"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="G.8271/Y.1366"/>
</reference> </reference>
<reference anchor="ISPCS" target="https://www.ispcs.org"> <reference anchor="ISPCS" target="https://2017.ispcs.org/plugfest">
<front> <front>
<title>Plugfest Report</title> <title>Plugfest</title>
<author surname="Arnold" initials="D."> <author surname="Arnold" initials="D.">
<organization>International Symposium on Precision Clock <organization>International Symposium on Precision Clock
Synchronization for Measurement, Control and Communications</ organization> Synchronization for Measurement, Control and Communications</ organization>
</author> </author>
<date month="10" year="2017"/> <author surname="Harris" initials="K.">
</front> <organization/>
</reference> </author>
<reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6 <date month="August" year="2017"/>
241" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.62
41.xml">
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author initials="R." surname="Enns" fullname="R. Enns" role="editor
">
<organization/>
</author>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" ro
le="editor">
<organization/>
</author>
<author initials="J." surname="Schoenwaelder" fullname="J. Schoenwae
lder" role="editor">
<organization/>
</author>
<author initials="A." surname="Bierman" fullname="A. Bierman" role="
editor">
<organization/>
</author>
<date year="2011" month="June"/>
<abstract>
<t>The Network Configuration Protocol (NETCONF) defined in this do
cument provides mechanisms to install, manipulate, and delete the configuration
of network devices. It uses an Extensible Markup Language (XML)-based data enco
ding for the configuration data as well as the protocol messages. The NETCONF p
rotocol operations are realized as remote procedure calls (RPCs). This document
obsoletes RFC 4741. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6241"/>
<seriesInfo name="DOI" value="10.17487/RFC6241"/>
</reference>
<reference anchor="RFC5905" target="https://www.rfc-editor.org/info/rfc5
905" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.59
05.xml">
<front>
<title>Network Time Protocol Version 4: Protocol and Algorithms Spec
ification</title>
<author initials="D." surname="Mills" fullname="D. Mills">
<organization/>
</author>
<author initials="J." surname="Martin" fullname="J. Martin" role="ed
itor">
<organization/>
</author>
<author initials="J." surname="Burbank" fullname="J. Burbank">
<organization/>
</author>
<author initials="W." surname="Kasch" fullname="W. Kasch">
<organization/>
</author>
<date year="2010" month="June"/>
<abstract>
<t>The Network Time Protocol (NTP) is widely used to synchronize c
omputer clocks in the Internet. This document describes NTP version 4 (NTPv4),
which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305,
as well as previous versions of the protocol. NTPv4 includes a modified protoco
l header to accommodate the Internet Protocol version 6 address family. NTPv4 i
ncludes fundamental improvements in the mitigation and discipline algorithms tha
t extend the potential accuracy to the tens of microseconds with modern workstat
ions and fast LANs. It includes a dynamic server discovery scheme, so that in m
any cases, specific server configuration is not required. It corrects certain e
rrors in the NTPv3 design and implementation and includes an optional extension
mechanism. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5905"/>
<seriesInfo name="DOI" value="10.17487/RFC5905"/>
</reference>
<reference anchor="RFC2026" target="https://www.rfc-editor.org/info/rfc2026" xml
:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2026.xml">
<front>
<title>The Internet Standards Process -- Revision 3</title>
<author initials="S." surname="Bradner" fullname="Scott O. Bradner">
<organization/>
</author>
<date year="1996" month="October"/>
<abstract>
<t>This memo documents the process used by the Internet community
for
the standardization of protocols and procedures. It defines the
stages in the standardization process, the requirements for moving a
document between stages and the types of documents used during this
process. It also addresses the intellectual property rights and
copyright issues associated with the standards process.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2026"/>
<seriesInfo name="DOI" value="10.17487/RFC2026"/>
</reference>
<reference anchor="RFC7384" target="https://www.rfc-editor.org/info/rfc7
384" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.73
84.xml">
<front>
<title>Security Requirements of Time Protocols in Packet Switched Ne
tworks</title>
<author initials="T." surname="Mizrahi" fullname="T. Mizrahi">
<organization/>
</author>
<date year="2014" month="October"/>
<abstract>
<t>As time and frequency distribution protocols are becoming incre
asingly common and widely deployed, concern about their exposure to various secu
rity threats is increasing. This document defines a set of security requirement
s for time protocols, focusing on the Precision Time Protocol (PTP) and the Netw
ork Time Protocol (NTP). This document also discusses the security impacts of ti
me protocol practices, the performance implications of external security practic
es on time protocols, and the dependencies between other security services and t
ime synchronization.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="7384"/> <refcontent>Proceedings of the IEEE International Symposium on Precisio
<seriesInfo name="DOI" value="10.17487/RFC7384"/> n Clock Synchronization for Measurement, Control, and Communication (ISPCS)</ref
content>
</reference> </reference>
<reference anchor="IPv6Registry" target="https://iana.org/assignments/ip <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
v6-multicast-addresses/ipv6-multicast-addresses.xhtml"> 241.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
905.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
384.xml"/>
<reference anchor="IPv6Registry" target="https://iana.org/assignments/ip
v6-multicast-addresses">
<front> <front>
<title>IPv6 Multicast Address Space Registry</title> <title>IPv6 Multicast Address Space Registry</title>
<author initials="S." surname="Venaas" fullname="Stig Venaas"> <author>
<organization>Internet Assigned Numbers Authority</organization> <organization>IANA</organization>
</author> </author>
<date year="2024" month="February"/>
</front> </front>
</reference> </reference>
<reference anchor="Estrela_and_Bonebakker" target="https://www.researchgat e.net/publication/260742322_Challenges_deploying_PTPv2_in_a_global_financial_com pany"> <reference anchor="Estrela_and_Bonebakker" target="https://www.researchgat e.net/publication/260742322_Challenges_deploying_PTPv2_in_a_global_financial_com pany">
<!-- the following is the minimum to make xml2rfc happy -->
<front> <front>
<title>Estrela and Bonebakker, "Challenges deploying PTPv2 in a globa <title>Challenges deploying PTPv2 in a global financial company</titl
l financial company"</title> e>
<author initials="P." surname="Estrela" fullname="P. V. Estrela"> <author initials="P." surname="Estrela" fullname="P. V. Estrela"/>
<organization>IEEE International Symposium on Precision Clock Sy <author initials="L." surname="Bonebakker" fullname="L. Bonebakker
nchronization for Measurement, Control and Communication Proceedings "/>
</organization> <date month="September" year="2012"/>
</author>
<author initials="L." surname="Bonebakker" fullname="L. Bonebakker
">
<organization>IEEE International Symposium on Precision Clock Sy
nchronization for Measurement, Control and Communication Proceedings
</organization>
</author>
<date year="2012"/>
</front> </front>
<refcontent>Proceedings of the IEEE International Symposium on Precis ion Clock Synchronization for Measurement, Control and Communication, pp. 1-6</r efcontent>
<seriesInfo name="DOI" value="10.1109/ISPCS.2012.6336634"/> <seriesInfo name="DOI" value="10.1109/ISPCS.2012.6336634"/>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Richard
Cochran"/>, <contact fullname="Kevin Gross"/>, <contact fullname="John
Fletcher"/>, <contact fullname="Laurent Montini"/>, and many other
members of the IETF for reviewing and providing feedback on this document.
</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 130 change blocks. 
680 lines changed or deleted 437 lines changed or added

This html diff was produced by rfcdiff 1.48.