Clock Class PDF

app23

NTP (Network Time Protocol)
and
PTP (Precision Time Protocol)

PART 2 ‐ PTP

Precise Time and Frequency, Inc.
50L Audubon Road, Wakefield, MA 01880, USA
Tel: +1 781 245 9090 Fax: +1 781 245 9099 www.ptfinc.com

Introduction
This paper addresses two protocols available for time transfer over Ethernet, NTP (Network Time Protocol) and PTP
(Precision Time Protocol). The paper is in two parts, Part 1 for NTP, and Part 2 for PTP. Both protocols rely upon the
exchange of information packets over a network. The packets contain time stamps defining when a packet was
transmitted and when it was received, and by analyzing these timestamps it is possible to determine the relative time
between the exchanging elements. Both protocols also contain mechanisms for the host to act as either a provider
(server) of time or a recipient (client) receiving time. This paper is written more from the perspective of a time provider
and does not cover in as much detail the receiving end of the transfer.
NTP has been around for many years (since the early 1980's) and is widely used in many time and frequency applications
today either just for a coarse time measure, supplemented by some other precision timing mechanism (e.g. 1PPS), or
can be used directly for time stamping events in applications where precision of a few milliseconds is sufficient . There
are many NTP "clients" freely available for download on the internet which makes this a popular choice for many
applications.
The newer PTP (often referred to by the name of the standard that defines it, IEEE 1588) was first introduced in the early
2000's and adds additional capability allowing much higher precision of time transfer (sub microseconds) albeit at
greater complexity. PTP is now in its second iteration (IEEE 1588 ‐ 2008, or PTP v2). This second iteration includes
additional features to achieve higher accuracies, e.g. inclusion of a capability that allows application specific "profiles"
that provide better estimation of timing delays etc. to be expected in particular application situations.
Both protocols also provide different "modes" of operation whereby a provider (server) may interact directly with a
request from a receiver (client) in "Unicast" mode, or when operating in "Multicast" mode, may send the time message
at regular intervals to a pre‐defined IP address, from which multiple clients receive the data.


PART 2 ‐ Precision Time Protocol (PTP)
In many ways, PTP (Precision Time Protocol) has been built upon the success of NTP but with some important
differences, and additional complexity needed to provide the enhanced accuracy. The initial IEEE standard (IEEE 1588)
for PTP was published in 2002. Several years later the Standard was revised and improved, and a new version, IEEE 1588
‐ 2008, was released , often referred to as PTP v2. PTP v2 is not compatible with PTP v1. This discussion primarily relates
to PTP v2.
In concept PTP is similar to NTP, with message packets containing timestamps being passed between "Master Clocks"
(equivalent to NTP servers) and "Slave Clocks" (similar to NTP clients). These Master and Slave clocks are referred to
collectively as "Ordinary Clocks" in the PTP nomenclature. Also whereas NTP typically utilizes one basic message, PTP has
a number of different messages (actually a total of 10 types in PTP v2), with considerably more information being passed
to and fro.
From here on out however NTP and PTP diverge rapidly.
First, the PTP second is not based upon UTC but upon another international time scale called TAI (from the French
"Temps Atomique International", or International atomic time). TAI does not have "leap" seconds like UTC. When UTC
was introduced (January 1, 1972) it was determined there should be a difference of 10 seconds between the two time
scales. Since then an additional 25 leap seconds (including one in June 2012) have been added to UTC to put the current
difference between the two timescales at 35 seconds.
By default PTP uses the same "epoch" (i.e. origination or reference start time and date of the timescale) as UNIX time, of
00:00, January 1, 1970. In PTP v2 however the option was introduced within the "profile" capability to choose a different
epoch if more appropriate for a specific application. The UTC offset is transmitted as part of the "announce" message by
the "Grand Master" clock (see below). The GPS time epoch is 00:00 on January 6, 1980
PTP seconds = NTP seconds ‐ 2,208,988,800 + leap seconds and PTP seconds = GPS seconds ‐ 315,964,819

Second, in a multi clock, multi network PTP system, one of the "ordinary" clocks in each network is designated as a
master (time server) and in the complete time distribution system there is also one time source designated as the
"Grandmaster" that is the reference for all the other clocks. In addition to the "ordinary" clocks there are two more
clock types, the "boundary" clock, and a newly introduced clock type (in PTPv2) the "transparent" clock. A boundary
clock connects to multiple networks, transferring the time stamped PTP messages between them. The new
"transparent" clock also connects between networks, but modifies the PTP messages by adding a correction
(correctionField in PTP header ‐ see below) for the timestamps to account for the time spent traversing the networks i.e.
making the time spent traversing networks "transparent".

Third, the obtainable time transfer accuracy is ultimately dependent upon the precision of the message time stamping,
and to this end there is an optional "hardware assisted" enhancement to PTP that brings this time stamping mechanism
as close to the actual receive/transmit ports as possible (eliminating the delays/jitter caused by relying on software
interrupts). Special integrated circuits are available to help with the implementation of this hardware time stamping
(e.g. National Semiconductor DP83640).

Message Interchange Overview.
Before examining each of the individual PTP messages, it is useful to review the message exchanges that take place
within a PTP domain. There are two phases to establishing (or joining) a PTP domain.
Phase 1.
In Phase 1 a hierarchy of clocks is established to determine which clock should be designated as "master" ( the
controlling source of time for this domain) and which clocks will be members. Each port of each of the clocks (ordinary
clocks and boundary clocks) establishes its own role based upon information received in "Announce" messages from
ports of the other clocks that are in the "master" state. The received data is compared to its own "local" clock data and
determines whether it should be "master" or just a "member" of the domain.
Phase 2
Once hierarchy has been established as described in Phase 1, the clocks in the domain are synchronized by exchanging
the following synchronization messages;
Master to Member sync message time stamped when sent by Master and time stamped when received by Member
Member to Master delay_request message time stamped when sent by Member and time stamped when received
by Master
Master to Member delay_response message (includes Master delay_request time stamp)
Member uses the time stamp data to synchronize to Master
In all there are ten different messages used within the PTP protocol, each message having its own specific function
within the overall protocol design. Descriptions of the structure and function of these messages is provided on the
following pages.
There are also "one step" and "two step" systems. A two step system uses "follow up" messages to supply the critical
time stamp information. The reason for the two step system is that it is less demanding (therefore less expensive) to
precisely record the time stamp and then insert it into a follow up message than trying to insert the data into a message
in real time.


PTP v2 Messages.

There are a total of ten different types of PTP messages, split into two groups (Event and General) as follows;

Message Length (bits) Function
Event Messages
Sync 352 Clock synchronization

Delay_Req 352 Clock synchronization

Pdelay_Req 432 Point to point delay characterization

Pdelay_Resp 432 Point to point delay characterization
General Messages
Announce 512 Establishment and maintenance of clock
hierarchy/Best master clock algorithm(BMC)

Follow_Up 352 Clock synchronization (two step system)

Delay_Resp 432 Clock synchronization

Pdelay_Resp_Follow_Up 432 Point to point delay characterization

Management 384+m(octets) Query/update PTP data sets, system
where m is customization, event generation, system
determined initialization, fault generation/reporting
by the data to
be sent

Signaling 48 + n(octets) Used to pass Type/Length/Value variables
where n is between system elements.
determined
by the data to
be sent

The event messages are time critical and the accuracy of their time stamping has a direct impact on the distributed time
accuracy. The Pdelay_XXX messages are used for determining point‐to‐point link propagation time between clocks, and
are not forwarded by boundary clocks or transparent clocks.
Although the data within the general messages is important to the functioning of PTP, the transmit and receipt
timestamps do not impact system accuracy.


The PTP Message Header
All of the above messages start with a 272 bit header. This header provides the following information fields;

Field Length Description

transportSpecific 4 bits Currently two valid values: default = 0, 802.1AS = 1

messageType 4 bits Identifies the message type (Sync, Delay_Req etc.) by number
SYNC=0x0, DELAY_REQ=0x1, PDELAY_REQ=0x2,PDELAY_RESP=0x3,
FOLLOW_UP=0x8, DELAY_RESP=0x9, PDELAY_RESP_FOLLOW_UP=0xA,
ANNOUNCE=0xB, SIGNALING=0xC, MANAGEMENT=0xD

reserved 4 bits

version PTP 4 bits Currently could be 1 or 2 (IEE 1588 ‐ 2002 or IEEE 1588 ‐ 2008 respectively)

messageLength 16 bits Full length of message including header, body and any suffix (but not padding)

domainNumber 8 bits Value can be 0 to 128 and identifies the (clock) domain # to which this clock belongs.

Reserved 8 bits

Flags 16 bits Alternate Master, two step, Unicast, Profile Specific 1, Profile Specific 2, Security,
Leap Indicator 61, Leap Indicator 59, UTC Reasonable, Timescale, Time Traceable,
Frequency Traceable
correctionField 64 bits clock corrections, 48 bits nano seconds, 16 bits sub nano seconds for residence time in

transparent clock, also path delay for peer‐to‐peer transparent clocks.

Reserved 32 bits

sourcePortIdentity 80 bits identifies the originating port for this message

sequenceID 16 bits sequence number for message type

controlField 8 bits value depends upon message type (from PTP v1)

logMessageInterval 8 bits stored as 2n e.g. for interval of 0.125 seconds Message Interval = ‐3 (i.e. 2‐3)
Value is determined by the type of message (Sync maybe -3, Announce maybe 3)


Message formats are as follows:
Message Content Length Description

Sync Header 272 bits PTP message header ‐ see above
originTimestamp 80 bits 48 bits for seconds, 32 bits for nano seconds

Delay_Req Header 272 bits PTP message header ‐ see above
originTimestamp 80 bits Epoch(16 bits), Seconds(32 bits),nano seconds
32 bits. (Epoch contains seconds overflows)

Pdelay_Req Header 272 bits PTP message header ‐ see above
originTimestamp 80 bits Epoch, Seconds, nano seconds(16,32,32)
reserved 10 bits

Pdelay_Resp Header 272 bits PTP message header ‐ see above
receiveReceiptTimestamp 80 bits Epoch, Seconds, nano seconds(16,32,32)
requestingPort Ientity 10 bits The sourcePortIdentity from the header of the
associated PDelay_Req message of the delay
requester peer‐to‐peer clock that requested
this message

PDelay_Resp_Follow_Up Header 272 bits PTP message header ‐ see above
responseOriginTimestamp 80 bits Epoch, Seconds, nano seconds(16,32,32)
requestingPort Ientity 10 bits The sourcePortIdentity from the header of the
associated PDelay_Req message of the delay
requester peer‐to‐peer clock that requested
this Pdelay_Resp message

Announce Header 272 bits PTP message header ‐ see above
originTimestamp 80 bits Epoch, Seconds, nano seconds(16,32,32)
currentUtcOffset 16 bits UTC offset
reserved 8 bits
grandmasterPriority 1 8 bits Designated priority 1
grandmasterClockQuality 32 bits Quality of clock
grandmasterPriority2 8 bits Designated priority 2
grandmasterIdentity 64 bits Identity of Grand Master
stepsRemoved 16 bits # of steps away from Primary Clock Source
timeSource 8 bits Master time source

Follow_Up Header 272 bits PTP message header ‐ see above
preciseOriginTimestamp 80 bits Epoch, Seconds, nano seconds(16,32,32)

Delay_Resp Header 272 bits PTP message header ‐ see above
receiveTimestamp 80 bits Epoch, Seconds, nano seconds(16,32,32)
requestingPort Identity 80 bits


Signaling Header 272 bits PTP message header ‐ see above
targetPort Identity 80 bits Identity of target
one or more TLV's N bits Target, Length Value identifiers (N is dependent
upon specific TLV)

