What’s in the 2019 edition of IEEE 1588: Mixed Multicast Unicast Operation

Five Minute Facts About Packet Timing

By Doug Arnold

The next installment in what’s in the revision of IEEE 1588 discusses mixed multicast-unicast operation.

In a previous post I described the virtues of mixed multicast-unicast operation in PTP.  Sometimes this is referred to as the “hybrid mode”.  I summarize the conclusion here, but if you want to know why see the previous post.  In a nutshell the mixed multicast-unicast operation minimizes the number of PTP messages which are received on the PTP multicast addresses by nodes in the PTP network which are intended for other nodes.  This can be especially important when there is a large number of PTP slave ports talking to the same master port.  Such is often the case in networks which use non PTP capable switches or Transparent clocks (TCs) instead of Boundary Clocks.  If your network uses the Peer Delay propagation delay mechanism, then you are done.  No need to read the rest, since this all applies only to the Delay Request-Response mechanism, i.e. end-to-end PTP.

This is accomplished by sending the Announce, Sync and optional Follow Up messages as multicast since this information is the same for each slave port, and the multicast BMCA can operate.  The Delay Requests and Delay Response messages, however are sent as unicast, since these are unique for each slave port.  When this mode of operation runs in the field it usually does not use unicast negotiation for the Delay Request and Response messages, although negotiation is allowed.

The IEEE 1588 working group, in its wisdom*, anticipated a few issues with regards to this mode of operation which solve a few anticipated problems.  First, a PTP slave port receives Announce and Sync messages from the master port and then must send a unicast Delay Request message to the master port.  No problem, right? Just fetch the source address from one of the received messages and send a Delay Request to that address.   Well … that sometimes works, but not always. Consider the network shown in Figure 1.

Figure 1. Layer two PTP network with master port, TC and slave port.

The figure depicts a layer two network with a TC between a master port and a slave port.  If the Ethernet port diverts PTP messages up the network stack to a PTP application, before forwarding it, then, according to the rules of rules of Ethernet bridging, the Ethernet frame sent to the slave port should list the TC as the source of the message.  This is a requirement of IEEE 802.1Q which defines the rules for Ethernet bridging.  It is also a requirement for IPv6, although it is optional for IPv4.  Not all TCs follow these rules, but some do.  A slave has no way of knowing if there is a standards compliant TC in the path, so it cannot assume that the source address of any of the multicast messages are from the master port.

To solve this the new edition of IEEE 1588 defines a TLV which can be attached to the Announce message to inform slave ports of its protocol address.  The protocol address would generally be an Ethernet address for Layer two operation or an IP address for layer three.

Are we set for the unicast part of mixed multicast-unicast?  Not quite.  The master must reply to a Delay Request message with a unicast Delay Response.  But, again, the Delay Request message night contain the address of a TC, rather than the Slave port.  So we defined a multicast signaling message to advertise the unicast address of the slave ports.  It turns out this was needed to allow PTP management messages to, optionally, be unicast as well.

We also thought it might be useful to create what we call a communication capabilities TLV for master ports to append to Announce messages.  This TLV includes sends the information in Table 1 bellow, except the actual TLV would send either TRUE or FALSE for each table entry, not “TRUE or FALSE.”

Table 1.  The Communication Capabilities TLV.

For example, a slave port is configured to use mixed multicast-unicast operation receives a Communication Capabilities TLV from the master port with a Delay Request/Response column with all TRUE values.  The slave port now knows that is can use mixed multicast-unicast behavior, but only if it negotiates the unicast Delay Request and Response message.  What happens if the slave port is not capable of unicast negotiation? It might revert to pure multicast operation and raise an alarm, but that is up to the implementation.  The new standard does not specify this.  Note that there are unicast options for Sync as well in the table.  Some network operators prefer to keep Sync and Delay Request messages in the same mode, either unicast or multicast.  The concern is that switches will treat these messages differently creating a propagation delay asymmetry.

If you have any questions about packet timing, don’t hesitate to send me an email at doug.arnold@meinberg.de or visit our website at www.meinbergglobal.com.

* Not, infinite wisdom, but hopefully at least non-zero, finite wisdom.