31.6.14 IEEE 1588 Support

IEEE 1588 is a standard for precision time synchronization in local area networks. It works with the exchange of special Precision Time Protocol (PTP) frames. The PTP messages can be transported over IEEE 802.3/Ethernet, over Internet Protocol Version 4 or over Internet Protocol Version 6 as described in the annex of IEEE P1588.D2.1.

The ETH indicates the message time-stamp point (asserted on the start packet delimiter and de-asserted at end of frame) for all frames and the passage of PTP event frames (asserted when a PTP event frame is detected and de-asserted at end of frame).

IEEE 802.1AS is a subset of IEEE 1588. One difference is that IEEE 802.1AS uses the Ethernet multicast address 0180C200000E for sync frame recognition whereas IEEE 1588 does not. ETH is designed to recognize sync frames with both IEEE 802.1AS and IEEE 1588 addresses and so can support both 1588 and 802.1AS frame recognition simultaneously.

Synchronization between host and client clocks is a two stage process.

First, the offset between the host and client clocks is corrected by the host sending a sync frame to the client with a follow up frame containing the exact time the sync frame was sent. Hardware assist modules at the host and client side detect exactly when the sync frame was sent by the host and received by the client. The client then corrects its clock to match the host clock.

Second, the transmission delay between the host and client is corrected. The client sends a delay request frame to the host which sends a delay response frame in reply. Hardware assist modules at the host and client side detect exactly when the delay request frame was sent by the client and received by the host. The client will now have enough information to adjust its clock to account for delay. For example, if the client was assuming zero delay, the actual delay will be half the difference between the transmit and receive time of the delay request frame (assuming equal transmit and receive times) because the client clock will be lagging the host clock by the delay time already.

The time-stamp is taken when the message time-stamp point passes the clock time-stamp point. This can generate an interrupt if enabled (IER). However, MAC Filtering configuration is needed to actually ‘copy’ the message to memory. For Ethernet, the message time-stamp point is the SFD and the clock time-stamp point is the MII interface. (The IEEE 1588 specification refers to sync and delay_req messages as event messages as these require time-stamping. These events are captured in the registers TSSx, EFTx, and EFRx, respectively. Follow up, delay response and management messages do not require time-stamping and are referred to as general messages.)

1588 version 2 defines two additional PTP event messages. These are the peer delay request (Pdelay_Req) and peer delay response (Pdelay_Resp) messages. These events are captured in the registers PEFTx and PEFRx, respectively. These messages are used to calculate the delay on a link. Nodes at both ends of a link send both types of frames (regardless of whether they contain a host or client clock). The Pdelay_Resp message contains the time at which a Pdelay_Req was received and is itself an event message. The time at which a Pdelay_Resp message is received is returned in a Pdelay_Resp_Follow_Up message.

1588 version 2 introduces transparent clocks of which there are two kinds, peer-to-peer (P2P) and end-to-end (E2E). Transparent clocks measure the transit time of event messages through a bridge and amend a correction field within the message to allow for the transit time. P2P transparent clocks additionally correct for the delay in the receive path of the link using the information gathered from the peer delay frames. With P2P transparent clocks delay_req messages are not used to measure link delay. This simplifies the protocol and makes larger systems more stable.

The ETH recognizes four different encapsulations for PTP event messages:

1. 1588 version 1 (UDP/IPv4 multicast)
2. 1588 version 2 (UDP/IPv4 multicast)
3. 1588 version 2 (UDP/IPv6 multicast)
4. 1588 version 2 (Ethernet multicast)

   Table 31-6. Example of Sync Frame in 1588 Version 1 Format

   Frame Segment	Value
   Preamble/SFD	55555555555555D5
   DA (Octets 0–5)	—
   SA (Octets 6–11)	—
   Type (Octets 12–13)	0800
   IP stuff (Octets 14–22)	—
   UDP (Octet 23)	11
   IP stuff (Octets 24–29)	—
   IP DA (Octets 30–32)	E00001
   IP DA (Octet 33)	81 or 82 or 83 or 84
   Source IP port (Octets 34–35)	—
   Dest IP port (Octets 36–37)	013F
   Other stuff (Octets 38–42)	—
   Version PTP (Octet 43)	01
   Other stuff (Octets 44–73)	—
   Control (Octet 74)	00
   Other stuff (Octets 75–168)	—

   Table 31-7. Example of Delay Request Frame in 1588 Version 1 Format

   Frame Segment	Value
   Preamble/SFD	55555555555555D5
   DA (Octets 0–5)	—
   SA (Octets 6–11)	—
   Type (Octets 12–13)	0800
   IP stuff (Octets 14–22)	—
   UDP (Octet 23)	11
   IP stuff (Octets 24–29)	—
   IP DA (Octets 30–32)	E00001
   IP DA (Octet 33)	81 or 82 or 83 or 84
   Source IP port (Octets 34–35)	—
   Dest IP port (Octets 36–37)	013F
   Other stuff (Octets 38–42)	—
   Version PTP (Octet 43)	01
   Other stuff (Octets 44–73)	—
   Control (Octet 74)	01
   Other stuff (Octets 75–168)	—

For 1588 version 1 messages, sync and delay request frames are indicated by the ETH if the frame type field indicates TCP/IP, UDP protocol is indicated, the destination IP address is 224.0.1.129/130/131 or 132, the destination UDP port is 319 and the control field is correct.

The control field is 0x00 for sync frames and 0x01 for delay request frames.

For 1588 version 2 messages, the type of frame is determined by looking at the message type field in the first byte of the PTP frame. Whether a frame is version 1 or version 2 can be determined by looking at the version PTP field in the second byte of both version 1 and version 2 PTP frames.

In version 2 messages sync frames have a message type value of 0x0, delay_req have 0x1, Pdelay_Req have 0x2 and Pdelay_Resp have 0x3.

For the multicast address 011B19000000 sync and delay request frames are recognized depending on the message type field, 00 for sync and 01 for delay request.

Pdelay request frames need a special multicast address so they can pass through ports blocked by the spanning tree protocol. For the multicast address 0180C200000E sync, Pdelay_Req and Pdelay_Resp frames are recognized depending on the message type field, 00 for sync, 02 for pdelay request and 03 for pdelay response.