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.
- ptp unicast
- ptp unicast multicast