[Linuxptp-devel] PTP supported profiles.

[Emilio Marín López]

Hello PTP developers,

I'm checking what kind of PTP profiles are supported by the last release
of the linuxptp tool. I only have found this info at the README file:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
- Implements Boundary Clock (BC) and Ordinary Clock (OC).

- Transport over UDP/IPv4, UDP/IPv6, and raw Ethernet (Layer 2).
[...]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I've been sniffing around this mailing list and found a couple of mails
about the topic three years ago.

I would like to know if the following PTP profiles are currently
supported by the linuxptp:

- PTP default profile
- IEEE-C37.238 Power Profile
- ITU-1 G.8265.1 Frequency Profile
- ITU-T G.8275.1 Time and Phase Profile

... or if there is any plan to implement them...

Also I want to ask about the unicast traffic.

Thank you very much for your work and efforts

Best regards,

Emilio.

[Richard Cochran]

Post by Emilio Marín López
I would like to know if the following PTP profiles are currently
- PTP default profile

Yes.

Post by Emilio Marín López
- IEEE-C37.238 Power Profile

Yes and no. We do not produce messages with the profile specific TLV
attached. So, as a client, we can support this profile. It is simply
a matter of changing a few options in default.cfg.

Also, IIRC, the latest add on to IEC 61850 specifies something like
the Power Profile, but without the TLVs. So we support that, too.

Post by Emilio Marín López
- ITU-1 G.8265.1 Frequency Profile

No.

Post by Emilio Marín López
- ITU-T G.8275.1 Time and Phase Profile

Again, as a client, we can support this. As a Grand Master or
Boundary Clock, we don't support the profile specific "notSlave" or
"localPriority" options. Even without "notSlave", I expect that a
normal GM would work fine in this profile.

Post by Emilio Marín López
... or if there is any plan to implement them...

I might be able to offer ITU-T G.8275.1 later on this year, but I
can't promise it.

Post by Emilio Marín López
Also I want to ask about the unicast traffic.

We don't support unicast, and it would be lots of work to add it.

HTH,
Richard

[Miroslav Lichvar]

Post by Richard Cochran

Post by Emilio Marín López
Also I want to ask about the unicast traffic.

We don't support unicast, and it would be lots of work to add it.

Do you think it would be worth adding support for the hybrid
multicast/unicast mode, where only delay request and response are
unicast, in order to save network traffic in very large networks?
If I understand it correctly, this might work without the registration
part of the protocol.

[Richard Cochran]

Post by Miroslav Lichvar
Do you think it would be worth adding support for the hybrid
multicast/unicast mode, where only delay request and response are
unicast, in order to save network traffic in very large networks?
If I understand it correctly, this might work without the registration
part of the protocol.

We've got that already, as of v1.6.

776f772 Merge the hybrid E2E work.
e85cb68 Support hybrid E2E using unicast delay requests and responses.

Thanks,
Richard

[Miroslav Lichvar]

Post by Richard Cochran

Post by Miroslav Lichvar
Do you think it would be worth adding support for the hybrid
multicast/unicast mode, where only delay request and response are
unicast, in order to save network traffic in very large networks?
If I understand it correctly, this might work without the registration
part of the protocol.

We've got that already, as of v1.6.
776f772 Merge the hybrid E2E work.
e85cb68 Support hybrid E2E using unicast delay requests and responses.

Awesome, I didn't realize we already have that :). Full unicast
support doesn't seem very useful to me, but maybe I just didn't see
the right use case for it.

Thanks,

[Richard Cochran]

Post by Miroslav Lichvar
Awesome, I didn't realize we already have that :). Full unicast
support doesn't seem very useful to me, but maybe I just didn't see
the right use case for it.

It is specified in one of the telecom profiles. The ITU published two
profiles.

1. ITU-1 G.8265.1 Frequency Profile
2. ITU-T G.8275.1 Time and Phase Profile

#1 specifies unicast negotiation, forbidding multicast, boundary
clocks, and transparent clocks.

#2 specifies multicast, forbidding unicast. Transparent clocks are
also not allowed, but they are named as a future possibility.

Both profiles exhibit a surprising level of cluelessness, but #1 is
worse than the other.

Thanks,
Richard