<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" docName="draft-ietf-tictoc-ptp-enterprise-profile-28" number="9760" consensus="true" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" prepTime="2025-05-23T15:01:57" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-enterprise-profile-28" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9760" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Enterprise Profile for PTP">Enterprise Profile for the Precision Time Protocol with Mixed Multicast and Unicast Messages</title>
    <seriesInfo name="RFC" value="9760" stream="IETF"/>
    <author fullname="Doug Arnold" initials="D." surname="Arnold">
      <organization showOnFrontPage="true">Meinberg-USA</organization>
      <address>
        <postal>
          <street>3 Concord Rd</street>
          <city>Shrewsbury</city>
          <region>Massachusetts</region>
          <code>01545</code>
          <country>United States of America</country>
        </postal>
        <email>doug.arnold@meinberg-usa.com</email>
      </address>
    </author>
    <author fullname="Heiko Gerstung" initials="H." surname="Gerstung">
      <organization showOnFrontPage="true">Meinberg</organization>
      <address>
        <postal>
          <street>Lange Wand 9</street>
          <city>Bad Pyrmont</city>
          <code>31812</code>
          <country>Germany</country>
        </postal>
        <email>heiko.gerstung@meinberg.de</email>
      </address>
    </author>
    <date month="05" year="2025"/>
    <area>INT</area>
    <workgroup>tictoc</workgroup>
    <keyword>PTP</keyword>
    <keyword>Enterprise Profile</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">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.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9760" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-technical-terms">Technical Terms</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-problem-statement">Problem Statement</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-network-technology">Network Technology</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-time-transfer-and-delay-mea">Time Transfer and Delay Measurement</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-default-message-rates">Default Message Rates</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-for-timetransm">Requirements for TimeTransmitter Clocks</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-for-timereceiv">Requirements for TimeReceiver Clocks</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-for-transparen">Requirements for Transparent Clocks</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-for-boundary-c">Requirements for Boundary Clocks</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-management-and-signaling-me">Management and Signaling Messages</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" format="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-forbidden-ptp-options">Forbidden PTP Options</xref></t>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="14" format="counter" sectionFormat="of" target="section-14"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-interoperation-with-ieee-15">Interoperation with IEEE 1588 Default Profile</xref></t>
          </li>
          <li pn="section-toc.1-1.15">
            <t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="15" format="counter" sectionFormat="of" target="section-15"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-profile-identification">Profile Identification</xref></t>
          </li>
          <li pn="section-toc.1-1.16">
            <t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="16" format="counter" sectionFormat="of" target="section-16"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.17">
            <t indent="0" pn="section-toc.1-1.17.1"><xref derivedContent="17" format="counter" sectionFormat="of" target="section-17"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.18">
            <t indent="0" pn="section-toc.1-1.18.1"><xref derivedContent="18" format="counter" sectionFormat="of" target="section-18"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.18.2">
              <li pn="section-toc.1-1.18.2.1">
                <t indent="0" pn="section-toc.1-1.18.2.1.1"><xref derivedContent="18.1" format="counter" sectionFormat="of" target="section-18.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.18.2.2">
                <t indent="0" pn="section-toc.1-1.18.2.2.1"><xref derivedContent="18.2" format="counter" sectionFormat="of" target="section-18.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.19">
            <t indent="0" pn="section-toc.1-1.19.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.20">
            <t indent="0" pn="section-toc.1-1.20.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">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 <xref target="IEEE1588-2019" format="default" sectionFormat="of" derivedContent="IEEE1588-2019">IEEE 1588-2019</xref> 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
      <xref target="IEEE1588g" format="default" sectionFormat="of" derivedContent="IEEE1588g">IEEE 1588g amendment</xref> to
      <xref target="IEEE1588-2019" format="default" sectionFormat="of" derivedContent="IEEE1588-2019"/>.</t>
      <t indent="0" pn="section-1-2">The "Best TimeTransmitter Clock Algorithm" (<xref target="IEEE1588-2019" format="default" sectionFormat="of" derivedContent="IEEE1588-2019"/>, Subclause 9.3), a mechanism that
      all participating PTP Nodes <bcp14>MUST</bcp14> follow, sets up strict rules for all
      members of a PTP domain to determine which node <bcp14>MUST</bcp14> 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.</t>
      <t indent="0" pn="section-1-3">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% 
     <xref target="Estrela_and_Bonebakker" format="default" sectionFormat="of" derivedContent="Estrela_and_Bonebakker"/>.</t>
      <t indent="0" pn="section-1-4">PTPv2.1 also includes PTP Profiles (<xref target="IEEE1588-2019" format="default" sectionFormat="of" derivedContent="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 <xref target="IEEE1588-2019" format="default" sectionFormat="of" derivedContent="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
     <xref target="IEEE1588-2019" format="default" sectionFormat="of" derivedContent="IEEE1588-2019"/>, Subclause 15.2) but
     allows a PTP Profile to specify an alternative management mechanism --
     for example, the Network Configuration Protocol (NETCONF).</t>
      <t indent="0" pn="section-1-5"> In this document, the term "PTP Port" refers to a logical access point of a PTP instantiation for PTP communication in a network.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-requirements-language">Requirements Language</name>
      <t indent="0" pn="section-2-1">The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
       "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
       "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
       "<bcp14>SHOULD NOT</bcp14>",
       "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
       "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP 14
       <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>
    </section>
    <section anchor="technical_terms" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-technical-terms">Technical Terms</name>
      <dl spacing="normal" newline="false" indent="3" pn="section-3-1">
        <dt pn="section-3-1.1">Acceptable TimeTransmitter Table:</dt>
        <dd pn="section-3-1.2">A list of timeTransmitters that
