draft-ietf-tictoc-ptp-enterprise-profile-09.txt   draft-ietf-tictoc-ptp-enterprise-profile-10.txt 
INTERNET-DRAFT Enterprise Profile for PTP December 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: June 12, 2018 December 12, 2017 Expires: December 19, 2018
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-09.txt draft-ietf-tictoc-ptp-enterprise-profile-10.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 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 June 12, 2018. This Internet-Draft will expire on December 19, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 48 skipping to change at page 2, line 48
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 "Best Master Clock Algorithm" ([IEEE1588] Subclause 9.3), a
9.3), a mechanism that all participating PTP nodes must follow, mechanism that all participating PTP nodes must follow, set up
set up strict rules for all members of a PTP domain to determine strict rules for all members of a PTP domain to determine which
which node shall be the active sending time source (Master Clock). node shall be the active sending time source (Master Clock).
Although the multicast communication model has advantages in Although the multicast communication model has advantages in
smaller networks, it complicated the application of PTP in larger smaller networks, it complicated the application of PTP in larger
networks, for example in environments like IP based networks, for example in environments like IP based
telecommunication networks or financial data centers. It is telecommunication networks or financial data centers. It is
considered inefficient that, even if the content of a message considered inefficient that, even if the content of a message
applies only to one receiver, it is forwarded by the underlying applies only to one receiver, it is forwarded by the underlying
network (IP) to all nodes, requiring them to spend network network (IP) to all nodes, requiring them to spend network
bandwidth and other resources like CPU cycles to drop the message. bandwidth and other resources, such as 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 more than 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 PTP profiles ([IEEE1588] subclause 19.3).
19.3). This construct allows organizations to specify selections This construct allows organizations to specify selections of
of attribute values and optional features, simplifying the 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. Many 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] subclause 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] subclause 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
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC-2119 in this document are to be interpreted as described in RFC-2119
[RFC2119]. [RFC2119].
skipping to change at page 4, line 30 skipping to change at page 4, line 30
timing and then other ports in master state to re-distribute the timing and then other ports in master state to re-distribute the
timing. timing.
Clock Identity: In IEEE 1588-2008 this is a 64-bit number Clock Identity: In IEEE 1588-2008 this is a 64-bit number
assigned to each PTP clock which must be unique. Often 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 Domain: Every PTP message contains a domain number. Domains are
treated as separate PTP systems in the network. Slaves, however, treated as separate PTP systems in the network. Clocks, however,
can combine the timing information derived from multiple domains. can combine the timing information derived from multiple domains.
End to End Delay Measurement Mechanism: A network delay End to End Delay Measurement Mechanism: A network delay
measurement mechanism in PTP facilitated by an exchange of measurement mechanism in PTP facilitated by an exchange of
messages between a Master Clock and Slave Clock. messages between a Master Clock and Slave Clock.
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
skipping to change at page 5, line 53 skipping to change at page 5, line 53
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 100 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.
skipping to change at page 8, line 46 skipping to change at page 8, line 46
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], subClause 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 a master from the Announce messages.
that the IP source addresses of Sync and Follow-up messages may Note that the IP source addresses of Sync and Follow-up messages
have been replaced by the source addresses of a transparent clock, may have been replaced by the source addresses of a transparent
so, slaves MUST send Delay Request messages to the IP address in clock, so, slaves MUST send Delay Request messages to the IP
the Announce message. Sync and Follow-up messages can be address in the Announce message. Sync and Follow-up messages can
correlated with the Announce message using the clock ID, which is be correlated with the Announce message using the clock ID, which
never altered by Transparent clocks in this profile. is 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.
skipping to change at page 9, line 43 skipping to change at page 9, line 43
messages intended for a specific clock, i.e. the [IEEE1588] defined messages intended for a specific clock, i.e. the [IEEE1588] defined
attribute targetPortIdentity.clockIdentity is not set to All 1's, attribute targetPortIdentity.clockIdentity is not set to All 1's,
MUST be sent as a unicast message. Similarly, if any signaling MUST be sent as a unicast message. Similarly, if any signaling
messages are used they MUST also be sent as unicast messages messages are used they MUST also be sent as unicast messages
whenever the message is intended for a specific clock. whenever the message is intended for a specific clock.
13. Forbidden PTP Options 13. Forbidden PTP Options
Clocks operating in the Enterprise Profile SHALL NOT use peer to Clocks operating in the Enterprise Profile SHALL NOT use peer to
peer timing for delay measurement. Grandmaster Clusters are NOT peer timing for delay measurement. Grandmaster Clusters are NOT
ALLOWED. The Alternate Master option is also forbidden. Clocks ALLOWED. The Alternate Master option is also NOT ALLOWED. Clocks
operating in the Enterprise Profile SHALL NOT use Alternate operating in the Enterprise Profile SHALL NOT use Alternate
Timescales. 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 Delay Measurement Mechanism. In addition, the Default Profile
would have to operates over IPv4 or IPv6 networks, and use would have to operates over IPv4 or IPv6 networks, and use
 End of changes. 15 change blocks. 
27 lines changed or deleted 26 lines changed or added

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