0% found this document useful (0 votes)
10 views5 pages

NET-2021-05-1_04

Current Developments of IEEE 1588 (Precision Time Protocol)

Uploaded by

jaguarondi_
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
10 views5 pages

NET-2021-05-1_04

Current Developments of IEEE 1588 (Precision Time Protocol)

Uploaded by

jaguarondi_
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

Current Developments of IEEE 1588 (Precision Time Protocol)

Kilian Rösel, Max Helm∗ , Johannes Zirngibl∗ , Henning Stubbe∗


∗ Chair
of Network Architectures and Services, Department of Informatics
Technical University of Munich, Germany
Email: [email protected], [email protected], [email protected], [email protected]

Abstract—Precise synchronization of clocks is essential for An Ordinary Clock (OC) is a terminal device which
multiple scientific and industrial applications. Synchroniza- has only one PTP port and maintains the timescale with
tion in networks can be achieved with the IEEE 1588 its local clock. It can either be the Grandmaster Clock,
Precision Time Protocol. This paper gives an overview of such that it acts as the source of time or a slave receiving
this protocol and explores recent developments of this stan- time. When it is in the master state, it often uses global
dard. It examines new features for accuracy and security navigation satellite systems (GNSS) or terrestrial radio
introduced by the 2020 released IEEE 1588-2019 (PTPv2.1) links as time reference.
edition of this protocol. Sub-nanosecond accuracy gets sup- Boundary Clocks (BC) are network devices with mul-
ported by the High Accuracy Profile based on the White tiple PTP ports. One of them is in the SLAVE state, so
Rabbit Extension, utilizing Layer 1 signals and a system they can synchronize their own local clock to the time
wide calibration procedure. Several approaches to make source. The ports in the MASTER state provide time to
the synchronization mechanism more secure are presented. other PTP Instances.
Finally the paper outlines the expected impact of PTPv2.1 End-to-end (E2E) and peer-to-peer (P2P) Transparent
functionality on industrial use cases.
Clocks (TC) are network devices as well, but do not
synchronize their own internal clock. Instead they measure
Index Terms—IEEE 1588, precision time protocol, high ac- the residence time of PTP messages and propagate them
curacy after adjusting a correction field.
Management Nodes are devices used for configuring
1. Introduction and monitoring clocks in a PTP network.
Non-PTP devices such as switches and routers, can
Precise synchronization of clocks in distributed sys- cause inaccuracies because they introduce asymmetry in
tems is a major requirement in several areas such as the network through queueing effects. For achieving high
telecommunication, finance and power grid. However, accuracy it is therefore essential to only use BCs and/or
many solutions lack in synchronization accuracy, robust- TCs as network devices.
ness and security to be properly deployed in real industrial The logical unit in which the PTP devices synchronize
scenarios [1]. to one timescale is called a domain. Originally multiple
On 16 June 2020 the IEEE 1588-2019 [2] version domains could exist in the same network, but were strictly
of the Precision Time Protocol (PTP) superseded the separated. The new edition introduces the possibility of
previous IEEE 1588-2008 (PTPv2) [3] version. This new inter-domain interactions between PTP devices. This fea-
revision includes the High Accuracy Profile (HA), which ture can get used to enhance security, presented in Sec-
allows to achieve sub-nanosecond accuracy as well as tion 4.
several mechanisms to make PTP systems more secure
and robust. 2.1. Master-Slave Hierarchy
This paper gives an overview over the PTP protocol in
Section 2. The different PTP devices with their topology The PTP domain has to be organized in a treelike
and the synchronization mechanism will be discussed. master-slave hierarchy, with the best suited clock as grand-
The new High Accuracy Profile allows to achieve sub- master at the root. To select the grandmaster and to
nanosecond accuracy. It relies on two key mechanisms: negotiate this topology the Best Master Clock Algorithm
Firstly, calibration and measurement of asymmetries and (BMCA) may be used. First OCs and BCs exchange the
secondly achieving higher precision in timestamping, following performance properties via Announce messages:
presented in Section 3. Furthermore, new features and 1) priority1: Can be set by administrators to apprise
guidelines for security are presented in Section 4. This their preferred master clock.
paper finally discusses new possibilities and challenges 2) clockClass: Describes the traceability, synchro-
of PTPv2.1 in PTP implementations based on different nization state and expected performance.
industries in Section 5. 3) clockAccuracy: Describes the accuracy of the
Local PTP Clock.
2. Background 4) offsetScaledLogVariance: Describes the stability
of the Local PTP Clock.
A PTP network consists of multiple PTP devices and 5) priority2: Can be set by administrators to arrange
non-PTP devices, such as switches and routers. equivalent PTP Instances.

