IEEE-1588 synchronization

IEEE-1588 synchronization

In continuation of time-synchronization article series, conceptually, IEEE-1588 synchronization is as simple as if you were asking the time from somebody and (s)he replying after looking at his/her watch. You would then correct your watch accordingly. This is simply:

Time to be set = Time told + some delay
But this simplicity just ends here.

Let us look at some of the issues we would face in the above scheme:

  1. To be very precise, you might want to calculate the exact delay it took him/her to tell you the time.
  2. In addition compensate for the time it would take you to set your own watch accordingly.
  3. What if this person is 4 km away and fastest way he can tell you the time is writing it on a piece of paper and sending through a homing pigeon? (No other source available)
  4. For calculating above delays whose time would you consider? Your own watch is not working as expected and you of course cannot borrow that person’s watch and there is no other reference.
  5. You definitely have no way of knowing when this carrier started flying towards you or if he lost his way in between, once or more, and took some breaks too.
  6. You probably want to send your own pet homing pigeons, to fly to him and back, to get an idea of flying latency by dividing this time by half.
  7. And if the delay you finally approximate is significantly more than the preciseness with which you want to set the time in your watch? Is it even possible?
  8. Maybe you plan to average out these delays over several trips to get a better approximation.
  9. Would your calculations be generic enough to give you the correct result, if this homing pigeon were to be replaced with a homing-duck or on the contrary if this person can tell you the time directly by calling on your phone?
  10. Wouldn’t your averaging process get skewed if you got no intimation of this abrupt change in carrier? Is there a way to know looking at the time-stamp? What if it is just a gradual but continuous slip?
  11. How would you conclude that your time is finally set and accurate w.r.t. that person? There is no second/third reference.
  12. Would you set your watch only once or correct it at every instance of the pigeon’s flight?
  13. Would you benefit by employing more than one flying carriers?

These questions are not an exaggeration of the situation, because in the computer networks the IEEE 1588 synchronization protocol aims at providing nanosecond accuracy even when the packets that are carrying the time-stamp data have millisecond latencies and sudden, random variations in delay, PDV (Packet Delay Variation), due to congestion, link failures and in addition the dynamic route changes, that remain invisible to the communicating nodes at two ends.



Let us now see how IEEE 1588v2 (version 2) works and accomplishes synchronization. The next figure is what you would commonly see no matter where you start reading about this technology because it depicts the idea very neatly:

IEEE-1588 synchronization

(Source: RTA Automation)

There are various interesting things to note in this figure:

  1. There are two time-lines (Master on left and Salve on right hand side) that depict the time in their respective clocks at any instant.
  2. Slave is a system that wants to synchronize its time with the Master clock. Master may be any system that is itself a very precise clock or getting synchronized from somewhere else.
  3. Slave clock (as you can see on top) starts from a garbage value (30) which is un-important and ir-relevant as it has to finally correct this time.
  4. It is also unimportant “when” the slave wants to synchronize with master. Slave system can boot-up at any time and wish to synchronize no matter what time it is.
  5. In IEEE-1588 synchronizaion, a Master system sends “Sync” messages (periodically) to the interested slaves. These are a type of PTP (Precision Time Protocol) messages that are sent over the IP protocol and contain the time-stamp (t1) when this packet left the master (like when the homing pigeon starts flying).
  6. This Sync Message reaches the slave system at time (t2). Note here that t1, t2 are not comparable with each other as they come from different clocks running independently, at least one of which (slave) contains a garbage value to start with. The only thing common between them is that both are the same physical quantity i.e. TIME. Also, we have discussed before that, it is not wise to say that slave is behind or ahead of master until we know for sure that slave is not faster or slower than the master. Otherwise no matter how much precisely we correct the slave clock, it will drift off.
  7. Once the Sync message has reached, the slave has two time-stamps t1 and t2. The slave can set its own time as equal to t1, but then it would not have accounted for the network delay (the time it took pigeon to fly to you) and a mere subtraction of these two would not give any meaningful information as both these clocks started at different unrelated and unknown times.
  8. In order to estimate this network delay, the slave sends a “Delay-Request” message back to the master at time t3, and the master replies to this with a “Delay-Response” message containing its own time t4, giving slave four different time-stamps to calculate the delay between master and slave, i.e. a set of {t1, t2, t3, t4}
  9. There is a concept of “Follow-up” message, but I will defer it for a later discussion.

After completing this set {t1, t2, t3, t4}, the slave system can apply the following standard formulae (to calculate the correction for its own clock) and get synchronized with the master.

Phase Correction or Offset = [(t2-t1) – (t4-t3)] / 2
Delay between master and slave = [(t2-t1) + (t4-t3)] / 2

So, Phase Synchronized clock = Slave clock – Offset

This correction is done over-and-over again, periodically to keep the slave in phase-sync with the master. A Master can support and provide timing to more than one Slave systems. The “sync” messages can be programmed to have a frequency from 2-10 to 210 Hz depending upon network bandwidth and accuracy requirements.

The master and slave do not need to be immediate peers, as the figure shows:

IEEE-1588 v2 Clock Recovery

Figure: Packet based mechanism for clock recovery
(Source: ADVA Optical Networking)

Real world challenge

