Protocol Description

PTP Devices

For this version of Raptor, PTP supports end-to-end and peer-to-peer transparent clocks.

The other 2 types of clocks are ordinary and boundary transparent clocks. They are explained in this chapter but are NOT supported by this version of Raptor.

Ordinary Clock (not supported at the current version)

An ordinary clock can be a grandmaster or slave clock in a master-slave hierarchy. Master clocks provide the time reference to other nodes, and slave clocks synchronize to a master clock. The ordinary clock has a single PTP port and single PTP port state. It consists of the local clock, the PTP control engine, the data and port data sets, timestamp functions for event messages, and application functions.

Figure 1. Model of an ordinary clock

The ordinary clock executes the port state machine and BMC (Best Master Clock) algorithm to select the PTP port state. If the port is in the master state, the local clock is synchronized to an external source of time traceable to TAI (International Atomic Time) and UTC (Universal Coordinated Time) such as GPS (Global Positioning System) system. If the port is in slave state, the local clock is synchronized with its master clock.

A PTP ordinary clock sends and receives PTP messages to synchronize the clocks. The ordinary clock contains one physical port and two logical interfaces to handle PTP event messages and PTP general messages separately. The PTP event messages are timestamp messages. Ordinary clock can use Delay request-response mechanism or Peer Delay request-response mechanism to calculate the propagation delay. In addition to event messages, general messages are used to transport non-timing critical data between the devices, such as Announce or Follow_Upmessages. PTP ordinary clocks are connected application devices such as sensors or actuators.

Boundary Clock (not supported at the current version)

The boundary clock can be grandmaster or master or slave clock in a master-slave hierarchy. It can have more than one port. It has functionally similar to the ordinary clock, except that a boundary clock executes port state machine on each port and BMC algorithm to select the port state of each port. The local clock and clock data set are common for all ports in the boundary clock.

A boundary clock is used only as a network element and is not associated with application devices such as sensors or actuators.

Figure 2. Model of an boundary clock

End-to-End Transparent Clocks

End-to-end (E2E) transparent clocks forward PTP messages, measure the residence time of PTP event message at the transparent clock, and add this residence time in the correction field of the PTP messages. Transparent clock timestamps the event messages on ingress and egress port. The difference between these timestamps is the residence time within the transparent clock. E2E transparent clocks will not execute port state machine and BMC algorithm to select the state of the port. E2E transparent clocks may be used as a network element, or they may be associated with application devices such as sensors or actuators if an ordinary clock is combined with the end-to-end transparent clock.

In an end-to-end transparent clock, users can:

Configure PTP on global switch level.
Enable/disable PTP protocol at port level.
Show the current PTP configuration and statistics
Go to PTP mode and set mode to E2E Transparent mode or Peer to Peer (P2P) Transparent mode.
Set the number of ports that can support Transparent mode.
Set minimum amount of time between sending PDelay request message in P2P mode.
Save PTP configuration.
Debug the PTP module.

Figure 3. End-to-end transparent clock

RC stands for rate estimation and control and RE1—rate estimation relative to master.

Peer-to-Peer Transparent Clocks

The P2P transparent clock differs from the end-to-end transparent clock in the way it corrects and handles the timing messages. The E2E transparent clock time stamps all PTP timing messages; peer-to-peer transparent clock forwards only Sync and Follow up messages.

The P2P transparent clock

calculates the residence time of PTP messages in peer-to-peer transparent clock
uses Pdelay Req-Pdelay Resp mechanism to measures the link delay between two ports implementing link delay (the link delay is used to is used to correct timing information in Sync and Follow_Up messages)
uses rate estimation and control mechanism to avoid the residence time error.

The Peer-to-peer transparent clock use the following event messages:

Pdelay_Req
Pdelay_Resp
Pdelay_Resp_Follow_up

The P2P transparent clock may be used as a network element or it may be associated with application devices such as sensors or actuators if an ordinary clock is combined with the peer-to-peer transparent clock.

Figure 4. Model of a peer-to-peer transparent clock

Where,

RC stands for rate estimation and control,

RE1—rate estimation relative to master, and

RE2—rate estimation relative to neighbor.

PTP Transparent Clock with Profiles Configuration Summary

User configures PTP on global switch level.
With the current configuration, a user configures 4 profiles. User can create PTP domain explicitly (implicitly done by configuring profile).
User can enable/disable PTP protocol at port level.
User is able show the current PTP configuration and statistics.
User can go to PTP mode and can set mode to “E2E Transparent mode” or “P2P Transparent mode”.
User can set the number of ports that can support Transparent mode.
User can set minimum amount of time between sending peer delay request message in transparent P2P mode.
User can save PTP configuration.
User can debug the PTP module.

