The Art of Negotiation, the PTP Way

Five Minute Facts About Packet Timing

By Doug Arnold and Andreja Jarc

A previous post discussed unicast PTP. Most PTP Profiles are based on multicast communication. However, PTP can operate using unicast. This is necessary in networks which don’t support multicast, or if there is a large number of PTP slaves, which would generate too much multicast traffic. See the recent post on hybrid mode for more discussion on the multicast traffic topic.

The advantage of multicast is that a PTP device does not have to know anything about the other PTP devices on the network. Just subscribe to the two PTP multicast addresses. It’s like a pick up ball game. Just show up at the right field and you get to play. So what about unicast? Unicast PTP devices need to know a little more to get started. Specifically what is the network protocol address for the ports your want messages from. Note: In a layer three network the network protocol address is the IP address. Once it knows that, a slave port can negotiate PTP messages with the master port, using the PTP Unicast Negotiation Protocol.

Actually, the port which requests the unicast messages doesn’t have to be a slave port. And the port which responds doesn’t have to be a master port. IEEE 1588 allows ports in any state to request unicast messages, or to grant that request. So a master port might ask a slave port for Sync messages. Huh? Why? The answer is for monitoring the time transfer accuracy in the network. A master port might ask the slave port for time to check on the slave’s timing. Or a passive port on a multicast boundary clock might grant a request for unicast Sync messages from a port checking for timing errors in the network by getting time from two different paths. For these reasons IEEE 1588 refers to the parties in unicast negotiation as Requester and Responder, rather than as slave and master.

Going back to the case of a slave port asking a master port for time, it works like this. The slave port asks for Announce messages from all of the master ports on its list, i.e. the ones it has configured unicast addresses for. Note that I said master ports, not grandmasters. They might be ports on a Boundary Clock. Whichever master port has the best clock properties, gets further requests for Sync and either Delay Request/Delay Responses or Peer Delay messages. Each message type is negotiated separately. Often there is just one address on the list, and that makes the decision easy for the slave.  So far unicast negotiation is generally only used with the delay request/response mechanism, so we will focus on that case in this tutorial.

When a port asks for unicast messages it specified three attributes:
1. The message type (Announce, Sync, Delay Request/Response)
2. The message rate, for example 16 messages per second.
3. The duration of the grant, for example 300 seconds.

Figure 1.  Sequence diagram for a PTP slave negotiating, receiving and terminating Sync messages from a PTP master.

Once, granted the messages stop coming when any of three things happen:
1. The grant duration times out (this is the usual case)
2. The Requestor sends a cancel message, “I don’t need this anymore”.
3. The Responder sends a cancel message, “I’ve had it, I can’t do this anymore!”

The figure shows the Sync message grant being terminated by the Requester. This is kind of complicated, why do we need this? Well, we’re glad you asked. If a Responder is sending unicast message to a lot of Requesters, it might want to manage its capacity by terminating grants early or by saying no in response to a grant request. That’s right, a port can just say no to a request. IEEE 1588 also allows a Responder to grant part of a request, however to make things simpler the telecom profiles which use unicast require that a Responder either grant the whole request or say no. So that is how most implementations work. A negotiation can look like this:

Requester: “can you give me 64 Sync messages/second for 300 seconds?”
Responder: “No”
Requester: “OK, how about 16 Syncs/second for 300 seconds?”
Responder: “No”
Requester: “Oh come on, at least give me 4 Syncs/second for 300 seconds?”
Responder: “Yes”

So that is how this the general idea. As an example,  we show you how to configure this on a Meinberg LANTIME Clock…

Figure 2.  PTP configuration for an unicast slave on a Meinberg LANTIME Clock.

When you login into the LANTIME Web GUI follow to the PTP configuration dialog. Chose PTP as the operating mode, NTP which is available as other alternative stands for hardware NTP timestamping with 10 ns resolution.

To test a unicast communication we do not need any particular PTP profile, therefore we leave “Custom” in the Profile selection box, as per default.

In the PTP Mode we chose “Unicast Slave” from a dropdown list.

Next we need to configure an IP Address of Unicast Masters in the network or a domain, respectively. LANTIME supports a configuration of 2 master ports here.

For this example we leave Delay Mechanism to be E2E and the network protocol  UDP/IPv4. Also Priority 1 and Priority 2, features which play an important role at BMCA,  we leave for our case unchanged.

We set the Announce Interval rate from a dropdown list to 1 Msg/s; Sync and Delay Request Intervals to 16 Msg/s.

The Interval Duration defines how long the message grant between a requester and responder is valid for. After the configured time is passed, the requester has to re-negotiate messages rates with a responder again.

The Announce Receipt value specifies the time for announce receipt timeout messages which can be 2-10 times the Announce interval, with a default of 3. This is the time in the BMCA that port will wait before it decides that the master is no longer available.

It is important to configure an IP address of the requester in the same network and Domain as the master ports. For the network settings of the PTP port, proceed to the Network configuration dialog and define proper network settings as shown on Figure 3.

We are now finished. With these configuration steps on the requester part you should be able to do PTP tests with unicast masters available in the network. We hope it works for you!

Figure 3.  Network configuration dialog for the unicast slave.

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