Configuring Precision Time Protocol

Precision Time Protocol (PTP) is a protocol that defines a method to distribute time around a network. PTP support is based on the IEEE 1588-2008 standard. This module describes the concepts around this protocol and details the various configurations involved.

This module contains the following topics:

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.

Table 1. PTP Clocks

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:

  • Master mode—Distributes timing information over the network to one or more slave clocks, thus allowing the slave to synchronize its clock to the master.

  • Slave mode—Synchronizes its clock to a master clock. You can enable the slave mode on up to two interfaces simultaneously in order to connect to two different master clocks.

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-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 configuring PTP hybrid mode is described in a subsequent section in this chapter.

Time of Day (ToD) Support

The router receives GPS ToD messages in serial ASCII stream through the RS422 interface in any of the following formats:

  • NTP Type 4

  • Cisco

  • NMEA - GPZDA


Note

You can refer to the below support information in context of the current release and see relevant Release Notes for more information on supported features and hardware.

Port States

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.

PTP Support Information

This table lists different types of support information related to PTP:

Transport Media

  • UDP over IPv4

  • Ethernet

Messages

  • Signaling

  • Announce

  • Sync

  • Follow-up

  • Delay-request

  • Delay-response

  • Management

Transport Modes

  • Unicast: This is the default mode. All packets are sent as unicast messages. Unicast is applicable only for PTP over IP profiles.

  • Multicast: All packets are sent as multicast messages. Multicast is the only mode for PTP over ethernet profiles.

PTP Hardware Support


Note

The table also contains support details of upcoming releases. You can read this table in context of the current release and see relevant Release Notes for more information on supported features and hardware.

This table provides a detailed information on the timing features that are supported on the following hardware variants.

Hardware Variant

Features

Cisco IOS XR Release

Comments

NCS-57B1-6D24-SYS

NCS-57B1-5DSE-SYS

NCS-57D2-18DD-SYS

Default profile

Release 7.11.1

 With this release, PTP Class C performance and QSFP-DD optics are now supported on 400G port speed.

G.8265.1

G.8275.1

G.8275.2

NC57-48Q2D-S

NC57-48Q2D-SE-S

G8275.1

Release 7.10.1

With this release, SyncE and PTP Class-C, Class-B performance is supported on 1G, 10G, 25G, 40G and 100G port speeds.

On 50G and 400G ports speeds, only timing functionality is supported.

PTP support is available on compatible mode.

PTP with Class-C is not achieved with macsec on any interface speed.

Note

 

For 1G Class C port speed, only port 32 and 40 are supported. It is not recommended to plug in 1G optics to ports greater than or equal to port 32.

NC57-36H6D-S

G8265.1

Release 7.10.1

With this release, timing support for PTP and SyncE is extended to 4x10G and 4x25G breakout ports of NC57-36H6D-S in native mode.

Class B and Class C performances are supported on 4x10G and 4x25G breakout ports in native mode. Route Processor: NC55-RP2-E

G8275.1

G8275.2

Default Profile

NC57-36H-SE

G8265.1

Release 7.10.1

With this release, timing support for PTP and SyncE is extended to 4x10G breakout port of NC57-36H-SE is in native mode.

Class B performance is supported on 4x10G breakout port in native mode.

Route Processor: NC55-RP2-E

G8275.1

G8275.2

Default Profile

NCS-57C1-48Q6-SYS

G.8265.1

Release 7.10.1

G.8273.2 Class C is supported on 400G interfaces with the following optics modules:

  • Cisco QSFPDD 400G FR4 Pluggable Optics Module

  • Cisco QSFPDD 400G LR4 Pluggable Optics Module

G.8275.1

G.8275.2

Default Profile

NCS-57D2-18DD-SYS

G.8265.1

Release 7.8.1

With this release,PTP is supported on 400G, 100G and 40G ports.

Class C performance on 100G and 40G ports.

G.8275.1

Release 7.8.1

G.8275.2

Release 7.8.1

Default Profile

Release 7.8.1

NCS-57C3-MOD-SYS

NCS-57C3-MODS-SYS

Timing support for PTP and SyncE over Breakout port

 Release 24.3.1

With this release, the timing support for PTP and SyncE is extended to 4x10G and 4x25G breakout ports in NCS-57C3-MOD and NCS-57C3-MODS-SYS routers with 8 fixed port number 24 to 31 and 4x10G.

Class A and Class B performances are supported on 4x10G and 4x25G breakout ports of NCS-57C3-MOD and NCS-57C3-MODS-SYS routers.

NCS-57C3-MOD-SYS

NCS-57C3-MODS-SYS

PTP Virtual Port and APTS

Release 7.7.1

C57-MPA-2D4H-S

Timing support for PTP and SyncE over Breakout port

 Release 24.3.1

With this release, the timing support for PTP and SyncE is extended to 4x25G breakout ports in NC57-MPA-2D4H-S router.

Class A and Class B performances are supported on 4x25G breakout ports of NC57-MPA-2D4H-S router.

NCS-57B1-6D24-SYS

PTP Virtual Port and APTS

Release 7.7.1

NCS-57C1-48Q6-SYS

Default profile

Release 7.5.1

G.8265.1

Release 7.5.1

G.8275.1

Release 7.5.1

G.8275.2

Release 7.5.1

RP:NC57-MOD-RP-2E with NCS573-MODS-SYS and NCS-573-MOD-SYS

G.8275.1

Release 7.4.1

G.8273.2

Release 7.4.1

GNSS

Release 7.4.1

NCS-57B1-5DSE-SYS

NCS-57B1-6D24-SYS

Default profile

Release 7.3.1

G.8265.1

Release 7.3.1

G.8275.1

Release 7.3.1

G.8275.2

Release 7.3.1

RP: NC55-RP2-E

Line card: NC57-36H6D-S

G.8275.1

 Release 7.3.2

  • Release 7.3.2 - Supports Compatible Mode only

  • Release 7.7.1 - Supports both Native and Compatible mode.

G.8273.2

Release 7.3.2

  • Release 7.3.2 - Supports Compatible Mode only

  • Release 7.7.1 - Supports both Native and Compatible mode.

RP:NC55-RP-E with Line cards: NC55-MOD-A-S and NC55-32T16Q4H-AT

BITS

Release 7.1.1

G8275.1

Release 7.1.1

For the profile G8275.1 NC55-32T16Q4H-AT supports only T-BCand does not support T-GM. 25G/100G/40G is supported from IOSXR release 7.2.2 onwards.

G8273.2

Release 7.1.1

Class B

RP:NC55-RP2-E with Line cards: NC55-MOD-A-S and NC55-32T16Q4H-AT

BITS

Release 7.1.1

G.8275.1

Release 7.1.1

For the profile G8275.1 NC55-32T16Q4H-AT supports only T-BC and does not support T-GM. 25G/100G/40G is supported from IOSXR release 7.2.2 onwards.

G.8273.2

Release 7.1.1

Class B

RP:NC55-RP2-E with Line card:NC55-32T16Q4H-AT

BITS

Release 7.1.1

G8275.1

Release 7.1.1

For the profile G8275.1 NC55-32T16Q4H-AT supports only T-BCand does not support T-GM. 25G/100G/40G is supported from IOSXR release 7.2.2 onwards.

G.8273.2

Release 7.1.1

Class C

NCS-55A1-36H-SE-S

G.8265.1

Release 7.0.1

G.8275.1

Release 7.0.1

G.8275.2

Release 7.0.1

G.8273.2

Release 7.0.1

Class B

NCS-55A1-36H-S

G.8265.1

Release 7.0.1

G.8275.1

Release 7.0.1

G.8275.2

Release 7.0.1

G.8273.2

Release 7.0.1

Class B

NCS-55A1-24Q6H-S

NCS-55A1-24Q6H-SS

G.8265.1

Release 6.6.25

G.8275.1

Release 6.6.25

G.8275.2

Release 6.6.25

From Release 7.7.1, support is available for PTP over IPv6 for ports 10G-25G and 40G-100G

G.8273.2

Release 6.6.25

Class B

NCS-55A1-48Q6H

G.8265.1

Release 6.6.25

G.8275.1

Release 6.6.25

G.8275.2

Release 6.6.25

G.8273.2

Release 6.6.25

Class B

NCS-55A1-24H

G.8265.1

Release 6.5.2

G.8275.1

Release 6.5.2

G.8275.2

Release 6.5.2

G.8273.2

Release 6.5.2

Class B

NCS55A2-MOD

G.8265.1

Release 6.5.1

G.8275.1

Release 6.5.1

G.8275.2

Release 6.5.1

G.8273.2

Release 6.5.1

Class B

RP:NC55-RP-E

Linecard:NC55-MOD-A-S

BITS

Release 6.5.1

SyncE is not supported on 25GE or 100GE interfaces, when they are used in 1G mode.

G.8265.1

Release 6.5.1

G.8275.1

Release 6.5.1

G.8275.2

Release 6.5.1

This profile is supported from Release 6.5.1 for Ipv4.

G.8273.2

Release 6.5.1

Class B

RP:NC55-RP-E

Linecard:NC55-36X100G-A-SE

G.8273.2

Release 6.3.2

Class B

BITS

Release 6.3.2

SyncE is not supported on 25GE or 100GE interfaces, when they are used in 1G mode.

G.8265.1

Release 6.3.2

G.8275.1

Release 6.3.2

G.8275.2

NA

G.8273.2

Release 6.3.2

Class B

NCS5501-SE

G.8265.1

Release 6.3.2

G.8275.1

Release 6.3.2

Class B

G.8275.2

Release 6.3.2

GNSS External

Release 6.3.2

Timing features are supported on the following MPAs:

  • NC55-MPA-2TH-S

  • NC55-MPA-1TH2H-S

  • NC55-MPA-1TH2H-HD-S

  • NC55-MPA-4H-S

  • NC55-MPA-4H-HD-S

  • NC55-MPA-12T-S

Breakout Timing Support

PTP Profiles 8275.1 and 8275.2 are supported on breakout ports on the following hardware PIDs:

Table 2. Breakout Timing Support Hardware Matrix

Hardware PID

Client Port

Server Port

NCS-57C3-MOD

NCS-57C3-MODS-SYS

100G

25G Breakout

NC57-MPA-2D4H-S

40G

10G Breakout

NCS-55A1-36H-S

100G

25G Breakout

NCS-55A1-36H-S

100G

10G Breakout

NCS-55A1-48Q6H

10G

