Network synchronization

This guide describes network synchronization capabilities available with SR Linux. These capabilities include physical layer frequency distribution via Synchronous Ethernet and packet based distribution of time using the precision time protocol (PTP) of IEEE 1588.

SR Linux supports network synchronization on the following platforms only:

  • 7220 IXR-D5, model 3HE17735AB (w/Timing)
  • 7250 IXR-X1b/X3b
  • 7730 SXR-series platforms: 7730 SXR-1x-44S and 7730 SXR-1d-32D
In the past, physical layer frequency distribution was required to ensure proper operation of the SDH and SONET network interfaces of a network. That requirement is now replaced by the need to support delivery of the following:
  • a reference frequency for mobile base stations to tune their carrier frequencies
  • an accurate frequency for the delivery of time using PTP
Note: SR Linux supports various network synchronization options. SR Linux network element ports can support both synchronous Ethernet and PTP/1588. See Supported synchronization options for more information.

The network time architecture in the following figure shows how network synchronization is commonly distributed in a hierarchical PTP topology at the physical layer.

Figure 1. Conventional network timing architecture (North American nomenclature)

This architecture provides the following benefits:

  • limits the need for high-quality clocks at each network element

  • only requires reliable and accurate replication of the input to remain traceable to its reference

  • uses reliable physical media to provide transport of the timing signal

  • does not consume any bandwidth and requires limited additional processing

The synchronization network is designed so a clock always receives timing from a clock of equal or higher stratum level or quality level. This ensures that if an upstream clock has a fault condition (for example, it loses its reference and enters a holdover or free-run state) and begins to drift in frequency, the downstream clock is able to follow it. For greater reliability and robustness, most offices and nodes have at least two synchronization references that can be selected in priority order (such as primary and secondary).

Additional resiliency can be provided by the ability of the node clock to operate within prescribed network performance specifications in the absence of any reference for a specified period. A clock operating in this mode is said to hold the last known state over (or holdover) until the reference lock is once again achieved. Each level in the timing hierarchy is associated with minimum levels of network performance.

Each synchronization-capable port can be independently configured to transmit data using the node reference timing.

Specifically for synchronous Ethernet, transmission of a reference clock through a chain of Ethernet equipment requires that all equipment supports synchronous Ethernet. A single piece of equipment that is not capable of performing synchronous Ethernet breaks the chain. Ethernet frames still get through, but downstream devices should not use the recovered line timing because it is not traceable to an acceptable stratum source.

Central frequency synchronization subsystem

The timing subsystem has a central clock located on the CPM. The timing subsystem performs many of the duties of the network element clock as defined by Telcordia (GR-1244-CORE) and ITU-T G.781.

The central clock uses the available timing inputs to train its local oscillator. The priority order of these references must be specified using the instance 1 and instance 2 parameters. When the central CPM clock is locked, the clock output is able to drive the clocking on all line cards in the system.

The routers support the selection of node reference using Quality Level (QL) indications. The recovered clock is able to derive its timing from one of the references available on that platform.

The following figure illustrates synchronization reference selection on the 7220 IXR-D5 and 7250 IXR-X1b/X3b. It shows how the recovered clock is able to derive the timing from Synchronous Ethernet ports.

Figure 2. Logical model of the synchronization reference selection (7220 IXR-D5 and 7250 IXR-X1b/X3b)

The following figure similarly illustrates synchronization reference selection on the 7730 SXR-series platforms. It shows how the recovered clock is able to derive the timing from synchronous input ports from any of the following references:

  • Synchronous Ethernet ports

  • GNSS RF ports

  • SyncE/1588 port on the CPM

Figure 3. Logical mode of the synchronization reference selection (7730 SXR-series)

The revert setting controls when the central clock can re-select a previously failed reference.

The following table describes the selection followed for two references in both revertive and non-revertive modes.

Table 1. Revertive and non-revertive timing reference switching operation
Status of reference A Status of reference B Active reference non-revertive case Active reference revertive case

OK

OK

A

A

Failed

OK

B

B

OK

OK

B

A

OK

Failed

A

A

Failed

Failed

Holdover

Holdover

OK

OK

A or B

A

Synchronization Status Message

Synchronization Status Messages (SSM) allow the synchronization distribution network to determine the quality level of the clock sourcing a specific synchronization trail, and to allow a network element to select the best of multiple input synchronization trails. SSM has been defined for synchronous Ethernet for interaction with office clocks, such as BITS or SSUs, and embedded network element clocks.

SSM allows equipment to autonomously provision and reconfigure (by reference switching) their synchronization references, while helping to avoid the creation of timing loops. These messages are particularly useful for synchronization re-configurations when timing is distributed in both directions around a ring.

Central time synchronization subsystem

SR Linux supports GNSS and PTP to provide accurate time, which is essential for OAM timestamping. NTP does not provide sufficient accuracy for 1-way delay measurements for example. GNSS is only supported on a subset of the SR Linux platforms.

SR Linux does not provide a configuration for time reference selection, as there is a preset fixed priority order. By default, if GNSS is available, it is selected. Otherwise, if PTP is available, it is selected.

Figure 4. Default time reference selection

The SR Linux system clock is configured separately and is based on NTP.

Supported synchronization options

The following table summarizes the synchronization options that are available.

Table 2. Supported synchronization options
Synchronization option Supported platform Notes

SyncE with SSM

7220 IXR-D5; model 3HE17735AB (w/Timing)

7250 IXR-X1b/X3b

7730 SXR

Supported for frequency only

1588/PTP with port-based timestamps

7220 IXR-D5; model 3HE17735AB (w/Timing)

7250 IXR-X1b/X3b

7730 SXR

Supported for time only

1pps interface

7220 IXR-D5; model 3HE17735AB (w/Timing)

7730 SXR

Supported for output only

GNSS

7730 SXR only

See GNSS.

SyncE/1588 port

7730 SXR only

Supported for frequency only