RFC 9760

Enterprise Profile for the Precision Time Protocol with Mixed Multicast and Unicast Messages

📅 published May 2025, from ietf

Enterprise Profile for the Precision Time Protocol with Mixed Multicast and Unicast Messages 🎀

RFC 9760 ✨ bestie, this one is a Standards Track document from the IETF, dated May 2025. It was written by D. Arnold (Meinberg-USA) and H. Gerstung (Meinberg). Its ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so there's nothing to chase there 💅

Abstract 🌸

Okay so this document describes a Precision Time Protocol (PTP) Profile (IEEE Standard 1588-2019) for use in an IPv4 or IPv6 enterprise information system environment. The profile uses the End-to-End delay measurement mechanism, and it lets both multicast and unicast Delay Request and Delay Response messages get used. It's giving flexibility 🦋

Status of This Memo 🧚

This is an Internet Standards Track document. ✨

It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 7841 💜

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9760.

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. 🫶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Revised BSD License. 📜

Table of Contents 🌈

1.  Introduction
2.  Requirements Language
3.  Technical Terms
4.  Problem Statement
5.  Network Technology
6.  Time Transfer and Delay Measurement
7.  Default Message Rates
8.  Requirements for TimeTransmitter Clocks
9.  Requirements for TimeReceiver Clocks
10. Requirements for Transparent Clocks
11. Requirements for Boundary Clocks
12. Management and Signaling Messages
13. Forbidden PTP Options
14. Interoperation with IEEE 1588 Default Profile
15. Profile Identification
16. IANA Considerations
17. Security Considerations
18. References
    18.1.  Normative References
    18.2.  Informative References
    Acknowledgements
    Authors' Addresses

1. Introduction 🦋

Okay so the Precision Time Protocol (PTP), standardized in IEEE 1588, debuted in its first version (IEEE 1588-2002) with one big goal: keep configuration on the participating nodes to a minimum. ✨ Network communication was based only on multicast messages. Unlike NTP, a receiving node didn't need to know who the time sources in the network were, as discussed in IEEE 1588-2019 [IEEE1588-2019]. Iconic design, honestly 😭

This document describes clock roles and PTP Port states. It uses the optional alternative terms "timeTransmitter" instead of "master" and "timeReceiver" instead of "slave", as defined in the IEEE 1588g amendment [IEEE1588g] to [IEEE1588-2019] 🎀

The "Best TimeTransmitter Clock Algorithm" ([IEEE1588-2019], Subclause 9.3) is a mechanism that all participating PTP Nodes MUST follow. It sets up strict rules so every member of a PTP domain can figure out which node MUST be the active reference time source (Grandmaster). Main character energy 👑

Here's the tea 🍓 The multicast model had real advantages in smaller networks, but it got messy in larger ones, like IP-based telecommunication networks or financial data centers. It's inefficient that, even when a message only applies to one receiver, the underlying network (IP) forwards it to every node. Those nodes then burn network bandwidth and other resources, such as CPU cycles, just to drop it. Not me being stressed about wasted CPU cycles 💀

The third edition of the standard (IEEE 1588-2019) defines PTPv2.1 and adds the option of unicast communication between PTP Nodes. This fixes the limitation of multicast for the bidirectional information exchange between PTP Nodes, and that's the whole point of the unicast approach. In PTP domains with lots of nodes, devices had to throw away most of the multicast messages they received, because those messages carried information meant for some other node. The percentage of PTP messages discarded as irrelevant to the receiving node can go over 99% [Estrela_and_Bonebakker]. That's a lot of wasted effort 😭

PTPv2.1 also includes PTP Profiles ([IEEE1588-2019], Subclause 20.3). These let organizations specify selections of attribute values and optional features, which makes it way easier to configure PTP Nodes for a specific application ✨ Instead of going through every possible parameter and setting each one up by hand, selecting a PTP Profile on a PTP Node sets all the parameters the profile specifies to defined values. If a PTP Profile allows multiple values for a parameter, selecting the profile sets that parameter to the profile-specific default value. Parameters that don't allow multiple values get set to the value the PTP Profile defines. 🧚

A lot of PTP features and functions are optional, so a PTP Profile should also define which optional features are required, permitted, and prohibited. You can extend the PTP standard with a PTP Profile by using the TLV mechanism of PTP (see [IEEE1588-2019], Subclause 13.4), or by defining an optional Best TimeTransmitter Clock Algorithm, among other techniques. Those other techniques are beyond the scope of this document. PTP has its own management protocol (defined in [IEEE1588-2019], Subclause 15.2), but a PTP Profile can specify an alternative management mechanism instead. One example is the Network Configuration Protocol (NETCONF). 💜

