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

TICTOC Working Group                                         D.A. Arnold
Internet-Draft                                              Meinberg-USA
Intended status: Standards Track                           H.G. Gerstung
Expires: 8 October 2022                                         Meinberg
                                                            6 April 2022

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

Abstract

   This document describes a profile for the use of the Precision Time
   Protocol in an IPV4 or IPv6 Enterprise information system
   environment.  The 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 8 October 2022.

Copyright Notice

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

Arnold & Gerstung        Expires 8 October 2022                 [Page 1]
Internet-Draft         Enterprise Profile for PTP             April 2022

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

1.  Introduction

   The Precision Time Protocol ("PTP"), first 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 ("slave clock") in
   IEEE 1588-2019 [IEEE1588] needs to know the identity of the time
   sources in the network (the Master Clocks).  This document describes
   clock roles and port states using the terms master and slave in order
   to correspond to the terms used in IEEE 1588, on which this document
   is based.  There is an active project in the IEEE to select
   alternative terms.  When this project is completed, then master and
   slave will be replaced with the new alternative terms in an update to

Arnold & Gerstung        Expires 8 October 2022                 [Page 2]
Internet-Draft         Enterprise Profile for PTP             April 2022

   this document.

   The "Best Master 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 shall be the active sending time source (Master
   Clock).  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 more than 99% of the received
   multicast messages because they carried information for some other
   node.  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 profile on a PTP
   node will set all the parameters that are specified in the profile to
   a defined value.  If a PTP profile definition allows multiple values
   for a parameter, selection of the 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 profile should
   also define which optional features of PTP are required, permitted,
   or 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 Master 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 specify an alternative management mechanism, for example
   NETCONF.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Arnold & Gerstung        Expires 8 October 2022                 [Page 3]
Internet-Draft         Enterprise Profile for PTP             April 2022

3.  Technical Terms

   *  Acceptable Master Table: A PTP Slave Clock may maintain a list of
      masters which it is willing to synchronize to.

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

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

   *  Best Master: A clock with a port in the master state, operating
      consistently with the Best Master Clock Algorithm.

   *  Best Master Clock Algorithm: A method for determining which state
      a port of a PTP clock should be in.  The algorithm works by
      identifying which of several PTP Master capable clocks is the best
      master.  Clocks have priority to become the acting Grandmaster,
      based on the properties each Master Clock sends in its Announce
      Message.

   *  Boundary Clock: A device with more than one PTP port.  Generally
      boundary Clocks will have one port in slave state to receive
      timing and then other ports in master 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 unique.  Often it is derived from
      the Ethernet MAC address, since there is already an international
      infrastructure for assigning unique numbers to each device
      manufactured.

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

   *  End to End Delay Measurement Mechanism: A network delay
      measurement mechanism in PTP facilitated by an exchange of
      messages between a Master Clock and Slave Clock.

   *  Grandmaster: the primary Master Clock within a domain of a PTP
      system

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

Arnold & Gerstung        Expires 8 October 2022                 [Page 4]
Internet-Draft         Enterprise Profile for PTP             April 2022

   *  Master Clock: a clock with at least one port in the master 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 Master Clock, or be a slave clock.

   *  Peer to Peer Delay Measurement Mechanism: A network delay
      measurement mechanism in PTP facilitated by an exchange of
      messages between adjacent devices in a network.

   *  Preferred Master: 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, a unicast slave which talks to several Grandmaster
      clocks in parallel.

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

   *  Rogue Master: A clock with a port in the master state, even though
      it should not be in the master state according to the Best Master
      Clock Algorithm, and does not set the alternate master flag.

   *  Slave clock: a clock with at least one port in the slave state,
      and no ports in the master state.

   *  Slave Only Clock: An Ordinary Clock which cannot become a Master
      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 slaves to establish a
      unicast communication with PTP masters using a configures table of
      master IP addresses and Unicast Message Negotiation.

