draft-ietf-tictoc-ptp-enterprise-profile-07.txt   draft-ietf-tictoc-ptp-enterprise-profile-08.txt 
Internet-Draft Enterprise Profile for PTP August 2017 INTERNET-DRAFT Enterprise Profile for PTP September 2017
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: February 21, 2017 August 21, 2017 Expires: March 28, 2018 September 28, 2017
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-07.txt draft-ietf-tictoc-ptp-enterprise-profile-08.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 39 skipping to change at page 1, line 39
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 February 21, 2017. This Internet-Draft will expire on March 28, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 3, line 13 skipping to change at page 3, line 13
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 like CPU cycles to drop the message. bandwidth and other resources like CPU cycles to drop the message.
The second revision of the standard (IEEE 1588-2008) is the The second revision of the standard (IEEE 1588-2008) is the
current version (also known as PTPv2) and introduced the current version (also known as PTPv2) and introduced the
possibility to use unicast communication between the PTP nodes in possibility to use unicast communication between the PTP nodes in
order to overcome the limitation of using multicast messages for order to overcome the limitation of using multicast messages for
the bi-directional information exchange between PTP nodes. The the bi-directional information exchange between PTP nodes. The
unicast approach avoided that, in PTP domains with a lot of nodes, unicast approach avoided that, in PTP domains with a lot of nodes,
devices had to throw away up to 99% of the received multicast devices had to throw away more than 99% of the received multicast
messages because they carried information for some other node. messages because they carried information for some other node.
PTPv2 also introduced so-called "PTP profiles" ([IEEE1588] Clause PTPv2 also introduced so-called "PTP profiles" ([IEEE1588] Clause
19.3). This construct allows organizations to specify selections 19.3). This construct allows organizations to specify selections
of attribute values and optional features, simplifying the of attribute values and optional features, simplifying the
configuration of PTP nodes for a specific application. Instead of configuration of PTP nodes for a specific application. Instead of
having to go through all possible parameters and configuration having to go through all possible parameters and configuration
options and individually set them up, selecting a profile on a PTP options and individually set them up, selecting a profile on a PTP
node will set all the parameters that are specified in the profile node will set all the parameters that are specified in the profile
to a defined value. If a PTP profile definition allows multiple to a defined value. If a PTP profile definition allows multiple
values for a parameter, selection of the profile will set the values for a parameter, selection of the profile will set the
profile-specific default value for this parameter. Parameters not profile-specific default value for this parameter. Parameters not
allowing multiple values are set to the value defined in the PTP allowing multiple values are set to the value defined in the PTP
profile. A number of PTP features and functions are optional and a profile. Many PTP features and functions are optional, and a
profile should also define which optional features of PTP are profile should also define which optional features of PTP are
required, permitted or prohibited. It is possible to extend the required, permitted, or prohibited. It is possible to extend the
PTP standard with a PTP profile by using the TLV mechanism of PTP PTP standard with a PTP profile by using the TLV mechanism of PTP
(see [IEEE1588] Clause 13.4), defining an optional Best Master (see [IEEE1588] Clause 13.4), defining an optional Best Master
Clock Algorithm and a few other ways. PTP has its own management Clock Algorithm and a few other ways. PTP has its own management
protocol (defined in [IEEE1588] Clause 15.2) but allows a PTP protocol (defined in [IEEE1588] Clause 15.2) but allows a PTP
profile specify an alternative management mechanism, for example profile specify an alternative management mechanism, for example
SNMP. SNMP.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
skipping to change at page 4, line 41 skipping to change at page 4, line 41
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.
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.
Master clock: a clock with at least one port in the master state. Master clock: a clock with at least one port in the master state.
NTP: Network Time Protocol, defined by RFC 5905, see [NTP]. NTP: Network Time Protocol, defined by RFC 5905, see [NTP].
Ordinary Clock: A clock that has a single Precision Time Protocol Ordinary Clock: A clock that has a single Precision Time Protocol
(PTP) port in a domain and maintains the timescale used in the (PTP) port in a domain and maintains the timescale used in the
domain. It may serve as a master clock, or be a slave clock. domain. It may serve as a master clock, or be a slave clock.
skipping to change at page 5, line 10 skipping to change at page 5, line 10
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 48 skipping to change at page 5, line 48
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 such financial corporations. It is becoming increasingly common in such
networks to perform distributed time tagged measurements, such as networks to perform distributed time tagged measurements, 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 in the Financial Industry range from
100 microseconds to 500 nanoseconds to the Grandmaster. This 100 microseconds to 500 nanoseconds to the Grandmaster. This
profile does not specify timing performance requirements, but such profile does not specify timing performance requirements, but such
requirements explain why the needs cannot always be met by NTP, as requirements explain why the needs cannot always be met by NTP, as
commonly implemented. Such accuracy cannot usually be achieved with commonly implemented. Such accuracy cannot usually be achieved with
a traditional time transfer such as NTP, without adding a traditional time transfer such as NTP, without adding
non-standard customizations such as hardware time stamping, and on non-standard customizations such as hardware time stamping, and on
path support. These features are currently part of PTP, or are path support. These features are currently part of PTP, or are
allowed by it. Because PTP has a complex range of features and allowed by it. Because PTP has a complex range of features and
options it is necessary to create a profile for enterprise options it is necessary to create a profile for enterprise
networks to achieve interoperability between equipment 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.
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.
skipping to change at page 6, line 51 skipping to change at page 6, line 51
Note that clocks SHOULD always be identified by their clock ID and Note that clocks SHOULD always be identified by their clock ID and
not the IP or Layer 2 address. This is important in IPv6 networks not the IP or Layer 2 address. This is important in IPv6 networks
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.
Similar to NTP, PTP makes the assumption that the one way network PTP, like NTP, assumes that the one-way network delay for Sync
delay for Sync Messages and Delay Response Messages are the same. Messages and Delay Response Messages are the same. When this is
When this is not true it can cause errors in the transfer of time not true it can cause errors in the transfer of time from the
from the Master to the Slave. It is up to the system integrator to Master to the Slave. It is up to the system integrator to design
design the network so that such effects do not prevent the PTP the network so that such effects do not prevent the PTP system
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 7, line 37 skipping to change at page 7, line 37
224.0.1.129 for IPv4 and FF0X:0:0:0:0:0:0:181 for Ipv6, where X can 224.0.1.129 for IPv4 and FF0X:0:0:0:0:0:0:181 for Ipv6, where X can
be a value between 0x0 and 0xF, see [IEEE1588] Annex E, Section be a value between 0x0 and 0xF, see [IEEE1588] Annex E, Section
E.3. E.3.
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 This allow for the use of Ordinary clocks which do not support the
Enterprise Profile, as long as they are slave Only Clocks. Enterprise Profile, if they are slave Only Clocks.
Clocks SHOULD include support for multiple domains. The purpose is Clocks SHOULD include support for multiple domains. The purpose is
to support multiple simultaneous masters for redundancy. Leaf to support multiple simultaneous masters for redundancy. Leaf
devices (non-forwarding devices) can use timing information from devices (non-forwarding devices) can use timing information from
multiple masters by combining information from multiple multiple masters by combining information from multiple
instantiations of a PTP stack, each operating in a different instantiations of a PTP stack, each operating in a different
domain. Redundant sources of timing can be ensembled, and/or domain. Redundant sources of timing can be ensembled, and/or
compared to check for faulty master clocks. The use of multiple compared to check for faulty master clocks. The use of multiple
simultaneous masters will help mitigate faulty masters reporting as simultaneous masters will help mitigate faulty masters reporting as
healthy, network delay asymmetry, and security problems. Security healthy, network delay asymmetry, and security problems. Security
skipping to change at page 8, line 16 skipping to change at page 8, line 16
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 MAY be Unicast Discovery and Unicast Message Negotiation options SHALL NOT
utilized. If Unicat Negotiation is not used, operators will need be utilized.
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 if each active Grandmaster is
Grandmaster is operating in a different PTP domain. 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. seconds.
If a unicast negotiation signaling message is received it SHALL
be ignored.
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
Announce Time Out Interval. Slaves MAY use an Acceptable Master Announce Time Out Interval. Slaves MAY use an Acceptable Master
Table. If a Master is not an Acceptable Master, then the Slave Table. If a Master is not an Acceptable Master, then the Slave
MUST NOT synchronize to it. Note that IEEE 1588-2008 requires MUST NOT synchronize to it. Note that IEEE 1588-2008 requires
slave clocks to support both two-step or one-step Master clocks. slave clocks to support both two-step or one-step Master clocks.
See [IEEE1588], section 11.2. See [IEEE1588], section 11.2.
Since Announce messages are sent as multicast messages slaves can Since Announce messages are sent as multicast messages slaves can
obtain the IP addresses of master from the Announce messages. Note obtain the IP addresses of master from the Announce messages. Note
that the IP source addresses of Sync and Follow-up messages may that the IP source addresses of Sync and Follow-up messages may
have been replaced by the source addresses of a transparent clock, have been replaced by the source addresses of a transparent clock,
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
Announce message. Sync and Follow-up messages can be correlated the Announce message. Sync and Follow-up messages can be
with the Announce message using the clock ID, which is never correlated with the Announce message using the clock ID, which is
altered by Transparent clocks in this profile. never 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 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
skipping to change at page 10, line 10 skipping to change at page 10, line 10
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 forbidden. Clocks ALLOWED. The Alternate Master option is also forbidden. Clocks
operating in the Enterprise Profile SHALL NOT use Alternate operating in the Enterprise Profile SHALL NOT use Alternate
Timescales. Timescales.
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 would Delay Measurement Mechanism. In addition, the Default Profile
have to operates over IPv4 or IPv6 networks, and use management would have to operates over IPv4 or IPv6 networks, and use
messages in unicast when those messages are directed at a specific management messages in unicast when those messages are directed at
clock. If either of these requirements are not met than Enterprise a specific clock. If either of these requirements are not met than
Profile clocks will not interoperate with Annex J.3 Default Profile Enterprise Profile clocks will not interoperate with Annex J.3
Clocks. The Enterprise Profile Profile will will not interoperate Default Profile Clocks. The Enterprise Profile will not
with the Annex J.4 variant of the Default Profile which requires interoperate with the Annex J.4 variant of the Default Profile
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.
 End of changes. 20 change blocks. 
37 lines changed or deleted 39 lines changed or added

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