draft-ietf-tictoc-ptp-enterprise-profile-00.txt   draft-ietf-tictoc-ptp-enterprise-profile-01.txt 
Internet-Draft Enterprise Profile for PTP November 2013
TICTOC Working Group Doug Arnold TICTOC Working Group Doug Arnold
Internet Draft Internet Draft Meinberg-USA
Intended status: Standards Track Heiko Gerstung Intended status: Standards Track Heiko Gerstung
Meinberg Meinberg
Expires: January 2014 July 5, 2013 Expires: May 22, 2014 Nov 23, 2013
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-00.txt draft-ietf-tictoc-ptp-enterprise-profile-01.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 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 January 5, 2014. This Internet-Draft will expire on May 22, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Abstract Abstract
This document describes a profile for the use of the Precision
Time Protocol in an IPV4 or IPv6 Enterprise information system This document describes a profile for the use of the Precision
environment. The profile uses the End to End Delay Measurement Time Protocol in an IPV4 or IPv6 Enterprise information system
Mechanism, allows both multicast and unicast Delay Request and Delay environment. The profile uses the End to End Delay Measurement
Response Messages. Mechanism, allows both multicast and unicast Delay Request and Delay
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 3 3. Technical Terms 4
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 6.1. Unicast Delay Measurement Mode 7
6.2. Multicast Delay Measurement Mode 8 6.2. Multicast Delay Measurement Mode 7
6.3. Hybrid delay Measurement Mode 8 6.3. Hybrid delay Measurement Mode 8
7. Default Message Rates 8 7. Default Message Rates 8
8. Timing Domains 8 8. Requirements for Master Clocks 8
9. Requirements for Master Clocks 8 9. Requirements for Slave Clocks 10
10. Requirements for Slave Clocks 9 10. Requirements for Transparent Clocks 10
11. Requirements for Transparent Clocks 10 11. Management and Signaling Messages 10
12. Management and Signaling Messages 10 12. Forbidden PTP Options 11
13. Forbidden PTP Options 10 13. Interoperation with Other PTP Profiles 11
14. Interoperation with Other PTP Profiles 10 14. Security Considerations 11
15. Security Considerations 11 15. IANA Considerations 12
16. IANA Considerations 11 16. References 12
17. References 11 16.1. Normative References 12
17.1. Normative References 11 16.2. Informative References 12
17.2. Informative References 12 17. Acknowledgments 13
18. Acknowledgments 12 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).
The so-called "Best Master Clock Algorithm" ([IEEE1588] Clause The so-called "Best Master Clock Algorithm" ([IEEE1588] Clause
9.3), a mechanism that all participating PTP nodes must follow, 9.3), a mechanism that all participating PTP nodes must follow,
set up strict rules for all members of a PTP domain to determine set up strict rules for all members of a PTP domain to determine
which node shall be the active sending time source (Master Clock). which 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
skipping to change at page 5, line 17 skipping to change at page 5, line 17
messages between adjacent devices in a network. messages between adjacent devices in a network.
Preferred Master: A device intended to act primarily as the Preferred Master: A device intended to act primarily as the
Grandmaster of a PTP system, or as a back up to a Grandmaster. 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 define by IEEE 1588. protocol define 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 a Unicast slave which talks to several Grandmaster for example a unicast slave which talks to several Grandmaster
clocks in parallel. clocks in parallel.
PTPv2: Refers specifically to the second version of PTP defined by PTPv2: Refers specifically to the second version of PTP defined by
IEEE 1588-2008. IEEE 1588-2008.
Rogue Master: A clock with a port in the master state, even though Rogue Master: A clock with a port in the master state, even though
it should not be in the master state according to the Best Master it should not be in the master state according to the Best Master
Clock Algorithm, and does not set the alternate master flag. Clock Algorithm, and does not set the alternate master flag.
Slave clock: a clock with at least one port in the slave state, Slave clock: a clock with at least one port in the slave state,
skipping to change at page 5, line 51 skipping to change at page 5, line 51
unicast communication with PTP masters using a configures table of unicast communication with PTP masters using a configures table of
master IP addresses and Unicast Message Negotiation. master IP addresses and Unicast Message Negotiation.
Unicast Negotiation: A mechanism in PTP for Slave Clocks to Unicast Negotiation: A mechanism in PTP for Slave Clocks to
negotiate unicast Sync, announce and Delay Request Message Rates negotiate unicast Sync, announce and Delay Request Message Rates
from a Master Clock. from a Master Clock.
4. Problem Statement 4. Problem Statement
This document describes a version of PTP intended to work in large This document describes a version of PTP intended to work in large
enterprise networks. Such networks are deployed, for example in enterprise networks. Such networks are deployed, for example, in
financial corporations. It is becoming increasingly common in financial corporations. It is becoming increasingly common in such
such networks to perform distributed time tagged measurements, networks to perform distributed time tagged measurements, such as
such as one-way packet latencies and cumulative delays on software one-way packet latencies and cumulative delays on software
systems spread across multiple computers. Furthermore there is systems spread across multiple computers. Furthermore there is
often a desire to check the age of information time tagged by a often a desire to check the age of information time tagged by a
different machine. To perform these measurements it is necessary different machine. To perform these measurements it is necessary
to deliver a common precise time to multiple devices on a network. to deliver a common precise time to multiple devices on a network.
Accuracy currently required in the Financial Industry range from
Accuracy currently required can be as tight as within 1 100 microseconds to 500 nanoseconds to the Grandmaster. This
microseconds to the Grandmaster. This profile does not specify profile does not specify timing performance requirements, but such
timing performance requirements, but such requirements explain why requirements explain why the needs cannot always be met by NTP, as
the needs cannot always be met by NTP, as commonly implemented. commonly implemented. Such accuracy cannot usually be achieved with
Such accuracy cannot usually be achieved with a traditional time a traditional time transfer such as NTP, without adding
transfer such as NTP, without adding non-standard customizations non-standard customizations such as hardware time stamping, and on
such as hardware time stamping, fast message rates, non-linear path support. These features are currently part of PTP, or are
servo loops, and on path support. These features are currently allowed by it. Because PTP has a complex range of features and
part of PTP, or are allowed by it. Because PTP has a complex range options it is necessary to create a profile for enterprise
of features and options it is necessary to create a profile for networks to achieve interoperability between equipment
enterprise networks to achieve interoperability between equipment
manufactured by different vendors. 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 multicast whenever the information going to many destinations is
the same. It is also advantageous to send information which is the same. It is also advantageous to send information which is
unique to one device as a unicast message. The latter can be unique to one device as a unicast message. The latter can be
essential as the number of PTP slaves becomes hundreds or essential as the number of PTP slaves becomes hundreds or
thousands. thousands.
skipping to change at page 7, line 15 skipping to change at page 7, line 18
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.
Similar to NTP, PTP makes the assumption that the one way network Similar to NTP, PTP makes the assumption that the one way network
delay for Sync Messages and Delay Response Messages are the same. delay for Sync Messages and Delay Response Messages are the same.
When this is not true it can cause errors in the transfer of time When this is not true it can cause errors in the transfer of time
from the Master to the Slave. It is up to system integrator to from the Master to the Slave. It is up to the system integrator to
design the network so that such effects do not prevent the PTP design the network so that such effects do not prevent the PTP
system from meeting the timing requirements. The details of system from meeting the timing requirements. The details of
network asymmetry are outside the scope of this document. See for network asymmetry are outside the scope of this document. See for
example, [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
skipping to change at page 7, line 42 skipping to change at page 7, line 45
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 In all three of the delay measurement modes, Sync messages MUST
be sent as PTP event multicast messages (UDP port 319) to the PTP be sent as PTP event multicast messages (UDP port 319) to the PTP
primary IP address. Two step clocks SHALL send Follow-up primary IP address. Two step clocks SHALL send Follow-up
messages as PTP general messages (UDP port 320). Announce messages messages as PTP general messages (UDP port 320). Announce messages
MUST be sent as multicast messages (UDP port 320) to the PTP MUST be sent as multicast messages (UDP port 320) to the PTP
primary address. The PTP primary IP address is 224.0.1.129 for 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. IPv4 and FF0X:0:0:0:0:0:0:181 for Ipv6, where X can be a value
between 0x0 and 0xF, see [IEEE1588] Annex E, Section E.3.
6.1. Unicast Delay Measurement Mode 6.1. Unicast Delay Measurement Mode
All Delay Request PTP event messages and Delay Response PTP All Delay Request PTP event messages and Delay Response PTP
general messages MUST be sent as unicast messages. Unicast general messages MUST be sent as unicast messages. Unicast
Discovery and Unicast Message Negotiation options MUST NOT be Discovery and Unicast Message Negotiation options MUST NOT be
utilized. utilized.
6.2. Multicast Delay Measurement Mode 6.2. Multicast Delay Measurement Mode
All Delay Request PTP event messages and Delay Response general All Delay Request PTP event messages and Delay Response general
messages MUST be sent as multicast messages. messages MUST be sent as multicast messages.
6.3. Hybrid delay Measurement Mode 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.
The default mode for Enterprise Profile PTP Master Clocks is The default mode for Enterprise Profile PTP Master Clocks is
Hybrid Delay Measurement Mode. This allow for the use of Ordinary Hybrid Delay Measurement Mode. This allow for the use of Ordinary
clocks which do not support the Enterprise Profile, as long as clocks which do not support the Enterprise Profile, as long as
skipping to change at page 8, line 34 skipping to change at page 8, line 29
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.
8. Timing Domains 8. Requirements for Master Clocks
All Master Clocks in the Enterprise Profile SHALL operate with the
PTP timing domain set in the range 0-3 when any part of the domain
is operating in either the Multicast Delay Measurement Mode, or
the Hybrid Delay Measurement Mode. The default timing domain for
operation with this configuration is Domain 0. All Master Clocks
in the Enterprise Profile SHOULD operate with the PTP timing
domain set in the range 40-60 when the entire domain is acting in
the Unicast Delay Measurement Mode. The default timing domain for
this configuration is Domain 40. If it is not known in advance
which modes will be operating in a domain, then domains 0-3 SHOULD
be used.
9. 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]. Clocks which are master capable MAY act as
Alternate masters according to [IEEE1588]. Preferred Master Alternate masters according to [IEEE1588]. Preferred Master
Clocks SHOULD operate as Alternate Masters when they are not the Clocks SHOULD operate as Alternate Masters when they are not the
Best Master. Using multiple masters can mitigate rogue master and Best Master. Using multiple masters can mitigate rogue master and
man-in-the-middle attacks such as delay attacks, packet man-in-the-middle attacks such as delay attacks, packet
interception / manipulation attacks. Assuming the path to each interception / manipulation attacks. Assuming the path to each
master is different, an attacker would have to attack more than master is different, an attacker would have to attack more than
one path simultaneously. one path simultaneously.
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
seconds. A clock with a port in the master state SHOULD indicate
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 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 = 2. The number of octets in the Length Field (UInteger16): value = 12. The number of TLV octets
Data Field
Organization Id (3 Octets): The Organization ID value for the IETF Port Number (UInteger16): The Port Number of the port transmitting
assigned by IEEE = TBD 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.
Organization SubType (Enumeration24) value = 000001hex (Enterprise Organization Unique Identifier (3 Octets): The Organization ID
PTP Profile version 1) value for IETF assigned by IEEE = 00005Ehex
Data Field, Delay Measurement Mode (Enumeration16): IETF Profile number (UInteger16): value = 1
Value 00hex = Multicast Delay Measurement Mode Revision number (UInteger8): value = 1
Value 01hex = Unicast Delay Measurement Mode 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.
Value 02hex = Hybrid Delay Measurement Mode Maximum Absolute Phase Adjustment Value within one sync interval
(UInteger16): value
Values 03-FFhex = reserved for future use. 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
The TLV represents the Delay Request Mode of the Master, not The TLV represents the Delay Request Mode of the Master, not
necessarily the Grandmaster. So for example, one port of a necessarily the Grandmaster. So for example, one port of a
Boundary clock could be set to Unicast Delay Measurement Mode, Boundary clock could be set to Unicast Delay Measurement Mode,
while the rest of the network is Hybrid Delay Measurement Mode. while the rest of the network is Hybrid Delay Measurement Mode.
10. 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 Alternate Masters. Slaves SHOULD make use of information
from the Alternate Masters in their clock control subsystems. from the Alternate Masters in their clock control subsystems.
Slave Clocks MUST be able to operate properly in the presence of a Slave Clocks MUST be able to operate properly in the presence of a
Rogue Master. Slaves SHOULD NOT Synchronize to a Rogue Master. Rogue Master. Slaves SHOULD NOT Synchronize to a Rogue Master.
Slaves MAY use an Acceptable Master Table. If the Best Master is Slaves MAY use an Acceptable Master Table. If the Best Master is
not an Acceptable Master, but an Alternate Master is an Acceptable not an Acceptable Master, but an Alternate Master is an Acceptable
Master, then the Slave SHOULD synchronize to the acceptable Master, then the Slave SHOULD synchronize to the acceptable
Alternate Master. Alternate Master. Note that IEEE 1588-2008 requires slave clocks to
support both two-step or one-step Master clocks. See [IEEE1588],
Note that IEEE 1588-2008 requires slave clocks to support both section 11.2.
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 in all
mode, slaves can obtain the IP addresses of master from the mode, slaves can obtain the IP addresses of master from the
Announce messages. Note that the IP source addresses of Sync and Announce messages. Note that the IP source addresses of Sync and
Follow-up messages may have been replaced by the source addresses Follow-up messages may have been replaced by the source addresses
of a transparent clock, so slaves MUST send Delay Request messages of a transparent clock, so slaves 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 messages can be correlated with the Announce message using the
clock ID, which is never altered by Transparent clocks. clock ID, which is never altered by Transparent clocks.
11. 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.
12. 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.
13. 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. Clocks
operating in the Enterprise Profile SHALL NOT use Alternative Time operating in the Enterprise Profile SHALL NOT use Alternative Time
Scales. Scales.
14. 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.
Clocks operating in the Enterprise profile will not interoperate Clocks operating in the Enterprise profile will not interoperate
with clocks operating in the Telecom Profile for Frequency with clocks operating in the Telecom Profile for Frequency
Synchronization[G8265.1], because the Enterprise Profile forbids Synchronization[G8265.1], because the Enterprise Profile forbids
Unicast Message Negotiation, and Unicast Discovery. These Unicast Message Negotiation, and Unicast Discovery. These
features are part of the default manner of operation for the features are part of the default manner of operation for the
Telecom Profile for Frequency Synchronization. Telecom Profile for Frequency Synchronization.
skipping to change at page 11, line 29 skipping to change at page 11, line 46
those messages are directed at a specific clock. If any of these those messages are directed at a specific clock. If any of these
requirements are not met than Enterprise Profile clocks will not requirements are not met than Enterprise Profile clocks will not
interoperate with Default Profile Clocks. The Default Profile is interoperate with Default Profile Clocks. The Default Profile is
described in Annex J of [IEEE1588]. described in Annex J of [IEEE1588].
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. 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 the IEEE 1588 The use of multiple simultaneous masters, using the IEEE 1588
Alternate Master option can mitigate problems from rogue masters Alternate Master option can mitigate problems from rogue masters
and 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.
16. IANA Considerations 15. IANA Considerations
There are no IANA requirements in this specification. There are no IANA requirements in this specification.
17. References 16. References
17.1. Normative References 16.1. Normative References
[IEEE1588] IEEE std. 1588-2008, "IEEE Standard for a [IEEE1588] IEEE std. 1588-2008, "IEEE Standard for a
Precision Clock Synchronization for Networked Precision Clock Synchronization for Networked
Measurement and Control Systems." July, 2008. Measurement and Control Systems." July, 2008.
[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.
skipping to change at page 12, line 19 skipping to change at page 12, line 35
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, [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 16.2. Informative References
[C37.238] IEEE std. C37.238-2011, "IEEE Standard Profile for [C37.238] IEEE std. C37.238-2011, "IEEE Standard Profile for
Use of IEEE 1588 Precision Time Protocol in Power Use of IEEE 1588 Precision Time Protocol in Power
System Applications," July 2011. System Applications," July 2011.
[G8265.1] ITU-T G.8265.1/Y.1365.1, "Precision time protocol [G8265.1] ITU-T G.8265.1/Y.1365.1, "Precision time protocol
telecom profile for frequency synchronization," telecom profile for frequency synchronization,"
October 2011. 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 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 prepared using 2-Word-v2.0.template.dot.
Authors' Addresses 18. Authors' Addresses
Doug Arnold Doug Arnold
3808 Sherbrook Dr. Meinberg USA
Santa Rosa, CA 95404 228 Windsor River Rd
Windsor, CA 95492
USA USA
Email: doug.arnold2@gmail.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. 43 change blocks. 
93 lines changed or deleted 101 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/