[ntpwg] Documents, slides, etc. from WG meeting

[Stewart Bryant]

Brad Knowles wrote:
> On 10/24/07, Stewart Bryant wrote:
>
>>  In discussing 1588, you need to make sure you are  talking about the V2
>>  spec.  V1 is  not likely to see significant deployment, whist V2 is 
>> likely
>>  to get significant hardware support and hence be widely deployed.
>
> Therein lies the problem.  I've been going through the page at 
> <http://ieee1588.nist.gov/>, and I can't find any real discussion of 
> the protocol, or specifics of the implementations.  I didn't even find 
> any reference to V1 versus V2, and hence did not know that there was 
> an updated version.
V2 has not been published yet. It is currently mid way though the IEEE 
ballot process at the moment. You may also wish to be aware of the 
802.1AS project which is based on 1588 and is also in IEEE ballot.

You could also look at the proceedings of a number of the timing 
conferences over the past couple of years - WSTS, ITSF and the IEEE1588 
conference for more implementation and application information.
>
>
> Sure, they reference specific chipsets as implementing IEEE 1588, and 
> other specific devices (this is how I found out about the clock that 
> Meinberg makes).
>
> But when the description given for IEEE 1588 is completely circular in 
> nature, just exactly what good does that do for anyone?
I am not sure what you mean by that.
>
>>  Both V1 and V2 can use multicast IP encapsulation and you can in
>>  principle build an IP multicast net, but I have always regarded this
>>  mode of operation as a little strange and unlikely to ge deployed
>>  outside a highly controlled network. I doubt if we will ever see the
>>  1588 multicast mode on the Internet.
>
> We've talked to one of the guys at ISC about broad use of multicast on 
> the Internet, and they've explained why they believe that would be a 
> bad idea.
>
> You may get multicast internal to a given network at a single entity, 
> but you're unlikely to get it anywhere else.
>
>>  However V2 can run over a unicast IP connection, and this is likely 
>> to find
>>  use in wide area networks. Indeed it exists largely to support the 
>> needs of
>>  the telecommunications operators for a method of providing clock 
>> sync over
>>  packet.
>
> If it's used by telecom operators, why do they need IP or anything 
> else that heavy?  I mean, if we're talking about something like SONET 
> synchronization, and they're worried about sub-nanosecond resolution, 
> then it seems to me that IP is a very hefty hammer to be wielding.
They are migrating off SONET to Ethernet, and hence loose the ability to 
deliver sync to some applications (for example cell sites) that need 
sync. There is some work on Synchronous Ethernet (meaning Ethernet with 
synchronous carrier, NOT synchronous packets, but that requires an end 
to end sync path which may not be available, hence the interest in sync 
over packet. There are many other applications for tiem and frequency 
sync, but the mobile phone network is the poster child.
>
>>  I am not sure what you mean by this. How the grand master acquires and
>>  locks to an external clock reference is outside the scope of the 
>> protocol,
>>  but it's also outside the scope of the NTP.
>
> But we have reference clocks, right?  And we have a defined way to 
> interface with them?
Sure, you have Caesiums and GPS locked Quartz and Rhubidiums clocks, 
some subset of these speak 1588, just as some subset of them currently 
speak NTP, and by analogy some subset speak GPS.
>
>
> Honestly, I'm not trying to argue.  I'm trying to understand better 
> where IEEE 1588 fits into the picture, and I'm just not finding much 
> in the way of what I consider to be useful documentation on the IEEE 
> website.

You could read John Eidson's book, though this is mainly about V1. 
However it does give a lot of context and the applications are invariant 
to a V1 or a V2 solution.
>
> From what little I can tell, it seems to me that IEEE 1588 is much 
> more oriented towards a closed single-entity local area (or near-local 
> area) network environment, where you don't care if you're sync'ed to 
> any given external reference, or how close or far you may be from The 
> One True Time, you just care that all your internal slaves are sync'ed 
> to your given master, and that you have some pretty tight tolerances 
> on how far out of sync the slaves can get.
Absolutely not.

One of the GM selection criteria is external reference and that includes 
GPS, Atomic etc.
>
> In contrast, it seems to me that NTP works well on the broader WAN 
> multi-entity internet (global and beyond), and that it can work just 
> fine on smaller scale single-entity networks where sub-nanosecond 
> accuracy timekeeping is not required.
>
>
> The two protocols seem to complement each other pretty well, and it 
> would appear that the folks at Meinberg agree.
The key issue is that we need better accuracy in the wide area.
>
>
> Ahh, okay.  Found the URL for one of the tutorials at 
> <http://ieee1588.nist.gov/tutorial-basic.pdf>, which was a little more 
> diffcult to find than it needed to be, thanks to the frame-based way 
> the web pages are laid out.
>
> Anyway, Page 6 of the PDF is where we want to start, where they 
> specifically compare IEEE 1588 and NTP, among others.  I think they're 
> wrong to target the peer-to-peer mode exclusively for NTP, but that is 
> certainly one potential model that could be used with NTP.  There are 
> other master/slave relationships that would be more typical for use 
> with NTP, but that doesn't really affect the conclusions you can draw 
> from those slides.
>
> Slide 9 is also useful:
>
>     Objectives of IEEE 1588
>
>     + Sub-microsecond synchronization of real-time clocks in
>       components of a networked distributed measurement and
>       control system [0]
>
>     + Intended for relatively localized systems typical of
>       industrial automation and test and measurement environments. [0]
>
>     + Applicable to local area networks supporting multicast
>       communications (including but not limited to Ethernet)
>
>     [0] indicates objectives that may be extended in version 2
>
>
> Hmm.  Did they fix the assumption of symmetric delays between master & 
> slave in V2?
No. The asymmetry is a  fundamental issue in all two way time transfer 
protocols
>
> Or the complete lack of any kind of security?  I mean, UDP is 
> trivially easy to spoof, and given that everyone on the subnet is 
> supposed to be operating with the exact same information and the exact 
> same algorithms, it seems like it would be simple to see who the 
> current master clock is and spoof them as being bogus and force a new 
> master clock to be selected -- which you should be able to guarantee 
> is your selected trojan machine....
>
There is an informational description of a security mechanism in the V2 
specification, although I think that is something that the IETF should 
take a look at if we write and IETF 1588 profile.

Stewart