Information About Precision Time Protocol
Precision Time Protocol (PTP) is defined in IEEE 1588 as Precision Clock Synchronization for Networked Measurements and Control Systems, and was developed to synchronize the clocks in packet-based networks that include distributed device clocks of varying precision and stability. PTP is designed specifically for industrial, networked measurement and control systems, and is optimal for use in distributed systems because it requires minimal bandwidth and little processing overhead.
Note |
The documentation set for this product strives to use bias-free language. For purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. In this document, the terms Grandmaster clock (GMC) or time source and time recipient are used instead of the traditional Master/Slave nomenclature. |
Why PTP?
Smart grid power automation applications such as peak-hour billing, virtual power generators, and outage monitoring and management, require extremely precise time accuracy and stability. Timing precision improves network monitoring accuracy and troubleshooting ability.
In addition to providing time accuracy and synchronization, the PTP message-based protocol can be implemented on packet-based networks, such as Ethernet networks. The benefits of using PTP in an Ethernet network include:
-
Low cost and easy setup in existing Ethernet networks
-
Limited bandwidth is required for PTP data packets
Ethernet Switches and Delays
In an Ethernet network, switches provide a full-duplex communication path between network devices. Switches send data packets to packet destinations using address information contained in the packets. When the switch attempts to send multiple packets simultaneously, some of the packets are buffered by the switch so that they are not lost before they are sent. When the buffer is full, the switch delays sending packets. This delay can cause device clocks on the network to lose synchronization with one another.
Additional delays can occur when packets entering a switch are stored in local memory while the switch searches the MAC address table to verify packet CRC fields. This process causes variations in packet forwarding time latency, and these variations can result in asymmetrical packet delay times.
Adding PTP to a network can compensate for these latency and delay problems by correctly adjusting device clocks so that they stay synchronized with one another. PTP enables network switches to function as PTP devices, including boundary clocks (BCs) and transparent clocks (TCs).
Note |
To learn more about PTP clock devices and their role in a PTP network, refer to PTP Clocks. |
Message-Based Synchronization
To ensure clock synchronization, PTP requires an accurate measurement of the communication path delay between time source (grandmaster clock) and the time recipient. PTP sends messages between the time source and time recipient to determine the delay measurement. Then, PTP measures the exact message transmit and receive times and uses these times to calculate the communication path delay. PTP then adjusts current time information contained in network data for the calculated delay, resulting in more accurate time information.
This delay measurement principle determines path delay between devices on the network, and the local clocks are adjusted for this delay using a series of messages sent between time source and time recipient devices. The one-way delay time is calculated by averaging the path delay of the transmit and receive messages. This calculation assumes a symmetrical communication path; however, switched networks do not necessarily have symmetrical communication paths, due to the buffering process.
PTP provides a method, using transparent clocks, to measure and account for the delay in a time-interval field in network timing packets, making the switches temporarily transparent to the time source and time recipient nodes on the network. An end-to-end transparent clock forwards all messages on the network in the same way that a switch does.
Note |
Cisco PTP supports multicast PTP messages only. |
To read a detailed description of synchronization messages, refer to PTP Event Message Sequences. To learn more about how transparent clocks calculate network delays, refer to Transparent Clock.
The following figure shows a typical 1588 PTP network that includes grandmaster clocks, switches in boundary clock mode, and Intelligent Electronic Device (IEDs) such as a digital relays or protection devices. In this diagram, Time Source 1 is the grandmaster clock. If Time Source 1 becomes unavailable, the time recipient boundary clocks switch to Time Source 2 for synchronization.
PTP Event Message Sequences
This section describes the PTP event message sequences that occur during synchronization.
Synchronizing with Boundary Clocks
The ordinary and boundary clocks configured for the delay request-response mechanism use the following event messages to generate and communicate timing information:
-
Sync
-
Delay_Req
-
Follow_Up
-
Delay_Resp
These messages are sent in the following sequence:
-
The time source sends a Sync message to the time recipient and notes the time t1 at which it was sent.
-
The time recipient receives the Sync message and notes the time of reception t2.
-
The time source conveys to the time recipient the timestamp t1 by embedding the timestamp t1 in a Follow_Up message.
-
The time recipient sends a Delay_Req message to the time source and notes the time t3 at which it was sent.
-
The time source receives the Delay_Req message and notes the time of reception t4.
-
The time source conveys to the time recipient the timestamp t4 by embedding it in a Delay_Resp message.
After this sequence, the time recipient possesses all four timestamps. These timestamps can be used to compute the offset of the time recipient clock relative to the time source, and the mean propagation time of messages between the two clocks.
The offset calculation is based on the assumption that the time for the message to propagate from time source to time recipient is the same as the time required from time recipient to time source. This assumption is not always valid on an Ethernet network due to asymmetrical packet delay times.
Synchronizing with Peer-to-Peer Transparent Clocks
When the network includes multiple levels of boundary clocks in the hierarchy, with non-PTP enabled devices between them, synchronization accuracy decreases.
The round-trip time is assumed to be equal to mean_path_delay/2, however this is not always valid for Ethernet networks. To improve accuracy, the resident time of each intermediary clock is added to the offset in the end-to-end transparent clock. Resident time, however, does not take into consideration the link delay between peers, which is handled by peer-to-peer transparent clocks.
Peer-to-peer transparent clocks measure the link delay between two clock ports implementing the peer delay mechanism. The link delay is used to correct timing information in Sync and Follow_Up messages.
Peer-to-peer transparent clocks use the following event messages:
-
Pdelay_Req
-
Pdelay_Resp
-
Pdelay_Resp_Follow_Up
These messages are sent in the following sequence:
-
Port 1 generates timestamp t1 for a Pdelay_Req message.
-
Port 2 receives and generates timestamp t2 for this message.
-
Port 2 returns and generates timestamp t3 for a Pdelay_Resp message.
To minimize errors due to any frequency offset between the two ports, Port 2 returns the Pdelay_Resp message as quickly as possible after the receipt of the Pdelay_Req message.
-
Port 2 returns timestamps t2 and t3 in the Pdelay_Resp and Pdelay_Resp_Follow_Up messages respectively.
-
Port 1 generates timestamp t4 after receiving the Pdelay_Resp message. Port 1 then uses the four timestamps (t1, t2, t3, and t4) to calculate the mean link delay.
Synchronizing the Local Clock
In an ideal PTP network, the time source and time recipient clocks operate at the same frequency. However, drift can occur on the network. Drift is the frequency difference between the time source and time recipient clocks. You can compensate for drift by using the time stamp information in the device hardware and follow-up messages (intercepted by the switch) to adjust the frequency of the local clock to match the frequency of the time source clock.
Best Master Clock Algorithm
The Best Master Clock Algorithm (BMCA) is the basis of PTP functionality. The BMCA specifies how each clock on the network determines the best time source clock in its subdomain of all the clocks it can see, including itself. The BMCA runs on the network continuously and quickly adjusts for changes in network configuration.
The BMCA uses the following criteria to determine the best time source clock in the subdomain:
-
Clock quality (for example, GPS is considered the highest quality)
-
Clock accuracy of the clock’s time base.
-
Stability of the local oscillator
-
Closest clock to the grandmaster
In addition to identifying the best time source clock, the BMCA also ensures that clock conflicts do not occur on the PTP network by ensuring that:
-
Clocks do not have to negotiate with one another
-
There is no misconfiguration, such as two time source clocks or no time source clocks, as a result of the time source clock identification process
PTP Clocks
A PTP network is made up of PTP-enabled devices and devices that are not using PTP. The PTP-enabled devices typically consist of the following clock types.
Grandmaster Clock
Within a PTP domain, the grandmaster clock is the primary source of time for clock synchronization using PTP. The grandmaster clock usually has a very precise time source, such as a GPS or atomic clock. When the network does not require any external time reference and only needs to be synchronized internally, the grandmaster clock can free run.
Ordinary Clock
An ordinary clock is a PTP clock with a single PTP port. It functions as a node in a PTP network. Ordinary clocks are the most common clock type on a PTP network because they are used as end nodes on a network that is connected to devices requiring synchronization. Ordinary clocks have various interface to external devices.
Boundary Clock
A boundary clock in a PTP network operates in place of a standard network switch or router. Boundary clocks have more than one PTP port, and each port provides access to a separate PTP communication path. Boundary clocks provide an interface between PTP domains. They intercept and process all PTP messages, and pass all other network traffic. The boundary clock uses the BMCA to select the best clock seen by any port. The selected port is then set to non-master mode. The master port synchronizes the clocks connected downstream, while the non-master port synchronizes with the upstream master clock.
Transparent Clock
The role of transparent clocks in a PTP network is to update the time-interval field that is part of the PTP event message. This update compensates for switch delay and has an accuracy of within one picosecond.
There are two types of transparent clocks:
End-to-end (E2E) transparent clocks measure the PTP event message transit time (also known as resident time ) for SYNC and DELAY_REQUEST messages. This measured transit time is added to a data field (correction field) in the corresponding messages:
-
The measured transit time of a SYNC message is added to the correction field of the corresponding SYNC or the FOLLOW_UP message.
-
The measured transit time of a DELAY_REQUEST message is added to the correction field of the corresponding DELAY_RESPONSE message.
The time recipient uses this information when determining the offset between the time recipient’s and the time source's time. E2E transparent clocks do not provide correction for the propagation delay of the link itself.
Peer-to-peer (P2P) transparent clocks measure PTP event message transit time in the same way E2E transparent clocks do, as described above. In addition, P2P transparent clocks measure the upstream link delay. The upstream link delay is the estimated packet propagation delay between the upstream neighbor P2P transparent clock and the P2P transparent clock under consideration.
These two times (message transit time and upstream link delay time) are both added to the correction field of the PTP event message, and the correction field of the message received by the time recipient contains the sum of all link delays. In theory, this is the total end-to-end delay (from time source to time recipient) of the SYNC packet.
The following figure illustrates PTP clocks in a time source-time recipient hierarchy within a PTP network.
PTP Profiles
The IEEE 1588 definition of a PTP profile is the set of allowed PTP features applicable to a device. A PTP profile is usually specific to a particular type of application or environment and defines the following values:
-
Best master clock algorithm options
-
Configuration management options
-
Path delay mechanisms (peer delay or delay request-response)
-
Range and default values of all PTP configurable attributes and data set members
-
Transport mechanisms that are required, permitted, or prohibited
-
Node types that are required, permitted, or prohibited
-
Options that are required, permitted, or prohibited
The following PTP profiles are available on the switch:
-
Default Profile
-
Power Profile (C37.238-2011/IEC 61850-9-3 support)
-
802.1AS Profile (IE 4000 only)
-
Extended Power Profile (IEEE C37.238-2017 support—Transparent clock mode only)
Default Profile Mode
The default PTP profile mode on the switch is Default Profile mode. In this mode:
-
The PTP mode of transport is Layer 3.
-
The supported transparent clock mode is end-to-end (E2E).
Table 1 lists the configuration values for the switch in Default Profile mode.
Power Profile Mode
The Power Profile is defined in C37.238-2011 - IEEE Draft Standard Profile for Use of IEEE 1588 Precision Time Protocol in Power System Applications. This switch documentation uses the terms Power Profile mode and Default Profile mode when referring to this IEEE 1588 profile and its associated configuration values.
The IEEE Power Profile defines specific or allowed values for PTP networks used in power substations. The defined values include the optimum physical layer, the higher level protocol for PTP messages, and the preferred best master clock algorithm. The Power Profile values ensure consistent and reliable network time distribution within substations, between substations, and across wide geographic areas.
The switch is optimized for PTP in these ways:
-
Hardware—The switch uses FPGA and PHY for the PTP function. The PHY time stamps the Fast Ethernet and Gigabit Ethernet ports.
-
Software—In Power Profile mode, the switch uses the configuration values defined in the IEEE 1588 Power Profile standard.
The following table lists the configuration values defined by the IEEE 1588 Power Profile and the values that the switch uses for each PTP profile mode.
PTP Field |
Power Profile Value |
Switch Configuration Value |
|
---|---|---|---|
Power Profile Mode |
Default Profile Mode |
||
Message transmission |
Ethernet 802.3 with Ethertype 0X88F7. PTP messages are sent as 802.1Q tagged Ethernet frames with a default VLAN 0 and default priority 4. |
Access Ports –Untagged Layer 2 packets. Trunk Ports –802.1Q tagged Layer 2 packets with native VLAN on the port and default priority value of 4. |
Layer 3 packets. By default, 802.1q tagging is disabled. |
MAC address– Non-peer delay messages |
01-1B-19-00-00-00. |
01-1B-19-00-00-00. |
01-1B-19-00-00-00. |
MAC address– Peer delay messages |
01-80-C2-00-00-0E. |
01-80-C2-00-00-0E. |
Not applicable to this mode. |
Domain number |
0. |
0. |
0. |
Path delay calculation |
Peer-to-peer transparent clocks. |
Peer-to-peer transparent clocks using the peer_delay mechanism. |
End-to-end transparent clocks using the delay_request mechanism. |
BMCA |
Enabled. |
Enabled. |
Enabled. |
Clock type |
Two-step clocks are supported. |
Two-step. |
Two-step. |
Time scale |
Epoch.1 |
Epoch. |
Epoch. |
Grandmaster ID and local time determination |
PTP-specific TLV (type, length, value) to indicate Grandmaster ID. |
PTP-specific TLV to indicate Grandmaster ID. |
PTP-specific type, length, and value to indicate Grandmaster ID. |
Time accuracy over network hops |
Over 16 hops, slave device synchronization accuracy is within 1 usec (1 microsecond). |
Over 16 hops, slave device synchronization accuracy is within 1 usec (1 microsecond). |
Not applicable in this mode. |
802.1AS Profile (IE 4000 only)
Note |
The 802.1AS Profile is supported for the IE 4000 only. |
The IEEE 802.1AS standard "Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks" specifies the protocol and procedures used to ensure that synchronization requirements are met for time-sensitive applications across bridged and virtual bridged local area networks.
802.1AS specifies the use of IEEE 1588 (PTP) specifications where applicable in the context of IEEE Std 802.1D -2004 and IEEE Std 802.1Q -2005.1. The 802.1AS standard is one of three 802.1 AVB draft standards. 802.1AS over Ethernet (802.3) qualifies as a Profile of IEEE 1588-2008. It simplifies IEEE 1588 and defines synchronization over different types of media.
Key characteristics of 802.1AS are:
-
For Ethernet full-duplex links, it uses the peer delay mechanism.
-
All switches in the domain need to be 802.1AS capable.
-
Transportation of 802.1AS packets is L2 multicast only, with no VLAN tag.
-
It requires two-step processing (use of Follow_Up and Pdelay_Resp_Follow_Up messages to communicate timestamps).
-
There is only a single active grandmaster in a time-aware network. That is, there is only a single 802.1AS domain.
-
The BMCA (Best Master Clock Algorithm) is same as that used in IEEE 1588 with the following exceptions:
-
Announce messages received on a time recipient port that were not sent by the receiving time-aware system are used immediately; that is, there is no foreign-time source qualification.
-
A port that the BMCA determines should be a time source port enters the time source state immediately; that is, there is no pre-time source state.
-
The uncalibrated state is not needed and therefore not used.
-
All time-aware systems are required to participate in best master selection (even if the system is not grandmaster capable).
-
802.1AS on the IE 4000
On the IE 4000, 802.1AS is used in the Time Sensitive Network (TSN) feature. However, as a precise timing distribution mechanism, 802.1AS runs by itself without TSN configuration or inputs. The 802.1AS feature software implementation is based on the existing time stamping functionality of FPGA and has no new requirement on hardware beyond other PTP profiles.
The end-to-end time-synchronization performance of 802.1AS on the IE 4000 is as follows:
-
Any two time-aware systems separated by six or fewer time-aware systems (that is, seven or fewer hops) will be synchronized to within 1 μs peak-to-peak of each other during steady-state operation.
-
Performance beyond 7 hops is not defined.
PTP Profile Comparison
Profile |
Default (*) |
Power |
802.1AS |
||
---|---|---|---|---|---|
Standard |
IEEE1588 v2 (J.3) |
IEEE C37.238-2011 |
IEEE802.1AS |
||
Mode |
Boundary |
End-to-End transparent |
Boundary |
Peer-to-Peer transparent |
** |
Path Delay |
Delay req/res |
Delay req/res |
Peer delay req/res |
Peer delay req/res |
Peer delay req/res |
Non-PTP device allowed in PTP domain |
Yes |
Yes |
No |
No |
No |
Transport |
UDP over IP (multicast and unicast) |
L2 Multicast |
L2 Multicast |
* Delay Request-Response Default PTP profile (as defined in IEEE1588 J.3).
** There is no mode setting for 802.1AS. Mathematically it is equivalent to P2P transparent, but it works differently from a transparent clock.
Tagging Behavior for PTP Packets
The following table describes the switch tagging behavior in Power Profile and Default Profile modes.
Switch Port Mode |
Configuration |
Power Profile Mode |
Default Profile Mode |
||
---|---|---|---|---|---|
Behavior |
Priority |
Behavior |
Priority |
||
Trunk Port |
vlan dot1q tag native enabled |
Switch tags packets |
7 |
Switch tags packets |
7 |
Trunk Port |
vlan dot1q tag native disabled |
PTP software tags packets |
4 |
Untagged |
None |
Access Port |
N/A |
Untagged |
None |
Untagged |
None |
PTP Clock Modes Supported on the Switch
PTP synchronization behavior depends on the PTP clock mode that you configure on the switch. You can configure the switch for one of the following global modes.
See Guidelines and Limitations for guidelines for configuring each of the clock modes.
Boundary Clock Mode
A switch configured for boundary clock mode participates in selecting the best time source clock on the subdomain, selecting from all clocks it can see, including itself. If the switch does not detect a more accurate clock than itself, then the switch becomes the time source clock. If a more accurate clock is detected, then the switch synchronizes to that clock and becomes a time recipient clock.
After initial synchronization, the switch and the connected devices exchange PTP timing messages to correct the changes caused by clock offsets and network delays.
Forward Mode
A switch configured for forward mode passes incoming PTP packets as normal multicast traffic.
E2E and P2P Transparent Clock Modes
Transparent clocks synchronize their local clocks to the GMC by snooping the Sync messages. They do not participate in the best master clock algorithm. Transparent clocks use the default PTP clock mode on all ports.
Configurable Boundary Clock Synchronization Algorithm
You can configure the BC synchronization algorithm to accommodate various PTP use cases, depending on whether you need to prioritize filtering of input time errors or faster convergence. A PTP algorithm that filters packet delay variation (PDV) converges more slowly than a PTP algorithm that does not.
By default, the BC uses a linear feedback controller (that is, a servo) to set the BC's time output to the next clock. The linear servo provides a small amount of PDV filtering and converges in an average amount of time. For improved convergence time, BCs can use the TC feedforward algorithm to measure the delay added by the network elements forwarding plane (the disturbance) and use that measured delay to control the time output.
While the feedforward BC dramatically speeds up the boundary clock, the feedforward BC does not filter any PDV. The adaptive PDV filter provides high quality time synchronization in the presence of PDV over wireless access points (APs) and enterprise switches that do not support PTP and that add significant PDV.
Three options are available for BC synchronization (all are compliant with IEEE 1588-2008):
-
Feedforward—For very fast and accurate convergence; no PDV filtering.
-
Adaptive—Filters as much PDV as possible, given a set of assumptions about the PDV characteristics, the hardware configuration, and the environmental conditions.
Note
With the adaptive filter, the switch does not meet the time performance requirements specified in ITU-T G.8261.
-
Linear—Provides simple linear filtering (the default).
Adaptive mode (ptp transfer filter adaptive ) is not available in Power Profile mode.
For configuration information, see .