ansport mechanisms (de- pending on the profile-see details in the following sections): PTP over layer 2 (Ethernet) multicast PTP over IP (either IPv4 or IPv6) With the L2 mechanism, the PTP port on an interface simply listens to one of the two standard mul- ticast MAC addresses for PTP messages. There is no specific configuration to contact any master port on another PTP clock. The port simply subscribes to the traffic flow, and BMCA decides what state the port will enter (in this case, slave) and the port will start to recover the clock from the PTP messages. In the L3 (IP) profiles, the transport is unicast (note that other non-telecom profiles may use multic- last), SO there is no ability to "subscribe" to a multicast address. In this case, the operator must con- figure the slave port with the IP address of a remote master port to contact. The slave port will then contact the PTP port on that IP address and request the packet flows it wants to receive. It would first ask for Announce messages to determine whether that master port is advertising itself as trace- able to a grandmaster. If so, then it can ask to also receive timing messages and start to send Delay_Req messages to the master. See the earlier section "Negotiation" in this chapter for details of how this process works. For redundancy, the operator would normally configure the slave port with several IP addresses SO that the slave can always find a valid master to synchronize with should one or more of the connec- tions fail. Note that on layer 3 ports, you might not be able to predict the ingress (or egress) port of the PTP packets because that might be determined dynamically by the IP routing protocols. This can be a problem because the interface selected for sending and receiving PTP messages might not be activ- ated for timestamping. This is especially SO for devices either in the middle of the network or situ- ated in rings, but for a router at a remote cell site, you would expect perhaps only a single link to the back-haul network. 7.4.1 Bounda