Hi Danny,
Yes, we (Symmetricom) have tested this. It does work. It basically is
what the 2step clock was designed for. You create an event message (SYNC) and
send it out. As it gets transmitted, you record the actual time of
transmission. Then you follow up with a general message (FOLLOW UP) in which
timing doesn't matter to send the corrected tx time. The slave sees the follow
up bit set in the SYNC message which tells the slave to wait for the follow up
packet before processing the timestamp.
This was designed as hardware wasn't available to insert timestamps
accurately but it was/is relatively easy to tap the G/MII channel to see the
packet flowing into the PHY. Obviously, you need to correlate the packet with
the timestamp which you can do by serializing transmission or looking at the
frame. This is part of the reasoning behind the draft in that, if the frame is
encrypted, it makes it easier to identify if there is a bit set somewhere.
Greg Dowd
gdowd at symmetricom dot com (antispam format)
Symmetricom, Inc.
www.symmetricom.com
"A clever person solves a problem. A wise person avoids it." Albert Einstein
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Danny Mayer
Sent: Thursday, October 13, 2011 5:08 PM
To: Kevin Gross
Cc: [email protected]; [email protected]; Cui Yang; David L. Mills
Subject: Re: [TICTOC] Review request for IPsec security for packet based
synchronization (Yang Cui)
On 10/13/2011 2:28 PM, Kevin Gross wrote:
> Definitely important issues for some synchronization protocols but it
> seems though two-step 1588 would work through such a connection. The
> followup message will contain an accurate (and encrypted) timestamp.
> Encryption delays would not result in significant loss of accuracy with
> respect to an unencrypted connection also using two step.
>
Has anyone tested or measured that? I have not seen any information how
this will work without losing accuracy. Don't forget the followon
message will also have to be encrypted and decrypted when sent making
for additional uncertainties and errors. I have not reviewed how the
two-step IEEE 1588 protocol works so I don't have a good understanding
of the effects of IPsec encryption on such packets.
Danny
> Kevin Gross
>
> On Thu, Oct 13, 2011 at 8:43 AM, Danny Mayer <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 9/18/2011 9:41 PM, Cui Yang wrote:
>
>
> IEEE-1588 (PTP) also cannot benefit from this as it is basically a
> hardware-stamping protocol and now you are routing it through a software
> tunnel which means it has to be timestamped before it is IPsec
> encapsulated which decreases it's accuracy. It's no longer on-wire.
>
>
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
