Five Minute Facts About Packet Timing
By Doug Arnold.
So far in this column we have talked about multicast PTP. Multicast is clearly critical to the working of the standard Best Master Clock Algorithm, since all the clocks need to discover who the possible master clocks in order to pick the best. However, some applications need unicast operation. It might be because the network is not set up to support multicast, or there is a desire to reduce overall traffic since the network is large. Sometimes there is only one slave and one master of interest and they just want to be alone with each other to have a private conversation without other PTP capable devices butting in. Whatever the reason IEEE 1588 2008 includes support for unicast operation.
A unicast PTP network is depicted below. Here the network is depicted as a cloud, since floating water vapor has been identified as the best metaphor for a system of cables and network appliances.
Note that a master can talk with multiple slaves, slaves can talk with multiple masters. In IEEE 1588 parlance each unicast master slave pairing is considered to be in its own little timing domain.
With multicast PTP a slave can stumble into a network without any clue who they are going to get time from. Not so with unicast. Unicast PTP slaves have to plan ahead. They need to have the address of the master all written in their little black book. In this cast the “little black book” might be an PTP construct called the Acceptable Master Table. The Acceptable Master Table lists the network addresses of masters which the slave knows about via user interface configuration.
Now that one or more masters have been identified the slave can use Unicast Negotiation to get Announce and Sync messages sent from the master, and to get Delay Requests answered with Delay Responses. The negotiation sequence is shown below.
The grant request messages, shown in red, are repeated when the duration of the grant, or contract, expires. For example a slave might ask for 4 Sync messages per second, for a period of 60 seconds. In this case after 60 seconds the master would stop sending Sync messages until another Sync message contract was negotiated. This might look like more handshaking than a political convention, but there is reason for it. Since the master must now have a separate conversation with each slave it might need to manage its capacity by having the ability to say no to a slave’s request for a certain message rate, for a specified period of time. The slave may optionally ask for a lower message rate and hope that the master will be more agreeable, or it can go to the next master on its list. The master can not make a counter offer, it can only say “No” until the slave asks for a rate which it can commit to under its current loading. Either the master or the slave can cancel the contract early by sending a cancellation message, and proper implementations can manage this without involving lawyers.
If you have any questions about PTP or NTP, don’t hesitate to send me an email at doug.arnold@meinberg-usa.com, or visit our website at www.meinbergglobal.com.
Hi Douglas,
I have been working on PTP unicast for 2 months now.
I took some samples of delay and plotted them as a graph.
One notices that with time, the delay between the master and the slave node decreases which is a good thing but i would like to know the reason behind it.
The delay is the message transport time right?..
Thanks 🙂
Ankit,
sorry for the long delay in getting back to you. I would suspect that the effect you see is caused by the fact that your slave device is synchronizing better and better to your Grandmaster clock, reducing the “error” in the delay measurement that is caused by the local clock of the slave.
Best Regards,
Heiko
Hi Douglas,
I am just starting to learning PTP and I have a question about logsyncinterval.
how does the master and slave negotiate the syncinterval when using unicast for transport?
Thanks
Koomier
When a PTP port requests a grant of messages, the request includes the logInterMessagePeriod. This is true of any of the messages that the port might ask for: Announce, Sync, or Delay Request/Response. IEEE 1588-2008 is rather vague about what the responder port should do if it cannot fulfil the entire grant. However, the telecom Profiles from the ITU which use unicast (G.8265.1, G.8275.2) are clear. They state that if the responder port cannot fulfil the entire grant, both message rate and grant duration, it should decline the request. So if the requester gets a “no” answer, it needs to reduce the message rate, or the grant duration, or both, and try again. Of course the requestor port can also try another responder on its list as well.
Note I am using the terms “requester” and “responder” rather than master and slave. This is because a PTP port is allowed to request, for example unicast Sync messages, even if it is not in the slave state. Similarly a PTP port not in the master state can grant and send unicast Sync messages. For example, you might want a slave port to send Sync to a master port for the purpose of monitoring the synchronization quality in the network.
I am doing some test on PTP between a slave and master over network and noticed that multicast is working but unicast does not work. Any reason why multicast mode can work but no the unicast ?
Hi,
We are working on PTP clock and frequency synchronization implementation within our organisation, and using http://linuxptp.sourceforge.net/ as reference to start with.
Our setup contains one master and one slave, so we decided to go with unicast transmission mode. We could see message exchange happening between master and slave such as Announce/Sync/Delay Request messages. But Master is unable to send the Delay Response message and the synchronization is incomplete.
Could you please give some pointers, how to debug this issue/similar issues.
Best Regards,
Giri Mahesh.
Hi Douglas,
I am trying to test PTP using ptp4l application for IPv6 (UDPv6) unicast. I wrote configuration file (linuxptp.cfg) like below, but getting parsing error for IPv6 unicast. Is Linux ptp4l supports IPv6 unicast? If so could you please let help in fixing this error. Parsing error is coming at line 15 in configuration file
1 [global]
2 delay_mechanism Auto
3 network_transport UDPv6
4 time_stamping hardware
5 step_threshold 0.000001
6 twoStepFlag 1
7 first_step_threshold 1
8 logAnnounceInterval 0
9 logSyncInterval 0
10 logMinDelayReqInterval 0
11
12 [unicast_master_table]
13 table_id 1
14 logQueryInterval 2
15 UDPv6 2001::2/64
16
17 [eth_red]
18 unicast_master_table 1
Thanks,
Hari Mulpuri
IEEE 1588 definitely allows for unicast mode over IPv6. Questions about about the ptp4l implementation should be addressed to the Linux ptp website at: http://linuxptp.sourceforge.net/