known as a transparent switch, which connects groups of PTP devices without segmenting the PTP network.

A transparent switch recognizes PTP messages passing through and notes each message’s residence time, the time spent in the switch where the message is not yet visible by the intended PTP device. The residence time is added to the PTP message’s correction field just before being transmitted from the switch to the next device (see Figure 6). PTP clocks can then examine the received message’s correction field and apply it to their calculations. Even though the message was temporarily held up in the transparent switch—a nondeterministic behavior that normally introduces significant synchronization error—the correction field allows that time to be removed, as if the switch were never there (hence, the name transparent switch).

Unlike boundary clocks, transparent switches expose their slave devices to the PTP master. The transparent switch is typically interested in only a relative time (the time a message spends in the switch) and therefore does not need to have a timekeeper synchronized to the master’s time. The oscillators that “tick” in both the master and the switch, however, must tick at the same rate. Keeping this rate the same is known as syntonization. PTP specifies that transparent switches must be syntonized—not necessarily synchronized—to the master.

The peer delay mechanism. The synchronization model described earlier, where the slave issues a Delay Request message and the master responds with a Delay Response, is known as the delay request-response mechanism, or sometimes as end-to-end mode. PTP offers an alternative to this known as the peer-delay mechanism, or peer-to-peer mode, which can provide superior performance in certain situations. Because end-to-end mode and peer-to-peer mode cannot be used together, system designers have to evaluate which delay mechanism will provide the best results and design their systems accordingly.

In peer-to-peer mode, a device issues a Peer Delay Request message to its immediate neighbor, which may or may not be the device’s master. The receiving device responds with a Peer Delay Response message (and optionally a Peer Delay Response Follow-up after that

ntP remains
a popular
synchronization
technology, even
as more PtP
implementations
have been made
available to system
designers on more
platforms—both
commercially and
as freely available
open source
implementations.

if the device is operating in a two-step mode). This allows the requesting device to calculate the propagation delay for the individual segment.

By knowing the exact propagation delay for each segment of a network path, peer-to-peer mode allows PTP to apply delay compensations between master and slaves that are more accurate than end-to-end mode allows when the intermediate switches choose different paths. Since peer-to-peer mode specifies that transparent switches adjust the correction field with not only the residence time of Sync and Follow-up messages (just as a transparent switch operating in end-to-end mode does), it also adds the delay previously calculated for the link the message came in on (see Figure 7).

This behavior means the master need not process Delay Request messages from each of its slaves; instead it concerns itself only with Peer Delay Requests and Responses for its immediate peer (transparent switch or PTP clock in slave state). Because of this, transparent switches in peer-to-peer mode do not pass Delay Request or Delay Response messages. Unlike end-to-end mode, peer-to-peer mode can be even more attractive to system designers concerned with network traffic, since a master device need not receive and respond to each slave’s Delay Request messages, and concerns itself only with its immediate peer.

Profiles. PTP profiles allow organizations to specify selections of attribute values and optional features of PTP that, when using the same transport protocol, work together and achieve a performance that meets the requirements of particular applications. 3 Profiles make PTP better suited for particular applications while adhering to the more general PTP standard. Profiles can specify several aspects of the standard. There are two “default” profiles: Delay Request-Response (often referred to as end-to-end mode) and Peer Delay ( often referred to as peer-to-peer mode). Implementers must support at least one of these defaults. Profiles themselves are standardized and defined by a recognized standards organization that has jurisdiction over a particular industry (such as the IEC, IEEE, IETF, ANSI, or ITU). These organizations,