25G Breakout

NCS-55A1-48Q6H

100G

25G Breakout

NCS55A1-24Q6H-S

1G

25G Breakout

NCS55A1-24Q6H-S

10G

25G Breakout

NCS55A1-24Q6H-S

100G

25G Breakout

NCS-5501-SE

1G

10G Breakout

NCS-5501-SE

1G

25G Breakout

NCS-5501-SE

10G

10G Breakout

NCS-5501-SE

10G

25G Breakout

NC57-36H6D-S

25G

25G Breakout

NC57-36H6D-S

25G

10G Breakout

NC57-36H6D-S

10G

25G Breakout

NC57-36H6D-S

10G

10G Breakout

NC57-36H-SE

10G

10G Breakout

Note

The server ports 100G and 40G are used as breakout for 4x25G and 4x10G respectively. The client ports are used as direct ports of different port speeds as presented in the table, Breakout Timing Support Hardware Matrix.

PTP Phase Difference Threshold Between Passive and Secondary Ports

Table 3. Feature History Table

Feature Name

Release Information

Feature Description

PTP Phase Difference Threshold Between Passive and Secondary Ports

Release 24.2.1

Introduced in this release on:NCS 5500 fixed port routersNCS 5500 modular routersNCS 5500 line cardsNCS 5700 line cards [Mode: Compatibility; Native]

Passive ports can now be included in the Delay Request-Response Mechanism (DRRM), which allows for the monitoring of PTP phase differences between a passive port and a secondary port. If these PTP phase differences surpass a predefined limit, system logs are triggered. This feature enables you to detect potential errors such as fiber asymmetry or a clock failure in the PTP network.

This feature introduces these changes:

CLI:

  • phase-difference-threshold-breach

  • The show ptp foreign-masters command output is enhanced to include phase difference values and servo status.

YANG Data Models:

The following data models are enhanced:

  • Cisco-IOS-XR-ptp-cfg.yang

  • Cisco-IOS-XR-um-ptp-cfg.yang

The Precision Time Protocol (PTP), as defined in the IEEE 1588 standard, is designed for precise time synchronization across networked devices. It operates by having Foreign Masters (FMs) broadcast timing information to interfaces within the network. The selection of the Grandmaster (GM), the primary reference clock, is determined by the Best Master Clock Algorithm (BMCA). Devices synchronize their clocks to the GM through a process known as the Delay Request-Response Mechanism (DRRM), wherein ports that are directly synchronizing with the GM enter a secondary state.

Historically, ports in a passive state—those that receive timing messages from FMs but aren’t actively syncing to the GM—didn’t participate in DRRM, which meant they didn’t synchronize their clocks.

Starting Cisco IOS XR Software Release 24.2.1, DRRM has been extended to include passive ports, enabling them to engage in the exchange of delay request and response packets. This enhancement allows for the calculation of PTP phase differences between the clocks on passive ports and the GM.

This calculated PTP phase difference provides a valuable insight into the timing characteristics of other foreign masters in the network by using the grandmaster as a reference point. It can be utilized on any boundary clock or slave clock that has connections to at least one other foreign master.

You can access these measurements and the calculated PTP phase differences using show commands through the router's CLI. Also, the information can be retrieved programmatically through operational data models in YANG, providing flexibility in how you can access and utilize this synchronization data.

Phase Difference Alarm

PTP phase difference can also be used to monitor the timing properties of the network. You can configure a value at which a bistate alarm is triggered when the PTP phase difference of a FM exceeds the threshold. The PTP phase difference can have a negative or positive value, but the threshold can only be the absolute value. You can configure the PTP phase difference threshold using the phase-difference-threshold-breach command.

System Log for PTP Phase Difference

When the configured threshold is reached, system logs (syslogs) are displayed. The following syslog is triggered if the configured PTP phase difference threshold is passed through by any master. 

Phase difference for clock ACDE48FFFE234567, steps removed 1, receiving-port 1, received on interface GigabitEthernet0/2/0/3 is 40ns, configured threshold is 30ns. Raising phase difference alarm.

Configure PTP Phase Difference Alarm Threshold

Procedure

Step 1

Configure threshold for triggering PTP phase difference alarms using the phase-difference-threshold-breach command.

Example:
Router#configure terminal
Router(config)#ptp
Router(config-ptp)#phase-difference-threshold-breach 300
Router(config-ptp)#commit

Step 2

Verify that PTP phase difference threshold value is configured using the show running configuration command.

Example:

ptp
 phase-difference-threshold-breach 300
!

Step 3

Display the current operational value using the show ptp foreign-masters command.

Example:
Router#show ptp foreign-masters
Ethernet, Address 0102.0304.050a, Multicast
    Configured priority: 40
    Configured clock class: None
    Configured delay asymmetry: 3 microseconds
    Announce granted:   4 per-second,      600 seconds
    Sync granted:       4 per-second,      600 seconds
    Delay-resp granted: 4 per-second,      600 seconds
    Not qualified (PTSF lossSync)
    Clock ID: abcdef1
    Phase difference: 300ns
    Servo status: PTSF-unusable
    Received clock properties:
      Domain: 0, Priority1: 1, Priority2: 100, Class: 52
      Accuracy: 0x00, Offset scaled log variance: 0x0000
      Steps-removed: 2, Time source: GPS, Timescale: PTP
      Time-traceable
      Current UTC offset: 0 seconds
    Parent properties:
      Clock ID: 0
      Port number: 0

Isolate Foreign Masters Causing Packet Timing Signal Fail

Table 4. Feature History Table

Feature Name

Release Information

Feature Description

Isolate Foreign Masters Causing Packet Timing Signal Fail

Release 24.2.1

Introduced in this release on:NCS 5500 fixed port routers, NCS 5500 modular routers, NCS 5500 line cards, and NCS 5700 line cards [Mode: Compatibility; Native]

This feature permits the flexible selection of timing sources by filtering out Foreign Master (FM) clocks that exhibit unstable timing. This filtering causes the secondary clocks to produce a signal deemed Packet Timing Signal Fail (PTSF)-unusable, from consideration within the Best Master Clock Algorithm (BMCA). The system continuously monitors these clocks for timing stabilization, and upon detecting enhanced stability, it may reevaluate and possibly reintegrate them as suitable time sources.

This feature introduces these changes:

CLI:

  • detect-ptsf-unusable

  • The show ptp foreign-masters command output is enhanced to include phase difference values and servo status.

YANG Data Models:

The following data models are enhanced:

  • Cisco-IOS-XR-ptp-cfg.yang

  • Cisco-IOS-XR-um-ptp-cfg.yang

Starting Cisco IOS XR Software Release 24.2.1, the servo mechanism now has the ability to detect unusable clocks due to packet timing signal fail by analyzing timestamps from foreign masters. This enhancement allows the system to identify foreign masters with unstable timing as unsuitable for use. A platform supports multiple masters, such a master can be excluded from the BMCA selection process while remaining under observation for potential recovery. Even after a master is deemed unusable, the DRRM continues to operate and timestamps from it are still provided to the servo. This ongoing monitoring enables PTP to detect and respond to any improvements in the primary's timing, allowing it to be reconsidered as usable.

System Log for PTSF-unusable

When the master becomes PTSF-unusable, and if its the current Grandmaster, the following system log (syslogs) is displayed:

Foreign master with clock ID ACDE48FFFE234567, steps removed 1, receiving-port 1, received on interface GigabitEthernet0/2/0/4 is now PTSF-unusable and disqualified from selection.

Configure PTSF-unusable

Procedure

Step 1

Exclude the FM with unstable timing from selection in the BMCA and declare it as unusable using the detect-ptsf-unusable command.

Example:
Router#configure terminal
Router(config)#ptp
Router(config-ptp)#detect-ptsf-unusable
Router(config-ptp)#commit

Step 2

Check if the master clock is PTSF-unuable using the show ptp foreign-masters command.

Example:
Router#show-ptp-foreign-masters
Ethernet, Address 0102.0304.050a, Multicast
    Configured priority: 40
    Configured clock class: None
    Configured delay asymmetry: 3 microseconds
    Announce granted:   4 per-second,      600 seconds
    Sync granted:       4 per-second,      600 seconds
    Delay-resp granted: 4 per-second,      600 seconds
    Not qualified (PTSF lossSync)
    Clock ID: abcdef1
    Phase difference: -5000ns
    Servo status: PTSF-unusable
    Received clock properties:
      Domain: 0, Priority1: 1, Priority2: 100, Class: 52
      Accuracy: 0x00, Offset scaled log variance: 0x0000
      Steps-removed: 2, Time source: GPS, Timescale: PTP
      Time-traceable
      Current UTC offset: 0 seconds
    Parent properties:
      Clock ID: 0
      Port number: 0

ITU-T Telecom Profiles for PTP

Cisco IOS XR software supports ITU-T Telecom Profiles for PTP as defined in the ITU-T recommendations. A profile is a specific selection of PTP configuration options that are selected to meet the requirements of a particular application.

PTP lets you define separate profiles to adapt itself for use in different scenarios. A telecom profile differs in several ways from the default behavior defined in the IEEE 1588-2008 standard and the key differences are mentioned in the subsequent sections.

The following sections describe the ITU-T Telecom Profiles that are supported for PTP.

G.8265.1

G.8265.1 profile fulfills specific frequency-distribution requirements in telecom networks. Features of G.8265.1 profile are:

  • Clock advertisement: G.8265.1 profile specifies changes to values used in Announce messages for advertising PTP clocks. The clock class value is used to advertise the quality level of the clock, while the other values are not used.

  • Clock Selection: G.8265.1 profile also defines an alternate Best Master Clock Algorithm (BMCA) to select port states and clocks is defined for the profile. This profile also requires to receive Sync messages (and optionally, Delay-Response messages) to qualify a clock for selection.

  • Port State Decision: The ports are statically configured to be Master or Slave instead of using state machines to dynamically set port states.

  • Packet Rates: The packet rates higher than rates specified in the IEEE 1588-2008 standard are used. They are:

    • Sync/Follow-Up Packets: Rates from 128 packets-per-second to 16 seconds-per-packet.

    • Delay-Request/Delay-Response Packets: Rates from 128 packets-per-second to 16 seconds-per-packet.

    • Announce Packets: Rates from 8 packets-per-second to 64 packets-per-second.

  • Transport Mechanism: G.8265.1 profile only supports IPv4 PTP transport mechanism.

  • Mode: G.8265.1 profile supports transport of data packets only in unicast mode.

  • Clock Type: G.8265.1 profile only supports Ordinary Clock-type (a clock with only one PTP port).

  • Domain Numbers: The domain numbers that can be used in a G.8265.1 profile network ranges from 4 to 23. The default domain number is 4.

  • Port Numbers: All PTP port numbers can only be one (1) because all clocks in this profile network are Ordinary Clocks.

