Hi Ron, I excluded NATs because I don't think that they are common in networks where enterprise profile PTP is used. So I just didn't want to address them,
I wouldn't say the same about TCs. Some TC implementations do change the source address, and some don't. I've seen both kinds at PTP plugfests. That is why the language in the draft says TCs might change the source. address. I think that this is important for network operators to know. That is why I want that statement in there. Technically speaking TCs do not forward frames/packets containing PTP event messages. Instead, they take them up the PTP layer, alter them, sed them back down to the data link or network layers and then transmit new frames/packets. That is officially true even in 1-step cut-through when the implementation combines all of these steps. At the PTP layer we call this retransmission, but that is not how it is viewed by the layers below. IEEE 802.1Q is explicit about this, and the IEEE 802.1 working group sent a message to the 1588 WG asking us to point this out in the 2019 edition of 1588. IEEE 1588-2019 subclause 7.3.1 starts with these two paragraphs: "All messages, including PTP messages, shall be transmitted and received in conformance with the standards governing the transport, network, and physical layers of the communication paths used. NOTE—As an example, consider IEEE 1588 PTP Instances, specifically including Transparent Clocks, running on IEEE 802.1Q communication paths. Suppose we have two Boundary Clocks separated by a Transparent Clock. The Transparent Clock entity (the PTP stack running above the MAC layer) is required to insert the appropriate MAC address of the Transparent Clock into the sourceAddress field of the Ethernet header for ALL messages it transmits. Other communication protocols can have similar requirements." Regards, Doug ________________________________ From: Ron Cohen <[email protected]> Sent: Wednesday, May 22, 2024 11:57 PM To: Doug Arnold <[email protected]>; [email protected] <[email protected]> Subject: RE: Enterprise Profile: Support for Non standard TCs Hi Doug, The draft states that deployments with NAT are out of scope of the document. “In IPv4 networks some clocks might be hidden behind a NAT, which hides their IP addresses from the rest of the network. Note also that the use of NATs may place limitations on the topology of PTP networks, depending on the port forwarding scheme employed. Details of implementing PTP with NATs are out of cope of this document.” A PTP TC that is a bridge per 802.1q or an IPv4/6 router must not change the source IP address of PTP delay requests. I’ve been working with TC solutions for more than 10 years. Both 1-step PTP TCs in HW (as well as 2-step in HW+SW) and none modified the source IP address of E2E delay requests, when working as either a bridge or router. This is the case for the products of the company I currently work for as well. My input is that per my understanding the following is not true for standard TCs: “This is important since Transparent Clocks will treat PTP messages that are altered at the PTP application layer as new IP packets and new Layer 2 frames when the PTP messages are retranmitted.” And with NAT services out of scope, this part should be removed in my opinion too: “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” I don’t have further new input beyond that. Best, Ron From: Doug Arnold <[email protected]> Sent: Thursday, May 23, 2024 12:05 AM To: Ron Cohen <[email protected]>; [email protected] Subject: [EXTERNAL] Re: Enterprise Profile: Support for Non standard TCs Prioritize security for external emails: Confirm sender and content safety before clicking links or opening attachments ________________________________ Hello Ron, For Ethernet - IEEE 802.1Q, I can't remember the RFCs for IPv4 and IPv6 but you can look them up. Here is the thing. I understand from a network layer model perspective a TC should not change the payload for a frame/packet and just forward it. However, there is no other way to do a cut-through 1-step TC. I pointed that out to the folks in IEEE 802.1 but they ignored me. I know for a fact that multiple companies' implementations of TCs do not replace the source address before retransmitting. I don't blame them. The standards are preventing a valuable use case just to preserve the purity of their layer model. I would be surprised if 1588 is the only technology that needs to change message fields on the fly in a cut through switch. Regards, Doug ________________________________ From: Ron Cohen <[email protected]<mailto:[email protected]>> Sent: Wednesday, May 22, 2024 2:58 AM To: Doug Arnold <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: RE: Enterprise Profile: Support for Non standard TCs Hi Doug, TC are not supposed to change source IP address of delay requests. If the TC is a layer2 switch/bridge, it must not modify the source MAC address while forwarding and must never touch the layer3 addresses. If the TC is a layer3 IP router, it must not modify the source IP address while forwarding and must change the source MAC address to the MAC address of its egress port. If the TC is a layer4 device, e.g., a NAT device, it modifies the source IP address of messages as it is its functionality. It may be the case that such functionality is required in the enterprise. My point is that it is far from obvious and the draft needs to elaborate why it’s needed. >> This is required by the standards that specify the transport networks. I would appreciate if you point to the relevant standards. The draft states that additional support is required for this deployment scenario: “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” These tables would be part of the IEEE1588 spec if this TC behavior was standard. It is not trivial to add support for these tables in HW, if you want to support scale and speed. Best, Ron From: Doug Arnold <[email protected]<mailto:[email protected]>> Sent: Wednesday, May 22, 2024 12:36 AM To: Ron Cohen <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: [EXTERNAL] Re: Enterprise Profile: Support for Non standard TCs Prioritize security for external emails: Confirm sender and content safety before clicking links or opening attachments ________________________________ 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]<mailto:[email protected]>> Sent: Tuesday, May 7, 2024 12:43 PM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[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]
