nt in the TC. It does this by timestamping the message on ingress and again on egress and subtracts the ingress time from the egress time. That result of that subtraction is the time that the message is resident in the clock, and that value is then added to the correctionField in the PTP message. The correctionField in Delay_Req is calculated and updated similarly. Figure 7-9 outlines how the PTP messages flow through the various clocks in the E2E delay mech- anism. Note that the BCs terminate the PTP flow, while the TCs retransmit the incoming PTP mes- sages. Note that IEEE 1588-2019 now says that the PTP message in the TC is retransmitted as a new packet, although conceptually, it seems to pass through with only a modification of the correctionField. Ordinary Transparent Boundary Grand- slave clock (E2E) clock master Ordinary M = Master port Boundary Transparent slave clock clock (E2E) S = Slave port End to end (no Pdelay messages) Figure 7-9 PTP Clock Types-End-to-End Mechanism For the case of two-step masters (where the Sync message has the twoStepFlag set), the E2E will not update the correctionField in the Sync message but will instead update the same field in associated Follow_Up message with the residence time for the Sync message. So, with one-step clocks, the t1 timestamp and correctionField are both in the Sync message, but with two-step, the t1 timestamp and correctionField would be both in the Follow_Up (but the timestamp it contains refers to the Sync message, not the Follow_Up). That correctionField value is then read on the downstream slave port SO that it can take residence time into account when recovering the time and phase. Remember that E2E is the only method used with telecom profiles. The details of this mechanism are explained in section 11.3 of IEEE 1588- 2008. Recall from the discussion of one-step and two-step clocks that there is a distinction between one- step and two-step TCs. As one example, if a one-step E2E TC receives a Sync message, it will up- date the correctionField with the 