Enterprise Profile for the Precision Time Protocol with Mixed Multicast and Unicast Messages
Extracted elements (29)
Delay Request messages MAY be sent as either multicast or unicast, allowing interoperability with Ordinary Clocks that do not support the Enterprise Profile if they are timeReceiver Only Clocks. This mixed approach is the central innovation of this profile.
Multiple simultaneous timeTransmitters using multiple PTP domains are RECOMMENDED to provide redundancy against rogue timeTransmitters, network delay asymmetry, and security attacks such as delay attacks, packet interception, and packet manipulation, assuming different paths to each timeTransmitter.
The profile was motivated by financial industry requirements for accuracy from 100 microseconds to 1 nanosecond to the Grandmaster and the inefficiency that in large PTP multicast domains over 99% of received PTP messages are discarded as irrelevant.
Unicast discovery and unicast message negotiation are forbidden because the profile relies on multicast Announce messages for timeReceiver discovery of timeTransmitter addresses, making negotiation unnecessary and avoiding complexity in large deployments.
Enterprise Profile clocks interoperate with other PTP Profiles only if those clocks obey all Enterprise Profile rules; those rules MUST NOT be changed to achieve interoperability with other PTP Profiles.
Enterprise Profile clocks will interoperate with the IEEE 1588 Default Profile (Annex I.3) only when that profile uses the End-to-End delay mechanism over IPv4 or IPv6 and sends management messages as unicast when directed at a specific clock. The Enterprise Profile will NOT interoperate with the Default Profile variant in Annex I.4, which requires Peer-to-Peer delay measurement.
PTP Ports must track the Clock ID of received messages and not just IP or Layer 2 addresses in networks with Transparent Clocks, since Transparent Clocks may replace IP addresses on retransmitted PTP messages.
Boundary Clocks MUST NOT combine timing information from different domains.
Boundary Clocks SHOULD support multiple simultaneous PTP domains, requiring them to maintain separate clocks for each supported domain at least in software.
Clocks operating in the Enterprise Profile MUST avoid any optional feature that requires Announce messages to be altered by Transparent Clocks, as this would prevent timeReceivers from discovering the timeTransmitter's protocol address.
Clocks operating in the Enterprise Profile MUST NOT use Peer-to-Peer timing, Grandmaster Clusters, the Alternate timeTransmitter option, Alternate Timescales, unicast discovery, or unicast message negotiation.
Clocks SHOULD include support for multiple domains to support multiple simultaneous timeTransmitters for redundancy; whenever feasible, the underlying network transport SHOULD be configured so that timing messages in different domains traverse different network paths.
If a unicast negotiation signaling message is received by a TimeTransmitter Clock, it MUST be ignored.
Management messages intended for a specific clock (targetPortIdentity.clockIdentity not all-1s) MUST be sent as unicast. Signaling messages intended solely for a specific PTP Node MUST also be sent as unicast.
Sync messages MUST be sent as PTP event multicast messages (UDP port 319) to the PTP primary IP address. Two-step clocks MUST send Follow-up messages as PTP general multicast messages (UDP port 320). Announce messages MUST be sent as PTP general multicast messages (UDP port 320) to the PTP primary address.
The Announce Receipt Timeout Interval MUST be three Announce Intervals for Preferred timeTransmitters and four Announce Intervals for all other timeTransmitters.
The End-to-End delay measurement method MUST be used. TimeReceiver Clocks MUST support both one-step and two-step clock behaviors.
The Sync and Delay Request message rates MAY be set to values other than the default, but not less than once every 128 seconds and not more than 128 messages per second.
The Sync, Announce, and Delay Request default message rates MUST each be once per second. The Announce message rate MUST NOT be changed from the default value.
This PTP Profile MUST operate only in networks characterized by UDP over either IPv4 or IPv6, as described by Annexes C and D of IEEE 1588-2019. IPv4 and IPv6 instances in the same network node MUST operate in different PTP domains.
TimeReceiver Clocks MUST be able to operate properly in the presence of a rogue timeTransmitter and MUST be able to function even if they use time from only one domain. If a timeTransmitter is not an Acceptable timeTransmitter, the timeReceiver MUST NOT synchronize to it.
TimeReceivers MUST send Delay Request messages to the IP address in the Announce message, since Sync and Follow-up message source addresses might have been replaced by Transparent Clock addresses.
TimeTransmitter Clocks MUST obey the standard Best TimeTransmitter Clock Algorithm as defined in IEEE 1588-2019. A PTP Port MUST NOT be in the timeTransmitter state unless the clock has a current value for the number of UTC leap seconds.
TimeTransmitter Clocks MUST respond to multicast Delay Request messages with multicast Delay Response PTP general messages, and MUST respond to unicast Delay Request PTP event messages with unicast Delay Response PTP general messages.
Transparent Clocks MUST NOT change the transmission mode of an Enterprise Profile PTP message — for example, a Transparent Clock MUST NOT change a unicast message to a multicast message.
Profile identification: Enterprise Profile, Profile number 1, Version 1.0, Profile identifier 00-00-5E-01-01-00, specified by the IETF.
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 be a value between 0x0 and 0xF. These addresses are allotted by IANA.
PTP management messages SHOULD NOT be used due to the lack of a security mechanism; secure management should instead use standard mechanisms that include security, such as NETCONF.
Time transfer protocols can be important to security mechanisms using time windows for keys and authorization. Multiple simultaneous timeTransmitters across multiple PTP domains can mitigate rogue timeTransmitters and on-path attacks including delay attacks, packet interception, and packet manipulation.