Subject: [TICTOC] Re: [ntpwg] Documents, slides, etc. from WG meeting

From: Stewart Bryant <[email-masked]>
Date: Wed, 24 Oct 2007 09:45:35 +0100

Brad
>   From reading the IEEE 1588 
> page, it's not clear whether this works over IP or not.
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.

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.

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.
> , although it 
> does seem to work over Ethernet (and maybe others?).  But IEEE 1588 
> seems to focus on ultra-high resolution, like sub-microsecond or even 
> sub-nanosecond.  Meinberg appears to have a clock that does both NTP 
> and IEEE 1588.
>
> But I'm not seeing how IEEE 1588 can provide synchronization to an 
> outside reference, and I'm not seeing how it can be used outside of 
> certain limited circumstances on a pretty much pure Ethernet network.
>
>   
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. However 1588 does have a grand master election mechanism
that - given honest representation by the clocks - selects the best 
clock as the
grand master to which the slaves synchronise and avoids the formation of
timing looks.

Stewart

_______________________________________________
TICTOC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tictoc

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 24 Oct 2007 13:25:19 +0100

Brad Knowles wrote:
> On 10/24/07, Stewart Bryant wrote:
>
>>  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.
>>  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.
>
> 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.
>>  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

---

From: Brad Knowles <[email-masked]>
Date: Wed, 24 Oct 2007 05:54:07 -0500

On 10/24/07, Stewart Bryant wrote:

>  spec.  V1 is  not likely to see significant deployment, whist V2 is likely

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.

But when the description given for IEEE 1588 is completely circular 
in nature, just exactly what good does that do for anyone?

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

>  locks to an external clock reference is outside the scope of the protocol,

 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.

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

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 <[email-masked]>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>

---

From: "Greg Dowd" <[email-masked]>
Date: Wed, 24 Oct 2007 13:45:29 -0700

At the recent ISPCS2007 plugfest, there were dozens of oem's demoing v2
of IEEE1588.  Symmetricom demonstrated v2 default profile (multicast)
and telecom profile (unicast) as did many others.  The v2 draft isn't
final yet which I imagine is why you don't see "pre-n" grandmasters
showing up as GA product.

In the unicast, multicast arena the same problem with delay requests
already applies but it's even worse.  V1 delay requests/response are
multicast (many-to-many).  In the v2 unicast model, each client
negotiates their own announce, sync and delay request flows with the
master.  More load on the master but the other ne's get the benefit.
Also, depending on the physical network implementation, some networks
don't allow multicast in both directions.

There is discussion ongoing on blended approaches such as that you
mentioned (mc sync with unicast delay) but that has the stronger
possibility of creating path asymmetry for time applications.  One thing
I haven't seen mentioned is separation of sync and servo.  In ntp, the
servo is intrinsically part of the protocol while 1588 separates the
two.

Lastly, regardless of the protocol the network itself is only capable of
passing phase and frequency to some level which is very difficult to
identify.  Google minTDEV.  

Ok, jury duty calls.  