Seminar IITM WS 20/21, 13 doi: 10.2313/NET-2021-05-1_04


Network Architectures and Services, May 2021
6) clockIdentity: Unique identifier for PTP Instances message, rendering the Follow_Up message obsolete. In
to break ties. order to calculate the network delay according to the E2E
mechansim the Slave clock then sends a Delay_Req mes-
Secondly, each PTP Instance computes the states of
sage, and notes the departure time t3 . The master creates
its ports according to those properties.
timestamp t4 at arrival of this message and communicates
The BMCA also prunes mesh topologies to avoid
this timestamp via a Delay_Resp to the slave. Figure 4
cyclic network connections. It does so by setting ports on
illustrates this message exchange. When the slave clock
PASSIVE state such that there is no time synchronization
possesses all four timestamps, it can compute the mean
on this connection. This way endless circulation of rogue
path delay d and its offset to the master o:
Announce messages can be avoided. Figure 1 shows an
exemplary PTP network with pruned mesh topolgy [2].
(t2 − t1 ) + (t4 − t3 )
d=
reference timesource 2
o = (t2 − t1 ) − d
GM M TC S BC
Port States:
M
M: MASTER Knowing the slave-master offset the slave clock can
S: SLAVE adjust its own clock and is then synchronized to the
S S
P: PASSIVE
master.
OC S M BC M P BC
Calculation of the network delay can also be done with
the P2P mechansim. This mechanism does not calculate
Figure 1: Example PTP network with pruned mesh topol- the network delay between a master and slave port, but
ogy [2]. between directly neighbouring nodes. The P2P network
delay then gets added up along the whole path. Figure 3
The BMCA is running continuously, even when the illustrates the difference between P2P and E2E.
desired topology is already established. This way the
network can reconfigure itself automatically, if for ex-
ample physical connections get lost or the performance OC M E2E TC E2E TC S OC

properties of a Grandmaster Clock degrade [2]. Delay-Request


The new edition of the standard also includes mecha- Delay-Response

nisms for manual configuration of PTP port states. How-


ever, setting port states manually may result in "timing OC M P2P TC P2P TC S OC

islands" where time does not get distributed, illustrated in


Figure 2. Additionally it disables automatic reconfigura-
tion [4]. Figure 3: PTP Delay Mechanism [5]

This model assumes the master-slave (tms ) and slave-


OC M S BC M M BC M S BC master (tsm ) propagation delay to be symmetric, i.e. mes-
GM in timing
island 1
GM in timing
island 2
sages need the same time to travel in either direction.
However, to achieve high accuracy in real scenarios one
Figure 2: Adjacent ports in master state result in timing must take steps to account for asymmetries in the network.
islands [4]. The HA therefore defines a system wide calibration pro-
cedure, shown in Section 3.1.

2.2. Synchronizing Mechanisms Master Slave


Clock Clock
Time Time
The time synchronization mechanism takes place be- t1 Timestamps
tween two linked Ordinary and/or Boundary Clocks. One Sync known by slave
tms
of them is in the master state, the other one in the slave PTP instance

state. They are exchanging a series of event and general t2 t2


Follow_Up
messages to calculate the offset of the Slave Clock with t1, t2
respect to the master clock. Event messages are messages t3 t1, t2, t3
that get timestamped when they egress or ingress a port. tsm
General messages are not required to be timestamped. Delay_Req
Details on timestamp generation are shown in Section 2.3. t4

Eventually, all PTP Instances are synchronized to the


grandmaster as time gets distributed through the hierarchy.
To distribute time, the master clock first sends a Sync Delay_Resp
t1, t2, t3, t4
message to the Slave and timestamps the departure time
t1 . The slave timestamps the arrival of this message t2 .
In a two-step setup the master then sends a Follow_Up Figure 4: Basic end-to-end PTP Timing Message Ex-
message containing t1 . In a one-step setup the master clock change [2]
would already have included timestamp t1 in the first Sync

Seminar IITM WS 20/21, 14 doi: 10.2313/NET-2021-05-1_04


