able performance requirements when trying to recover frequency from the packet stream at the slave. When using circuit emulation, and where the circuit has its own service clock that is being transported using ACR. Most of the information for this second case is for further study. This recommendation includes the following topics: Several network HRMs. Reference points for network limits in packet networks, which are the points at which network limits are applicable. Examples are at the output of the PRC, the output of the master packet clock, and the input and output of the slave packet clock. PDV network limits, which are defined as the maximum permissible levels of PDV at the input to the packet slave clock. These limits can differ based on the HRM. G.8261.1 really needs to be read in conjunction with G.8260, but it gives an idea of what network topologies and performance aspects are required to carry frequency over packet networks. G.8261.1 has not yet been consolidated into a single document, SO both the February 2012 version and the amendment 1 from May 2014 need to be read together. Both documents are available at https://handle.itu.int/11.1002/1000/12190 8.3.1 Synchronous Ethernet The recommendations for SyncE build upon the existing ones for TDM and physical frequency transfer as well as those that apply to frequency transfer using packet techniques. Therefore, in this section, you will see the recommendations for clocks that deal with the physical transfer of fre- quency via an Ethernet (packet) link. This section covers the standard SyncE clock and the newer, more accurate enhanced SyncE clock. These clocks used to be described as the Ethernet equipment clock (EEC) and the enhanced Ether- net equipment clock (eEEC). But since about 2018, Q13/15 is beginning to refer to the SDH equip- ment clock (SEC) from G.813, the EEC (G.8262), and the OTN equipment clock (OEC) as the gen- eric synchronous equipment clock (SEC). Similarly, the eEEC (and enhanced eOEC) are now re- ferred to as the enhanced SEC (eSEC).