G.8265.1 profile defines an alternate algorithm to select between different master clocks based on the local priority given to each master clock and their quality levels (QL). This profile also defines Packet Timing Signal Fail (PTSF) conditions to identify the master clocks that do not qualify for selection. They are:

  • PTSF-lossSync condition: Raised for master clocks that do not receive a reliable stream of Sync and Delay-Resp messages. Cisco IOS XR software requests Sync and Delay-Resp grants for each configured master clock to track the master clock with this condition.

  • PTSF-lossAnnounce condition: Raised for master clocks that do not receive a reliable stream of Announce messages.

  • PTSF-unusable condition: Raised for master clocks that receives a reliable stream of Announce, Sync, and Delay-Resp messages, but not usable by slave clocks. Cisco IOS XR software does not use this condition.

G.8275.1

G.8275.1 profile fulfills the time-of-day and phase synchronization requirements in telecom networks with all network devices participating in the PTP protocol. G.8275.1 profile provides better frequency stability for the time-of-day and phase synchronization.

Features of G.8275.1 profile are:

  • Synchronization Model: G.8275.1 profile adopts hop-by-hop synchronization model. Each network device in the path from master to slave synchronizes its local clock to upstream devices and provides synchronization to downstream devices.

  • Clock Selection: G.8275.1 profile also defines an alternate BMCA that selects a clock for synchronization and port state for the local ports of all devices in the network is defined for the profile. The parameters defined as a part of the BMCA are:

    • Clock Class

    • Clock Accuracy

    • Offset Scaled Log Variance

    • Priority 2

    • Clock Identity

    • Steps Removed

    • Port Identity

    • notSlave flag

    • Local Priority

  • Port State Decision: The port states are selected based on the alternate BMCA algorithm. A port is configured to a master-only port state to enforce the port to be a master for multicast transport mode.

  • Packet Rates: The nominal packet rate for Announce packets is 8 packets-per-second and 16 packets-per-second for Sync/Follow-Up and Delay-Request/Delay-Response packets.

  • Transport Mechanism: G.8275.1 profile only supports Ethernet PTP transport mechanism.

  • Mode: G.8275.1 profile supports transport of data packets only in multicast mode. The forwarding is done based on forwardable or non-forwardable multicast MAC address.

  • Clock Type: G.8275.1 profile supports the following clock types:

    • Telecom Grandmaster (T-GM): Provides timing for other network devices and does not synchronize its local clock to other network devices.

    • Telecom Time Slave Clock (T-TSC): A slave clock synchronizes its local clock to another PTP clock, but does not provide PTP synchronization to any other network devices.

    • Telecom Boundary Clock (T-BC): Synchronizes its local clock to a T-GM or an upstream T-BC clock and provides timing information to downstream T-BC or T-TSC clocks.

  • Domain Numbers: The domain numbers that can be used in a G.8275.1 profile network ranges from 24 to 43. The default domain number is 24.

The G.8275.1 supports the following:

  • T-GM: The telecom grandmaster (T-GM) provides timing to all other devices on the network. It does not synchronize its local clock with any other network element other than the Primary Reference Time Clock (PRTC).

  • T-BC: The telecom boundary clock (T-BC) synchronizes its local clock to a T-GM or an upstream T-BC, and provides timing information to downstream T-BCs or T-TSCs. If at a given point in time there are no higher-quality clocks available to a T-BC to synchronize to, it may act as a grandmaster.

  • T-TSC: The telecom time slave clock (T-TSC) synchronizes its local clock to another PTP clock (in most cases, the T-BC), and does not provide synchronization through PTP to any other device.

The following figure describes a sample G.8275.1 topology.

Figure 1. A Sample G.8275.1 Topology

G.8275.2

Table 5. Feature History Table

Feature Name

Release Information

Description

ITU-T G.8275.2 and Default PTP profiles over IPv6

 Release 7.8.1

For ITU-T G.8275.2 and the IEEE 1588 default PTP profiles, the encapsulation type for PTP packet transport is now extended to IPv6.

This feature modifies the transport command to include the keyword ipv6 .

The G.8275.2 is a PTP profile for use in telecom networks where phase or time-of-day synchronization is required. It differs from G.8275.1 in that it is not required that each device in the network participates in the PTP protocol. Also, G.8275.2 uses PTP over IPv4 in unicast mode.

Effective Cisco IOS XR Software Release 7.8.1, the G.8275.2 is capable of using PTP over IPv6 as well. You can now use the transport ipv6 command to set this encapsulation type.

The G.8275.2 profile is based on the partial timing support from the network. Hence nodes using G.8275.2 are not required to be directly connected.

The G.8275.2 profile is used in mobile cellular systems that require accurate synchronization of time and phase. For example, the fifth generation (5G) of mobile telecommunications technology.


Note

G.8275.2 profile is supported on Cisco NCS 5500 Series Routers. However, the performance standards of this profile is not aligned with any of the ITU-T standards because performance specifications for G.8275.2 profile has not yet been made available by ITU-T.

For more information on hardware that supports G.8275.2 profile configurations, refer to Supported Hardware section in this chapter.

Features of G.8275.2 profile are:

  • Clock Selection: G.8275.2 profile also defines an alternate BMCA that selects a clock for synchronization and port state for the local ports of all devices in the network is defined for the profile. The parameters defined as a part of the BMCA are:

    • Clock Class

    • Clock Accuracy

    • Offset Scaled Log Variance

    • Priority 2

    • Clock Identity

    • Steps Removed

    • Port Identity

    • notSlave flag

    • Local Priority


    Note

    See ITU-T G.8275.2 document to determine the valid values for Clock Class parameter.

  • Port State Decision: The port states are selected based on the alternate BMCA algorithm. A port is configured to a master-only port state to enforce the port to be a master for unicast transport mode.

  • Packet Rates:

    • Synchronization/Follow-Up—minimum is one packet-per-second and maximum of 128 packets-per-second.

    • Packet rate for Announce packets—minimum of one packet-per-second and maximum of eight packets-per-second.

    • Delay-Request/Delay-Response packets—minimum is one packet-per-second and maximum of 128 packets-per-second

  • Transport Mechanism: G.8275.2 profile supports only IPv4 PTP transport mechanism.

  • Mode: G.8275.2 profile supports transport of data packets only in unicast mode.

  • Clock Type: G.8275.2 profile supports the following clock types:

    • Telecom Grandmaster (T-GM): Provides timing for other network devices and does not synchronize its local clock to other network devices.

    • Telecom Time Slave Clock (T-TSC): A slave clock synchronizes its local clock to another PTP clock, but does not provide PTP synchronization to any other network devices.

    • Telecom Boundary Clock (T-BC): Synchronizes its local clock to a T-GM or an upstream T-BC clock and provides timing information to downstream T-BC or T-TSC clocks.

  • Domain Numbers: The domain numbers that can be used in a G.8275.2 profile network ranges from 44 to 63. The default domain number is 44.

Configure PTP

Precision Time Protocol (PTP) is a protocol that defines a method to distribute time around a network. PTP support is based on the IEEE 1588-2008 standard.

This module describes the tasks you need to configure PTP on Cisco IOS XR software.


Note
When a subinterface is configured with encapsulation default or untag configuration, you must configure PTP on that subinterface, instead of the main interface.

Configure Global G.8275.1 Profile

This below configuration describes the steps involved to create a global configuration profile for a PTP interface that can then be assigned to any interface as required. It uses G.8275.1 profile as an example:


Note

Prior to Cisco IOS XR Software Release 6.3.3, the default PTP timers for G2875.1 were not set to standard values. This could lead to interoperability issues with other routers running the timers with updated values. Hence, to prevent such issues arising due to difference in packet rates, you must explicitly configure the announce interval value to 8, sync frequency value to 16 and delay-request frequency value to 16 while configuring global g.2875.1 profile. 


RP/0/RP0/CPU0:router# config terminal
RP/0/RP0/CPU0:router(config)# ptp
RP/0/RP0/CPU0:router(config-ptp)# clock
RP/0/RP0/CPU0:router(config-ptp-clock)# domain 24
RP/0/RP0/CPU0:router(config-ptp-clock)# profile g.8275.1 clock-type T-BC
RP/0/RP0/CPU0:router(config-ptp-clock)# exit
RP/0/RP0/CPU0:router(config-ptp)# profile slave
RP/0/RP0/CPU0:router(config-ptp-profile)# multicast target-address ethernet 01-1B-19-00-00-00
RP/0/RP0/CPU0:router(config-ptp-profile)# transport ethernet
RP/0/RP0/CPU0:router(config-ptp-profile)# sync frequency 16
RP/0/RP0/CPU0:router(config-ptp-profile)# announce frequency 8
RP/0/RP0/CPU0:router(config-ptp-profile)# delay-request frequency 16
RP/0/RP0/CPU0:router(config-ptp-profile)# exit
RP/0/RP0/CPU0:router(config-ptp)# profile master
RP/0/RP0/CPU0:router(config-ptp-profile)# multicast target-address ethernet 01-1B-19-00-00-00
RP/0/RP0/CPU0:router(config-ptp-profile)# transport ethernet
RP/0/RP0/CPU0:router(config-ptp-profile)# sync frequency 16
RP/0/RP0/CPU0:router(config-ptp-profile)# announce frequency 8
RP/0/RP0/CPU0:router(config-ptp-profile)# delay-request frequency 16
RP/0/RP0/CPU0:router(config-ptp-profile)# exit
RP/0/RP0/CPU0:router(config-ptp)# physical-layer-frequency
RP/0/RP0/CPU0:router(config-ptp)# log
RP/0/RP0/CPU0:router(config-ptp-log)# servo events
RP/0/RP0/CPU0:router(config-ptp-log)# commit

Verification

To display the configured PTP profile details, use show run ptp command. 


RP/0/RP0/CPU0:router# show run ptp 
   
