draft-ietf-tictoc-ptp-enterprise-profile-24.txt   draft-ietf-tictoc-ptp-enterprise-profile-25.txt 
TICTOC Working Group D.A. Arnold TICTOC Working Group D.A. Arnold
Internet-Draft Meinberg-USA Internet-Draft Meinberg-USA
Intended status: Standards Track H.G. Gerstung Intended status: Standards Track H.G. Gerstung
Expires: 26 May 2024 Meinberg Expires: 26 September 2024 Meinberg
23 November 2023 25 March 2024
Enterprise Profile for the Precision Time Protocol With Mixed Multicast Enterprise Profile for the Precision Time Protocol With Mixed Multicast
and Unicast messages and Unicast messages
draft-ietf-tictoc-ptp-enterprise-profile-24 draft-ietf-tictoc-ptp-enterprise-profile-25
Abstract Abstract
This document describes a PTP Profile for the use of the Precision This document describes a PTP Profile for the use of the Precision
Time Protocol in an IPv4 or IPv6 Enterprise information system Time Protocol 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, allows both multicast and unicast Delay Request and Delay
Response messages. Response messages.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 26 May 2024. This Internet-Draft will expire on 26 September 2024.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
skipping to change at page 3, line 6 skipping to change at page 3, line 6
minimize configuration on the participating nodes. Network minimize configuration on the participating nodes. Network
communication was based solely on multicast messages, which unlike communication was based solely on multicast messages, which unlike
NTP did not require that a receiving node in IEEE 1588-2019 NTP did not require that a receiving node in IEEE 1588-2019
[IEEE1588] need to know the identity of the time sources in the [IEEE1588] need to know the identity of the time sources in the
network. This document describes clock roles and PTP Port states network. This document describes clock roles and PTP Port states
using the optional alternative terms timeTransmitter, in stead of using the optional alternative terms timeTransmitter, in stead of
master, and timeReceiver, in stead of slave, as defined in the IEEE master, and timeReceiver, in stead of slave, as defined in the IEEE
1588g [IEEE1588g] amendment to IEEE 1588-2019 [IEEE1588] . 1588g [IEEE1588g] amendment to IEEE 1588-2019 [IEEE1588] .
The "Best TimeTransmitter Clock Algorithm" (IEEE 1588-2019 [IEEE1588] The "Best TimeTransmitter Clock Algorithm" (IEEE 1588-2019 [IEEE1588]
Subclause 9.3), a mechanism that all participating PTP nodes must Subclause 9.3), a mechanism that all participating PTP nodes MUST
follow, set up strict rules for all members of a PTP domain to follow, set up strict rules for all members of a PTP domain to
determine which node shall be the active reference time source determine which node MUST be the active reference time source
(Grandmaster). Although the multicast communication model has (Grandmaster). Although the multicast communication model has
advantages in smaller networks, it complicated the application of PTP advantages in smaller networks, it complicated the application of PTP
in larger networks, for example in environments like IP based in larger networks, for example in environments like IP based
telecommunication networks or financial data centers. It is telecommunication networks or financial data centers. It is
considered inefficient that, even if the content of a message applies considered inefficient that, even if the content of a message applies
only to one receiver, it is forwarded by the underlying network (IP) only to one receiver, it is forwarded by the underlying network (IP)
to all nodes, requiring them to spend network bandwidth and other to all nodes, requiring them to spend network bandwidth and other
resources, such as CPU cycles, to drop the message. resources, such as CPU cycles, to drop the message.
The third edition of the standard (IEEE 1588-2019) defines PTPv2.1 The third edition of the standard (IEEE 1588-2019) defines PTPv2.1
skipping to change at page 4, line 28 skipping to change at page 4, line 28
* Alternate timeTransmitter: A PTP timeTransmitter Clock, which is * Alternate timeTransmitter: A PTP timeTransmitter Clock, which is
not the Best timeTransmitter, may act as a timeTransmitter with not the Best timeTransmitter, may act as a timeTransmitter with
the Alternate timeTransmitter flag set on the messages it sends. the Alternate timeTransmitter flag set on the messages it sends.
* Announce message: Contains the timeTransmitter Clock properties of * Announce message: Contains the timeTransmitter Clock properties of
a timeTransmitter Clock. Used to determine the Best a timeTransmitter Clock. Used to determine the Best
TimeTransmitter. TimeTransmitter.
* Best timeTransmitter: A clock with a PTP Port in the * Best timeTransmitter: A clock with a PTP Port in the
timeTransmitter state, operating consistently with the Best timeTransmitter state, operating as the Grandmaster of a PTP
TimeTransmitter Clock Algorithm. domain.
* Best TimeTransmitter Clock Algorithm: A method for determining * Best TimeTransmitter Clock Algorithm: A method for determining
which state a PTP Port of a PTP clock should be in. The algorithm which state a PTP Port of a PTP clock should be in. The state
works by identifying which of several PTP timeTransmitter capable decisions lead to the formation of a clock spanning tree for a PTP
Clocks is the best timeTransmitter. Clocks have priority to domain.
become the acting Grandmaster, based on the properties each
timeTransmitter Clock sends in its Announce message.
* Boundary Clock: A device with more than one PTP Port. Generally * Boundary Clock: A device with more than one PTP Port. Generally
Boundary Clocks will have one PTP Port in timeReceiver state to Boundary Clocks will have one PTP Port in timeReceiver state to
receive timing and other PTP Ports in timeTransmitter state to re- receive timing and other PTP Ports in timeTransmitter state to re-
distribute the timing. distribute the timing.
* Clock Identity: In IEEE 1588-2019 this is a 64-bit number assigned * Clock Identity: In IEEE 1588-2019 this is a 64-bit number assigned
to each PTP clock which must be globally unique. Often it is to each PTP clock which MUST be globally unique. Often it is
derived from the Ethernet MAC address. derived from the Ethernet MAC address.
* Domain: Every PTP message contains a domain number. Domains are * Domain: Every PTP message contains a domain number. Domains are
treated as separate PTP systems in the network. Clocks, however, treated as separate PTP systems in the network. Clocks, however,
can combine the timing information derived from multiple domains. can combine the timing information derived from multiple domains.
* End-to-End delay measurement mechanism: A network delay * End-to-End delay measurement mechanism: 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
switches. This mechanism might not work properly if the Sync and
Delay Request messages traverse different network paths.
* Grandmaster: the primary timeTransmitter Clock within a domain of * Grandmaster: the primary timeTransmitter Clock within a domain of
a PTP system a PTP system
* IEEE 1588: The timing and synchronization standard which defines * IEEE 1588: The timing and synchronization standard which defines
PTP, and describes the node, system, and communication properties PTP, and describes the node, system, and communication properties
necessary to support PTP. necessary to support PTP.
* TimeTransmitter Clock: a clock with at least one PTP Port in the * TimeTransmitter Clock: a clock with at least one PTP Port in the
timeTransmitter state. timeTransmitter state.
skipping to change at page 5, line 29 skipping to change at page 5, line 32
* NTP: Network Time Protocol, defined by RFC 5905, see RFC 5905 * NTP: Network Time Protocol, defined by RFC 5905, see RFC 5905
[RFC5905] [RFC5905]
* Ordinary Clock: A clock that has a single Precision Time Protocol * 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 domain. It may serve as a timeTransmitter Clock, or be a
timeReceiver Clock. timeReceiver Clock.
* Peer-to-Peer delay measurement mechanism: A network delay * Peer-to-Peer delay measurement mechanism: A network delay
measurement mechanism in PTP facilitated by an exchange of measurement mechanism in PTP facilitated by an exchange of
messages 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
network support PTP and the Peer-to-peer measurement mechanism.
* Preferred timeTransmitter: A device intended to act primarily as * Preferred timeTransmitter: A device intended to act primarily as
the Grandmaster of a PTP system, or as a back up to a Grandmaster. the Grandmaster of a PTP system, or as a back up to a Grandmaster.
* PTP: The Precision Time Protocol: The timing and synchronization * PTP: The Precision Time Protocol: The timing and synchronization
protocol defined by IEEE 1588. protocol defined by IEEE 1588.
* PTP Port: An interface of a PTP clock with the network. Note that * PTP Port: An interface of a PTP clock with the network. Note that
there may be multiple PTP Ports running on one physical interface, there may be multiple PTP Ports running on one physical interface,
for example, mulitple unicast timeReceivers which talk to several for example, mulitple unicast timeReceivers which talk to several
Grandmaster Clocks in different PTP Domains. Grandmaster Clocks in different PTP Domains.
* PTP Profile: A set of constraints on the options and features of
PTP, designed to optimize PTP for a specific use case or industry.
The profile specifies what is required, allowed and forbidden
among options and attribute values of PTP.
* PTPv2.1: Refers specifically to the version of PTP defined by IEEE * PTPv2.1: Refers specifically to the version of PTP defined by IEEE
1588-2019. 1588-2019.
* Rogue timeTransmitter: A clock with a PTP Port in the * Rogue timeTransmitter: A clock with a PTP Port in the
timeTransmitter state, even though it should not be in the timeTransmitter state, even though it should not be in the
timeTransmitter state according to the Best TimeTransmitter Clock timeTransmitter state according to the Best TimeTransmitter Clock
Algorithm, and does not set the Alternate timeTransmitter flag. Algorithm, and does not set the Alternate timeTransmitter flag.
* TimeReceiver Clock: a clock with at least one PTP Port in the * TimeReceiver Clock: a clock with at least one PTP Port in the
timeReceiver state, and no PTP Ports in the timeTransmitter state. timeReceiver state, and no PTP Ports in the timeTransmitter state.
skipping to change at page 6, line 41 skipping to change at page 6, line 52
spread across multiple computers. Furthermore, there is often a spread across multiple computers. Furthermore, there is often a
desire to check the age of information time tagged by a different desire to check the age of information time tagged by a different
machine. To perform these measurements, it is necessary to deliver a machine. To perform these measurements, it is necessary to deliver a
common precise time to multiple devices on a network. Accuracy common precise time to multiple devices on a network. Accuracy
currently required in the Financial Industry range from 100 currently required in the Financial Industry range from 100
microseconds to 1 nanoseconds to the Grandmaster. This PTP Profile microseconds to 1 nanoseconds to the Grandmaster. This PTP Profile
does not specify timing performance requirements, but such 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 non-standard a traditional time transfer such as NTP, without adding non-standard
customizations such as hardware time stamping, and on path support. customizations such as on-path support, similar to what is done in
These features are currently part of PTP, or are allowed by it. PTP with Transparent Clocks and Boundary Clocks. Such PTP support is
Because PTP has a complex range of features and options it is commonly available in switches and routers, and many such devices
necessary to create a PTP Profile for enterprise networks to achieve have already been deployed in networks. Because PTP has a complex
interoperability between equipment manufactured by different vendors. range of features and options it is necessary to create a PTP Profile
for enterprise networks to achieve interoperability between equipment
manufactured by different vendors.
Although enterprise networks can be large, it is becoming 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 desired to make use of
multicast whenever the information going to many destinations is the multicast whenever the information going to many destinations is the
same. It is also advantageous to send information which is unique to same. It is also advantageous to send information which is only
one device as a unicast message. The latter can be essential as the relevant to one device as a unicast message. The latter can be
number of PTP timeReceivers becomes hundreds or thousands. essential as the number of PTP timeReceivers becomes hundreds or
thousands.
PTP devices operating in these networks need to be robust. This PTP devices operating in these networks need to be robust. This
includes the ability to ignore PTP messages which can be identified includes the ability to ignore PTP messages which can be identified
as improper, and to have redundant sources of time. as improper, and to have redundant sources of time.
Interoperability among independent implementations of this PTP Interoperability among independent implementations of this PTP
Profile has been demonstrated at the ISPCS Plugfest ISPCS [ISPCS]. Profile has been demonstrated at the ISPCS Plugfest ISPCS [ISPCS].
5. Network Technology 5. Network Technology
This PTP Profile SHALL operate only in networks characterized by UDP This PTP Profile MUST operate only in networks characterized by UDP
RFC 768 [RFC0768] over either IPv4 RFC 791 [RFC0791] or IPv6 RFC 8200 RFC 768 [RFC0768] over either IPv4 RFC 791 [RFC0791] or IPv6 RFC 8200
[RFC8200], as described by Annexes C and D in IEEE 1588 [IEEE1588] [RFC8200], as described by Annexes C and D in IEEE 1588 [IEEE1588]
respectively. If a network contains both IPv4 and IPv6, then they respectively. Clocks which communicate using IPv4 can interact with
SHALL be treated as separate communication paths. Clocks which clocks using IPv6 if, and only if, there is an intermediary device
communicate using IPv4 can interact with clocks using IPv6 if there which simultaneously communicates with both IP versions. A Boundary
is an intermediary device which simultaneously communicates with both Clock might perform this function, for example. The PTP system MAY
IP versions. A Boundary Clock might perform this function, for include switches and routers. These devices MAY be Transparent
example. A PTP domain SHALL use either IPv4 or IPv6 over a Clocks, Boundary Clocks, or neither, in any combination. PTP Clocks
communication path, but not both. The PTP system MAY include MAY be Preferred timeTransmitters, Ordinary Clocks, or Boundary
switches and routers. These devices MAY be Transparent Clocks, Clocks. The Ordinary Clocks may be TimeReceiver Only Clocks, or be
Boundary Clocks, or neither, in any combination. PTP Clocks MAY be
Preferred timeTransmitters, Ordinary Clocks, or Boundary Clocks. The
Ordinary Clocks may be TimeReceiver Only Clocks, or be
timeTransmitter capable. timeTransmitter capable.
Note that clocks SHOULD always be identified by their Clock ID and Note that clocks SHOULD always be identified by their Clock ID and
not the IP or Layer 2 address. This is important in IPv6 networks not the IP or Layer 2 address. This is important since Transparent
since Transparent Clocks are required to change the source address of Clocks will treat PTP messages that are altered at the PTP
any packet which they alter. In IPv4 networks some clocks might be application layer as new IP packets and new Layer 2 frames when the
PTP messages are retranmitted. In IPv4 networks some clocks might be
hidden behind a NAT, which hides their IP addresses from the rest of hidden behind a NAT, which hides their IP addresses from the rest of
the network. Note also that the use of NATs may place limitations on the network. Note also that the use of NATs may place limitations on
the topology of PTP networks, depending on the port forwarding scheme the topology of PTP networks, depending on the port forwarding scheme
employed. Details of implementing PTP with NATs are out of scope of employed. Details of implementing PTP with NATs are out of scope of
this document. this document.
PTP, similar to NTP, assumes that the one-way network delay for Sync PTP, similar to NTP, assumes that the one-way network delay for Sync
messages and Delay Response messages are the same. When this is not messages and Delay Response messages are the same. When this is not
true it can cause errors in the transfer of time from the true it can cause errors in the transfer of time from the
timeTransmitter to the timeReceiver. It is up to the system timeTransmitter to the timeReceiver. It is up to the system
skipping to change at page 8, line 23 skipping to change at page 8, line 29
be used. be used.
Note that, in IP networks, Sync messages and Delay Request messages Note that, in IP networks, Sync messages and Delay Request messages
exchanged between a timeTransmitter and timeReceiver do not exchanged between a timeTransmitter and timeReceiver do not
necessarily traverse the same physical path. Thus, wherever necessarily traverse the same physical path. Thus, wherever
possible, the network SHOULD be engineered so that the forward and possible, the network SHOULD be engineered so that the forward and
reverse routes traverse the same physical path. Traffic engineering reverse routes traverse the same physical path. Traffic engineering
techniques for path consistency are out of scope of this document. techniques for path consistency are out of scope of this document.
Sync messages MUST be sent as PTP event multicast messages (UDP port Sync messages MUST be sent as PTP event multicast messages (UDP port
319) to the PTP primary IP address. Two step clocks SHALL send 319) to the PTP primary IP address. Two step clocks MUST send
Follow-up messages as PTP general multicast messages (UDP port 320). Follow-up messages as PTP general multicast messages (UDP port 320).
Announce messages MUST be sent as multicast messages (UDP port 320) Announce messages MUST be sent as multicast messages (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, see IEEE 1588 [IEEE1588] Annex D, be a value between 0x0 and 0xF, see IEEE 1588 [IEEE1588] Annex D,
Section D.3. Section D.3. These addresses are aloted by IANA, see the Ipv6
Multicast Address Space Registry [IPv6Registry]
Delay Request messages MAY be sent as either multicast or unicast PTP Delay Request messages MAY be sent as either multicast or unicast PTP
event messages. TimeTransmitter Clocks SHALL respond to multicast event messages. TimeTransmitter Clocks MUST respond to multicast
Delay Request messages with multicast Delay Response PTP general Delay Request messages with multicast Delay Response PTP general
messages. TimeTransmitter Clocks SHALL respond to unicast Delay messages. TimeTransmitter Clocks MUST respond to unicast Delay
Request PTP event messages with unicast Delay Response PTP general Request PTP event messages with unicast Delay Response PTP general
messages. This allows for the use of Ordinary Clocks which do not messages. This allows for the use of Ordinary Clocks which do not
support the Enterprise Profile, if they are timeReceiver Only Clocks. support the Enterprise Profile, if they are timeReceiver Only Clocks.
Clocks SHOULD include support for multiple domains. The purpose is Clocks SHOULD include support for multiple domains. The purpose is
to support multiple simultaneous timeTransmitters for redundancy. to support multiple simultaneous timeTransmitters for redundancy.
Leaf devices (non-forwarding devices) can use timing information from Leaf 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 PTP instantiations of a PTP stack, each operating in a different PTP
Domain. Redundant sources of timing can be ensembled, and/or Domain. Redundant sources of timing can be ensembled, and/or
skipping to change at page 9, line 4 skipping to change at page 9, line 10
multiple timeTransmitters by combining information from multiple multiple timeTransmitters by combining information from multiple
instantiations of a PTP stack, each operating in a different PTP instantiations of a PTP stack, each operating in a different PTP
Domain. Redundant sources of timing can be ensembled, and/or Domain. Redundant sources of timing can be ensembled, and/or
compared to check for faulty timeTransmitter Clocks. The use of compared to check for faulty timeTransmitter Clocks. The use of
multiple simultaneous timeTransmitters will help mitigate faulty multiple simultaneous timeTransmitters will help mitigate faulty
timeTransmitters reporting as healthy, network delay asymmetry, and timeTransmitters reporting as healthy, network delay asymmetry, and
security problems. Security problems include on-path attacks such as security problems. Security problems include on-path attacks such as
delay attacks, packet interception / manipulation attacks. Assuming delay attacks, packet interception / manipulation attacks. Assuming
the path to each timeTransmitter is different, failures malicious or the path to each timeTransmitter is different, failures malicious or
otherwise would have to happen at more than one path simultaneously. otherwise would have to happen at more than one path simultaneously.
Whenever feasible, the underlying network transport technology SHOULD Whenever feasible, the underlying network transport technology SHOULD
be configured so that timing messages in different domains traverse be configured so that timing messages in different domains traverse
different network paths. different network paths.
7. Default Message Rates 7. Default Message Rates
The Sync, Announce, and Delay Request default message rates SHALL The Sync, Announce, and Delay Request default message rates MUST each
each be once per second. The Sync and Delay Request message rates be once per second. The Sync and Delay Request message rates MAY be
MAY be set to other values, but not less than once every 128 seconds, set to other values, but not less than once every 128 seconds, and
and not more than 128 messages per second. The Announce message rate not more than 128 messages per second. The Announce message rate
SHALL NOT be changed from the default value. The Announce Receipt MUST NOT be changed from the default value. The Announce Receipt
Timeout Interval SHALL be three Announce Intervals for Preferred Timeout Interval MUST be three Announce Intervals for Preferred
TimeTransmitters, and four Announce Intervals for all other TimeTransmitters, and four Announce Intervals for all other
timeTransmitters. timeTransmitters.
The logMessageInterval carried in the unicast Delay Response message The logMessageInterval carried in the unicast Delay Response message
MAY be set to correspond to the timeTransmitter ports preferred MAY be set to correspond to the timeTransmitter ports preferred
message period, rather than 7F, which indicates message periods are message period, rather than 7F, which indicates message periods are
to be negotiated. Note that negotiated message periods are not to be negotiated. Note that negotiated message periods are not
allowed, see forbidden PTP options (Section 13). allowed, see forbidden PTP options (Section 13).
8. Requirements for TimeTransmitter Clocks 8. Requirements for TimeTransmitter Clocks
TimeTransmitter Clocks SHALL obey the standard Best TimeTransmitter TimeTransmitter Clocks MUST obey the standard Best TimeTransmitter
Clock Algorithm from IEEE 1588 [IEEE1588]. PTP systems using this Clock Algorithm from IEEE 1588 [IEEE1588]. PTP systems using this
PTP Profile MAY support multiple simultaneous Grandmasters if each PTP Profile MAY support multiple simultaneous Grandmasters if each
active Grandmaster is operating in a different PTP domain. active Grandmaster is operating in a different PTP domain.
A PTP Port of a clock SHALL NOT be in the timeTransmitter state A PTP Port of a clock MUST NOT be in the timeTransmitter state unless
unless the clock has a current value for the number of UTC leap the clock has a current value for the number of UTC leap seconds.
seconds.
If a unicast negotiation signaling message is received it SHALL be If a unicast negotiation signaling message is received it MUST be
ignored. ignored.
In PTP Networks that contain Transparent Clocks, timeTransmitters In PTP Networks that contain Transparent Clocks, timeTransmitters
might receive Delay Request messages that no longer contains the IP might receive Delay Request messages that no longer contains the IP
Addresses of the timeReceivers. This is becuase Transparent Clocks Addresses of the timeReceivers. This is because Transparent Clocks
might replace the IP address of Delay Requests with their own IP might replace the IP address of Delay Requests with their own IP
address after updating the Correction Fields. For this deployment address after updating the Correction Fields. For this deployment
scenario timeTransmitters will need to have configured tables of scenario timeTransmitters will need to have configured tables of
timeReceivers' IP addresses and associated Clock Identities in order timeReceivers' IP addresses and associated Clock Identities in order
to send Delay Responses to the correct PTP Nodes. to send Delay Responses to the correct PTP Nodes.
9. Requirements for TimeReceiver Clocks 9. Requirements for TimeReceiver Clocks
TimeReceiver Clocks MUST be able to operate properly in a network TimeReceiver Clocks MUST be able to operate properly in a network
which contains multiple timeTransmitters in multiple domains. which contains multiple timeTransmitters in multiple domains.
skipping to change at page 10, line 25 skipping to change at page 10, line 25
the duration of the Announce Time Out Interval. TimeReceivers MAY the duration of the Announce Time Out Interval. TimeReceivers MAY
use an Acceptable TimeTransmitter Table. If a timeTransmitter is not use an Acceptable TimeTransmitter Table. If a timeTransmitter is not
an Acceptable timeTransmitter, then the timeReceiver MUST NOT an Acceptable timeTransmitter, then the timeReceiver MUST NOT
synchronize to it. Note that IEEE 1588-2019 requires timeReceiver synchronize to it. Note that IEEE 1588-2019 requires timeReceiver
Clocks to support both two-step or one-step timeTransmitter Clocks. Clocks to support both two-step or one-step timeTransmitter Clocks.
See IEEE 1588 [IEEE1588], subClause 11.2. See IEEE 1588 [IEEE1588], subClause 11.2.
Since Announce messages are sent as multicast messages timeReceivers Since Announce messages are sent as multicast messages timeReceivers
can obtain the IP addresses of a timeTransmitter from the Announce can 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 may have been replaced by the source addresses of a messages might have been replaced by the source addresses of a
Transparent Clock, so, timeReceivers MUST send Delay Request messages Transparent Clock, so, timeReceivers MUST send Delay Request messages
to the IP address in the Announce message. Sync and Follow-up to the IP address in the Announce message. Sync and Follow-up
messages can be correlated with the Announce message using the Clock messages can be correlated with the Announce message using the Clock
ID, which is never altered by Transparent Clocks in this PTP Profile. ID, which is never altered by Transparent Clocks in this PTP Profile.
10. Requirements for Transparent Clocks 10. Requirements for Transparent Clocks
Transparent Clocks SHALL NOT change the transmission mode of an Transparent Clocks MUST NOT change the transmission mode of an
Enterprise Profile PTP message. For example, a Transparent Clock Enterprise Profile PTP message. For example, a Transparent Clock
SHALL NOT change a unicast message to a multicast message. MUST NOT change a unicast message to a multicast message.
Transparent Clocks SHOULD support multiple domains. Transparent Transparent Clocks SHOULD support multiple domains. Transparent
Clocks which syntonize to the timeTransmitter Clock will need to Clocks which syntonize to the timeTransmitter Clock might need to
maintain separate clock rate offsets for each of the supported maintain separate clock rate offsets for each of the supported
domains. domains.
11. Requirements for Boundary Clocks 11. Requirements for Boundary Clocks
Boundary Clocks SHOULD support multiple simultaneous PTP domains. Boundary Clocks SHOULD support multiple simultaneous PTP domains.
This will require them to maintain servo loops 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 MUST NOT
combine timing information from different domains. combine timing information from different domains.
12. Management and Signaling Messages 12. Management and Signaling Messages
PTP Management messages MAY be used. Management messages intended PTP Management messages MAY be used. Management messages intended
for a specific clock, i.e. the IEEE 1588 [IEEE1588] defined attribute for a specific clock, i.e. the IEEE 1588 [IEEE1588] defined attribute
targetPortIdentity.clockIdentity is not set to All 1s, MUST be sent targetPortIdentity.clockIdentity is not set to All 1s, MUST be sent
as a unicast message. Similarly, if any signaling messages are used as a unicast message. Similarly, if any signaling messages are used
they MUST also be sent as unicast messages whenever the message is they MUST also be sent as unicast messages whenever the message is
intended for a specific PTP Node. intended soley for a specific PTP Node.
13. Forbidden PTP Options 13. Forbidden PTP Options
Clocks operating in the Enterprise Profile SHALL NOT use Peer-to-Peer Clocks operating in the Enterprise Profile MUST NOT use Peer-to-Peer
timing for delay measurement. Grandmaster Clusters are NOT ALLOWED. timing for delay measurement. Grandmaster Clusters are NOT ALLOWED.
The Alternate TimeTransmitter option is also NOT ALLOWED. Clocks The Alternate TimeTransmitter option is also NOT ALLOWED. Clocks
operating in the Enterprise Profile SHALL NOT use Alternate operating in the Enterprise Profile MUST NOT use Alternate
Timescales. Unicast discovery and unicast negotiation SHALL NOT be Timescales. Unicast discovery and unicast negotiation MUST NOT be
used. Clocks operating in the Enterprise Profile SHALL NOT use any used. Clocks operating in the Enterprise Profile MUST NOT use any
optional feature that requires Announce messages to be altered by optional feature that requires Announce messages to be altered by
Transparent Clocks, as this would require the Transparent Clock to Transparent Clocks, as this would require the Transparent Clock to
change the source address and prevent the timeReceiver nodes from change the source address and prevent the timeReceiver nodes from
discovering the protocol address of the timeTransmitter. discovering the protocol address of the timeTransmitter.
14. Interoperation with IEEE 1588 Default Profile 14. Interoperation with IEEE 1588 Default Profile
Clocks operating in the Enterprise Profile will interoperate with Clocks operating in the Enterprise Profile will interoperate with
clocks operating in the Default Profile described in IEEE 1588 clocks operating in the Default Profile described in IEEE 1588
[IEEE1588] Annex I.3. This variant of the Default Profile uses the [IEEE1588] Annex I.3. This variant of the Default Profile uses the
skipping to change at page 12, line 17 skipping to change at page 12, line 17
Version: 1.0 Version: 1.0
Profile identifier: 00-00-5E-00-01-00 Profile identifier: 00-00-5E-00-01-00
This PTP Profile was specified by the IETF This PTP Profile was specified by the IETF
A copy may be obtained at A copy may be obtained at
https://datatracker.ietf.org/wg/tictoc/documents https://datatracker.ietf.org/wg/tictoc/documents
16. Acknowledgements 16. Acknowledgements
The authors would like to thank members of IETF for reviewing and The authors would like to thank Richard Cochran, Kevin Gross, John
providing feedback on this draft. Fletcher, Laurent Montini and many other members of IETF for
reviewing and providing feedback on this draft.
This document was initially prepared using 2-Word-v2.0.template.dot This document was initially prepared using 2-Word-v2.0.template.dot
and has later been converted manually into xml format using an and has later been converted manually into xml format using an
xml2rfc template. xml2rfc template.
17. IANA Considerations 17. IANA Considerations
There are no IANA requirements in this specification. There are no IANA requirements in this specification.
18. Security Considerations 18. Security Considerations
skipping to change at page 13, line 46 skipping to change at page 13, line 46
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
19.2. Informative References 19.2. Informative References
[G8271] International Telecommunication Union, "ITU-T G.8271/ [G8271] International Telecommunication Union, "ITU-T G.8271/
Y.1366, "Time and Phase Synchronization Aspects of Packet Y.1366, "Time and Phase Synchronization Aspects of Packet
Networks"", March 2020, <https://www.itu.int>. Networks"", March 2020, <https://www.itu.int>.
[IPv6Registry]
Venaas, S., "IPv6 Multicast Address Space Registry",
February 2024, <https://iana.org/assignments/ipv6-
multicast-addresses/ipv6-multicast-addresses.xhtml>.
[ISPCS] Arnold, D., "Plugfest Report", October 2017, [ISPCS] Arnold, D., "Plugfest Report", October 2017,
<https://www.ispcs.org>. <https://www.ispcs.org>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
 End of changes. 37 change blocks. 
68 lines changed or deleted 82 lines changed or added

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