Precision Time Protocol

The Precision Time Protocol (PTP) is a protocol used to synchronize clocks throughout a computer network. On a local area network, it achieves clock accuracy in the sub-microsecond range, making it suitable for measurement and control systems.[1]

PTP was originally defined in the IEEE 1588-2002 standard, officially entitled "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems" and published in 2002. In 2008, IEEE 1588-2008 was released as a revised standard; also known as PTP Version 2, it improves accuracy, precision and robustness but is not backward compatible with the original 2002 version.[2]

"IEEE 1588 is designed to fill a niche not well served by either of the two dominant protocols, NTP and GPS. IEEE 1588 is designed for local systems requiring accuracies beyond those attainable using NTP. It is also designed for applications that cannot bear the cost of a GPS receiver at each node, or for which GPS signals are inaccessible."[3]

Architecture

The IEEE 1588 standards describe a hierarchical master-slave architecture for clock distribution. Under this architecture, a time distribution system consists of one or more communication media (network segments), and one or more clocks. An ordinary clock is a device with a single network connection and is either the source of (master) or destination for (slave) a synchronization reference. A boundary clock has multiple network connections and can accurately synchronize one network segment to another. A synchronization master is selected for each of the network segments in the system. The root timing reference is called the grandmaster.[4] The grandmaster transmits synchronization information to the clocks residing on its network segment. The boundary clocks with a presence on that segment then relay accurate time to the other segments to which they are also connected.

A simplified PTP system frequently consists of ordinary clocks connected to a single network, and no boundary clocks are used. A grandmaster is elected and all other clocks synchronize directly to it.

IEEE 1588-2008 introduces a clock associated with network equipment used to convey PTP messages. The transparent clock modifies PTP messages as they pass through the device. Timestamps in the messages are corrected for time spent traversing the network equipment. This scheme improves distribution accuracy by compensating for delivery variability across the network.

PTP typically uses the same epoch as Unix time (Midnight, 1 January 1970).[note 1] While the Unix time is based on Coordinated Universal Time (UTC) and is subject to leap seconds, PTP is based on International Atomic Time (TAI). The PTP grandmaster communicates the current offset between UTC and TAI, so that UTC can be computed from the received PTP time.

Protocol details

Synchronization and management of a PTP system is achieved through the exchange of messages across the communications medium. To this end, PTP uses the following message types.

Messages are categorized as event and general messages. Event messages are time-critical in that accuracy in transmission and receipt timestamp accuracy directly affects clock distribution accuracy. Sync, Delay_Req, Pdelay_Req and Pdelay_resp are event messages. General messages are more conventional protocol data units in that the data in these messages is of importance to PTP, but their transmission and receipt timestamps are not. Announce, Follow_Up, Delay_Resp, Pdelay_Resp_Follow_Up, Management and Signaling messages are members of the general message class.[5]:Clause 6.4

Message transport

In IEEE 1588-2002, all PTP messages are sent using multicast messaging, while IEEE 1588-2008 introduced an option for devices to negotiate unicast transmission on a port-by-port basis.[5]:Clause 16.1

PTP messages may use the User Datagram Protocol (UDP) over Internet Protocol (IP) for transport. IEEE 1588-2002, the original specification, uses only IPv4 transports,[6]:Annex D but this has been extended to include IPv6 in IEEE 1588-2008.[5]:Annex F Datagrams are transmitted using IP multicast addressing, for which multicast group addresses are defined for IPv4 and IPv6 (see table).[5]:Annex D and E Event messages are sent to port number 319. General messages use port number 320. Replies to Management messages are always returned to the unicast address of the originator.

 IP multicast group addresses
Messages IPv4 IPv6
All except peer delay messages 224.0.1.129[note 3] FF0x::181[note 4]
Peer delay messages: Pdelay_Req, Pdelay_Resp and Pdelay_Resp_Follow_Up[note 5] 224.0.0.107[note 6] FF02::6B

