ced in slave state to a remote grandmaster) should the local source fail. The physical interface to the local time source is a normal time/phase interface, such as the 1 pulse per second (1PPS) and time of day (ToD); there may also be a frequency source, such as 10 MHz. No PTP messages cross this interface. The data fields that the BMCA requires for the virtual port to determine the order of selection of slave port are configured on the boundary clock. For example, fields like stepsRemoved, domain number, and priority1/priority2 are defined by the network engin- eer in the configuration. Other fields, such as the grandmaster identity or stepsRemoved, must be determined by the implementation on the BC (since there is no real PTP grandmaster here). 7.3.1 Negotiation The IEEE 1588-2008 standard covers optional components. For example, the unicast discovery op- tion (section 17.5) allows PTP to contact the master in a network that does not offer multicast (which might be the case in many IP networks). It is used in combination with another optional component, negotiation (section 16.1), to discover the best master available over IP unicast. There- fore, the following discussion is of most interest to those working with unicast PTPoIP deployments. Firstly, the engineer configures the desired slave port with the IP addresses of all possible masters. Using the negotiation process, that PTP port then requests synchronization service from those IP addresses by a transmission of a unicast PTP signaling message. Simply put, the slave requests the master IP for the unicast transmission of Announce, Sync, and Delay_Resp (or Pdelay_Resp) mes- sages using the REQUEST_UNICAST_TRANSMISSION type, length, value (TLV) entity. The port being asked for service will be referred to as the grant port. When negotiating for a unicast transmission, the slave requests a message type, a message rate (lo- gInterMessagePeriod), and the length of time (durationField) for which the message flow is de- sired. As is normal in IEEE 1588, the rate is