In this document, the term "PTP Port" refers to a logical access point of a PTP instantiation for PTP communication in a network. 🌸

2. Requirements Language 🫶

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🔥

3. Technical Terms ✨

okay so before we get into the juicy stuff, we need to make sure we're speaking the same language, bestie 🫶 here's the glossary, no cap 💅

  • Acceptable TimeTransmitter Table: a list of timeTransmitters that a PTP timeReceiver Clock 🎀 may keep on hand. The timeReceiver is willing to sync to anyone on this list 🦋
  • Alternate timeTransmitter: a PTP timeTransmitter Clock that is not the Best timeTransmitter, so it's basically the backup singer 🎤 It can act as a timeTransmitter and sets the Alternate timeTransmitter flag on the messages it sends 🌸
  • Announce message: contains the properties of a given timeTransmitter Clock 📣 The info gets used to figure out who the Best timeTransmitter is 👑
  • Best timeTransmitter: a clock with a PTP Port in the timeTransmitter state, operating as the Grandmaster of a PTP domain. the main character of the domain, obviously 💖
  • Best TimeTransmitter Clock Algorithm: a method for deciding which state a PTP Port of a PTP clock should be in 🧚 Those state decisions build the clock spanning tree for a PTP domain. it's giving organization, iykyk 🌈
  • Boundary Clock: a device with more than one PTP Port 🍓 Usually one Port is in the timeReceiver state to receive timing, and the other Ports are in the timeTransmitter state to pass the timing along 💜
  • Clock Identity: in [IEEE1588-2019], a 64-bit number given to each PTP clock. This number MUST be globally unique 🔥 It's often derived from the Ethernet Media Access Control (MAC) address 🦋
  • Domain: treated as a separate PTP system in a network. Every PTP message has a domain number 🎀 Clocks can still combine the timing info from multiple domains, which is so cool 🧚
  • End-to-End delay measurement mechanism: a network delay measurement mechanism in PTP, facilitated by an exchange of messages between a timeTransmitter Clock and a timeReceiver Clock 💅 Those messages might go through Transparent Clocks and PTP-unaware switches 🌸 This mechanism might not work properly if the Sync and Delay Request messages take different network paths 🙈
  • Grandmaster: the timeTransmitter Clock that's currently acting as the reference time source of the PTP domain 👑
  • IEEE 1588: the timing and synchronization standard that defines PTP and describes the node, system, and communication properties needed to support PTP ✨
  • NTP: Network Time Protocol, defined by [RFC5905] 🌸
  • Ordinary Clock: a clock that has a single PTP Port in a domain and maintains the timescale used in that domain 💖 It may serve as a timeTransmitter Clock or be a timeReceiver Clock 🦋
  • Peer-to-Peer delay measurement mechanism: a network delay measurement mechanism in PTP, facilitated by an exchange of 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 delay measurement mechanism 💀
  • Preferred timeTransmitter: a device intended to act primarily as the Grandmaster of a PTP system, or as a backup to a Grandmaster 👑
  • PTP: The Precision Time Protocol, the timing and synchronization protocol defined by IEEE 1588 ⭐
  • PTP Port: an interface of a PTP clock with the network 🎀 There can be multiple PTP Ports on one physical interface, for example multiple unicast timeReceivers talking to several 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 PTP's options and attribute values 🌈
  • PTPv2.1: refers specifically to the version of PTP defined by [IEEE1588-2019] 🔥
  • Rogue timeTransmitter: a clock that has a PTP Port in the timeTransmitter state, even though it should not be in that state according to the Best TimeTransmitter Clock Algorithm, and that does not set the Alternate timeTransmitter flag 🙈 Not it 😭
  • TimeReceiver Clock: a clock with at least one PTP Port in the timeReceiver state and no PTP Ports in the timeTransmitter state 🦋
  • TimeReceiver Only Clock: an Ordinary Clock that cannot become a timeTransmitter Clock 🌸
  • TimeTransmitter Clock: a clock with at least one PTP Port in the timeTransmitter state 💜
  • TLV: Type Length Value, a mechanism for extending messages in networked communications 🍓
  • Transparent Clock: a device that measures the time it takes for a PTP event message to transit the device, then updates the message with a correction for that transit time ✨
  • Unicast discovery: a mechanism for PTP timeReceivers to establish unicast communication with PTP timeTransmitters, using a configured table of timeTransmitter IP addresses and unicast message negotiation 🫶
  • Unicast message negotiation: a mechanism in PTP for timeReceiver Clocks to negotiate the unicast Sync, Announce, and Delay Request message transmission rates from timeTransmitters 💖

