All PTP Clock Types and How to Configure in Asterfusion

Introduction

In What is PTP and How Does It Work?, we introduced the fundamental concepts of PTP. This article provides a consolidated overview of PTP clock types, covering the commonly referenced device-level clocks—GC, TC, BC, and OC—as well as the Hardware Clock, which is not a PTP-layer clock but plays an essential role in PTP accuracy.

The goal is to extend your understanding from PTP clock types to PTP message types, then explain how these messages interact within a topology to achieve time synchronization. The article concludes with how to configure these mechanisms on Asterfusion platforms.

Different PTP Clocks Types Defined in IEEE 1588v2

IEEE 1588v2 standardizes four core ptp clock types, with the Grandmaster Clock (GM) being the top-level time reference.

PTP Grandmaster Clock

In IEEE 1588v2, the Grandmaster Clock (GM or GMC) is the highest-quality and highest-priority PTP clock type in a PTP domain. All other PTP clock types in the network ultimately synchronize to it.

• Primary functions:
  • Provide the reference time: The GM typically connects to a GPS/GNSS atomic reference and supplies high-accuracy UTC time to the network.
  • Core of the BMC election: The Best Master Clock (BMC) algorithm selects the Grandmaster based on attributes such as Clock Class.
    • A lower Clock Class value indicates a higher-quality clock.
    • Note: Different PTP profiles define different comparison sequences in BMC, and the weight of Clock Class may vary. In most deployments, however, it remains the key determinant of which device becomes the Grandmaster.

This election mechanism ensures that the most reliable ptp clock type is selected as the domain’s time source.

The other major PTP clock types defined are the Ordinary Clock (OC), Transparent Clock (TC), and Boundary Clock (BC).

PTP Ordinary Clock

A PTP Ordinary Clock, one of the PTP clock types, is an endpoint device in a PTP network. It has only one physical port participating in PTP communication.

• Primary functions:
  • Operate as a Slave: In most deployments, an OC acts as a slave-side device that requires time synchronization. Typical examples include industrial robots, cameras, and server NICs. It receives time from the GM and adjusts its local clock.
  • Operate as a Master: In limited, simple topologies, an OC can operate as a master for a single slave. However, it does not provide forwarding or relay capabilities.

Therefore, an OC can be classified as OC-M or OC-S based on the port role (Master or Slave) as shown in the diagram. Whether operating as OC-M or OC-S, this ptp clock type only supports single-port PTP communication, limiting its use in complex topologies.

Note: “Master” and “Slave” denote PTP port states, not standard PTP clock types. In practice, however, devices that contain a port in the master state are commonly called “master clocks,” and those with a port in the slave state are called “slave clocks.” To remain consistent with this convention, the present article will use “master clock” and “slave clock” wherever applicable.

• A master clock provides time to downstream nodes.
• A slave clock receives time from an upstream master and synchronizes to it.
• Communication between them is carried out through PTP message exchanges.

PTP Transparent Clock

Another critical ptp clock type in intermediate network devices is the PTP Transparent Clock (TC), which focuses on delay correction rather than time regeneration. TC is also typically implemented in switches, but its behavior is fundamentally different from a BC. A TC does not terminate the PTP path; instead, PTP messages pass through the device.

Types: E2E TC and P2P TC are two subtypes of this ptp clock type, each optimized for different delay measurement mechanisms.

• E2E TC (End-to-End Transparent Clock): It only corrects residence time. For Delay_Req and Delay_Resp messages, which are used to measure link delay, an E2E TC simply forwards them while updating the residence time. In other words, an E2E TC compensates only for the time spent inside the device.
• P2P TC (Peer-to-Peer Transparent Clock): It corrects the residence time and also measures the link delay to its peer. A P2P TC intercepts and terminates Pdelay_Req messages and exchanges them directly with the neighboring device. This allows it to compute the link delay without sending these messages to the Master. In effect, a P2P TC compensates for the internal residence time plus the transmission delay of the previous link.

Primary functions of a PTP TC:

