draft-ietf-tictoc-ptp-enterprise-profile-01.txt   draft-ietf-tictoc-ptp-enterprise-profile-02.txt 
Internet-Draft Enterprise Profile for PTP November 2013 Internet-Draft Enterprise Profile for PTP February 2014
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: May 22, 2014 Nov 23, 2013 Expires: August 10, 2014 Feb 11, 2014
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-01.txt draft-ietf-tictoc-ptp-enterprise-profile-02.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 1, line 38 skipping to change at page 1, line 38
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 22, 2014. This Internet-Draft will expire on August 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
skipping to change at page 2, line 17 skipping to change at page 2, line 17
This document describes a profile for the use of the Precision This document describes a 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 profile uses the End to End Delay Measurement environment. The 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.
Table of Contents Table of Contents
1. Introduction 2 1. Introduction 2
2. Conventions used in this document 3 2. Conventions used in this document 3
3. Technical Terms 4 3. Technical Terms 3
4. Problem Statement 5 4. Problem Statement 5
5. Network Technology 6 5. Network Technology 6
6. Time Transfer and Delay Measurement 7 6. Time Transfer and Delay Measurement 7
6.1. Unicast Delay Measurement Mode 7 7. Default Message Rates 7
6.2. Multicast Delay Measurement Mode 7 8. Requirements for Master Clocks 7
6.3. Hybrid delay Measurement Mode 8 9. Requirements for Slave Clocks 9
7. Default Message Rates 8 10. Requirements for Transparent Clocks 9
8. Requirements for Master Clocks 8 11. Management and Signaling Messages 9
9. Requirements for Slave Clocks 10 12. Forbidden PTP Options 10
10. Requirements for Transparent Clocks 10 13. Interoperation with Other PTP Profiles 10
11. Management and Signaling Messages 10 14. Security Considerations 10
12. Forbidden PTP Options 11 15. IANA Considerations 11
13. Interoperation with Other PTP Profiles 11 16. References 11
14. Security Considerations 11 16.1. Normative References 11
15. IANA Considerations 12 16.2. Informative References 11
16. References 12 17. Acknowledgments 11
16.1. Normative References 12 18. Authors addresses 12
16.2. Informative References 12
17. Acknowledgments 13
18. Authors addresses 13
1. Introduction 1. Introduction
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).
skipping to change at page 4, line 32 skipping to change at page 4, line 20
identifying which of several PTP Master capable clocks is the best identifying which of several PTP Master capable clocks is the best
master. Clocks have priority to become the acting Grandmaster, master. Clocks have priority to become the acting Grandmaster,
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 an 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 the assigned to each PTP clock which must be unique. Often the
Ethernet MAC address is used since there is already an Ethernet MAC address is used 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
treated as seperate PTP systems in the network. Slaves, however,
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.
Grandmaster: the primary master clock within a domain of a PTP Grandmaster: the primary master clock within a domain of a PTP
system 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.
skipping to change at page 7, line 39 skipping to change at page 7, line 20
MUST be used. MUST be used.
Note that, in IP networks, Sync messages and Delay Request Note that, in IP networks, Sync messages and Delay Request
messages exchanged between a master and slave do not necessarily messages exchanged between a master and slave do not necessarily
traverse the same physical path. Thus, wherever possible, the traverse the same physical path. Thus, wherever possible, the
network SHOULD be traffic engineered so that the forward and network SHOULD be traffic engineered so that the forward and
reverse routes traverse the same physical path. Traffic reverse routes traverse the same physical path. Traffic
engineering techniques for path consistency are out of scope of engineering techniques for path consistency are out of scope of
this document. this document.
In all three of the delay measurement modes, Sync messages MUST Sync messages MUST be sent as PTP event multicast messages (UDP
be sent as PTP event multicast messages (UDP port 319) to the PTP port 319) to the PTP primary IP address. Two step clocks SHALL
primary IP address. Two step clocks SHALL send Follow-up send Follow-up messages as PTP general messages (UDP port 320).
messages as PTP general messages (UDP port 320). Announce messages Announce messages MUST be sent as multicast messages (UDP port 320)
MUST be sent as multicast messages (UDP port 320) to the PTP to the PTP primary address. The PTP primary IP address is
primary address. The PTP primary IP address is 224.0.1.129 for 224.0.1.129 for IPv4 and FF0X:0:0:0:0:0:0:181 for Ipv6, where X can
IPv4 and FF0X:0:0:0:0:0:0:181 for Ipv6, where X can be a value be a value between 0x0 and 0xF, see [IEEE1588] Annex E, Section
between 0x0 and 0xF, see [IEEE1588] Annex E, Section E.3. E.3.
6.1. Unicast Delay Measurement Mode
All Delay Request PTP event messages and Delay Response PTP
general messages MUST be sent as unicast messages. Unicast
Discovery and Unicast Message Negotiation options MUST NOT be
utilized.
6.2. Multicast Delay Measurement Mode
All Delay Request PTP event messages and Delay Response general
messages MUST be sent as multicast messages.
6.3. Hybrid Delay Measurement Mode
Delay Request Messages MAY be sent as either multicast or unicast Delay Request Messages MAY be sent as either multicast or unicast
PTP event messages. Master clocks SHALL respond to multicast Delay PTP event messages. Master clocks SHALL respond to multicast Delay
Request messages with multicast Delay Response PTP general Request messages with multicast Delay Response PTP general
messages. Master clocks SHALL respond to unicast Delay Request PTP messages. Master clocks SHALL respond to unicast Delay Request PTP
event messages with unicast Delay Response PTP general messages. event messages with unicast Delay Response PTP general messages.
This allow for the use of Ordinary clocks which do not support the
The default mode for Enterprise Profile PTP Master Clocks is Enterprise Profile, as long as they are slave Only Clocks.
Hybrid Delay Measurement Mode. This allow for the use of Ordinary
clocks which do not support the Enterprise Profile, as long as
they are slave Only Clocks.
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 SHALL
each be once per second. The Sync and Delay Request message rates each be once per second. The Sync and Delay Request message rates
MAY be set to other values, but not less than once every 128 MAY be set to other values, but not less than once every 128
seconds, and not more than 128 messages per second. The Announce seconds, and not more than 128 messages per second. The Announce
message rate SHALL NOT be changed from the default value. The message rate SHALL NOT be changed from the default value. The
Announce Receipt Timeout Interval SHALL be three Announce Announce Receipt Timeout Interval SHALL be three Announce
Intervals for Preferred Masters, and four Announce Intervals for Intervals for Preferred Masters, and four Announce Intervals for
all other masters. all other masters. Unicast Discovery and Unicast Message
Negotiation options MUST NOT be utilized.
8. Requirements for Master Clocks 8. Requirements for Master Clocks
Master clocks SHALL obey the standard Best Master Clock Algorithm Master clocks SHALL obey the standard Best Master Clock Algorithm
from [IEEE1588]. Clocks which are master capable MAY act as from [IEEE1588]. PTP systems using this profile MAY support
Alternate masters according to [IEEE1588]. Preferred Master multiple simultaneous Grandmasters as long as each active
Clocks SHOULD operate as Alternate Masters when they are not the Grandmaster is operating in a different PTP domain. When Preferred
Best Master. Using multiple masters can mitigate rogue master and Master Clocks are not the Best Master in one domain, they SHOULD
man-in-the-middle attacks such as delay attacks, packet operate in another domain when they. Using multiple masters can
interception / manipulation attacks. Assuming the path to each mitigate rogue master and man-in-the-middle attacks such as delay
master is different, an attacker would have to attack more than attacks, packet interception / manipulation attacks. Assuming the
one path simultaneously. path to each master is different, an attacker would have to attack
more than one path simultaneously.
A port of a clock SHALL NOT be in the master state unless the A port of a clock SHALL NOT be in the master state unless the
clock has a current value for the number of UTC leap clock has a current value for the number of UTC leap
seconds. A clock with a port in the master state SHOULD indicate seconds. A clock with a port in the master state SHOULD indicate
the maximum adjustment to its internal clock within one sync the maximum adjustment to its internal clock within one sync
interval. The maximum phase adjustment is indicated in the interval. The maximum phase adjustment is indicated in the
Enterprise Profile announce TLV field for Maximum Phase Adjustment. Enterprise Profile announce TLV field for Maximum Phase Adjustment.
The Announce Messages SHALL include a TLV which indicates that the The Announce Messages SHALL include a TLV which indicates that the
clock is operating in the Enterprise Profile. The TLV shall have clock is operating in the Enterprise Profile. The TLV shall have
the following structure: the following structure:
TLV Type (Enumeration16): ORGANIZATION_EXTENSION value = 0003 hex TLV Type (Enumeration16): ORGANIZATION_EXTENSION value = 0003 hex
Length Field (UInteger16): value = 12. The number of TLV octets Length Field (UInteger16): value = 10. The number of TLV octets
Port Number (UInteger16): The Port Number of the port transmitting Port Number (UInteger16): The Port Number of the port transmitting
the TLV. The all-ones Port Number, with value FFFFhex, is used to the TLV. The all-ones Port Number, with value FFFFhex, is used to
indicate that the identified profile is applicable to all ports on indicate that the identified profile is applicable to all ports on
the clock. the clock.
Organization Unique Identifier (3 Octets): The Organization ID Organization Unique Identifier (3 Octets): The Organization ID
value for IETF assigned by IEEE = 00005Ehex value for IETF assigned by IEEE = 00005Ehex
IETF Profile number (UInteger16): value = 1 IETF Profile number (UInteger8): value = 1
Revision number (UInteger8): value = 1 Revision number (UInteger8): value = 1
Delay Measurement Mode (Enumeration8):
Value 0 = Multicast Delay Measurement Mode
Value 1 = Unicast Delay Measurement Mode
Value 2 = Hybrid Delay Measurement Mode
Values 3-255 = reserved for future use.
Maximum Absolute Phase Adjustment Value within one sync interval Maximum Absolute Phase Adjustment Value within one sync interval
(UInteger16): value (UInteger16): value
Maximum Phase Adjustment Units (Enumeration8): Maximum Phase Adjustment Units (Enumeration8):
Value 0 = unknown Value 0 = unknown
Value 1 = seconds Value 1 = seconds
Value 3 = milliseconds Value 3 = milliseconds
Value 6 = microseconds Value 6 = microseconds
Value 9 = nanoseconds Value 9 = nanoseconds
Value 12 = picoseconds Value 12 = picoseconds
Value 15 = femtoseconds Value 15 = femtoseconds
All other values reserved for future use All other values reserved for future use
The TLV represents the Delay Request Mode of the Master, not Slaves can use the Maximum Phase Adjustment to determine if the
necessarily the Grandmaster. So for example, one port of a clock is slewing to rapidly for the applications which are of
Boundary clock could be set to Unicast Delay Measurement Mode, interest. For example if the clock set by slave is used to
while the rest of the network is Hybrid Delay Measurement Mode. measure time intervals then it might be desired that that the
amount which the time changes during the intervals is limited.
9. Requirements for Slave Clocks 9. Requirements for Slave Clocks
Slave clocks MUST be able to operate properly in a network which Slave clocks MUST be able to operate properly in a network which
contains Alternate Masters. Slaves SHOULD make use of information contains multiple Masters in multiple domains. Slaves SHOULD make
from the Alternate Masters in their clock control subsystems. use of information from the all Masters in their clock control
Slave Clocks MUST be able to operate properly in the presence of a subsystems. Slave Clocks MUST be able to operate properly in the
Rogue Master. Slaves SHOULD NOT Synchronize to a Rogue Master. presence of a Rogue Master. Slaves SHOULD NOT Synchronize to a
Slaves MAY use an Acceptable Master Table. If the Best Master is Master which is not the Best Master in its domain. Slaves will
not an Acceptable Master, but an Alternate Master is an Acceptable continue to recognize a Best Master for the duration of the
Master, then the Slave SHOULD synchronize to the acceptable Announce Time Out Interval. Slaves MAY use an Acceptable Master
Alternate Master. Note that IEEE 1588-2008 requires slave clocks to Table. If a Master is not an Acceptable Master, then the Slave
support both two-step or one-step Master clocks. See [IEEE1588], MUST NOT synchronize to it. Note that IEEE 1588-2008 requires
section 11.2. slave clocks to support both two-step or one-step Master clocks.
See [IEEE1588], section 11.2.
Since Announce messages are sent as multicast messages in all Since Announce messages are sent as multicast messages slaves can
mode, slaves can obtain the IP addresses of master from the obtain the IP addresses of master from the Announce messages. Note
Announce messages. Note that the IP source addresses of Sync and that the IP source addresses of Sync and Follow-up messages may
Follow-up messages may have been replaced by the source addresses have been replaced by the source addresses of a transparent clock,
of a transparent clock, so slaves MUST send Delay Request messages so slaves MUST send Delay Request messages to the IP address in the
to the IP address in the Announce message. Sync and Follow-up Announce message. Sync and Follow-up messages can be correlated
messages can be correlated with the Announce message using the with the Announce message using the clock ID, which is never
clock ID, which is never altered by Transparent clocks. altered by Transparent clocks in this profile.
10. Requirements for Transparent Clocks 10. Requirements for Transparent Clocks
Transparent clocks SHALL NOT change the transmission mode of an Transparent clocks SHALL 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. SHALL NOT change a unicast message to a multicast message.
Transparent clocks SHALL NOT alter the Enterprise Profile TLV of Transparent clocks SHALL NOT alter the Enterprise Profile TLV of
an Announce message, or any other part of an Announce message. an Announce message, or any other part of an Announce message.
Transparent Clocks SHOULD support multiple domains.
11. Management and Signaling Messages 11. Management and Signaling Messages
PTP Management messages MAY be used. Any PTP management message PTP Management messages MAY be used. Any PTP management message
which is sent with the targetPortIdentity.clockIdentity set to all which is sent with the targetPortIdentity.clockIdentity set to all
1s (all clocks) MUST be sent as a multicast message. Management 1s (all clocks) MUST be sent as a multicast message. Management
messages with any other value of for the Clock Identity is messages with any other value of for the Clock Identity is
intended for a specific clock and MUST be sent as a unicast intended for a specific clock and MUST be sent as a unicast
message. Similarly, if any signaling messages are used they message. Similarly, if any signaling messages are used they
MUST also be sent as unicast messages whenever the message is MUST also be sent as unicast messages whenever the message is
intended for a specific clock. intended for a specific clock.
12. Forbidden PTP Options 12. 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. Clocks operating in the peer timing for delay measurement. Clocks operating in the
Enterprise Profile SHALL NOT use Unicast Message Negotiation to Enterprise Profile SHALL NOT use Unicast Message Negotiation to
determine message rates. Slave clocks operating in the Enterprise determine message rates. Slave clocks operating in the Enterprise
Profile SHALL NOT use Unicast Discovery to establish connection to Profile SHALL NOT use Unicast Discovery to establish connection to
Master clocks. Grandmaster Clusters are NOT ALLOWED. Clocks Master clocks. Grandmaster Clusters are NOT ALLOWED. The Alternate
operating in the Enterprise Profile SHALL NOT use Alternative Time Master option is also forbidden. Clocks operating in the Enterprise
Scales. Profile SHALL NOT use Alternate Timescales.
13. Interoperation with Other PTP Profiles 13. Interoperation with Other PTP Profiles
Clocks operating in the Enterprise profile will not interoperate Clocks operating in the Enterprise profile will not interoperate
with clocks operating in the Power Profile [C37.238], because the with clocks operating in the Power Profile [C37.238], because the
Enterprise Profile requires the End to End Delay Measurement Enterprise Profile requires the End to End Delay Measurement
Mechanism and the Power Profile requires the Peer to Peer Delay Mechanism and the Power Profile requires the Peer to Peer Delay
Measurement Mechanism. Measurement Mechanism.
skipping to change at page 12, line 4 skipping to change at page 10, line 52
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.
14. Security Considerations 14. 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 the IEEE 1588 domains can mitigate problems from rogue masters and
Alternate Master option can mitigate problems from rogue masters man-in-the-middle attacks. See sections 9 and 10. Additional
and 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.
15. IANA Considerations 15. IANA Considerations
There are no IANA requirements in this specification. There are no IANA requirements in this specification.
16. References 16. References
16.1. Normative References 16.1. Normative References
skipping to change at page 13, line 10 skipping to change at page 11, line 53
[NTP] Mills, D., Martin, J., Burbank, J., Kasch, W., [NTP] Mills, D., Martin, J., Burbank, J., Kasch, W.,
"Network Time Protocol Version 4: Protocol and "Network Time Protocol Version 4: Protocol and
Algorithms Specification," RFC 5905, June 2010. Algorithms Specification," RFC 5905, June 2010.
17. Acknowledgments 17. Acknowledgments
The authors would like to thank members of IETF for reviewing and The authors would like to thank members of IETF for reviewing and
providing feedback on this draft. providing feedback on this draft.
This document was prepared using 2-Word-v2.0.template.dot. This document was initially prepared using
2-Word-v2.0.template.dot.
18. Authors' Addresses 18. Authors' Addresses
Doug Arnold Doug Arnold
Meinberg USA Meinberg USA
228 Windsor River Rd 228 Windsor River Rd
Windsor, CA 95492 Windsor, CA 95492
USA USA
Email: doug.arnold@meinberg-usa.com Email: doug.arnold@meinberg-usa.com
 End of changes. 23 change blocks. 
98 lines changed or deleted 81 lines changed or added

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