PTP on Cisco Catalyst IR8340 Rugged Series Routers
Starting from Cisco IOS XE Release 17.7.x, Cisco Catalyst IR8340 Rugged Series Router supports PTP.
PTP requires a Network Advantage license.
PTP in Ethenet networks
PTP provides time accuracy and synchronization on packet-based networks, such as Ethernet.
Smart grid power automation applications, such as peak-hour billing, virtual power generators, and outage monitoring, need precise time accuracy and stability. Accurate timing improves network monitoring and troubleshooting.
PTP in Ethernet networks offers:
-
low cost and easy setup in existing Ethernet networks, and
-
limited bandwidth usage for PTP data packets.
PTP clocks
A PTP network includes both PTP-enabled devices and devices that do not use PTP.
PTP-enabled devices typically consist of these clock types.
Grandmaster clock
The grandmaster clock connects directly to the server time source and serves as the synchronization point for all clocks. In a PTP domain, it acts as the primary time source for synchronization using PTP. The grandmaster clock typically relies on a highly accurate time source, such as a GPS or atomic clock. When the network requires only internal synchronization and no external time reference, the grandmaster clock can operate freely.
Ordinary clock
An ordinary clock is a 1588 clock with a single PTP port that can operate in one of these modes:
-
server mode—distributes timing information to one or more client clocks, allowing them to synchronize with the server clock.
-
client mode—synchronizes its clock to a server clock. It can connect to two different server clocks simultaneously by enabling client mode on up to two interfaces.
Ordinary clocks are the most common clock type in a PTP network and serve as end nodes connected to devices that require synchronization.
Boundary clock
A boundary clock in a PTP network replaces a standard network switch or router. It has multiple PTP ports, with each port supporting a separate PTP communication path. Boundary clocks act as interfaces between PTP domains, intercepting and processing all PTP messages while passing other network traffic.
The boundary clock uses the BMCA to identify the best clock from any port. The selected port is set to non-master mode, synchronizing with the upstream master clock. Meanwhile, the master port synchronizes all downstream clocks.
Transparent clock
A transparent clock in a PTP network updates the time-interval field in PTP event messages. This update compensates for switch delays with up to one-picosecond accuracy.
There are two types of transparent clocks:
-
End-to-end (E2E) transparent clocks: E2E transparent clocks measure the transit time (resident time) of PTP event messages, such as Sync and Delay_Req messages. They add the measured transit time to the correction field of the corresponding messages:
-
For Sync messages, the transit time is added to the correction field of the Sync or Follow_Up message.
-
For Delay_Req messages, the transit time is added to the correction field of the Delay_Resp message.
This information helps the time recipient to calculate the offset between its time and the time source's time. E2E transparent clocks do not provide the propagation delay of the link itself.
-
-
Peer-to-peer (P2P) transparent clocks: The P2P transparent clocks measure PTP event message transit time in the same way E2E transparent clocks do. In addition, P2P transparent clocks measure the upstream link delay. The upstream link delay is the estimated packet propagation delay between the upstream neighbor P2P transparent clock and the P2P transparent clock under consideration.
The message transit time and upstream link delay are both added to the correction field of the PTP event message. The correction field received by the time recipient contains the total of all link delays.
Theoretically, this is the total end-to-end delay of the Sync packet from the source time to the recipient.
PTP clock hierarchy
Summary
The PTP hierarchy ensures precise time synchronization across a network by establishing a primary-secondary relationship among different clock types.
The key components involved in the process are:
-
Grandmaster clock (Switch): The primary and most accurate time source in the hierarchy, acting as the primary clock source for all downstream clocks.
-
Boundary or Transparent clock (Switch): A network device that acts as a secondary clock to an upstream primary clock and as a primary clock source to downstream secondary clocks, relaying and potentially correcting time information.
-
Ordinary clock: An end-device clock that acts solely as a secondary, synchronizing its time to an upstream primary clock.
-
Primary (M) role: The clock sending synchronization messages to a secondary.
-
Secondary(S) role: The clock receiving and synchronizing its time based on the messages from a primary.
Workflow
The process involves these stages:
-
Grandmaster initiation: The Grandmaster clock, positioned at the top of the hierarchy, sends precise time information to the first-level clocks to initiate the time synchronization process.
-
First-level synchronization: The first boundary or transparent clock receives time information from the Grandmaster, acting as a secondary to synchronize its own clock with the Grandmaster's time.
-
Hierarchical propagation: Each Boundary or transparent clock, having synchronized with its upstream primary clock, acts as a primary clock to its connected downstream Boundary,Transparent, or Ordinary clocks. It propagates the precise time synchronization further down the hierarchy.
-
End-device synchronization: Ordinary clocks receive time synchronization messages from their respective primary boundary or transparent clocks and adjust their internal clocks accordingly, operating as secondary.
-
Continuous synchronization: This primary-secondary relationship is continuously maintained throughout the PTP hierarchy, ensuring all clocks remain precisely synchronized to the Grandmaster clock.
Result
The PTP clock hierarchy provides highly accurate and distributed time synchronization across a network, which is critical for applications requiring precise timing, such as industrial automation, financial trading, and telecommunications.
Message-based PTP synchronization
PTP synchronizes clocks across network devices. It:
-
exchanges messages between the time source (Grandmaster Clock) and the time recipient to synchronize clocks,
-
measures the precise transmit and receive times of these messages to calculate the communication path delay, and
-
adjusts the current time information in network data based on the calculated delay to achieve highly accurate time synchronization.
Delay measurement in PTP synchronization
The delay measurement calculates the path delay between devices on the network and adjusts local clocks accordingly. It uses a series of messages exchanged between the time source and time recipient devices. The one-way delay is determined by averaging the path delay of the transmit and receive messages. This calculation assumes a symmetrical communication path, but switched networks may not have symmetrical paths due to the buffering process.
Transparent Clocks in PTP synchronization
PTP uses transparent clocks to measure and account for the delay in the time-interval field of network timing packets. This approach makes switches temporarily transparent to the time source and time recipient nodes on the network. An end-to-end transparent clock forwards all messages across the network similar to a switch.
 Note |
