Re: [Linuxptp-devel] [RFC V2] Add IEEE 802.1AS-2011 time-aware bridge support

[Rodney Cummings]

Hi Jagmeet,

At this stage I think the implementers of products with 802.1AS relay 
(previously bridge) capability would benefit greatly if they could use 
linuxptp. To that end, I think the participants in linuxptp should integrate 
802.1AS relay support however they see fit... BC... TC... I don't care. The 
main requirement is to meet the "shalls" in the 802.1AS standard, so that 
linuxptp interoperates well with other implementations.

That being said, the "does not conform to the complete specifications for a P2P 
Transparent Clock in IEEE Std 1588" was placed into 802.1AS-2020 intentionally. 
I think of it this way:
1. If you have a TC implementation, is it possible to use that TC 
implementation for a subset of an 802.1AS time-aware relay implementation? Yes
2. Is an 802.1AS time-aware relay considered a 1588 TC? No

Many major Ethernet switch semiconductor vendors participate in 802.1. Some of 
those switches have hardware support for TC. When 802.1AS syncLocked is true, 
it is possible to take advantage of such TC support, and some would argue that 
is intentional in the design of the 802.1AS standard. I suppose the same 
thinking could apply to linuxptp... TC code might make sense when 802.1AS 
syncLocked is true.

Nevertheless, there are aspects of 802.1AS relay that clearly fall into the BC 
category, like syncLocked false, and running the BMCA. I think that's why many 
of us involved in the 802.1AS standard tend to say "BC" when asked "What is 
it?". Overall, it seems safer to start with an assumption that it is a BC, and 
then take advantage of TC implementation if/when it makes sense. Doing it the 
other way (i.e., assuming TC overall and BC for the exceptions) seems a bit 
risky to me.

Rodney Cummings

From: Jagmeet Singh Hanspal 
Sent: Friday, February 21, 2020 10:33 AM
To: Y.b. Lu 
Cc: Rodney Cummings ; 
linuxptp-devel@lists.sourceforge.net; Richard Cochran 
; Erik Hons 
Subject: [EXTERNAL] Re: [Linuxptp-devel] [RFC V2] Add IEEE 802.1AS-2011 
time-aware bridge support

Hi,

> I realize all of that is anecdotal, in that
> a TC-based fork of Linuxptp might have performed well also. Nevertheless, I'm
> concerned that a fully TC-based implementation would move the code away
> from conformance with 802.1AS-2011, and interoperation would break as a
> result.

I'd like to know why the move towards BC based .1AS implementation, when the 
section 7.5 in .1AS 2020 shows that the AVB profile is like a very controlled 
BC, more like a P2P TC (+BMC) with its usage of Sync/Follow-up and PDelay 
message set (instead of Delay_Req / Delay_Resp pairs). Also, whether the 
syntonization of the bridge serves the purpose to send forward the corrections 
(residence + link delay) and calculation of rate-ratios, or a phase-sync is 
also required in the bridges implementing PTP relay, in which case BC might 
make more sense?

Regards,
Jagmeet


On Thu, Oct 24, 2019 at 9:28 AM Y.b. Lu 
mailto:yangbo...@nxp.com>> wrote:
Hi Richard,
May I have your comments?

Hi Rodney,
Please see my comments inline.

Thanks a lot.

Best regards,
Yangbo Lu

> -Original Message-
> From: Rodney Cummings mailto:rodney.cummi...@ni.com>>
> Sent: Tuesday, October 15, 2019 1:12 AM
> To: Y.b. Lu mailto:yangbo...@nxp.com>>; 
> linuxptp-devel@lists.sourceforge.net;
> Richard Cochran mailto:richardcoch...@gmail.com>>; 
> Erik Hons mailto:erik.h...@ni.com>>
> Subject: RE: [RFC V2] Add IEEE 802.1AS-2011 time-aware bridge support
>
> Thanks Yangbo,
>
> I'd like to interject some overall comments/questions before digging into
> comments on the code.
>
> In my opinion I prefer this v2 (BC) over the previous v1 (TC).
>
> To me, it isn't so much about the name. It is more about aligning the code 
> with
> the 802.1AS-2011 requirements ("shall"s). My employer (National Instruments)
> has been shipping our own BC-based fork of Linuxptp for years now (e.g. uses
> bc_dispatch() and bc_event() as is). That code has passed UNH-IOL
> conformance for 802.1AS-2011, performed well in 802.1AS-2011 plugfests (i.e.
> ICC, Avnu, ISPCS), and interoperated in customer applications with many other
> 802.1AS-2011 end-stations and bridges. I realize all of that is anecdotal, in 
> that
> a TC-based fork of Linuxptp might have performed well also. Nevertheless, I'm
> concerned that a fully TC-based implementation would move the code away
> from conformance with 802.1AS-2011, and interoperation would break as a
> result.
>

[Y.b. Lu] To me, I think BC is proper after you clarified that, although I 
thought it's TC before.

> Assuming the group is okay with BC, there is probably one other major
> question to answer before we go much further:
>Are we okay implementing the 802.1AS-2011 BC specifics in clock.c,
>or do we prefer to move most of that to a different file (bridge.c,
> gptp_relay.c, or whatever)?
>

[Y.b. Lu] I'm ok with any method. We can have Richard's comment.
From my patch, there were not too much ch

Re: [Linuxptp-devel] [RFC V2] Add IEEE 802.1AS-2011 time-aware bridge support

