Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Precision Time Protocol

SUMMARY Precision Time Protocol (PTP) is a time-based protocol, designed to distribute precise time and frequency over packet-switched Ethernet networks.

PTP Overview

PTP, also known as IEEE 1588v2, is a packet-based technology that enables the operator to deliver synchronization services on packet-based mobile backhaul networks. IEEE 1588 PTP (Version 2) clock synchronization standard is a highly precise protocol for time synchronization that synchronizes clocks in a distributed system. The time synchronization is achieved through packets that are transmitted and received in a session between a primary clock and a client clock.

The system clocks can be categorized based on the role of the node in the network. They are broadly categorized into ordinary clocks and boundary clocks. The primary clock and the client clock are known as ordinary clocks. The boundary clock can operate as either a primary clock or a client clock. The following list explains these clocks in detail:

  • Primary clock—The primary clock transmits the messages to the PTP clients (also called client node or boundary node). This allows the clients to establish their relative time distance and offset from the primary clock (which is the reference point) for phase synchronization. Delivery mechanism to the clients is either unicast or multicast packets over Ethernet or UDP.

  • Member clock—located in the PTP client (also called client node), the client clock performs clock and time recovery operations based on the received and requested timestamps from the primary clock.

  • Boundary clock—The boundary clock operates as a combination of the primary and client clocks. The boundary clock endpoint acts as a client clock to the primary clock, and also acts as the primary to all the slaves reporting to the boundary endpoint.

For more information about configuring PTP, see Configure Precision Time Protocol.

Table 1 summarizes the first Junos OS release that supports PTP on various Juniper Networks devices:

Table 1: Precision Time Protocol Support

Juniper Networks Devices

Junos OS Release

MX80 Universal Routing Platforms with model number MX80-P

12.2

MX-MPC2E-3D-P (MPC2E P) on MX240, MX480, and MX960 routers

12.2

MX-MPC2E-3D-P (MPC2E P) on MX2010 and MX2020 routers

12.3

MX-MPC2E- 3D-NG (MPC2E NG)

15.1R2

MPC4E-3D-32XGE-SFPP on MX240, MX480, MX960, MX2010, MX2020

15.1R1

MPC4E-3D-2CGE-8XGE on MX240, MX480, MX960, MX2010, MX2020

15.1R1

MPC3E-3D-NG-Q on MX240, MX480, MX960, MX2010, MX2020

15.1R2

MPC3E-3D-NG on MX240, MX480, MX960, MX2010, MX2020

15.1R2

Following enhanced MPCs support PTP (1588v2):

  • MPC5E-40G10G on MX240, MX480, MX960, MX2010, and MX2020 routers

  • MPC5EQ-40G10G on MX240, MX480, MX960, MX2010, and MX2020 routers

  • MPC5E-100G10G on MX240, MX480, MX960, MX2010, and MX2020 routers

  • MPC5EQ-100G10G on MX240, MX480, MX960, MX2010, and MX2020 routers

  • MX2K-MPC6E on MX2010, and MX2020 routers

14.2R2

Ethernet Modular Interface Cards (MICs) on MX240, MX480, and MX960 routers

12.2

Ethernet Modular Interface Cards (MICs) on MX2010 and MX2020 routers

12.3

On MX240, MX480, MX960, MX2010, and MX2020 routers, the following Enhanced MPCs (MPCEs) support PTP (1588v2) under express licensing only:

  • MPC1E (MX-MPC1E-3D)

  • MPC1E Q (MX-MPC1E-3D-Q)

  • MPC2E (MX-MPC2E-3D)

  • MPC2E Q (MX-MPC2E-3D-Q)

  • MPC2E EQ (MX-MPC2E-3D-EQ)

For more information about obtaining a license, contact JTAC.

12.3

ACX Series Universal Metro Routers

12.2

MPC6E, MPC7E, MPC8E, MPC9E, MPC2E NG, and MPC3E NG on MX2008.

17.2

