ir input and pass that fre- quency along to the far end. On the other side of the link, the remote receiver can recover that fre- quency and use it to transmit Ethernet onto the fiber, thereby passing the frequency along as SyncE. Figure 9-35 illustrates how that might work. Recovered frequency Frequency recovered Recovered frequency Frequency recovered as SyncE output from transport used in transport from SyncE input ((p)) PRC/PRS Frequency looped frequency source SyncE for transmission SyncE SyncE Slave Frequency master Non-Ethernet network Figure 9-35 Frequency Transport over a Non-Ethernet Transport Obviously, the best outcome is that the transport system can carry a reference frequency natively using some physical method. This tends to be a binary yes/no capability based on the equipment. But when looking at the transport of PTP messages over the transport, the situation is more nuanced because, of course, the transport can carry PTP, but how well can it do it? 9.8.1 Carrying Phase/Time over the Transport System When the packet transport carries phase/time, the same issues arise as with the carriage of fre- quency. The issue of PDV is still a factor, but with the extra complication of asymmetry, which means a difference in message transit time between the forward and reverse direction. You have already seen that the asymmetry can also be caused by PDV and traffic load (see the section "Asymmetry" earlier in the chapter). The answer to these issues must be applied to two areas: the network elements themselves and the transport between them. The earlier section "Clock Performance" deals with the first area, where the designer considers the performance of the (PTP-aware) network element and how it resists the accumulation of PDV and asymmetry. But what about the second area, the links in the transport system? When network elements are linked together via some passive transport such as dark fiber, an Ether- net circuit running on that link has very little ability to inject any PDV or asymmetry into the timing si