[ntpwg] Documents, slides, etc. from WG meeting
brad at shub-internet.org
Wed Oct 24 10:54:07 UTC 2007
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
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
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
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 
+ Intended for relatively localized systems typical of
industrial automation and test and measurement environments. 
+ Applicable to local area networks supporting multicast
communications (including but not limited to Ethernet)
 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>
More information about the ntpwg