Arnold & Gerstung        Expires 8 October 2022                 [Page 5]
Internet-Draft         Enterprise Profile for PTP             April 2022

   *  Unicast Negotiation: A mechanism in PTP for Slave Clocks to
      negotiate unicast Sync, announce and Delay Request Message Rates
      from a Master Clock.

4.  Problem Statement

   This document describes a version of PTP intended to work in large
   enterprise networks.  Such 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 100 nanoseconds to the Grandmaster.  This 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
   customizations such as hardware time stamping, and on path support.
   These features are currently part of PTP, or are allowed by it.
   Because PTP has a complex range of features and options it is
   necessary to create a 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 unique to
   one device as a unicast message.  The latter can be essential as the
   number of PTP slaves 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].

Arnold & Gerstung        Expires 8 October 2022                 [Page 6]
Internet-Draft         Enterprise Profile for PTP             April 2022

5.  Network Technology

   This PTP profile SHALL 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 D and E in IEEE 1588 [IEEE1588]
   respectively.  If a network contains both IPv4 and IPv6, then they
   SHALL be treated as separate communication paths.  Clocks which
   communicate using IPv4 can interact with clocks using IPv6 if there
   is an intermediary device which simultaneously communicates with both
   IP versions.  A Boundary Clock might perform this function, for
   example.  A PTP domain SHALL use either IPv4 or IPv6 over a
   communication path, but not both.  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 Masters, Ordinary Clocks, or Boundary Clocks.  The Ordinary
   Clocks may be Slave Only Clocks, or be master capable.

   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
   since Transparent Clocks are required to change the source address of
   any packet which they alter.  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, like 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 Master to
   the Slave.  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

   Master Clocks, Transparent Clocks and Boundary Clocks MAY be either
   one-step clocks or two-step clocks.  Slave 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 master and slave do not necessarily traverse the
   same physical path.  Thus, wherever possible, the network SHOULD be
   traffic 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.

Arnold & Gerstung        Expires 8 October 2022                 [Page 7]
Internet-Draft         Enterprise Profile for PTP             April 2022

   Sync messages MUST be sent as PTP event multicast messages (UDP port
   319) to the PTP primary IP address.  Two step clocks SHALL send
   Follow-up messages as PTP general 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, see IEEE 1588 [IEEE1588] Annex E, Section E.3.

   Delay Request Messages MAY be sent as either multicast or unicast PTP
   event messages.  Master Clocks SHALL respond to multicast Delay
   Request messages with multicast Delay Response PTP general messages.
   Master Clocks SHALL respond to unicast Delay Request PTP event
   messages with unicast Delay Response PTP general messages.  This
   allow for the use of Ordinary Clocks which do not support the
   Enterprise Profile, if they are slave Only Clocks.

   Clocks SHOULD include support for multiple domains.  The purpose is
   to support multiple simultaneous masters for redundancy.  Leaf
   devices (non-forwarding devices) can use timing information from
   multiple masters by combining information from multiple
   instantiations of a PTP stack, each operating in a different domain.
   Redundant sources of timing can be ensembled, and/or compared to
   check for faulty Master Clocks.  The use of multiple simultaneous
   masters will help mitigate faulty masters reporting as healthy,
   network delay asymmetry, and security problems.  Security problems
   include man-in-the-middle attacks such as delay attacks, packet
   interception / manipulation attacks.  Assuming the path to each
   master 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 SHALL 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
   SHALL NOT be changed from the default value.  The Announce Receipt
   Timeout Interval SHALL be three Announce Intervals for Preferred
   Masters, and four Announce Intervals for all other masters.

   The logMessageInterval carried in the unicast Delay Response message
   MAY be set to correspond to the master 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).

Arnold & Gerstung        Expires 8 October 2022                 [Page 8]
Internet-Draft         Enterprise Profile for PTP             April 2022

8.  Requirements for Master Clocks

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

   A port of a clock SHALL NOT be in the master state unless the clock
   has a current value for the number of UTC leap seconds.

   If a unicast negotiation signaling message is received it SHALL be
   ignored.