In IEEE 1588-2008, encapsulation is also defined for bare IEEE 802.3 Ethernet,[5]:Annex F DeviceNet,[5]:Annex G ControlNet[5]:Annex H and PROFINET.[5]:Annex I PTP over IEEE 802.3 Ethernet uses Ethertype 0x88F7 and an Ethernet multicast destination address of 01-1B-19-00-00-00 for all but peer delay messages. Peer delay messages are sent to 01-80-C2-00-00-0E.[5]:Annex F[note 7]

Domains

A domain[note 8] is an interacting set of clocks that synchronize to one another using PTP. Clocks are assigned to a domain by virtue of the contents of the Subdomain name (IEEE 1588-2002) or the domainNumber (IEEE 1588-2008) fields in PTP messages they receive or generate. Subdomains allow multiple clock distribution systems to share the same communications medium.

Subdomain name field contents (IEEE1588-2002) IPv4 multicast address
(IEEE1588-2002)[note 9]		 domainNumber
(IEEE1588-2008)		 Notes
_DFLT 224.0.1.129 0 Default domain
_ALT1 224.0.1.130 1 Alternate domain 1
_ALT2 224.0.1.131 2 Alternate domain 2
_ALT3 224.0.1.132 3 Alternate domain 3
Application specific up to 15 octets[6]:Clause 6.2.5.1 224.0.1.130, 131 or 132 as per hash function on Subdomain name[6]:Annex C 4 through 127 User-defined domains

Best master clock algorithm

The best master clock (BMC) algorithm performs a distributed selection of the best candidate clock based on the following clock properties:

Identifier
A universally unique numeric identifier for the clock. This is typically constructed based on a device's MAC address.
Quality
Both versions of IEEE 1588 attempt to quantify clock quality based on expected timing deviation, technology used to implement the clock or location in a stratum schema, although only V1 (IEEE 1588-2002) knows a data field stratum. PTP V2 (IEEE 1588-2008) defines the overall quality of a clock by using the data fields clockAccuracy and clockClass.
Priority
An administratively assigned precedence hint used by the BMC to help select a grandmaster for the PTP domain. IEEE 1588-2002 used a single boolean variable to indicate precedence. IEEE 1588-2008 features two 8-bit priority fields.
Variance
A clock's estimate of its stability based on observation of its performance against the PTP reference.

IEEE 1588-2008 uses a hierarchical selection algorithm based on the following properties, in the indicated order:[5]:Figure 27

  1. Priority 1: the user can assign a specific static-designed priority to each clock, preemptively defining a priority among them.
  2. Class: each clock is a member of a given class, each class getting its own priority.
  3. Accuracy: precision between clock and UTC, in nanoseconds (ns)
  4. Variance: variability of the clock
  5. Priority 2: final-defined priority, defining backup order in case the other criteria were not sufficient.
  6. Unique identifier (tie breaker): MAC address-based selection

IEEE 1588-2002 uses a selection algorithm based on similar properties.

Synchronization

Through use of the BMC algorithm, PTP selects a master source of time for an IEEE 1588 domain and for each network segment in the domain.

Clocks determine the offset between themselves and their master.[7] Let the variable t represent physical time. For a given slave device, the offset o(t) at time t is defined by:

\ o(t) = s(t) - m(t)

where s(t) represents the time measured by the slave clock at physical time t, and m(t) represents the time measured by the master clock at physical time t.

The master periodically broadcasts the current time as a message to the other clocks. Under IEEE 1588-2002 broadcasts are up to once per second. Under IEEE 1588-2008, up to 10 per second are permitted.

IEEE 1588 synchronisation mechanism and delay calculation

Each broadcast begins at time T1 with a Sync message sent by the master to all the clocks in the domain. A clock receiving this message takes note of the local time T1' when this message is received.

The master may subsequently send a multicast Follow_Up with accurate T1 timestamp. Not all masters have ability to present an accurate timestamp in the Sync message. It is only after the transmission is complete that they are able to retrieve an accurate timestamp for the Sync transmission from their network hardware. Masters with this limitation use the Follow_Up message to convey T1. Masters with PTP capabilities built into their network hardware are able to present an accurate timestamp in the Sync message and do not need to send Follow_Up messages.