Wed Feb 28 11:16:05.943 UTC
ptp
 clock
  domain 24
  profile g.8275.1 clock-type T-BC
 !
 profile slave
  multicast target-address ethernet 01-1B-19-00-00-00
  transport ethernet
  sync frequency 16
  announce frequency 8
  delay-request frequency 16
 !
 profile master
  multicast target-address ethernet 01-1B-19-00-00-00
  transport ethernet
  sync frequency 16
  announce frequency 8
  delay-request frequency 16
 !
 physical-layer-frequency
 log
  servo events
!

Configure PTP Master Interface

The below configuration describes the steps involved to configure a PTP interface to be a Master.


RP/0/RP0/CPU0:router# configure terminal
RP/0/RP0/CPU0:router(config)# interface HundredGigE0/0/0/0
RP/0/RP0/CPU0:router(config-if)# ptp
RP/0/RP0/CPU0:router(config-if-ptp)# profile master
RP/0/RP0/CPU0:router(config-if-ptp)# port state master-only
RP/0/RP0/CPU0:router(config-if-ptp)# commit

Verification

To verify the port state details, use show run interface interface-name command. 


RP/0/RP0/CPU0:router# show run interface HundredGigE0/0/0/0
interface HundredGigE0/0/0/0
 ptp
  profile master
  port state master-only
!

Configure PTP Slave Interface

This procedure describes the steps involved to configure a PTP interface to be a Slave.


RP/0/RP0/CPU0:router# configure terminal
RP/0/RP0/CPU0:router(config)# interface HundredGigE0/0/0/1
RP/0/RP0/CPU0:router(config-if)# ptp
RP/0/RP0/CPU0:router(config-if-ptp)# profile slave
RP/0/RP0/CPU0:router(config-if-ptp)# port state slave-only
RP/0/RP0/CPU0:router(config-if-ptp)# commit

Verification

To verify the port state details, use show run interface interface-name command. 


RP/0/RP0/CPU0:router# show run interface HundredGigE0/0/0/1
interface HundredGigE0/0/0/1
 ptp
  profile slave
  port state slave-only
 !
!

Configure PTP Hybrid Mode

This procedure describes the steps involved to configure router in a hybrid mode. You configure hybrid mode by selecting PTP for phase and time-of-day (ToD) and another source for the frequency.


Note

  • G.8275.1 PTP profile supports only the hybrid mode. By default, the hybrid mode is used, regardless of the physical-layer-frequency configuration.

  • G.8275.2 PTP profile supports both hybrid mode and non-hybrid mode. By default, the non-hybrid mode is used. Hybrid mode is used only when the physical-layer-frequency is configured.

To configure PTP Hybrid mode:

  1. Configure Global Frequency Synchronization

    RP/0/RP0/CPU0:router(config)# frequency synchronization
RP/0/RP0/CPU0:router(config)# commit

  2. Configure Frequency Synchronization for an Interface. The time-of-day-priority setting specifies that SyncE to be used as a ToD source if there is no source available with a lower priority. 

    RP/0/RP0/CPU0:router(config)# interface GigabitEthernet 0/0/0/0
RP/0/RP0/CPU0:router(config-if)# frequency synchronization
RP/0/RP0/CPU0:router(config-if-freqsync)# selection input
RP/0/RP0/CPU0:router(config-if-freqsync)# time-of-day-priority 100
RP/0/RP0/CPU0:router(config-if-freqsync)# commit

  3. Configure Global PTP. To configure PTP as source for ToD, use ToD priority values in the range from 1 (highest priority) to 254 (lowest priority). Use frequency from the physical layer. 

    RP/0/RP0/CPU0:router(config)# ptp
RP/0/RP0/CPU0:router(config-ptp)# physical-layer-frequency
RP/0/RP0/CPU0:router(config-ptp)# time-of-day priority 1
RP/0/RP0/CPU0:router(config)# commit

  4. Configure PTP Interface. To enable this interface as a PTP Master, use master command in ptp-interface configuration mode. 

    RP/0/RP0/CPU0:router(config)# interface GigabitEthernet 0/0/0/2 
RP/0/RP0/CPU0:router(config-if)# ipv4 address 10.0.0.1/24
RP/0/RP0/CPU0:router(config-if)# ptp
RP/0/RP0/CPU0:router(config-if-ptp)# master ipv4 10.0.0.2 
RP/0/RP0/CPU0:router(config-if-ptp)# commit

Verifying PTP Hybrid Mode

RP/0/RP0/CPU0:router # show frequency synchronization selection

Tue Feb  6 06:34:17.627 UTC
Node 0/0/CPU0:
==============
Selection point: ETH_RXMUX (1 inputs, 1 selected)
  Last programmed 3d23h ago, and selection made 3d23h ago
  Next selection points
    SPA scoped    : None
    Node scoped   : None
    Chassis scoped: T0-SEL-B 1588-SEL
    Router scoped : None
  Uses frequency selection
  S  Input                     Last Selection Point         QL  Pri  Status
  == ========================  ========================  =====  ===  ===========
  1  GigabitEthernet0/0/0/2    n/a			 PRC      1  Available
Selection point: LC_TX_SELECT (1 inputs, 1 selected)
  Last programmed 3d23h ago, and selection made 3d23h ago
  Next selection points
    SPA scoped    : None
    Node scoped   : None
    Chassis scoped: None
    Router scoped : None
  Uses frequency selection
  Used for local line interface output
  S  Input                     Last Selection Point         QL  Pri  Status
  == ========================  ========================  =====  ===  ===========
  7  GigabitEthernet0/0/0/2    0/RP0/CPU0 T0-SEL-B 1       PRC    1  Available
Node 0/RP0/CPU0:
==============
Selection point: T0-SEL-B (3 inputs, 1 selected)
  Last programmed 1d00h ago, and selection made 00:36:33 ago
  Next selection points
    SPA scoped    : None
    Node scoped   : CHASSIS-TOD-SEL
    Chassis scoped: LC_TX_SELECT
    Router scoped : None
  Uses frequency selection
  Used for local line interface output
  S  Input                     Last Selection Point         QL  Pri  Status
  == ========================  ========================  =====  ===  ===========
1  GigabitEthernet0/0/0/2	0/0/CPU0 ETH_RXMUX 1       PRC    1  Locked
   PTP [0/RP0/CPU0]		n/a			   SEC  254  Available
   Internal0 [0/RP0/CPU0]	n/a			   SEC  255  Available

Selection point: 1588-SEL (2 inputs, 1 selected)
  Last programmed 3d23h ago, and selection made 00:36:33 ago
  Next selection points
    SPA scoped    : None
    Node scoped   : None
    Chassis scoped: None
    Router scoped : None
  Uses frequency selection
  S  Input		       Last Selection Point      QL     Pri  Status
  == ========================  ========================  =====  ===  ===========
  1  GigabitEthernet0/0/0/2    0/0/CPU0 ETH_RXMUX 1      PRC      1  Locked
     Internal0 [0/RP0/CPU0]    n/a		  	 SEC    255  Available

Selection point: CHASSIS-TOD-SEL (2 inputs, 1 selected)
  Last programmed 1d00h ago, and selection made 1d00h ago
  Next selection points
    SPA scoped    : None
    Node scoped   : None
    Chassis scoped: None
    Router scoped : None
PRC    1  Locked
SEC  255  Available
Last Selection Point
QL Pri Status
Uses time-of-day selection
S  Input		     Last Selection Point      Pri  Time  Status	
== ========================  ========================  ===  ====  ===========
  1  PTP [0/RP0/CPU0]          n/a		       100  Yes   Available
     GigabitEthernet0/0/0/2    0/RP0/CPU0 T0-SEL-B 1   100  No    Available

Configure PTP for SyncE and PTP Traceability

In the hybrid mode of operation, if the SyncE and PTP clocks are coming from separate nodes and are not traceable to each other, and if the offset between the clocks is high, then the PTP-receiver may fail to synchronize with the PTP-transmitter node.

Starting with Cisco IOS XR Release 24.4.1, a new command, synchronous-ethernet prefer-interface ptp-receiver is introduced in the global frequency-synchronisation mode to ensure traceability between the PTP and SyncE clocks.

If you configure this CLI, note these points:

  • A SyncE source among equal sources 1 is selected on the same interface on which PTP is selected by the router.

  • If the SyncE source on the PTP receiver interface is inferior (in terms of QL and user configured priority) than any other available SyncE source, then the SyncE source is selected using the default criteria (based on the ITU-T G.781 requirements).

  • In the event that the selected PTP source goes down or if the PTP source's quality degrades, the system may switch to another PTP source. In such case, use the synchronous-ethernet prefer-interface ptp-receiver command so that the SyncE source selection would also switch to the new PTP receiver interface. Here, the preferred switching of SyncE source to the new PTP receiver interface shall happen only if the new interface uses the same SyncE QL and the user configured priority as the previously selected interface.


Note

The router can monitor only limited number of interfaces for SyncE selection. The synchronous-ethernet prefer-interface ptp-receiver command selects a SyncE source from the PTP receiver interface only if the interface is part of the list displayed using the show frequency synchronization selection command.

This example shows how to configure the synchronous-ethernet prefer-interface ptp-receiver command. 

RP/0/RP0/CPU0:router(config)# frequency synchronization synchronous-ethernet prefer-interface ptp-receiver
RP/0/RP0/CPU0:router(config)# commit

This example verifies the synchronous-ethernet prefer-interface ptp-receiver configuration. 

RP/0/RP0/CPU0:router(config)# show running-config frequency synchronization
Thu Aug 8 04:50:13.638 UTC
frequency-synchronization
 synchronous-ethernet prefer-interface ptp-receiver
!

Configure PTP for SyncE and PTP Traceability

In the hybrid mode of operation, if the SyncE and PTP clocks are coming from separate nodes and are not traceable to each other, and if the offset between the clocks is high, then the PTP-receiver may fail to synchronize with the PTP-transmitter node.

Starting with Cisco IOS XR Release 24.4.1, a new command, synchronous-ethernet prefer-interface ptp-receiver is introduced in the global frequency-synchronisation mode to ensure traceability between the PTP and SyncE clocks.

If you configure this CLI, note these points:

  • A SyncE source among equal sources 2 is selected on the same interface on which PTP is selected by the router.

  • If the SyncE source on the PTP receiver interface is inferior (in terms of QL and user configured priority) than any other available SyncE source, then the SyncE source is selected using the default criteria (based on the ITU-T G.781 requirements).

  • In the event that the selected PTP source goes down or if the PTP source's quality degrades, the system may switch to another PTP source. In such case, use the synchronous-ethernet prefer-interface ptp-receiver command so that the SyncE source selection would also switch to the new PTP receiver interface. Here, the preferred switching of SyncE source to the new PTP receiver interface shall happen only if the new interface uses the same SyncE QL and the user configured priority as the previously selected interface.


