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

[Brad Knowles]

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.


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?

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

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


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.

 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.

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.


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?

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

-- 
Brad Knowles <brad at shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>