Hybrid Mode PTP: Mixed Multicast and Unicast

Five Minute Facts About Packet Timing

By Doug Arnold.

Quiet! Such is the lament of a PTP slave in a delay request – delay response PTP network. A slave port needs to receive Sync and Announce messages from a master port, and it needs to send Delay_Request messages and receive the corresponding Delay_Responses. If the device on the network implement two-step timing, then the slave will also need to receive Follow_Up messages.

Figure 1. Sequence diagram for time transfer from a one-step master port to a slave port.

In networks which include multicast operation all ports which subscribe to a multicast address receive all messages sent to that multicast address. In the case of PTP, two multicast addresses are defined, one for event messages, which get timestamped, and one for general messages, which are not timestamped. Any port implementing PTP will need to subscribe to both multicast addresses.

Figure 2. This diagram shows the timing messages exchanged among a grandmaster clock and three slave clocks using multicast end-to-end PTP. The bridge may be a transparent clock or a switch or router with no PTP capability.  Color code: blue=Sync, red=delay request, green=delay response.

Consider the diagram in Figure 2. Notice that each slave receives not only the Delay_Response to its Delay_Request messages, but also the Delay_Requests and Delay_Responses for all of the other slave ports. If the network only has 3 slaves then perhaps this is of little consequence. However, in a large network with, for example, one thousand slaves, then nearly all of the messages received at slave port are intended for another node on the network. Imagine that you are expecting an important phone call from a family member, and you keep getting calls form robots trying to sell you something.

What can you do about this. There are a few options:

1. you can replace your switches with those which also act as PTP boundary clocks. In this case slaves communicate with nearest boundary clock, rather than the whole network. However, this may be cost prohibitive, or their may be no boundary clocks which have the desired bridging performance.
2. You can use unicast PTP
3. You can use mixed multicast/unicast PTP

Figure 3. This diagram shows the timing messages exchanged among a grandmaster clock and three slave clocks, using unicast PTP. The bridge may be a transparent clock or a switch or router with no PTP capability. Color code: blue=Sync, red=delay request, green=delay response.

Lets look at these last two options in more detail. Figure 3 shows timing messages for the same network as Figure 2, except that unicast PTP rather than multicast is used. Note that the slaves now do not receive Delay_Requests or Delay_Responses for other slave ports. However, the grandmaster must now send a separate Sync message to each slave.

Figure 4. This diagram shows the timing messages exchanged among a grandmaster clock and three slave clocks, using mixed multicast/unicast PTP. The bridge may be a transparent clock or a switch or router with no PTP capability. Color code: blue=Sync, red=delay request, green=delay response.

Figure four shows our network again, but with mixed multicast/unicast PTP. This mode is the most efficient with respect to PTP messages. The Sync, and Announce message (not shown in diagrams) will are sent multicast so that they do not have to be duplicated at the master. The Delay_Requests and Delay_Responses are sent as unicast messages so that the slave ports do not have to drop them. An assumption here is that the bridge will not have an asymmetry between mulitcast and unicast messages since PTP assumes that the propagation delays of the Sync message and Delay_Request messages are the same. Or if the bridge is a transparent clock, then it would need to support both multicast and unicast PTP.

If you have a large PTP network without boundary clocks, try mixed multicast/unicast PTP so that your slaves clocks can finally find peace.