I read Annex B and Appendix III of T-REC-G.8275-202010, and I claim
that linuxptp already implements this functionality, even though there
is no "virtual port" explicitly modeled.
I also read about APTS in T-REC-G.8275.2-202003. This is what I learned...
On Mon, Jul 25, 2022 at 02:02:11AM +0000, Greg Armstrong wrote:
> Virtual PTP Port is defined in Annex B of G.8275. It was moved to
> recommendation G.8275 since it can be used in both G.8275.1 and
> G.8275.2 Profiles. It was defined before 1588-2019 Special
> Port. There are similarities, but not the same.
The text of Annex B is very thin indeed. I quote the meaty bits in full:
This annex describes the model for inclusion of a unidirectional,
phase/time interface on a PTP clock. High-level principles are
introduced in this annex.
When associated with an external input signal, a virtual PTP port
allows this external interface to participate in the PTP
protocol. As an input, this external port can participate in the
source selection with an associated virtual Erbest using the
associated virtual PTP port.
When associated with an external output signal, a virtual PTP port
allows communication of the PTP clock information to other
equipment.
That's it.
The key phrase is: "High-level principles are introduced in this annex."
In the case of linuxptp, the functionality of allowing an external
interface to participate is handled by the UDS management interface.
This works adequately for all use cases that I am aware of.
> APTS stands for Assisted Partial Time Support and is an option of
> the G.8275.2 Profile.
AFAICT, G.8275.2 does not really specify any kind of concrete protocol
or PTP stack behavior related to APTS. It seems to be used in a very
generic sense.
> IWF stands for Inter-Working Function and is defined in Appendix III
> of G.8275. It describes how to connect synchronization network
> segments that are running different PTP profiles.
We can already do this in linuxptp. Each port can be configured for a
different profile, and so the IWF is implicitly present in the
linuxptp software architecture. Once again, this works for all known
use cases.
So I really don't see any reason for merging the Virtual Port patch
series. It merely adds a second way to accomplish existing
functionality, but having two ways of doing the same thing violated
best software design practice.
Thanks,
Richard
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
