ndustry profiles, with one example being the Power Profile (IEEE C37.238:2017) using the layer 2 (Ethernet) transport. But again, just note that no telecom profiles use this mechanism. The P2P delay mechanism is covered in a little more detail when addressing TCs because there are special TCs that support and enable the P2P method. For now, accept that a P2P TC is one that provides accurate transit time information for PTP event messages and processes the Pdelay mes- sages to implement the P2P delay mechanism. 7.3.1 One-Way Versus Two-Way PTP As stated earlier in this chapter, PTP is a two-way time protocol, and to recover frequency, phase, and time, it needs to be two-way-chiefly to estimate the one-way delay time (meanPathDelay) between the master and slave. However, if PTP is being used only to recover the frequency from the master, then the slave does not need to know the one-way delay time and therefore does not need to send messages to the master. By recovering frequency only, the clock is concerned that the rate of passage of time on the slave is the same as the master, and not worried about the offset in phase from the master clock. Therefore, for frequency-only synchronization, PTP can be a one-way protocol. How is this possible? Well, in frequency synchronization, the task of the slave is to ensure that the oscillator in the slave is running at very close to its nominal frequency. The way to do this is to get timestamps from the master over an extended period and see if the local clock is gaining or losing time compared to the master. If it is gaining time compared to the master, then the oscillator is run- ning too quickly, and if it is losing time, it is running too slowly. The slave doesn't really need to know the exact time and phase, just whether time is passing at the correct rate. One could imagine doing the same with a wristwatch and using a similar method to determine whether the watch gains or loses time. The wristwatch wearer would check the time against a relev- ant source (say, at the preci