Network Architectures and Services, May 2021
2.3. Timestamp Generation sources of asymmetry: timestamp generation latencies and
medium asymmetry. Knowing the values allows to com-
Precise timestamp generation is crucial for the accu- pensate for their effects when calculating the offset from
racy of round trip time measurement. A timestamp is the master.
defined as the instance the message timestamp point of Timestamp generation latencies get introduced on
an event message crosses the reference plane between egress and ingress of messages, e.g. because timestamps
medium and PTP port. Though in implementations times- are captured at a point removed from the reference plane,
tamping might take place in the Application Layer (C), in see Section 2.3. Medium asymmetries originate from the
the kernel interrupt service routines (B) or in the physical physical communication medium. They can for example
layer (A), illustrated in Figure 5. Traveling through the be caused by the use of different wavelengths of light in
protocol stack can introduce latencies, thus it is preferable single-strand fibers. The standard defines several proce-
to choose a point near to the physical layer. In this dures, how to calibrate these latencies and asymmetries.
case, specialized hardware assists in the generation of the Because of different optical phenomena in long distance
timestamp. Nevertheless, any offset from the reference optical links, these procedures are only intended for Local
plane has to be compensated for by measurement and Area Networks [2]. However, deployment of long distance
calibration [2]. fiber links has already been investigated [9].

3.2. Precise Timestamping


IEEE 1588 Code
C
(application layer)
The accuracy of delay measurements relies on the
OS resolution and precision of timestamping. Timestamps are
created by the Local PTP Clock whenever the message
MAC B
timestamp point crosses the implemented point in the
protocol stack, see Section 2.3. However, usually the
Hardware Assist
receive and transmit signals on the Physical Layer (L1)
PHY A are different from the Local PTP Clock signal used for
timestamping. This may result in timestamping impreci-
reference plane sion. For example, a Local PTP Clock with a frequency
of 125 MHz is limited to a resolution of 8 ns [8].
Network To correct for this imprecision, knowledge about the
phase offset between the L1 transmit clock signal (clktxL1 ),
Preamble Header L1 receive clock signal (clkrxL1 ), and the Local PTP
Clock (clklocalPTP ) is required. The L1 tx/rx signals are
the physical signals used by the medium to transport
signals over the wire. The reception phase offset (xrx )
and transmission phase offset (xtx ) is the offset between
the Local PTP Clock signal to the L1 receive signal and
Message Timestamp point
L1 transmission signal respectively. This relationship gets
demonstrated in Figure 6. Note that the transmit signal
Figure 5: Protocol Stack and Message Timestamp of Clock A is the receive signal of Clock B. Knowing
Point [2] the value of xrx and xtx at the instance of the timestamp
allows then to compensate the offsets in the calculation
process.
3. High Accuracy
The High-Accuracy Profile is based on the White clktxL1_A Tx Rx clkrxL1_B

Rabbit Extension (WR) for PTPv2. WR was developed xtx_A xrx_B

to renovate the control and timing system at CERN [6]


and was later generalized and included in the standard by clklocalPTP_A clklocalPTP_B

the P1588 working group [7]. xrx_A xtx_B

It allows to achieve sub-nanosecond synchronization


accuracy by relying on two mechanisms and method-
clkrxL1_A Rx Tx clktxL1_B

ologies: (1) Various sources of asymmetry get recog-


nized, measured and calibrated to compensate for their Figure 6: Link Reference Model between two Clocks [8]
effects, described in Section 3.1. (2) Utilizing physical
transmission and receive signals to increase precision in Quantifying the phase offsets depends on the vari-
the hardware assisted timestamping process of PTP event ability of the offset. In the simplest case the offsets are
messages, described in Section 3.2 [8]. constant. That means the L1 tx/rx signals and the Local
PTP clock signal are coherent, i.e., they operate on the
3.1. Calibration same frequency. To achieve coherency, ports can base their
Local PTP Clock signal on the L1 rx signal recovered
Asymmetries between two PTP Instances introduce from the medium and generate their L1 tx signal from
inaccuracy in the synchronization process. There are two the Local PTP Clock. With this relationship in place, the

Seminar IITM WS 20/21, 15 doi: 10.2313/NET-2021-05-1_04