Note

The router can monitor only limited number of interfaces for SyncE selection. The synchronous-ethernet prefer-interface ptp-receiver command selects a SyncE source from the PTP receiver interface only if the interface is part of the list displayed using the show frequency synchronization selection command.

This example shows how to configure the synchronous-ethernet prefer-interface ptp-receiver command. 

RP/0/RP0/CPU0:router(config)# frequency synchronization synchronous-ethernet prefer-interface ptp-receiver
RP/0/RP0/CPU0:router(config)# commit

This example verifies the synchronous-ethernet prefer-interface ptp-receiver configuration. 

RP/0/RP0/CPU0:router(config)# show running-config frequency synchronization
Thu Aug 8 04:50:13.638 UTC
frequency-synchronization
 synchronous-ethernet prefer-interface ptp-receiver
!

Configure PTP Telecom Profile Interface

This procedure describes the steps involved to create an interface for PTP ITU-T Telecom Profiles.


Note

  • It is also possible to make these definitions within a global PTP profile and attach them to the interface using the profile command in PTP interface configuration mode.

  1. To configure an interface, use interface type interface-path-id command in the configuration mode. 

    
 RP/0/RP0/CPU0:router(config)# interface gigabitethernet 0/1/0/1

  2. To enter the PTP configuration mode for the given interface, use ptp command in the interface configuration mode. 

    
 RP/0/RP0/CPU0:router(config-if)# ptp

  3. To configure a PTP profile (or specify a previously defined profile), use profile name command in the ptp-interface configuration mode.


    Note
    Any additional commands entered in ptp-interface configuration mode overrides the global profile settings. 
    
RP/0/RP0/CPU0:router(config-if-ptp)# profile slave

  4. To configure frequency for Sync or Delay-request messages for the given ptp interface, use sync frequency rate command or delay-request frequency rate command appropriately in the ptp-interface configuration mode. The valid configurable values are 2, 4, 8, 16, 32, 64 or 128. 

    
RP/0/RP0/CPU0:router(config-if-ptp)# sync frequency 128
    
RP/0/RP0/CPU0:router(config-if-ptp)# delay-request frequency 128

  5. To configure duration for different PTP messages, use one of the following commands in the ptp-interface configuration mode: announce grant-duration duration , sync grant-duration duration , or delay-response grant-duration duration . The duration value can be between 60 and 1000 seconds.


    Note
    This duration value represents the length of grant that is requested by a port in Slave state and represents the maximum grant-duration allowed when the port is in Master state. 
    
RP/0/RP0/CPU0:router(config-if-ptp)# announce grant-duration 120
    
RP/0/RP0/CPU0:router(config-if-ptp)# sync grant-duration 120
    
RP/0/RP0/CPU0:router(config-if-ptp)# delay-response grant-duration 120

  6. To configure a timeout value, length of time by when a PTP message must be received (before PTSF-lossSync is raised), use one of the following commands in the ptp-interface configuration mode: sync timeout timeout or delay-response timeout timeout . The timeout value can be between 100 to 10000 micro seconds. 

    
RP/0/RP0/CPU0:router(config-if-ptp)# sync timeout 120
    
RP/0/RP0/CPU0:router(config-if-ptp)# delay-response timeout 120

  7. To configure a response for unicast-grant invalid-request, use unicast-grant invalid-request {reduce | deny} command. The response for requests with unacceptable parameters would either be denied or granted with reduced parameters. 

    RP/0/RP0/CPU0:router(config-if-ptp)# unicast-grant 
invalid-request reduce

  8. To configure IPv4 address for a PTP master, use master ipv4 ip-address command in the ptp-interface configuration mode. 

    RP/0/RP0/CPU0:router(config-if-ptp)# master ipv4 1.7.1.2

  9. To override the clock-class received in Announce messages from the specified Master, use clock-class class command in the ptp-master-interface configuration mode. The class values can range from 0 to 255. 

    RP/0/RP0/CPU0:router(config-if-ptp-master)# clock-class 2

Verification

To display the PTP interface details, use show ptp interfaces brief command. 


RP/0/RP0/CPU0:router# show ptp interfaces brief
Fri Feb  9 11:16:45.248 UTC
Intf              Port         Port                  Line
Name              Number       State        Encap    State         Mechanism
--------------------------------------------------------------------------------
Gi0/1/0/0         1            Slave        IPv4     up            1-step DRRM
Gi0/0/0/40        2            Master       IPv4     up            1-step DRRM

To verify the configured profile details, use show run interface interface-name command. 


RP/0/RP0/CPU0:router# show run interface Gi0/0/0/33 

Wed Feb 28 11:49:16.940 UTC
interface GigabitEthernet0/0/0/33
ptp
  profile slave
  transport ipv4
  sync frequency 64
  clock operation one-step
  delay-request frequency 64
  !
 physical-layer-frequency
!
ipv4 address 21.1.1.2 255.255.255.0
frequency synchronization
  selection input
  priority 5
  wait-to-restore 0
!

Configure PTP Telecom Profile Clock

This procedure describes the steps involved to configure PTP clock and its settings to be consistent with ITU-T Telecom Profiles for Frequency.

  1. To enter the PTP configuration mode, use ptp command in the configuration mode. 

    
 RP/0/RP0/CPU0:router(config)# ptp

  2. To enter the PTP-clock configuration mode, use clock command in the ptp-configuration mode. 

    
 RP/0/RP0/CPU0:router(config-ptp)# clock

  3. To configure the domain-number for a PTP profile, use domain number command in the ptp-configuration mode. The allowed domain number range for G.8265.1 profile is between 4 and 23 and the range for G.8275.1 profile is between 24 and 43. 

    
 RP/0/RP0/CPU0:router(config-ptp)# domain 24

  4. To exit the ptp-clock configuration mode, use exit command. 

    
RP/0/RP0/CPU0:router(config-ptp-clock)# exit

  5. To configure the desired telecom profile and the clock type for the profile, use clock profile {g.8275.1 | g.8275.2} clock-type {T-GM | T-BC | T-TSC} command in the ptp configuration mode. For g.8265.1 clock profile, clock type is either master or slave.


    Note
    The clock-selection telecom-profile and clock-advertisement telecom-profile commands are deprecated from Release 6.1.2. They are replaced by the clock profile command. 
    
RP/0/RP0/CPU0:router(config-ptp)# clock profile g.8275.1 clock-type T-GM

Verification

To display the configured PTP clock profile details, use show run ptp command. 


RP/0/RP0/CPU0:router# show run ptp 
ptp
clock
  domain 24
  profile g.8275.1 clock-type T-GM
  timescale PTP
  time-source GPS
  clock-class 6
!
profile master
  transport ethernet
  sync frequency 16
  announce interval 1
  delay-request frequency 16
!
profile master1
  transport ethernet
  sync frequency 64
  announce interval 1
  delay-request frequency 64
!

To verify that PTP has been enabled on the router and the device is in LOCKED Phase, use show ptp platform servo command. 

RP/0/RP0/CPU0:router # show ptp platform servo

Fri Feb  9 11:16:54.568 UTC
Servo status: Running
Servo stat_index: 2
Device status: PHASE_LOCKED
Servo log level: 0
Phase Alignment Accuracy: 1 ns
Sync timestamp updated: 111157
Sync timestamp discarded: 0
Delay timestamp updated: 111157
Delay timestamp discarded: 0
Previous Received Timestamp T1: 1518155252.263409770  T2: 1518155252.263410517  T3: 1518155252.287008362  T4: 1518155252.287009110 
Last Received Timestamp T1: 1518155252.325429435  T2: 1518155252.325430194  T3: 1518155252.348938058  T4: 1518155252.348938796 
Offset from master:  0 secs, 11 nsecs
Mean path delay   :  0 secs, 748 nsecs
setTime():2  stepTime():1  adjustFreq():10413 adjustFreqTime():0
Last setTime: 1.000000000 flag:1  Last stepTime:-736216, Last adjustFreq:465

Configure PTP Delay Asymmetry

Table 6. Feature History Table

Feature Name

Release Information

Description

PTP Delay Asymmetry

Release 7.3.1

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

  • If you configure multiple PTP delay asymmetries for the same PTP profile, the latest PTP delay asymmetry that you configure is applied to the PTP profile.

  • For G8275.1 and G8275.2 PTP profiles, PTP delay asymmetry is supported for both, client port and dynamic port that act as a client.

  • Fixed delay can be measured by using any test and measurement tool. Fixed delay can be compensated by using the positive or negative values. For example, if the fixed delay is +10 nanoseconds, configure -10 nanoseconds to compensate the fixed delay.

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:

  1. Configure an interface with PTP.

  2. 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)# commit

Running Configuration

interface preconfigure HundredGigE 0/1/0/0
 ptp
  delay-asymmetry 3 microseconds

Verification

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: 1

To 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

Performance Monitoring for PTP Networks

Table 7. Feature History Table

Feature Name

Release Information

Feature Description

Performance Monitoring

 Release 24.3.1

Introduced in this release on: NCS 5500 fixed port routers

You can now get statistical information with Performance Monitoring in PTP networks, such as clock accuracy, synchronization status, and network delays by defining Performance Monitoring Parameters and Port Specific Parameters.

This feature empowers operators with comprehensive performance monitoring and precise time-stamp analysis, offering enhanced granularity for time synchronization in telecommunication networks. By providing detailed insights, it enables operators to make well-informed decisions and take proactive actions to ensure optimal network performance.

The feature introduces these changes:

CLI:

  • performance-monitoring

  • show ptp platform performance-counters

  • show ptp dataset performance

YANG Data Models:

  • Cisco-IOS-XR-ptp-cfg.yang

  • Cisco-IOS-XR-ptp-oper.yang

  • Cisco-IOS-XR-um-ptp-cfg.yang

(see GitHub, YANG Data Models Navigator)

Performance Monitoring in PTP involves tracking and analyzing the performance of PTP networks to ensure accurate time synchronization across devices. This includes monitoring various metrics such as clock accuracy, synchronization status, and network delays. The goal is to identify and address any issues that may affect the precision and reliability of time synchronization in the network.