9.  Requirements for Slave Clocks

   Slave clocks MUST be able to operate properly in a network which
   contains multiple Masters in multiple domains.  Slaves SHOULD make
   use of information from the all Masters in their clock control
   subsystems.  Slave Clocks MUST be able to operate properly in the
   presence of a Rogue Master.  Slaves SHOULD NOT Synchronize to a
   Master which is not the Best Master in its domain.  Slaves will
   continue to recognize a Best Master for the duration of the Announce
   Time Out Interval.  Slaves MAY use an Acceptable Master Table.  If a
   Master is not an Acceptable Master, then the Slave MUST NOT
   synchronize to it.  Note that IEEE 1588-2019 requires slave clocks to
   support both two-step or one-step Master clocks.  See IEEE 1588
   [IEEE1588], subClause 11.2.

   Since Announce messages are sent as multicast messages slaves can
   obtain the IP addresses of a master from the Announce messages.  Note
   that the IP source addresses of Sync and Follow-up messages may have
   been replaced by the source addresses of a Transparent Clock, so,
   slaves 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 profile.

10.  Requirements for Transparent Clocks

   Transparent Clocks SHALL NOT change the transmission mode of an
   Enterprise Profile PTP message.  For example, a Transparent Clock
   SHALL NOT change a unicast message to a multicast message.
   Transparent Clocks SHOULD support multiple domains.  Transparent
   Clocks which syntonize to the master clock will need to maintain
   separate clock rate offsets for each of the supported domains.

Arnold & Gerstung        Expires 8 October 2022                 [Page 9]
Internet-Draft         Enterprise Profile for PTP             April 2022

11.  Requirements for Boundary Clocks

   Boundary Clocks SHOULD support multiple simultaneous PTP domains.
   This will require them to maintain servo loops 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 for a specific clock.

13.  Forbidden PTP Options

   Clocks operating in the Enterprise Profile SHALL NOT use peer to peer
   timing for delay measurement.  Grandmaster Clusters are NOT ALLOWED.
   The Alternate Master option is also NOT ALLOWED.  Clocks operating in
   the Enterprise Profile SHALL NOT use Alternate Timescales.  Unicast
   discovery and unicast negotiation SHALL NOT be used.

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 J.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 J.3
   Default Profile Clocks.  The Enterprise Profile will not interoperate
   with the Annex J.4 variant of the Default Profile which requires use
   of the Peer to Peer Delay Measurement Mechanism.

   Enterprise Profile Clocks will interoperate with clocks operating in
   other profiles if the clocks in the other profiles obey the rules of
   the Enterprise Profile.  These rules MUST NOT be changed to achieve
   interoperability with other profiles.

15.  Profile Identification

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

Arnold & Gerstung        Expires 8 October 2022                [Page 10]
Internet-Draft         Enterprise Profile for PTP             April 2022

             PTP Profile:
             Enterprise Profile
             Version: 1.0
             Profile identifier: 00-00-5E-00-01-00

             This 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 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 masters, using multiple PTP domains can mitigate
   problems from rogue masters and man-in-the-middle attacks.  See
   sections 9 and 10.  Additional security 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

Arnold & Gerstung        Expires 8 October 2022                [Page 11]
Internet-Draft         Enterprise Profile for PTP             April 2022

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

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

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

19.2.  Informative References

   [G8271]    International Telecommunication Union, "ITU-T G.8271/
              Y.1366, "Time and Phase Synchronization Aspects of Packet
              Networks"", February 2012, <https://www.itu.int>.

   [ISPCS]    Arnold, D.A., "Plugfest Report", October 2017,
              <https://www.ispcs.org>.

   [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

Arnold & Gerstung        Expires 8 October 2022                [Page 12]
Internet-Draft         Enterprise Profile for PTP             April 2022

   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

Arnold & Gerstung        Expires 8 October 2022                [Page 13]