Network Architectures and Services, May 2021
constant offsets can be measured, for example by using Architecture Mechanisms. The standard presents various
Digital Dual Mixer Time Difference (DDMTD) phase guidelines to enhance security by architectural choices
detection [10]. based on redundancy: (1) Redundancy by complementary
Syntonization in networks can for example be timing systems means that end-users of time obtain a
achieved with Synchronous Ethernet (ITU-T Recommen- second reference through a non-PTP way, for example by
dations G.8261 [11] and G.8262 [12]). The PTP Clocks GPS. This way they can detect malicious behaviour. (2)
can then take advantage of the Layer 1 syntonization to Multiple domains with separate Grandmaster Clocks work
enhance their timestamping precision [8]. together through inter-domain interactions. End users then
can obtain time in a voting process from multiple domains
and are therefore able to exclude malfunctioning time
4. Security Mechanisms information. (3) Lastly redundant network paths between
nodes can ensure distribution of timing messages even
Security concerns have long been neglected in the when some connections get lost [2].
development of PTP. Especially in critical infrastructures
such as the power grid this might prove fatal. However, Monitoring and Management Mechanisms. Monitoring
PTPv2.1 describes several mechanisms to make PTP more and managing the performance of the PTP network can
secure [13]. reveal clues about potential security attacks, e.g. delay
attacks. These can be identified by detecting unexpected
PTP Integrated Security Mechanism. PTP messages offset jumps or large changes in measured path delays.
can be extended by a type, length, value (TLV) extension The new version has also introduced a standardized format
mechanism in order to transfer additional information. in which all PTP devices can share their performance data
There are several different types of TLVs defined. in an uniform way with Management Nodes [2].
The AUTHENTICATION TLV, providing a way to
authenticate PTP messages, was already introduced in
PTPv2. But test implementations of this feature have
5. Applications of PTPv2.1 Functionality
shown little additional security at the expense of over-
head [14]. PTPv2.1 revised the AUTHENTICATION TLV The White Rabbit Extension has already proven useful
feature. in multiple scientific applications, e.g. in particle accelera-
tors. But also other sectors have already made endeavours
The included integrity check value (ICV) verifies all
in adapting this technology [17]. Deutsche Börse, for
fields from the PTP Header up to the AUTHENTICATION
example, uses WR to synchronize their own timestamping
TLV without including the ICV itself. Also included in the
devices. Additionally they provide means for their trading
calculation is a secret key. This key has to be distributed
partners to synchronize their own clocks to theirs [18]. As
by a key management system. Depending on this system
the WR technology matures through the standardization as
two different verification schemes are possible: (1) Imme-
High Accuracy Profile, it will grow even more attractive
diate security processing enables verification of the mes-
for industrial use. So it is to be expected to see an adaption
sage immediately. To achieve this, the secret key has to be
in multiple areas. Especially the operation of power grids
known to the communication partners before processing.
can profit from increased timing accuracy. As the grid
This approach also allows mutable fields. For example a
evolves to being powered by sustainable but unpredictable
transparent clock can adjust the correction field and can
energy sources, precise monitoring is essential. For exam-
then recompute the ICV. (2) Delayed processing enables
ple, multiple synchrophasers can detect characteristic volt-
to share the secret key after message transmission. With
age spikes caused by malfunctioning equipment. When the
this approach the receiver has to store the message until
measurements are precisely synchronized conclusions on
he receives the key to verify it. Those two approaches can
the origin can be drawn [19].
also be combined. Figure 7 shows this case. Everything
Deployment in such critical infrastructure was previ-
after the first AUTHENTICATION TLV is immediately
ously hampered by security concerns. An implementation
verified. This method allows to add TLVs that can be
of the AUTHENTICATION TLV feature for Linux PTP
modified by intermediate devices [13].
has already proven to be feasible with a low computational
overhead [13]. This result and the other security guidelines
Transport PTP PTP Other PTP AUTHENTICATION TLV Other PTP
AUTHENTICATION
Transport
may encourage adopters in utilizing PTPv2.1 functionality
in their own implementations.
ICV TLV ICV
Header Header Payload TLVs delayed processing TLVs Trailer
immediate processing

Integrity protected by delayed processing

Integrity protected by immediate processing

6. Conclusion and Future Work


Figure 7: Authentication TLV [2]
The new version includes options for achieving high
The key management system is responsible for the accuracy and mitigating security risks. These two features
distribution of keys, however the standard does not yet are essential for PTP to be further adapted as time syn-
define such a system, but merely gives guidelines [15]. chronization technology. This paper has presented these
new features and has briefly outlined their impact on in-
PTP External Transport Security Mechanisms. The dustrial scenarios. However, PTPv2.1 includes even more
standard suggests using MACSec and IPSec as external innovations, not presented in this paper, such as profile
security mechanisms. Those protocols provide protection isolation, special PTP ports and mixed multicast/unicast
against several attacks, as shown by [16]. operation [20].

Seminar IITM WS 20/21, 16 doi: 10.2313/NET-2021-05-1_04