PTP Master-Slave Hierarchy

PTP forms the master-slave hierarchy with ordinary and boundary clocks in a such way so that all slave clocks are synchronized with their master clock. The clock at the top of the hierarchy is the grandmaster clock which will sync its time with external time source.

PTP uses different kinds of messages for its protocol operations. The following messages are used:

Announce
Sync
Follow_Up
Delay_Req
Delay_Resp
Pdelay_Req
Pdelay_Resp
Management
Signaling message

In the above messages, Sync, Delay_Req, and Pdelay_Req messages are called event messages, and all other messages are called general messages. The announce message is used to form master-slave hierarchy; all event messages are used for slave clock synchronization. Management messages are used to manage PTP devices. All event messages will be time stamped.

To provide more orderly behavior when a clock comes online, an ordinary clock or boundary clock listens for an Announce message from a master for a configurable time interval. If no announce message is received within this time, the clock assumes itself as the master until a better clock appears.

The Best Master Algorithm (BMC) is triggered periodically for each announce interval. The port state is selected by comparing the clock characteristic of other clocks received from the announce message and the clock characteristics of local clock.

If the port state is selected as master, it periodically sends Announce message and Sync messages on this port. If the type of the clock is two step clock, then it sends the Follow_Up message also. The master port sends the Delay_Resp message if it receives the Delay_Req message. It also sends the Delay_Resp_Follow_Up message if the clock is two step clock.

If a port is selected as a slave port, then it calculates the offset from master using the time stamped messages and adjusts its local clock time. The slave clocks calculate the propagation delay either using the Delay request-response mechanism or Peer delay request response mechanism.

If the slave clock uses Delay request-response mechanism, it sends the Delay_Req as soon as it receives the sync message. The master clock will send the Delay_Resp message in reply to the Delay_Req message. Using the time stamp in the Sync, Delay_Req and Delay_Resp messages, the slave clock calculates the mean path delay and calculates the offset from master.

If the slave clock uses Peer delay request-response mechanism, the slave clock should also have peer-to-peer transparent clock which will have link delay for all the ingress ports. The slave clock calculates the offset from the master using the time stamp in the sync message and the link delay from the peer-to-peer transparent clock.

PTP Synchronization and Syntonization

The time error of the slave clock with the master clock is corrected using synchronization. The calculation of OffsetFromMaster will correct the time error at the slave clock. The OffsetFromMaster is calculated using the following formula at the slave clock.

Figure 5. Basic Synchronization Message Exchange

If the type of clock is not a two step clock,

<offsetFromMaster> = <syncEventIngressTimestamp> ─ <originTimestamp> ─ <meanPathDelay> ─ correctionField of Sync message

If the type of clock is a two step clock,

<offsetFromMaster> = <syncEventIngressTimestamp> ─ <preciseOriginTimestamp> ─ <meanPathDelay> ─ correctionField of Sync message ─ correctionField of Follow_UpMessage

Where,

syncEventIngressTimestamp = t2

originTimestamp = t1

meanPathDelay = [(t2 – t1) + (t4 – t3)]/2 = [(t2 –t3) + (t4 – t1)]/2

The correction field depends on inbound latency, outbound latency, delay asymmetry in the communication path, and residence time at switches or routers in the communication path.

If the slave clock uses peer delay request-response mechanism, the mean path delay will be calculated using the following formulae:

Figure 6. Link Delay Measurement

If the type of clock is not a two step clock,

<meanPathDelay> = [(t4 − t1) − correctionField of Pdelay_Resp]/2

If the type of clock is two step clock,

<meanPathDelay> = [(t4 − t1) − (responseOriginTimestamp − requestReceiptTimestamp) − correctionField of Pdelay_Resp − correctionField of Pdelay_Resp_Follow_Up]/2

The rate error correction is called syntonization. This rate error is calculated using the following formulae and then the clock is adjusted for the rate error.

(<syncEventIngressTimestamp>N − <syncEventIngressTimestamp>) /

Where N is the number of syncInterval separating the timestamps (N>0).

The frequency of clock A can then be adjusted by this factor, where <correctedMasterEventTime0stamp> is calculated as follows:

If the type of clock is not a two step clock,

<correctedMasterEventTimestamp> = <originTimestamp> + <meanPathDelay> + correctionField of Sync message

If the type of clock is a two step clock,

<correctedMasterEventTimestamp> = <preciseOriginTimestamp> + <meanPathDelay> + correctionField of Sync message + correctionField of Follow_Up message