draft-ietf-tictoc-ptp-enterprise-profile-11.txt   draft-ietf-tictoc-ptp-enterprise-profile-12.txt 
TICTOC Working Group Doug Arnold TICTOC Working Group Doug Arnold
Internet Draft Meinberg-USA Internet Draft Meinberg-USA
Intended status: Standards Track Heiko Gerstung Intended status: Standards Track Heiko Gerstung
Meinberg Meinberg
Expires: January 31, 2019 Expires: June 30, 2019
Enterprise Profile for the Precision Time Protocol Enterprise Profile for the Precision Time Protocol
With Mixed Multicast and Unicast Messages With Mixed Multicast and Unicast Messages
draft-ietf-tictoc-ptp-enterprise-profile-11.txt draft-ietf-tictoc-ptp-enterprise-profile-12.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be provisions of BCP 78 and BCP 79. This document may not be
modified, and derivative works of it may not be created, except to modified, and derivative works of it may not be created, except to
publish it as an RFC and to translate it into languages other than publish it as an RFC and to translate it into languages other than
English. English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 49 skipping to change at page 2, line 49
The Precision Time Protocol ("PTP"), standardized in IEEE 1588, The Precision Time Protocol ("PTP"), standardized in IEEE 1588,
has been designed in its first version (IEEE 1588-2002) with the has been designed in its first version (IEEE 1588-2002) with the
goal to minimize configuration on the participating nodes. Network goal to 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 ("slave clock") in NTP did not require that a receiving node ("slave clock") in
[IEEE1588] needs to know the identity of the time sources in the [IEEE1588] needs to know the identity of the time sources in the
network (the Master Clocks). network (the Master Clocks).
The "Best Master Clock Algorithm" ([IEEE1588] Subclause 9.3), a The "Best Master Clock Algorithm" ([IEEE1588] Subclause 9.3), a
mechanism that all participating PTP nodes must follow, set up mechanism that all participating PTP nodes must follow, set up
strict rules for all members of a PTP domain to determine which strict rules for all members of a PTP domain to determine which
node shall be the active sending time source (Master Clock). node shall be the active sending time source (Master Clock).
Although the multicast communication model has advantages in Although the multicast communication model has advantages in
smaller networks, it complicated the application of PTP in larger smaller networks, it complicated the application of PTP in larger
networks, for example in environments like IP based 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 considered inefficient that, even if the content of a message
applies only to one receiver, it is forwarded by the underlying applies only to one receiver, it is forwarded by the underlying
network (IP) to all nodes, requiring them to spend network network (IP) to all nodes, requiring them to spend network
bandwidth and other resources, such as CPU cycles, to drop the bandwidth and other resources, such as CPU cycles, to drop the
message. message.
skipping to change at page 4, line 25 skipping to change at page 4, line 25
based on the properties each Master Clock sends in its Announce based on the properties each Master Clock sends in its Announce
Message. 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 port in slave state to receive boundary Clocks will have one port in slave state to receive
timing and then other ports in master state to re-distribute the timing and then other ports in master state to re-distribute the
timing. timing.
Clock Identity: In IEEE 1588-2008 this is a 64-bit number Clock Identity: In IEEE 1588-2008 this is a 64-bit number
assigned to each PTP clock which must be unique. Often it is assigned to each PTP clock which must be unique. Often it is
derived from the Ethernet MAC address, since there is already an derived from the Ethernet MAC address, since there is already an
international infrastructure for assigning unique numbers to each international infrastructure for assigning unique numbers to each
device manufactured. device manufactured.
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 Master Clock and Slave Clock. messages between a Master Clock and Slave Clock.
skipping to change at page 6, line 30 skipping to change at page 6, line 30
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 includes the ability to ignore PTP messages which can be
identified as improper, and to have redundant sources of time. identified 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]. profile has been demonstrated at the ISPCS Plugfest [ISPCS].
5. Network Technology 5. Network Technology
This PTP profile SHALL operate only in networks characterized by This PTP profile SHALL operate only in networks characterized by
UDP [RFC768] over either IPv4 [RFC791] or IPv6 [RFC2460], as UDP [RFC768] over either IPv4 [RFC791] or IPv6 [RFC8200], as
described by Annexes D and E in [IEEE1588] respectively. If a described by Annexes D and E in [IEEE1588] respectively. If a
network contains both IPv4 and IPv6, then they SHALL be treated as network contains both IPv4 and IPv6, then they SHALL be treated as
separate communication paths. Clocks which communicate using IPv4 separate communication paths. Clocks which communicate using IPv4
can interact with clocks using IPv6 if there is an intermediary can interact with clocks using IPv6 if there is an intermediary
device which simultaneously communicates with both IP versions. A device which simultaneously communicates with both IP versions. A
Boundary Clock might perform this function, for example. A PTP Boundary Clock might perform this function, for example. A PTP
domain SHALL use either IPv4 or IPv6 over a communication path, domain SHALL use either IPv4 or IPv6 over a communication path,
but not both. The PTP system MAY include switches and routers. but not both. The PTP system MAY include switches and routers.
These devices MAY be Transparent Clocks, boundary Clocks, or These devices MAY be Transparent Clocks, boundary Clocks, or
neither, in any combination. PTP Clocks MAY be Preferred Masters, neither, in any combination. PTP Clocks MAY be Preferred Masters,
skipping to change at page 6, line 56 skipping to change at page 6, line 56
since Transparent Clocks are required to change the source address since Transparent Clocks are required to change the source address
of any packet which they alter. In IPv4 networks some clocks of any packet which they alter. In IPv4 networks some clocks
might be hidden behind a NAT, which hides their IP addresses from might be hidden behind a NAT, which hides their IP addresses from
the rest of the network. Note also that the use of NATs may place the rest of the network. Note also that the use of NATs may place
limitations on the topology of PTP networks, depending on the port limitations on the topology of PTP networks, depending on the port
forwarding scheme employed. Details of implementing PTP with NATs forwarding scheme employed. Details of implementing PTP with NATs
are out of scope of this document. are out of scope of this document.
PTP, like NTP, assumes that the one-way network delay for Sync PTP, like NTP, assumes that the one-way network delay for Sync
Messages and Delay Response Messages are the same. When this is Messages and Delay Response Messages are the same. When this is
not true it can cause errors in the transfer of time from the not true it can cause errors in the transfer of time from the
Master to the Slave. It is up to the system integrator to design Master to the Slave. It is up to the system integrator to design
the network so that such effects do not prevent the PTP system the network so that such effects do not prevent the PTP system
from meeting the timing requirements. The details of 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, [G8271]. example, [G8271].
6. Time Transfer and Delay Measurement 6. Time Transfer and Delay Measurement
Master Clocks, Transparent Clocks and Boundary Clocks MAY be Master Clocks, Transparent Clocks and Boundary Clocks MAY be
either one-step clocks or two-step clocks. Slave clocks MUST either one-step clocks or two-step clocks. Slave clocks MUST
support both behaviors. The End to End Delay Measurement Method support both behaviors. The End to End Delay Measurement Method
MUST be used. MUST be used.
skipping to change at page 9, line 46 skipping to change at page 9, line 46
messages are used they MUST also be sent as unicast messages messages are used they MUST also be sent as unicast messages
whenever the message is intended for a specific clock. whenever the message is intended for a specific clock.
13. Forbidden PTP Options 13. Forbidden PTP Options
Clocks operating in the Enterprise Profile SHALL NOT use peer to Clocks operating in the Enterprise Profile SHALL NOT use peer to
peer timing for delay measurement. Grandmaster Clusters are NOT peer timing for delay measurement. Grandmaster Clusters are NOT
ALLOWED. The Alternate Master option is also NOT ALLOWED. Clocks ALLOWED. The Alternate Master option is also NOT ALLOWED. Clocks
operating in the Enterprise Profile SHALL NOT use Alternate operating in the Enterprise Profile SHALL NOT use Alternate
Timescales. Unicast discovery and unicast negotiation SHALL NOT be Timescales. Unicast discovery and unicast negotiation SHALL NOT be
used. used.
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 [IEEE1588] clocks operating in the Default Profile described in [IEEE1588]
Annex J.3. This variant of the Default Profile uses the End to End Annex J.3. This variant of the Default Profile uses the End to End
Delay Measurement Mechanism. In addition, the Default Profile Delay Measurement Mechanism. In addition, the Default Profile
would have to operate over IPv4 or IPv6 networks, and use would have to operate over IPv4 or IPv6 networks, and use
management messages in unicast when those messages are directed at management messages in unicast when those messages are directed at
a specific clock. If either of these requirements are not met than a specific clock. If either of these requirements are not met than
Enterprise Profile clocks will not interoperate with Annex J.3 Enterprise Profile clocks will not interoperate with Annex J.3
Default Profile Clocks. The Enterprise Profile will not Default Profile Clocks. The Enterprise Profile will not
interoperate with the Annex J.4 variant of the Default Profile interoperate with the Annex J.4 variant of the Default Profile
which requires use of the Peer to Peer Delay Measurement Mechanism. which requires use of the Peer to Peer Delay Measurement Mechanism.
Enterprise Profile Clocks will interoperate with clocks operating Enterprise Profile Clocks will interoperate with clocks operating
in other profiles if the clocks in the other profiles obey the in other profiles if the clocks in the other profiles obey the
rules of the Enterprise Profile. These rules MUST NOT be changed rules of the Enterprise Profile. These rules MUST NOT be changed
to achieve interoperability with other profiles. to achieve interoperability with other profiles.
15. Profile Identification 15. Profile Identification
The IEEE 1588 standard requires that all profiles provide the The IEEE 1588 standard requires that all profiles provide the
following identifying information. following identifying information.
PTP Profile: PTP Profile:
Enterprise Profile Enterprise Profile
Version: 1.0 Version: 1.0
Profile identifier: 00-00-5E-00-01-00 Profile identifier: 00-00-5E-00-01-00
This profile was specified by the IETF This 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. Security Considerations 16. Security Considerations
Protocols used to transfer time, such as PTP and NTP can be Protocols used to transfer time, such as PTP and NTP can be
important to security mechanisms which use time windows for keys important to security mechanisms which use time windows for keys
and authorization. Passing time through the networks poses a and authorization. Passing time through the networks poses a
security risk since time can potentially be manipulated. security risk since time can potentially be manipulated.
The use of multiple simultaneous masters, using multiple PTP The use of multiple simultaneous masters, using multiple PTP
domains can mitigate problems from rogue masters and domains can mitigate problems from rogue masters and
man-in-the-middle attacks. See sections 9 and 10. Additional man-in-the-middle attacks. See sections 9 and 10. Additional
security mechanisms are outside the scope of this document. security mechanisms are outside the scope of this document.
PTP native management messages SHOULD not be used, due to the lack PTP native management messages SHOULD not be used, due to the lack
of a security mechanism for this option. Secure management can be of a security mechanism for this option. Secure management can be
obtained using standard management mechanisms which include obtained using standard management mechanisms which include
security, for example NETCONF [NETCONF]. security, for example NETCONF [NETCONF].
General security considerations of time protocols are discussed in General security considerations of time protocols are discussed in
[RFC7384]. [RFC7384].
17. IANA Considerations 17. IANA Considerations
There are no IANA requirements in this specification. There are no IANA requirements in this specification.
18. References 18. References
18.1. Normative References 18.1. Normative References
[IEEE1588] IEEE std. 1588-2008, "IEEE Standard for a [IEEE1588] IEEE std. 1588-2008, "IEEE Standard for a
skipping to change at page 11, line 22 skipping to change at page 11, line 22
[RFC768] Postel, J., "User Datagram Protocol," RFC 768, [RFC768] Postel, J., "User Datagram Protocol," RFC 768,
August, 980. August, 980.
[RFC791] "Internet Protocol DARPA Internet Program Protocol [RFC791] "Internet Protocol DARPA Internet Program Protocol
Specification," RFC 791, September, 1981. Specification," RFC 791, September, 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to [RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119, Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997. March 1997.
[RFC2460] Deering, S., Hinden, R., "Internet Protocol, [RFC8200] Deering, S., Hinden, R., "Internet Protocol,
Version 6 (IPv6) Specification," RFC 2460, Version 6 (IPv6) Specification," RFC 8200,
December, 1998. July, 2017.
18.2. Informative References 18.2. Informative References
[G8271] ITU-T G.8271/Y.1366, "Time and Phase [G8271] ITU-T G.8271/Y.1366, "Time and Phase
Synchronization Aspects of Packet Networks" Synchronization Aspects of Packet Networks"
February, 2012. February, 2012.
[ISPCS] Arnold, D., et. al. "Plugfest Report," [ISPCS] Arnold, D., et. al. "Plugfest Report,"
International Symposium on Precision Clock International Symposium on Precision Clock
Synchronization for Measurement, Control and Synchronization for Measurement, Control and
skipping to change at page 12, line 21 skipping to change at page 12, line 21
USA USA
Email: doug.arnold@meinberg-usa.com Email: doug.arnold@meinberg-usa.com
Heiko Gerstung Heiko Gerstung
Meinberg Funkuhren GmbH & Co. KG Meinberg Funkuhren GmbH & Co. KG
Lange Wand 9 Lange Wand 9
D-31812 Bad Pyrmont D-31812 Bad Pyrmont
Germany Germany
Email: Heiko.gerstung@meinberg.de Email: heiko.gerstung@meinberg.de
 End of changes. 17 change blocks. 
35 lines changed or deleted 35 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/