Enterprise Profile for the Precision Time Protocol With Mixed Multicast and Unicast messages
draft-ietf-tictoc-ptp-enterprise-profile-28

TICTOC Working Group                                         D.A. Arnold
Internet-Draft                                              Meinberg-USA
Intended status: Standards Track                           H.G. Gerstung
Expires: 24 January 2025                                        Meinberg
                                                            23 July 2024

Enterprise Profile for the Precision Time Protocol With Mixed Multicast
                          and Unicast messages
              draft-ietf-tictoc-ptp-enterprise-profile-28

Abstract

   This document describes a Precision Time Protocol (PTP) Profile
   IEEE 1588-2019 [IEEE1588] for use in an IPv4 or IPv6 Enterprise
   information system environment.  The PTP Profile uses the End-to-End
   delay measurement mechanism, allows both multicast and unicast Delay
   Request and Delay Response messages.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 24 January 2025.

Copyright Notice

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

Arnold & Gerstung        Expires 24 January 2025                [Page 1]
Internet-Draft         Enterprise Profile for PTP              July 2024

   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, as 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 are
   provided without warranty as described in the Revised BSD License.

Table of Contents

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

1.  Introduction

   The Precision Time Protocol ("PTP"), standardized in IEEE 1588, has
   been designed in its first version (IEEE 1588-2002) with the goal to
   minimize configuration on the participating nodes.  Network
   communication was based solely on multicast messages, which unlike
   NTP did not require that a receiving node in IEEE 1588-2019
   [IEEE1588] need to know the identity 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 [IEEE1588g] amendment to IEEE 1588-2019 [IEEE1588] .

Arnold & Gerstung        Expires 24 January 2025                [Page 2]
Internet-Draft         Enterprise Profile for PTP              July 2024

   The "Best TimeTransmitter Clock Algorithm" (IEEE 1588-2019 [IEEE1588]
   Subclause 9.3), a mechanism that all participating PTP nodes MUST
   follow, set 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, it 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 the message.

   The third edition of the standard (IEEE 1588-2019) defines PTPv2.1
   and includes the possibility to use unicast communication between the
   PTP nodes in order to overcome the limitation of using multicast
   messages for the bi-directional 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 message that are discarded as irrelevant to the
   receving node can exceded 99% (Estrela and Bonebakker
   [Estrela_and_Bonebakker]).

   PTPv2.1 also includes PTP Profiles (IEEE 1588-2019 [IEEE1588]
   subclause 20.3).  This construct allows 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 IEEE 1588-2019 [IEEE1588] subclause 13.4), defining an optional
   Best TimeTransmitter Clock Algorithm and a few other ways.  PTP has
   its own management protocol (defined in IEEE 1588-2019 [IEEE1588]
   subclause 15.2) but allows a PTP Profile to specify an alternative
   management mechanism, for example NETCONF.

   In this document the term PTP Port refers to a logical access point
   of a PTP instantiation for PTP communincation in a network.

Arnold & Gerstung        Expires 24 January 2025                [Page 3]
Internet-Draft         Enterprise Profile for PTP              July 2024

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 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they
   appear in all capitals, as shown here.

3.  Technical Terms

   *  Acceptable TimeTransmitter Table: A PTP timeReceiver Clock may
      maintain a list of timeTransmitters which it is willing to
      synchronize to.

   *  Alternate timeTransmitter: A PTP timeTransmitter Clock, which is
      not the Best timeTransmitter, may act as a timeTransmitter with
      the Alternate timeTransmitter flag set on the messages it sends.

   *  Announce message: Contains the timeTransmitter Clock properties of
      a timeTransmitter Clock.  Used to determine the Best
      TimeTransmitter.

   *  Best timeTransmitter: A clock with a PTP Port in the
      timeTransmitter state, operating as the Grandmaster of a PTP
      domain.

   *  Best TimeTransmitter Clock Algorithm: A method for determining
      which state a PTP Port of a PTP clock should be in.  The state
      decisions lead to the formation of a clock spanning tree for a PTP
      domain.

   *  Boundary Clock: A device with more than one PTP Port.  Generally
      Boundary Clocks will have one PTP Port in timeReceiver state to
      receive timing and other PTP Ports in timeTransmitter state to re-
      distribute the timing.

   *  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
      derived from the Ethernet MAC address.

   *  Domain: Every PTP message contains a domain number.  Domains are
      treated as separate PTP systems in the network.  Clocks, however,
      can combine the timing information derived from multiple domains.

Arnold & Gerstung        Expires 24 January 2025                [Page 4]
Internet-Draft         Enterprise Profile for PTP              July 2024

   *  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.
      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 timeTransmitter Clock that is currently acting as
      the reference time source of the PTP domain

   *  IEEE 1588: The timing and synchronization standard which defines
      PTP, and describes the node, system, and communication properties
      necessary to support PTP.

   *  TimeTransmitter Clock: a clock with at least one PTP Port in the
      timeTransmitter state.

   *  NTP: Network Time Protocol, defined by RFC 5905, see RFC 5905
      [RFC5905]

   *  Ordinary Clock: A clock that has a single Precision Time Protocol
      PTP Port in a domain and maintains the timescale used in the
      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 measurement mechanism.

   *  Preferred timeTransmitter: A device intended to act primarily as
      the Grandmaster of a PTP system, or as a back up 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.  Note that
      there may be multiple PTP Ports running on one physical interface,
      for example, mulitple unicast timeReceivers which talk 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 options and attribute values of PTP.

Arnold & Gerstung        Expires 24 January 2025                [Page 5]
Internet-Draft         Enterprise Profile for PTP              July 2024

   *  PTPv2.1: Refers specifically to the version of PTP defined by IEEE
      1588-2019.

   *  Rogue timeTransmitter: A clock with a PTP Port in the
      timeTransmitter state, even though it should not be in the
      timeTransmitter state according to the Best TimeTransmitter Clock
      Algorithm, and does not set the Alternate timeTransmitter flag.

   *  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 which cannot become a
      timeTransmitter Clock.

   *  TLV: Type Length Value, a mechanism for extending messages in
      networked communications.

   *  Transparent Clock.  A device that measures the time taken for a
      PTP event message to transit the device and then updates the
      message with a correction for this transit time.

   *  Unicast Discovery: A mechanism for PTP timeReceivers to establish
      a unicast communication with PTP timeTransmitters using a
      configured table of timeTransmitter IP addresses and Unicast
      Message Negotiation.

   *  Unicast Negotiation: A mechanism in PTP for timeReceiver Clocks to
      negotiate unicast Sync, Announce and Delay Request message
      transmission rates from timeTransmitters.

4.  Problem Statement

   This document describes how PTP can be applied to work in large
   enterprise networks.  See ISPCS [RFC2026] for information on IETF
   applicability statements.  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 range
   from 100 microseconds to 1 nanoseconds 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
   a traditional time transfer such as NTP, without adding non-standard

Arnold & Gerstung        Expires 24 January 2025                [Page 6]
Internet-Draft         Enterprise Profile for PTP              July 2024

   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 between 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 desired to make use of
   multicast whenever the information going to many destinations is the
   same.  It is also advantageous to send information which 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 which 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 ISPCS Plugfest ISPCS [ISPCS].

5.  Network Technology

   This PTP Profile MUST operate only in networks characterized by UDP
   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]
   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 which
   communicate using IPv4 can transfer time to PTP Clocks using IPv6, or
   the reverse, if and only if, there is a network node which
   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 be timeTransmitter capable.

   Note that PTP Ports will need to keep tack of the Clock ID of
   received messages and not just the IP or Layer 2 addresses in any
   network that includes Transparent Clocks, or 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

Arnold & Gerstung        Expires 24 January 2025                [Page 7]
Internet-Draft         Enterprise Profile for PTP              July 2024

   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 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 of this
   document.

   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
   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 of 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 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 IEEE 1588 IEEE 1588 [IEEE1588] Annex D, Section D.3.
   These addresses are aloted by IANA, see the Ipv6 Multicast Address
   Space Registry [IPv6Registry]

Arnold & Gerstung        Expires 24 January 2025                [Page 8]
Internet-Draft         Enterprise Profile for PTP              July 2024

   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 which 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.  Redundant sources of timing can be ensembled, and/or
   compared to check for faulty timeTransmitter Clocks.  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 / manipulation attacks.  Assuming
   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 message periods are
   to be negotiated.  Note that negotiated message periods are not
   allowed, see forbidden PTP options (Section 13).

8.  Requirements for TimeTransmitter Clocks

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

Arnold & Gerstung        Expires 24 January 2025                [Page 9]
Internet-Draft         Enterprise Profile for PTP              July 2024

   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 contains 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 which 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 which is
   not the Best TimeTransmitter in its domain.  TimeReceivers will
   continue to recognize a Best TimeTransmitter for the duration of the
   Announce Time Out 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 or one-step timeTransmitter Clocks.  See IEEE 1588
   [IEEE1588], 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, so, 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.