Management Header 272 bits PTP message header ‐ see above
targetPort Identity 80 bits Identity of target
startingBoundaryHops 8 bits number of boundary clocks that this message is
allowed to be retransmitted by
boundaryHops 8 bits the number of remaining boundary clock
retransmissions left for this particular
message, request or reply. Identical value to
startingBoundaryHops field for initial
transmission from issuing clock/node.
reserved/Action field(4bits) 8 bits Type of action for this message. (Get, Set,
Response, Command, Acknowledge)
reserved 8 bits
managementTLV M bits Target, Length, Value. M=48+N (see below)

format of the managementTLV fields is:
tlvType 16 bits should be set to "Management" (0x01)
lengthField 16 bits length of the TLV.
managementID 16 bits Identifies the type of management message this
is e.g. Initialize, Enable_Port, Disable_Port
dataField N octets dependent upon managementID


All PTP messages are Multicast, with an option in PTP v2 for a Unicast mode. Separate ports are used for Event and
General type messages. Event messages are sent to port 319, and General messages use port 320.

The multicast address for most of the messages in PTP v2 is:
IPv4 224.0.1.129 IPv6 FF0x::181

Peer delay messages (Pdelay_Req, Pdelay_Resp and Pdelay_Resp_Follow_Up) however use a different multicast
address:
IPv4 224.0.0.107 IPv6 FF02::6B

