anism to improve the accuracy of the recovered clock. The correctionField is a 64-bit field in the common PTP header. Any nanosecond value is multiplied by 216 before being represented in the correctionField, which really means the lower 16 bits are sub-nanoseconds and the other 48 are nanoseconds. You could think of it as two subcomponents, nanoseconds and sub-nanoseconds, and the PTP dis- sector on Wireshark splits them and displays the correctionField split into two values. Wireshark labels the upper 48 bits as correction.ns and the lower 16 as correction.subms One example of the use of this (combined) field is to allow a TC to report a delay (the residence time measured by the TC) in the Sync message to the downstream slave, SO that the slave can re- move that delay from the calculation of meanPathDelay. For a two-step clock, the adjustment is made to the Follow_Up message rather than the Sync message. Beyond this example, the correctionField has several functions in a PTP network: Reporting residence time: The preceding paragraph gave an example of the use of the field to report residence time of Sync messages in TCs. The same approach can be used not only on Sync messages, but also on Follow_Up, Delay_Req, Delay_Resp, Pdelay_Req, Pdelay_Resp, and Pdelay_Resp_Follow_Up messages. Asymmetry correction: Any configured delayAsymmetry is combined with the correction- Field before the calculations of meanPathDelay and offsetFromMaster are done. In the E2E delay mechanism, this is done on the transmitting port for a Delay_Req or the receiving port for the Sync (or Follow_Up) message. In a case of a non-transparent clock, this is the slave port. To carry sub-nanoseconds: The PTP timestamp fields are integer fields for seconds (since the epoch) and nanoseconds. There is no field to carry sub-nanosecond values. The correctionField, having 16 bits to represent fractions of a nanosecond, is used to do this. The field is used differently in the case of E2E transparent clocks (E2E TC) from the peer-to-peer transparent clo