Telecom Profile With Full On-Path Support

Five Minute Facts About Packet Timing

By Doug Arnold.

A while back I posted about the Telecom Profile for Frequency Synchronization, or ITU-T G.8265.  In the view of the International Telecommunications Union (ITU), frequency was all they could promise with this profile since it assumed that there was no on-path support.  In other words the network contains no boundary clocks or transparent clocks.  The concern is that without on-path support the accumulative network queuing noise would be too large for precise time transfer.  That didn’t stop people from using the Frequency Synchronization profile to transfer time, but the general wisdom is you can recover time to within about a microsecond only when there are five or fewer switches and or routers between the master and the slave.

But what if your network could help?  Encouraged by the success of G.8265, the ITU decided to publish a sequel.  In fact, like all great works of literature, they decided to make it a trilogy.  The second profile, G.8275.1, would consider the case where ALL of the switches and routers are PTP aware, and G.8275.2 will consider the case where some switches are PTP aware and some are not.  The committee is still working on the the partial timing support profile, but the full on path support profile is out.  So let me tell you about it.

The document is called, “Precision Time Protocol Profile For Phase Time Synchronization With Full Timing Support From the Network.”  The assumption is that every switch or router between the grand master and the slave is a boundary clock.  Why not transparent clocks?  Perhaps the fact that a chain of boundary clocks are more akin to traditional telecom sync architectures than a chain of transparent clocks.  Whatever the reason, the sign on the door reads “no TCs allowed.”

PTP slave connected to a grandmaster through a chain of boundary clocks.

In addition to focussing on BCs for on path support, the profile makes the following selections among PTP and network options:

• PTP messages are multicast layer 2 (bare Ethernet).  In this architecture messages are only exchanged with adjacent devices, so layering the internet protocol on top of Ethernet doesn’t add any value.
• The End-to-end delay measurement mechanism is used.  The difference between end-to-end and peer-to-peer is minor in this network.  Either way the messages only go to adjacent devices.
• Sync and Delay Requests are sent at a rate of 16/second.  Announce messages are sent at 8/second.

The profile also contains an alternate Best Master Clock Algorithm or BMCA.  This is allowed by IEEE 1588-2008, since it is really a very permissive parent document.  The BMCA in G.8275.1 introduces a feature, which has been deemed by us standards folks as so useful we are planning on putting into the next edition of IEEE 1588. It is the Not-slave port attribute. Consider the diagram below.

Boundary clock connected to GMs and slaves

It is often undesirable to allow for an ordinary clock, which is nominally a slave, to EVER become the grandmaster of the network.  This might happen if the slave was misconfigured and falsely reported itself as the best master in the network.  To prevent this ports on the boundary clock can be configured as not-slave.  Recall that a BC has one port in the slave state and all others in the master or passive states.  In the diagram above, port 1 is in the slave state, getting its time from the active GM, port 2 is passive, and the rest are masters, sending the BC’s version of time to the slaves.  The BC could be configured so that ports 3-5 are Not-slave.  That would prevent the slave OC’s from accidentally taking over.

As with the G.8265 profile, the G.8275.1 profile is expected to have a large install base in the telecom industry.  It is the best option for a wireless backhaul green field installation, where you have the option of selecting switches which have boundary clock functionality. That means that lots of PTP equipment out there will support it.  So even if your application is not telecommunications this profile would work for you if you can ensure that all switches and routers are BCs.  If you like the added protection of the Not-slave feature, G.8275.1 enabled equipment may be the only way to get it in the near future.

If you have any questions about PTP or hardware timestamping, don’t hesitate to send me an email at doug.arnold@meinberg-usa.com, or visit our website at www.meinbergglobal.com.