Re: [TICTOC] Enterprise profile update

[Richard Cochran <[e-mail]>]

On Tue, Apr 08, 2014 at 10:44:12PM +0100, Wojciech Owczarek wrote:
> On 8 April 2014 15:45, Richard Cochran <[e-mail]> wrote:
> 
> > But why not simply do what it says to do in 1588-2008 Section 16.1 ?
> >
> >
> Because doing this will require the GM to start keeping track of all the
> grants and their expiry and maintain a table of slaves, and will require
> the GM and the slave to implement the grants, refusals, cancellations and
> expiry. What the profile suggests hugely simplifies this. Out of the
> implementations supporting this behaviour today (many more than ptpd), most
> do it without unicast negotiation. This obviously doesn't mean anything,
> but shows that the industry already has a preference.

Well, if it is a "de facto" standard, then it does mean something. It
means that 16.1 is not really used or even implemented, in which case,
it should be removed from the next edition of 1588.

Is there anyone on the committee who can speak to this?

> On the master side, this behaviour actually is not a departure from the
> standard - it's explicitly permitted:
> 
> 9.5.12 states:
> 
> Delay_Resp messages shall be transmitted as multicast if the associated
> Delay_Req message was sent as
> multicast.
> Delay_Resp messages shall be transmitted as unicast if the associated
> Delay_Req message was sent as
> unicast.
> 
> - no mention of clause 16 here.

None the less, there is no provision in 1588 for transmitting unicast
Delay_Req *except* by using 16.1.
 
> 9.5.11.1 (slave side - delay req) states:
> 
> Delay_Req messages shall be transmitted as multicast except if:
> a) The optional unicast provisions of Clause 16 are used
> 
> Which indeed essentially already defines the mixed mode in combination with
> 16.1, but this is a combination of a "shall" with an optional feature, so
> this is inconsistent - therefore I think that the standard needs amended
> anyway, because currently both you and I are 50% right.

I think the wording of 1588 is consistent. You must use 16.1 if you
want to send unicast Delay_Req messages. If the authors of the
standard meant to allow slaves to send unicast any time they feel like
it, then there would have been no need for 16.1 in the first place.

>From my point of view, I see the unfortunate trend of PTP profiles
becoming mini standards all on there own (gPTP is an extreme case of
this), each one adding changes in incompatible ways. This is a
nightmare for anyone who wants to try and implement this stuff.

Thanks,
Richard