Why are there 4 bytes after the PTP message?

Update: From M88 v1.0.17 (Qg2 SW v12.1.16) the padding bytes for UDP checksum recalculation in PTP messages are reduced to the mandatory 2, when running PTP over IPv6. In case of IPv4 the UDP checksum is no longer used.

If you wireshark PTP sync and delay response messages from an M88 or a Qg 2 you will see something like this:

As you can see, there are four additional bytes after the PTP message (00, 00, 59, and 95 in this example). What are they for and are they allowed to be there?

The reason for these four additional bytes is that for one-step, there is actually no time to calculate the UDP checksum and put it into the message after the HW timestamp has been taken. Instead we put in a default UDP checksum and then add bytes to the end, to make that default UDP checksum correct after we had the time to UDP calculate the checksum. The leading two bytes are entered as we calculate what that correction needs to be. In IPv4 UDP checksum is optional, so we would not need to bother about having it correct, but in IPv6 UDP checksum is mandatory and adding these "correction" bytes is the only way of getting the UDP checksum correct. For simplicity we apply the same mechanism both for IPv4 and IPv6.

From the IEEE1588-2008 standard, Annex E (Transport of PTP over User Datagram Protocol over Internet Protocol Version 6), section E.1: 

"Other than for purposes of calculating the UDP checksum, the contents of the UDP field beyond the end of the PTP fields shall be ignored by the receiver." 

In Annex D (Transport of PTP over User Datagram Protocol over Internet Protocol Version 4), Section D.4, Table D.2: 

"Except as required for backward compatibility with some version 1 hardware, nodes shall disregard the padding octets."

Hence, we believe a correct implementation on the receive side will look into the message length in the PTP header and ignore everything after this. However, there might be other implementations that assume everything after the UDP header is payload data, and they might have a problem with this.

Still need help? Contact Us Contact Us