In order to accurately synchronize to their master, clocks must individually determine the network transit time of the Sync messages. The transit time is determined indirectly by measuring round-trip time from each clock to its master. The clocks initiate an exchange with their master designed to measure the transit time d. The exchange begins with a clock sending a Delay_Req message at time T2 to the master. The master receives and timestamps the Delay_Req at time T2' and responds with a Delay_Resp message. The master includes the timestamp T2' in the Delay_Resp message.

Through these exchanges a clock learns T1, T1', T2 and T2'

If d is the transit time for the Sync message, and \tilde{o} is the constant offset between master and slave clocks, then

\ T1' - T1 = \tilde{o} + d and \ T2' - T2 = - \tilde{o} + d

Combining the above two equations, we find that

\tilde{o} = (T1'-T1-T2'+T2)/2

The clock now knows the offset \tilde{o} during this transaction and can correct itself by this amount to bring it into agreement with their master.

One assumption is that this exchange of messages happens over a period of time so small that this offset can safely be considered constant over that period. Another assumption is that the transit time of a message going from the master to a slave is equal to the transit time of a message going from the slave to the master. Finally, it is assumed that both the master and slave can accurately measure the time they send or receive a message. The degree to which these assumptions hold true determines the accuracy of the clock at the slave device.[5]:Clause 6.2

Optional features

IEEE 1588-2008 standard lists the following set of features that implementations may choose to support:

Related initiatives

See also

Notes

  1. ↑ The profile capability under IEEE 1588-2008 allows the use of application-specific epochs.[5]:Annex B
  2. ↑ In IEEE 1588-2002, information carried by Announce messages is carried in the Sync messages. In IEEE 1588-2008, the Sync message has been optimized and this information is no longer carried here.
  3. ↑ IEEE 1588-2002 non-default domains use destination addresses 224.0.1.130 through 224.0.1.132 (see #Domains).
  4. ↑ Where x is the address scope (2 for link-local) as per RFC 2373 (see IPv6 multicast address)
  5. ↑ Peer delay messages are intended to propagate to the immediately connected neighbor. The multicast addresses for these messages are designed to be link-local in scope and are not passed through a router. IEEE 1588-2008 also recommends setting time to live to 1 (IPv4) or hop limit to 0 (IPv6) as further insurance that the messages will not be routed.
  6. ↑ Peer delay messaging is not present in IEEE 1588-2002
  7. ↑ In some PTP applications it is permissible to send all PTP messages to 01-1B-19-00-00-00
  8. ↑ IEEE 1588-2002 defined a domain as any interconnected set of clocks (regardless of whether they synchronized to one another) and used subdomain to refer to what is known as a domain in IEEE 1588-2008.
  9. ↑ IEEE 1588-2008 uses 224.0.1.129 as the address for all multicast messages.

References

  1. ↑ "IEEE 1588 Systems". National Institute of Standards and Technology (NIST).
  2. ↑ John Eidson (2 October 2010). "IEEE 1588 Standard Version 2 - A Tutorial". Archived from the original (PDF) on 18 June 2010.
  3. ↑ Eidson, John C. (April 2006). Measurement, Control and Communication Using IEEE 1588. Springer. ISBN 1-84628-250-0.
  4. ↑ "Meanings of common terms used in IEEE 1588". Nation Institute or Standards and Technologies. Archived from the original on 17 June 2010.
  5. 1 2 3 4 5 6 7 8 9 10 11 12 IEEE 1588-2008, IEEE, 24 July 2008, doi:10.1109/IEEESTD.2008.4579760
  6. 1 2 3 IEEE 1588-2002, IEEE, 8 November 2002, doi:10.1109/IEEESTD.2002.94144
  7. ↑ International standard IEC 61588: Precision clock synchronization protocol for networked measurement and control systems. 2004.
  8. ↑ ISPCS website
  9. ↑ SMPTE Publishes First Two Parts of Standard Enabling Deployment of PTP-Timed Equipment in Existing SDI Plants, Society of Motion Picture and Television Engineers, 2015-04-13, retrieved 2015-05-21

External links

This article is issued from Wikipedia - version of the Thursday, March 24, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.