4. Problem Statement 🌸

okay this section is the "why are we even doing this" moment, and it's kind of a big deal 😭

This document describes how PTP can be applied to work in large enterprise networks. Big networks like these show up in places like financial corporations 💼 More and more of these networks are doing distributed time-tagged measurements, like one-way packet latencies and cumulative delays across software systems spread over many computers 🖥️ There's also often a desire to check the age of information time-tagged by a different machine ⏰ To make any of that work, a common precise time has to be delivered to multiple devices on the network 🎯 The accuracy the financial industry currently needs ranges from 100 microseconds down to 1 nanosecond at the Grandmaster 🔥 This PTP Profile doesn't specify timing performance requirements itself, but those requirements explain why NTP, as it's commonly implemented, can't always meet these needs 🙈 That level of accuracy usually can't be reached with NTP unless you add non-standard customizations like on-path support, similar to what PTP does with Transparent Clocks and Boundary Clocks 🧚 That kind of PTP support is commonly available in switches and routers, and tons of those devices are already deployed 🌈 PTP has a really complex range of features and options, so it's necessary to create a PTP Profile for enterprise networks, so that equipment from different vendors can actually interoperate 💅

Even though enterprise networks can be huge, multicast protocols are becoming more common, even across multiple subnets 📡 So it's desirable to use multicast whenever the information going to many destinations is the same 💜 It's also advantageous to send information that's only relevant to one device as a unicast message 🦋 The unicast part gets especially essential once the number of PTP timeReceivers reaches hundreds or thousands 🌸

PTP devices in these networks need to be robust 💪 That includes being able to ignore PTP messages that can be identified as improper, and having redundant sources of time 🫶

Interoperability among independent implementations of this PTP Profile has been demonstrated at the International Symposium on Precision Clock Synchronization (ISPCS) Plugfest [ISPCS] 🎀

5. Network Technology 🌐

okay this is the networking glow-up section 💖

  • This PTP Profile MUST operate only in networks characterized by UDP [RFC0768] over either IPv4 [RFC0791] or IPv6 [RFC8200], as described by Annexes C and D of [IEEE1588-2019], respectively. 🦋
  • A network node MAY include multiple PTP instances running simultaneously ✨
  • IPv4 and IPv6 instances in the same network node MUST operate in different PTP domains 🙈
  • PTP clocks that communicate using IPv4 can transfer time to PTP clocks using IPv6, or the reverse, if and only if there is a network node that simultaneously communicates with both PTP domains in the different IP versions 🌈

The PTP system MAY include switches and routers 🧚 These devices MAY be Transparent Clocks, 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 may be timeTransmitter capable 🌸

Okay, this next bit is important, bestie 🚨 PTP Ports need to keep track of the Clock ID of received messages, and not just the IP or Layer 2 addresses, in any network that includes Transparent Clocks or that might include them in the future 🫶 This matters because 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 messages are retransmitted 💀 In IPv4 networks, some clocks might be hidden behind a NAT, which hides their IP addresses from the rest of the network 🎭 The use of NATs may also place limitations on the topology of PTP Networks, depending on the port forwarding scheme employed 🦋 Details of implementing PTP with NATs are out of scope for this document 🙃

PTP, just like NTP, assumes that the one-way network delay for Sync messages and Delay Response messages is the same 🧠 When that isn't true, it can cause errors in transferring time from the timeTransmitter to the timeReceiver 😬 It's up to the system integrator to design the network so those effects don't stop the PTP system from meeting the timing requirements 🛠️ The details of network asymmetry are outside the scope of this document, but see, for example, ITU-T G.8271 [G8271] for more 📚

6. Time Transfer and Delay Measurement ✨

Okay so this section is all about how the clocks actually swap timing messages, and bestie, it's giving precision. 💅 TimeTransmitter Clocks, Transparent Clocks, and Boundary Clocks MAY be either one-step clocks or two-step clocks. 🦋 TimeReceiver Clocks MUST support both behaviors. The End-to-End delay measurement method MUST be used. No cap, that's the vibe. 🔥

Ngl, there's a catch in IP networks. Sync messages and Delay Request messages between a timeTransmitter and a timeReceiver do not necessarily go the same physical path. 🙈 So wherever it's possible, the network SHOULD be engineered so the forward and reverse routes take the same physical path. ✨ Traffic engineering techniques for path consistency are out of scope for this document, so we're leaving that one for another day. 💜

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 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. 🧚 The different IPv6 address options are explained in [IEEE1588-2019], Annex D, Section D.3. These addresses are allotted by IANA; see the "IPv6 Multicast Address Space Registry" [IPv6Registry]. 🎀

