Hi,

My understanding of the problem is as follows:

Currently nodes recognize 1588 packets at the physical ports and generate a 
timestamp on RX or TX at a reference point between the PHY and the MAC. This 
becomes complicated when we throw Ipsec as the nodes will now no longer be able 
to identify the 1588 packets that need to be timestamped/consumed. Ideally we 
would like the nodes to recognize all such packets at the port level and 
therefore generate a time stamp that can be later used after decrypting (or 
verifying Ipsec if its only being used for data integrity i.e. ESP-NULL). The 
earlier we recognize the packets that need to be time stamped the better it is. 

There is also an issue at the intermediate nodes which need to know if there is 
a 1588 packet inside the Ipsec tunnel so that it can be prioritized over the 
other packets.

I spoke to Rock and others in Beijing about this and I was told that having a 
separate Ipsec tunnel exclusively for transporting 1588 packets is not scalable 
in the femto architecture and we need a mechanism to unambiguously identify 
1588 packets within an Ipsec tunnel that's also carrying other service/data 
traffic. This, thus is the problem that 
draft-xu-tictoc-ipsec-security-for-synchronization is attempting to solve.

Is this correct?

Cheers, Manav

--
Manav Bhatia,
IP Division, Alcatel-Lucent,
Bangalore - India

 
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc

Reply via email to