• Residence time correction: When PTP messages traverse a switch, queuing introduces delay. A TC measures how long each message stays inside the device and updates the Correction Field in the PTP header accordingly. These updated messages are forwarded to downstream clocks (OC or the slave port of a BC), which use the accumulated correction values when computing path delay and local clock offset.
• Jitter reduction: By subtracting the residence time contributed by intermediate switches, downstream devices can maintain precise synchronization even through multiple switching layers. As the name suggests, a TC is “transparent” to the protocol logic, but it plays a critical role in preserving timing accuracy.

PTP Boundary Clock

The PTP Boundary Clock (BC) is a multi-port ptp clock type that acts as a relay node between the GM and downstream terminal clocks.

• Primary functions:
  • Time regeneration and distribution: One port on a BC operates as a slave to learn the time from an upstream source such as the GM and aligns its local clock. After synchronization, the BC uses its calibrated clock to act as a master on other ports and distribute time to downstream devices.
  • Load reduction: A BC terminates Delay_Req messages, which are the most resource-intensive messages for the GM to process. By shielding the GM from downstream Delay_Req traffic, a BC significantly reduces the processing load on the Grandmaster and is well suited for large-scale PTP networks.

Compared with other types, this ptp clock type is the most effective in reducing GM load in large-scale PTP networks.

These are all PTP clock types defined at the protocol level. Next, we look at a clock that exists at the physical level but plays a critical role in PTP—the PTP Hardware Clock.

PTP Hardware Clock

Beyond the four protocol-level entities, the PTP Hardware Clock (PHC) is a physical-layer ptp clock type that underpins all PTP synchronization accuracy. PHC refers to the physical, independent oscillator/counter embedded in networking devices such as NICs or switching ASICs.

• Primary functions:
  • Hardware timestamping: PTP achieves high precision because it does not rely on operating system time. Instead, timestamps are generated directly from the PHC value at the hardware level.
  • Driving system time: In Linux systems (for example, /dev/ptp0), the PTP stack synchronizes this hardware clock first. The operating system then aligns the system clock with the Hardware Clock. The PHC is the physical foundation enabling PTP-level accuracy.

The following table provides a consolidated overview of all PTP clock types.

Clock Type	Full Name (English)	Core Definition	Key Characteristics	Typical Deployment Location
GM	Grandmaster Clock	The reference time source for a PTP domain; the single root clock that provides the synchronization signal.	1. Highest priority (elected through Priority1/Priority2). 2. Typically connected to GNSS (GPS/BeiDou) for absolute UTC time. 3. Dual-GM deployments for high availability.	Core data center rooms, backbone layers.
OC	Ordinary Clock	A terminal device clock with one PTP port that operates either as a Slave or a Master.	1. Slave mode: receives synchronization from a GM or BC (e.g., cameras, encoders, servers). 2. Master mode: used only in simple topologies as a lightweight GM replacement (rare).	Endpoint access layer (A/V devices, servers).
BC	Boundary Clock	A multi-port PTP clock that acts as both Slave and Master, serving as a timing relay.	1. Synchronizes from an upstream GM/BC and distributes time downstream. 2. Absorbs network jitter and compensates clock drift. 3. Reduces the load on the GM by terminating downstream delay requests.	Aggregation and access switches.
TC	Transparent Clock	A forwarding device that does not change the master–slave hierarchy and only corrects PTP packet transit delays.	1. Includes E2E-TC (corrects end-to-end delay) and P2P-TC (corrects link delay). 2. Does not participate in BMCA. 3. Suitable for high-jitter or long-haul transport networks.	Backbone switches, inter-region transport equipment.
PHC	PTP Hardware Clock	The physical timing source inside a device that enables PTP accuracy; an independent counter/oscillator embedded in a NIC, ASIC, PHY, or SoC.	1. Provides nanosecond-level hardware timing. 2. Supports hardware timestamping (HW Timestamping). 3. Exposed as /dev/ptpX for ptp4l/phc2sys in Linux. 4. Required by all GM/OC/BC/TC devices.	NICs, switch ASICs, router SoCs, server motherboard oscillators.

Core PTP Message Types

Different ptp clock type relies on specific PTP message combinations to complete time information transmission and delay calculation. According to IEEE 1588v2, they are classified into Event Messages and General Messages. The core message types and their functions are summarized below.

Key characteristics of PTP messages:

1. Event Messages vs. General Messages:
   • Event Messages: Require accurate hardware transmit or receive timestamps. Used for delay measurement and time synchronization (e.g., Sync, Delay_Req, Pdelay_Req).
   • General Messages: Do not require high-precision timestamps. Used to deliver control information or supplemental data (e.g., Announce, Delay_Resp, Follow_Up).
2. Delay mechanism alignment: Devices operating as Slave clocks use different message combinations depending on the selected delay mechanism. After calculating the time offset between the Master and Slave, the Slave corrects its local clock.
   • E2E (End-to-End) mechanism: Uses Sync + Follow_Up + Delay_Req + Delay_Resp.
   • P2P (Peer-to-Peer) mechanism: Uses Sync + Follow_Up + Pdelay_Req + Pdelay_Resp + Pdelay_Resp_Follow_Up.
3. Multicast vs. unicast transmission:
   • Sync and Announce messages use multicast by default (address 224.0.1.129).
   • Delay_Req and Delay_Resp are unicast in mixed mode (to reduce network load) and multicast in full multicast mode.

This section provides a consolidated overview of all PTP message types.

In the following traffic-flow analysis section, these message types will be explained together with the corresponding PTP clock types.

Message Type	Full Name	Message Category	Type Code	Core Function	Sender / Receiver	Key Notes
Sync	Synchronization Message	Event Message	0x0	Delivers the precise timestamp of the Master clock; triggers synchronization on Slave clocks.	GM/BC (Master port) → BC/OC (Slave port)	1. Carries the current Master timestamp. 2. Configurable transmit interval (e.g., 8/s, 1/s). 3. Core message for synchronization.
Follow_Up	Follow-Up Message	General Message	0x8	Provides the accurate timestamp associated with a Sync message when hardware timestamp insertion is delayed.	GM/BC (Master port) → BC/OC (Slave port)	Sent only when Sync cannot include a real-time hardware timestamp; one-to-one with Sync.
Announce	Announce Message	General Message	0xB	Advertises the identity of the Master clock and participates in BMCA selection.	GM/BC (Master port) → All downstream clocks	1. Includes Priority1/Priority2, accuracy, and clock ID. 2. Interval typically 1/s. 3. Used by downstream nodes to determine the best Master clock.
Delay_Req	Delay Request Message	Event Message	0x1	Requests end-to-end delay measurement from the Master clock.	OC/BC (Slave port) → GM/BC (Master port)	1. Used only in the E2E delay mechanism. 2. Interval aligned with Sync (e.g., 8/s). 3. Contains the Slave’s transmit timestamp.
Delay_Resp	Delay Response Message	General Message	0x9	Returns the delay measurement result for Slave-side compensation.	GM/BC (Master port) → OC/BC (Slave port)	Contains the Master’s receive timestamp for Delay_Req; used by the Slave to compute total delay.
Pdelay_Req	Peer Delay Request Message	Event Message	0x2	Measures link delay between neighboring devices.	Any P2P-capable clocks (GM/BC/TC)	1. Used only in P2P delay mechanism. 2. Exchanged only between adjacent nodes (e.g., GM↔BC, BC↔BC). 3. Corrects physical link delay.
Pdelay_Resp	Peer Delay Response Message	Event Message	0x3	Responds to Pdelay_Req with timestamps for link-delay calculation.	Node receiving Pdelay_Req	Contains the receive timestamp of Pdelay_Req; used to compute one-way link delay.
Pdelay_Resp_Follow_Up	Peer Delay Response Follow-Up Message	General Message	0xA	Provides the accurate timestamp associated with Pdelay_Resp.	Node sending Pdelay_Resp	Similar to Follow_Up; improves P2P delay measurement accuracy.
Signaling	Signaling Message	General Message	0xC	TLV-based control channel for extension and negotiation.	Any node → Any node	Not used for timestamping. Core mechanism for dynamic negotiation, message-rate control, and unicast service management.
Management	Management Message	General Message	0xD	Configures PTP parameters and queries clock state.	Two-way exchange between management entities and clock nodes	Message body consists of a TLV list; used for manual configuration of priority, sync interval, delay mechanism, etc.