Fixed port PIC (6xQSFPP) and modular MIC (JNP-MIC1) on MX10003 routers

17.3

Fixed port PICs (4xQSFP28 and 8xSFPP) on MX204 routers

17.4

MPC7E-10G and MPC7E-MRATE on MX240, MX480, MX960, MX2010, MX2020

17.4

MPC8E and MPC9E on MX2010, MX2020

17.4

Note:
  • Unified in-service software upgrade (unified ISSU) is currently not supported when clock synchronization is configured for PTP and Synchronous Ethernet on the MICs and Enhanced MPCEs on MX240, MX480, MX960, MX2010, and MX2020 routers.

  • To switch between the PTP and Synchronous Ethernet modes, you must first deactivate the configuration for the current mode and then commit the configuration. Wait for a short period of 30 seconds, configure the new mode and its related parameters, and then commit the configuration.

PTP over Link Aggregation Group

Junos Supports PTP over LAG based on the recommendation in ITU-T-G.8275.1. For each aggregated Ethernet link configured as PTP primary or client, you can specify one member link of the aggregated Ethernet bundle as primary and another as secondary. PTP switches over to the secondary member in the aggregated Ethernet bundle when the primary aggregated Ethernet link is down. For providing both link-level and FPC-level redundancy, the primary and secondary interfaces of the aggregated Ethernet bundle must be configured on separate line cards. If both primary and secondary are configured on the same line card, it would provide only link-level redundancy.

PTP primary streams are created on the FPC on which the primary interface is present. Announce and sync packets are transmitted on this active PTP aggregated Ethernet link. The line card on the PTP client containing this active PTP aggregated Ethernet link will receive announce and sync packets from the remote primary.

This table summarizes the first Junos OS release that supports PTP over LAG on various Juniper Networks devices:

Table 2: PTP over LAG Support

Juniper Network Devices

PTP over IPv4

PTP over Ethernet

MPC2E NG

17.2R1

MPC3E NG

17.2R1

MPC5E

17.2R1

18.2R1

MPC6E

17.2R1

18.2R1

MPC7E-10G

18.1R1

18.3R1

MPC7E–MRATE

18.1R1

18.3R1

MPC8E

18.1R1

18.3R1

MPC9E

18.1R1

18.3R1

PTP Trace Overview

Precision Time Protocol (PTP), also known as IEEE 1588v2, works on the principle of phase synchronization and frequency synchronization—it synchronizes both frequency and phase, including time of day. Phase synchronization is achieved either by adjusting the phase of the client clock (the router’s internal clock oscillator) discontinuously—by receiving clock signals from the primary clock at irregular periods of time—or by adjusting the phase-locked loop of the client’s internal clock at regular intervals. The accuracy of clock synchronization depends on factors such as packet delay variation, quality of oscillator used, network asymmetry, and so on.

You can implement a path trace mechanism to detect PTP loops that circulate endlessly within a PTP ring of boundary clocks over an IPv4 network. The PTP ring topology implementation uses the 1588v2 path trace mechanism to prevent PTP loops and to provide PTP convergence in the event of any single-point failure.

The following sections explain the path trace mechanism and how it is implemented in a multiple-reference clock PTP ring topology over an IPv4 network. The sections also explain steady state and failure handling in a PTP ring topology:

PTP Ring Topology

A PTP ring topology is a ring topology that consists of one or more reference clocks and several boundary clocks.

Consider a simple ring topology of boundary clocks—BC1 through BC5—driven by one primary PTP reference clock and one backup PTP reference clock—GM-A and GM-B, respectively—as illustrated in Figure 1. Assume that GM-A is superior to GM-B—that is, the quality level of GM-A’s clock is higher than that of GM-B’s clock.

Figure 1: Multiple-reference Clock PTP Ring Topology Multiple-reference Clock PTP Ring Topology

Each boundary clock in the PTP ring is configured as both client and primary to its immediate neighbor to provide seamless PTP reference clock switchover in case of reference or boundary clock failure. For example, in Figure 1 BC2 is both primary and client to both BC1 and BC3, BC3 is both primary and client to BC2 and BC4, and so on.