Delay Request messages MAY be sent as either multicast or unicast PTP event messages. TimeTransmitter Clocks MUST respond to multicast Delay Request messages with multicast Delay Response PTP general messages. TimeTransmitter Clocks MUST respond to unicast Delay Request PTP event messages with unicast Delay Response PTP general messages. This allows for the use of Ordinary Clocks that do not support the Enterprise Profile, if they are timeReceiver Only Clocks. 🫶 Lowkey really considerate of the old hardware, iykyk.

Clocks SHOULD include support for multiple domains. The whole point is to support multiple simultaneous timeTransmitters for redundancy. ⭐ Leaf devices (non-forwarding devices) can use timing information from multiple timeTransmitters by combining information from multiple instantiations of a PTP stack, each operating in a different PTP domain. To check for faulty timeTransmitter Clocks, redundant sources of timing can be evaluated as an ensemble and/or compared individually. 👑 Using multiple simultaneous timeTransmitters helps mitigate faulty timeTransmitters reporting as healthy, network delay asymmetry, and security problems. Those security problems include on-path attacks such as delay attacks, packet interception attacks, and packet manipulation attacks. 💀 Assuming the path to each timeTransmitter is different, failures (malicious or otherwise) would have to happen on more than one path at the same time. Whenever feasible, the underlying network transport technology SHOULD be configured so that timing messages in different domains traverse different network paths. 🌈

7. Default Message Rates 🍓

The Sync, Announce, and Delay Request default message rates MUST 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 seconds and not more than 128 messages per second. The Announce message rate MUST NOT be changed from the default value. 🙅‍♀️ The Announce Receipt Timeout Interval MUST be three Announce Intervals for Preferred timeTransmitters and four Announce Intervals for all other timeTransmitters.

The logMessageInterval carried in the unicast Delay Response message MAY be set to correspond to the timeTransmitter ports' preferred message period, rather than 7F, which indicates that message periods are to be negotiated. 💅 Note that negotiated message periods are not allowed; see Section 13 ("Forbidden PTP Options").

8. Requirements for TimeTransmitter Clocks 👑

TimeTransmitter Clocks MUST obey the standard Best TimeTransmitter Clock Algorithm as defined in [IEEE1588-2019]. PTP systems using this PTP Profile MAY support multiple simultaneous Grandmasters if each active Grandmaster is operating in a different PTP domain. 🌸

A PTP Port of a clock MUST NOT be in the timeTransmitter state unless the clock has a current value for the number of UTC leap seconds. ✨ Bestie, no leap second info, no timeTransmitter vibes. 🙅‍♀️

If a unicast negotiation signaling message is received, it MUST be ignored. 🫶

In PTP Networks that contain Transparent Clocks, timeTransmitters might receive Delay Request messages that no longer contain the IP addresses of the timeReceivers. 🦋 This is because Transparent Clocks might replace the IP address of Delay Requests with their own IP address after updating the Correction Fields. For this deployment scenario, timeTransmitters will need to have configured tables of timeReceivers' IP addresses and associated Clock Identities in order to send Delay Responses to the correct PTP Nodes. 🧚

9. Requirements for TimeReceiver Clocks 🎀

In a network that contains multiple timeTransmitters in multiple domains, timeReceivers SHOULD make use of information from all the timeTransmitters in their clock control subsystems. TimeReceiver Clocks MUST be able to function in such networks even if they use time from only one of the domains. TimeReceiver Clocks MUST be able to operate properly in the presence of a rogue timeTransmitter. 😭 TimeReceivers SHOULD NOT synchronize to a timeTransmitter that is not the Best timeTransmitter in its domain. TimeReceivers will continue to recognize a Best timeTransmitter for the duration of the Announce Receipt Timeout Interval. TimeReceivers MAY use an Acceptable TimeTransmitter Table. If a timeTransmitter is not an Acceptable timeTransmitter, then the timeReceiver MUST NOT synchronize to it. 🚫 Note that IEEE 1588-2019 requires timeReceiver Clocks to support both two-step and one-step timeTransmitter Clocks. See [IEEE1588-2019], Subclause 11.2.