Arnold & Gerstung        Expires 24 January 2025               [Page 10]
Internet-Draft         Enterprise Profile for PTP              July 2024

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 which 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. the IEEE 1588 [IEEE1588] defined attribute
   targetPortIdentity.clockIdentity is not set to All 1s, 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 soley for a specific PTP Node.

13.  Forbidden PTP Options

   Clocks operating in the Enterprise Profile MUST NOT use: Peer-to-Peer
   timing for delay measurement, Grandmaster Clusters, The Alternate
   TimeTransmitter option, Alternate Timescales.  Unicast discovery, or
   unicast 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 IEEE 1588
   [IEEE1588] 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 either of these requirements are not met than
   Enterprise Profile clocks will not interoperate with Annex I.3
   Default Profile Clocks.  The Enterprise Profile will not interoperate
   with the Annex I.4 variant of the Default Profile which requires use

Arnold & Gerstung        Expires 24 January 2025               [Page 11]
Internet-Draft         Enterprise Profile for PTP              July 2024

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

   The authors would like to thank Richard Cochran, Kevin Gross, John
   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
   and has later been converted manually into xml format using an
   xml2rfc template.

17.  IANA Considerations

   There are no IANA requirements in this specification.

18.  Security Considerations

   Protocols used to transfer time, such as PTP and NTP can be important
   to security mechanisms which 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 IEEE 1588-2019 [IEEE1588] that helps with time
   transfer accuracy.  See sections 9 and 10.  Additional security

Arnold & Gerstung        Expires 24 January 2025               [Page 12]
Internet-Draft         Enterprise Profile for PTP              July 2024

   mechanisms are outside the scope of this document.

   PTP native 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 which include security,
   for example NETCONF NETCONF [RFC6241].

   General security considerations of time protocols are discussed in
   RFC 7384 [RFC7384].

19.  References

19.1.  Normative References

   [IEEE1588] Institute of Electrical and Electronics Engineers, "IEEE
              std. 1588-2019, "IEEE Standard for a Precision Clock
              Synchronization for Networked Measurement and Control
              Systems."", November 2019, <https://www.ieee.org>.

   [IEEE1588g]
              Institute of Electrical and Electronics Engineers, "IEEE
              std. 1588g-2022, "IEEE Standard for a Precision Clock
              Synchronization Protocol for Networked Measurement and
              Control Systems Amendment 2: Master-Slave Optional
              Alternative Terminology"", December 2022,
              <https://www.ieee.org>.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              DOI 10.17487/RFC0768, August 1980,
              <https://www.rfc-editor.org/info/rfc768>.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 2119, DOI 10.17487/RFC2119,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

Arnold & Gerstung        Expires 24 January 2025               [Page 13]
Internet-Draft         Enterprise Profile for PTP              July 2024

19.2.  Informative References

   [Estrela_and_Bonebakker]
              Estrela, P. and L. Bonebakker, "Estrela and Bonebakker,
              "Challenges deploying PTPv2 in a global financial
              company"", DOI 10.1109/ISPCS.2012.6336634, 2012,
              <https://www.researchgate.net/publication/260742322_Challe
              nges_deploying_PTPv2_in_a_global_financial_company>.

   [G8271]    International Telecommunication Union, "ITU-T G.8271/
              Y.1366, "Time and Phase Synchronization Aspects of Packet
              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,
              <https://www.ispcs.org>.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", RFC 2026, DOI 10.17487/RFC2026, October 1996,
              <https://www.rfc-editor.org/info/rfc2026>.

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/info/rfc5905>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC7384]  Mizrahi, T., "Security Requirements of Time Protocols in
              Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
              October 2014, <https://www.rfc-editor.org/info/rfc7384>.

Authors' Addresses

   Doug Arnold
   Meinberg-USA
   3 Concord Rd
   Shrewsbury, Massachusetts 01545
   United States of America
   Email: doug.arnold@meinberg-usa.com

Arnold & Gerstung        Expires 24 January 2025               [Page 14]
Internet-Draft         Enterprise Profile for PTP              July 2024

   Heiko Gerstung
   Meinberg
   Lange Wand 9
   31812 Bad Pyrmont
   Germany
   Email: heiko.gerstung@meinberg.de

Arnold & Gerstung        Expires 24 January 2025               [Page 15]