draft-ietf-tictoc-ptp-enterprise-profile-24.txt | draft-ietf-tictoc-ptp-enterprise-profile-25.txt | |||
---|---|---|---|---|
TICTOC Working Group D.A. Arnold | TICTOC Working Group D.A. Arnold | |||
Internet-Draft Meinberg-USA | Internet-Draft Meinberg-USA | |||
Intended status: Standards Track H.G. Gerstung | Intended status: Standards Track H.G. Gerstung | |||
Expires: 26 May 2024 Meinberg | Expires: 26 September 2024 Meinberg | |||
23 November 2023 | 25 March 2024 | |||
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-24 | draft-ietf-tictoc-ptp-enterprise-profile-25 | |||
Abstract | Abstract | |||
This document describes a PTP Profile for the use of the Precision | This document describes a PTP Profile for the use of the Precision | |||
Time Protocol in an IPv4 or IPv6 Enterprise information system | Time Protocol in an IPv4 or IPv6 Enterprise information system | |||
environment. The PTP Profile uses the End-to-End delay measurement | environment. The PTP Profile uses the End-to-End delay measurement | |||
mechanism, allows both multicast and unicast Delay Request and Delay | mechanism, allows both multicast and unicast Delay Request and Delay | |||
Response messages. | Response messages. | |||
Status of This Memo | Status of This Memo | |||
skipping to change at page 1, line 36 ¶ | skipping to change at page 1, line 36 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on 26 May 2024. | This Internet-Draft will expire on 26 September 2024. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2023 IETF Trust and the persons identified as the | Copyright (c) 2024 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 (https://trustee.ietf.org/ | |||
license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
skipping to change at page 3, line 6 ¶ | skipping to change at page 3, line 6 ¶ | |||
minimize configuration on the participating nodes. Network | minimize 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 in IEEE 1588-2019 | |||
[IEEE1588] need to know the identity of the time sources in the | [IEEE1588] need to know the identity of the time sources in the | |||
network. This document describes clock roles and PTP Port states | network. This document describes clock roles and PTP Port states | |||
using the optional alternative terms timeTransmitter, in stead of | using the optional alternative terms timeTransmitter, in stead of | |||
master, and timeReceiver, in stead of slave, as defined in the IEEE | master, and timeReceiver, in stead of slave, as defined in the IEEE | |||
1588g [IEEE1588g] amendment to IEEE 1588-2019 [IEEE1588] . | 1588g [IEEE1588g] amendment to IEEE 1588-2019 [IEEE1588] . | |||
The "Best TimeTransmitter Clock Algorithm" (IEEE 1588-2019 [IEEE1588] | The "Best TimeTransmitter Clock Algorithm" (IEEE 1588-2019 [IEEE1588] | |||
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, set up strict rules for all members of a PTP domain to | |||
determine which node shall 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, it is forwarded by the underlying network (IP) | |||
to all nodes, requiring them to spend network bandwidth and other | to all nodes, requiring them to spend network bandwidth and other | |||
resources, such as CPU cycles, to drop the message. | resources, such as CPU cycles, to drop the message. | |||
The third edition of the standard (IEEE 1588-2019) defines PTPv2.1 | The third edition of the standard (IEEE 1588-2019) defines PTPv2.1 | |||
skipping to change at page 4, line 28 ¶ | skipping to change at page 4, line 28 ¶ | |||
* Alternate timeTransmitter: A PTP timeTransmitter Clock, which is | * Alternate timeTransmitter: A PTP timeTransmitter Clock, which is | |||
not the Best timeTransmitter, may act as a timeTransmitter with | not the Best timeTransmitter, may act as a timeTransmitter with | |||
the Alternate timeTransmitter flag set on the messages it sends. | the Alternate timeTransmitter flag set on the messages it sends. | |||
* Announce message: Contains the timeTransmitter Clock properties of | * Announce message: Contains the timeTransmitter Clock properties of | |||
a timeTransmitter Clock. Used to determine the Best | a timeTransmitter Clock. 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 state, operating consistently with the Best | timeTransmitter state, operating as the Grandmaster of a PTP | |||
TimeTransmitter Clock Algorithm. | domain. | |||
* Best TimeTransmitter Clock Algorithm: A method for determining | * Best TimeTransmitter Clock Algorithm: A method for determining | |||
which state a PTP Port of a PTP clock should be in. The algorithm | which state a PTP Port of a PTP clock should be in. The state | |||
works by identifying which of several PTP timeTransmitter capable | decisions lead to the formation of a clock spanning tree for a PTP | |||
Clocks is the best timeTransmitter. Clocks have priority to | domain. | |||
become the acting Grandmaster, based on the properties each | ||||
timeTransmitter Clock sends in its Announce message. | ||||
* 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 timeReceiver state to | |||
receive timing and other PTP Ports in timeTransmitter state to re- | receive timing and other PTP Ports in timeTransmitter state to re- | |||
distribute the timing. | distribute the timing. | |||
* Clock Identity: In IEEE 1588-2019 this is a 64-bit number assigned | * Clock Identity: In IEEE 1588-2019 this is a 64-bit number assigned | |||
to each PTP clock which must be globally unique. Often it is | to each PTP clock which MUST be globally unique. Often it is | |||
derived from the Ethernet MAC address. | derived from the Ethernet MAC address. | |||
* Domain: Every PTP message contains a domain number. Domains are | * Domain: Every PTP message contains a domain number. Domains are | |||
treated as separate PTP systems in the network. Clocks, however, | treated as separate PTP systems in the network. Clocks, however, | |||
can combine the timing information derived from multiple domains. | can combine 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 mechanism in PTP facilitated by an exchange of | measurement mechanism in PTP facilitated by an exchange of | |||
messages between a timeTransmitter Clock and a timeReceiver Clock. | messages between a timeTransmitter Clock and a timeReceiver Clock. | |||
These messages might traverse Transparent Clocks and PTP unaware | ||||
switches. This mechanism might not work properly if the Sync and | ||||
Delay Request messages traverse different network paths. | ||||
* Grandmaster: the primary timeTransmitter Clock within a domain of | * Grandmaster: the primary timeTransmitter Clock within a domain of | |||
a PTP system | a PTP system | |||
* IEEE 1588: The timing and synchronization standard which defines | * IEEE 1588: The timing and synchronization standard which defines | |||
PTP, and describes the node, system, and communication properties | PTP, 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 | * TimeTransmitter Clock: a clock with at least one PTP Port in the | |||
timeTransmitter state. | timeTransmitter state. | |||
skipping to change at page 5, line 29 ¶ | skipping to change at page 5, line 32 ¶ | |||
* NTP: Network Time Protocol, defined by RFC 5905, see RFC 5905 | * NTP: Network Time Protocol, defined by RFC 5905, see RFC 5905 | |||
[RFC5905] | [RFC5905] | |||
* Ordinary Clock: A clock that has a single Precision Time Protocol | * Ordinary Clock: A clock that has a single Precision Time Protocol | |||
PTP Port in a domain and maintains the timescale used in the | PTP Port in a domain and maintains the timescale used in the | |||
domain. It may serve as a timeTransmitter Clock, or be a | domain. It may serve as a timeTransmitter Clock, or 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 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 | ||||
network support PTP and the Peer-to-peer measurement mechanism. | ||||
* Preferred timeTransmitter: A device intended to act primarily as | * Preferred timeTransmitter: A device intended to act primarily as | |||
the Grandmaster of a PTP system, or as a back up to a Grandmaster. | the Grandmaster of a PTP system, or as a back up 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, mulitple unicast timeReceivers which talk to several | |||
Grandmaster Clocks in different PTP Domains. | Grandmaster Clocks in different PTP Domains. | |||
* PTP Profile: A set of constraints on the options and features of | ||||
PTP, designed to optimize PTP for a specific use case or industry. | ||||
The profile specifies what is required, allowed and forbidden | ||||
among options and attribute values of PTP. | ||||
* PTPv2.1: Refers specifically to the version of PTP defined by IEEE | * PTPv2.1: Refers specifically to the version of PTP defined by IEEE | |||
1588-2019. | 1588-2019. | |||
* Rogue timeTransmitter: A clock with a PTP Port in the | * Rogue timeTransmitter: A clock with 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 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. | |||
skipping to change at page 6, line 41 ¶ | skipping to change at page 6, line 52 ¶ | |||
spread across multiple computers. Furthermore, there is often a | spread across multiple computers. Furthermore, there is often a | |||
desire to check the age of information time tagged by a different | desire to check the age of information time tagged by a different | |||
machine. To perform these measurements, it is necessary to deliver a | machine. To perform these measurements, it is necessary to deliver a | |||
common precise time to multiple devices on a network. Accuracy | common precise time to multiple devices on a network. Accuracy | |||
currently required in the Financial Industry range from 100 | currently required in the Financial Industry range from 100 | |||
microseconds to 1 nanoseconds to the Grandmaster. This PTP Profile | microseconds to 1 nanoseconds to the Grandmaster. This PTP Profile | |||
does not specify timing performance requirements, but such | does not specify timing performance requirements, but such | |||
requirements explain why the needs cannot always be met by NTP, as | requirements explain why the needs cannot always be met by NTP, as | |||
commonly implemented. Such accuracy cannot usually be achieved with | commonly implemented. Such accuracy cannot usually be achieved with | |||
a traditional time transfer such as NTP, without adding non-standard | a traditional time transfer such as NTP, without adding non-standard | |||
customizations such as hardware time stamping, and on path support. | customizations such as on-path support, similar to what is done in | |||
These features are currently part of PTP, or are allowed by it. | PTP with Transparent Clocks and Boundary Clocks. Such PTP support is | |||
Because PTP has a complex range of features and options it is | commonly available in switches and routers, and many such devices | |||
necessary to create a PTP Profile for enterprise networks to achieve | have already been deployed in networks. Because PTP has a complex | |||
interoperability between equipment manufactured by different vendors. | range of features and options it is necessary to create a PTP Profile | |||
for enterprise networks to achieve interoperability between equipment | ||||
manufactured by different vendors. | ||||
Although enterprise networks can be large, it is becoming | 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 desired 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 unique to | same. It is also advantageous to send information which is only | |||
one device as a unicast message. The latter can be essential as the | relevant to one device as a unicast message. The latter can be | |||
number of PTP timeReceivers becomes hundreds or thousands. | essential as the number of PTP timeReceivers becomes hundreds or | |||
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 which can be identified | |||
as improper, and to have redundant sources of time. | as 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 ISPCS Plugfest ISPCS [ISPCS]. | |||
5. Network Technology | 5. Network Technology | |||
This PTP Profile SHALL 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 | RFC 768 [RFC0768] over either IPv4 RFC 791 [RFC0791] or IPv6 RFC 8200 | |||
[RFC8200], as described by Annexes C and D in IEEE 1588 [IEEE1588] | [RFC8200], as described by Annexes C and D in IEEE 1588 [IEEE1588] | |||
respectively. If a network contains both IPv4 and IPv6, then they | respectively. Clocks which communicate using IPv4 can interact with | |||
SHALL be treated as separate communication paths. Clocks which | clocks using IPv6 if, and only if, there is an intermediary device | |||
communicate using IPv4 can interact with clocks using IPv6 if there | which simultaneously communicates with both IP versions. A Boundary | |||
is an intermediary device which simultaneously communicates with both | Clock might perform this function, for example. The PTP system MAY | |||
IP versions. A Boundary Clock might perform this function, for | include switches and routers. These devices MAY be Transparent | |||
example. A PTP domain SHALL use either IPv4 or IPv6 over a | Clocks, Boundary Clocks, or neither, in any combination. PTP Clocks | |||
communication path, but not both. The PTP system MAY include | MAY be Preferred timeTransmitters, Ordinary Clocks, or Boundary | |||
switches and routers. These devices MAY be Transparent Clocks, | Clocks. The Ordinary Clocks may be TimeReceiver Only Clocks, or be | |||
Boundary Clocks, or neither, in any combination. PTP Clocks MAY be | ||||
Preferred timeTransmitters, Ordinary Clocks, or Boundary Clocks. The | ||||
Ordinary Clocks may be TimeReceiver Only Clocks, or be | ||||
timeTransmitter capable. | timeTransmitter capable. | |||
Note that clocks SHOULD always be identified by their Clock ID and | Note that clocks SHOULD always be identified by their Clock ID and | |||
not the IP or Layer 2 address. This is important in IPv6 networks | not the IP or Layer 2 address. This is important since Transparent | |||
since Transparent Clocks are required to change the source address of | Clocks will treat PTP messages that are altered at the PTP | |||
any packet which they alter. In IPv4 networks some clocks might be | application layer as new IP packets and new Layer 2 frames when the | |||
PTP messages are retranmitted. In IPv4 networks some clocks might be | ||||
hidden behind a NAT, which hides their IP addresses from the rest of | 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 network. Note also that the use of NATs may place limitations on | |||
the topology of PTP networks, depending on the port forwarding scheme | the topology of PTP networks, depending on the port forwarding scheme | |||
employed. Details of implementing PTP with NATs are out of scope of | employed. Details of implementing PTP with NATs are out of scope of | |||
this document. | this 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 are 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 | |||
skipping to change at page 8, line 23 ¶ | skipping to change at page 8, line 29 ¶ | |||
be used. | 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 of 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 SHALL 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 multicast messages (UDP port 320) | |||
to the PTP primary address. The PTP primary IP address is | 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, see IEEE 1588 [IEEE1588] Annex D, | be a value between 0x0 and 0xF, see IEEE 1588 [IEEE1588] Annex D, | |||
Section D.3. | Section D.3. These addresses are aloted by IANA, see the Ipv6 | |||
Multicast Address Space 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 SHALL 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 SHALL 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 which 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. Redundant sources of timing can be ensembled, and/or | |||
skipping to change at page 9, line 4 ¶ | skipping to change at page 9, line 10 ¶ | |||
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. Redundant sources of timing can be ensembled, and/or | |||
compared to check for faulty timeTransmitter Clocks. The use of | compared to check for faulty timeTransmitter Clocks. The use of | |||
multiple simultaneous timeTransmitters will help mitigate faulty | multiple simultaneous timeTransmitters will help mitigate faulty | |||
timeTransmitters reporting as healthy, network delay asymmetry, and | timeTransmitters reporting as healthy, network delay asymmetry, and | |||
security problems. Security problems include on-path attacks such as | security problems. Security problems include on-path attacks such as | |||
delay attacks, packet interception / manipulation attacks. Assuming | delay attacks, packet interception / manipulation attacks. Assuming | |||
the path to each timeTransmitter is different, failures malicious or | the path to each timeTransmitter is different, failures malicious or | |||
otherwise would have to happen at more than one path simultaneously. | otherwise would have to happen at more than one path simultaneously. | |||
Whenever feasible, the underlying network transport technology SHOULD | Whenever feasible, the underlying network transport technology SHOULD | |||
be configured so that timing messages in different domains traverse | 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 SHALL | The Sync, Announce, and Delay Request default message rates MUST each | |||
each be once per second. The Sync and Delay Request message rates | be once per second. The Sync and Delay Request message rates MAY be | |||
MAY be set to other values, but not less than once every 128 seconds, | set to other values, but not less than once every 128 seconds, and | |||
and not more than 128 messages per second. The Announce message rate | not more than 128 messages per second. The Announce message rate | |||
SHALL NOT be changed from the default value. The Announce Receipt | MUST NOT be changed from the default value. The Announce Receipt | |||
Timeout Interval SHALL be three Announce Intervals for Preferred | Timeout 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 message periods are | |||
to be negotiated. Note that negotiated message periods are not | to be negotiated. Note that negotiated message periods are not | |||
allowed, see forbidden PTP options (Section 13). | allowed, see forbidden PTP options (Section 13). | |||
8. Requirements for TimeTransmitter Clocks | 8. Requirements for TimeTransmitter Clocks | |||
TimeTransmitter Clocks SHALL 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 from IEEE 1588 [IEEE1588]. PTP systems using this | |||
PTP Profile MAY support multiple simultaneous Grandmasters if each | PTP Profile MAY support multiple simultaneous Grandmasters if each | |||
active Grandmaster is operating in a different PTP domain. | active Grandmaster is operating in a different PTP domain. | |||
A PTP Port of a clock SHALL NOT be in the timeTransmitter state | A PTP Port of a clock MUST NOT be in the timeTransmitter state unless | |||
unless the clock has a current value for the number of UTC leap | the clock has a current value for the number of UTC leap seconds. | |||
seconds. | ||||
If a unicast negotiation signaling message is received it SHALL 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 contains the IP | |||
Addresses of the timeReceivers. This is becuase 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 | |||
TimeReceiver Clocks MUST be able to operate properly in a network | TimeReceiver Clocks MUST be able to operate properly in a network | |||
which contains multiple timeTransmitters in multiple domains. | which contains multiple timeTransmitters in multiple domains. | |||
skipping to change at page 10, line 25 ¶ | skipping to change at page 10, line 25 ¶ | |||
the duration of the Announce Time Out Interval. TimeReceivers MAY | the duration of the Announce Time Out Interval. TimeReceivers MAY | |||
use an Acceptable TimeTransmitter Table. If a timeTransmitter is not | use an Acceptable TimeTransmitter Table. If a timeTransmitter is not | |||
an Acceptable timeTransmitter, then the timeReceiver MUST NOT | an Acceptable timeTransmitter, then the timeReceiver MUST NOT | |||
synchronize to it. Note that IEEE 1588-2019 requires timeReceiver | synchronize to it. Note that IEEE 1588-2019 requires timeReceiver | |||
Clocks to support both two-step or one-step timeTransmitter Clocks. | Clocks to support both two-step or one-step timeTransmitter Clocks. | |||
See IEEE 1588 [IEEE1588], subClause 11.2. | See IEEE 1588 [IEEE1588], 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 may 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, so, timeReceivers MUST send Delay Request messages | |||
to the IP address in the Announce message. Sync and Follow-up | to the IP address in the Announce message. Sync and Follow-up | |||
messages can be correlated with the Announce message using the Clock | messages can be correlated with the Announce message using the Clock | |||
ID, which is never altered by Transparent Clocks in this PTP Profile. | ID, which is never altered by Transparent Clocks in this PTP Profile. | |||
10. Requirements for Transparent Clocks | 10. Requirements for Transparent Clocks | |||
Transparent Clocks SHALL 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 | |||
SHALL NOT change a unicast message to a multicast message. | MUST NOT change a unicast message to a multicast message. | |||
Transparent Clocks SHOULD support multiple domains. Transparent | Transparent Clocks SHOULD support multiple domains. Transparent | |||
Clocks which syntonize to the timeTransmitter Clock will need to | Clocks which syntonize to the timeTransmitter Clock might need to | |||
maintain separate clock rate offsets for each of the supported | maintain separate clock rate offsets for each of the supported | |||
domains. | 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 servo loops 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. the IEEE 1588 [IEEE1588] defined attribute | |||
targetPortIdentity.clockIdentity is not set to All 1s, MUST be sent | targetPortIdentity.clockIdentity is not set to All 1s, MUST be sent | |||
as a unicast message. Similarly, if any signaling messages are used | as a unicast message. Similarly, if any signaling messages are used | |||
they MUST also be sent as unicast messages whenever the message is | they MUST also be sent as unicast messages whenever the message is | |||
intended for a specific PTP Node. | intended soley for a specific PTP Node. | |||
13. Forbidden PTP Options | 13. Forbidden PTP Options | |||
Clocks operating in the Enterprise Profile SHALL NOT use Peer-to-Peer | Clocks operating in the Enterprise Profile MUST NOT use Peer-to-Peer | |||
timing for delay measurement. Grandmaster Clusters are NOT ALLOWED. | timing for delay measurement. Grandmaster Clusters are NOT ALLOWED. | |||
The Alternate TimeTransmitter option is also NOT ALLOWED. Clocks | The Alternate TimeTransmitter option is also NOT ALLOWED. Clocks | |||
operating in the Enterprise Profile SHALL NOT use Alternate | operating in the Enterprise Profile MUST NOT use Alternate | |||
Timescales. Unicast discovery and unicast negotiation SHALL NOT be | Timescales. Unicast discovery and unicast negotiation MUST NOT be | |||
used. Clocks operating in the Enterprise Profile SHALL NOT use any | used. Clocks operating in the Enterprise Profile MUST NOT use any | |||
optional feature that requires Announce messages to be altered by | optional feature that requires Announce messages to be altered by | |||
Transparent Clocks, as this would require the Transparent Clock to | Transparent Clocks, as this would require the Transparent Clock to | |||
change the source address and prevent the timeReceiver nodes from | change the source address and prevent the timeReceiver nodes from | |||
discovering the protocol address of the timeTransmitter. | 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 IEEE 1588 | |||
[IEEE1588] Annex I.3. This variant of the Default Profile uses the | [IEEE1588] Annex I.3. This variant of the Default Profile uses the | |||
skipping to change at page 12, line 17 ¶ | skipping to change at page 12, line 17 ¶ | |||
Version: 1.0 | Version: 1.0 | |||
Profile identifier: 00-00-5E-00-01-00 | Profile identifier: 00-00-5E-00-01-00 | |||
This PTP Profile was specified by the IETF | This PTP Profile was specified by the IETF | |||
A copy may be obtained at | A copy may be obtained at | |||
https://datatracker.ietf.org/wg/tictoc/documents | https://datatracker.ietf.org/wg/tictoc/documents | |||
16. Acknowledgements | 16. Acknowledgements | |||
The authors would like to thank members of IETF for reviewing and | The authors would like to thank Richard Cochran, Kevin Gross, John | |||
providing feedback on this draft. | 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 | This document was initially prepared using 2-Word-v2.0.template.dot | |||
and has later been converted manually into xml format using an | and has later been converted manually into xml format using an | |||
xml2rfc template. | xml2rfc template. | |||
17. IANA Considerations | 17. IANA Considerations | |||
There are no IANA requirements in this specification. | There are no IANA requirements in this specification. | |||
18. Security Considerations | 18. Security Considerations | |||
skipping to change at page 13, line 46 ¶ | skipping to change at page 13, line 46 ¶ | |||
(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 | 19.2. Informative References | |||
[G8271] International Telecommunication Union, "ITU-T G.8271/ | [G8271] International Telecommunication Union, "ITU-T G.8271/ | |||
Y.1366, "Time and Phase Synchronization Aspects of Packet | Y.1366, "Time and Phase Synchronization Aspects of Packet | |||
Networks"", March 2020, <https://www.itu.int>. | Networks"", March 2020, <https://www.itu.int>. | |||
[IPv6Registry] | ||||
Venaas, S., "IPv6 Multicast Address Space Registry", | ||||
February 2024, <https://iana.org/assignments/ipv6- | ||||
multicast-addresses/ipv6-multicast-addresses.xhtml>. | ||||
[ISPCS] Arnold, D., "Plugfest Report", October 2017, | [ISPCS] Arnold, D., "Plugfest Report", October 2017, | |||
<https://www.ispcs.org>. | <https://www.ispcs.org>. | |||
[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 | |||
End of changes. 37 change blocks. | ||||
68 lines changed or deleted | 82 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |