What’s in the IEEE 1588 revision: Interdomain interactions

Five Minute Facts About Packet Timing

By Doug Arnold

The next installment in what’s in the revision of IEEE 1588 discusses PTP domains

Before we get started. A quick review on domains.  Every PTP message contains a domain number.  A PTP instance is configured to work in one, and only one, domain.  It is required to ignore messages with any other domain number.  The point of this complication is to allow different independent timing systems to inhabit the same network without confusing each other. For example, a management timing system and an experimental timing system.  The later might be used to test new PTP equipment. 

A device can have multiple PTP instances operating simultaneously, possibility operating in different domains.  However, from the point of view of PTP, they are different PTP instances. 

From a protocol point of view, domains are still independent in the upcoming revision, but we describe how multiple PTP domains can be used to accomplish certain goals in multidomain timing system.  One example is to transfer the time from one PTP domain to another.  The general idea is shown in figure 1 below.

Here timing metadata includes things like pending leap seconds, UTC offset, clock properties.  The purpose of the “sink adaptor” and source adaptor” is too reformate the timing information as needed by different subsystems.  The timing metadata includes whatever is needed for domain B to understand the time and clock quality it is given.  It does not however include PTP state information or things like steps removed which are properties of PTP rather than timing.  The bottom line is that PTP, including the BMCA, runs independently in each of the two domains. 

One application for interdomain time transfer is to translate one PTP profile into another one.  See the recent post on combining a telecom profile with a power profile in an electrical grid network.  Another use could be to bring time from one network to another, but without a network connection, since the networks are intended to be isolated.  Note that physically unconnected PTP networks are considered to be operating as separate PTP domains whether they use the same domain number or not.  Time transfer between isolated networks is illustrated in Figure 2.

In networks depicted in Figure 2, the source of time is a GNSS based clock in network B.  It is desired to use that time source in network A, but without having a network connection between the two isolated networks.  Instead a chassis with a PTP slave operating in network B puts timing information on the chassis backplane.  The timing information is used by another PTP card connected to network A, operating as the grandmaster.

Multiple domains operating in the same network can be used for redundancy as depicted in Figure 3.

In Figure 3 a robust slave clock includes three PTP instances acting in different domains to receive time from three different grandmaster clocks.  A voting algorithm can be employed by the robust clock to identify if any of the grandmaster has faulty time, according to majority vote.  In such a case faulty time could be due to clock failure, excessive network delays, network hacking, or GNSS spoofing.

Yet another type of interdomain interactions is related to a new optional feature in the upcoming IEEE 1588 revision, the Common Mean Link Delay Service.  But, oh my! My five minutes are up.  That one will have to wait for another post.

If you have any questions about packet timing, don’t hesitate to send me an email at doug.arnold@meinberg.de or visit our website at www.meinbergglobal.com.