PTP Overview
The Precision Time Protocol (PTP), as defined in the IEEE 1588 standard, synchronizes with nanosecond accuracy the real-time clocks of the devices in a network. The clocks are organized into a master-slave hierarchy. PTP identifies the port that is connected to a device with the most precise clock. This clock is referred to as the master clock. All the other devices on the network synchronize their clocks with the master and are referred to as members. Constantly exchanged timing messages ensure continued synchronization. PTP ensures that the best available clock is selected as the source of time (the grandmaster clock) for the network and that other clocks in the network are synchronized to the grandmaster.
|
Network Element |
Description |
|---|---|
|
Grandmaster (GM) |
A network device physically attached to the primary time source. All clocks are synchronized to the grandmaster clock. |
|
Ordinary Clock (OC) |
An ordinary clock is a 1588 clock with a single PTP port that can operate in one of the following modes:
|
|
Boundary Clock (BC) |
The device participates in selecting the best master clock and can act as the master clock if no better clocks are detected. Boundary clock starts its own PTP session with a number of downstream slaves. The boundary clock mitigates the number of network hops and packet delay variations in the packet network between the Grand Master and Slave. |
|
Transparent Clock (TC) |
A transparent clock is a device or a switch that calculates the time it requires to forward traffic and updates the PTP time correction field to account for the delay, making the device transparent in terms of time calculations. |
PTP consists of two parts:
-
The port State machine and Best Master Clock Algorithm: This provides a method to determine state of the ports in the network that will remain passive (neither master nor slave), run as a master (providing time to other clocks in the network), or run as slaves (receiving time from other clocks in the network).
-
Delay-Request/Response mechanism and a Peer-delay mechanism: This provides a mechanisms for slave ports to calculate the difference between the time of their own clocks and the time of their master clock.
 Note |