Path Trace Mechanism for Handling PTP Failures

During the process of synchronization in a PTP ring topology, certain announce messages—timing information messages that are sent from primary to client—might form in an infinite loop (also called PTP loop) in a network trail of boundary clocks. These PTP loops create issues such as a boundary clock potentially synchronizing its local clock with its own timing information, thereby compromising the quality of the recovered clock. The path trace mechanism is used to detect such loops.

A path trace is the route that a PTP announce message takes through the network trail of boundary clocks and is tracked through the path trace TLV in the announce message. A path trace TLV (type, length, and value) is a set of octets in an announce message that includes the TLV type, the length field, and the path sequence. The path trace sequence contains the clock ID of each boundary clock that an announce message traverses through the PTP ring.

One of the principal uses of the path trace mechanism is to detect the so-called rogue announce messages that circulate endlessly in loops in the PTP ring of boundary clocks. A boundary clock detects a PTP loop when it finds its own clock ID in the path trace of the received announce message. When such a loop is detected, the router discards the received announce message.

To view the trail of the announce message or path trace, use the show ptp path-trace detail operational mode command. For more information, see show ptp path-trace detail.

Note:
  • During GRES, the path trace and the best primary clock algorithm information are pushed to the kernel. Therefore, this information is available on the backup Routing Engine as well.

  • When the number of boundary clocks in a topology exceeds 20, the path trace TLV is dropped.

  • Currently, the PTP ring topology is supported only for PTP over IPv4 networks.

Steady State

The PTP ring is considered to be in steady state or operating normally when a router, say BC1, is locked—that is, is connected and synchronized—to a reference clock that has a higher quality level value—higher than the quality level of other reference clocks in the network—and all the other routers in the PTP ring are locked to the reference clock through this router BC1. For example in Figure 1, during steady state, BC1 is locked to GM-A, BC2 and BC5 are locked to BC1, BC3 is locked to BC2, and BC4 is locked to BC5. When the path trace mechanism is implemented in this ring topology, a clock ID is assigned to each boundary clock that, in turn, is included in the path trace TLV within the announce message. Therefore, the path trace TLV in the announce message originating from BC1 has its own clock ID—CID1. Similarly, the announce message from BC2 has its own clock ID—CID2—and BC1’s clock ID–CID1—and so on.

As router BC2 is primary to BC1, BC1 constantly receives BC2’s announce messages. The announce messages from BC2 received on BC1 contains BC1’s own clock ID—CID1—along with BC2’s clock ID—CID2. Because BC1 receives its own clock ID—CID1—in the announce message, BC1 drops BC2’s announce messages. Similarly, BC2 drops BC3’s announce messages as the messages contain BC2’s clock ID—CID2—along with other clock IDs—CID1 and CID3. Note that this behavior is intentional and by design, as is explained in Failure Handling.

Failure Handling

Consider a scenario where the router BC1 crashes in the PTP ring illustrated in Figure 1. This failure is handled in the following way:

  1. The router BC2 stops receiving announce messages from BC1.

  2. The announce messages now received by BC2 are only those sent by BC3. BC2 drops these announce messages because these messages contain BC2’s own clock ID—CID2.

  3. Because BC2 does not receive any valid announce messages, it goes into holdover mode and lowers the value of its announce parameters, such as clock class, which results in BC2 announce messages carrying an inferior clock class.

  4. When BC3 receives these announce messages with inferior clock class from BC2, it in turn announces this inferior clock class to all the downstream routers.

  5. When BC5 eventually receives this announce message with the inferior quality level value from BC4, the best primary clock algorithm running on the BC5 router switches BC5 to GM-B automatically and the BC5 router sends announce messages corresponding to the parameters as set by GM-B.

  6. When BC4 receives this announce message—carrying superior clock class information as compared to that carried by BC3's announce message—the BC4 router switches to BC5. Similarly, BC3 locks to BC4 and then BC2 locks to BC3. In other words, the ring topology shown in Figure 1 converges to a clockwise hierarchy of boundary clocks. This entire process takes a few tens of seconds.

