draft-ietf-tictoc-ptp-enterprise-profile-12.txt   draft-ietf-tictoc-ptp-enterprise-profile-13.txt 
TICTOC Working Group Doug Arnold
Internet Draft Meinberg-USA
Intended status: Standards Track Heiko Gerstung
Meinberg
Expires: June 30, 2019
Enterprise Profile for the Precision Time Protocol TICTOC Working Group D. Arnold
With Mixed Multicast and Unicast Messages Internet-Draft H. Gerstung
Intended status: Informational Meinberg
Expires: September 30, 2019 March 29, 2019
draft-ietf-tictoc-ptp-enterprise-profile-12.txt Enterprise Profile for the Precision Time Protocol With Mixed Multicast
and Unicast Messages
draft-ietf-tictoc-ptp-enterprise-profile-13
Status of this Memo Abstract
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be
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
English.
Internet-Drafts are working documents of the Internet Engineering This document describes a profile for the use of the Precision Time
Task Force (IETF), its areas, and its working groups. Note that Protocol in an IPV4 or IPv6 Enterprise information system
other groups may also distribute working documents as Internet- environment. The profile uses the End to End Delay Measurement
Drafts. Mechanism, allows both multicast and unicast Delay Request and Delay
Response Messages.
Internet-Drafts are draft documents valid for a maximum of six Status of This Memo
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft is submitted in full conformance with the
http://www.ietf.org/ietf/1id-abstracts.txt provisions of BCP 78 and BCP 79.
The list of Internet-Draft Shadow Directories can be accessed at Internet-Drafts are working documents of the Internet Engineering
http://www.ietf.org/shadow.html Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
This Internet-Draft will expire on January 31, 2019. Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Copyright Notice This Internet-Draft will expire on September 30, 2019.
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Copyright Notice
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document describes a profile for the use of the Precision This document is subject to BCP 78 and the IETF Trust's Legal
Time Protocol in an IPV4 or IPv6 Enterprise information system Provisions Relating to IETF Documents
environment. The profile uses the End to End Delay Measurement (https://trustee.ietf.org/license-info) in effect on the date of
Mechanism, allows both multicast and unicast Delay Request and Delay publication of this document. Please review these documents
Response Messages. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Technical Terms 3 3. Technical Terms . . . . . . . . . . . . . . . . . . . . . . . 3
4. Problem Statement 5 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
5. Network Technology 6 5. Network Technology . . . . . . . . . . . . . . . . . . . . . 6
6. Time Transfer and Delay Measurement 7 6. Time Transfer and Delay Measurement . . . . . . . . . . . . . 7
7. Default Message Rates 8 7. Default Message Rates . . . . . . . . . . . . . . . . . . . . 8
8. Requirements for Master Clocks 8 8. Requirements for Master Clocks . . . . . . . . . . . . . . . 8
9. Requirements for Slave Clocks 8 9. Requirements for Slave Clocks . . . . . . . . . . . . . . . . 8
10. Requirements for Transparent Clocks 9 10. Requirements for Transparent Clocks . . . . . . . . . . . . . 9
11. Requirements for Boundary Clocks 9 11. Requirements for Boundary Clocks . . . . . . . . . . . . . . 9
12. Management and Signaling Messages 9 12. Management and Signaling Messages . . . . . . . . . . . . . . 9
13. Forbidden PTP Options 9 13. Forbidden PTP Options . . . . . . . . . . . . . . . . . . . . 10
14. Interoperation with Other PTP Profiles 10 14. Interoperation with IEEE 1588 Default Profile . . . . . . . . 10
15. Profile Identification 10 15. Profile Identification . . . . . . . . . . . . . . . . . . . 10
16. Security Considerations 10 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
17. IANA Considerations 10 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
18. References 11 18. Security Considerations . . . . . . . . . . . . . . . . . . . 11
18.1. Normative References 11 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
18.2. Informative References 11 19.1. Normative References . . . . . . . . . . . . . . . . . . 11
19. Acknowledgments 11 19.2. Informative References . . . . . . . . . . . . . . . . . 12
20. Authors addresses 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The Precision Time Protocol ("PTP"), standardized in IEEE 1588, The Precision Time Protocol ("PTP"), standardized in IEEE 1588, has
has been designed in its first version (IEEE 1588-2002) with the been designed in its first version (IEEE 1588-2002) with the goal to
goal to minimize configuration on the participating nodes. Network 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 IEEE 1588-2008 [IEEE1588] needs to know the identity of the time
network (the Master Clocks). sources in the network (the Master Clocks).
The "Best Master Clock Algorithm" ([IEEE1588] Subclause 9.3), a
mechanism that all participating PTP nodes must follow, set up
strict rules for all members of a PTP domain to determine which
node shall be the active sending time source (Master Clock).
Although the multicast communication model has advantages in
smaller networks, it complicated the application of PTP in larger
networks, for example in environments like IP based
telecommunication networks or financial data centers. It is
considered inefficient that, even if the content of a message
applies only to one receiver, it is forwarded by the underlying
network (IP) to all nodes, requiring them to spend network
bandwidth and other resources, such as CPU cycles, to drop the
message.
The second revision of the standard (IEEE 1588-2008) is the The "Best Master Clock Algorithm" (IEEE 1588-2008 [IEEE1588]
current version (also known as PTPv2) and introduced the Subclause 9.3), a mechanism that all participating PTP nodes must
possibility to use unicast communication between the PTP nodes in follow, set up strict rules for all members of a PTP domain to
order to overcome the limitation of using multicast messages for determine which node shall be the active sending time source (Master
the bi-directional information exchange between PTP nodes. The Clock). Although the multicast communication model has advantages in
unicast approach avoided that, in PTP domains with a lot of nodes, smaller networks, it complicated the application of PTP in larger
devices had to throw away more than 99% of the received multicast networks, for example in environments like IP based telecommunication
messages because they carried information for some other node. networks or financial data centers. It is considered inefficient
PTPv2 also introduced PTP profiles ([IEEE1588] subclause 19.3). that, even if the content of a message applies only to one receiver,
This construct allows organizations to specify selections of it is forwarded by the underlying network (IP) to all nodes,
attribute values and optional features, simplifying the requiring them to spend network bandwidth and other resources, such
configuration of PTP nodes for a specific application. Instead of as CPU cycles, to drop the message.
having to go through all possible parameters and configuration
options and individually set them up, selecting a profile on a PTP
node will set all the parameters that are specified in the profile
to a defined value. If a PTP profile definition allows multiple
values for a parameter, selection of the profile will set the
profile-specific default value for this parameter. Parameters not
allowing multiple values are set to the value defined in the PTP
profile. Many PTP features and functions are optional, and a
profile should also define which optional features of PTP are
required, permitted, or prohibited. It is possible to extend the
PTP standard with a PTP profile by using the TLV mechanism of PTP
(see [IEEE1588] subclause 13.4), defining an optional Best Master
Clock Algorithm and a few other ways. PTP has its own management
protocol (defined in [IEEE1588] subclause 15.2) but allows a PTP
profile specify an alternative management mechanism, for example
SNMP.
2. Conventions used in this document The second revision of the standard (IEEE 1588-2008) is the current
version (also known as PTPv2) and introduced the possibility to use
unicast communication between the PTP nodes in order to overcome the
limitation of using multicast messages for the bi-directional
information exchange between PTP nodes. The unicast approach avoided
that, in PTP domains with a lot of nodes, devices had to throw away
more than 99% of the received multicast messages because they carried
information for some other node. PTPv2 also introduced PTP profiles
(IEEE 1588-2008 [IEEE1588] subclause 19.3). This construct allows
organizations to specify selections of attribute values and optional
features, simplifying the configuration of PTP nodes for a specific
application. Instead of having to go through all possible parameters
and configuration options and individually set them up, selecting a
profile on a PTP node will set all the parameters that are specified
in the profile to a defined value. If a PTP profile definition
allows multiple values for a parameter, selection of the profile will
set the profile-specific default value for this parameter.
Parameters not allowing multiple values are set to the value defined
in the PTP profile. Many PTP features and functions are optional,
and a profile should also define which optional features of PTP are
required, permitted, or prohibited. It is possible to extend the PTP
standard with a PTP profile by using the TLV mechanism of PTP (see
IEEE 1588-2008 [IEEE1588] subclause 13.4), defining an optional Best
Master Clock Algorithm and a few other ways. PTP has its own
management protocol (defined in IEEE 1588-2008 [IEEE1588] subclause
15.2) but allows a PTP profile specify an alternative management
mechanism, for example SNMP.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 2. Requirements Language
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC-2119
[RFC2119].
In this document, these words will appear with that interpretation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
only when in ALL CAPS. Lower case uses of these words are not to "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
be interpreted as carrying RFC-2119 significance. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Technical Terms 3. Technical Terms
Acceptable Master Table: A PTP Slave Clock may maintain a list of o Acceptable Master Table: A PTP Slave Clock may maintain a list of
masters which it is willing to synchronize to. masters which it is willing to synchronize to.
Alternate Master: A PTP Master Clock, which is not the Best o Alternate Master: A PTP Master Clock, which is not the Best
Master, may act as a master with the Alternate Master flag set on Master, may act as a master with the Alternate Master flag set on
the messages it sends. the messages it sends.
Announce message: Contains the Master Clock properties of a Master o Announce message: Contains the Master Clock properties of a Master
Clock. Used to determine the Best Master. Clock. Used to determine the Best Master.
Best Master: A clock with a port in the master state, operating o Best Master: A clock with a port in the master state, operating
consistently with the Best Master Clock Algorithm. consistently with the Best Master Clock Algorithm.
Best Master Clock Algorithm: A method for determining which state o Best Master Clock Algorithm: A method for determining which state
a port of a PTP clock should be in. The algorithm works by a port of a PTP clock should be in. The algorithm works by
identifying which of several PTP Master capable clocks is the best identifying which of several PTP Master capable clocks is the best
master. Clocks have priority to become the acting Grandmaster, master. Clocks have priority to become the acting Grandmaster,
based on the properties each Master Clock sends in its Announce based on the properties each Master Clock sends in its Announce
Message. Message.
Boundary Clock: A device with more than one PTP port. Generally o Boundary Clock: A device with more than one PTP port. Generally
boundary Clocks will have one port in slave state to receive boundary Clocks will have one port in slave state to receive
timing and then other ports in master state to re-distribute the timing and then other ports in master state to re-distribute the
timing. timing.
Clock Identity: In IEEE 1588-2008 this is a 64-bit number o Clock Identity: In IEEE 1588-2008 this is a 64-bit number assigned
assigned to each PTP clock which must be unique. Often it is to each PTP clock which must be unique. Often it is derived from
derived from the Ethernet MAC address, since there is already an the Ethernet MAC address, since there is already an international
international infrastructure for assigning unique numbers to each infrastructure for assigning unique numbers to each device
device manufactured. manufactured.
Domain: Every PTP message contains a domain number. Domains are o Domain: Every PTP message contains a domain number. Domains are
treated as separate PTP systems in the network. Clocks, 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 o 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 o Grandmaster: the primary Master Clock within a domain of a PTP
system system
IEEE 1588: The timing and synchronization standard which defines o 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. o Master Clock: a clock with at least one port in the master state.
NTP: Network Time Protocol, defined by RFC 5905, see [NTP]. o NTP: Network Time Protocol, defined by RFC 5905, see RFC 5905
[RFC5905]
Ordinary Clock: A clock that has a single Precision Time Protocol o 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.
Peer to Peer Delay Measurement Mechanism: A network delay o Peer to Peer 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 adjacent devices in a network. messages between adjacent devices in a network.
Preferred Master: A device intended to act primarily as the o 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 o PTP: The Precision Time Protocol, the timing and synchronization
protocol defined by IEEE 1588. protocol defined by IEEE 1588.
PTP port: An interface of a PTP clock with the network. Note that o 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 o 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 o 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, o Slave clock: a clock with at least one port in the slave state,
and no ports in the master state. and no ports in the master state.
Slave Only Clock: An Ordinary Clock which cannot become a Master o Slave Only Clock: An Ordinary Clock which cannot become a Master
Clock. Clock.
TLV: Type Length Value, a mechanism for extending messages in o TLV: Type Length Value, a mechanism for extending messages in
networked communications. networked communications.
Transparent Clock. A device that measures the time taken for a o Transparent Clock. A device that measures the time taken for a
PTP event message to transit the device and then updates the PTP event message to transit the device and then updates the
message with a correction for this transit time. message with a correction for this transit time.
Unicast Discovery: A mechanism for PTP slaves to establish a o Unicast Discovery: A mechanism for PTP slaves to establish a
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 o 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 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
systems spread across multiple computers. Furthermore, there is spread across multiple computers. Furthermore, there is often a
often a desire to check the age of information time tagged by a desire to check the age of information time tagged by a different
different machine. To perform these measurements, it is necessary machine. To perform these measurements, it is necessary to deliver a
to deliver a common precise time to multiple devices on a network. common precise time to multiple devices on a network. Accuracy
Accuracy currently required in the Financial Industry range from currently required in the Financial Industry range from 100
100 microseconds to 100 nanoseconds to the Grandmaster. This microseconds to 100 nanoseconds to the Grandmaster. This profile
profile does not specify timing performance requirements, but such 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
non-standard customizations such as hardware time stamping, and on customizations such as hardware time stamping, and on path support.
path support. These features are currently part of PTP, or are These features are currently part of PTP, or are allowed by it.
allowed by it. Because PTP has a complex range of features and Because PTP has a complex range of features and options it is
options it is necessary to create a profile for enterprise necessary to create a profile for enterprise networks to achieve
networks to achieve interoperability between equipment 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
the same. It is also advantageous to send information which is same. It is also advantageous to send information which is unique to
unique to one device as a unicast message. The latter can be one device as a unicast message. The latter can be essential as the
essential as the number of PTP slaves becomes hundreds or 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
identified as improper, and to have redundant sources of time. as improper, and to have redundant sources of time.
Interoperability among independent implementations of this PTP Interoperability among independent implementations of this PTP
profile has been demonstrated at the ISPCS Plugfest [ISPCS]. profile has been demonstrated at the ISPCS Plugfest ISPCS [ISPCS].
5. Network Technology 5. Network Technology
This PTP profile SHALL operate only in networks characterized by This PTP profile SHALL operate only in networks characterized by UDP
UDP [RFC768] over either IPv4 [RFC791] or IPv6 [RFC8200], as RFC 768 [RFC0768] over either IPv4 RFC 791 [RFC0791] or IPv6 RFC 8200
described by Annexes D and E in [IEEE1588] respectively. If a [RFC8200], as described by Annexes D and E in IEEE 1588 [IEEE1588]
network contains both IPv4 and IPv6, then they SHALL be treated as respectively. If a network contains both IPv4 and IPv6, then they
separate communication paths. Clocks which communicate using IPv4 SHALL be treated as separate communication paths. Clocks which
can interact with clocks using IPv6 if there is an intermediary communicate using IPv4 can interact with clocks using IPv6 if there
device which simultaneously communicates with both IP versions. A is an intermediary device which simultaneously communicates with both
Boundary Clock might perform this function, for example. A PTP IP versions. A Boundary Clock might perform this function, for
domain SHALL use either IPv4 or IPv6 over a communication path, example. A PTP domain SHALL use either IPv4 or IPv6 over a
but not both. The PTP system MAY include switches and routers. communication path, but not both. The PTP system MAY include
These devices MAY be Transparent Clocks, boundary Clocks, or switches and routers. These devices MAY be Transparent Clocks,
neither, in any combination. PTP Clocks MAY be Preferred Masters, boundary Clocks, or neither, in any combination. PTP Clocks MAY be
Ordinary Clocks, or Boundary Clocks. The Ordinary Clocks may be Preferred Masters, Ordinary Clocks, or Boundary Clocks. The Ordinary
Slave Only Clocks, or be master capable. Clocks may be Slave Only Clocks, or be master capable.
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
of any packet which they alter. In IPv4 networks some clocks any packet which they alter. In IPv4 networks some clocks might be
might be hidden behind a NAT, which hides their IP addresses from hidden behind a NAT, which hides their IP addresses from the rest of
the rest of the network. Note also that the use of NATs may place the network. Note also that the use of NATs may place limitations on
limitations on the topology of PTP networks, depending on the port the topology of PTP networks, depending on the port forwarding scheme
forwarding scheme employed. Details of implementing PTP with NATs employed. Details of implementing PTP with NATs are out of scope of
are out of scope of this document. this document.
PTP, like NTP, assumes that the one-way network delay for Sync PTP, like NTP, assumes that the one-way network delay for Sync
Messages and Delay Response Messages are the same. When this is Messages and Delay Response Messages are the same. When this is not
not true it can cause errors in the transfer of time from the true it can cause errors in the transfer of time from the Master to
Master to the Slave. It is up to the system integrator to design the Slave. It is up to the system integrator to design the network
the network so that such effects do not prevent the PTP system so that such effects do not prevent the PTP system from meeting the
from meeting the timing requirements. The details of timing requirements. The details of network asymmetry are outside
network asymmetry are outside the scope of this document. See for the scope of this document. See for example, ITU-T G.8271 [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
either one-step clocks or two-step clocks. Slave clocks MUST one-step clocks or two-step clocks. Slave clocks MUST support both
support both behaviors. The End to End Delay Measurement Method behaviors. The End to End Delay Measurement Method MUST be used.
MUST be used.
Note that, in IP networks, Sync messages and Delay Request Note that, in IP networks, Sync messages and Delay Request messages
messages exchanged between a master and slave do not necessarily exchanged between a master and slave do not necessarily traverse the
traverse the same physical path. Thus, wherever possible, the same physical path. Thus, wherever possible, the network SHOULD be
network SHOULD be traffic engineered so that the forward and traffic engineered so that the forward and reverse routes traverse
reverse routes traverse the same physical path. Traffic the same physical path. Traffic engineering techniques for path
engineering techniques for path consistency are out of scope of consistency are out of scope of this document.
this document.
Sync messages MUST be sent as PTP event multicast messages (UDP Sync messages MUST be sent as PTP event multicast messages (UDP port
port 319) to the PTP primary IP address. Two step clocks SHALL 319) to the PTP primary IP address. Two step clocks SHALL send
send Follow-up messages as PTP general messages (UDP port 320). Follow-up messages as PTP general messages (UDP port 320). Announce
Announce messages MUST be sent as multicast messages (UDP port 320) messages MUST be sent as multicast messages (UDP port 320) to the PTP
to the PTP primary address. The PTP primary IP address is primary address. The PTP primary IP address is 224.0.1.129 for IPv4
224.0.1.129 for IPv4 and FF0X:0:0:0:0:0:0:181 for Ipv6, where X can and FF0X:0:0:0:0:0:0:181 for Ipv6, where X can be a value between 0x0
be a value between 0x0 and 0xF, see [IEEE1588] Annex E, Section and 0xF, see IEEE 1588 [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
PTP event messages. Master Clocks SHALL respond to multicast Delay 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.
messages. Master Clocks SHALL respond to unicast Delay Request PTP Master Clocks SHALL respond to unicast Delay Request PTP event
event messages with unicast Delay Response PTP general messages. messages with unicast Delay Response PTP general messages. This
This allow for the use of Ordinary Clocks which do not support the allow for the use of Ordinary Clocks which do not support the
Enterprise Profile, if 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.
domain. Redundant sources of timing can be ensembled, and/or Redundant sources of timing can be ensembled, and/or compared to
compared to check for faulty Master Clocks. The use of multiple check for faulty Master Clocks. The use of multiple simultaneous
simultaneous masters will help mitigate faulty masters reporting as masters will help mitigate faulty masters reporting as healthy,
healthy, network delay asymmetry, and security problems. Security network delay asymmetry, and security problems. Security problems
problems include man-in-the-middle attacks such as delay attacks, include man-in-the-middle attacks such as delay attacks, packet
packet interception / manipulation attacks. Assuming the path to interception / manipulation attacks. Assuming the path to each
each master is different, failures malicious or otherwise would master is different, failures malicious or otherwise would have to
have to happen at more than one path simultaneously. Whenever happen at more than one path simultaneously. Whenever feasible, the
feasible, the underlying network transport technology SHOULD be underlying network transport technology SHOULD be configured so that
configured so that timing messages in different domains traverse timing messages in different domains traverse different network
different network paths. paths.
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
each be once per second. The Sync and Delay Request message rates be once per second. The Sync and Delay Request message rates MAY be
MAY be set to other values, but not less than once every 128 set to other values, but not less than once every 128 seconds, and
seconds, and not more than 128 messages per second. The Announce not more than 128 messages per second. The Announce message rate
message rate SHALL NOT be changed from the default value. The SHALL NOT be changed from the default value. The Announce Receipt
Announce Receipt Timeout Interval SHALL be three Announce Timeout Interval SHALL be three Announce Intervals for Preferred
Intervals for Preferred Masters, and four Announce Intervals for Masters, and four Announce Intervals for all other masters.
all other masters.
The logMessageInterval carried in the unicast Delay Response The logMessageInterval carried in the unicast Delay Response message
message MAY be set to correspond to the master ports preferred MAY be set to correspond to the master ports preferred message
message period, rather than 7F, which indicates message periods period, rather than 7F, which indicates message periods are to be
are to be negotiated. Note that negotiated message periods are not negotiated. Note that negotiated message periods are not allowed,
allowed, see section 13. see forbidden PTP options (Section 13).
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 IEEE 1588 [IEEE1588]. PTP systems using this profile MAY
multiple simultaneous Grandmasters if each active Grandmaster is support multiple simultaneous Grandmasters if each active Grandmaster
operating in a different PTP domain. 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
clock has a current value for the number of UTC leap has a current value for the number of UTC leap seconds.
seconds.
If a unicast negotiation signaling message is received it SHALL If a unicast negotiation signaling message is received it SHALL be
be ignored. 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
Announce Time Out Interval. Slaves MAY use an Acceptable Master Time Out Interval. Slaves MAY use an Acceptable Master Table. If a
Table. If a Master is not an Acceptable Master, then the Slave Master is not an Acceptable Master, then the Slave MUST NOT
MUST NOT synchronize to it. Note that IEEE 1588-2008 requires synchronize to it. Note that IEEE 1588-2008 requires slave clocks to
slave clocks to support both two-step or one-step Master clocks. support both two-step or one-step Master clocks. See IEEE 1588
See [IEEE1588], subClause 11.2. [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 a master from the Announce messages. obtain the IP addresses of a master from the Announce messages. Note
Note that the IP source addresses of Sync and Follow-up messages that the IP source addresses of Sync and Follow-up messages may have
may have been replaced by the source addresses of a Transparent been replaced by the source addresses of a Transparent Clock, so,
Clock, so, slaves MUST send Delay Request messages to the IP slaves MUST send Delay Request messages to the IP address in the
address in the Announce message. Sync and Follow-up messages can Announce message. Sync and Follow-up messages can be correlated with
be correlated with the Announce message using the clock ID, which the Announce message using the clock ID, which is never altered by
is never altered by Transparent Clocks in this profile. 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
combine timing information from different domains. combine timing information from different domains.
12. Management and Signaling Messages 12. Management and Signaling Messages
PTP Management messages MAY be used. Management PTP Management messages MAY be used. Management messages intended
messages intended for a specific clock, i.e. the [IEEE1588] defined for a specific clock, i.e. the IEEE 1588 [IEEE1588] defined attribute
attribute targetPortIdentity.clockIdentity is not set to All 1's, targetPortIdentity.clockIdentity is not set to All 1's, MUST be sent
MUST be sent as a unicast message. Similarly, if any signaling as a unicast message. Similarly, if any signaling messages are used
messages are used they MUST also be sent as unicast messages they MUST also be sent as unicast messages whenever the message is
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
peer timing for delay measurement. Grandmaster Clusters are NOT timing for delay measurement. Grandmaster Clusters are NOT ALLOWED.
ALLOWED. The Alternate Master option is also NOT ALLOWED. Clocks The Alternate Master option is also NOT ALLOWED. Clocks operating in
operating in the Enterprise Profile SHALL NOT use Alternate the Enterprise Profile SHALL NOT use Alternate Timescales. Unicast
Timescales. Unicast discovery and unicast negotiation SHALL NOT be discovery and unicast negotiation SHALL NOT be used.
used.
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 IEEE 1588
Annex J.3. This variant of the Default Profile uses the End to End [IEEE1588] Annex J.3. This variant of the Default Profile uses the
Delay Measurement Mechanism. In addition, the Default Profile End to End Delay Measurement Mechanism. In addition, the Default
would have to operate over IPv4 or IPv6 networks, and use Profile would have to operate over IPv4 or IPv6 networks, and use
management messages in unicast when those messages are directed at management messages in unicast when those messages are directed at a
a specific clock. If either of these requirements are not met than specific clock. If either of these requirements are not met than
Enterprise Profile clocks will not interoperate with Annex J.3 Enterprise Profile clocks will not interoperate with Annex J.3
Default Profile Clocks. The Enterprise Profile will not Default Profile Clocks. The Enterprise Profile will not interoperate
interoperate with the Annex J.4 variant of the Default Profile with the Annex J.4 variant of the Default Profile which requires use
which requires use of the Peer to Peer Delay Measurement Mechanism. 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
in other profiles if the clocks in the other profiles obey the other profiles if the clocks in the other profiles obey the rules of
rules of the Enterprise Profile. These rules MUST NOT be changed the Enterprise Profile. These rules MUST NOT be changed to achieve
to achieve interoperability with other profiles. 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.
PTP Profile: PTP Profile:
Enterprise Profile Enterprise Profile
Version: 1.0 Version: 1.0
Profile identifier: 00-00-5E-00-01-00 Profile identifier: 00-00-5E-00-01-00
This profile was specified by the IETF This profile was specified by the IETF
A copy may be obtained at A copy may be obtained at
https://datatracker.ietf.org/wg/tictoc/documents https://datatracker.ietf.org/wg/tictoc/documents
16. Security Considerations 16. Acknowledgements
Protocols used to transfer time, such as PTP and NTP can be The authors would like to thank members of IETF for reviewing and
important to security mechanisms which use time windows for keys providing feedback on this draft.
and authorization. Passing time through the networks poses a
security risk since time can potentially be manipulated.
The use of multiple simultaneous masters, using multiple PTP
domains can mitigate problems from rogue masters and
man-in-the-middle attacks. See sections 9 and 10. Additional
security mechanisms are outside the scope of this document.
PTP native management messages SHOULD not be used, due to the lack This document was initially prepared using 2-Word-v2.0.template.dot
of a security mechanism for this option. Secure management can be and has later been converted manually into xml format using an
obtained using standard management mechanisms which include xml2rfc template.
security, for example NETCONF [NETCONF].
General security considerations of time protocols are discussed in 17. IANA Considerations
[RFC7384].
17. IANA Considerations There are no IANA requirements in this specification.
There are no IANA requirements in this specification. 18. Security Considerations
18. References Protocols used to transfer time, such as PTP and NTP can be important
to security mechanisms which use time windows for keys and
authorization. Passing time through the networks poses a security
risk since time can potentially be manipulated. The use of multiple
simultaneous masters, using multiple PTP domains can mitigate
problems from rogue masters and man-in-the-middle attacks. See
sections 9 and 10. Additional security mechanisms are outside the
scope of this document.
18.1. Normative References PTP native management messages SHOULD not be used, due to the lack of
a security mechanism for this option. Secure management can be
obtained using standard management mechanisms which include security,
for example NETCONF NETCONF [RFC6241].
[IEEE1588] IEEE std. 1588-2008, "IEEE Standard for a General security considerations of time protocols are discussed in
Precision Clock Synchronization for Networked RFC 7384 [RFC7384].
Measurement and Control Systems." July, 2008.
[RFC768] Postel, J., "User Datagram Protocol," RFC 768,
August, 980.
[RFC791] "Internet Protocol DARPA Internet Program Protocol 19. References
Specification," RFC 791, September, 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to 19.1. Normative References
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC8200] Deering, S., Hinden, R., "Internet Protocol, [IEEE1588]
Version 6 (IPv6) Specification," RFC 8200, Institute of Electrical and Electronics Engineers, "IEEE
July, 2017. std. 1588-2008, "IEEE Standard for a Precision Clock
Synchronization for Networked Measurement and Control
Systems."", 7 2008, <https://www.ieee.org>.
18.2. Informative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[G8271] ITU-T G.8271/Y.1366, "Time and Phase [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
Synchronization Aspects of Packet Networks" DOI 10.17487/RFC0791, September 1981,
February, 2012. <https://www.rfc-editor.org/info/rfc791>.
[ISPCS] Arnold, D., et. al. "Plugfest Report," [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
International Symposium on Precision Clock Requirement Levels", BCP 14, RFC 2119,
Synchronization for Measurement, Control and DOI 10.17487/RFC2119, March 1997,
Communications, Monterey, CA, October, 2017. <https://www.rfc-editor.org/info/rfc2119>.
[NETCONF] Ens, R., et. al., "Network Configuration Protocol [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(NETCONF)," RFC 6241, June, 2011. (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[NTP] Mills, D., Martin, J., Burbank, J., Kasch, W., 19.2. Informative References
"Network Time Protocol Version 4: Protocol and
Algorithms Specification," RFC 5905, June 2010.
[RFC7384] Mizrahi, T., "Security Requirements of Time [G8271] International Telecommunication Union, "ITU-T G.8271/
Protocols in Packet Switched Networks," RFC 7384, Y.1366, "Time and Phase Synchronization Aspects of Packet
October, 2014. Networks"", 2 2012, <https://www.itu.int>.
19. Acknowledgments [ISPCS] Arnold, D., "Plugfest Report", 10 2017,
<https://www.ispcs.org>.
The authors would like to thank members of IETF for reviewing and [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
providing feedback on this draft. "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
This document was initially prepared using [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
2-Word-v2.0.template.dot. and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
20. Authors' Addresses [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>.
Doug Arnold Authors' Addresses
Meinberg USA
929 Salem End Road
Framingham, MA 01702
USA
Email: doug.arnold@meinberg-usa.com Doug Arnold
Meinberg
Lange Wand 9
Bad Pyrmont 31812
Germany
Heiko Gerstung Email: doug.arnold@meinberg.de
Meinberg Funkuhren GmbH & Co. KG Heiko Gerstung
Lange Wand 9 Meinberg
D-31812 Bad Pyrmont Lange Wand 9
Germany Bad Pyrmont 31812
Germany
Email: heiko.gerstung@meinberg.de Email: heiko.gerstung@meinberg.de
 End of changes. 107 change blocks. 
463 lines changed or deleted 447 lines changed or added

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