Re: [TICTOC] Enterprise profile update

[Kevin Gross <[e-mail]>]

I've not been able to keep up with 1588v3 to know whether this has been
discussed there.

There is a 1588 profile under development by SMPTE for professional video
synchronization. Unicast delay request without 16.1 negotiation is
encouraged in the SMPTE profile as currently drafted. If we put this into
the enterprise profile, perhaps it is overstepping but we will not be alone.

Kevin Gross - AVA Networks


On Tue, Apr 8, 2014 at 11:11 PM, Richard Cochran
<[e-mail]>wrote:

> 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
>