On 10/14/2011 1:08 PM, Greg Dowd wrote: > 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. >
Good to know that. This implies that if these are NTP packets you need to be in interleave mode in order to support this. > 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. > How does identifying the packet help? If you want to do correlation then properly speaking you should be adding an ID to the packet so that the followon packet can carry the same ID to give you a way of updating that packet. According to what you are saying it doesn't matter that they have to be decoded at the receiving end, they will be processed and associated with the original packet. Danny > > 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