Interaction Logic Between PTP Clock Types

To understand PTP synchronization workflows, we must first clarify how each ptp clock type interacts with adjacent nodes through message exchanges.

Based on the context above, we first define the network used in this analysis: the entire PTP domain operates in two-step mode. GM to BC, BC to TC, and TC to OC all use the P2P mechanism.

Note: One-step and two-step are mechanisms in PTP networks for delivering accurate timestamps in event messages such as Sync.

• One-step: A single message is sent. The precise transmission timestamp is inserted into the correction field by hardware at the moment the message leaves the device.
• Two-step: Two messages are sent. After the initial message (for example, Sync), a Follow_Up message is sent to carry the exact transmission timestamp of the first message.

The following section uses this topology to explain how PTP clock types and PTP message exchanges operate together. Concrete examples are provided to illustrate their interactions in practical scenarios.

PTP synchronization is essentially a hierarchical process from GM → intermediate clocks → terminal OCs. The interaction logic is built around three elements: BMCA selection, message exchange, and delay compensation.

GM Layer

GM selection takes place in this layer.. Within a PTP domain, all clocks that participate in PTP (OC/BC) run BMCA (Best Master Clock Algorithm). They compare attributes such as priority1, priority2, clockClass, and clockAccuracy. Different profiles define different selection rules. The algorithm elects the best candidate as the Grandmaster (GM). BMCA not only selects the optimal GM but also determines the working mode of each ptp clock type in the domain.

The elected GM calibrates its local hardware clock (time-of-day clock) using one or more reference sources:

• GNSS (GPS, BeiDou, etc.)
• Upstream SyncE or another PTP domain
• A high-stability oscillator (OCXO or Rubidium) during holdover

A clock servo runs inside the GM to continuously adjust the hardware clock. It keeps the GM aligned with the external time source, such as UTC.

Interaction Between the GM and Boundary Clocks (BCs)

The first synchronization hop occurs between the GM (root ptp clock type) and BCs (relay ptp clock type), using P2P messages for delay measurement.

GM side

The GM has two master ports participating in the PTP domain. These ports connect to the slave ports of BC1 and BC2.

The GM periodically sends two-step Sync / Follow_Up messages and Announce messages to each BC.

BC side

Because the GM–BC links use the P2P delay mechanism, the upstream slave port on each BC periodically exchanges Pdelay_Req, Pdelay_Resp, and (when applicable) Pdelay_Resp_Follow_Up with the GM port.

Using the transmit and receive timestamps taken on the BC side, together with the timestamps carried in the GM’s response messages, the BC calculates the one-way mean path delay for that hop. The result is stored in the peerMeanPathDelay variable of the port.

When the BC’s upstream slave port receives a Sync / Follow_Up from the GM, it already has:

• the GM’s transmit timestamp t1 (preciseOriginTimestamp in the Follow_Up)
• its own receive timestamp t2 (taken on Sync reception)
• the correctionField carried in the Sync message (accumulated residence time and link delay from upstream)
• its local peerMeanPathDelay (computed from the Pdelay exchange)

Using these values, the BC computes its offsetFromMaster relative to the GM. A commonly used approximation is:

offsetFromMaster ≈ t2 − t1 − (correctionField + peerMeanPathDelay)

The BC passes this value to its local clock servo, which adjusts the hardware clock so that it gradually aligns with the GM time.

Interaction Between the BCs and Transparent Clocks (TCs)

After that, the BC continues the hierarchy by sending Sync messages downstream to the TC, using its own local clock as the reference.

BC side

After the BC aligns its local hardware clock to the GM through the upstream slave port, it uses this local time as the reference and sends Sync messages from its downstream master ports toward the TC.

On the BC–TC link, the BC’s downstream port operates as a master and the TC’s upstream port is its peer.

The BC periodically sends two-step Sync / Follow_Up messages and Announce messages to the TC. When a Sync is transmitted from the BC’s downstream port, the port timestamps the message on egress. The Follow_Up then carries this exact transmit timestamp in the preciseOriginTimestamp field.

TC side (P2P Transparent Clock)

