s increasingly began to drop support for TDM connectivity. Therefore, many SPs are actively decom- missioning or have already decommissioned TDM connectivity. The current situation is that SyncE is the recommended solution because most equipment in the back-haul network supports it natively, and many transport options increasingly support it. With the improved performance of the enhanced eSyncE now becoming available, nothing can match it for frequency stability. The last alternative is to use a packet-based transport for frequency, which normally means PTP. This solution is recommended only where SyncE is not available as an option. NTP did have some role to play here, but operators regarded it as proprietary and only one vendor widely adopted it. It is no longer being actively proposed. And for PTP, it really makes sense to use the ITU-T G.8265.1 profile because it is designed to interoperate with SDH/SONET and SyncE (although you could re- cover frequency with G.8275.1 and G.8275.2). The next question to address is, what conditions would cause an engineer to choose SyncE rather than PTP or vice-versa? 11.2.1 G.8265.1 Packet-Based Versus SyncE At several points, this book examines the strengths and trade-offs between using PTP or SyncE to carry frequency. In summary, the main points for the MSP to consider in the decision include the following: Using G.8265.1 is easy because there is no on-path support needed (it is not even allowed). This means that an implementation only requires a PTP GM next to a PRC/PRS and a PTP slave clock where the frequency is required with an IP network connecting them together. The G.8265.1 telecom profile carries PTP with IPv4 (IPv6 optional), SO transporting the PTP and configuring the paths between the slave and master is straightforward. The main downside of the PTP approach is that the engineer needs to minimize any PDV in the network for the slave to be able to accurately recover frequency. This means (as a minimum) configuration of high-priority QoS on the intervening nodes ca