Theoretically, the equations in previous section are all that is needed in an ideal world scenario with no delays or with fixed delays. The IEEE 1588 synchronization standard defines the PTP message formats and communication between master and slave and basic equations but leaves the processing of the time-stamps to the creativity of everybody. What makes this a challenge is the fact that, no two sets you would receive are same. Each time you calculate the delay and offset, you would get slightly different values. In fact, each time stamp is corrupted due to physical limitations, network congestion, impairment, sequence errors, collisions and retries as these packets hop through various service providers and networks. If you are expecting an accuracy which is of the same order of magnitude as the slight variations you see in the results of these equations, or if the results vary more than the accuracy you want, then you have to adopt various other methods that we would discuss shortly.

Another big challenge in real networks is the asymmetry due to which just dividing the full path delay by a factor of two would never give accurate result. The standards body is still working to resolve this issue.

IEEE-1588 synchronization Messages

IEEE 1588v2 proposes several message types. It is beneficial to group them based on functionality for better understanding.

  1. Ordinary clock (Slave clock):
    1. Sync message: This contains the origin time stamp (t1) and its arrival at the slave marks the destination time (t2).
    2. Follow Up message: The master stores and sends a precise version of origin time-stamp (t1) in this message.
    3. Delay Request message: The slave sends this message at time “t3” to gauge the delay.
    4. Delay Response message: The master time-stamps the arrival (t4) of delay-request message and send it in this response message.
  2. Transparent clocks can use extra messages that do not differentiate systems based on master or slave. Using the following messages, two peer nodes can know the mean path delay between each other. This is extremely useful in rapid recovery from change in network topology. (Please see the explanation of Transparent clock in the advanced section)
    1. Peer delay Request message.
    2. Peer delay Response message.
    3. Peer delay Response Follow Up message.
  3. Announce messages are used by the BMC (Best Master Clock selection algorithm) in IEEE 1588-2008 to build a clock hierarchy. Announce message tells the quality of the clock and frequency with which it would be transmitting the Sync messages. It would also tell whether a two-step clock (i.e. Follow-up message) is supported or not.
  4. Management messages are used to monitor, configure and maintain a PTP system.
  5. Signalingmessages are used for non-time-critical communications.

These PTP messages can be transported over UDP over IPv4 or IPv6 or IEEE 802.3 over Ethernet.

Advanced Concepts

To make things more interesting and help achieve higher accuracy, the standard provides guidelines for various advanced systems in IEEE-1588 synchronization. These are:

Two-step clock

We deferred the discussion of a “follow up” message until now, because 1588 can work even without it, although with less precise results. This message contains the precise time-stamp when the Sync message left the Master “Hardware” successfully. There are two ways to send the t1 time-stamp to the slave:

  1. Capture the RTC, prepare a PTP packet, hand it over to IP layer for transmission.
  2. Capture the precise time-stamp when the above packet actually leaves the Master, and send this exact time-stamp in a “follow-up” message.

Thus, if a slave receives a follow-up message, subsequent to a “sync” message, it should use the t1 time-stamp contained in this message as the “precise” value for better results. This is simply called a “Two-step” clock.

Boundary clock

For reliability reasons, not all the slaves are synchronized to the same PRC. The network is provided with dedicated intermediate clocks that supply timing to all the 1588 slaves. These nodes can be chosen by each slave individually based on its Best-Master-Clock algorithm and its proximity. They also reduce the load from a single master. Needless to say, a clock that is located closer would have lesser hops and lesser variations in the delay. As we know, the delay can be easily calculated, but the challenge is the filtering of delay variations.

IEEE-1588 Boundary Clock

Figure: A boundary clock
(Source: ADVA Optical networking)

We, a company with a huge market share in routing, should work towards Sync-E, IEEE 1588 Master and Boundary clocks. This is because the places where routers get installed are usually larger facilities and ISPs and lesser at end-users’ homes and offices. At these places the BITS, SONET-SDH timing and GPS are usually available and this timing has to be propagated to the user (which are serviced by various other individual vendors) through the low cost Ethernet at the last mile etc. It is a bet only to be won by companies that have penetration in the backhaul and the edge of the network.

Transparent clock

When a node talks to another node on the internet, there are numerous intermediate nodes through which the data passes and each one contributes to the delay in lesser or greater amount. These can be routers or plain non-intelligent switches and cross-connects. Transparent clocks are devices that compute the internal delay and modify the time-stamp in the PTP mesaage so they remain truly invisible. This is done to hide the store-and-forward and queuing related device delays and thus prevent them from accumulating with the PDV. Here is a design example for this concept:

IEEE-1588 Transparent Clock

Figure: Transparent Clock Design
(Source: Agilent Technologies)

By using a transparent clock, the nodes and system between two ends become invisible delay-wise, as shown in the next interaction between a master and a slave, where the PTP messages are also passing through a transparent clock:

Transparent clocks are “good-to-have” for the whole network as they benefit anyone who is synchronizing through 1588 PTP messages. The master and the slave do not really need to be “related” to any transparent clock on their way. There is no specific and direct revenue model for the transparent clocks. Installing it is more like a social service to all the network users. If all nodes in the path (that PTP message is traversing) are transparent, it reduces the delay variations and preciseness of synchronization increases.

Listen to this article
Listen to
this article
Text to speech by Listencat
Text to speech
by Listencat

AV Chrono

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Back to top
You cannot copy content of this page