Hello Ron, Yes. A TC is required to change the source address of a message at least for Ethernet and IP mappings. This is not an IEEE 1588 decision. This is required by the standards that specify the transport networks. Ethernet (IEEE 802.1Q) IPv4 and IPv6. A TC effectively changes the payload of the messages from the point of view of L2 and L3, so it is a new frame and new packet to those layers. I think that IPv4 has an option to alter a message in-route, but the node is supposed to zero out the source address.
Regards, Doug ________________________________ From: Ron Cohen <[email protected]> Sent: Tuesday, May 7, 2024 12:43 PM To: [email protected] <[email protected]> Subject: [TICTOC]Enterprise Profile: Support for Non standard TCs Hi, I’m late to the game here. I apologize in advance if this has already been discussed and decided: I can’t figure out why the profile needs to support non-standard TCs, or what seems to be a strange combination of a NAT+TC devices: “In PTP Networks that contain Transparent Clocks, timeTransmitters might receive Delay Request messages that no longer contains the IP Addresses of the timeReceivers. This is because Transparent Clocks might replace the IP address of Delay Requests with their own IP address after updating the Correction Fields. For this deployment scenario timeTransmitters will need to have configured tables of timeReceivers' IP addresses and associated Clock Identities in order to send Delay Responses to the correct PTP Nodes.” Is a standard TC allowed to change the source IP address of messages? There should be a strong reason to require support for such devices in a standard profile. Best, Ron /* * Ron Cohen * Email: [email protected]<mailto:[email protected]> * Mobile: +972.54.5751506 */
_______________________________________________ TICTOC mailing list -- [email protected] To unsubscribe send an email to [email protected]