Because the BC–TC link also uses the P2P delay mechanism, the TC’s upstream port periodically exchanges Pdelay_Req, Pdelay_Resp, and (when applicable) Pdelay_Resp_Follow_Up with the BC’s master port. Using its own transmit and receive timestamps, together with the timestamps carried in the BC’s response, the TC calculates the one-way mean path delay for that hop and stores it in its peerMeanPathDelay variable.

When the TC’s upstream port receives a Sync / Follow_Up from the BC, it already has:

• the BC’s transmit timestamp t₁′ (preciseOriginTimestamp in the Follow_Up)
• its own receive timestamp t₂′ (taken on Sync reception)
• the current correctionField in the Sync message (accumulated residence time and link delay from GM–BC and any upstream devices)
• its local peerMeanPathDelay (the BC–TC one-way delay computed via Pdelay)

Next, the TC performs an additional operation during message forwarding. When the Sync enters the TC on the upstream port, the port records an ingress timestamp t_in. Before the Sync leaves the downstream port, the TC records an egress timestamp t_out. The difference gives the residence time:

residenceTime = t_out − t_in

The TC then computes the correction value that must be added to the Sync message. This value can be viewed as:

Δcorrection ≈ residenceTime + peerMeanPathDelay

In other words, the TC adds both the time spent inside the device (residenceTime) and the one-way delay of the previous hop (its peerMeanPathDelay) to the Sync’s correctionField. The Sync is then forwarded out the downstream port to the next node, which may be an OC or another BC/TC. The Follow_Up is normally forwarded transparently, without modifying the timestamps, because the time source remains the upstream BC/GM.

Throughout this process, the TC does not compute offsetFromMaster and does not discipline its own hardware clock. Its only function is to update the correctionField by incorporating peerMeanPathDelay and residenceTime, so that downstream slave clocks (OC) can calculate accurate end-to-end delay and time offset.

TC–OC Interaction

The final synchronization link connects the TC (delay-correcting ptp clock type) to the OC (terminal ptp clock type), completing the end-to-end time distribution.

TC side

After the upstream GM→BC→TC segment, the Sync / Follow_Up messages arriving from the BC have already been corrected once inside the TC. The TC has added its own residence time and the one-way delay of the BC–TC hop into the Sync message’s correctionField. The Sync carrying this cumulative correction value is then transmitted from the TC’s downstream port toward the final slave clock (OC).

On this last hop, the TC’s downstream port is directly connected to the OC’s single PTP port.

OC side

The OC is typically not a networking device.

1. Synchronization messages (time information, downstream)
   • Sync: forwarded from the upstream master, through the TC, to the OC
   • Follow_Up: carries the precise transmit timestamp of the associated Sync These two messages transport upstream time information to the OC.
2. Delay-measurement messages (link delay, exchanged bidirectionally)
   • Pdelay_Req: sent by the OC to the TC to measure the link delay for this hop
   • Pdelay_Resp: returned by the TC with the TC-side timestamps
   • Pdelay_Resp_Follow_Up (present only in two-step Pdelay): sent when the TC cannot insert the transmit timestamp into the Resp at the moment of transmission

Using these timestamps, the OC calculates its time offset relative to the GM. The OC then hands this offset to its local clock servo, which disciplines the local hardware clock and gradually aligns it to the GM.

At this point, the full PTP synchronization chain is complete: the GM provides the reference time, the BC distributes it hierarchically, the TC applies cumulative delay corrections, and the OC—acting as the final slave clock—uses Sync / Follow_Up, the accumulated correctionField, and its own peerMeanPathDelay to align its local clock precisely to the GM.

How to Config Clock Profile and PTP Clock Types on Asterfusion

In Asterfusion’s recommended deployment practices, the profile should be determined first before selecting the clock mode.

This is because the behavior of each mode (Master, Slave, Boundary, Transparent) is constrained by the profile. The profile defines whether the delay mechanism uses P2P or E2E, whether messages use Layer-2 multicast or Layer-3 unicast, and the timing templates and message parameters. Only after the profile is fixed can the clock roles be configured correctly and consistent behavior ensured across the network.

Profile Overview and Use Cases

Asterfusion switches support flexible configuration of each ptp clock type, with profile settings directly constraining the behavior of the selected ptp clock type. Asterfusion provides the following PTP profiles:

