wilamowski-b-m-irwin-j-d-industrial-communication-systems-2011

Clock Synchronization in Distributed Systems 18-3
Clock synchronization protocol
code
Timestamp point for
outbound messages
Outbound
message
stack
Inbound
message
stack
Timestamp point for
inbound messages
Access to communication media
Synchronization message
Ideal message timestamp
point
FIGURE 18.2
IEEE 1588 node model (PTPNodeModel.pdf).
data flows handle the data transmission for the two directions. The exact timestamp point for both the
DELAY_REQ and SYNC is unimportant for the further processing of the protocol as long as the position is
the same for all communication partners.
As soon as a node detects an incoming DELAY_REQ or SYNC message, timestamps for further processing
are generated. If the actual implementation is not able to detect the exact time of incoming messages,
the timestamp has to be corrected in an appropriate way. The time for a message to travel between
the ideal timestamp point and the actual timestamp point for inbound or outbound message point is
referred to as inbound latency and outbound latency for IEEE 1588.
18.4 Service Access Points
Beyond the logical division of subnets, PTP relies on the possibility of distinguishing messages with the
identification of the incoming service access point (SAP) mapped to the ISO model. For the example of
user datagram protocol (UDP), which is defined in the annex of PTP as a possible transport protocol,
this means that synchronization messages (i.e., SYNC and FOLLOW_UP) are sent to another UDP port
than all other messages.
18.5 Ordinary Clocks
Figure 18.3 shows a model for an ordinary PTP clock. Each PTP clock uses a communication path for
message exchange with other PTP nodes. This path is accessed in PTP via two different SAPs, namely the
event and the general port. Both hand over messages to the protocol engine of the PTP clock. In order
to model the fact that a clock may not be limited to only one PTP port, the configuration information is
© 2011 by Taylor and Francis Group, LLC