Since Announce messages are sent as multicast messages, timeReceivers can obtain the IP addresses of a timeTransmitter from the Announce messages. 🌈 Note that the IP source addresses of Sync and Follow-up messages might have been replaced by the source addresses of a Transparent Clock; therefore, timeReceivers MUST send Delay Request messages to the IP address in the Announce message. Sync and Follow-up messages can be correlated with the Announce message using the Clock ID, which is never altered by Transparent Clocks in this PTP Profile. 💖

10. Requirements for Transparent Clocks ⭐

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. 🙈 Transparent Clocks that syntonize to the timeTransmitter Clock might need to maintain separate clock rate offsets for each of the supported domains.

11. Requirements for Boundary Clocks 🍓

Boundary Clocks SHOULD support multiple simultaneous PTP domains. This will require them to maintain separate clocks for each of the domains supported, at least in software. Boundary Clocks MUST NOT combine timing information from different domains. 🫶

12. Management and Signaling Messages 💜

PTP management messages MAY be used. Management messages intended for a specific clock, i.e., where the targetPortIdentity.clockIdentity attribute (defined in [IEEE1588-2019]) does not have all bits set to 1, MUST be sent as a unicast message. Similarly, if any signaling messages are used, they MUST also be sent as unicast messages whenever the message is intended solely for a specific PTP Node. 📬

13. Forbidden PTP Options 🚫

Clocks operating in the Enterprise Profile MUST NOT use the following:

  • Peer-to-Peer timing for delay measurement
  • Grandmaster Clusters
  • The Alternate timeTransmitter option
  • Alternate Timescales
  • Unicast discovery
  • Unicast message negotiation

Clocks operating in the Enterprise Profile MUST avoid any optional feature that requires Announce messages to be altered by Transparent Clocks, 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. 🙅‍♀️💀

14. Interoperation with IEEE 1588 Default Profile 🌸

Clocks operating in the Enterprise Profile will interoperate with clocks operating in the Default Profile described in [IEEE1588-2019], Annex I.3. This variant of the Default Profile uses the End-to-End delay measurement mechanism. In addition, the Default Profile would have to operate over IPv4 or IPv6 networks and use management messages in unicast when those messages are directed at a specific clock. If neither of these requirements is met, then Enterprise Profile clocks will not interoperate with Default Profile clocks as defined in [IEEE1588-2019], Annex I.3. 🧩 The Enterprise Profile will not interoperate with the variant of the Default Profile defined in [IEEE1588-2019], Annex I.4, which requires the use of the Peer-to-Peer delay measurement mechanism.

Enterprise Profile clocks will interoperate with clocks operating 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 to achieve interoperability with other PTP Profiles. 👑

15. Profile Identification 🎀

The IEEE 1588 standard requires that all PTP Profiles provide the following identifying information.

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. 🌈

A copy may be obtained at <https://datatracker.ietf.org/wg/tictoc/documents>. ✨

16. IANA Considerations 🧚

This document has no IANA actions. 💅

17. Security Considerations 💀

Protocols used to transfer time, such as PTP and NTP, can be important to security mechanisms that use time windows for keys and authorization. 🔐 Passing time through the networks poses a security risk, since time can potentially be manipulated. The use of multiple simultaneous timeTransmitters, using multiple PTP domains, can mitigate problems from rogue timeTransmitters and on-path attacks. Note that Transparent Clocks alter PTP content on-path, but in a manner specified in [IEEE1588-2019] that helps with time transfer accuracy. See Sections 9 and 10. Additional security mechanisms are outside the scope of this document. 😱

PTP management messages SHOULD NOT be used, due to the lack of a security mechanism for this option. Secure management can be obtained using standard management mechanisms that include security -- for example, NETCONF [RFC6241]. 🔒 General security considerations related to time protocols are discussed in [RFC7384]. 🫶

18. References 📚

18.1. Normative References ✨

Okay bestie, these are the docs the spec leans on 🫶 You can't really read this RFC without them.

18.2. Informative References 🦋

These ones are the extra reading 📚 Not strictly required, but SO good for context and backstory.

Acknowledgements 💜

Huge shoutout to Richard Cochran, Kevin Gross, John Fletcher, Laurent Montini, and so many other IETF folks who reviewed this doc and gave feedback 🫶 The authors literally could not have done it without you, you're all iconic ✨

Authors' Addresses 🌸

Doug Arnold
Meinberg-USA
3 Concord Rd
Shrewsbury, Massachusetts 01545
United States of America
Email: doug.arnold@meinberg-usa.com
Heiko Gerstung
Meinberg
Lange Wand 9
31812 Bad Pyrmont
Germany
Email: heiko.gerstung@meinberg.de
📦 where this page comes from