Transparent Clock (TC) is not supported. |
Frequency and Time Selection
The selection of the source to synchronize the device clock frequency is made by frequency synchronization, and is outside of the scope of PTP. The Announce, Sync, and Delay-request frequencies must be the same on the master and slave.
Delay Request-Response Mechanism
The Delay Request-response mechanism (defined in section 11.3 of IEEE Std 1588-2008) lets a slave port estimate the difference between its own clock-time and the clock-time of its master. The following options are supported:
-
One-step mechanism - The timestamp for a Sync message is sent in the Sync message itself.
-
Two-step mechanism - The timestamp for a Sync message is sent later in a Follow-up message.
When running a port in Slave state, a router can send Delay-request messages and handle incoming Sync, Follow-up, and Delay-response messages. The timeout periods for both Sync and Delay-response messages are individually configurable.
Hybrid Mode
Your router allows the ability to select separate sources for frequency and time-of-day (ToD). Frequency selection can be between any source of frequency available to the router, such as: BITS, GPS, SyncE or IEEE 1588 PTP. The ToD selection is between the source selected for frequency and PTP, if available (ToD selection is from GPS, or PTP). This is known as hybrid mode, where a physical frequency source (BITS or SyncE) is used to provide frequency synchronization, while PTP is used to provide ToD synchronization.
Frequency selection uses the algorithm described in ITU-T recommendation G.781. The ToD selection is controlled using the time-of-day priority configuration. This configuration is found under the clock interface frequency synchronization configuration mode and under the global PTP configuration mode. It controls the order for which sources are selected for ToD. Values in the range of 1 to 254 are allowed, with lower numbers indicating higher priority.
The steps involved in section Configuring PTP Hybrid Mode of the topic G.8275.1.
Time of Day (ToD) Support
The router receives GPS ToD messages in serial ASCII stream through the RS422 interface in one of the following configurable formats:
-
NTP Type 4
-
Cisco
Port States for PTP
State machine indicates the behavior of each port. The possible states are:
|
State |
Description |
|---|---|
|
INIT |
Port is not ready to participate in PTP. |
|
LISTENING |
First state when a port becomes ready to participate in PTP: In this state, the port listens to PTP masters for a (configurable) period of time. |
|
PRE-MASTER |
Port is ready to enter the MASTER state. |
|
MASTER |
Port provides timestamps for any Slave or boundary clocks that are listening. |
|
UNCALIBRATED |
Port receives timestamps from a Master clock but, the router’s clock is not yet synchronized to the Master. |
|
SLAVE |
Port receives timestamps from a Master clock and the router’s clock is synchronized to the Master. |
|
PASSIVE |
Port is aware of a better clock than the one it would advertise if it was in MASTER state and is not a Slave clock to that Master clock. |
Restrictions for PTP
The following PTP restrictions apply to the Cisco 8000 Series Router:
-
Sync2 interface is supported only if 10 MHz, 1 Pulse per Second (PPS) and time-of-day (ToD) ports are configured.
-
PTP is not supported with global MACSec.
-
PTP is not supported with MACSec on the same interface.
However, PTP is supported if MACSec is not configured on interface.
-
PTP is not supported with global MACSec-FIPS-Post.
MACSec-FIPS-Post is not available per interface.
-
Transparent Clock is not supported. One-step clock is supported. It can receive follow-up PTP packets, that is, it can support a two-step peer primary but it cannot send follow-up PTP packets.
-
When a subinterface is configured with encapsulation default or untag configuration, you must configure PTP on that subinterface, instead of the main interface.
-
PTP is configurable on Gigabit Ethernet interfaces (1G, 10G, 40G, and 100G), Bundle Ethernet interfaces, and sub-interfaces. PTP is not configurable on LAG Ethernet sub-interfaces.
-
PTP is supported over individual bundle member links and not supported on Bundle-Ether interfaces.
PTP Support Information
This table lists different types of support information related to PTP:
|
Transport Media |
|
|
Messages |
|
|
Transport Modes |
|
Timing Profile and Class Support Matrix
This table provides a detailed information on the timing features that are supported on the Cisco 8000 series routers and line cards.
|
Hardware Module |
Supported Profile |
Supported G.8273.2 Class |
Cisco IOS XR Release |
|---|---|---|---|
|
Cisco 8212-48FH-M router |
G.8262 |
NA |
Release 24.4.1 |
|
G.8264 |
NA |
||
|
G.8275.1 |
NA |
||
|
G.8273.2 |
Class C |
||
|
G8275.1 |
NA |
Release 7.11.1 |
|
G8273.2 |
Class C |
||
|
G.8273.2 |
Class C |
Release 7.5.2 |
|
G.8275.1 |
NA |
||
|
G.8273.2 |
Class C |
Release 7.3.3 |
|
G.8275.1 |
NA |
||
|
G.8273.2 |
Class C |
Release 7.3.1 |
|
G.8275.1 |
NA | ||
|
G.8265.1 |
NA | ||
|
G.8263 |
NA |
Configuring PTP Delay Asymmetry
|
Feature Name |
Release Information |
Description |
|---|---|---|
|
PTP Delay Asymmetry |
Release 7.3.2 |
Any delays on Precision Time Protocol (PTP) paths can impact PTP accuracy and in turn impact clock settings for all devices in a network. This feature allows you to configure the static asymmetry such that the delay is accounted for and the PTP synchronization remains accurate. The delay-symmetry command is introduced for this feature. |
Configure PTP delay asymmetry to offset the static delays on a PTP path that occur due to different route selection for forward and reverse PTP traffic. Delays can also be due to any node having different delay for ingress or egress path. These delays can impact PTP accuracy due to the asymmetry in PTP. With this feature, you can enable a higher degree of accuracy in the PTP server performance leading to better synchronization between real-time clocks of the devices in a network.
Configuration of this delay asymmetry provides an option to configure static delays on a client clock for every server clock. You can configure this delay value in microseconds and nanoseconds. Configured PTP delay asymmetry is also synchronized with the Servo algorithm.
Note |
|
A positive value indicates that the server-to-client propagation time is longer than the client-to-server propagation time, and conversely for negative values.
Supported PTP Profiles
The following PTP profiles support the configuration of PTP delay asymmetry:
-
PTP over IP (G8275.2 or default profile)
-
PTP over L2 (G8275.1)
Restrictions
-
PTP delay asymmetry can be configured only on the PTP port of the grandmaster clock, which can either be a boundary clock or an ordinary clock.
-
PTP delay asymmetry is supported for delay compensation of fixed cables and not for variable delay in the network.
-
PTP delay asymmetry can be configured within the range of 3 microseconds and -3 microseconds or 3000 nanoseconds and -3000 nanoseconds.
Configuration
To configure PTP delay asymmetry:
-
Configure an interface with PTP.
-
Configure PTP delay asymmetry on the client side.
Configuration Example
/* Configure an interface with PTP. */
Router# configure
Router(config)# interface HundredGigE 0/1/0/0
Router(config-if)# ptp
/* Configure PTP delay asymmetry on the client side. */
Router(config-if-ptp)# delay-asymmetry 3 microseconds
Router(config-if-ptp)# commitRunning Configuration
interface preconfigure HundredGigE 0/1/0/0
ptp
delay-asymmetry 3 microsecondsVerification
To verify if PTP delay asymmetry is applied, use the show ptp foreign-masters command:
Router# show ptp foreign-masters
Sun Nov 1 10:19:21.874 UTC
Interface HundredGigE0/1/0/0 (PTP port number 1)
IPv4, Address 209.165.200.225, Unicast
Configured priority: 1
Configured clock class: None
Configured delay asymmetry: 3 microseconds <- configured variable delay asymmetry value
Announce granted: every 2 seconds, 300 seconds
Sync granted: 16 per-second, 300 seconds
Delay-resp granted: 16 per-second, 300 seconds
Qualified for 2 minutes, 45 seconds
Clock ID: 80e01dfffe8ab73f
Received clock properties:
Domain: 0, Priority1: 128, Priority2: 128, Class: 6
Accuracy: 0x22, Offset scaled log variance: 0xcd70
Steps-removed: 1, Time source: GPS, Timescale: PTP
Frequency-traceable, Time-traceable
Current UTC offset: 37 seconds (valid)
Parent properties:
Clock ID: 80e01dfffe8ab73f
Port number: 1To validate the approximate compensated delay value, use the show ptp platform servo command:
Router# show ptp platform servo
Mon Jun 27 22:32:44.912 UTC
Servo status: Running
Servo stat_index: 2
Device status: PHASE_LOCKED
Servo Mode: Hybrid
Servo log level: 0
Phase Alignment Accuracy: -2 ns
Sync timestamp updated: 18838
Sync timestamp discarded: 0
Delay timestamp updated: 18837
Delay timestamp discarded: 0
Previous Received Timestamp T1: 1657002314.031435081 T2: 1657002314.031436686 T3: 1657002314.026815770 T4: 1657002314.026814372
Last Received Timestamp T1: 1657002314.031435081 T2: 1657002314.031436686 T3: 1657002314.088857790 T4: 1657002314.088856392
Offset from master: 0 secs, 1502 nsecs <<--compensated value shows 1.5 microseconds because the asymmetry configured under the interface is
3 microseconds.->>
Mean path delay : 0 secs, 103 nsecs
setTime():0 stepTime():0 adjustFreq():2
Last setTime: 0.000000000 flag:0 Last stepTime:0 Last adjustFreq:-5093
Feedback