is required to support PTP and SyncE, meaning that each node needs to be a T-BC or a T-TC (up to a maximum of eight T-TC clocks). This PTP support cannot be just some random PTP profile, but specifically the PTP G.8275.1 telecom profile, together with SyncE carrying frequency in hybrid mode. See Chapter 12 for details on specifying the require- ments for network devices. The level of performance of any PTP-aware device must meet the performance specifications for boundary/slave clocks in G.8273.2 and/or transparent clocks in G.8273.3. Similarly, the SyncE clock must meet the specifications for either G.8262 or G.8262.1 Ethernet clocks. Obviously, the better the performance of the individual T-BC or T-TC, the more accurate and stable the timing signal will be at the destination and the more hops it can be carried without ex- cessive degradation. The transport system is required to support PTP "awareness" from end to end. Any device in the transport system that processes packets in any meaningful way needs mechanisms to limit the timing noise and phase error that it introduces. The transport system is required to support transparent carriage of SyncE. Any transport device between network elements must be able to faithfully carry the frequency without introducing excessive jitter and wander. It must also honor and faithfully replicate the Ethernet synchroniza- tion messaging channel (ESMC) quality level values from SyncE. The network must introduce only a very small amount of asymmetry and PDV. With full on- path support and PTP-aware transport, these factors are well controlled, but for the PTS ap- proach, the network designer is responsible. The main benefit to the FTS approach is the last bullet point. When a timing solution is designed according to these principles, the resulting performance of the timing is deterministic and largely predictable. It is for these reasons that G.8275.1 and SyncE carried over an FTS network is the re- commended approach. But what happens then the FTS case cannot be supported by the