[Jagmeet Singh Hanspal]

Hi,

> I realize all of that is anecdotal, in that
> a TC-based fork of Linuxptp might have performed well also. Nevertheless,
I'm
> concerned that a fully TC-based implementation would move the code away
> from conformance with 802.1AS-2011, and interoperation would break as a
> result.

I'd like to know why the move towards BC based .1AS implementation, when
the section 7.5 in .1AS 2020 shows that the AVB profile is like a very
controlled BC, more like a P2P TC (+BMC) with its usage of Sync/Follow-up
and PDelay message set (instead of Delay_Req / Delay_Resp pairs). Also,
whether the syntonization of the bridge serves the purpose to send forward
the corrections (residence + link delay) and calculation of rate-ratios, or
a phase-sync is also required in the bridges implementing PTP relay, in
which case BC might make more sense?

Regards,
Jagmeet


On Thu, Oct 24, 2019 at 9:28 AM Y.b. Lu  wrote:

> Hi Richard,
> May I have your comments?
>
> Hi Rodney,
> Please see my comments inline.
>
> Thanks a lot.
>
> Best regards,
> Yangbo Lu
>
> > -Original Message-
> > From: Rodney Cummings 
> > Sent: Tuesday, October 15, 2019 1:12 AM
> > To: Y.b. Lu ; linuxptp-devel@lists.sourceforge.net;
> > Richard Cochran ; Erik Hons 
> > Subject: RE: [RFC V2] Add IEEE 802.1AS-2011 time-aware bridge support
> >
> > Thanks Yangbo,
> >
> > I'd like to interject some overall comments/questions before digging into
> > comments on the code.
> >
> > In my opinion I prefer this v2 (BC) over the previous v1 (TC).
> >
> > To me, it isn't so much about the name. It is more about aligning the
> code with
> > the 802.1AS-2011 requirements ("shall"s). My employer (National
> Instruments)
> > has been shipping our own BC-based fork of Linuxptp for years now (e.g.
> uses
> > bc_dispatch() and bc_event() as is). That code has passed UNH-IOL
> > conformance for 802.1AS-2011, performed well in 802.1AS-2011 plugfests
> (i.e.
> > ICC, Avnu, ISPCS), and interoperated in customer applications with many
> other
> > 802.1AS-2011 end-stations and bridges. I realize all of that is
> anecdotal, in that
> > a TC-based fork of Linuxptp might have performed well also.
> Nevertheless, I'm
> > concerned that a fully TC-based implementation would move the code away
> > from conformance with 802.1AS-2011, and interoperation would break as a
> > result.
> >
>
> [Y.b. Lu] To me, I think BC is proper after you clarified that, although I
> thought it's TC before.
>
> > Assuming the group is okay with BC, there is probably one other major
> > question to answer before we go much further:
> >Are we okay implementing the 802.1AS-2011 BC specifics in clock.c,
> >or do we prefer to move most of that to a different file (bridge.c,
> > gptp_relay.c, or whatever)?
> >
>
> [Y.b. Lu] I'm ok with any method. We can have Richard's comment.
> From my patch, there were not too much changes to reuse BC.
>
> > There's a short list of items that make 802.1AS-2011 BC different from
> > 1588-2008 P2P Default BC:
> >
> > 1. Transfer Sync / FollowUp differences from Slave (receive) to Master
> > (transmit) ports.
> > 2. Support distinct sync intervals on Slave and Master ports (like a
> typical BC).
> >
> > The v2 patch covers item 1 and 2, which are the core differences.
> Nevertheless,
> > it might be good to keep other differences in mind (i.e. future patches)
> before
> > we decide the preceding question:
> >
>
> [Y.b. Lu] Yes. The patch had core changes, so that it could be reviewed to
> decide which method is good to add it in linuxptp.
>
> > 3. Transfer Pdelay differences from Slave to Master ports (cumulative
> rate
> > ratio).
>
> [Y.b. Lu] I have already done that in patch. But it's different with
> standard. I'm very confused on this, and doubt the standard.
> See below changes.
> +   /* Update follow_up TLV */
> +   gm_rr *= nrr;
> +   fui->cumulativeScaledRateOffset = gm_rr * POW2_41 - POW2_41;
>
> I can't understand why standard gets rateRatio with,
> rateRatio += (neighborRateRatio - 1.0);
> not,
> rateRatio *= neighborRateRatio;
>
> As I understand, the rateRatio got from neighbor should be freq_gm /
> freq_neighbor.
> The neighborRateRato should be freq_neighbor / freq_cureent.
> So rateRatio for current device (freq_gm / freq_cureent) should be
> rateRatio * neighborRateRato.
>
> I will appreciate if you can help me to get it right.
>
> > 4. BMCA: Skip over UNCALIBRATED and PRE_MASTER states.
> > 5. BMCA: Remove foreign master qualification (i.e. change threshold from
> 2 to
> > 1).
> > 6. Check performance requirement in 802.1AS-2011 B.1.1 for neighbor rate
> > ratio computation.
> > 7. BMCA: FAULTY causes a State Decision Event. 802.1AS-2011's methodology
> > for faults is to avoid waiting in that FAULTY state in hopes that
> management
> > will notice. Instead, 802.1AS moves on to search for a valid non-faulty
> state
> > (SDE). If supported, the fault is logged so that management can notice
> later,
> > but that logging isn't a requireme