The peer to peer delay messages are not intended to be transmitted between different clock domains (or networks) and
therefore time to live should be set to 1 (hops to 0 in IPv6)

If operating in Unicast mode, message are sent back to the originating Unicast address.

Best Master Clock Algorithm (BMC)

One of the key aspects of PTP is the BMC. The algorithm selects the best clock in a clock domain according to the
following properties that are contained within the Announce message fields:

grandmasterIdentity ‐ this 64 bit field contains up to 8, 8 bit clock identities, usually based on MAC address
grandmasterClockQuality ‐ this 32 bit field contains a structure consisting of three sets of data:
clockClass unsigned 8 bit integer (default class is 248, 13 is when synchronized to an application
specific source and also indicates should not be slaved to another clock) See note 1.
clockAccuracy 8 bit enum (0x20= 25ns...0x31+>10ns, 0xFE=Unkown ). See note 2.
offsetScaledLogVariance 16 bit unsigned integer indicating the clock stability. See note 3.
grandmasterPriority 1 ‐ | Two 8 bit fields used to indicate the clock precedence. If set to mid point (128)
grandmasterPriority 2 ‐ | allows easy control of BMC algorithm

The BMC algorithm evaluates and selects based on the above properties in the following order;
grandmasterPriority 1
grandmasterClockQuality
grandmasterPriority 2
grandmasterIdentity


