ry Clocks According to the official PTP definition, a BC is a clock with more than one PTP port. At the min- imum, it has one slave port (recovering the clock from a remote master port) and one master port (passing the clock downstream to another slave port). Of course, it could have more than one master port because it is able to send PTP traffic in many directions. Figure 7-8 illustrates how a BC fits into a timing distribution network. The PTP message flow from the master port (in this case on a GM) will be forwarded to the slave port of the BC. At the ingress port, those messages are timestamped, processed, and discarded. Similarly, messages in the reverse direction, such as Delay_Req, are created, the time of transmission is recorded, and the message is transmitted to the master. End-to-end phase alignment Master Slave Time carried Time carried Grand- Slave in packets in packets master Slave PRTC and clock Grandmaster Time carried in H/W Figure 7-8 PTP Boundary Clocks At the egress port, the mirror image of this process occurs. PTP messages are created, timestamped, and transmitted to the downstream slave. Similarly, traffic in the reverse direction, such as incoming Delay_Req, will be timestamped, answered (with a Delay_Resp), and discarded. Note that because the PTP message flow has been re-created, the PDV of the PTP message flow has been "reset" to zero. However, internally to the BC, there are hardware connections to distribute time and frequency around the node from the ingress port, to/from the timing hardware to the egress port. This means that the transfer of time through a properly designed boundary clock is predictable because the transfer of time is not compromised by either other traffic, forwarding plane events or asymmetrical delays on the node. The section "Hardware and Software Solution Requirements" in "Chapter 12. Operating and Verify- ing Timing Solutions", covers the hardware aspects of design, including more details of what is re- quired to build an accurate clock. But in summary, when 