may be maintained by a PTP timeReceiver Clock.  The PTP timeReceiver Clock would be willing to synchronize to timeTransmitters in this list.</dd>
        <dt pn="section-3-1.3">Alternate timeTransmitter:</dt>
        <dd pn="section-3-1.4">A PTP timeTransmitter Clock that is not the Best
          timeTransmitter and therefore is used as an alternative clock. It may act as a timeTransmitter with the Alternate timeTransmitter flag set on
          the messages it sends.</dd>
        <dt pn="section-3-1.5">Announce message:</dt>
        <dd pn="section-3-1.6">Contains the properties of a given timeTransmitter Clock. The information is used to determine the Best timeTransmitter.</dd>
        <dt pn="section-3-1.7">Best timeTransmitter:</dt>
        <dd pn="section-3-1.8">A clock with a PTP Port in the timeTransmitter state, operating
          as the Grandmaster of a PTP domain.</dd>
        <dt pn="section-3-1.9">Best TimeTransmitter Clock Algorithm:</dt>
        <dd pn="section-3-1.10">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.</dd>
        <dt pn="section-3-1.11">Boundary Clock:</dt>
        <dd pn="section-3-1.12">A device with more than one PTP Port.  Generally,
          Boundary Clocks will have one PTP Port in the timeReceiver state to receive
          timing and other PTP Ports in the timeTransmitter state to redistribute the
          timing.</dd>
        <dt pn="section-3-1.13">Clock Identity:</dt>
        <dd pn="section-3-1.14">In <xref target="IEEE1588-2019" format="default" sectionFormat="of" derivedContent="IEEE1588-2019"/>, a 64-bit number
          assigned to each PTP clock.  This number <bcp14>MUST</bcp14> be globally unique. Often, it is
          derived from the Ethernet Media Access Control (MAC) address.</dd>
        <dt pn="section-3-1.15">Domain:</dt>
        <dd pn="section-3-1.16">Treated as a separate PTP system in a network. Every PTP message contains a domain number. Clocks, however,
          can combine the timing information derived from multiple domains.</dd>
        <dt pn="section-3-1.17">End-to-End delay measurement mechanism:</dt>
        <dd pn="section-3-1.18">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.</dd>
        <dt pn="section-3-1.19">Grandmaster:</dt>
        <dd pn="section-3-1.20">The timeTransmitter Clock that is currently acting as the reference time source of the PTP domain.</dd>
        <dt pn="section-3-1.21">IEEE 1588:</dt>
        <dd pn="section-3-1.22">The timing and synchronization standard that defines
          PTP and describes the node, system, and communication properties
          necessary to support PTP.</dd>
        <dt pn="section-3-1.23">NTP:</dt>
        <dd pn="section-3-1.24">Network Time Protocol, defined by <xref target="RFC5905" format="default" sectionFormat="of" derivedContent="RFC5905"/>.</dd>
        <dt pn="section-3-1.25">Ordinary Clock:</dt>
        <dd pn="section-3-1.26">A clock that has a single
          PTP Port in a domain and maintains the timescale used in the
          domain. It may serve as a timeTransmitter Clock or may be a timeReceiver Clock.</dd>
        <dt pn="section-3-1.27">Peer-to-Peer delay measurement mechanism:</dt>
        <dd pn="section-3-1.28">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.</dd>
        <dt pn="section-3-1.29">Preferred timeTransmitter:</dt>
        <dd pn="section-3-1.30">A device intended to act primarily as the
          Grandmaster of a PTP system or as a backup to a Grandmaster.</dd>
        <dt pn="section-3-1.31">PTP:</dt>
        <dd pn="section-3-1.32">The Precision Time Protocol -- the timing and synchronization
          protocol defined by IEEE 1588.</dd>
        <dt pn="section-3-1.33">PTP Port:</dt>
        <dd pn="section-3-1.34">An interface of a PTP clock with the network.  Note that
          there may be multiple PTP Ports running on one physical interface --
          for example, multiple unicast timeReceivers that talk to several Grandmaster
          Clocks in different PTP domains.</dd>
        <dt pn="section-3-1.35">PTP Profile:</dt>
        <dd pn="section-3-1.36">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.</dd>
        <dt pn="section-3-1.37">PTPv2.1:</dt>
        <dd pn="section-3-1.38">Refers specifically to the version of PTP defined by
          <xref target="IEEE1588-2019" format="default" sectionFormat="of" derivedContent="IEEE1588-2019"/>.</dd>
        <dt pn="section-3-1.39">Rogue timeTransmitter:</dt>
        <dd pn="section-3-1.40">A clock that has 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 that does not set the Alternate timeTransmitter flag.</dd>
        <dt pn="section-3-1.41">TimeReceiver Clock:</dt>
        <dd pn="section-3-1.42">A clock with at least one PTP Port in the timeReceiver state
          and no PTP Ports in the timeTransmitter state.</dd>
        <dt pn="section-3-1.43">TimeReceiver Only Clock:</dt>
        <dd pn="section-3-1.44">An Ordinary Clock that cannot become a timeTransmitter
          Clock.</dd>
        <dt pn="section-3-1.45">TimeTransmitter Clock:</dt>
        <dd pn="section-3-1.46">A clock with at least one PTP Port in the timeTransmitter state.</dd>
        <dt pn="section-3-1.47">TLV:</dt>
        <dd pn="section-3-1.48">Type Length Value -- a mechanism for extending messages in
          networked communications.</dd>
        <dt pn="section-3-1.49">Transparent Clock:</dt>
        <dd pn="section-3-1.50">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.</dd>
        <dt pn="section-3-1.51">Unicast discovery:</dt>
        <dd pn="section-3-1.52">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.</dd>
        <dt pn="section-3-1.53">Unicast message negotiation:</dt>
        <dd pn="section-3-1.54">A mechanism in PTP for timeReceiver Clocks to
          negotiate unicast Sync, Announce, and Delay Request message transmission rates
          from timeTransmitters.</dd>
      </dl>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-problem-statement">Problem Statement</name>
      <t indent="0" pn="section-4-1">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.</t>
      <t indent="0" pn="section-4-2">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.</t>
      <t indent="0" pn="section-4-3">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.</t>
      <t indent="0" pn="section-4-4">Interoperability among independent implementations of this PTP
      Profile has been demonstrated at the <xref target="ISPCS" format="default" sectionFormat="of" derivedContent="ISPCS">International Symposium on Precision Clock Synchronization (ISPCS) Plugfest</xref>.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-network-technology">Network Technology</name>
      <t indent="0" pn="section-5-1">This PTP Profile <bcp14>MUST</bcp14> operate only in networks characterized by
      UDP <xref target="RFC0768" format="default" sectionFormat="of" derivedContent="RFC0768"/> over either IPv4 
      <xref target="RFC0791" format="default" sectionFormat="of" derivedContent="RFC0791"/> or IPv6 <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/>,
      as described by Annexes C and D of <xref target="IEEE1588-2019" format="default" sectionFormat="of" derivedContent="IEEE1588-2019"/>, respectively.  
      A network node <bcp14>MAY</bcp14> include multiple PTP instances running simultaneously. 
      IPv4 and IPv6 instances in the same network node <bcp14>MUST</bcp14> 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.</t>
      <t indent="0" pn="section-5-2"> The PTP system <bcp14>MAY</bcp14> include switches and routers.
      These devices <bcp14>MAY</bcp14> be Transparent Clocks, Boundary Clocks, or
      neither, in any combination.  PTP clocks <bcp14>MAY</bcp14> be Preferred timeTransmitters,
      Ordinary Clocks, or Boundary Clocks.  The Ordinary Clocks may be
      timeReceiver Only Clocks or may be timeTransmitter capable.</t>
      <t indent="0" pn="section-5-3">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.</t>
      <t indent="0" pn="section-5-4">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, <xref target="G8271" format="default" sectionFormat="of" derivedContent="G8271">ITU-T G.8271</xref>.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-time-transfer-and-delay-mea">Time Transfer and Delay Measurement</name>
      <t indent="0" pn="section-6-1">TimeTransmitter Clocks, Transparent Clocks, and Boundary Clocks <bcp14>MAY</bcp14> be
    either one-step clocks or two-step clocks.  TimeReceiver Clocks <bcp14>MUST</bcp14>
    support both behaviors. The End-to-End delay measurement method
    <bcp14>MUST</bcp14> be used.</t>
      <t indent="0" pn="section-6-2">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 <bcp14>SHOULD</bcp14> 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.</t>
      <t indent="0" pn="section-6-3">Sync messages <bcp14>MUST</bcp14> be sent as PTP event multicast messages (UDP
    port 319) to the PTP primary IP address.   Two-step clocks <bcp14>MUST</bcp14>
    send Follow-up messages as PTP general multicast messages (UDP port 320).
    Announce messages <bcp14>MUST</bcp14> 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 
    <xref target="IEEE1588-2019" format="default" sectionFormat="of" derivedContent="IEEE1588-2019"/>, Annex D, Section D.3.  
    These addresses are allotted by IANA; see the <xref target="IPv6Registry" format="default" sectionFormat="of" derivedContent="IPv6Registry">"IPv6 Multicast Address Space Registry"</xref>.</t>
      <t indent="0" pn="section-6-4">Delay Request messages <bcp14>MAY</bcp14> be sent as either multicast or unicast
    PTP event messages. TimeTransmitter Clocks <bcp14>MUST</bcp14> respond to multicast Delay
    Request messages with multicast Delay Response PTP general
    messages. TimeTransmitter Clocks <bcp14>MUST</bcp14> 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.</t>
      <t indent="0" pn="section-6-5">Clocks <bcp14>SHOULD</bcp14> 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 <bcp14>SHOULD</bcp14> be
    configured so that timing messages in different domains traverse
    different network paths.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-default-message-rates">Default Message Rates</name>
      <t indent="0" pn="section-7-1">The Sync, Announce, and Delay Request default message rates <bcp14>MUST</bcp14>
    each be once per second.  The Sync and Delay Request message rates
    <bcp14>MAY</bcp14> 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 <bcp14>MUST NOT</bcp14> be changed from the default value.  The
    Announce Receipt Timeout Interval <bcp14>MUST</bcp14> be three Announce
    Intervals for Preferred timeTransmitters and four Announce Intervals for
    all other timeTransmitters.</t>
      <t indent="0" pn="section-7-2">The logMessageInterval carried in the unicast Delay Response
    message <bcp14>MAY</bcp14> 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 <xref target="forbidden_ptp_options" format="default" sectionFormat="of" derivedContent="Section 13"/> ("<xref target="forbidden_ptp_options" format="title" sectionFormat="of" derivedContent="Forbidden PTP Options"/>").</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-requirements-for-timetransm">Requirements for TimeTransmitter Clocks</name>
      <t indent="0" pn="section-8-1">TimeTransmitter Clocks <bcp14>MUST</bcp14> obey the standard Best TimeTransmitter Clock Algorithm
    as defined in <xref target="IEEE1588-2019" format="default" sectionFormat="of" derivedContent="IEEE1588-2019"/>.  PTP systems using this PTP Profile <bcp14>MAY</bcp14> support
    multiple simultaneous Grandmasters if each active Grandmaster is
    operating in a different PTP domain.</t>
      <t indent="0" pn="section-8-2">A PTP Port of a clock <bcp14>MUST NOT</bcp14> be in the timeTransmitter state unless the
    clock has a current value for the number of UTC leap
    seconds.</t>
      <t indent="0" pn="section-8-3">If a unicast negotiation signaling message is received, it <bcp14>MUST</bcp14>
    be ignored.</t>
      <t indent="0" pn="section-8-4">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.</t>
    </section>
    <section numbered="true" toc="include" anchor="req-timereceiver-clocks" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-requirements-for-timereceiv">Requirements for TimeReceiver Clocks</name>
      <t indent="0" pn="section-9-1">In a network that contains multiple timeTransmitters in multiple domains,
    timeReceivers <bcp14>SHOULD</bcp14> make use of information from all the timeTransmitters in their clock control subsystems.
    TimeReceiver Clocks <bcp14>MUST</bcp14> be able to function in such networks even if they use time from only one of the domains.
    TimeReceiver Clocks <bcp14>MUST</bcp14> be able to operate properly in the
    presence of a rogue timeTransmitter. TimeReceivers <bcp14>SHOULD NOT</bcp14> 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 <bcp14>MAY</bcp14> use an Acceptable TimeTransmitter
    Table.  If a timeTransmitter is not an Acceptable timeTransmitter, then the timeReceiver
    <bcp14>MUST NOT</bcp14> synchronize to it. Note that IEEE 1588-2019 requires
    timeReceiver Clocks to support both two-step and one-step timeTransmitter Clocks.
    See <xref target="IEEE1588-2019" format="default" sectionFormat="of" derivedContent="IEEE1588-2019"/>, Subclause 11.2.</t>
      <t indent="0" pn="section-9-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 <bcp14>MUST</bcp14> 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.</t>
    </section>
    <section numbered="true" toc="include" anchor="req-transparent-clocks" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-requirements-for-transparen">Requirements for Transparent Clocks</name>
      <t indent="0" pn="section-10-1">Transparent Clocks <bcp14>MUST NOT</bcp14> change the transmission mode of an
    Enterprise Profile PTP message.  For example, a Transparent Clock
    <bcp14>MUST NOT</bcp14> 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.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-11">
      <name slugifiedName="name-requirements-for-boundary-c">Requirements for Boundary Clocks</name>
      <t indent="0" pn="section-11-1">Boundary Clocks <bcp14>SHOULD</bcp14> 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 <bcp14>MUST NOT</bcp14>
    combine timing information from different domains.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-12">
      <name slugifiedName="name-management-and-signaling-me">Management and Signaling Messages</name>
      <t indent="0" pn="section-12-1">PTP management messages <bcp14>MAY</bcp14> be used.  Management
    messages intended for a specific clock, i.e., where the targetPortIdentity.clockIdentity attribute (defined in <xref target="IEEE1588-2019" format="default" sectionFormat="of" derivedContent="IEEE1588-2019"/>) does not have all bits set to 1,
    <bcp14>MUST</bcp14> be sent as a unicast message.  Similarly, if any signaling
    messages are used, they <bcp14>MUST</bcp14> also be sent as unicast messages
    whenever the message is intended solely for a specific PTP Node.</t>
    </section>
    <section anchor="forbidden_ptp_options" numbered="true" toc="include" removeInRFC="false" pn="section-13">
      <name slugifiedName="name-forbidden-ptp-options">Forbidden PTP Options</name>
      <t indent="0" pn="section-13-1">Clocks operating in the Enterprise Profile <bcp14>MUST NOT</bcp14> use the following:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-13-2">
        <li pn="section-13-2.1">Peer-to-Peer timing for delay measurement</li>
        <li pn="section-13-2.2">Grandmaster Clusters</li>
        <li pn="section-13-2.3">The Alternate timeTransmitter option</li>
        <li pn="section-13-2.4">Alternate Timescales</li>
        <li pn="section-13-2.5">Unicast discovery</li>
        <li pn="section-13-2.6">Unicast message negotiation</li>
      </ul>
      <t indent="0" pn="section-13-3">Clocks operating in the Enterprise Profile <bcp14>MUST</bcp14> 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.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-14">
      <name slugifiedName="name-interoperation-with-ieee-15">Interoperation with IEEE 1588 Default Profile</name>
      <t indent="0" pn="section-14-1">Clocks operating in the Enterprise Profile will interoperate with
    clocks operating in the Default Profile described in <xref target="IEEE1588-2019" format="default" sectionFormat="of" derivedContent="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 <xref target="IEEE1588-2019" format="default" sectionFormat="of" derivedContent="IEEE1588-2019"/>, Annex I.3.  The Enterprise Profile will not
    interoperate with the variant of the Default Profile defined in
    <xref target="IEEE1588-2019" format="default" sectionFormat="of" derivedContent="IEEE1588-2019"/>, Annex I.4,
    which requires the use of the Peer-to-Peer delay measurement mechanism.</t>
      <t indent="0" pn="section-14-2">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 <bcp14>MUST NOT</bcp14> be changed
    to achieve interoperability with other PTP Profiles.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-15">
      <name slugifiedName="name-profile-identification">Profile Identification</name>
      <t indent="0" pn="section-15-1">The IEEE 1588 standard requires that all PTP Profiles provide the
        following identifying information.</t>
      <dl newline="false" spacing="compact" indent="3" pn="section-15-2">
        <dt pn="section-15-2.1">PTP Profile:</dt>
        <dd pn="section-15-2.2">Enterprise Profile</dd>
        <dt pn="section-15-2.3">Profile number:</dt>
        <dd pn="section-15-2.4">1</dd>
        <dt pn="section-15-2.5">Version:</dt>
        <dd pn="section-15-2.6">1.0</dd>
        <dt pn="section-15-2.7">Profile identifier:</dt>
        <dd pn="section-15-2.8">00-00-5E-01-01-00</dd>
      </dl>
      <t indent="0" pn="section-15-3">This PTP Profile was specified by the IETF.</t>
      <t indent="0" pn="section-15-4">A copy may be obtained at
        <eref target="https://datatracker.ietf.org/wg/tictoc/documents" brackets="angle"/>.</t>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-16">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-16-1">This document has no IANA actions.</t>
    </section>
    <section anchor="Security" numbered="true" toc="include" removeInRFC="false" pn="section-17">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-17-1">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 <xref target="IEEE1588-2019" format="default" sectionFormat="of" derivedContent="IEEE1588-2019"/> 
       that helps with time transfer accuracy. See Sections <xref target="req-timereceiver-clocks" format="counter" sectionFormat="of" derivedContent="9"/> and <xref target="req-transparent-clocks" format="counter" sectionFormat="of" derivedContent="10"/>. Additional
       security mechanisms are outside the scope of this document.</t>
      <t indent="0" pn="section-17-2">PTP management messages <bcp14>SHOULD NOT</bcp14> 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, <xref target="RFC6241" format="default" sectionFormat="of" derivedContent="RFC6241">NETCONF</xref>.</t>
      <t indent="0" pn="section-17-3">General security considerations related to time protocols are discussed in
       <xref target="RFC7384" format="default" sectionFormat="of" derivedContent="RFC7384"/>.</t>
    </section>
  </middle>
  <back>
    <references pn="section-18">
      <name slugifiedName="name-references">References</name>
      <references pn="section-18.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="IEEE1588-2019" target="https://ieeexplore.ieee.org/document/9120376" quoteTitle="true" derivedAnchor="IEEE1588-2019">
          <front>
            <title>IEEE Standard for a Precision Clock Synchronization for Networked Measurement and Control Systems</title>
            <author>
              <organization showOnFrontPage="true">IEEE</organization>
            </author>
            <date month="June" year="2020"/>
          </front>
          <seriesInfo name="IEEE Std" value="1588-2019"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9120376"/>
        </reference>
        <reference anchor="IEEE1588g" target="https://ieeexplore.ieee.org/document/10070440" quoteTitle="true" derivedAnchor="IEEE1588g">
          <front>
            <title>IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Amendment 2: Master-Slave Optional Alternative Terminology</title>
            <author>
              <organization showOnFrontPage="true">IEEE</organization>
            </author>
            <date month="March" year="2023"/>
          </front>
          <seriesInfo name="IEEE Std" value="1588g-2022"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2023.10070440"/>
        </reference>
        <reference anchor="RFC0768" target="https://www.rfc-editor.org/info/rfc768" quoteTitle="true" derivedAnchor="RFC0768">
          <front>
            <title>User Datagram Protocol</title>
            <author fullname="J. Postel" initials="J." surname="Postel"/>
            <date month="August" year="1980"/>
          </front>
          <seriesInfo name="STD" value="6"/>
          <seriesInfo name="RFC" value="768"/>
          <seriesInfo name="DOI" value="10.17487/RFC0768"/>
        </reference>
        <reference anchor="RFC0791" target="https://www.rfc-editor.org/info/rfc791" quoteTitle="true" derivedAnchor="RFC0791">
          <front>
            <title>Internet Protocol</title>
            <author fullname="J. Postel" initials="J." surname="Postel"/>
            <date month="September" year="1981"/>
          </front>
          <seriesInfo name="STD" value="5"/>
          <seriesInfo name="RFC" value="791"/>
          <seriesInfo name="DOI" value="10.17487/RFC0791"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8200" target="https://www.rfc-editor.org/info/rfc8200" quoteTitle="true" derivedAnchor="RFC8200">
          <front>
            <title>Internet Protocol, Version 6 (IPv6) Specification</title>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <author fullname="R. Hinden" initials="R." surname="Hinden"/>
            <date month="July" year="2017"/>
            <abstract>
              <t indent="0">This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="86"/>
          <seriesInfo name="RFC" value="8200"/>
          <seriesInfo name="DOI" value="10.17487/RFC8200"/>
        </reference>
      </references>
      <references pn="section-18.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="Estrela_and_Bonebakker" target="https://www.researchgate.net/publication/260742322_Challenges_deploying_PTPv2_in_a_global_financial_company" quoteTitle="true" derivedAnchor="Estrela_and_Bonebakker">
          <front>
            <title>Challenges deploying PTPv2 in a global financial company</title>
            <author initials="P." surname="Estrela" fullname="P. V. Estrela"/>
            <author initials="L." surname="Bonebakker" fullname="L. Bonebakker"/>
            <date month="September" year="2012"/>
          </front>
          <refcontent>Proceedings of the IEEE International Symposium on Precision Clock Synchronization for Measurement, Control and Communication, pp. 1-6</refcontent>
          <seriesInfo name="DOI" value="10.1109/ISPCS.2012.6336634"/>
        </reference>
        <reference anchor="G8271" target="https://www.itu.int/rec/T-REC-G.8271-202003-I/en" quoteTitle="true" derivedAnchor="G8271">
          <front>
            <title>Time and phase synchronization aspects of telecommunication networks</title>
            <author>
              <organization showOnFrontPage="true">ITU-T</organization>
            </author>
            <date month="March" year="2020"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="G.8271/Y.1366"/>
        </reference>
        <reference anchor="IPv6Registry" target="https://iana.org/assignments/ipv6-multicast-addresses" quoteTitle="true" derivedAnchor="IPv6Registry">
          <front>
            <title>IPv6 Multicast Address Space Registry</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="ISPCS" target="https://2017.ispcs.org/plugfest" quoteTitle="true" derivedAnchor="ISPCS">
          <front>
            <title>Plugfest</title>
            <author surname="Arnold" initials="D.">
              <organization showOnFrontPage="true">International Symposium on Precision Clock Synchronization for Measurement, Control and Communications</organization>
            </author>
            <author surname="Harris" initials="K.">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="August" year="2017"/>
          </front>
          <refcontent>Proceedings of the IEEE International Symposium on Precision Clock Synchronization for Measurement, Control, and Communication (ISPCS)</refcontent>
        </reference>
        <reference anchor="RFC5905" target="https://www.rfc-editor.org/info/rfc5905" quoteTitle="true" derivedAnchor="RFC5905">
          <front>
            <title>Network Time Protocol Version 4: Protocol and Algorithms Specification</title>
            <author fullname="D. Mills" initials="D." surname="Mills"/>
            <author fullname="J. Martin" initials="J." role="editor" surname="Martin"/>
            <author fullname="J. Burbank" initials="J." surname="Burbank"/>
            <author fullname="W. Kasch" initials="W." surname="Kasch"/>
            <date month="June" year="2010"/>
            <abstract>
              <t indent="0">The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5905"/>
          <seriesInfo name="DOI" value="10.17487/RFC5905"/>
        </reference>
        <reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6241" quoteTitle="true" derivedAnchor="RFC6241">
          <front>
            <title>Network Configuration Protocol (NETCONF)</title>
            <author fullname="R. Enns" initials="R." role="editor" surname="Enns"/>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>
            <author fullname="A. Bierman" initials="A." role="editor" surname="Bierman"/>
            <date month="June" year="2011"/>
            <abstract>
              <t indent="0">The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6241"/>
          <seriesInfo name="DOI" value="10.17487/RFC6241"/>
        </reference>
        <reference anchor="RFC7384" target="https://www.rfc-editor.org/info/rfc7384" quoteTitle="true" derivedAnchor="RFC7384">
          <front>
            <title>Security Requirements of Time Protocols in Packet Switched Networks</title>
            <author fullname="T. Mizrahi" initials="T." surname="Mizrahi"/>
            <date month="October" year="2014"/>
            <abstract>
              <t indent="0">As time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP). This document also discusses the security impacts of time protocol practices, the performance implications of external security practices on time protocols, and the dependencies between other security services and time synchronization.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7384"/>
          <seriesInfo name="DOI" value="10.17487/RFC7384"/>
        </reference>
      </references>
    </references>
    <section anchor="Acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The authors would like to thank <contact fullname="Richard       Cochran"/>, <contact fullname="Kevin Gross"/>, <contact fullname="John       Fletcher"/>, <contact fullname="Laurent Montini"/>, and many other
      members of the IETF for reviewing and providing feedback on this document.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Doug Arnold" initials="D." surname="Arnold">
        <organization showOnFrontPage="true">Meinberg-USA</organization>
        <address>
          <postal>
            <street>3 Concord Rd</street>
            <city>Shrewsbury</city>
            <region>Massachusetts</region>
            <code>01545</code>
            <country>United States of America</country>
          </postal>
          <email>doug.arnold@meinberg-usa.com</email>
        </address>
      </author>
      <author fullname="Heiko Gerstung" initials="H." surname="Gerstung">
        <organization showOnFrontPage="true">Meinberg</organization>
        <address>
          <postal>
            <street>Lange Wand 9</street>
            <city>Bad Pyrmont</city>
            <code>31812</code>
            <country>Germany</country>
          </postal>
          <email>heiko.gerstung@meinberg.de</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
