The Precision Time Protocol (PTP) specified in IEEE standard 1588v2 is the latest in packet-based timing technology. Originally designed to provide precise timing for critical industrial automation applications, it is now providing the highest level of accurate frequency, phase, and time of day to wireless backhaul networks.

PTP overcomes the Ethernet NTP latency and delay variation issues, providing an unprecedented accuracy in the nanosecond range. The effects of network latency are greatly reduced by using a technique whereby the master and slave communicate with one another to cancel out a measured delay between the two nodes.

The IEEE1588 standard makes several assumptions about the network being used (e.g. multicast support) but the key assumptions that affect clock accuracy are:

  1. The transmission delays are almost constant over time (or at least change slowly)
  2. The transmission delays are symmetrical between master and slave (i.e. time to travel from master to slave is the same as from slave to master)

When carried over a Carrier Ethernet Network (CEN), 1588v2 requires a dedicated CoS or even a dedicated EVC – with stringent requirements on Frame Loss Ratio, Frame Delay and Inter-frame Delay Variation.

PTP Network Components

Figure 1 (at right) shows an example PTP synchronization network topology.

Grandmaster Clock

This is the primary reference source within a PTP sub-domain. The Grandmaster clock has a high-precision time source, which can be a GPS reference or an atomic clock.

Boundary Clock

Boundary Clock (BC) is specified by both Version 1 and Version 2 of IEEE standard 1588. The boundary clock functionality can be implemented in a switch/router at the boundary of a network.

IEEE 1588 boundary clocks are an effective way to reduce packet delay variation. A boundary clock runs the PTP protocol and is synchronized to the master clock. The boundary clock, in turn, acts as a master clock to all slaves within the same network.

The boundary clock acts as an interface between separate PTP domains intercepting and processing all PTP messages and passing all other network traffic. The boundary clock does not pass Sync, Follow_Up, Delay_Req, or Delay_Resp messages.

Cascading of boundary clocks introduces the cascade effect, because boundary clocks distribute timing based on the a local clock and so each clock depends on the quality of all preceding clocks. The Best Master Clock (BMC) algorithm (see below in PTP Operation) is used by the boundary clock to select the best clock any port can connect to. The chosen port is set as a slave to the selected Grandmaster clock, and all other ports of the boundary clock are asserted as masters to their domain. Figure 2 shows a network topology with boundary clocks.

 Transparent Clocks

Transparent clocks were added to version 2 of the IEEE 1588 standard as an improved method of forming cascaded topologies where each clock does not depend on the quality of the preceding clocks. Rather than acting as a multi-port ordinary clock as boundary clocks do, transparent clocks update a newly introduced time-interval field within PTP event messages. This 64-bit time-interval correction field allows for switch delay compensation to a potential accuracy of less than one picosecond.

There are two types of transparent clocks:- end-to-end and peer-to-peer.

End-to-end transparent clocks forward PTP event messages, but modify the messages to include the residence time for the message to traverse the transparent clock. The residence times are accumulated in the correction field of the PTP event message or the associated follow-up message. (See figure 3).

Peer-to-peer transparent clocks measure the local link delays using the peer delay mechanism, in addition to the residence time. The computation of link delay (peer delay mechanism) is based on an exchange of Pdelay_Req, Pdelay_Resp, and possibly Pdelay_Resp_Follow_Up messages with the link peer. (See figure 4).

Peer-to-peer and end-to-end transparent clocks cannot be mixed on the same communication path. Peer-to-peer transparent clocks can allow for faster reconfiguration after network topology changes.

In summary, transparent clock is a PTP enhanced switch which modifies the precise timestamps within the PTP messages to account for receive and transmit delays within the individual switch itself, thus leading to more accurate synchronization between the slave and master clocks.

PTP Operation

PTP operation is based upon the transfer of short messages to determine system properties and to convey time information. A delay measurement method is used to determine path delay, which is then used for the adjustment of local clocks. IEEE 1588 uses a specific algorithm – the Best Master Clock (BMC) algorithm – in order to determine which clock is of the highest quality within the network and to create a master/slave hierarchy.

The BMC node (grandmaster clock) then synchronizes all other nodes (slave clocks) in the network. The BMC algorithm is then run continuously to quickly adjust for changes in network configuration. So, if the BMC node is removed from the network or is determined by the BMC algorithm to no longer have the highest quality clock, the algorithm determines the new BMC node.

Figure 1 - PTP Synchronization Topology


Figure 2 - Topology with Boundary Clocks


Figure 3 - End-end Transparent Clocks

Figure 4 - Peer-peer Transparent Clocks



Related and Further Reading
 Timing | Circuit Emulation |




  1. user-c3471

    All the pictures can not be showed.

  2. user-f045d

    Broken links to all four drawings

  3. Hi user-c3471user-f045d

    The links are fixed now. Thank you for pointing this out.

    The resolution is not as high as we would like it to be, so we will rework the graphics as soon as possible in order to make them more legible.

    CC: Larry Samberg

  4. user-6fcd8

    Hello Larry Samberg

    One of the biggest issues the communications industry is facing with regards 1588v2 deployment for Phase, Timing and Time applications, is about network asymmetry, due to PTP's inability to compensate or deal with it and its direct effect in loss of accuracy.

    I wonder if MEF has any metrics for asymmetry in the real world (deterministic and variable).

  5. Hi Ildefonso Polo,

    This is a really important point and a real problem as you point out. I am not aware of any efforts to address this issue in the MEF (or anywhere else, but I don't track this very closely).

    This sounds like a good issue to post to the Carrier Ethernet group on LinkedIn to see if anybody else has insight.