Note that each PTP best primary clock algorithm switchover at each boundary clock is seamless and thereby ensures that the performance of the PTP ring does not degrade. However, when there are multiple simultaneous failures in the ring topology—for example, simultaneous link failures between GM-A and BC1 and between BC4 and BC5—the short-term absolute maximum time interval error (MTIE) might go up to 650ns—for example, between routers BC2 to BC4. Note that this type of multiple failures in a ring topology is rare.

MTIE is a maximum phase variation error that is measured over a period of time, where the error is calculated between the phase variation of a signal with the perfect signal.

PTP Ring Topology Without Path Trace Mechanism

When the PTP path trace mechanism is not implemented, the BC2 router cannot detect announce messages from BC3 that are actually BC2’s looped announce messages. This, in turn, results in BC2 attempting to lock to BC3 (while BC3 is already locked to BC2) and a PTP deadlock is created. Because of the PTP deadlock, there is a significant clock drift over a period of time on both BC2 and BC3 and potentially on all the boundary clocks that can be traced to BC3.

Note that when the crashed router BC1 comes up, it chooses GM-A as its primary, and it sends out announce messages that carry superior clock class information compared to those carried by announce messages sent out by GM-B. The BC2 router’s best primary clock algorithm determines that the BC1’s announce messages carry superior clock class information as compared to BC3’s, resulting in BC2 switching back to BC1. Similarly, BC3 switches back to BC2. This way, the ring topology is restored to the pre-crash topology.

Line Card Redundancy for PTP

Line card redundancy is one the PTP redundancy scenarios possible in a mobile backhaul solution. Multiple client streams are configured across line cards and if the currently active client line card crashes or all streams on that line card lose their timing packets another client line card can take over if it has been primed to do so.

When you configure line card redundancy, client streams are created on appropriate line cards. At this time all of the line cards are in DPLL mode. All of the client streams are primed to receive and process announce messages.

Each line card executes the BMCA algorithm and identifies the best primary and the stream serving the best primary. The line card sends the best primary information to the RE. After receiving best primary information from individual line cards, the RE selects the best primary to serve the BC node. This information is propagated to all of the line cards. Once the best primary is selected by the RE, the regular PTP state machine will be executed.

If the BMCA algorithm results in a stream switchover and the new stream falls on a different line card, a hitless switchover will be triggered. The new client card may be configured in pure PTP or Hybrid mode. The old client card may in pure PTP client or Hybrid client mode. The line cards need to go through following steps:

  • A client line card transition needs to happen via holdover state on the primary line card.

  • FSM needs to convert the old client line card to pure PTP primary mode.

  • On the new client card, FSM needs to be triggered based on pure PTP or hybrid mode of operation. All these transitions need to be hitless.

Note:

Line card redundancy is currently only supported on MPC2E P line cards.

Timing Defects and Event Management on Routing Platforms

Junos OS for ACX Universal Metro Routers supports defect and event management capabilities for timing features. Defects and events are notified in the form of SNMP traps and these SNMP traps are logged into the system log-file (var/log/snmpd). For each of the SNMP traps (timing defects and timing events) that are generated, a message is logged in the clksyncd file (var/log/clksyncd).

Table 1 shows the list of SNMP trap notifications for timing defects and events supported in ACX Universal Metro Routers.

Table 3: SNMP trap notifications for timing defects and events

SNMP Trap

Notification Type

Description

jnxTimingFaultLOS

Defects

Denotes loss of signal

jnxTimingFaultEFD

Defects

Denotes exceeded frequency deviation

jnxTimingFaultLOESMC

Defects

Denotes loss of Ethernet Synchronization Message Channel (ESMC)

jnxTimingFaultQLFailed

Defects

Denotes failure in quality level

