Time Synchronization

Time Synchronization
News & Tutorials from Meinberg
  • PTP / IEEE 1588
  • NTP
  • Configuration Guidelines
  • Industry Applications
  • Security
Home » IEEE 1588 » PTP Auto Mode

PTP Auto Mode

June 13, 2020 by Andreja Jarc Leave a Comment

Five Minute Facts About Packet Timing

By Andreja Jarc.

In this post I would like to introduce a method which can be deployed in versatile PTP networks, professional media, power or any other timing network.  Basically, it is a method which uses a combination of PTP and the Meinberg MRS (Multi-Reference-Source) feature which build together an elegant backup concept useful for many implementations.
Sometimes we call it “Safe Sync Redundancy (SSR)” and sometimes simply “PTP Auto Mode”.

What is it about?

Redundant networks

Let’s consider a redundant network with two master clocks, each with their own GNSS. They are both connected to isolated networks and cross linked to two switches. Some slaves can receive the timing from both networks. So, if one master clock or switch goes down, slaves connected to both networks would still be able to receive the timing.

Now, what will happen in such a network if a GNSS failure and a network error occur at the same time? One or both master clocks would be free running. Due to the network failure, the master clocks would not see each other, and they would both start sending timing packets into the network. Therefore, some slaves would get the timing from the grandmaster A and others from the grandmaster B.

Figure 1: An example of a redundant network. Due to a network failure some slaves are getting their time from a grandmaster A and some from a grandmaster B.

This situation can lead to synchronization islands, where a couple of slaves are drifting in one direction and others following the second master into the other. In case that one of the two grandmasters is free running the two groups will drift apart over time.

Figure 2: An excerpt from a Sync Monitor Map, where we simulated two sync islands: one group of slaves following the grandmaster A and the other the grandmaster B. The UTC reference is depicted as a green dot in the middle of the graph. PTP slaves are all marked as red dots.

The synchronization island problem can be solved if we cross connect the master clocks with a so-called PTP Auto mode (see Figure 3). Here, grandmasters would be able to see each other and the Best master clock algorithm (BMCA) would be able to identify the better one. The better one would become a grandmaster and would serve as a fallback reference for the other master clock. As the name “PTP Auto mode” tells you, a given PTP port can operate either as a master or a slave. In our case the better clock switches automatically to a master and the inferior into a slave role.

See also  What's in the IEEE 1588 revision: Interdomain interactions

We can use the BMCA well for this because with clock accuracy and clock variance even if both devices are in free run, one usually has less drift in holdover or one has a better oscillator. If everything is the same, the clock ID is eventually a tie breaker.
As a result all slaves would be getting timing from one grandmaster. 

Figure 3: PTP Auto Mode as a self-healing mechanism in case that two things happen at the same time: for example GNSS loss and a network failure. By using a PTP auto mode link between two PTP grandmasters you make sure that your slaves are always in sync to the same grandmaster.

PTP Auto Mode against GNSS vulnerabilities

Another use case for the PTP Auto Mode method is as a counter measure against jamming or spoofing. In our last blog post on GNSS jamming / spoofing we addressed different strategies how to protect your timing against either accidental or unfriendly events.  One strategy is to use multiple clocks and multiple reference signals since the source diversity can help.

Let’s say you have two grandmaster clocks. It is recommended that the two GNSS antennas are installed as far as possible from each other (see Figure 4). The longer distance would help if jamming is going on at one of the two locations.  

Figure 4: PTP Auto Mode used as a counter measure against a GNSS jamming attack.

You can connect the two grandmasters via PTP directly point to point, for example by using a long 10 km single mode fibre cable. The grandmaster that is affected by a GNSS attack would lose the GNSS. However, due to the PTP Auto Mode this grandmaster would automatically switch to a slave mode and would continue receiving accurate time from the other grandmaster 10 km away.

A similar setup can detect a spoofing attack via PTP measurement against the remote receiver. In case of spoofing the attacker would have to attack both sides at the same time with very high accuracy to make sure that both grandmasters are compromised to a new time. If the attacker is able to spoof only one of them this can be detected by measuring PTP quality between both clocks, for example with Sync Monitor, where you would measure the affected difference. You wouldn’t know which of the two is actually attacked, but at least you would be alarmed that something is going on and you can investigate the incident further.

See also  PTP On-Path Support Tests (Part II)

If you have more questions about the PTP Auto Mode don’t hesitate to send me an email at andreja.jarc@meinberg.de or visit our website at www.meinbergglobal.com.

Thank you for your interest in our blog. Wish you all to stay compassionate and strong in this challenging time.

  • share 
  • share  
  • share 

Related posts:

  1. What Are All Of These IEEE 1588 Clock Types?
  2. Hybrid Mode PTP: Mixed Multicast and Unicast
  3. The Art of Negotiation, the PTP Way
  4. BMCA deep dive: part 1
Previous Post - The PTP AUTHENTICATION TLV
Next Post - What’s in IEEE 1588-2019: DIY PTP Port States

Filed Under: IEEE 1588, Industry Applications, Security

Discussion Area:

If you enjoyed this post, or have any questions left, feel free to leave a comment or question below.

Share Your Comments & Feedback Cancel reply

PTP Software

  • PTP Track HoundPTP / IEEE 1588 Protocol Analyzer

  • NTP / PTP Simulation Software
  • Meinberg Advertisement

    Categories

    • Authors
    • Configuration Guidelines
    • IEEE 1588
    • IEEE 1952
    • Industry Applications
    • NTP
    • Security

    External Links

  • NTP Security
    • Site Notice
    • Privacy Policy

    You may also like

    1. What Are All Of These IEEE 1588 Clock Types?
    2. Hybrid Mode PTP: Mixed Multicast and Unicast
    3. The Art of Negotiation, the PTP Way
    4. BMCA deep dive: part 1

    © 2025 · Time Synchronization Blog

    MENU
    • PTP / IEEE 1588
    • NTP
    • Configuration Guidelines
    • Industry Applications
    • Security