Network Architectures and Services, May 2021
References [11] “Timing and Synchronization Aspects in Packet Networks,” ITU-T
G.8261/Y.1361, pp. 1–120, 2019.
[1] F. Girela-López, J. López-Jiménez, M. Jiménez-López, R. Ro- [12] “Timing Characteristics of Synchronous Equipment Slave Clock,”
dríguez, E. Ros, and J. Díaz, “IEEE 1588 High Accuracy Default ITU-T G.8262/Y.1361, pp. 1–44, 2018.
Profile: Applications and Challenges,” IEEE Access, vol. 8, pp.
45 211–45 220, 2020. [13] E. Shereen, F. Bitard, G. Dán, T. Sel, and S. Fries, “Next Steps
in Security for Time Synchronization: Experiences from imple-
[2] “IEEE Standard for a Precision Clock Synchronization Protocol for menting IEEE 1588 v2.1,” 2019 IEEE International Symposium
Networked Measurement and Control Systems,” IEEE Std 1588- on Precision Clock Synchronization for Measurement, Control, and
2019 (Revision of IEEE Std 1588-2008), pp. 1–499, 2020. Communication (ISPCS), pp. 1–6, 2019.
[3] “IEEE Standard for a Precision Clock Synchronization Protocol for [14] C. Önal and H. Kirrmann, “Security Improvements for IEEE
Networked Measurement and Control Systems,” IEEE Std 1588- 1588 Annex K: Implementation and Comparison of Authentication
2008 (Revision of IEEE Std 1588-2002), pp. 1–300, 2008. Codes,” pp. 1–6, 2012.
[4] D. Arnold, “What’s in IEEE 1588-2019: DIY PTP [15] D. Arnold, “The PTP AUTHENTICATION TLV,” https://blog.
Port States,” https://blog.meinbergglobal.com/2020/07/24/ meinbergglobal.com/2020/06/04/the-ptp-authentication-tlv/, 2020,
whats-in-ieee-1588-2019-diy-ptp-port-states/, 2020, [Online; [Online; accessed 29-September-2020].
accessed 24-September-2020].
[16] T. Mizrahi, “Time Synchronization Security Using IPsec and MAC-
[5] Z. Idrees, J. Granados, Y. Sun, S. Latif, L. Gong, Z. Zou, and sec,” 2011 IEEE International Symposium on Precision Clock
L. Zheng, “IEEE 1588 for Clock Synchronization in Industrial IoT Synchronization for Measurement, Control and Communication,
and Related Applications: A Review on Contributing Technologies, pp. 38–43, 2011.
Protocols and Enhancement Methodologies,” IEEE Access, vol. 8,
pp. 155 660–155 678, 2020. [17] M. Lipiński, E. van der Bij, J. Serrano, T. Włostowski, G. Daniluk,
A. Wujek, M. Rizzi, and D. Lampridis, “White rabbit applica-
[6] “The White Rabbit Project,” https://white-rabbit.web.cern.ch/ tions and enhancements,” 2018 IEEE International Symposium on
Default.htm, 2020, [Online; accessed 26-September-2020]. Precision Clock Synchronization for Measurement, Control, and
[7] “IEEE P1588 Working Group,” https://sagroups.ieee.org/1588/, Communication (ISPCS), pp. 1–7, 2018.
2020, [Online; accessed 26-September-2020].
[18] “High Precision Time (White Rabbit) Pilot,” https:
[8] O. Ronen and M. Lipinski, “Enhanced Synchronization Accuracy //www.eurexchange.com/ex-en/find/initiatives/technical-changes/
in IEEE1588,” 2015 IEEE International Symposium on Precision high-precision-time-white-rabbit-pilot, 2019, [Online; accessed
Clock Synchronization for Measurement, Control, and Communi- 3-October-2020].
cation (ISPCS), pp. 76–81, 2015.
[19] A. Jarc, “Use Cases for Timing in Power
[9] E. F. Dierikx, A. E. Wallin, T. Fordell, J. Myyry, P. Koponen, Grids,” https://blog.meinbergglobal.com/2019/07/16/
M. Merimaa, T. J. Pinkert, J. C. J. Koelemeij, H. Z. Peek, and use-cases-for-timing-in-power-grids/, 2019, [Online; accessed
R. Smets, “White Rabbit Precision Time Protocol on Long Distance 3-October-2020].
Fiber Links,” IEEE Transactions on Ultrasonics, Ferroelectrics,
and Frequency Control, vol. 63, no. 7, pp. 945–952, 2016. [20] D. Arnold, “What’s In the 2019 Edition of IEEE
1588?” https://blog.meinbergglobal.com/2017/09/24/
[10] P. Moreira, P. Alvarez, J. Serrano, I. Darwezeh, and T. Wlostowski, whats-coming-next-edition-ieee-1588/, 2017, [Online; accessed
“Digital Dual Mixer Time Difference for Sub-Nanosecond Time 3-October-2020].
Synchronization in Ethernet,” pp. 449–453, 2010.

Seminar IITM WS 20/21, 17 doi: 10.2313/NET-2021-05-1_04


Network Architectures and Services, May 2021

You might also like