jnxTimingFaultLTI

Defects

Denotes loss of timing information

jnxTimingFaultPriSrcFailed

Defects

Denotes the failure of primary source

jnxTimingFaultSecSrcFailed

Defects

Denotes the failure of secondary source

jnxTimingFaultPtpUniNegRateReject

Defects

When acting as primary, this SNMP trap denotes failure or rejects clients for signaling messages. When acting as a client, this SNMP trap denotes failure or client stops receiving signaling messages

jnxTimingEventPriSrcRecovered

Events

Denotes the recovery of primary source

jnxTimingEventSecSrcRecovered

Events

Denotes the recovery of secondary source

jnxTimingEventPriRefChanged

Events

Denotes a change in primary reference such as a change in logical interface or a change from SyncE to BITS/external interface)

jnxTimingEventSecRefChanged

Events

Denotes a change in secondary reference such as a change in logical interface

jnxTimingEventQLChanged

Events

Denotes a change in quality level

jnxTimingEventDpllStatus

Events

Denotes the DPLL status (SyncE, BITS, Hybrid)

jnxTimingEventPtpServoStatus

Events

Denotes the following PTP Servo states:

  • INITIALIZING

  • ACQUIRING (Primary is elected and servo starts acquiring lock)

  • PHASE ALIGNED (Locked to Primary)

  • FREERUN (no PTP source available)

  • HOLDOVER (Member locked to PTP for more than 12 hours and then loses all the PTP sources)

jnxTimingEventPtpClockClassChange

Events

Denotes a change in PTP clock class

jnxTimingEventPtpClockAccuracyChange

Events

Denotes a change in PTP accuracy

jnxTimingEventPtpGMChange

Events

Denotes a change in PTP reference clock

jnxTimingEventHybridStatus

Events

Denotes the following hybrid states:

  • INITIALIZING

  • ACQUIRING (Primary is elected and servo starts acquiring lock)

  • FREQUENCY LOCKED (Frequency locked but acquiring phase)

  • PHASE ALIGNED (Frequency and phase locked)

To configure and generate timing defects and events trap notifications, include the timing-events statement at the [edit snmp trap-group trap-group-name categories] hierarchy level as shown below:

The following is a sample configuration for SNMP timing in ACX Series routers:

SNMP MIB for Timing on Routing Platforms

Junos OS for ACX Universal Metro Routers supports SNMP get, get-next, and walk management capabilities for timing features. These capabilities are enabled through the PTP MIB, SyncE MIB and GPS MIB timing objects.

Note:

The PTP MIB and SyncE MIB timing objects are grouped under the jnxTimingNotfObjects SNMP MIB object.

Table 1 shows the list of SNMP MIB objects supported for SNMP get, get-next, and walk management on ACX Universal Metro Routers.

Table 4: SNMP MIB Objects for get, get-next, and walk management

SNMP MIB

Object

Description

PTP MIB

jnxPtpServoState

Denotes the following PTP Servo states:

  • INITIALIZING

  • ACQUIRING

  • PHASE ALIGNED

  • FREERUN

  • HOLDOVER

  • FREQUENCY LOCKED

jnxPtpServoStateStr

Denotes the PTP Servo state string:

  • INITIALIZING

  • ACQUIRING (Primary is elected and servo starts acquiring lock)

  • PHASE ALIGNED (Locked to Primary)

  • FREERUN (no PTP source available)

  • HOLDOVER (Member locked to PTP for more than 12 hours and then loses all the PTP sources)

jnxPtpClass

Denotes the class of the PTP reference clock.

jnxPtpGmId

Denotes the PTP reference clock identifier.

SyncE MIB

jnxClksyncQualityCode

Denotes the SSM/ESMC quality level of the locked source in decimal format.

jnxClksyncQualityCodeStr

Denotes the SSM/ESMC quality level of the locked source in string format

jnxClksyncIfIndex

Denotes the interface index of the locked source in decimal format.

jnxClksyncIntfName