Performance Monitoring now has the ability to provide performance monitoring and time-stamp analysis information in a PTP network as per Annex J IEEE 1588-2019. This feature also includes additional monitoring granularity for time synchronization in telecommunication networks as per Annex F from the G8275 standard. For more information on PTP, Best TimeTransmitter Clock Algorithm (BTCA), see PTP Overview.

You can use the following parameters to define the Performance Monitoring in a PTP Network:

  • Performance Monitoring Parameters

  • Port Specific Parameters

Performance Monitoring Parameters

In addition to using the timestamps received from the grandmaster to sync to the grandmaster’s clock, the timestamps can now be used to calculate parameters that are of your interest in performance monitoring:

  • TimeTransmitter - TimeReceiver Delay: corrected propagation time from TimeTransmitter to TimeReceiver.

  • TimeReceiver - TimeTransmitter Delay: corrected propagation time from TimeReceiver to TimeTransmitter.

  • Mean Path Delay: mean propagation time over the PTP Communication Path.

  • Offset from TimeTransmitter: time difference between a TimeTransmitter PTP instance and a TimeReceiver PTP instance as computed by the TimeReceiver PTP instance.

For each of these parameters, you can measure the average, minimum, maximum, and standard deviation for each measurement. These values are calculated and maintained for the following time intervals over the specified time periods:

  • 3-minute: maintained for the current 1-hour period.

  • 15-minute: maintained for the current 24-hour period.

  • 1-hour: maintained for the current 2-hour period.

  • 24-hour: maintained for the current 48-hour period.

The platform actively calculates the end-to-end latency between the TimeTransmitter and TimeReceiver through the Delay-Request-Response-Mechanism (DRRM), allowing Precision Time Protocol (PTP) to seamlessly operate across networks equipped with Transparent clocks, non-PTP aware switches, or a mix of both. Upon a request, PTP dynamically extracts these calculated values from the servo using a platform specific API, allowing you to make proactive changes to the network to ensure precise time synchronization essential for applications that depend on accurate timing.

Additional Port Specific Parameters

The parameters mentioned above apply to the entire Precision Time Protocol (PTP) instance, and there is an additional set of parameters specific to individual ports. These parameters include the counters for various packet types,

  • received (rx) and

  • transmitted (tx)

It is important to collect and maintain these counters for performance monitoring purposes, which follows the same time intervals and periods as those used for monitoring clock performance.

Port-specific parameters play a crucial role in ensuring accurate time synchronization. These packet types are essential for maintaining the accuracy and reliability of time synchronization in a PTP network:

  • Sync Packets: These packets are sent by the master clock to the slave clocks to synchronize their time. They contain the precise time at which the packet was sent.

  • Delay Request Packets: Sent by the slave clock to the master clock, these packets measure the delay between the master and slave clocks. The master clock responds with a Delay Response packet.

  • Follow-Up Packets: These packets are sent by the master clock immediately after the Sync packet. They contain the exact time the Sync packet was sent, which helps in correcting any delays introduced by the network.

  • Announce Packets: These packets are used by the master clock to announce its presence and capabilities to the slave clocks. They help in the selection of the best master clock in the network.

  • Management Packets: These packets are used for configuration and management purposes within the PTP network. They allow for the adjustment of various parameters and settings.

Record format

Record format refers to the structure or layout of data within a record, which is used to store information about time synchronization events and measurements. This format can include various fields such as timestamps, event types, and other relevant data that PTP uses to maintain accurate time synchronization across a network. It is a single buffer for both annexes.

The format is the same for both clock and port performance monitoring parameters that is presented in the operational data. The data is stored over a 48-hour period, resulting in a list of records as per Annex J 1588-2019, composed of the following:

  • 1 record for the current 15-minute set of statistics (stored at position 0 in the buffer).

  • 96 records for the 15-minute sets of statistics over the last 24-hour period (stored between positions 1-96 in the buffer).

  • 1 record for the current 24-hour set of statistics (stored at position 97 in the buffer).

  • 1 record for the previous 24-hour set of statistics (stored at position 98 in the buffer).

The data buffer records data at 3-minute intervals over the most recent 1-hour period, creating a list of records that includes:

  • 1 record for the current 3-minute set of statistics (stored at position 100 in the buffer).

  • 20 records for the 3-minute set of statistics over the last 1-hour period (stored between positions 101-120).

  • 1 record for the current 1-hour set of statistics (stored at position 121 in the buffer).

  • 1 record for the previous 1-hour set of statistics (stored at position 122 in the buffer).

Configure PTP Performance Monitoring

The purpose of this task is to configure and verify PTP performance monitoring.

Procedure

Step 1

Configure the performance-monitoring command to enable collection of performance monitoring statistics and for the users to make performance monitoring requests.

Example:


Router(config)# ptp
Router(config-ptp)# performance-monitoring
Router(config-ptp)# commit

Step 2

Run the sh ptp platform performance-counters command to display the details of all 123 records.

The existing command show ptp platform is extended to include the performance monitoring data for the local clock. The detail mode of the command displays all 123 records while the brief mode displays only the current windows for 15 minutes, 24 hours, 3minutes, and 1hour.

Example:


Router#sh ptp platform performance-counters detail 

PTP Current record index 15 min: 96
PTP Current record index 3 min: 119

PTP performance monitoring statistics: 
==============================================================================================================
15 min stats
[0]     12 August 2024 07:08:59 UTC 15 min statistics
--------------------------------------------------------------------------------------------------------------
                Stat    Min(sec.nsec)        Max(sec.nsec)       Mean(sec.nsec)     Std deviation           Samples
--------------------------------------------------------------------------------------------------------------
  Master-slave-delay -000000000.15937      000000000.333       -000000000.1780       000000000.71191      154       
  Slave-master-delay  000000000.319        000000000.16593      000000000.2437       000000000.74103      154       
     mean-path-delay  000000000.322        000000000.334        000000000.327        000000000.4057       154       
  offset-from-master -000000000.16263      000000000.6         -000000000.2108       000000000.72546      154       

--------------------------------------------------------------------------------------------------------------
            Complete      Valid      PmRef      ServoAtStart     ServoAtEnd          LastServoFlapTime
--------------------------------------------------------------------------------------------------------------
               FALSE      FALSE       TRUE        PHASE_LOCKED   HOLDOVER               12 Apr 2024 07:09:09 UTC 

==============

….

Step 3

Run the show ptp dataset performance clock command to display the performance monitoring data-set details in 15 minutes intervals.

Example:


Router#show ptp dataset performance clock

performanceMonitoringDS for the current 15-minute window:
Clock ID ccccfffecccc00, steps removed 1, receiving-port 2:
    Start of time window: Thursday, April 11, 2024 14:18:59
    Measurement is valid
    Period is complete
    Measurement has been taken with reference to system clock
    Master slave delay:
        Average: 50ns
        Min: 50ns
        Max: 70ns
        Std: 1ns
    Slave master delay:
        Average: 51ns
        Min: 51ns
        Max: 71ns
        Std: 2ns
    Mean path delay:
        Average: 52ns
        Min: 52ns
        Max: 72ns
        Std: 3ns
    Offset from master:
        Average: 53ns
        Min: 53ns
        Max: 73ns
        Std: 4ns

Clock ID aaaabbbecccc00, steps removed 1, receiving-port 2:
    Start of time window: Thursday, April 11, 2024 14:18:59
    Measurement is not valid
    Period is not complete
    Measurement has been taken with reference to system clock
    Master slave delay:
        Average: 50ns
        Min: 50ns
        Max: 70ns
        Std: 1ns
    Slave master delay:
        Average: 51ns
        Min: 51ns
        Max: 71ns
        Std: 2ns
    Mean path delay:
        Average: 52ns
        Min: 52ns
        Max: 72ns
        Std: 3ns
    Offset from master:
        Average: 53ns
        Min: 53ns
        Max: 73ns
        Std: 4ns

Step 4

Run the show ptp dataset performance port to display the Performance Monitoring Port Data-set in 15 minutes intervals.

Example:

Router#show ptp dataset performance port GigabitEthernet 0/0/0/1

performanceMonitoringPortDS for the current 15-minute window:
Interface GigabitEthernet 0/0/0/1
    Start of time window: Thursday, April 11, 2024 14:18:59
    Measurement is valid
    Period is not complete
    Measurement has been taken with reference to system clock
    Packets                     Sent        Received         Dropped
    ----------------------------------------------------------------
    Announce                       3              83              11
    Sync                           0              32               5
    Follow-Up                      0              31               0
    Delay-Req                     22               0               0
    Delay-Resp                     0              21               7
    Pdelay-Req                     0               7               0
    Pdelay-Resp                    0               0               0
    Pdelay-Resp-Follow-Up          0               0               0
    Signaling                      2               1               0
    Management                     0               0               0
    Other                          0               3              12
                               -----           -----           -----
    TOTAL                         27             178              35

Configuration Examples

Slave Configuration Example

The following example shows a PTP slave configuration: 


 interface TenGigE 0/1/0/5
 ptp
  profile slave
  transport ipv4
  port state slave-only
  master ipv4 1.7.1.2
  !
  announce interval 1
  !
 ipv4 address 1.7.1.1 255.255.255.0
!

Master Configuration Example

This example shows a PTP master configuration: 


 ptp
  profile master
  transport ipv4
  announce interval 1
 !
 ipv4 address 1.7.1.2 255.255.255.0
 !

PTP Hybrid Mode Configuration Example

This example shows the configuration of PTP hybrid mode: 


ptp
 time-of-day priority 10
 !
interface GigabitEthernet0/1/1/0
 ptp
  transport ipv4
  port state slave-only
  master ipv4 1.7.1.2
  !
  sync frequency 64
  announce interval 1
  delay-request frequency 64
 !
interface GigabitEthernet 0/1/0/1
 ipv4 address 1.7.1.2 255.255.255.0
 speed 100
 frequency synchronization
  selection input
  priority 10
  wait-to-restore 0
  ssm disable
  time-of-day-priority 100
 !

ITU-T Telecom Profile Examples:

G.8265.1 Profile Configuration Examples

Master Global Configuration:


ptp
 clock
 domain 4
 profile g.8265.1
 !
  profile master
  transport ipv4
  sync frequency 16
  announce interval 1
  delay-request frequency 16
interface gi 0/2/0/4
 ptp
  profile master
  transport ipv4
  clock operation two-step
 !
 ipv4 address 17.1.1.1/24

Slave Global Configuration: 


ptp
 clock
 domain 4
 profile g.8265.1
 !
  profile slave
  transport ipv4
  sync frequency 16
  announce interval 1
  delay-request frequency 16
