One of the primary objectives of IEEE 1588 is to achievesub-microsecond synchronization accuracy. To achieve this objective,the protocol must:
Provide one or more events that can be timestamped and used as thebasis for computing clock corrections,
Communicate the needed timestamps to the clocks requiring thisinformation, and
Overcome timing impairments introduced by the various componentsof the system.
Figure 3.9 below is asimplified diagram of the sequencing and critical timestamps associatedwith timing messages.
|Figure3.9. Timing diagram for synchronization messages|
The basic sequence in synchronizing a slave clock to a master clockis:
The master clock sends a Sync message to all directly connectedslave clocks. The master clock generates a timestamp t1 based on the master's local clock, indicating the Sync message sendingtime at the master clock.
A slave clock receives the Sync message and generates a timestamp t2 based on the slave's local clock, indicating the Sync message receipttime at the slave.
The master clock communicates the Sync message sending timestamp t1 to the slaves as a data field in a Follow Up message.
The slave clock sends a Delay Req message to the master clock. Theslave clock generates a timestamp t3 based on the slave'slocal clock, indicating the Delay Req sending time at the slave clock.
The master clock receives the Delay Req message and generates atimestamp t4 based on the master's local clock, indicatingthe Delay Req receipt time at the master clock.
The master clock communicates the Delay Req receipt timestamp t4 to the slave as a data field in a Delay Resp message.
The slave uses the four timestamps t1 , t2 , t3 ,and t4 to compute theoffset between the slave and master clocks.
The offset between the time as seen by the master clock and a slaveis computed based on the four timestamps present in the slave after anexchange of these four timing messages. This computation is based onthe following definitions of the quantities illustrated in Figure 3.9:
The measured difference between the time a Sync message isreceived at the slave and the time it was sent by the master:
ms difference= t2 – t1 (3.1)
The measured difference between the time a Delay Req message isreceived at the master and the time it was sent by the slave:
sm_difference = t4 – t3 (3.2)
The actual offset between the time observed on the master andslave clocks:
offset = t slave – t master (3.3)
The actual propagation time for a Sync message traveling betweenthe master and slave clocks:
msdelay = t 2m – t 1 (3.4)
The actual propagation time for a Delay Req message travelingbetween the slave and master clocks:
sm delay = t 4 – t 3m (3.5)
The following relationships are derived from first principles:
ms difference= offset + msdelay (3.6)
sm difference= – offset + sm delay (3.7)
Rearranging Equations 3.6 and 3.7 yields
offset = [(ms difference- sm difference)- (ms delay – sm delay)]÷ 2 (3.8)
ms delay + sm delay = ms difference+sm difference (3.9)
Thus, there are two equations (Equations 3.8 and 3.9) involving twomeasured quantities: ms difference and sm difference; and threeunknowns: offset, ms delay, and sm delay.
It is clearly impossible to solve Equations 3.8 and 3.9 withoutadditional independent measurements or assumptions. This problem is notconfined to IEEE 1588, but is shared by all synchronization protocolsbased on the exchange of timing information over channels with unknownpropagation delays. The assumption – Equation 3.10 – used by the PTPprotocol is that the two propagation times are equal.
If the error caused by this assumption is significant relative tothe required synchronization accuracy, then some sort of calibrationcorrection must be applied.
sm delay = ms delay = one way delay (3.10)
Combining Equations 3.1, 3.2, 3.8, 3.9, and 3.10
offset = (msdifference- smdifference)÷ 2 = [(t2 – t1 ) – (t4 – t3 )]÷ 2 (3.11)
one way delay = (ms difference +sm difference)÷ 2 = [(t 2 – t 1 ) + (t 4 – t 3 )] ÷ 2 (3.12)
The effect of path asymmetry on the calculation of clock offset canbe seen from the example in Table3.1, below .
|Table3.1. Example of asymmetric delay on offset computation|
In this example, it is assumed that the slave clock is 1 h ahead ofthe master, and that the master-to-slave propagation delays, and theslave-to-master propagation delays, are 30 and 40 min, respectively. Inthe table, entries enclosed in parenthesis are not used in thecomputations but are for reference only.
The example computed values for offset and one way delay of 55 and35 min, respectively, are in obvious disagreement with the assumedoffset of 1 h and the 30 and 40 min delays assumed between master andslave, and slave and master. The disagreement in each case amounts tohalf of the asymmetry in the assumed delay values.
It is clear that the timestamps associated with sending andreceiving Sync and Delay Req messages are critical to the operation ofthe protocol. Synchronization accuracy will depend in part on theaccuracy and repeatability of timing information derived from thesetimestamps.
Figure 3.10 below illustratesthe principal sources of timing impairments for a typicalEthernet-based clock and switch.
|Figure3.10. Timing impairments of system components|
Approximate values for the impairments in Figure 3.10 for a 10/100BaseT Ethernet system are shown in Table3.2 below . The impairments from operating systems arise fromqueues in the protocol stack, interrupt service routine timingdifferences, context switches, and load- and application-specificvariation in code execution times.
|Table3.2. Approximate Ethernet timing impairments|
Switch impairments arise from input and output queuing and variationin the access patterns to the switch fabric. Switches also have anadditional impairment, in that the path taken by the Sync and Delay Reqpackets may not be the same, thereby introducing asymmetry.
The PHY layer fluctuations and asymmetry arise primarily from theoperation of the phase lock loops in the receive path that are used torecover the received clock signal. Cable-induced fluctuations aretypically small, and arise from microphonics and similar causes.
Asymmetry in some cables, for example, CAT-5 cable often used inEthernet, is intentionally introduced to reduce crosstalk between wirepairs. The values for switch impairments, and to some extent operatingsystem impairments, are network traffic-dependent. Similar timingimpairments are introduced by the components of all transporttechnologies.
The magnitudes of the delay, fluctuation, and asymmetry values inTable 3.2 clearly require correction to achieve the goal ofsub-microsecond synchronization accuracy. Although not specified inIEEE 1588, the clock architecture shown in Figure 3.11 below is particularlyuseful in overcoming operating system and protocol stack impairmentswithin an ordinary clock.
|Figure3.11. Architecture of an ordinary clock in master state|
Figure 3.11 shows several useful IEEE 1588-specific hardwarefunctions. The key element is the packet recognizer and capture block(PRC block). This block passively observes both transmitted andreceived packets at a point as close to the network connection aspossible.
In an Ethernet environment, the media-independent interface (MII) isthe easiest point of access. The PRC block selectively detects all Syncand Delay Req packets. The details shown are typical of anEthernet-based node, and will be used in this discussion. Similartechniques can be used for other network technologies, although thedetails of the PRC block will differ.
The PRC block also:
Captures a snapshot of the local hardware clock to generate theappropriate timestamp t1 , t2 , t3 , or t4 depending on whether the unit is a master or slave, and whether thepacket is a Sync or Delay Req packet.
Captures identification fields from these packets. Thisidentification is used by the IEEE 1588 code to properly associate thetimestamp with the correct Sync or Delay Req packet.
The timestamp and captured identification information is sent to theIEEE 1588 code via a hardware interface and the operating system. Inthe case of a clock in the master state (Figure 3.11 ), this information isincluded in the Follow Up message.
|Figure3.12. Architecture of an ordinary clock in slave state|
Figure 3.12 above shows anode in the slave state receiving the Sync and Follow Up messages fromthe master. The PRC block performs the same functions on the receivedSync packet, passing timestamp t2 and the identification information tothe IEEE 1588 code in the slave.
When this code receives the actual Sync packet via the MII, and thenormal path through the operating system and protocol stack, it cancorrectly associate the timestamp with the Sync packet based on thisidentification information. A similar correspondence can be achievedwith the Follow Up packet, which also contains this same identificationinformation. Similar techniques may be used in constructing IEEE 1588in boundary clocks.
A similar sequence of events involving the Delay Req and Delay Respmessages occurs between the slave and the master. When all of thetimestamps are present in the slave, it computes offset and ratecorrections that are applied to the clock adjustment block on theslave, as indicated in Figure 3.12.
This brief overview of the hardware assist demonstrates the keyadvantages associated with IEEE 1588, namely:
The PRC block generates timestamps very close to the PHY layer.This effectively eliminates the operating system and protocol stackdelay, fluctuations, and asymmetry detailed in Table 3.2.
The two message feature of the protocol allows the timestampsgenerated by the PRC for the Sync or Delay Req messages to be easilyinserted into the companion Follow Up and Delay Resp messages by theIEEE 1588 code.
The timing of this insertion is not critical, and is therefore quiteeasy to implement. In a single message protocol, this insertion wouldhave to be done in hardware as the message was being transmitted. Thiscan certainly be done, but at a minimum would require hardwarerecalculation of the packet CRC.
System Management Overview
Messages of type management are used to provide access to IEEE 1588-specified parameters. These messages can be used by system integratorsor operators to customize a system of IEEE 1588 clocks if the defaultperformance is unsatisfactory. They may also be used for systemmonitoring and adjustment.
One of the objectives of IEEE 1588 is to be network-neutral. The PTPmanagement message suite meets this objective. For Ethernet IP systems,SNMP  is the de facto standard for device management. Other networktechnologies that in the future may be used in IEEE 1588 systems mayalso have their own management protocols.
The IEEE 1588 management messages can run in parallel withnetwork-specific protocols, or may be used internally in a device asthe basis for a protocol such as SNMP to access IEEE 1588 data. ForIEEE 1588 systems that include multiple network technologies, the PTPmanagement messages can be used throughout the system without the needfor protocol translators.
System-wide communication of management messages is a function ofboundary clocks. The communication of management messages between twoclocks on a link that does not include a boundary clock normally usesthe multicast model.
Such a link is termed a “PTP communication path”. For systemsincluding boundary clocks, management messages will be communicated todevices on separate PTP communication paths by the boundary clock,subject to some state restrictions.
To prevent unlimited propagation of management messages, the numberof times a management message can be forwarded by a boundary clock islimited by a field in the management message. Unlike the communicationof non-management PTP messages, which always are limited to a spanningtree, it is possible for a device to receive multiple copies of thesame management message if the underlying network topology forms acyclic graph.
The suite of management messages provides:
Clock discovery: the messages can be used to discover IEEE 1588clocks in a system.
State control: the messages can be used to initiate certain statechanges in an IEEE 1588 clock. Typically, these messages are used toinitialize a system or to remove a faulty clock from the system.
Data access: there are several sets of data maintained by a clock.These data include information about the state of the clock, propertiesof the clock used by the best master clock algorithm, and otherproperties. These data can be read by means of management messages andwritten to, in the case of modifiable data.
To read Part 1, go to “The varieties of system temporalspecifications.”
To read Part 2, go to “Overview ofthe 1588 clock synchronization standard.”
To read Part 3, go to “Master-slave Synchronization Hierarchy“
Used with permission of its publisher, Springer Science andBusiness Media, this series of articles is based on material from “Measurement,Control and Communication Using IEEE 1588,” by John C. Eidson andcan be purchased on line.
John C. Eidson, Ph.D., received a B.S. and an M.S. from MichiganState University and a Ph.D. from Stanford University, all inelectrical engineering. He held a postdoctoral position at Stanford fortwo years, spent six years with the Central Research Laboratory ofVarian Associates, and joined the Central Research Laboratories ofHewlett-Packard in 1972. When HP split in 1999, he transferred to theCentral Research Laboratory of AgilentTechnologies. Dr. Eidson was heavily involved in IEEE 1451.2 andIEEE 1451.1 and is the chairperson of the IEEE 1588 standards committeeand a life fellow of the IEEE.