rfc9760.original   rfc9760.txt 
TICTOC Working Group D.A. Arnold Internet Engineering Task Force (IETF) D. Arnold
Internet-Draft Meinberg-USA Request for Comments: 9760 Meinberg-USA
Intended status: Standards Track H.G. Gerstung Category: Standards Track H. Gerstung
Expires: 24 January 2025 Meinberg ISSN: 2070-1721 Meinberg
23 July 2024 April 2025
Enterprise Profile for the Precision Time Protocol With Mixed Multicast Enterprise Profile for the Precision Time Protocol with Mixed Multicast
and Unicast messages and Unicast Messages
draft-ietf-tictoc-ptp-enterprise-profile-28
Abstract Abstract
This document describes a Precision Time Protocol (PTP) Profile This document describes a Precision Time Protocol (PTP) Profile (IEEE
IEEE 1588-2019 [IEEE1588] for use in an IPv4 or IPv6 Enterprise Standard 1588-2019) for use in an IPv4 or IPv6 enterprise information
information system environment. The PTP Profile uses the End-to-End system environment. The PTP Profile uses the End-to-End delay
delay measurement mechanism, allows both multicast and unicast Delay measurement mechanism, allowing both multicast and unicast Delay
Request and Delay Response messages. Request and Delay Response messages.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 24 January 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9760.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language
3. Technical Terms . . . . . . . . . . . . . . . . . . . . . . . 4 3. Technical Terms
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 4. Problem Statement
5. Network Technology . . . . . . . . . . . . . . . . . . . . . 7 5. Network Technology
6. Time Transfer and Delay Measurement . . . . . . . . . . . . . 8 6. Time Transfer and Delay Measurement
7. Default Message Rates . . . . . . . . . . . . . . . . . . . . 9 7. Default Message Rates
8. Requirements for TimeTransmitter Clocks . . . . . . . . . . . 9 8. Requirements for TimeTransmitter Clocks
9. Requirements for TimeReceiver Clocks . . . . . . . . . . . . 10 9. Requirements for TimeReceiver Clocks
10. Requirements for Transparent Clocks . . . . . . . . . . . . . 11 10. Requirements for Transparent Clocks
11. Requirements for Boundary Clocks . . . . . . . . . . . . . . 11 11. Requirements for Boundary Clocks
12. Management and Signaling Messages . . . . . . . . . . . . . . 11 12. Management and Signaling Messages
13. Forbidden PTP Options . . . . . . . . . . . . . . . . . . . . 11 13. Forbidden PTP Options
14. Interoperation with IEEE 1588 Default Profile . . . . . . . . 11 14. Interoperation with IEEE 1588 Default Profile
15. Profile Identification . . . . . . . . . . . . . . . . . . . 12 15. Profile Identification
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 16. IANA Considerations
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 17. Security Considerations
18. Security Considerations . . . . . . . . . . . . . . . . . . . 12 18. References
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 18.1. Normative References
19.1. Normative References . . . . . . . . . . . . . . . . . . 13 18.2. Informative References
19.2. Informative References . . . . . . . . . . . . . . . . . 14 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses
1. Introduction 1. Introduction
The Precision Time Protocol ("PTP"), standardized in IEEE 1588, has The Precision Time Protocol (PTP), standardized in IEEE 1588, has
been designed in its first version (IEEE 1588-2002) with the goal to been designed in its first version (IEEE 1588-2002) with the goal of
minimize configuration on the participating nodes. Network minimizing configuration on the participating nodes. Network
communication was based solely on multicast messages, which unlike communication was based solely on multicast messages, which, unlike
NTP did not require that a receiving node in IEEE 1588-2019 NTP, did not require that a receiving node as discussed in IEEE
[IEEE1588] need to know the identity of the time sources in the 1588-2019 [IEEE1588-2019] need to know the identities of the time
network. This document describes clock roles and PTP Port states sources in the network. This document describes clock roles and PTP
using the optional alternative terms timeTransmitter, instead of Port states using the optional alternative terms "timeTransmitter"
master, and timeReceiver, instead of slave, as defined in the IEEE instead of "master" and "timeReceiver" instead of "slave", as defined
1588g [IEEE1588g] amendment to IEEE 1588-2019 [IEEE1588] . in the IEEE 1588g amendment [IEEE1588g] to [IEEE1588-2019].
The "Best TimeTransmitter Clock Algorithm" (IEEE 1588-2019 [IEEE1588] The "Best TimeTransmitter Clock Algorithm" ([IEEE1588-2019],
Subclause 9.3), a mechanism that all participating PTP nodes MUST Subclause 9.3), a mechanism that all participating PTP Nodes MUST
follow, set up strict rules for all members of a PTP domain to follow, sets up strict rules for all members of a PTP domain to
determine which node MUST be the active reference time source determine which node MUST be the active reference time source
(Grandmaster). Although the multicast communication model has (Grandmaster). Although the multicast communication model has
advantages in smaller networks, it complicated the application of PTP advantages in smaller networks, it complicated the application of PTP
in larger networks, for example in environments like IP based in larger networks -- for example, in environments like IP-based
telecommunication networks or financial data centers. It is telecommunication networks or financial data centers. It is
considered inefficient that, even if the content of a message applies considered inefficient that, even if the content of a message applies
only to one receiver, it is forwarded by the underlying network (IP) only to one receiver, the message is forwarded by the underlying
to all nodes, requiring them to spend network bandwidth and other network (IP) to all nodes, requiring them to spend network bandwidth
resources, such as CPU cycles, to drop the message. and other resources, such as CPU cycles, to drop it.
The third edition of the standard (IEEE 1588-2019) defines PTPv2.1 The third edition of the standard (IEEE 1588-2019) defines PTPv2.1
and includes the possibility to use unicast communication between the and includes the possibility of using unicast communication between
PTP nodes in order to overcome the limitation of using multicast the PTP Nodes in order to overcome the limitation of using multicast
messages for the bi-directional information exchange between PTP messages for the bidirectional information exchange between PTP
nodes. The unicast approach avoided that. In PTP domains with a lot Nodes. The unicast approach avoided that. In PTP domains with a lot
of nodes, devices had to throw away most of the received multicast of nodes, devices had to throw away most of the received multicast
messages because they carried information for some other node. The messages because they carried information for some other node. The
percent of PTP message that are discarded as irrelevant to the percent of PTP messages that are discarded as irrelevant to the
receving node can exceded 99% (Estrela and Bonebakker receiving node can exceed 99% [Estrela_and_Bonebakker].
[Estrela_and_Bonebakker]).
PTPv2.1 also includes PTP Profiles (IEEE 1588-2019 [IEEE1588] PTPv2.1 also includes PTP Profiles ([IEEE1588-2019], Subclause 20.3).
subclause 20.3). This construct allows organizations to specify These constructs allow organizations to specify selections of
selections of attribute values and optional features, simplifying the attribute values and optional features, simplifying the configuration
configuration of PTP nodes for a specific application. Instead of of PTP Nodes for a specific application. Instead of having to go
having to go through all possible parameters and configuration through all possible parameters and configuration options and
options and individually set them up, selecting a PTP Profile on a individually set them up, selecting a PTP Profile on a PTP Node will
PTP node will set all the parameters that are specified in the PTP set all the parameters that are specified in the PTP Profile to a
Profile to a defined value. If a PTP Profile definition allows defined value. If a PTP Profile definition allows multiple values
multiple values for a parameter, selection of the PTP Profile will for a parameter, selection of the PTP Profile will set the profile-
set the profile-specific default value for this parameter. specific default value for this parameter. Parameters not allowing
Parameters not allowing multiple values are set to the value defined multiple values are set to the value defined in the PTP Profile.
in the PTP Profile. Many PTP features and functions are optional, Many PTP features and functions are optional, and a PTP Profile
and a PTP Profile should also define which optional features of PTP should also define which optional features of PTP are required,
are required, permitted, and prohibited. It is possible to extend permitted, and prohibited. It is possible to extend the PTP standard
the PTP standard with a PTP Profile by using the TLV mechanism of PTP with a PTP Profile by using the TLV mechanism of PTP (see
(see IEEE 1588-2019 [IEEE1588] subclause 13.4), defining an optional [IEEE1588-2019], Subclause 13.4) or defining an optional Best
Best TimeTransmitter Clock Algorithm and a few other ways. PTP has TimeTransmitter Clock Algorithm, among other techniques (which are
its own management protocol (defined in IEEE 1588-2019 [IEEE1588] beyond the scope of this document). PTP has its own management
subclause 15.2) but allows a PTP Profile to specify an alternative protocol (defined in [IEEE1588-2019], Subclause 15.2) but allows a
management mechanism, for example NETCONF. PTP Profile to specify an alternative management mechanism -- for
example, the Network Configuration Protocol (NETCONF).
In this document the term PTP Port refers to a logical access point In this document, the term "PTP Port" refers to a logical access
of a PTP instantiation for PTP communincation in a network. point of a PTP instantiation for PTP communication in a network.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
appear in all capitals, as shown here. capitals, as shown here.
3. Technical Terms 3. Technical Terms
* Acceptable TimeTransmitter Table: A PTP timeReceiver Clock may Acceptable TimeTransmitter Table: A list of timeTransmitters that
maintain a list of timeTransmitters which it is willing to may be maintained by a PTP timeReceiver Clock. The PTP
synchronize to. timeReceiver Clock would be willing to synchronize to
timeTransmitters in this list.
* Alternate timeTransmitter: A PTP timeTransmitter Clock, which is Alternate timeTransmitter: A PTP timeTransmitter Clock that is not
not the Best timeTransmitter, may act as a timeTransmitter with the Best timeTransmitter and therefore is used as an alternative
the Alternate timeTransmitter flag set on the messages it sends. clock. It may act as a timeTransmitter with the Alternate
timeTransmitter flag set on the messages it sends.
* Announce message: Contains the timeTransmitter Clock properties of Announce message: Contains the properties of a given timeTransmitter
a timeTransmitter Clock. Used to determine the Best Clock. The information is used to determine the Best
TimeTransmitter. timeTransmitter.
* Best timeTransmitter: A clock with a PTP Port in the Best timeTransmitter: A clock with a PTP Port in the timeTransmitter
timeTransmitter state, operating as the Grandmaster of a PTP state, operating as the Grandmaster of a PTP domain.
domain.
* Best TimeTransmitter Clock Algorithm: A method for determining Best TimeTransmitter Clock Algorithm: A method for determining which
which state a PTP Port of a PTP clock should be in. The state state a PTP Port of a PTP clock should be in. The state decisions
decisions lead to the formation of a clock spanning tree for a PTP lead to the formation of a clock spanning tree for a PTP domain.
domain.
* Boundary Clock: A device with more than one PTP Port. Generally Boundary Clock: A device with more than one PTP Port. Generally,
Boundary Clocks will have one PTP Port in timeReceiver state to Boundary Clocks will have one PTP Port in the timeReceiver state
receive timing and other PTP Ports in timeTransmitter state to re- to receive timing and other PTP Ports in the timeTransmitter state
distribute the timing. to redistribute the timing.
* Clock Identity: In IEEE 1588-2019 this is a 64-bit number assigned Clock Identity: In [IEEE1588-2019], a 64-bit number assigned to each
to each PTP clock which MUST be globally unique. Often it is PTP clock. This number MUST be globally unique. Often, it is
derived from the Ethernet MAC address. derived from the Ethernet Media Access Control (MAC) address.
* Domain: Every PTP message contains a domain number. Domains are Domain: Treated as a separate PTP system in a network. Every PTP
treated as separate PTP systems in the network. Clocks, however, message contains a domain number. Clocks, however, can combine
can combine the timing information derived from multiple domains. the timing information derived from multiple domains.
* End-to-End delay measurement mechanism: A network delay End-to-End delay measurement mechanism: A network delay measurement
measurement mechanism in PTP facilitated by an exchange of mechanism in PTP facilitated by an exchange of messages between a
messages between a timeTransmitter Clock and a timeReceiver Clock. timeTransmitter Clock and a timeReceiver Clock. These messages
These messages might traverse Transparent Clocks and PTP unaware might traverse Transparent Clocks and PTP-unaware switches. This
switches. This mechanism might not work properly if the Sync and mechanism might not work properly if the Sync and Delay Request
Delay Request messages traverse different network paths. messages traverse different network paths.
* Grandmaster: the timeTransmitter Clock that is currently acting as Grandmaster: The timeTransmitter Clock that is currently acting as
the reference time source of the PTP domain the reference time source of the PTP domain.
* IEEE 1588: The timing and synchronization standard which defines IEEE 1588: The timing and synchronization standard that defines PTP
PTP, and describes the node, system, and communication properties and describes the node, system, and communication properties
necessary to support PTP. necessary to support PTP.
* TimeTransmitter Clock: a clock with at least one PTP Port in the NTP: Network Time Protocol, defined by [RFC5905].
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 Ordinary Clock: A clock that has a single PTP Port in a domain and
PTP Port in a domain and maintains the timescale used in the maintains the timescale used in the domain. It may serve as a
domain. It may serve as a timeTransmitter Clock, or be a timeTransmitter Clock or may be a timeReceiver Clock.
timeReceiver Clock.
* Peer-to-Peer delay measurement mechanism: A network delay Peer-to-Peer delay measurement mechanism: A network delay
measurement mechanism in PTP facilitated by an exchange of measurement mechanism in PTP facilitated by an exchange of
messages over the link between adjacent devices in a network. messages over the link between adjacent devices in a network.
This mechanism might not work properly unless all devices in the This mechanism might not work properly unless all devices in the
network support PTP and the Peer-to-peer measurement mechanism. network support PTP and the Peer-to-Peer delay measurement
mechanism.
* Preferred timeTransmitter: A device intended to act primarily as Preferred timeTransmitter: A device intended to act primarily as the
the Grandmaster of a PTP system, or as a back up to a Grandmaster. Grandmaster of a PTP system or as a backup to a Grandmaster.
* PTP: The Precision Time Protocol: The timing and synchronization PTP: The Precision Time Protocol -- the timing and synchronization
protocol defined by IEEE 1588. protocol defined by IEEE 1588.
* PTP Port: An interface of a PTP clock with the network. Note that PTP Port: An interface of a PTP clock with the network. Note that
there may be multiple PTP Ports running on one physical interface, there may be multiple PTP Ports running on one physical interface
for example, mulitple unicast timeReceivers which talk to several -- for example, multiple unicast timeReceivers that talk to
Grandmaster Clocks in different PTP Domains. several Grandmaster Clocks in different PTP domains.
* PTP Profile: A set of constraints on the options and features of PTP Profile: A set of constraints on the options and features of
PTP, designed to optimize PTP for a specific use case or industry. PTP, designed to optimize PTP for a specific use case or industry.
The profile specifies what is required, allowed and forbidden The profile specifies what is required, allowed, and forbidden
among options and attribute values of PTP. among options and attribute values of PTP.
* PTPv2.1: Refers specifically to the version of PTP defined by IEEE PTPv2.1: Refers specifically to the version of PTP defined by
1588-2019. [IEEE1588-2019].
* Rogue timeTransmitter: A clock with a PTP Port in the Rogue timeTransmitter: A clock that has a PTP Port in the
timeTransmitter state, even though it should not be in the timeTransmitter state -- even though it should not be in the
timeTransmitter state according to the Best TimeTransmitter Clock timeTransmitter state according to the Best TimeTransmitter Clock
Algorithm, and does not set the Alternate timeTransmitter flag. Algorithm -- and that does not set the Alternate timeTransmitter
flag.
* TimeReceiver Clock: a clock with at least one PTP Port in the TimeReceiver Clock: A clock with at least one PTP Port in the
timeReceiver state, and no PTP Ports in the timeTransmitter state. timeReceiver state and no PTP Ports in the timeTransmitter state.
* TimeReceiver Only clock: An Ordinary Clock which cannot become a TimeReceiver only clock: An Ordinary Clock that cannot become a
timeTransmitter Clock. timeTransmitter Clock.
* TLV: Type Length Value, a mechanism for extending messages in TimeTransmitter Clock: A clock with at least one PTP Port in the
timeTransmitter state.
TLV: Type Length Value -- a mechanism for extending messages in
networked communications. networked communications.
* Transparent Clock. A device that measures the time taken for a Transparent Clock: A device that measures the time taken for a PTP
PTP event message to transit the device and then updates the event message to transit the device and then updates the message
message with a correction for this transit time. with a correction for this transit time.
* Unicast Discovery: A mechanism for PTP timeReceivers to establish Unicast Discovery: A mechanism for PTP timeReceivers to establish a
a unicast communication with PTP timeTransmitters using a unicast communication with PTP timeTransmitters using a configured
configured table of timeTransmitter IP addresses and Unicast table of timeTransmitter IP addresses and unicast message
Message Negotiation. negotiation.
* Unicast Negotiation: A mechanism in PTP for timeReceiver Clocks to Unicast message negotiation: A mechanism in PTP for timeReceiver
negotiate unicast Sync, Announce and Delay Request message Clocks to negotiate unicast Sync, Announce, and Delay Request
transmission rates from timeTransmitters. message transmission rates from timeTransmitters.
4. Problem Statement 4. Problem Statement
This document describes how PTP can be applied to work in large This document describes how PTP can be applied to work in large
enterprise networks. See ISPCS [RFC2026] for information on IETF enterprise networks. See ISPCS [RFC2026] for information on IETF
applicability statements. Such large networks are deployed, for applicability statements. Such large networks are deployed, for
example, in financial corporations. It is becoming increasingly example, in financial corporations. It is becoming increasingly
common in such networks to perform distributed time tagged common in such networks to perform distributed time-tagged
measurements, such as one-way packet latencies and cumulative delays measurements, such as one-way packet latencies and cumulative delays
on software systems spread across multiple computers. Furthermore, on software systems spread across multiple computers. Furthermore,
there is often a desire to check the age of information time tagged there is often a desire to check the age of information time-tagged
by a different machine. To perform these measurements, it is by a different machine. To perform these measurements, it is
necessary to deliver a common precise time to multiple devices on a necessary to deliver a common precise time to multiple devices on a
network. Accuracy currently required in the Financial Industry range network. Accuracy currently required in the financial industry
from 100 microseconds to 1 nanoseconds to the Grandmaster. This PTP ranges from 100 microseconds to 1 nanosecond to the Grandmaster.
Profile does not specify timing performance requirements, but such This PTP Profile does not specify timing performance requirements,
requirements explain why the needs cannot always be met by NTP, as but such requirements explain why the needs cannot always be met by
commonly implemented. Such accuracy cannot usually be achieved with NTP as commonly implemented. Such accuracy cannot usually be
a traditional time transfer such as NTP, without adding non-standard achieved with NTP, without adding non-standard customizations such as
customizations such as on-path support, similar to what is done in on-path support, similar to what is done in PTP with Transparent
PTP with Transparent Clocks and Boundary Clocks. Such PTP support is Clocks and Boundary Clocks. Such PTP support is commonly available
commonly available in switches and routers, and many such devices in switches and routers, and many such devices have already been
have already been deployed in networks. Because PTP has a complex deployed in networks. Because PTP has a complex range of features
range of features and options it is necessary to create a PTP Profile and options, it is necessary to create a PTP Profile for enterprise
for enterprise networks to achieve interoperability between equipment networks to achieve interoperability among equipment manufactured by
manufactured by different vendors. different vendors.
Although enterprise networks can be large, it is becoming Although enterprise networks can be large, it is becoming
increasingly common to deploy multicast protocols, even across increasingly common to deploy multicast protocols, even across
multiple subnets. For this reason, it is desired to make use of multiple subnets. For this reason, it is desirable to make use of
multicast whenever the information going to many destinations is the multicast whenever the information going to many destinations is the
same. It is also advantageous to send information which is only same. It is also advantageous to send information that is only
relevant to one device as a unicast message. The latter can be relevant to one device as a unicast message. The latter can be
essential as the number of PTP timeReceivers becomes hundreds or essential as the number of PTP timeReceivers becomes hundreds or
thousands. thousands.
PTP devices operating in these networks need to be robust. This PTP devices operating in these networks need to be robust. This
includes the ability to ignore PTP messages which can be identified includes the ability to ignore PTP messages that can be identified as
as improper, and to have redundant sources of time. improper and to have redundant sources of time.
Interoperability among independent implementations of this PTP Interoperability among independent implementations of this PTP
Profile has been demonstrated at the ISPCS Plugfest ISPCS [ISPCS]. Profile has been demonstrated at the International Symposium on
Precision Clock Synchronization (ISPCS) Plugfest [ISPCS].
5. Network Technology 5. Network Technology
This PTP Profile MUST operate only in networks characterized by UDP This PTP Profile MUST operate only in networks characterized by UDP
RFC 768 [RFC0768] over either IPv4 RFC 791 [RFC0791] or IPv6 RFC 8200 [RFC0768] over either IPv4 [RFC0791] or IPv6 [RFC8200], as described
[RFC8200], as described by Annexes C and D in IEEE 1588 [IEEE1588] by Annexes C and D of [IEEE1588-2019], respectively. A network node
respectively. A network node MAY include multiple PTP instances MAY include multiple PTP instances running simultaneously. IPv4 and
running simultaneously. IPv4 and IPv6 instances in the same network IPv6 instances in the same network node MUST operate in different PTP
node MUST operate in different PTP Domains. PTP Clocks which domains. PTP clocks that communicate using IPv4 can transfer time to
communicate using IPv4 can transfer time to PTP Clocks using IPv6, or PTP clocks using IPv6, or the reverse, if and only if there is a
the reverse, if and only if, there is a network node which network node that simultaneously communicates with both PTP domains
simultaneously communicates with both PTP domains in the different IP in the different IP versions.
versions.
The PTP system MAY include switches and routers. These devices MAY The PTP system MAY include switches and routers. These devices MAY
be Transparent Clocks, Boundary Clocks, or neither, in any be Transparent Clocks, Boundary Clocks, or neither, in any
combination. PTP Clocks MAY be Preferred timeTransmitters, Ordinary combination. PTP clocks MAY be Preferred timeTransmitters, Ordinary
Clocks, or Boundary Clocks. The Ordinary Clocks may be TimeReceiver Clocks, or Boundary Clocks. The Ordinary Clocks may be timeReceiver
Only Clocks, or be timeTransmitter capable. only clocks or may be timeTransmitter capable.
Note that PTP Ports will need to keep tack of the Clock ID of 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 received messages and not just the IP or Layer 2 addresses in any
network that includes Transparent Clocks, or might include them in network that includes Transparent Clocks or that might include them
the future. This is important since Transparent Clocks might treat in the future. This is important, since Transparent Clocks might
PTP messages that are altered at the PTP application layer as new IP treat PTP messages that are altered at the PTP application layer as
packets and new Layer 2 frames when the PTP messages are new IP packets and new Layer 2 frames when the PTP messages are
retranmitted. In IPv4 networks some clocks might be hidden behind a retransmitted. In IPv4 networks, some clocks might be hidden behind
NAT, which hides their IP addresses from the rest of the network. 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 Note also that the use of NATs may place limitations on the topology
of PTP networks, depending on the port forwarding scheme employed. of PTP Networks, depending on the port forwarding scheme employed.
Details of implementing PTP with NATs are out of scope of this Details of implementing PTP with NATs are out of scope for this
document. document.
PTP, similar to NTP, assumes that the one-way network delay for Sync 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 messages and Delay Response messages is the same. When this is not
true it can cause errors in the transfer of time from the true, it can cause errors in the transfer of time from the
timeTransmitter to the timeReceiver. It is up to the system timeTransmitter to the timeReceiver. It is up to the system
integrator to design the network so that such effects do not prevent integrator to design the network so that such effects do not prevent
the PTP system from meeting the timing requirements. The details of the PTP system from meeting the timing requirements. The details of
network asymmetry are outside the scope of this document. See for network asymmetry are outside the scope of this document. See, for
example, ITU-T G.8271 [G8271]. example, ITU-T G.8271 [G8271].
6. Time Transfer and Delay Measurement 6. Time Transfer and Delay Measurement
TimeTransmitter Clocks, Transparent Clocks and Boundary Clocks MAY be TimeTransmitter Clocks, Transparent Clocks, and Boundary Clocks MAY
either one-step clocks or two-step clocks. TimeReceiver Clocks MUST be either one-step clocks or two-step clocks. TimeReceiver Clocks
support both behaviors. The End-to-End Delay measurement method MUST MUST support both behaviors. The End-to-End delay measurement method
be used. MUST be used.
Note that, in IP networks, Sync messages and Delay Request messages Note that, in IP networks, Sync messages and Delay Request messages
exchanged between a timeTransmitter and timeReceiver do not exchanged between a timeTransmitter and timeReceiver do not
necessarily traverse the same physical path. Thus, wherever necessarily traverse the same physical path. Thus, wherever
possible, the network SHOULD be engineered so that the forward and possible, the network SHOULD be engineered so that the forward and
reverse routes traverse the same physical path. Traffic engineering reverse routes traverse the same physical path. Traffic engineering
techniques for path consistency are out of scope of this document. techniques for path consistency are out of scope for this document.
Sync messages MUST be sent as PTP event multicast messages (UDP port Sync messages MUST be sent as PTP event multicast messages (UDP port
319) to the PTP primary IP address. Two step clocks MUST send 319) to the PTP primary IP address. Two-step clocks MUST send
Follow-up messages as PTP general multicast messages (UDP port 320). Follow-up messages as PTP general multicast messages (UDP port 320).
Announce messages MUST be sent as multicast messages (UDP port 320) Announce messages MUST be sent as PTP general multicast messages (UDP
to the PTP primary address. The PTP primary IP address is 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 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 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. are explained in [IEEE1588-2019], Annex D, Section D.3. These
These addresses are aloted by IANA, see the Ipv6 Multicast Address addresses are allotted by IANA; see the "IPv6 Multicast Address Space
Space Registry [IPv6Registry] Registry" [IPv6Registry].
Delay Request messages MAY be sent as either multicast or unicast PTP Delay Request messages MAY be sent as either multicast or unicast PTP
event messages. TimeTransmitter Clocks MUST respond to multicast event messages. TimeTransmitter Clocks MUST respond to multicast
Delay Request messages with multicast Delay Response PTP general Delay Request messages with multicast Delay Response PTP general
messages. TimeTransmitter Clocks MUST respond to unicast Delay messages. TimeTransmitter Clocks MUST respond to unicast Delay
Request PTP event messages with unicast Delay Response PTP general Request PTP event messages with unicast Delay Response PTP general
messages. This allows for the use of Ordinary Clocks which do not messages. This allows for the use of Ordinary Clocks that do not
support the Enterprise Profile, if they are timeReceiver Only Clocks. support the Enterprise Profile, if they are timeReceiver only clocks.
Clocks SHOULD include support for multiple domains. The purpose is Clocks SHOULD include support for multiple domains. The purpose is
to support multiple simultaneous timeTransmitters for redundancy. to support multiple simultaneous timeTransmitters for redundancy.
Leaf devices (non-forwarding devices) can use timing information from Leaf devices (non-forwarding devices) can use timing information from
multiple timeTransmitters by combining information from multiple multiple timeTransmitters by combining information from multiple
instantiations of a PTP stack, each operating in a different PTP instantiations of a PTP stack, each operating in a different PTP
Domain. Redundant sources of timing can be ensembled, and/or domain. To check for faulty timeTransmitter Clocks, redundant
compared to check for faulty timeTransmitter Clocks. The use of sources of timing can be evaluated as an ensemble and/or compared
multiple simultaneous timeTransmitters will help mitigate faulty individually. The use of multiple simultaneous timeTransmitters will
timeTransmitters reporting as healthy, network delay asymmetry, and help mitigate faulty timeTransmitters reporting as healthy, network
security problems. Security problems include on-path attacks such as delay asymmetry, and security problems. Security problems include
delay attacks, packet interception / manipulation attacks. Assuming on-path attacks such as delay attacks, packet interception attacks,
the path to each timeTransmitter is different, failures malicious or and packet manipulation attacks. Assuming that the path to each
otherwise would have to happen at more than one path simultaneously. timeTransmitter is different, failures -- malicious or otherwise --
Whenever feasible, the underlying network transport technology SHOULD would have to happen at more than one path simultaneously. Whenever
be configured so that timing messages in different domains traverse feasible, the underlying network transport technology SHOULD be
configured so that timing messages in different domains traverse
different network paths. different network paths.
7. Default Message Rates 7. Default Message Rates
The Sync, Announce, and Delay Request default message rates MUST each The Sync, Announce, and Delay Request default message rates MUST each
be once per second. The Sync and Delay Request message rates MAY be 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 set to other values, but not less than once every 128 seconds and not
not more than 128 messages per second. The Announce message rate more than 128 messages per second. The Announce message rate MUST
MUST NOT be changed from the default value. The Announce Receipt NOT be changed from the default value. The Announce Receipt Timeout
Timeout Interval MUST be three Announce Intervals for Preferred Interval MUST be three Announce Intervals for Preferred
TimeTransmitters, and four Announce Intervals for all other timeTransmitters and four Announce Intervals for all other
timeTransmitters. timeTransmitters.
The logMessageInterval carried in the unicast Delay Response message The logMessageInterval carried in the unicast Delay Response message
MAY be set to correspond to the timeTransmitter ports preferred MAY be set to correspond to the timeTransmitter ports' preferred
message period, rather than 7F, which indicates message periods are message period, rather than 7F, which indicates that message periods
to be negotiated. Note that negotiated message periods are not are to be negotiated. Note that negotiated message periods are not
allowed, see forbidden PTP options (Section 13). allowed; see Section 13 ("Forbidden PTP Options").
8. Requirements for TimeTransmitter Clocks 8. Requirements for TimeTransmitter Clocks
TimeTransmitter Clocks MUST obey the standard Best TimeTransmitter TimeTransmitter Clocks MUST obey the standard Best TimeTransmitter
Clock Algorithm from IEEE 1588 [IEEE1588]. PTP systems using this Clock Algorithm as defined in [IEEE1588-2019]. PTP systems using
PTP Profile MAY support multiple simultaneous Grandmasters if each this PTP Profile MAY support multiple simultaneous Grandmasters if
active Grandmaster is operating in a different PTP domain. each active Grandmaster is operating in a different PTP domain.
A PTP Port of a clock MUST NOT be in the timeTransmitter state unless 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. the clock has a current value for the number of UTC leap seconds.
If a unicast negotiation signaling message is received it MUST be If a unicast negotiation signaling message is received, it MUST be
ignored. ignored.
In PTP Networks that contain Transparent Clocks, timeTransmitters In PTP Networks that contain Transparent Clocks, timeTransmitters
might receive Delay Request messages that no longer contains the IP might receive Delay Request messages that no longer contain the IP
Addresses of the timeReceivers. This is because Transparent Clocks addresses of the timeReceivers. This is because Transparent Clocks
might replace the IP address of Delay Requests with their own IP might replace the IP address of Delay Requests with their own IP
address after updating the Correction Fields. For this deployment address after updating the Correction Fields. For this deployment
scenario timeTransmitters will need to have configured tables of scenario, timeTransmitters will need to have configured tables of
timeReceivers' IP addresses and associated Clock Identities in order timeReceivers' IP addresses and associated Clock Identities in order
to send Delay Responses to the correct PTP Nodes. to send Delay Responses to the correct PTP Nodes.
9. Requirements for TimeReceiver Clocks 9. Requirements for TimeReceiver Clocks
In a network which contains multiple timeTransmitters in multiple In a network that contains multiple timeTransmitters in multiple
domains, TimeReceivers SHOULD make use of information from all the domains, timeReceivers SHOULD make use of information from all the
timeTransmitters in their clock control subsystems. TimeReceiver timeTransmitters in their clock control subsystems. TimeReceiver
Clocks MUST be able to function in such networks even if they use 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 time from only one of the domains. TimeReceiver Clocks MUST be able
to operate properly in the presence of a rogue timeTransmitter. to operate properly in the presence of a rogue timeTransmitter.
TimeReceivers SHOULD NOT Synchronize to a timeTransmitter which is TimeReceivers SHOULD NOT synchronize to a timeTransmitter that is not
not the Best TimeTransmitter in its domain. TimeReceivers will the Best timeTransmitter in its domain. TimeReceivers will continue
continue to recognize a Best TimeTransmitter for the duration of the to recognize a Best timeTransmitter for the duration of the Announce
Announce Time Out Interval. TimeReceivers MAY use an Acceptable Receipt Timeout Interval. TimeReceivers MAY use an Acceptable
TimeTransmitter Table. If a timeTransmitter is not an Acceptable TimeTransmitter Table. If a timeTransmitter is not an Acceptable
timeTransmitter, then the timeReceiver MUST NOT synchronize to it. timeTransmitter, then the timeReceiver MUST NOT synchronize to it.
Note that IEEE 1588-2019 requires timeReceiver Clocks to support both Note that IEEE 1588-2019 requires timeReceiver Clocks to support both
two-step or one-step timeTransmitter Clocks. See IEEE 1588 two-step and one-step timeTransmitter Clocks. See [IEEE1588-2019],
[IEEE1588], subClause 11.2. Subclause 11.2.
Since Announce messages are sent as multicast messages timeReceivers Since Announce messages are sent as multicast messages, timeReceivers
can obtain the IP addresses of a timeTransmitter from the Announce can obtain the IP addresses of a timeTransmitter from the Announce
messages. Note that the IP source addresses of Sync and Follow-up messages. Note that the IP source addresses of Sync and Follow-up
messages might have been replaced by the source addresses of a messages might have been replaced by the source addresses of a
Transparent Clock, so, timeReceivers MUST send Delay Request messages Transparent Clock; therefore, timeReceivers MUST send Delay Request
to the IP address in the Announce message. Sync and Follow-up messages to the IP address in the Announce message. Sync and Follow-
messages can be correlated with the Announce message using the Clock up messages can be correlated with the Announce message using the
ID, which is never altered by Transparent Clocks in this PTP Profile. Clock ID, which is never altered by Transparent Clocks in this PTP
Profile.
10. Requirements for Transparent Clocks 10. Requirements for Transparent Clocks
Transparent Clocks MUST NOT change the transmission mode of an Transparent Clocks MUST NOT change the transmission mode of an
Enterprise Profile PTP message. For example, a Transparent Clock Enterprise Profile PTP message. For example, a Transparent Clock
MUST NOT change a unicast message to a multicast message. MUST NOT change a unicast message to a multicast message.
Transparent Clocks which syntonize to the timeTransmitter Clock might Transparent Clocks that syntonize to the timeTransmitter Clock might
need to maintain separate clock rate offsets for each of the need to maintain separate clock rate offsets for each of the
supported domains. supported domains.
11. Requirements for Boundary Clocks 11. Requirements for Boundary Clocks
Boundary Clocks SHOULD support multiple simultaneous PTP domains. Boundary Clocks SHOULD support multiple simultaneous PTP domains.
This will require them to maintain separate clocks for each of the This will require them to maintain separate clocks for each of the
domains supported, at least in software. Boundary Clocks MUST NOT domains supported, at least in software. Boundary Clocks MUST NOT
combine timing information from different domains. combine timing information from different domains.
12. Management and Signaling Messages 12. Management and Signaling Messages
PTP Management messages MAY be used. Management messages intended PTP management messages MAY be used. Management messages intended
for a specific clock, i.e. the IEEE 1588 [IEEE1588] defined attribute for a specific clock, i.e., where the
targetPortIdentity.clockIdentity is not set to All 1s, MUST be sent targetPortIdentity.clockIdentity attribute (defined in
as a unicast message. Similarly, if any signaling messages are used [IEEE1588-2019]) does not have all bits set to 1, MUST be sent as a
they MUST also be sent as unicast messages whenever the message is unicast message. Similarly, if any signaling messages are used, they
intended soley for a specific PTP Node. MUST also be sent as unicast messages whenever the message is
intended solely for a specific PTP Node.
13. Forbidden PTP Options 13. Forbidden PTP Options
Clocks operating in the Enterprise Profile MUST NOT use: Peer-to-Peer Clocks operating in the Enterprise Profile MUST NOT use the
timing for delay measurement, Grandmaster Clusters, The Alternate following:
TimeTransmitter option, Alternate Timescales. Unicast discovery, or
unicast negotiation. Clocks operating in the Enterprise Profile MUST * Peer-to-Peer timing for delay measurement
avoid any optional feature that requires Announce messages to be
altered by Transparent Clocks, as this would require the Transparent * Grandmaster Clusters
Clock to change the source address and prevent the timeReceiver nodes
from discovering the protocol address of the timeTransmitter. * The Alternate timeTransmitter option
* Alternate Timescales
* Unicast discovery
* Unicast message negotiation
Clocks operating in the Enterprise Profile MUST avoid any optional
feature that requires Announce messages to be altered by Transparent
Clocks, as this would require the Transparent Clock to change the
source address and prevent the timeReceiver nodes from discovering
the protocol address of the timeTransmitter.
14. Interoperation with IEEE 1588 Default Profile 14. Interoperation with IEEE 1588 Default Profile
Clocks operating in the Enterprise Profile will interoperate with Clocks operating in the Enterprise Profile will interoperate with
clocks operating in the Default Profile described in IEEE 1588 clocks operating in the Default Profile described in [IEEE1588-2019],
[IEEE1588] Annex I.3. This variant of the Default Profile uses the Annex I.3. This variant of the Default Profile uses the End-to-End
End-to-End delay measurement mechanism. In addition, the Default delay measurement mechanism. In addition, the Default Profile would
Profile would have to operate over IPv4 or IPv6 networks, and use have to operate over IPv4 or IPv6 networks and use management
management messages in unicast when those messages are directed at a messages in unicast when those messages are directed at a specific
specific clock. If either of these requirements are not met than clock. If neither of these requirements is met, then Enterprise
Enterprise Profile clocks will not interoperate with Annex I.3 Profile clocks will not interoperate with Default Profile clocks as
Default Profile Clocks. The Enterprise Profile will not interoperate defined in [IEEE1588-2019], Annex I.3. The Enterprise Profile will
with the Annex I.4 variant of the Default Profile which requires use not interoperate with the variant of the Default Profile defined in
of the Peer-to-Peer delay measurement mechanism. [IEEE1588-2019], Annex I.4, which requires the use of the Peer-to-
Peer delay measurement mechanism.
Enterprise Profile Clocks will interoperate with clocks operating in Enterprise Profile clocks will interoperate with clocks operating in
other PTP Profiles if the clocks in the other PTP Profiles obey the 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 rules of the Enterprise Profile. These rules MUST NOT be changed to
achieve interoperability with other PTP Profiles. achieve interoperability with other PTP Profiles.
15. Profile Identification 15. Profile Identification
The IEEE 1588 standard requires that all PTP Profiles provide the The IEEE 1588 standard requires that all PTP Profiles provide the
following identifying information. following identifying information.
PTP Profile: PTP Profile: Enterprise Profile
Enterprise Profile Profile number: 1
Profile number: 1 Version: 1.0
Version: 1.0 Profile identifier: 00-00-5E-01-01-00
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 This PTP Profile was specified by the IETF.
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 A copy may be obtained at <https://datatracker.ietf.org/wg/tictoc/
and has later been converted manually into xml format using an documents>.
xml2rfc template.
17. IANA Considerations 16. IANA Considerations
There are no IANA requirements in this specification. This document has no IANA actions.
18. Security Considerations 17. Security Considerations
Protocols used to transfer time, such as PTP and NTP can be important Protocols used to transfer time, such as PTP and NTP, can be
to security mechanisms which use time windows for keys and important to security mechanisms that use time windows for keys and
authorization. Passing time through the networks poses a security authorization. Passing time through the networks poses a security
risk since time can potentially be manipulated. The use of multiple risk, since time can potentially be manipulated. The use of multiple
simultaneous timeTransmitters, using multiple PTP domains can simultaneous timeTransmitters, using multiple PTP domains, can
mitigate problems from rogue timeTransmitters and on-path attacks. mitigate problems from rogue timeTransmitters and on-path attacks.
Note that Transparent Clocks alter PTP content on-path, but in a Note that Transparent Clocks alter PTP content on-path, but in a
manner specified in IEEE 1588-2019 [IEEE1588] that helps with time manner specified in [IEEE1588-2019] that helps with time transfer
transfer accuracy. See sections 9 and 10. Additional security accuracy. See Sections 9 and 10. Additional security mechanisms are
mechanisms are outside the scope of this document. outside the scope of this document.
PTP native management messages SHOULD NOT be used, due to the lack of PTP management messages SHOULD NOT be used, due to the lack of a
a security mechanism for this option. Secure management can be security mechanism for this option. Secure management can be
obtained using standard management mechanisms which include security, obtained using standard management mechanisms that include security
for example NETCONF NETCONF [RFC6241]. -- for example, NETCONF [RFC6241].
General security considerations of time protocols are discussed in General security considerations related to time protocols are
RFC 7384 [RFC7384]. discussed in [RFC7384].
19. References 18. References
19.1. Normative References 18.1. Normative References
[IEEE1588] Institute of Electrical and Electronics Engineers, "IEEE [IEEE1588-2019]
std. 1588-2019, "IEEE Standard for a Precision Clock IEEE, "IEEE Standard for a Precision Clock Synchronization
Synchronization for Networked Measurement and Control for Networked Measurement and Control Systems", IEEE
Systems."", November 2019, <https://www.ieee.org>. Std 1588-2019, DOI 10.1109/IEEESTD.2020.9120376, June
2020, <https://ieeexplore.ieee.org/document/9120376>.
[IEEE1588g] [IEEE1588g]
Institute of Electrical and Electronics Engineers, "IEEE IEEE, "IEEE Standard for a Precision Clock Synchronization
std. 1588g-2022, "IEEE Standard for a Precision Clock Protocol for Networked Measurement and Control Systems
Synchronization Protocol for Networked Measurement and Amendment 2: Master-Slave Optional Alternative
Control Systems Amendment 2: Master-Slave Optional Terminology", IEEE Std 1588g-2022,
Alternative Terminology"", December 2022, DOI 10.1109/IEEESTD.2023.10070440, March 2023,
<https://www.ieee.org>. <https://ieeexplore.ieee.org/document/10070440>.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
19.2. Informative References 18.2. Informative References
[Estrela_and_Bonebakker] [Estrela_and_Bonebakker]
Estrela, P. and L. Bonebakker, "Estrela and Bonebakker, Estrela, P. and L. Bonebakker, "Challenges deploying PTPv2
"Challenges deploying PTPv2 in a global financial in a global financial company", Proceedings of the IEEE
company"", DOI 10.1109/ISPCS.2012.6336634, 2012, International Symposium on Precision Clock Synchronization
for Measurement, Control and Communication, pp. 1-6,
DOI 10.1109/ISPCS.2012.6336634, September 2012,
<https://www.researchgate.net/publication/260742322_Challe <https://www.researchgate.net/publication/260742322_Challe
nges_deploying_PTPv2_in_a_global_financial_company>. nges_deploying_PTPv2_in_a_global_financial_company>.
[G8271] International Telecommunication Union, "ITU-T G.8271/ [G8271] ITU-T, "Time and phase synchronization aspects of
Y.1366, "Time and Phase Synchronization Aspects of Packet telecommunication networks", ITU-T
Networks"", March 2020, <https://www.itu.int>. Recommendation G.8271/Y.1366, March 2020,
<https://www.itu.int/rec/T-REC-G.8271-202003-I/en>.
[IPv6Registry] [IPv6Registry]
Venaas, S., "IPv6 Multicast Address Space Registry", IANA, "IPv6 Multicast Address Space Registry",
February 2024, <https://iana.org/assignments/ipv6- <https://iana.org/assignments/ipv6-multicast-addresses>.
multicast-addresses/ipv6-multicast-addresses.xhtml>.
[ISPCS] Arnold, D., "Plugfest Report", October 2017, [ISPCS] Arnold, D. and K. Harris, "Plugfest", Proceedings of the
<https://www.ispcs.org>. IEEE International Symposium on Precision Clock
Synchronization for Measurement, Control, and
Communication (ISPCS), August 2017,
<https://2017.ispcs.org/plugfest>.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, DOI 10.17487/RFC2026, October 1996, 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
<https://www.rfc-editor.org/info/rfc2026>. <https://www.rfc-editor.org/info/rfc2026>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>. October 2014, <https://www.rfc-editor.org/info/rfc7384>.
Acknowledgements
The authors would like to thank Richard Cochran, Kevin Gross, John
Fletcher, Laurent Montini, and many other members of the IETF for
reviewing and providing feedback on this document.
Authors' Addresses Authors' Addresses
Doug Arnold Doug Arnold
Meinberg-USA Meinberg-USA
3 Concord Rd 3 Concord Rd
Shrewsbury, Massachusetts 01545 Shrewsbury, Massachusetts 01545
United States of America United States of America
Email: doug.arnold@meinberg-usa.com Email: doug.arnold@meinberg-usa.com
Heiko Gerstung Heiko Gerstung
Meinberg Meinberg
Lange Wand 9 Lange Wand 9
31812 Bad Pyrmont 31812 Bad Pyrmont
Germany Germany
Email: heiko.gerstung@meinberg.de Email: heiko.gerstung@meinberg.de
 End of changes. 108 change blocks. 
361 lines changed or deleted 377 lines changed or added

This html diff was produced by rfcdiff 1.48.