1. SMPTE-2059-2

• Industry: Broadcasting, media production (SMPTE ST 2110 series)
• Transport: L2 or L3 multicast
• Delay Mechanism: E2E
• Core Requirement: Precise audio/video stream synchronization (frame-level, sub-microsecond)
• Characteristics:
  • Based on IEEE 1588-2008 (PTPv2)
  • Defines specific announce/priorities logic
  • Replaces traditional black-level and tri-level sync in broadcasting

2. IEEE 1588v2 Default Profile

• Industry: General IT and enterprise networks
• Transport: L2/L3 multicast or unicast
• Delay Mechanism: E2E or P2P
• Core Requirement: Standard PTP synchronization, no industry-specific optimization
• Characteristics:
  • Supported by all vendors by default
  • Loose parameters, strong compatibility
  • Medium accuracy (milliseconds to tens of microseconds)

3. AES67 PTP Profile

• Industry: Professional audio networks (AES67, Dante, live audio)
• Transport: Mostly multicast
• Delay Mechanism: E2E
• Core Requirement: Audio sample synchronization (microsecond-level)
• Characteristics:
  • Based on 1588v2 but stricter than Default profile
  • Specifies sync frequency (usually 1 pps or 8 pps)
  • Interoperable with SMPTE audio links; widely used in Dante networks

4. ITU-T G.8275.1 (Full Timing Support, FTS)

• Industry: Telecom mobile backhaul (4G/5G)
• Transport: L2 multicast mandatory
• Delay Mechanism: P2P mandatory
• Core Requirement: Phase synchronization (<1.5 μs), usually combined with SyncE
• Characteristics:
  • Requires full network support for BC/TC
  • Typical sync rate: 16 pps
  • Telecom-specific TLVs

5. ITU-T G.8275.2 (Partial Timing Support, PTS)

• Industry: Cross-operator mobile backhaul, backbone networks
• Transport: IPv4/IPv6 unicast
• Delay Mechanism: E2E
• Core Requirement: Maintain synchronization when parts of the network lack BC/TC
• Characteristics:
  • Slightly lower accuracy than G.8275.1 but more flexible
  • Suitable for large-scale L3 network synchronization

Profile Key Parameter Comparison Table

A comparative table for the five profiles with parameters is available:

Profile	Primary Use	Transport Method	Delay Mechanism	Sync Frequency	Accuracy	Characteristics
SMPTE-2059-2	Broadcasting / Media (ST 2110)	L2/L3 multicast	E2E	Typically 8–16 pps	Microsecond-level	Replaces traditional video sync; industry standard for audio/video
1588v2 Default	General networks	L2/L3	E2E / P2P	Flexible (1–8 pps)	Milliseconds to tens of microseconds	Most widely supported; no industry-specific optimizations
AES67	Professional audio	L2/L3 multicast	E2E	Fixed (1 or 8 pps)	Microsecond-level	Audio sample synchronization; subset of 1588v2
G.8275.1	5G/4G mobile backhaul (FTS)	L2 multicast	P2P	16 pps	<1.5 μs	Full Timing Support; most common in telecom networks
G.8275.2	5G/4G mobile backhaul (PTS)	L3 unicast	E2E	8–16 pps	Microsecond-level	Partial Timing Support; for cross-domain synchronization

PTP Clock Types Selection

In Asterfusion’s configuration guidelines, specific clock types are prescribed for each PTP profile. The detailed settings are shown in the following configuration examples.

Profile	PTP Clock Type
SMPTE-2059-2	OC, BC, E2E TC, P2P TC
1588v2	OC, BC, E2E TC, P2P TC
AES67	OC, BC, E2E TC, P2P TC
G.8275.1	T-GM, T-BC, T-TSC, T-TC
G.8275.2	T-GM, T-BC-P, T-TSC-P

Configuration Sequence for PTP Clock Types

On Asterfusion CX308P-48Y-N-V2, CX532P-N-V2, and CX732Q-N-V2, using a TC as an example, the configuration steps are as follows:

1. Enable PTP Feature Globally