interface gi 0/1/0/0
 ptp
  profile slave
  transport ipv4
  Master ipv4 18.1.1.1
  port state slave-only
  !
  clock operation two-step
  !
 ipv4 address 18.1.1.2/24

Configuring With Clock Type as T-Boundary Clock (T-BC)


ptp
 clock
 domain 4
 profile g.8265.1
 !
  profile master
  transport ipv4
  sync frequency 16
  announce interval 1
  delay-request frequency 16
  exit
  profile slave
  transport ipv4
  sync frequency 16
  announce interval 1
  delay-request frequency 16
  exit
interface gi 0/2/0/4
 ptp
  profile slave
  transport ipv4
  Master ipv4 17.1.1.1
  port state slave-only
  !
  clock operation two-step
  !
ipv4 address 17.1.1.2/24
interface gi 0/2/0/0
 ptp
  profile master
  transport ipv4
  clock operation two-step
  !
 ipv4 address 18.1.1.1/24

G.8275.1 Profile Configuration Examples


Note

The Sync 2 port and GNSS receiver configuration listed below are not supported simultaneously for network synchronization. Choose only one synchronization method at a time.

Master Global Configuration:


ptp
 clock
 domain 24
 profile g.8275.1 	
 !
  profile master
  transport ethernet
  sync frequency 16
  announce frequency 8
  delay-request frequency 16
interface gi 0/2/0/4
 ptp
  profile master
  transport ethernet
  multicast target-address ethernet 01-1B-19-00-00-00
  !

Slave Global Configuration: 


ptp
 clock
 domain 24
 profile g.8275.1 clock-type T-TSC
 !
  profile slave
  transport ethernet
  sync frequency 16
  announce frequency 8
  delay-request frequency 16
interface gi 0/1/0/0
 ptp
  profile slave
  transport ethernet
  multicast target-address ethernet 01-1B-19-00-00-00
  !

Configuring With Clock Type as T-Boundary Clock (T-BC)



ptp
 clock
 domain 24
 profile g.8275.1 clock-type T-BC
 !
  profile master
  transport ethernet
  sync frequency 16
  announce frequency 8
  delay-request frequency 16
  exit
  profile slave
  transport ethernet
  sync frequency 16
  announce frequency 8
  delay-request frequency 16
  exit
interface gi 0/2/0/4
 ptp
  profile slave
  transport ethernet
  multicast target-address ethernet 01-1B-19-00-00-00
  !
interface gi 0/2/0/0
 ptp
  profile master
  transport ethernet
  multicast target-address ethernet 01-1B-19-00-00-00

G.8275.2 Profile Configuration Examples


Note

The Sync 2 port and GNSS receiver configuration listed below are not supported simultaneously for network synchronization. Choose only one synchronization method at a time.

Master Global Configuration:


ptp
 clock
  domain 44
  profile g.8275.2 clock-type T-GM
 !
 profile master
  transport ipv4
  sync frequency 64
  announce frequency 8
  unicast-grant invalid-request deny
  delay-request frequency 64
 !
!
 
interface GigabitEthernet0/2/0/11
 ptp
  profile master
 !
 ipv4 address 17.1.1.1/24

Slave Global Configuration: 


ptp
 clock
  domain 44
  profile g.8275.2 clock-type T-TSC
 !
 profile slave
  transport ipv4
  port state slave-only
  sync frequency 64
  announce frequency 8
  unicast-grant invalid-request deny
  delay-request frequency 64
 !
 log
  servo events
  best-master-clock changes
 !        
!
interface GigabitEthernet0/2/0/12
 ptp
  profile slave
  master ipv4 18.1.1.1 
  !
 !
 ipv4 address 18.1.1.2/24
!

Effective Cisco IOS XR Software Release 7.8.1, the encapsulation type for PTP packet transport is now extended to IPv6; you can now use the transport ipv6 to set this encapsulation type.

Configuring With Clock Type as T-Boundary Clock (T-BC)



ptp
 clock
  domain 44
  profile g.8275.2 clock-type T-BC
 !
 profile slave
  transport ipv4
  port state slave-only
  sync frequency 64
  announce frequency 8
  unicast-grant invalid-request deny
  delay-request frequency 64
 !
 profile master
  transport ipv4
  sync frequency 64
  announce frequency 8
  unicast-grant invalid-request deny
  delay-request frequency 64
 !
 log
  servo events
  best-master-clock changes
 !        
!

interface GigabitEthernet0/2/0/11
 ptp
  profile master
 !
 ipv4 address 18.1.1.1/24
!

interface GigabitEthernet0/2/0/12
 ptp
  profile slave
  master ipv4 17.1.1.1 
  !
 !
 ipv4 address 17.1.1.2/24
!

Effective Cisco IOS XR Software Release 7.8.1, the encapsulation type for PTP packet transport is now extended to IPv6; you can now use the transport ipv6 command to set this encapsulation type.

Monitor PTP virtual port using PTP timeReceiver ports

Table 8. Feature History Table

Feature Name

Release Information

Feature Description

Monitor PTP virtual port using PTP timeReceiver ports

Release 24.4.1

You can now configure a threshold value for the Time of Day (ToD) difference or offset between the PTP virtual port Global Navigation Satellite System (GNSS) and the time received by the timeReceiver ports. The timeReceiver ports receive the timing signal from remote timeTransmitters.

As part of the monitoring process, the servo mechanism in the router routinely calculates the ToD offset between the GNSS receiver and the best PTP timeTransmitter. When the offset value exceeds the configured threshold, the router raises a syslog message. Based on the generated syslog message, you can determine if you should switch from the virtual port GNSS to selecting the PTP timeTransmitter as a fallback source.

Command introduced: gm-threshold-breach threshold_value

YANG data models:

  • Cisco-IOS-XR-ptp-cfg, version 3.2.0

  • Cisco-IOS-XR-um-ptp-cfg, version 2.0.0

  • Cisco-IOS-XR-ptp-oper, version 2.3.0

See (GitHub, Yang Data Models Navigator)

Monitor PTP virtual port using PTP timeReceiver ports

The router achieves redundancy by having a primary and secondary timing source. For example, it can receive timing signals from a primary source, such as the Global Navigation Satellite System (GNSS) receiver, and secondary sources like PTP timeTransmitters.

When configuring a PTP virtual port to receive the GNSS timing signal, the router initially considers it the optimal local timing source. To monitor the quality of the virtual port signal, the servo mechanism in the router routinely calculates the Time of Day (ToD) difference, or offset, between the GNSS and the best timeReceiver port. You can now configure a ToD offset threshold value for the PTP virtual port GNSS. Threshold refers to a predefined limit or value set for the ToD offset. The router enforces the configured threshold value upon the absolute measured offset value, without any relative adjustments or considerations. If the offset exceeds the threshold, known as a threshold breach, the router sends alarm notifications as syslog messages.

Threshold configuration

Suppose you intend to configure a threshold of 1000 ns for the virtual port that receives the GNSS signal. You must configure the command as shown in the example: 

Router(config-ptp-vp)#gm-threshold-breach 1000

Threshold breach

When the offset value exceeds the configured threshold value, it is referred to as a threshold breach. If the calculated offset value is 1100 ns, it exceeds the configured threshold. Upon detecting that the virtual port has breached the threshold value, the router sends a syslog message indicating a threshold breach. You can then analyze the syslog message and determine if you should switch from the virtual port GNSS to selecting the best PTP timeTransmitter as a fallback source.

The router enforces the configured threshold value of 1000 ns on the absolute measured offset value of 1100 ns, without any relative adjustments or considerations.

Sample syslog message

The alarm notification is sent as a syslog message, and it shows that the configured threshold value is 1000 ns. However, the offset value is 1100 ns, indicating a threshold breach. 

Time of day offset between virtual port and best foreign master clock aaaafffeaaaa00,
steps removed 1, receiving port 1, received on interface GigabitEthernet0/2/0/0 is 1100 ns,
configured threshold is 1000 ns. Raising virtual port offset alarm due to threshold breach.

Supported platforms

  • N540-ACC-SYS

  • N540X-ACC-SYS

  • N540-24Z8Q2C-SYS

Alarm conditions

The list provided explains the specific state or events that raise or clear the threshold alarm.

  • An alarm is raised when

    • the configured threshold is exceeded, for reasons such as changing the timeTransmitter.

    • a new threshold value that is lesser than the current offset is configured.

  • An alarm is cleared when

    • the offset value drops below the configured threshold.

    • the threshold value is unconfigured.

    • the virtual port is no longer the best source of timing for reasons such as configuration or clock rank change.

    • all timeTransmitters are lost.

Configure threshold to monitor PTP virtual port using PTP timeReceiver ports

Use this task to configure a threshold value to monitor the PTP Virtual Port using PTP timeReceiver timing sources.

Before you begin

Configure global SyncE and GNSS before you configure the virtual port. See the Configuration Example for more information.

Procedure

Step 1

Configure PTP.

Router(config)#ptp

Step 2

Configure the PTP virtual port.

Router(config-ptp)#virtual-port

Step 3

Configure the threshold for the PTP virtual port.

Router(config-ptp-vp)#gm-threshold-breach 1000

Note

 

The valid range is from 0 through 4,294,967,295 ns.

Configuration example

The example shows a Time-Based Clock (T-BC) consolidated configuration with Synchronous Ethernet (SyncE), GNSS, and PTP with the threshold value. 

T-BC (Middle Router Configurations)
Global SyncE Configuration
Router#configure terminal
Router(config)#frequency synchronization
Router(config-freqsync)#quality itu-t option 1
Router(config-freqsync)#clock-interface timing-mode system
Router(config-freqsync)#commit

Source GNSS Configuration
Router#configure terminal
Router(config)#gnss-receiver 0 location 0/rp0/cpu0
Router(config-gnss)#frequency synchronization
Router(config-gnss-freqsync)#selection input
Router(config-gnss-freqsync)#priority 20
Router(config-gnss-freqsync)#time-of-day-priority 100
Router(config-gnss-freqsync)#quality receive exact itu-t option 1 PRC
Router(config-gnss-freqsync)#commit

