Subject: Re: [AVTCORE] [avtext] draft-williams-avtext-avbsync updated

From: Kevin Gross <[email-masked]>
Date: Tue, 29 Nov 2011 15:07:10 -0700

Aidan and I ended up at the same conference in San Diego last weekend and
found time to discuss clock domain identification. We believe it
is desirable to use the same clock identification scheme for IDMS and
Aidan's work. Here's a proposal I've fleshed out based on our discussion.

The "clocksource" parameter should be improved to allow optional
specification of clock identifiers. Clock identifiers are derived from an
EUI-48 or EUI-64 as specified by IEEE 1588 (IEEE 1588-2008 7.5.2.2.2, IEEE
1588-2002 D.2). The listed identifiers would be for the current grandmaster
and other high-quality clocks on the IEEE 1288 domain, members of a
grandmaster cluster (IEEE 1588-2008 17.3) or an alternate master (IEEE
1588-2008 17.4).

If no clock identifiers are supplied, implementations may assume that a
match of the supplied attributes (e.g. PTP, version and domain identifier)
specifies the same clock. If one or more clock identifiers are supplied,
these should be compared to the available clock identifiers for the
specified domain. If there is at least one match, there is assumed to be a
clock match.

We both believe a traceability indication should be included in the
"clocksource" attribute for IEEE 1588-2002, IEEE 1588-2008, IEEE 802.1AS
and NTP. Galileo and GPS are implied traceable and local is presumably
never traceable. Aidan argues that  you shouldn't have to second guess
a traceable clock and therefore, no domain or clock identifiers are
required for traceable clocks.

Kevin Gross

> On Sun, Nov 6, 2011 at 9:12 PM, Kevin Gross <[email-masked]> wrote:

>
> IDMS defines a "clocksource" SDP attribute to identify the clock
> domain. The following clock distribution methods are supported by IDMS:
> NTP, GPS, Galileo, IEEE 1588-2002, IEEE 1588-2008 and IEEE 802.1AS. When
> IEEE 1588-2002 or IEEE 1588-2008 are used, a domain identifier is also
> specified. The IEEE 802.1AS PTP profile allows use of the default domain
> (0) only. You are proposing using the EUI-64 of the grandmaster instead. I
> also considered this possibility for IDMS but was confounded by the
> following scenario...
>
> For fault tolerance, mission-critical media systems are configured with at
> least two potential grandmasters all receiving time from a common reference
> (e.g. house sync reference, GPS). Upon failure of the primary grandmaster,
> another takes over and, although nothing has functionally changed about the
> clock domain, the EUI-64 of the grandmaster in the network does change.
> Until updated SDP advertisements reflecting the new grandmaster are
> received, senders and receivers will believe they are operating on
> different time domains and streams will presumably be interrupted.
>
> It would be very useful to have a unique identifier for a clock domain. My
> conclusion after considering the above scenario was that the grandmaster ID
> was not that identifier and clock distribution protocol, protocol version
> and domain identifier is currently the best identifier we have. I think
> there is definitely room for improvement in this. It does not strike me as
> an easy problem, however.
>
> I like your idea of using a traceability indicator to help determine clock
> compatibility. I am concerned however that while traceable clocks can be
> assumed to be frequency synchronized (syntonized) I am not aware of any way
> to gauge the accuracy of their phase synchronization. Nevertheless, adding
> a traceability indicator to the SDP clock attribute would seem to be a
> useful improvement.
>
>