Note 1. Clock Classes)

0 Reserved to enable compatibility with future versions.
1‐5 Reserved
6 Designates a clock that is synchronized to a primary reference time source. The timescale distributed is
PTP. A clock Class 6 clock shall not be a slave to another clock in the domain.
7 Designates a clock that has previously been designated as clock Class 6 but that has lost the ability to
synchronize to a primary reference time source and is in holdover mode and within holdover specifications. The
timescale distributed is be PTP. A clock Class 7 clock shall not be a slave to another clock in the domain.
8 Reserved
9‐10 Reserved to enable compatibility with future versions.
11‐12 Reserved
13 Designates a clock that is synchronized to an application specific source of time. The timescale distributed
is ARB*1. A clock Class 13 clock shall not be a slave to another clock in the domain.
14 Designates a clock that has previously been designated as clock Class 13 but that has lost the ability to
synchronize to an application specific source of time and is in holdover mode and within holdover specifications.
The timescale distributed shall be ARB *1. A clock Class 14 clock shall not be a slave to another clock in the
domain.
15‐51 Reserved
52 Degradation alternative A for a clock of clock Class 7 that is not within holdover specification. A clock of
clock Class 52 shall not be a slave to another clock in the domain.
53‐57 Reserved
58 Degradation alternative A for a clock of clock Class 14 that is not within holdover specification. A clock of
clock Class 58 shall not be a slave to another clock in the domain.
59‐67 Reserved
68‐122 For use by alternate PTP profiles
123‐127 Reserved
128‐132 Reserved
171‐186 Reserved
187 Degradation alternative B for a clock of clock Class 7 that is not within holdover specification. A clock of
clock Class 187 may be a slave to another clock in the domain.
188‐192 Reserved
193 Degradation alternative B for a clock of clock Class 14 that is not within holdover specification. A clock of
clock Class 193 may be a slave to another clock in the domain.
194‐215 reserved
233‐247 Reserved
248 Default. This clock Class is used if none of the other clock Class definitions apply.
249‐250 Reserved
251 Reserved for PTP version 1 compatibility
252‐254 Reserved
255 Shall be the clock Class of a slave‐only clock
*1. ARB is ARBitrary time scale, running at the rate of the SI second but with its epoch set arbitrarily.

