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,