-----Original Message-----
From: ntpwg-bounces+gdowd=[email-masked]
[mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf Of
David L. Mills
Sent: Wednesday, October 24, 2007 11:12 AM
Cc: NTP Working Group; [email-masked]
Subject: Re: [ntpwg] Documents, slides, etc. from WG meeting

Guys,

I have carefully trod over the V2 spec and investigated the available
1588-capable devices. You have to be very careful when comparing NTP and
1588. The bottom line is that NTP is best used to synchronizes computer
system clocks, while 1588 is best used to synchronize hardware interface
clocks and other data acquisition or telecom devices on a LAN. To
sustain the best accuracy, special Ethernet switches called boundary
clocks are necessary, so 1588 would not normally be expected to transit
a level-3 router, although in priciple it could.

The comments about 1588 V1 and V2 are interesting. All the devices I
know about from Symmetricom, Meinberg and 1588 Ethernet interfaces are
V1 (1588-2002). The Intel chipsets should be able to do both. The
Symmetricom 1588 grandmaster costs several thousand bucks and doesn't
even do NTP. The Meinberg grandmaster does 1588 and NTP and in fact does
everything the public NTPv4 distribution does, including Autokey.

There are a few straightforward issues that might have been overlooked. 
The computer system clock is typically interpolated by the PCC/TSC with
resolution 1 ns, but reading it via syscall typically burns 500 ns in
modern silicon. The resolution of a 1588 timestamp is 1 ns, while the
resolution of an NTP timestamp is 0.232 ns, although the difference is
not significant. It is reasonable that the ioctl time to fetch a
timestamp from a 1588 interface would be comparable to the time to read
the system clock, 500 ns.

The TCXO rock in a 1588 interface is not likely to operate at
frequencies much above 20 MHz, although a cold rock might be higher. In
other words, the 1588 resolution as a practical matter will be in the 50
ns range. The NSI Etherface and Symmetricom grandmaster claim resolution
of 50 ns.

What the above suggests is that 1588 will likely find the most important
application to synchronize LAN hardware interface clocks to a
grandmaster to the order of 50 ns. Real-time devices can provide signals
that latch the interface clock which is later read by the program. This
has nothing to do with the computer system clock.

However, it is interesting to speculate on how 1588 and NTP could
interoperate or support each other. In one approach 1588 can be used
within a LAN with time exported beyond the level-3 router by NTP. In
another, 1588 interfaces can be used to derive precision timestamps for
use by NTP. A project on my shelf is to modify the driver for my 1588
Etherface for use as a reference clock driver.

In answer to a previous question, 1588 V2 has the same limitations as
NTP; both use four timestamps to compute offset and delay and assume the
one-way delays are very nearly the same. There is a proposal for
security extensions to 1588, although it does not address the issue of
possibly degraded accuracy. Since 1588 uses hardware derived timestamps
and is not expected to face seriously hostile attacks as assumed in NTP,
this might not matter. As a very simple security provision, 1588 could
well adopt the NTP protocol defenses used to deflect hostile replays and
lost packets. This does not change the protocol or packet format.

Finally, the observation that 1588 multicast might become deprecated is
interesting. I make no judgement about that, but Symmetricom promotes
its use in networks with thousands (!) of 1588 slaves. Well, maybe; the
SYNC message is one-to-many, but this will be followed by thousands of
DELAY_REQ messages imploding at the grandmaster.

Dave

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

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

_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: "David L. Mills" <[email-masked]>
Date: Wed, 24 Oct 2007 18:11:46 +0000

Guys,

Dave

Brad Knowles wrote:

>> to find

---

From: "Mark Elliot" <[email-masked]>
Date: Thu, 25 Oct 2007 10:56:33 -0700

Since I'm intimately familiar with Symmetricom's NTP and IEEE 1588, I'd
like to correct some observations.  First of all, Symmetricom does offer
an IEEE 1588 grandmaster.  The same unit offers NTP at the same time.
NTP is an option and it is on a second port from IEEE 1588 card.  There
is nothing to prevent anyone from placing both of these services on the
same Internet subnet.  It's true that the current IEEE 1588 grandmaster
does support IEEE 1588 version 1.  In the same platform we've also
demonstrated IEEE 1588 version 2 in the last IEEE 1588 plug fest.
Therefore, you can conclude that at some time in the future will be
offering version 2 as well.

On the subject of supporting thousands of IEEE 1588 clients this is
true.  For IEEE 1588 version 1, set at a two second sync rate, a delay
request comes in from a client approximately every 30 seconds.  This
number is approximate for two reasons.  Reason number one is I don't
have manual in front of me right now and I'm going on remembered
laboratory experience.  The second and most important reason is this
rate is randomized so that all the requests do not come in at once.  On
average, 1000 clients will generate just over 33 packets per second.  

For the most part IEEE 1588 works well in the real world.  The only
disadvantage of this scheme is when one grandmasters fails over to
another grandmaster, the 30 sec. delay request message rate can ring the
system more than some people would like.  This is a well document and
explored subject within the IEEE 1588 group.  Version 2 has ways of
mitigating this last effect as well as a host of other features.

I hope this clarifies things, Mark Elliot.  

-----Original Message-----
From: David L. Mills [mailto:[email-masked]] 
Sent: Wednesday, October 24, 2007 11:12 AM
Cc: NTP Working Group; [email-masked]
Subject: [TICTOC] Re: [ntpwg] Documents, slides, etc. from WG meeting

Guys,

Dave

deployed.

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 26 Oct 2007 13:13:38 +0000

Mark,

I think we have talked before. I was told that the Symmetricom 1588 
grandmaster does not do NTP, but I was not told it could do NTP as an 
option. at the same time. I was told the customer would have to buy a 
separate server for that. The Meingerg grandmaster I have does both 
without special order option.

The delay request/response behavior is as expected and does mitigate the 
implosion hazard. However, the features noted on the web page for the 
XLI suggest the device is safe for up to thousands of clients. My 
experience and that of USNO and NIST suggest loads like this present 
special hazards independent of 1588 or NTP.

Dave