Note 2. Clock Accuracy
0x00‐0x1F reserved 0x2B Accurate to within 10 ms

0x20 Accurate to within 25 ns 0x2C Accurate to within 25 ms
0x21 Accurate to within 100 ns 0x2D Accurate to within 100 ms
0x22 Accurate to within 250 ns 0x2E Accurate to within 250 ms
0x23 Accurate to within 1 us 0x2F Accurate to within 1 s
0x24 Accurate to within 2.5 us 0x30 Accurate to within 10 s
0x25 Accurate to within 10 us 0x31 Accurate to >10 s
0x26 Accurate to within 25 us 0x32‐0x7F reserved
0x27 Accurate to within 100 us 0x80‐0xFD For use by alternate PTP profiles
0x28 Accurate within 250 us 0xFE Unknown
0x29 Accurate to within 1 ms 0xFF reserved
0x2A Accurate to within 2.5 ms

Note 3. Calculation of offsetScaledLogVariance

As detailed in standard 802.1AS‐2011, the value of the offsetScaledLogVariance is calculated according to the value of
PTPDEV at an observation interval equal to the default Sync message transmission interval (0.125 seconds).

The default value provided in the 802.1AS‐2011 standard is based on measurement data for an inexpensive oscillator
and yields an offsetScaledLogVariance value of 17258 (or in Hexadecimal 0X436A) ‐ this is a corrected value based on
recalculating from the revised 802.1AS TDEV mask (the original value was 16640 (0X4100).

The value of offsetScaledLogVariance for a precision GPS based local clock with a high performance OCXO is calculated
as follows;
start with the Allan Deviation of the OCXO at the sync message time interval of 0.125 seconds (see chart below);

ptf 3203A Frequency Stability
1.00E‐10
1.00E‐11
1.00E‐12
1.00E‐13
0.001 0.010 0.100 1.000 10.000 100.000 1000.000 10000.000 100000.000
Averaging Time, Seconds


Allan Deviation(0.125 seconds) = σy(0.125) = 4.964 x 10‐12 (from chart above)

next calculate PTPDEV = Allan Deviation x τ /(3)

PTPDEV .

.
4.964 10

‐13
PTPDEV = 3.582 x 10 = 0.3582 pico seconds

next, the PTP variance ( PTPDEV2 i.e. σ2) is calculated

2
PTP VAR = (σy PTP) = ( 3.582 x 10‐13 )2 = 1.2831 x 10‐25

to calculate the offsetScaledLogVariance the log base 2 of PTP VAR is taken, and then multiplied by 28 to produce a
scaled value ;

2 2
log2 (σy PTP) = log10 (σy PTP)/ log10 2
= ‐24.8917/0.301
= ‐82.6886

2
28 x log2 (σy PTP) = ‐21168.282

which is then truncated to give

2
28 x log2 (σy PTP) = ‐21168

Represented in hexadecimal this gives 0xAD50

now the two's complement is taken and 0x8000 is added to the result :

(0xFFFF ‐ 0xAD50) + 0x8000 = 0x52AF + 0x8000
yielding an offsetScaledLogVariance of = 0xD2AF
= 53935 in decimal notation

Therefore for an instrument such as the ptf 3203A fitted with a high performance OCXO the offsetScaledLogVariance
value would be 53935


Clock Synchronization

Once the clock hierarchy has been established (i.e. a master has been selected) through interchange of "announce"
messages and use of the BMC (Best Master Clock) algorithm the process of synchronizing the member clocks to the
master can begin.

In the example below, we show the passage of the event messages through End to End (E2E) transparent clocks (TC).
The E2E TCs add a correction into the correction field of the message header, for the time taken for a message to
traverse the TC, thus making the TC "transparent".


From the above diagram;

Clock Offset = ( T2 ‐ T1) ‐ ( mpd ) where mpd = mean path delay
mpd = ((T2‐T1) + (T4‐T3))/2 mean path delays are assumed to be symmetrical

Therefore;
Clock offset = (T2 - T1) - (T2-T1)/2 - (T4-T3)/2

= (2*T2 - 2*T1 - T2 +T1 )/2 - (T4-T3)/2
= (T2 -T1)/2 - (T4-T3)/2
or re-written;
Clock offset = [ (T2-T1) +(T3 - T4) ] / 2 which of course is exactly the same equation we had for NTP

Summary

Precision Time Protocol comprises two message types namely, system management and synchronization. In PTP v2,
synchronization message lengths have been reduced for higher efficiency, and are now either 352 bits long (Sync etc.)
or 432 bits long (Delay_Resp) and are sent at a default interval of 0.125 seconds each. System management messages
are typically greater in length, but are sent at much reduced intervals (e.g. 2 seconds).

The attainable accuracy of PTP comes from the precision of time stamping (can be enhanced with special hardware time
stamping) and additional fields provided within the protocol for other network delay correction factors.

PTP is more suited to operating within Local Area Networks than on Wide Area Networks, as cascading a large number
of system elements can result in a significant increase in time errors.

Used within closed networks, PTP provides an economically attractive solution to time synchronization requirements
down to microsecond levels (1 to 10 microseconds). With hardware assisted time stamping and a carefully controlled
network it is possible to achieve synchronization down to sub microsecond levels.

It should also be noted that typically manufacturers of PTP clocks quote the time stamping accuracy on specifications,
not the synchronization accuracy across a network. This is understandable as there are many factors and variables
within a network that will ultimately have an impact on the actual synchronization accuracy that is attainable using PTP.

The telecommunications industry is becoming a driving force in the PTP market. GSM, WCDMA, and CDMA2000 telecom
standards all require frequency accuracies of around 5x10‐8 at the air interface. The CDMA2000 and WCDMA standards
also require timing synchronization accuracies of <10 microseconds and <1.25 microseconds respectively, making them
an ideal target for a PTP solution.

A table showing some typical application frequency and timing requirements for which PTP could be considered a good
solution is shown below.

Application Frequency Phase Time
Accuracy (df/F) Accuracy(seconds) Accuracy(seconds)
Telecommunications
CDMA2000 5E‐8 10E‐6
WCDMA(TDD) 5E‐8 2.5 E‐6
GSM 5E‐8
TD‐SCDMA 5E‐8 3E‐6
LTE(eMBMS with SFN) 5E‐8 1E‐6
WiFi
Mobile WiMax 5E‐8 1E‐6
Smart Grid(Power Utilities)
Fault Detection/Recording 1E‐3 1E‐3
Bus Synchronization 1E‐6 1E‐6
Data Acquisition 1E‐6 1E‐6


Part 1 and Part 2 Conclusions

NTP and PTP both have a place within the time synchronization world, and both have significant benefits to offer in the
right applications. PTP utilizing standard network cabling is well positioned to economically fill a void between NTP and
direct 1PPS (One Pulse Per Second) timing synchronization that requires dedicated local hardware.

NTP has been established for over twenty years, and there are many hardware and software solutions available for
implementation, whereas due to its relatively recent introduction, the number of hardware and software solutions
available for implementing PTP is still very limited. As PTP becomes more popular, especially in high volume consumer
driven applications such as telecommunications, additional hardware and software solutions will inevitably become
available, providing end users with a broader choice of system implementations.

As PTP is ultimately derived from some form of local clock, most typically a GPS receiver, it will never be able to provide
a better accuracy than the clock upon which it relies. For ultimate synchronization accuracy, down to a few tens of nano
seconds, a 1PPS timing pulse remains the preferred solution as it is capable of delivering the clock accuracy directly to
the synchronization port. This can be supplemented with NTP (or PTP) to obtain "absolute" time referenced to UTC.


Clock Class PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Clock Class PDF

Uploaded by

Copyright:

Available Formats

correctionField 64 bits clock corrections, 48 bits nano seconds, 16 bits sub nano seconds for residence time in

Message Content Length Description

0x00‐0x1F reserved 0x2B Accurate to within 10 ms

Clock offset = (T2 - T1) - (T2-T1)/2 - (T4-T3)/2

You might also like