The P2P TC treats the Sync and Follow Up messages the same as the E2E case but drops any Delay_Req and Delay_Resp messages. Therefore, unlike the E2E case, the calculation of the mean path delay between the master and the slave ports cannot be done using the Delay_Req/Delay_Resp mechanism between the master and slave ports. Instead, the mean path delay is calculated between neighboring peers using the P2P mechanism. This value is added to Sync or Follow_Up messages passing through the P2P TC. Figure 7-10 shows how the P2P TC interacts with the boundary and ordinary clocks. Boundary Ordinary Transparent Grand- slave clock (P2P) clock master Ordinary Transparent Transparent M = Master port slave clock (P2P) clock (P2P) S = Slave port Sync/Follow_Up (Delay messages dropped at P2P TC) Peer to peer (Pdelay messages) Figure 7-10 PTP Peer Delay Topology and Message Flow Note in Figure 7-10 that PTP ports in master and slave state also support the P2P delay mechanism. The P2P TC treats the Sync and Follow messages (short-dash arrows) the same as the E2E case but drops any Delay Req and Delay_Resp messages. With a P2P TC in the path, the calculation of the E2E mean path delay between the master and the slave ports is not possible because the Delay_Req and Delay_Resp are dropped by a P2P TC. In- stead, the P2P mechanism calculates the link delay between the neighboring peers (long-dash ar- rows) using Pdelay messages, and the E2E TC adds this value to the correction field of the passing Sync or Follow message. The computation of link delay is based on an exchange of Pdelay_Req, Pdelay_Resp, and possibly Pdelay_Resp_Follow_Up messages with the peer, as shown in Figure 7-11. As a result of these ex- changes, the link delay is known for each port of the P2P TC. Pdelay Transit time from A-B Requestor Responder Transit time from B-A Figure 7-11 PTP Peer-to-Peer Delay Mechanism The P2P method uses the timestamps in the same way as the Sync message case in the E2E method. So, the one-way link delay can be calculated by using the 