[Linuxptp-devel] transportSpecific field

[Jesuiter, Henry (ALC NetworX GmbH)]

Hello,

according to IEEE 1588-2008 Annex D.4 it is possible to set the transport specific bit to signal that PTP event (and Announce) messages have to be padded. Now
we are discussing here, if that consequently allows to have a mixed mode PTP-Network, where one or more hosts set this bit and others don't. While we see here,
that linuxptp denies such mixed mode (you have to choose it by your config), we don't see that the standard would forbid it.

So, is there a standard-backed reason to choose that implementation in linuxptp or has is it just a behaviour (f.e. by simplicity in implementation, etc.), that should
be changed in future versions?

Best regards
Henry Jesuiter

[Richard Cochran]

This post might be inappropriate. Click to display it.

[Jesuiter, Henry (ALC NetworX GmbH)]

Post by Richard Cochran
We don't support the hardwareCompatibility bit. It conflicts with
gPTP according to 802.1AS. It is hack (I guess for a particular
vendor) for compatitibiliy with some legacy PTP Version 1 hardware.
Why on earth would you want it?

Thank you for your quick answer.

In fact we have a project here, that uses such mixed-mode network (some devices set that bit, other don't).
To distinguish between gPTP and PTP one could just use the additional information about the transport
layer, since gPTP uses Layer 2 while the hardwareCompatibility bit is defined for Layer 4. According to
your information we now will decide how to go on.

Best regards
Henry Jesuiter

[Richard Cochran]

This post might be inappropriate. Click to display it.

[Jesuiter, Henry (ALC NetworX GmbH)]

Post by Richard Cochran
When I first looked at it, I made a conscious decision *not* to
support it, because it appeared to me as a special hack for someone
pulling strings in the standards process.

That's exactly our opinion.

Post by Richard Cochran
Do you mind telling us what HW is using the hardwareCompatibility bit?

In the audio streaming world there are several companies that try to establish an
Audio over IP (AoIP) standard. One of the early proprietary standards (DANTE) is using PTPv1 in
its devices. In the last years there has been an overall standard developed (AES67) that
uses PTPv2 instead.

So currently all companies try to adopt that AES67 standard by building compatability-interfaces
into their products. Now, while that proprietary standard (DANTE) still supports PTPv1 for its own
audio streams, it need to support PTPv2 for AES67 compatibility (to all other manufacturers).
These devices have the hardwareCompatibility set in PTPv2 mode.

Since we are yet unsure if this is really necessary on their hardware (we still have to check this out), there
may be a chance we need to have that bit supported by the linuxptp implementation in a standard conform way.

Best regards
Henry Jesuiter