app_23_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

app23

NTP (Network Time Protocol)

and

PTP (Precision Time Protocol)

PART 2 ‐ PTP



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 133‐170 For use by alternate PTP profiles 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 216‐232 For use by alternate PTP profiles

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 0x20 Accurate to within 25 ns 0x21 Accurate to within 100 ns 0x22 Accurate to within 250 ns 0x23 Accurate to within 1 us 0x24 Accurate to within 2.5 us 0x25 Accurate to within 10 us 0x26 Accurate to within 25 us 0x27 Accurate to within 100 us 0x28 Accurate within 250 us 0x29 Accurate to within 1 ms 0x2A Accurate to within 2.5 ms

0x2B Accurate to within 10 ms 0x2C Accurate to within 25 ms 0x2D Accurate to within 100 ms 0x2E Accurate to within 250 ms 0x2F Accurate to within 1 s 0x30 Accurate to within 10 s 0x31 Accurate to >10 s 0x32‐0x7F reserved 0x80‐0xFD For use by alternate PTP profiles 0xFE Unknown 0xFF reserved

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);

1.00E‐13

1.00E‐12

1.00E‐11

1.00E‐10

0.001 0.010 0.100 1.000 10.000 100.000 1000.000 10000.000 100000.000

Averaging Time, Seconds

ptf 3203A Frequency Stability



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 .

PTPDEV = 3.582 x 10‐13 = 0.3582 pico seconds

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

PTP VAR = (σy2PTP) = ( 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 ;

log2 (σy2PTP) = log10 (σy

2PTP)/ log10 2

= ‐24.8917/0.301 = ‐82.6886

28 x log2 (σy2PTP) = ‐21168.282

which is then truncated to give

28 x log2 (σy2PTP) = ‐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 Accuracy (df/F)

Phase Accuracy(seconds)

Time 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.

app_23_part 2_ptp

Documents