a stable frequency output on the slave clock places increased requirements on the quality of the oscillator, especially if the packet network is suffering high PDV. For those (and other reasons) there is an alternative used in large installations, called differential clock recovery (DCR), which brings the network clock back into the solution. Differential Clock Recovery DCR is designed to solve the same problem as ACR, which is for a network to carry a service clock transparently without the AC having to align with the network clock of the transport network. As seen in the preceding section, with ACR, the downstream node recovers the clock from the up- stream end of the CEM circuit by aligning its frequency with the packet arrival rate. With DCR, the upstream (master) clock inserts timestamps in the real-time transport protocol (RTP) header included in the CEM data packets. The slave clock recovers the clock from those differential timestamps. Including RTP is normally an optional component when configuring CEM circuits, but when using DCR, it is mandatory because the differential clock information is transferred in the RTP. See IETF RFC 3550 for more details on RTP. Figure 9-7 illustrates how the DCR method works. Both the master and slave end of the CEM cir- cuit have a network clock available, traceable to a common frequency source (normally it would be traceable to a PRC/PRS, but it could be just a common clock of different quality). The upstream master AC interface on that CEM node is using the TDM as a line clock to recover the frequency from the customer. Like the ACR case, it uses that frequency to both receive the incoming AC data and transmit the output data. CEM packets with Customer RTP headers Customer premises premises Service Service clock Ethernet/IP clock TDM attachment TDM attachment circuit circuit TDM clock recovered Customer Network clock Dejitter frequency buffer source Figure 9-7 TDM Circuit Emulation, Timed with Differential Clock Recovery But with DCR the electronic circuitry (such as an 