e is no carriage of over-the-top PTP traffic on the system; it is carried by some other mechan- ism native to the transport. At the remote end, the transport system recovers the phase/time from the native mechanism and uses that phase/time to re-create a PTP packet stream to the downstream devices. Recovered phase/time Phase recovered used to timestamp PTP from PTP input Phase recovered Recovered phase ((p)) from transport used in transport ((2)) Non-Ethernet network PRTC T-GM Transport Transport phase/time slave phase/time master Boundary clock Figure 9-36 Phase and Time Transport over a Non-Ethernet Transport To the PTP network, the link looks like an extended, distributed boundary clock with PTP extin- guished at the ingress to the transport system and re-created on the egress side. In the same way that a network element can be a BC with a set of performance characteristics, SO can a transport link. This allows the link to be budgeted and modeled for time error just like every other link in the tim- ing chain. The limits for timing error allowed in timing distribution systems for telecoms are found in clause 7.1 of ITU-T G.8273.2. Of course, phase/time can be injected into the transport system centrally and recovered where ne- cessary; taking it from the data path isn't necessary. This is what many SDH/SONET systems did with frequency. The core nodes in these transport systems may be equipped with their own PRTC inputs to access phase/time and frequency sources for their own purposes. The mechanism used to carry phase/time internally to the transport system varies based on the tech- nology involved. It even varies based on the internal architecture of the system-for one example, see the following section "DOCSIS Cable and Remote PHY Devices" for details on timing inside the new packetized version of distribution for DOCSIS cable systems. 9.9 Non-Mobile Deployments This chapter draws to a close by updating a few of the use cases mentioned in the earlier chapters and showing the deployments applied to those spec