Denotes the interface name of the locked source in string format.

GPS MIB

jnxGpsRecvStatus

Displays the status of the GPS receiver.

Note:
  • The SNMP get and walk management are supported only for scalar objects.

  • For SyncE objects, the jnxClksyncQualityCode, jnxClksyncQualityCodeStr, jnxClksyncIfIndex, and jnxClksyncIntfName objects displays only for locked source.

You can use the show chassis synchronization extensive, show ptp lock-status detail, show snmp mib get <MIB-timing-objects>, and show snmp mib walk jnxTimingNotfObjects show commands for monitoring and troubleshooting purposes.

The following are the sample show command outputs for reference:

show chassis synchronization extensive

show chassis synchronization extensive

show ptp lock-status detail

show snmp mib get <MIB-timing-objects>

show snmp mib walk jnxTimingNotfObjects

Assisted Partial Timing Support on Routing Platforms

The assisted partial timing support (APTS), which is a Global Navigation Satellite System (GNSS) backed by Precision Time Protocol (PTP), delivers accurate timing and synchronization in mobile backhaul networks.

Note:

The APTS feature is supported only on the Junos OS Release 12.3X54–D25 for ACX500 router.

On the ACX500 router, the APTS feature helps you to configure PTP client ports on a GNSS reference clock serving as the PTP primary.

APTS uses GNSS as the primary time reference at cell site locations, or at an aggregation point close to the cell sites. APTS uses network-based timing distribution to assist and maintain the timing during holdover periods when GNSS is unavailable.

To support this feature, you need an APTS node with GNSS source configured at the [edit chassis synchronization] hierarchy level and PTP boundary clock configured at the [edit protocols ptp] hierarchy level as shown below:

GNSS configuration

PTPoE Configuration

PTPoIP Configuration

The priority of clock source would be GNSS first and then PTP.

You can use the show ptp lock-status detail, show chassis synchronization extensive, and show chassis synchronization gnss extensive show commands to monitor and troubleshoot the configurations.

Global Positioning System (GPS) on Routing Platforms

Global Positioning System (GPS) is a navigation aid system that uses signals from satellites to calculate the actual position of a GPS-capable receiver. These signals are not only used for determining the position of the receiver on Earth but also as a very accurate time base. There are GPS receivers with 10-MHz clock frequency output synchronized to a GPS satellite. The ACX Series router has a SubMiniature version B (SMB) connector that can take 10-MHz sine-wave input from a GPS receiver. To configure this 10-MHz clock from a GPS receiver as a candidate clock source for chassis synchronization, include the gps statement and options at the [edit chassis synchronization source] hierarchy level.

Note:

ACX500 routers do not require an external GPS receiver because the GPS receiver is integrated into the system.

Integrated Global Navigation Satellite System (GNSS) on Routing Platforms

Global Navigation Satellite System (GNSS) is a navigation aid system that uses signals from satellites to calculate the actual position of a GPS-capable receiver. These signals are not only used for determining the position of the receiver on Earth but also as a very accurate time base.

The ACX500 series router has the GNSS receiver integrated into the system. This eliminates the need to have an external GPS receiver. However, you will need a GPS antenna. The ACX500 series routers support GNSS input through SubMiniature version A (SMA) connector. You can configure the GNSS port and its associated parameters at the [edit chassis synchronization] hierarchy level.

You can configure the GNSS port by including the constellation gps] CLI statement at the [edit chassis synchronization port gnss] hierarchy level. If you do not specify a constellation option, then the gps constellation option is considered by default.

The following is the [edit chassis synchronization port gnss] hierarchy level:

Note:
  • The range for cable-length-compensation is from 0 to 50000000 nanoseconds.

  • The integrated GNSS receiver in the ACX500 series routers do not support 10-MHz frequency input and output.

ACX500 series routers support reference clock functionality with the integrated GNSS receiver.

Use the show chassis synchronization gnss command to check the status of the GNSS receiver. For more information, see show chassis synchronization.