• configure terminal // Enter global configuration view
• feature ptp state enable // Enable PTP feature
• feature ptp autorestart enable // Enable PTP autorestart

2. Configure PTP Domain

• ptp domain 127 // Create PTP domain 127; domain scope differs by profile
• ptp profile smpte-2059-2 // Configure appropriate PTP profile to choose right PTP clock type
• ptp mode e2ec // Configure PTP clock type
• ptp clock-step two_step // Configure timestamp carrying method
• ptp source ip {A.B.C.D|A::B} // Configure PTP message source IP

3. Configure Clock Parameters (optional)
4. Enable PTP on the Interface

• interface ethernet <interface-name> // Enter Ethernet interface view
• ptp domain 127 // Bind the interface to PTP domain
• ptp enable // Enable PTP

5. Configure Delay Measurement Method on Interface (optional)

• configure terminal
• interface ethernet <interface-name>
• ptp delay-mechanism E2E // Configure delay measurement method

Finally, verify PTP clock type with: show ptp clock

For full configuration details, optional parameters, and typical deployment scenarios, refer to the Asterfusion guide: Typical Scenario for PTP

Conclusion

This article connects the complete “GM → BC → TC → OC hierarchical synchronization and delay compensation” process from two angles: PTP clock types (GM, OC, BC, TC, Hardware Clock) and PTP message types:

• The GM, a PTP clock type serving as the domain root, provides the network-wide time reference.
• The BC, a PTP clock type that enables hierarchical time distribution, operates as a Slave on its upstream interface and as a Master on its downstream interface, regenerating and distributing time.
• The TC, a PTP clock type focused on delay compensation, does not participate in BMCA and only updates the correctionField by adding its residence time and the link delay.
• The OC, a PTP clock type acting as the final slave clock, uses Sync and Follow_Up messages, the cumulative correctionField, and its local Pdelay results to calculate offsetFromMaster and adjusts its time based on the local hardware clock

Why Choose Asterfusion for Your PTP Network?

Asterfusion switches are designed to bridge the gap between complex PTP protocols and practical deployment, covering scenarios from Campus Networks to Data Centers.

• Flexible PTP Clock Types: Full support for configuring devices as Boundary Clock (BC) or Transparent Clock (TC) to adapt to your network topology.
• Comprehensive Profile Support: Seamless integration with major PTP profiles including G.8275.1 (Telecom) and SMPTE 2059-2 (Broadcast), supporting both E2E and P2P delay mechanisms.
• High-Precision Standards: Fully compliant with IEEE 1588v2 and SMPTE 2059-2, delivering Class A/C accuracy for critical timing requirements.
• Versatile Deployment: From enterprise campus to high-performance data center, Asterfusion delivers robust PTP functionality across the board.

By mapping the topology and packet interactions described in this article to Asterfusion’s hardware capabilities, network engineers can easily deploy precise, stable, and scalable timing networks.

Product	PTP Time Synchronization ITU Classification	Description
CX306P-48Y-M-H	Class C	• 48×25 Gb SFP28, 6×100 Gb QSFP28• Support IEEE1588v2 and SyncE, GNSS receiver, 1PPS, ToD, 10MHz timing interfaces
CX102S-8MT-M-S CX102S-8MT-M-SWP CX102S-16GT-M-SWP CX102S-16GT-DPU-M-SWP	Class A	• Support different access rates and enabling flexible deployment across diverse application scenarios• Optional PTP module supports SyncE
CX204Y-24GT-M-S CX204Y-24GT-M-SWP2 CX204Y-24GT-M-SWP4 CX206Y-48GT-M-H CX206Y-48GT-M-HWP4 CX206Y-48GT-M-HWP8 CX206P-24S-M-H CX202P-24Y-M-H CX206P-48S-M-H CX308P-48Y-M-H CX532P-M-H CX732Q-M-H CX206Y-48GT-M-H	Class C

Contact US !

• To request a proposal, send an E-Mail to bd@cloudswit.ch
• To receive timely and relevant information from Asterfusion, sign up at AsterNOS Community Portal
• To submit a case, visit Support Portal
• To find user manuals for a specific command or scenario, access AsterNOS Documentation
• To find a product or product family, visit Asterfusion-cloudswit.ch