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

Abstract

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 PTP Profile uses the End-to-End delay measurement mechanism, allowing both multicast and unicast Delay Request and Delay Response messages.¶

1. Introduction

The Precision Time Protocol (PTP), standardized in IEEE 1588, has been designed in its first version (IEEE 1588-2002) with the goal of minimizing configuration on the participating nodes. Network communication was based solely on multicast messages, which, unlike NTP, did not require that a receiving node as discussed in IEEE 1588-2019 [IEEE1588-2019] need to know the identities of the time sources in the network. This document describes clock roles and PTP Port states using 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), a mechanism that all participating PTP Nodes MUST follow, sets up strict rules for all members of a PTP domain to determine which node MUST be the active reference time source (Grandmaster). Although the multicast communication model has advantages in smaller networks, it complicated the application of PTP in larger networks -- for example, in environments like IP-based telecommunication networks or financial data centers. It is considered inefficient that, even if the content of a message applies only to one receiver, the message is forwarded by the underlying network (IP) to all nodes, requiring them to spend network bandwidth and other resources, such as CPU cycles, to drop it.¶

The third edition of the standard (IEEE 1588-2019) defines PTPv2.1 and includes the possibility of using unicast communication between the PTP Nodes in order to overcome the limitation of using multicast messages for the bidirectional information exchange between PTP Nodes. The unicast approach avoided that. In PTP domains with a lot of nodes, devices had to throw away most of the received multicast messages because they carried information for some other node. The percent of PTP messages that are discarded as irrelevant to the receiving node can exceed 99% [Estrela_and_Bonebakker].¶

PTPv2.1 also includes PTP Profiles ([IEEE1588-2019], Subclause 20.3). These constructs allow organizations to specify selections of attribute values and optional features, simplifying the configuration of PTP Nodes for a specific application. Instead of having to go through all possible parameters and configuration 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 to a defined value. If a PTP Profile definition allows multiple values for a parameter, selection of the PTP Profile will set the profile-specific default value for this parameter. Parameters not allowing multiple values are set to the value defined in the PTP Profile. Many PTP features and functions are optional, and a PTP Profile should also define which optional features of PTP are required, permitted, and prohibited. It is possible to extend the PTP standard with a PTP Profile by using the TLV mechanism of PTP (see [IEEE1588-2019], Subclause 13.4) or defining an optional Best TimeTransmitter Clock Algorithm, among other techniques (which are beyond the scope of this document). PTP has its own management protocol (defined in [IEEE1588-2019], Subclause 15.2) but allows a PTP Profile to specify an alternative management mechanism -- for example, 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.¶

4. Problem Statement

This document describes how PTP can be applied to work in large enterprise networks. Such large networks are deployed, for example, in financial corporations. It is becoming increasingly common in such networks to perform distributed time-tagged measurements, such as one-way packet latencies and cumulative delays on software systems spread across multiple computers. Furthermore, there is often a desire to check the age of information time-tagged by a different machine. To perform these measurements, it is necessary to deliver a common precise time to multiple devices on a network. Accuracy currently required in the financial industry ranges from 100 microseconds to 1 nanosecond to the Grandmaster. This PTP Profile does not specify timing performance requirements, but such requirements explain why the needs cannot always be met by NTP as commonly implemented. Such accuracy cannot usually be achieved with NTP, without adding non-standard customizations such as on-path support, similar to what is done in PTP with Transparent Clocks and Boundary Clocks. Such PTP support is commonly available in switches and routers, and many such devices have already been deployed in networks. Because PTP has a complex range of features and options, it is necessary to create a PTP Profile for enterprise networks to achieve interoperability among equipment manufactured by different vendors.¶

Although enterprise networks can be large, it is becoming increasingly common to deploy multicast protocols, even across multiple subnets. For this reason, it is desirable to make use of multicast whenever the information going to many destinations 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 essential as the number of PTP timeReceivers becomes hundreds or thousands.¶

PTP devices operating in these networks need to be robust. This includes the ability to ignore PTP messages that can be identified as improper and to have 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

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

Note that PTP Ports will 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 is important, 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 retransmitted. In IPv4 networks, some clocks 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 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, similar to NTP, assumes that the one-way network delay for Sync messages and Delay Response messages is the same. When this is 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 the network so that such effects do not prevent the PTP system from meeting the timing requirements. The details of network asymmetry are outside the scope of this document. See, for example, ITU-T G.8271 [G8271].¶

6. Time Transfer and Delay Measurement

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

Note that, in IP networks, Sync messages and Delay Request messages exchanged between a timeTransmitter and timeReceiver do not necessarily traverse the same physical path. Thus, wherever possible, the network SHOULD be engineered so that the forward and reverse routes traverse the same physical path. Traffic engineering techniques for path consistency are out of scope for this document.¶

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

Clocks SHOULD include support for multiple domains. The purpose 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. The use of multiple simultaneous timeTransmitters will help mitigate faulty timeTransmitters reporting as healthy, network delay asymmetry, and security problems. Security problems include on-path attacks such as delay attacks, packet interception attacks, and packet manipulation attacks. Assuming that the path to each timeTransmitter is different, failures -- malicious or otherwise -- would have to happen at more than one path simultaneously. 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.¶

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

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

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

18. References