draft-ietf-tictoc-ptp-enterprise-profile-05.txt   draft-ietf-tictoc-ptp-enterprise-profile-06.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: August 4, 2015 Feb 4, 2015 Expires: July 22, 2016 Jan 22, 2016
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-05.txt draft-ietf-tictoc-ptp-enterprise-profile-06.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 37 skipping to change at page 1, line 37
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 Agust 4, 2015. This Internet-Draft will expire on Agust 4, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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 8, line 14 skipping to change at page 8, line 14
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. Unicast Discovery and Unicast Message all other masters.
Negotiation options MUST NOT be utilized.
Unicast Discovery and Unicast Message Negotiation options MAY be
utilized. If Unicat Negotiation is not used, operators will need
to set a delay request interval, or make use of a default value.
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]. PTP systems using this profile MAY support from [IEEE1588]. PTP systems using this profile MAY support
multiple simultaneous Grandmasters as long as each active multiple simultaneous Grandmasters as long as each active
Grandmaster is operating in a different PTP domain. Grandmaster is operating in a different PTP domain.
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.
the maximum adjustment to its internal clock within one sync
interval. The maximum phase adjustment is indicated in the
Enterprise Profile announce TLV field for Maximum Phase Adjustment.
The Announce Messages SHALL include a TLV which indicates that the
clock is operating in the Enterprise Profile. The TLV shall have
the following structure:
TLV Type (Enumeration16): ORGANIZATION_EXTENSION value = 0003 hex
Length Field (UInteger16): value = 10. The number of TLV octets
Organization Unique Identifier (3 Octets): The Organization ID
value for IETF assigned by IEEE = 00005Ehex
IETF Profile number (UInteger8): value = 1
Revision number (UInteger8): value = 1
Port Number (UInteger16): The Port Number of the port transmitting
the TLV. The all-ones Port Number, with value FFFFhex, is used to
indicate that the identified profile is applicable to all ports on
the clock.
Maximum Absolute Phase Adjustment Value within one sync interval
(UInteger16): value
Maximum Phase Adjustment Units (Enumeration8):
Value 0 = unknown
Value 1 = seconds
Value 3 = milliseconds
Value 6 = microseconds
Value 9 = nanoseconds
Value 12 = picoseconds
Value 15 = femtoseconds
All other values reserved for future use
Slaves can use the Maximum Phase Adjustment to determine if the
clock is slewing to rapidly for the applications which are of
interest. For example if the clock set by slave is used to
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 multiple Masters in multiple domains. Slaves SHOULD make contains multiple Masters in multiple domains. Slaves SHOULD make
use of information from the all Masters in their clock control use of information from the all Masters in their clock control
subsystems. Slave Clocks MUST be able to operate properly in the subsystems. Slave Clocks MUST be able to operate properly in the
presence of a Rogue Master. Slaves SHOULD NOT Synchronize to a presence of a Rogue Master. Slaves SHOULD NOT Synchronize to a
Master which is not the Best Master in its domain. Slaves will Master which is not the Best Master in its domain. Slaves will
continue to recognize a Best Master for the duration of the continue to recognize a Best Master for the duration of the
skipping to change at page 9, line 49 skipping to change at page 9, line 19
so slaves MUST send Delay Request messages to the IP address in the so slaves MUST send Delay Request messages to the IP address in the
Announce message. Sync and Follow-up messages can be correlated Announce message. Sync and Follow-up messages can be correlated
with the Announce message using the clock ID, which is never with the Announce message using the clock ID, which is never
altered by Transparent clocks in this profile. 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
an Announce message, or any other part of an Announce message.
Transparent Clocks SHOULD support multiple domains. Transparent Transparent Clocks SHOULD support multiple domains. Transparent
Clocks which syntonize to the master clock will need to maintain Clocks which syntonize to the master clock will need to maintain
separate clock rate offsets for each of the supported domains. separate clock rate offsets for each of the 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 servo loops for each of the This will require them to maintain servo loops 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.
skipping to change at page 10, line 26 skipping to change at page 9, line 44
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.
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. Clocks operating in the peer timing for delay measurement. Grandmaster Clusters are NOT
Enterprise Profile SHALL NOT use Unicast Message Negotiation to ALLOWED. The Alternate Master option is also forbidden. Clocks
determine message rates. Slave clocks operating in the Enterprise operating in the Enterprise Profile SHALL NOT use Alternate
Profile SHALL NOT use Unicast Discovery to establish connection to Timescales.
Master clocks. Grandmaster Clusters are NOT ALLOWED. The Alternate
Master option is also forbidden. Clocks operating in the Enterprise
Profile SHALL NOT use Alternate Timescales.
14. Interoperation with Other PTP Profiles
Clocks operating in the Enterprise Profile will not interoperate
with clocks operating in the Power Profile [C37.238], because the
Enterprise Profile requires the End to End Delay Measurement
Mechanism and the Power Profile requires the Peer to Peer Delay
Measurement Mechanism.
Clocks operating in the Enterprise Profile will not interoperate 14. Interoperation with IEEE 1588 Default Profile
with clocks operating in the Telecom Profile for Frequency
Synchronization[G8265.1], because the Enterprise Profile forbids
Unicast Message Negotiation. This feature is part of the default
manner of operation for the Telecom Profile for Frequency
Synchronization.
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 would Delay Measurement Mechanism. In addition the Default Profile would
have to operates over IPv4 or IPv6 networks, and use management have to operates over IPv4 or IPv6 networks, and use management
messages in unicast when those messages are directed at a specific messages in unicast when those messages are directed at a specific
clock. If either of these requirements are not met than Enterprise clock. If either of these requirements are not met than Enterprise
Profile clocks will not interoperate with Annex J.3 Default Profile Profile clocks will not interoperate with Annex J.3 Default Profile
Clocks. The Enterprise Profile Profile will will not interoperate Clocks. The Enterprise Profile Profile will will not interoperate
skipping to change at page 12, line 7 skipping to change at page 11, line 28
[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, [RFC2460] Deering, S., Hinden, R., "Internet Protocol,
Version 6 (IPv6) Specification," RFC 2460, Version 6 (IPv6) Specification," RFC 2460,
December, 1998. December, 1998.
17.2. Informative References 17.2. Informative References
[C37.238] IEEE std. C37.238-2011, "IEEE Standard Profile for
Use of IEEE 1588 Precision Time Protocol in Power
System Applications," July 2011.
[G8265.1] ITU-T G.8265.1/Y.1365.1, "Precision time protocol
telecom profile for frequency synchronization,"
October 2011.
[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.
[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.
18. Acknowledgments 18. 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 initially prepared using This document was initially prepared using
2-Word-v2.0.template.dot. 2-Word-v2.0.template.dot.
19. Authors' Addresses 19. Authors' Addresses
Doug Arnold Doug Arnold
Meinberg USA Meinberg USA
228 Windsor River Rd 929 Salem End Road
Windsor, CA 95492 Framingham, MA 01702
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
 End of changes. 11 change blocks. 
81 lines changed or deleted 17 lines changed or added

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