Cisco PTP supports multicast PTP messages only. |
For more details on synchronization messages, refer to PTP event message sequences.
For more details on calculation of network delays, refer to Transparent clock.
PTP network
The key components involved in the process are:
-
Time Source 1 (Grandmaster): The primary, high-quality source of time and frequency that initiates the timing distribution.
-
Time Source 2: A secondary, lower-quality source of time and frequency, potentially serving as a backup or alternative.
-
Boundary Clock 1: A network device (example: a switch) that synchronizes its internal clock with the Grandmaster and then acts as a time source for downstream devices.
-
Boundary Clock 2: A network device that synchronizes its internal clock with Boundary Clock 1 and distributes the precise timing to the end-point recipients.
-
IED (Intelligent Electronic Device) or recipient: End devices that receive and utilize the precise timing information for their operations.
Summary
PTP networks distribute precise timing information from a highly accurate source to various network devices, ensuring synchronization across the system.
Workflow
The process involves the following stages:
-
Grandmaster Initialization: A high-quality frequency or time source provides highly accurate timing to Time Source 1, which functions as the Grandmaster.
-
Grandmaster to Boundary Clock 1 distribution: The Grandmaster transmits its precise timing information to Boundary Clock 1 over a network connection.
-
Boundary Clock 1 to Boundary Clock 2 synchronization: Boundary Clock 1 synchronizes its clock with the Grandmaster and then forwards the timing information to Boundary Clock 2.
-
Boundary Clock 2 to recipient distribution: Boundary Clock 2 synchronizes its clock with Boundary Clock 1 and distributes the precise timing to the connected IEDs (Recipient 1, Recipient 2, and Recipient 3).
Result
All connected IEDs (Recipients) receive synchronized and precise timing information, enabling coordinated and time-sensitive operations across the network.
PTP event message sequences
This section explains the sequence of PTP event messages during synchronization.
Synchronize with Boundary clocks
Use these event messages to configure Ordinary and Boundary Clocks for the delay request-response mechanism and communicate timing information:
-
Sync,
-
Delay_Req,
-
Follow_Up, and
-
Delay_Resp messages.
Boundary Clock synchronization
The key components involved in the process are:
-
Time Source: The entity that provides the reference time.
-
Time Recipient: The entity that seeks to synchronize its clock with the Time Source.
-
Sync message: A message sent by the Time Source to initiate synchronization.
-
Follow-Up message: A message sent by the Time Source to provide the precise departure timestamp (t1) of the Sync message.
-
Delay-Req message: A message sent by the Time Recipient to the Time Source to request delay measurement.
-
Delay-Resp message: A message sent by the Time Source to the Time Recipient, containing the arrival timestamp (t4) of the Delay-Req message.
-
Path-Delay: The calculated one-way network latency between the Time Source and Time Recipient.
-
Offset from Time Source: The calculated time difference between the Time Recipient's clock and the Time Source's clock.
Summary
Network time synchronization ensures that different devices or systems maintain a consistent and accurate understanding of time, which is crucial for logging, data correlation, and distributed operations.
Workflow
The network time synchronization process involves these stages:
-
Sync message transmission: The Time Source sends a Sync message to the Time Recipient and notes the time (t1) it sends the message.
-
Sync message reception: The Time Recipient receives the Sync message and notes the time (t2) it receives the message.
-
Follow-Up message transmission: The Time Source sends the timestamp t1 to the Time Recipient in a Follow-Up message.
-
Delay request transmission: The Time Recipient sends a Delay-Req message to the Time Source and notes the time (t3) it sends the message.
-
Delay request reception: The Time Source receives the Delay-Req message and notes the time of reception (t4).
-
Delay response transmission: The Time Source sends the timestamp t4 to the Time Recipient in a Delay-Resp message.
-
Path-Delay calculation: The Time Recipient calculates the Path-Delay using the formula
[(t4 - t1) - (t3 - t2)] / 2. -
Offset calculation: The Time Recipient calculates the offset from the Time Source using the formula
(t2 - t1) - Path-Delay.
Result
This process enables the Time Recipient to obtain all four necessary timestamps (t1, t2, t3, t4) to calculate the network path delay and its clock's offset relative to the Time Source. This allows the Time Recipient to adjust its clock for precise synchronization. It is important to note that the calculation assumes symmetrical propagation time between the source and recipient; however, this assumption may not hold true on all networks, such as Ethernet, due to asymmetrical packet delay times.
Synchronize with peer-to-peer Transparent clocks
The network includes multiple levels of boundary clocks in the hierarchy with non-PTP-enabled devices between them, which decreases synchronization accuracy. The calculation typically assumes the round-trip time equals mean_path_delay divided by 2, but this is not always accurate for Ethernet networks.
To improve accuracy, an end-to-end TC adds the resident time of each intermediary clock to the offset. However, the resident time does not include the link delay between peers, which a peer-to-peer TC manages.
Peer-to-peer TCs use the peer delay mechanism to calculate the link delay between two clock ports. This link delay is used to adjust the timing information in Sync and Follow_Up messages.
Peer-to-peer TC use these event messages:
-
Pdelay_Req,
-
Pdelay_Resp, and
-
Pdelay_Resp_Follow_Up
Peer-to-Peer Transparent Clock synchronization
Summary
Peer link delay measurement is a mechanism used to precisely determine the communication delay over a direct link between two network devices. This process is essential for accurate time synchronization protocols like PTP.
The key components involved in the process are:
-
Switch 1: The initiating device that sends delay requests and calculates the peer link delay.
-
Switch 2: The responding device that receives delay requests, sends responses, and provides its internal timestamps.
-
Pdelay_Req: A message sent by Switch 1 to initiate the delay measurement process.
-
Pdelay-Resp: A message sent by Switch 2 in response to a Pdelay_Req, containing the timestamp of its reception (
t2). -
Pdelay-Resp_followup: A subsequent message sent by Switch 2 that provides the precise timestamp of when it transmitted the Pdelay-Resp message (
t3). -
Timestamps (t1, t2, t3, t4): Specific points in time recorded by the switches during the message exchange to measure transmission and reception times.
Workflow
These messages are sent in this sequence:
-
Switch 1 generates timestamp t1 for a Pdelay_Req message.
-
Switch 2 receives Pdelay_Req and generates timestamp t2 for this message.
-
Switch 2 generates timestamp t3 for a Pdelay_Resp message.
To minimize errors due to any frequency offset between the two switches, switch 2 returns the Pdelay_Resp message as quickly as possible after the receipt of the Pdelay_Req message.
-
Switch 2 returns timestamps t1, t2, and t3 in the Pdelay_Resp and Pdelay_Resp_Follow_Up messages respectively.
-
Switch 1 generates timestamp t4 after receiving the Pdelay_Resp message. switch 1 then uses the four timestamps (t1, t2, t3, and t4) to calculate the mean link delay between switch1 and switch 2
The process involves these stages:
-
Request initiation: Switch 1 sends a Pdelay_Req message to switch 2 and records the precise time of transmission as
t1. -
Request reception: Switch 2 receives the Pdelay_Req message from switch 1 and records the precise time of reception as
t2. -
Response transmission: Switch 2 prepares and sends a Pdelay-Resp message back to switch 1. This message includes the
t2timestamp. Switch 2 also records the precise time of transmitting this Pdelay-Resp message ast3. -
Follow-up transmission: Shortly after sending the Pdelay-Resp, switch 2 sends a Pdelay-Resp_followup message to switch 1. This Follow-up message contains the
t3timestamp, providing a precise record of the Pdelay-Resp's transmission time. -
Response reception and calculation: Switch 1 receives both the Pdelay-Resp and Pdelay-Resp_followup messages. It records the precise time of receiving these messages as
t4. Switch 1 then calculates the peer link delay using the formula:Peer_link_delay = [(t4 - t1) - (t3 - t2)]/2.
Result
The process accurately determines the one-way communication delay over a specific network link, allowing devices to compensate for propagation delays and achieve highly precise time synchronization across the network.
Synchronize the local clock
In an ideal PTP network, the time source and time recipient clocks operate at the same frequency. Drift occurs when their frequencies differ. PTP uses timestamp information from device hardware and the FollowUp messages intercepted by the switch to correct clock drift and align the local clock with the time source.
Best Master Clock Algorithm
The Best Master Clock Algorithm (BMCA) serves as the basis for PTP functionality. It defines how each clock in the network identifies the best time source clock within its subdomain from all visible clocks, including itself. BMCA continuously operates on the network and quickly adapts to changes in the network configuration.
The BMCA identifies the best time source clock in the subdomain based on:
-
clock quality (example: GPS is considered the highest quality),
-
accuracy of the clock's time base,
-
stability of the local oscillator, and
-
proximity to the grandmaster clock.
The BMCA prevents clock conflicts on the PTP network by ensuring:
-
clocks do not negotiate with one another, and
-
misconfigurations, such as multiple or missing time source clocks, do not occur during the time source clock identification process.
PTP profiles
Cisco Catalyst IR8340 Rugged Series Router supports these PTP profiles:
-
Default,
-
Power, and
-
802.1AS.
Cisco IOS-XE Release 17.7.1 supports Power Profile-2011, defined in the PC37.238-2011 IEEE Draft Standard Profile for using IEEE 1588 PTP in Power System Applications.
Note |
This documentation uses the terms Power Profile mode and Default Profile mode to refer to the IEEE 1588 profile and its configuration values. |
Starting from Cisco IOS-XE Release 17.8.1, Cisco Catalyst IR8340 Rugged Series Router supports two Power Profiles. Power Profile-2011 and Power Profile-2017. Power Profile-2017 is defined in IEEE Standard C37.238™-2017 (a Revision of IEEE Std C37.238-2011) for use of IEEE 1588 PTP in Power System Applications.
IEEE 1588 defines a PTP profile as a set of allowed PTP features for a device. A PTP profile is tailored to a specific application or environment and specifies these values:
-
Best master clock algorithm options
-
Configuration management options
-
Path delay mechanisms (peer delay or delay request-response)
-
Range and default values of all PTP configurable attributes and data set members
-
Transport mechanisms that are required, permitted, or prohibited
-
Node types that are required, permitted, or prohibited
-
Options that are required, permitted, or prohibited
Default Profile mode
The Cisco Catalyst IR8340 Rugged Series Router uses Default Profile mode as its default PTP profile. In this mode:
-
It supports Ordinary Clock (OC)- slave, Boundary Clock (BC), and Transparent Clock (TC).
-
It does not support OC-master.
-
All PTP profiles over bundles or port-channels are not supported.
Power Profile mode
The IEEE Power Profile specifies the allowed values for PTP networks used in power substations. These values include the optimal physical layer, the higher-level protocol for PTP messages, and the preferred BMCA. The Power Profile ensures consistent and reliable time distribution within substations, between substations, and across wide geographic areas.
The router is optimized for PTP in these ways:
-
Hardware—The router uses FPGA and PHY for the PTP function. The PHY time stamps the Fast Ethernet and Gigabit Ethernet ports.
-
Software—In Power Profile mode, the router uses the configuration values defined in the IEEE 1588 Power Profile standard.
This table displays the IEEE 1588 power profile configuration values and shows how the Cisco Catalyst IR8340 Rugged Series Router applies them for each PTP profile mode.
|
PTP field |
Router configuration value |
|
|---|---|---|
|
Power profile mode |
Default profile mode |
|
| Message transmission |
Access Ports –Untagged Layer 2 packets. Trunk Ports –802.1Q tagged Layer 2 packets. PTP packets are tagged with the PTP VLAN. If the PTP VLAN is not configured, packets go untagged over the native VLAN. |
Layer 3 packets. By default, 802.1q tagging is disabled. |
|
MAC address–Non-peer delay messages |
01-00-5e-00-01-81. | Default profile uses L3 transport multicast address 224.0.1.129 for all PTP messages. Equivalent MAC address is 01-00-5e-00-01-81 |
|
MAC address-Peer delay messages |
01-80-C2-00-00-0E. | Not applicable to this mode. |
| Domain number | 0. | 0. |
| Path delay calculation | Peer-to-peer transparent clocks using the peer_delay mechanism. | End-to-end transparent clocks using the delay_request mechanism. |
| BMCA | Enabled. | Enabled. |
| Clock type | Two-step. | Two-step. |
| Time scale | Epoch. | Epoch. |
| Grandmaster ID and local time determination | PTP-specific TLV to indicate Grandmaster ID. | PTP-specific type, length, and value to indicate Grandmaster ID. |
| Time accuracy over network hops | Over 16 hops, slave device synchronization accuracy is within 1 usec (1 microsecond). | Not applicable in this mode. |
802.1AS profile
The IEEE 802.1AS standard, Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks, defines the protocol and procedures to meet synchronization requirements for time-sensitive applications in bridged and virtual bridged local area networks.
The 802.1AS standard applies IEEE 1588 (PTP) specifications where its relevant within the context of IEEE Std 802.1D-2004 and IEEE Std 802.1Q-2005. It is one of three 802.1 Audio Video Bridging (AVB) draft standards. 802.1AS over Ethernet (802.3) serves as a profile of IEEE 1588-2008, simplifying IEEE 1588 and enabling synchronization across various types of media.
Note |
On Cisco Catalyst IR8340 Rugged Series Routers, 802.1AS can only be configured with domain 0." |
802.1AS key characteristics
These are the key characteristics of 802.1AS.
-
It uses the peer delay mechanism for Ethernet full-duplex links.
-
All devices in the domain must be 802.1AS capable.
-
It transports 802.1AS packets as L2 multicast only, without VLAN tags.
-
It requires two-step processing using Follow_Up and Pdelay_Resp_Follow_Up messages to communicate timestamps.
-
A time-aware network has only one active grandmaster and a single 802.1AS domain.
-
The BMCA is the same as IEEE 1588, with these exceptions:
-
It uses Announce messages received on a time recipient port immediately, without foreign-time source qualification.
-
A port determined as a time source port by the BMCA enters the time source state immediately, skipping the pre-time source state.
-
It does not use the uncalibrated state.
-
All time-aware systems must participate in best master selection (even if the system is not grandmaster capable).
-
802.1AS Timing for Time Sensitive Networks
802.1AS is used in Time Sensitive Networking (TSN). However, it operates independently as a precise timing distribution mechanism without requiring TSN configuration or inputs. It uses the existing FPGA time-stamping functionality and does not require additional hardware beyond other PTP profiles.
802.1AS for end-to-end synchronization
The 802.1AS standard ensures these end-to-end time synchronizations.
-
Any two time-aware systems separated by six or fewer time-aware systems (seven hops or less) achieve synchronization within 1 microsecond peak-to-peak during steady-state operation.
-
Synchronization performance beyond seven hops is not defined.
PTP profile comparison
This table provides the comparison of different PTP power profiles on IE switches.
| Profile | Default (*) | Power profile-2011 |
Power profile-2017 |
802.1AS | ||
|---|---|---|---|---|---|---|
| Standard | IEEE1588 v2 (J.3) | IEEE C37.238-2011 |
IEEE C37.238-2017 |
IEEE802.1AS | ||
| Mode | Boundary | End-to-End transparent | Boundary | Peer-to-Peer transparent |
Peer-to-Peer transparent |
** |
| Path Delay | Delay req/res | Delay req/res | Peer delay req/res | Peer delay req/res |
Peer delay req/res |
Peer delay req/res |
| Non-PTP device allowed in PTP domain | Yes | Yes | No | No |
No |
No |
| Transport | UDP over IP (multicast) | L2 Multicast |
L2 Multicast |
L2 Multicast | ||
* Delay Request-Response Default PTP profile (as defined in IEEE1588 J.3).
** 802.1AS has no mode setting. It is mathematically similar to P2P transparent but operates differently from a transparent clock.
PTP clock modes
PTP synchronization behavior relies on the PTP clock mode configured on the router. You can set the router to one of these global modes.
The router supports these PTP device types:
-
OC-slave, Boundary Clock (BC), and Transparent Clock(TC) on Default Profile or IEEE 1588.
-
BC and TC on Power profile.
-
BC on 802.1AS profile.
For guidelines on each clock configuration. See Restrictions of PTP
Note |
Currently, all the above profiles support two-step mode and don't support one-step mode. |
Default settings
By default, the router is configured with these PTP settings.
-
PTP is enabled.
-
Default profile mode is enabled, using configuration values defined in the Default profile.
-
The PTP clock mode is set to End-to-End (E2E) Transparent Clock mode.
-
The Boundary Clock (BC) synchronization algorithm is set to the linear filter.
Boundary Clock Synchronization algorithm
You configure the Boundary Clock (BC) Synchronization algorithm based on your PTP use case, prioritizing either filtering input time errors or achieving faster convergence. A PTP algorithm that filters packet delay variation (PDV) converges more slowly than one without filtering
By default, the BC uses a linear feedback controller (servo) to adjust its time output to the next clock. The linear servo offers minimal PDV filtering and achieves average convergence time. For faster convergence, the BC can use the TC feedforward algorithm, which measures the delay introduced by the network elements' forwarding plane (the disturbance) and uses this delay to control the time output.
The feedforward BC significantly improves BC performance but does not filter PDV. The adaptive PDV filter ensures high-quality time synchronization even when wireless access points (APs) and enterprise switches, which do not support PTP, introduce significant PDV.
BC synchronization supports three options which are compliant with IEEE 1588-2008:
-
Feedforward—For very fast and accurate convergence but does not filter PDV.
-
Adaptive—Adaptive filters maximize PDV filtering based on assumptions about PDV characteristics, hardware configuration, and environmental conditions.
Note
With the adaptive filter, the switch does not meet the time performance requirements specified in ITU-T G.8261.
-
Linear—Provides simple linear filtering which is the default.
Adaptive mode ptp transfer filter adaptive is not available in Power Profile mode.
PTP profile switch tag behavior
This table describes the switch tagging behavior in Power profile and Default profile mode.
|
Switch Port Mode |
Configuration |
Power Profile Mode |
Default Profile Mode |
||
|---|---|---|---|---|---|
|
Behavior |
Priority |
Behavior |
Priority |
||
| Trunk Port | vlan dot1q tag native enabled | Switch tags packets | 7 | Switch tags packets | 7 |
| Trunk Port | vlan dot1q tag native disabled | PTP software tags packets | 4 | Untagged | None |
| Access Port | N/A | Untagged | None | Untagged | None |
PTP packet flow
The key components involved in the process are:
-
Boundary Clock (BC): A network device that participates in PTP, synchronizing its clock to a primary and acting as a primary clock source to downstream clocks.
-
Grandmaster Clock (GMC): The primary source of time within a PTP domain, typically located in a foreign network.
-
GMC-Block configuration: A specific feature enabled on an interface (Example: Gig 1/4) of a Boundary Clock.
-
PTP packets (Sync, Announce, Follow_Up): Messages used by PTP for time synchronization.
-
Existing Network: The local network containing the Boundary Clock with the GMC-Block configuration.
-
Foreign Network: An external network that may be a source of PTP packets.
Summary
A network interface configured with GMC-Block processes and then drops incoming synchronization messages while allowing outgoing ones, controlling the flow of PTP packets. This ensures that the local network's PTP synchronization is maintained by its own Grandmaster Clock (GMC).
Workflow
This figure shows an example of a PTP network topology with the GMC Block feature configured on an interface.
The process involves these stages:
-
Configuration of Gmc-Block: A network administrator configures the Gmc-Block feature on a specific interface, such as Gig 1/4, of a Boundary Clock within the existing network.
-
Incoming PTP packet handling: When PTP Sync, announce, and followup packets arrive on the configured interface from a Foreign Network, the Boundary Clock retrieves necessary information from these packets and drops them due to the Gmc-Block configuration.
-
Egress PTP packet handling: The Boundary Clock continues to forward egress PTP packets from the configured interface to the Foreign Network, even with the Gmc-Block enabled.
Result
The Gmc-Block configuration effectively prevents a specific Boundary Clock interface from accepting incoming PTP synchronization messages from a designated foreign network by processing and then dropping them. This allows the system to restrict synchronization from external sources, ensuring the local network synchronizes with its own GMC. Simultaneously, it allows the interface to continue sending its own PTP information, maintaining its role as a primary to other devices within its domain. This provides granular control over PTP domain boundaries and ensures that the clock synchronization source is managed as intended.
Configure PTP
Use this procedure to configure PTP on the router.
Procedure
|
Step 1 |
Use the config terminal command to enter configuration mode. Example: |
|
Step 2 |
Use the license boot level network-advantage command to configure the license as Network Advantage. Example: |
|
Step 3 |
Use the end command to exit from configuration mode and enter into EXEC mode. Example: |
NTP to PTP time conversion
NTP to PTP time conversion lets you use Network Time Protocol (NTP) as a time source for PTP. You can use PTP for precise synchronization within a site and rely on NTP across sites where precision is unnecessary.
NTP is the traditional method to synchronize clocks in packet-based networks. It uses a two-way time transfer mechanism between a time source and an end device. NTP synchronizes a device within a few hundred milliseconds over the Internet and within a few milliseconds in a controlled LAN. Using NTP as a PTP time source lets you correlate data from your PTP network with data in enterprise data centers running NTP.
NTP to PTP conversion
Summary
This process describes the hierarchical distribution of time synchronization, starting from a global UTC source and extending down to industrial control systems, enabling the precise time synchronization often required by devices in operational technology (OT) environments through eventual NTP to PTP conversion.
The key components involved in the process are:
Time sources and network zones
-
UTC Time: The global reference for highly accurate time synchronization.
-
NTP Time Server Pool: A collection of servers that acquire accurate time from UTC sources and distribute it via NTP.
-
Internet: The wide area network (WAN) used to access the NTP Time Server Pool and connect the Enterprise WAN.
-
Enterprise WAN: The WAN connecting the enterprise infrastructure to the internet.
-
Enterprise zone: The primary network segment for general enterprise operations.
-
Demilitarized zone (DMZ): A network segment that provides a secure buffer between the internal network and external networks, hosting services like the NTP Time Mirror.
-
Manufacturing zone: A network segment dedicated to manufacturing operations, relying on accurate time for process control.
Network infrastructure and end devices
-
NTP time mirror: A local NTP server within the DMZ that synchronizes with the external NTP Time Server Pool, providing a secure and reliable internal time source.
-
Core switches: High-performance switches forming the backbone of the network, connecting different zones and distributing network traffic.
-
Distribution switch: A switch that aggregates connections from core switches and distributes them to lower-level network segments like the Cell/Area Zone.
-
Layer 2 switch: Switches operating at the data link layer, providing connectivity to end devices within a local network segment.
-
Industrial Devices: Equipment such as Programmable Logic Controllers (PLCs) and Human-Machine Interfaces (HMIs) in the Cell/Area Zone that require highly precise time synchronization, often via PTP.
Workflow
The process involves these stages:
-
Global time source acquisition: The NTP Time Server Pool obtains highly accurate time from a UTC time source over the internet, ensuring a precise global time reference.
-
Enterprise network distribution: The NTP Time Server Pool distributes this synchronized NTP time to the Enterprise Zone, which includes the Enterprise WAN and core network infrastructure, providing time synchronization for general IT systems.
-
DMZ time mirroring: An NTP Time Mirror located within the Demilitarized Zone (DMZ) synchronizes with the external NTP Time Server Pool, establishing a secure and reliable local NTP time source for internal networks.
-
Manufacturing zone synchronization: Core switches and connected devices within the Manufacturing Zone obtain their time synchronization from the NTP Time Mirror in the DMZ, ensuring operational consistency for manufacturing processes.
-
Industrial network connectivity: The Distribution Switch connects the Manufacturing Zone's core network to the Cell/Area Zone, which contains critical industrial control systems and devices. Layer 2 switches further distribute network connectivity within this zone to the industrial equipment.
-
PTP conversion enablement: Within the cell or area zone, the distributed NTP time serves as a reference for specialized devices that convert NTP to PTP. This conversion provides the extremely precise time synchronization required by industrial automation equipment like PLCs and HMIs for coordinated operations.
Result
This hierarchical time synchronization process ensures that all network zones, from enterprise IT to critical industrial operational technology (OT), receive accurate and consistent time. This enables precise timestamping, synchronized operations, and the high-fidelity timing required for sensitive industrial control applications through the enablement of NTP to PTP conversion at the network edge.
Clock manager
The clock manager in the Cisco NTP to PTP software architecture tracks various time services and selects the active clock providing time. It also notifies time services of key changes, such as state changes, leap seconds, or daylight saving time.
The clock manager prioritizes the NTP or manually set clock first, followed by PTP, and then the real-time clock if NTP is inactive. This table shows the results of the clock selection process.
| NTP (Active) or Manually Set | PTP (Active) | Real-Time Clock | Selected Output |
|---|---|---|---|
| True | Don’t care | Don’t care | NTP or Manually Set |
| False | True | Don’t care | PTP |
| False | False | True | Real-Time Clock |
In general, the clock manager ensures that the time displayed in the Cisco IOS commands show ptp lan clock and show clock match. The show clock command always follows this priority, but there are two corner cases where the show ptp lan clock time may differ:
-
The router acts as a TC or BC with no other active reference on the network. To maintain backward compatibility, the TC and BC take their time only from the network’s PTP GMC, not from the clock manager. If no active PTP GMC exists, the show clock and show ptp lan clock command outputs may differ.
-
The router is a syntonizing TC, a BC with a secondary port, or a GMC-BC with a secondary port, and the time from the PTP GMC does not match the time from NTP or the user (manually set). In this case, the PTP clock must forward the time from the PTP GMC. If the PTP clock does not follow the PTP GMC, the PTP network has two different time bases, disrupting control loops or sequence-of-event applications that rely on PTP.
This table shows how the Cisco IOS and PTP clocks behave given the various configurations. Most of the time, the two clocks match. Occasionally, the two clocks are different; those configurations are highlighted in the table.
| IOS Clock Configuration | PTP Clock Configuration | IOS Clock Source | PTP Clock Source |
|---|---|---|---|
|
Calendar |
PTP BC, E2E TC, or GMC-BC in BC Mode |
PTP |
PTP |
| Manual | PTP BC, E2E TC, or GMC-BC in BC Mode | Manual | PTP |
| NTP | PTP BC, E2E TC, or GMC-BC in BC Mode | NTP | PTP |
| Calendar | GMC-BC in GM Mode | Calendar | Calendar |
| Manual | GMC-BC in GM Mode | Manual | Manual |
| NTP | GMC-BC in GM Mode | NTP | NTP |
Grandmaster clock
Grandmaster clock (GMC) block protects a network from rogue GMC that is attempting to synchronize with devices inside the network. Similarly, this is supported for all PTP clock modes except forward mode. Once it is enabled on an interface, it allows only egress Announce, Sync, and Follow_Up PTP packets while dropping all ingress Announce, Sync, and Follow_Up packets on the interface. This prevents the port state from transitioning to a time recipient.
Information about a rogue GMC is retrieved from its packets before they are dropped. Similarly, egress PTP packets are allowed from this interface, enabling it to act as a GMC. To identify the rogue device, details such as its IP address and clock ID are stored and displayed for the interface. Additionally, two Syslog messages are generated to notify both the detection and clearance of rogue devices.
You can configure PTP gmc-block on multiple ports if you suspect multiple foreign networks are connected to your system. The system displays per-port Syslog messages 30 seconds after receiving rogue packets and 180–240 seconds after the packets stop. It also generates relay minor alarms and SNMP traps to notify you about the presence of foreign rogue devices.
Restrictions of PTP
PTP messages
The Cisco Catalyst IR8340 Rugged Series Router supports two-step clock and multicast PTP messages.
PTP mode and profile
-
The router and the grandmaster clock must be in the same PTP domain.
-
When Power Profile mode is enabled, the router drops PTP announce messages that do not include the Organization_extension and Alternate_timescale TLV message extensions.
If the GMC is not compliant with PTP and sends announce messages without these TLVs, configure the router to process the announce message by entering this command:
ptp clock boundary domain 1 profile power allow-without-tlv -
When the router is in Power Profile mode, only the peer_delay mechanism is supported.
To enable Power Profile boundary mode and associate interfaces using the clock-port suboption, enter these commands:
ptp clock boundary domain 1 profile power clock-port 1 transport ethernet multicast interface gi0/1/1 -
To disable power profile transparent mode, enter this command, which returns the router to forward mode.
no ptp clock transparent domain x profile power -
To enable the E2E transparent clock, use this command:
ptp clock transparent domain x profile default - In Default Profile mode, only the delay_request mechanism is supported.
To enable Default Profile BC mode and interfaces associated with clock-port suboption, enter this command:
ptp clock boundary domain 1 profile default clock-port 1 transport ipv4 multicast interface gi0/1/1 -
The 802.1AS profile does not have a clock mode setting.
Packet format
The router handles PTP packet formats and behavior as specified:
-
PTP messages can use 802.1q tagged packets or untagged packets.
-
The router does not support 802.1q QinQ tunneling.
-
In Power Profile mode:
-
When the PTP interface is configured as an access port, PTP messages are sent as untagged Layer 2 packets.
-
When the PTP interface is configured as a trunk port, PTP packets are sent as 802.1q tagged Layer 2 packets over the port's native VLAN.
-
-
Time recipient IEDs must support tagged and untagged packets.
-
In E2E TC mode, PTP packets sent on the native VLAN are untagged. To send them as tagged packets, use the
vlan dot1q tag nativecommand in global configuration mode.
PTP VLAN characteristics
Key details and considerations for configuring PTP VLANs and related settings include:
-
Set the PTP VLAN on a trunk port. The range is from 1 to 4094, with the default VLAN being the native VLAN of the trunk port.
-
In Boundary mode, the device processes only PTP packets in the PTP VLAN and drops packets from other VLANs.
-
Before configuring the PTP VLAN on an interface, ensure the PTP VLAN is created and allowed on the trunk port.
-
Most GMC use the default VLAN 0.
-
In Power Profile mode, the router defaults to VLAN 1, while VLAN 0 is reserved.
-
When changing the default GMC VLAN, ensure it is set to a VLAN other than 0.
-
If VLAN is disabled on the GMC, configure the PTP interface as an access port.
PTP VLAN and synchronization
The key aspects of PTP VLAN functionality and synchronization include:
-
All PHY PTP clocks synchronize to the GC.
-
The router system clock does not synchronize as part of PTP configuration and processes.
-
When VLAN is enabled on the GMC, it must be in the same VLAN as the native VLAN of the PTP port on the router.
-
GMC can drop untagged PTP messages when a VLAN is configured on the GMC.
-
To ensure the router sends tagged packets to the GMC, use the
vlan dot1q tag nativecommand in the global configuration mode.
PTP and clock modes
PTP support and clock modes for the router are:
-
PTP over port channels is not supported.
-
These PTP clock modes operate on a single VLAN:
-
e2etransparent
-
p2ptransparent
-
NTP to PTP conversion
-
The NTP to PTP conversion supports the Default E2E profile and Power profile.
Feedback