Virtual Port and Global PTP Configuration
Router#configure terminal
Router(config)#ptp
Router(config-ptp)#physical-layer-frequency
Router(config-ptp)#time-of-day priority 90
Router(config-ptp)#clock
Router(config-ptp-clock)#domain 24
Router(config-ptp-clock)#profile G.8275.1 clock-type T-BC
Router(config-ptp-clock)#time-source GPS
Router(config-ptp-clock)#timescale PTP
Router(config-ptp-clock)#virtual-port
Router(config-ptp-vp)#clock-accuracy 0x21
Router(config-ptp-vp)#clock-class 6
Router(config-ptp-vp)#local-priority 128
Router(config-ptp-vp)#priority2 50
Router(config-ptp-vp)#offset-scaled-log-variance 0x4e5d
Router(config-ptp-vp)#gm-threshold-breach 1000
Router(config-ptp-vp)#ptp
Router(config-ptp)#profile master
Router(config-ptp-profile)#transport ethernet
Router(config-ptp-profile)#sync frequency 16
Router(config-ptp-profile)#delay-req frequency 16
Router(config-ptp-profile)#announce frequency 8
Router(config-ptp-profile)#ptp
Router(config-ptp)#profile slave
Router(config-ptp-profile)#transport ethernet
Router(config-ptp-profile)#sync frequency 16
Router(config-ptp-profile)#delay-req frequency 16
Router(config-ptp-profile)#announce frequency 8
Router(config-ptp-profile)#commit
Interface Configuration
Router#configure terminal
Router(config)#interface HundredGigE0/0/1/1
Router(config-if)#ptp
Router(config-if-ptp)#profile slave
Router(config-if-ptp)#transport ethernet
Router(config-if-ptp)#local-priority 30
Router(config-if-ptp)#port state slave-only
Router(config-if-ptp)#clock operation one-step
Router(config-if-ptp)#multicast target-address ethernet 01-1B-19-00-00-00
Router(config-if-ptp)#frequency synchronization
Router(config-if-freqsync)#selection input
Router(config-if-freqsync)#priority 30
Router(config-if-freqsync)#wait-to-restore 0
Router(config-if-freqsync)#commit

Verify PTP virtual port using PTP timeReceiver ports

These commands show that the offset value is 900 ns for the virtual port. The offset value does not exceed the configured threshold value of 1000 ns. The offset value indicates no threshold breach, implying consistent timing between the GNSS receiver and the best timeReceiver port.

Before you begin

Use these show commands to verify that the offset does not exceed the configured threshold value. You can execute these commands as needed and do not have to follow a specific sequence.

Procedure

Step 1

Verify local PTP clock information.


RP/0/0/CPU0#show ptp local-clock
    Clock ID: ACDE48FFFE234567
    Clock properties:
       Domain: 0, Priority1: 7, Priority2: 83, Class: 7
       Accuracy: 0x2B, Offset scaled log variance: 0x27FF
       Time Source: GPS
       Timescale: PTP
       Frequency-traceable, Time-traceable
       Current UTC offset: 35 seconds
    Virtual Port:
       Configured: True, Connected: True
       Offset from PTP best foreign master: 900ns

If no timeTransmitters send timestamps, the show command displays:

Offset from PTP best foreign master: none qualified

Step 2

Verify the best timeReceiver clock information.

RP/0/0/CPU0:demo#show ptp foreign-masters best
    Used to set system frequency and time
    Ipv4, Address 1.2.3.4
    Received on interface GigabitEthernet0/2/0/3 (port number 0x1007)
    Clock ID: ACDE48FFFE234567
    Best foreign-master for 5 days, 4 hours, 27 minutes
    Advertised for 5 days, 4 hours, 20 minutes
 Offset from Virtual Port: 900ns
    Clock properties:
       Domain: 0, Priority1: 7, Priority2: 83, Class: 6
       Accuracy: 0x2B, Offset scaled log variance: 0x27FF
       Steps-removed: 5, Time Source: GPS, Timescale: PTP

If the virtual port is not configured or connected, the show command displays:

Offset from Virtual Port: not configured/not connected

If the servo cannot provide offset, the show command displays:

Offset from Virtual Port: unavailable

Step 3

Verify the timeReceiver clock information.

RP/0/0/CPU0:demo#show ptp foreign-masters 
    Used to set system frequency and time 
    Ipv4, Address 1.2.3.4 
    Received on interface GigabitEthernet0/2/0/3 (port number 0x1007) 
    Clock ID: ACDE48FFFE234567  
        Advertised for 5 days, 4 hours, 20 minutes 
    Offset from Virtual Port: 900ns 
    Received Clock properties:  
       Domain: 0, Priority1: 7, Priority2: 83, Class: 6 
       Accuracy: 0x2B, Offset scaled log variance: 0x27FF 
       Steps-removed: 5, Time Source: GPS, Timescale: PTP

If the virtual port is not configured or connected, the show command displays:

Offset from Virtual Port: not configured/not connected

If the servo cannot provide offset, the show command displays:

Offset from Virtual Port: unavailable

Step 4

Verify the generated syslog.

Router#show logging
Router:Sep 21 06:42:39.995 UTC: ptp_ctrlr[1081]: %L2-PTP-4-VIRTUAL_PORT_OFFSET_EXCEEDED : Time of day offset between virtual port
and best foreign master clock aaaafffeaaaa00, steps removed 1, receiving port 1, 
received on interface GigabitEthernet0/2/0/0 is 1100 ns, 
configured threshold is 1000 ns. Raising virtual port offset alarm due to threshold breach.

Restriction to monitor PTP virtual port using PTP timeReceiver ports

The main restriction to consider while enforcing the threshold:

  • The threshold is only enforced on the best timeReceiver, even when the offset is reported for multiple timeReceivers.

Configure E-SyncE on Primary and Secondary Interface

Primary Interface

The following example shows how you can configure global synce on primary interface:

Router#configure terminal 
Router(config)#frequency synchronization 
Router(config-freqsync)#quality itu-t option 1
Router(config-freqsync)#clock-identity mac-address aaaa.bbbb.cccc
Router(config-freqsync)#clock-interface timing-mode system 
Router(config-freqsync)#commit

The following example shows how you can configure synce on primary interface:

Router#configure terminal 
Router(config)# interface HundredGigE0/0/0/11
Router(config-if)# frequency synchronization
Router(config-if)# quality transmit exact itu-t option 1 ePRTC
Router(config-if)# commit

Secondary Interface

The following example shows how you can configure global synce on secondary interface:

Router#configure terminal 
Router(config)#frequency synchronization 
Router(config-freqsync)#quality itu-t option 1
Router(config-freqsync)#clock-interface timing-mode system 
Router(config-freqsync)#commit

The following example shows how you can configure synce on secondary interface:

Router#configure terminal
Router(config)# interface HundredGigE0/0/0/10
Router(config-if)# frequency synchronization
Router(config-if-freqsync)# selection input
Router(config-if-freqsync)# priority 10
Router(config-if-freqsync)# wait-to-restore 0
Router(config-if-freqsync)# commit

Note

If timing mode system is not configured, the major alarm T4 PLL is in FREERUN mode is raised. This alarm has no functional impact to the system behavior.

Verification

Use the show frequency synchronization command if e-synce is configured. 

Routerr#show frequency synchronization  interfaces  br
Flags:  > - Up                D - Down              S - Assigned for selection
        d - SSM Disabled      x - Peer timed out    i - Init state
        s - Output squelched
Fl   Interface                QLrcv QLuse Pri QLsnd Output driven by
==== ======================== ===== ===== === ===== ========================
>S   HundredGigE0/0/0/13      ePRTC ePRTC  31 ePRTC HundredGigE0/0/0/18     
>S   HundredGigE0/0/0/18      ePRTC ePRTC  30 DNU   HundredGigE0/0/0/18     
RP/0/RP0/CPU0:Shadowtower#sh frequency  synchronization  selection 
Node 0/RP0/CPU0:
==============
Selection point: T0-SEL-B (3 inputs, 1 selected)
  Last programmed 02:41:55 ago, and selection made 02:41:04 ago
  Next selection points
    SPA scoped    : None
    Node scoped   : CHASSIS-TOD-SEL
    Chassis scoped: LC_TX_SELECT
    Router scoped : None
  Uses frequency selection
  Used for local line interface output
  Used for local clock interface output
  S  Input                     Last Selection Point         QL  Pri  Status
  == ========================  ========================  =====  ===  ===========
  33 HundredGigE0/0/0/18       0/RP0/CPU0 ETH_RXMUX 33   ePRTC   30  Locked     
     HundredGigE0/0/0/13       0/RP0/CPU0 ETH_RXMUX 22   ePRTC   31  Available  
     Internal0 [0/RP0/CPU0]    n/a                         SEC  255  Available  

Selection point: 1588-SEL (3 inputs, 1 selected)
  Last programmed 02:41:55 ago, and selection made 02:41:04 ago
  Next selection points
    SPA scoped    : None
    Node scoped   : None
    Chassis scoped: None
    Router scoped : None
  Uses frequency selection
  S  Input                     Last Selection Point         QL  Pri  Status
  == ========================  ========================  =====  ===  ===========
  1  Internal0 [0/RP0/CPU0]    n/a                         SEC  255  Freerun    
     HundredGigE0/0/0/18       0/RP0/CPU0 ETH_RXMUX 33   ePRTC   30  Available  
     HundredGigE0/0/0/13       0/RP0/CPU0 ETH_RXMUX 22   ePRTC   31  Available  

Selection point: CHASSIS-TOD-SEL (1 inputs, 1 selected)
  Last programmed 02:41:44 ago, and selection made 02:41:44 ago
  Next selection points
    SPA scoped    : None
    Node scoped   : None
    Chassis scoped: None
    Router scoped : None
  Uses time-of-day selection
  S  Input                     Last Selection Point      Pri  Time  Status
  == ========================  ========================  ===  ====  ===========
  1  HundredGigE0/0/0/18       0/RP0/CPU0 T0-SEL-B 33    100  No    Available  

Selection point: ETH_RXMUX (2 inputs, 2 selected)
  Last programmed 02:41:55 ago, and selection made 02:41:55 ago
  Next selection points
    SPA scoped    : None
    Node scoped   : T0-SEL-B 1588-SEL
    Chassis scoped: None
    Router scoped : None
  Uses frequency selection
  S  Input                     Last Selection Point         QL  Pri  Status
  == ========================  ========================  =====  ===  ===========
  33 HundredGigE0/0/0/18       n/a                       ePRTC   30  Available  
  22 HundredGigE0/0/0/13       n/a                       ePRTC   31  Available
1 sources equal in their advertised QL and user configured priority
2 sources equal in their advertised QL and user configured priority