阅读说明：本技术 同步的网络设备之间的时钟故障检测和校正 (Clock fault detection and correction between synchronized network devices ) 是由 S·K·斯 K·S·戈帕拉克里什南 于 2020-08-24 设计创作，主要内容包括：本申请的各实施例涉及同步的网络设备之间的时钟故障检测和校正。第一网络设备可以从第二网络设备接收与第二网络设备的时钟相关联的时钟质量指示,其中第二网络设备的时钟是针对包括第一网络设备和第二网络设备的网络的基准时钟。第一网络设备可以基于第二网络设备的时钟信号来确定时钟的质量度量不满足阈值。第一网络设备可以向第二网络设备提供时钟故障通知,以引起第二网络设备降级由第二网络设备传输的时钟质量指示。第一网络设备可以基于从第二网络设备接收到所降级的时钟质量指示来针对第一网络设备选择新的基准时钟。(Embodiments of the present application relate to clock failure detection and correction between synchronized network devices. The first network device may receive, from the second network device, a clock quality indication associated with a clock of the second network device, wherein the clock of the second network device is a reference clock for a network including the first network device and the second network device. The first network device may determine, based on a clock signal of the second network device, that a quality metric of the clock does not satisfy a threshold. The first network device may provide a clock failure notification to the second network device to cause the second network device to degrade a clock quality indication transmitted by the second network device. The first network device may select a new reference clock for the first network device based on receiving the degraded clock quality indication from the second network device.)

1. A method, comprising:

receiving, by a first network device from a second network device, a clock quality indication associated with a clock of the second network device,

wherein the clock of the second network device is a reference clock for a network including the first network device and the second network device;

determining, by the first network device, based on a clock signal of the second network device, that a quality metric of the clock does not meet a threshold;

providing, by the first network device, a clock failure notification to the second network device to cause the second network device to degrade the clock quality indication transmitted by the second network device;

selecting, by the first network device, a new reference clock for the first network device based on receiving the degraded clock quality indication from the second network device.

2. The method of claim 1, wherein the clock quality indication is received via an ethernet communication layer of the network, and

wherein the clock signal is received via a physical communication layer of the network.

3. The method of claim 1, wherein the new reference clock is associated with a third network device of the network comprising the first network device and the second network device, and

wherein the new reference clock is used to synchronize the first network device and the third network device.

4. The method of claim 3, wherein the first network device is located downstream from the second network device and the third network device within a topology of the network.

5. The method of claim 1, wherein the clock quality indication associated with the clock of the second network device has a higher priority than a clock quality indication associated with the new reference clock.

6. The method of claim 1, wherein providing the clock failure notification comprises:

inserting a fault code within an unused field of a synchronization status message associated with the type of synchronization status message indicated by the clock quality,

wherein the first network device and the second network device are configured to detect the fault code; and

providing the synchronization status message as the clock failure notification.

7. The method of claim 1, wherein the network comprises a synchronous ethernet network, and

wherein the clock quality indication, the clock failure notification, and the new clock quality indication are synchronization status messages transmitted via an Ethernet synchronization message channel of the synchronous Ethernet network.

8. A first network device, comprising:

one or more memories; and

one or more processors configured to:

a quality metric of the clock signal is measured,

wherein the clock signal is associated with a clock of a second network device, an

Wherein the clock of the second network device is a reference clock for the first network device and the second network device;

determining, based on the clock signal, that the quality metric does not meet a threshold;

providing a clock failure notification to the second network device based on the threshold not being met to cause the second network device to degrade a clock quality indication transmitted by the second network device; and

performing an action associated with establishing a new reference clock for the first network device.

9. The first network device of claim 8, wherein the clock quality indication and the clock signal are received from the second network device.

10. The first network device of claim 8, wherein the first network device and the second network device are routers of a synchronous ethernet network.

11. The first network device of claim 8, wherein the clock quality indication is received via an Ethernet communication layer of the network, and

wherein the clock signal is received via a physical communication layer of the network.

12. The first network device of claim 8, wherein the one or more processors are configured to:

receiving the degraded clock quality indication from the second network device,

selecting the new reference clock based on a different clock quality indication associated with the new reference clock; and is

Forwarding the second clock quality indication to one or more other network devices to cause the one or more other network devices to use the new reference clock.

13. The first network device of claim 12, wherein the new reference clock is associated with a third network device of the network, and

wherein the new reference clock is configured to synchronize the first network device and the third network device.

14. The first network device of claim 8, wherein the one or more processors, when providing the clock failure notification, are configured to:

a fault code is inserted in a field of the first type of synchronization status message,

wherein the clock quality indication is associated with a second type of synchronization status message different from the first type,

wherein the first network device and the second network device are different types of network devices; and

providing the synchronization status message as the clock failure notification.

15. A system, comprising:

a first network device configured to:

receiving a clock quality indication associated with a clock of the second network device,

wherein the clock of the second network device is a reference clock for a network including the first network device and the second network device;

determining, based on a clock signal of the second network device, that a quality metric of the clock does not meet a threshold; and

providing a clock failure notification to the second network device to cause the second network device to degrade the clock quality indication.

16. The system of claim 15, wherein the clock quality indication is received via an ethernet synchronization message channel of the network, and

wherein the clock signal is received via a physical communication layer of the network.

17. The system of claim 15, wherein the first network device, in determining that the quality metric of the clock does not satisfy the threshold, is further configured to:

analyzing the clock signal via a phase locked loop of the first network device to determine the quality metric;

comparing the quality metric to the threshold; and

determining that the quality metric does not satisfy the threshold.

18. The system of claim 15, wherein the first network device is further configured to:

selecting a new reference clock for the first network device; and

providing, to one or more other network devices, a clock quality indication associated with the new reference clock.

19. The system of claim 15, wherein the network is a synchronous ethernet network.

20. The system of claim 15, wherein the first network device, in providing the clock failure notification, is further configured to:

determining a configuration of the second network device; and

providing the clock failure notification as a failure code within one of:

an unused field of a first type of synchronization status message associated with the clock quality indication, or

A field of a second type of synchronization status message different from the first type of synchronization status message.

Technical Field

Embodiments of the present application relate to clock failure detection and correction between synchronized network devices.

Background

In some networks, timing may be critical to telecommunications system performance. For example, in some networks, a synchronous clock may be required at both the source node and the destination node. Synchronous networks, such as synchronous ethernet networks, facilitate the transmission of clock signals over the physical layer to provide synchronization signals to network resources that may ultimately require synchronization.

Disclosure of Invention

According to some implementations, a method may include: receiving, by a first network device from a second network device, a clock quality indication associated with a clock of the second network device, wherein the clock of the second network device is a reference clock for a network comprising the first network device and the second network device; determining, by the first network device, that a quality metric of the clock does not meet a threshold based on a clock signal of the second network device; providing, by the first network device, a clock failure notification to the second network device to cause the second network device to downgrade (downgrade) the clock quality indication transmitted by the second network device; selecting, by the first network device, a new reference clock for the first network device based on receiving the degraded clock quality indication from the second network device.

According to some implementations, a first network device may include one or more memories and one or more processors. In some implementations, the one or more processors are communicatively coupled to the one or more memories. The one or more processors may be configured to: measuring a quality metric of a clock signal, wherein the clock signal is associated with a clock of a second network device, and wherein the clock of the second network device is a reference clock for the first network device and the second network device; determining, based on the clock signal, that the quality metric does not meet a threshold; providing a clock failure notification to the second network device based on the threshold not being met to cause the second network device to degrade a clock quality indication transmitted by the second network device; and performing an action associated with establishing a new reference clock for the first network device.

According to some implementations, a system may include a first network device configured to: receiving a clock quality indication associated with a clock of a second network device, wherein the clock of the second network device is a reference clock for a network comprising the first network device and the second network device; determining, based on a clock signal of the second network device, that a quality metric of the clock does not meet a threshold; and providing a clock failure notification to the second network device to cause the second network device to degrade the clock quality indication.

Drawings

1A-1F are diagrams of example implementations described herein;

FIG. 2 is a diagram of an example implementation described herein;

FIG. 3 is a diagram of one or more example clock failure notification configurations described herein;

FIG. 4A is a diagram of an example process for a network device to detect a clock failure as described herein;

FIG. 4B is a diagram of an example process in which a network device described herein experiences a clock failure;

FIG. 5 is an illustration of an example environment in which systems and/or methods described herein may be implemented;

FIG. 6 is a diagram of example components of one or more of the devices of FIG. 5;

FIG. 7 is a diagram of example components of one or more of the devices of FIG. 5; and

fig. 8-10 are flowcharts of example processes related to clock failure detection and correction between synchronized network devices.

Detailed Description

The following detailed description of example implementations refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements.

In synchronous networks, such as synchronous ethernet networks, network devices may be synchronized by sharing a clock signal on the physical layer. The network device may transmit an indication of the quality of the clock signal to each network device via the packet. For example, the first network device may receive, via the packet, the first physical clock signal and an indication of the quality of the first clock signal from the second network device. The first network device may receive, via the packet, the second physical clock signal and an indication of a quality of the second clock signal from the third network device. The first network device may determine that the clock signal from the second network device should be used as a reference clock for the network (e.g., based on comparing an indication of the quality of the clock signals from the second network device and the third network device).

The first network device may provide the clock signal of the second network device to the third network device and indicate to the third network device that the clock signal of the second network device is to be used to synchronize the first network device, the second network device, and the third network device. However, if the clock signal of the network device fails (e.g., due to an error of the network device, degradation of hardware of the network device, bad ports, bad line cards, etc.), the network device may continue to transmit an indication of the quality of the clock signal via packets that do not reflect the actual quality of the physical clock signal (e.g., the network device may continue to transmit an indication that the clock signal quality is high when the actual quality of the clock signal is bad). Another network device (e.g., a first network device) may receive an indication of a quality of a clock signal (e.g., indicating a high quality clock signal) and select the clock signal as the reference clock based on the indication of the quality of the clock signal. As a result, a poor physical clock signal may be selected (e.g., due to a clock signal failure of the reference clock) and transmitted to other network devices of the network and used to synchronize the network devices. Furthermore, network devices that use a poor clock signal to synchronize the synchronous network may degrade the performance and reliability of communications sent by the network devices over the synchronous network.

Some implementations described herein enable clock failure detection and correction between synchronized network devices. For example, a first network device may be configured to compare a quality metric of a physical clock signal received from another network device to a threshold. The first network device may determine that a clock of another network device has failed based on determining that a quality metric of the clock signal does not satisfy a threshold. The first network device may send a clock failure notification to the other network device to cause the other network device to degrade a clock quality indication transmitted by the other network device via the packet. The first network device may select a different clock signal as a reference clock for the synchronous network based on receiving a degraded clock quality indication from another network device. As a result, the synchronous network will not use a bad clock signal to synchronize the network devices of the synchronous network. This may save computational and/or network resources that would otherwise be used to synchronize network devices of the synchronous network using a poor clock signal. Furthermore, ensuring that network devices that do not use a poor clock signal to synchronize the synchronous network may improve the performance and reliability of communications sent by the network devices over the synchronous network.

Fig. 1A-1E are diagrams of an example implementation 100 described herein. As shown in fig. 1A-1E, the example implementation 100 includes synchronizing multiple network devices (e.g., R0, R1, R2, and R3) within a network. R2 may be a first network device, R0 may be a second network device, R1 may be a third network device, and R3 may be a fourth network device. R2 may be located between R0 and R1 and R3 within the topology of the synchronous network (e.g., R0 and R1 may be located upstream of R2 in the synchronous network topology (e.g., before R2 in the synchronous network topology) and R3 may be downstream of R2 in the synchronous network topology (e.g., after R2 in the synchronous network topology). in some implementations, R0, R1, and/or R2 may be router devices, switching devices, server devices, wireless nodes, etc.

Network devices (e.g., R0, R1, R2, R3, etc.) may transmit clock signals at the physical layer of the network. The network devices may synchronize (e.g., based on the clock signal and a clock quality indication associated with the clock signal arriving through the packet) the internal clocks using a selected reference clock (e.g., a clock from a network device of the synchronous network) to form a chain or tree of interconnected ethernet device clocks (EECs). The EEC may be based on a master reference clock (PRC) (e.g., the source of the EEC may be tracked to the PRC, which may be the selected reference clock). The synchronous network may be a synchronous ethernet network that uses a synchronous ethernet protocol to synchronize network devices within the synchronous network (e.g., using a reference clock of the synchronous network).

As shown in fig. 1A and reference numeral 110, R2 may monitor the clock quality of one or more clocks of the synchronous network based on a clock quality indication (e.g., QL as shown in fig. 1A-1E) and clock signals received from other network devices of the synchronous network (e.g., R0, R1, etc.). The clock quality indication may indicate a quality of a clock signal transmitted by the network device. The clock quality indication may indicate: the clock signal is associated with a master reference clock (e.g., PRC), the clock signal is associated with a synchronization providing unit (e.g., SSU), the clock signal is associated with a Synchronous Digital Hierarchy (SDH) device clock (e.g., SEC), the clock signal should not be used (e.g., DNU), and so on. The clock quality indications may be prioritized such that a network device receiving the clock quality indications may select a clock signal as a reference clock for the synchronous network based on the priority of the clock quality indications. For example, according to ITU-T standard g.8264, the clock quality indications may be prioritized such that the indication of PRC has the highest priority, followed by the indication of SSU, followed by the indication of SEC. In some implementations, the indication of the SSU may include a higher priority SSU (e.g., SSU-a) and a lower priority SSU (e.g., SSU-B). In some implementations, the network device selects the clock signal associated with the highest priority clock quality indication as the reference clock for the synchronous network.

The clock quality indication may be transmitted via an ethernet communication layer (e.g., indicated by solid lines in fig. 1A-1E) of the synchronous network. The ethernet communication layer may be an ethernet synchronization message channel of the network. For example, the clock quality indication may be sent within the packet using packet-based communication, using an Ethernet Synchronous Message Channel (ESMC), or the like. The clock quality indication may be included in a Synchronization Status Message (SSM), may be sent as an SSM, and so on. The clock quality indication may be indicated in a Type Length Value (TLV) field of the SSM. For example, the SSM may include a TLV field that includes a value. The value may indicate a clock quality indication (e.g., PRC, SSU, SEC, DNU, etc.).

The clock signal may be transmitted via a physical layer of the synchronous network (e.g., represented by dashed lines in fig. 1A-1E). The clock signal may be a frequency generated by the network device (e.g., by a clock module of the network device). The clock signal may be received via a Phase Locked Loop (PLL) of the network device. The clock signal may be associated with one or more quality metrics, such as frequency error rate, frequency accuracy level, frequency drift, noise transfer level, noise generation level, retention performance level, and the like. The quality metric may be measured in parts per million (ppm). The quality metric may indicate a quality level (e.g., a good amount, a poor quality, etc.) of the clock signal. The network device may measure or determine the quality metric via a PLL of the network device.

As shown in FIG. 1A, R2 may receive a clock signal (e.g., Clk-0) and an associated clock quality indication (e.g., PRC) from R0. R2 may receive a clock signal via a PLL associated with R2. The R2 may receive a clock quality indication via a first port (e.g., P2-1) of R2. R2 may determine that the clock signal of R0 should be selected as the reference clock of the synchronous network based on the Best Master Clock Algorithm (BMCA). The BMCA may compare the clock quality indication received from R2 with clock quality indications received from one or more other network devices (e.g., R1, etc.) to verify inputs, compare the clock quality indications, select a reference clock, and so on. For example, R2 may determine that the clock signal of R0 should be selected as the reference clock for the synchronous network based on the clock quality indication received from R0. In this case, R0 may convey an indication that the clock quality of the clock signal is PRC (e.g., indicating that the clock signal transmitted by R0 is associated with PRC of the synchronous network, the clock signal transmitted by R0 is of high quality, the clock signal transmitted by R0 is associated with the highest priority, etc.). R1 may transmit a clock quality indication of the R1 clock signal of an SSU (e.g., SSU-A, SSU-B, etc.). R2 may compare the clock quality indication (e.g., PRC) received from R0 with the clock quality indication (e.g., SSU) received from R1. The R2 may select the clock signal of R0 as the reference clock based on the clock quality indication received from R0 having a higher priority than the clock quality indication received from R1.

In some implementations, the clock signal (e.g., Clk-0) may be the clock signal generated by R0. In some implementations, R0 may receive a clock signal from a network device (not shown in fig. 1A) upstream of R0. As described above, R0 may determine that the clock signal from the network device upstream of R0 should be selected as the reference clock (e.g., based on the clock quality indication associated with the clock signal from the network device upstream of R0 and using BMCA, as described above). R0 may generate a clock signal (e.g., Clk-0) that is the same as (e.g., matches) the clock signal received from the network device upstream of R0. The R0 may transmit the clock signal and a clock quality indication of the PRC to other network devices downstream of R2 and/or R0.

In some implementations, R2 may transmit a clock signal and a clock quality indication to R0. In this case, since R2 has determined that the clock signal of R0 should be selected as the reference clock for the synchronous network, R2 may transmit a clock quality indication for the DNU to R0 (e.g., indicating that R0 should continue to use Clk-0 as the reference clock and that R0 should not select the physical clock sent by R2 to R0).

R2 may generate the same clock signal (e.g., Clk-0) as the clock signal received from R0 based on determining that the clock signal of R0 should be selected as the reference clock for the synchronization network. R2 may transmit clock quality indications of clock signals Clk-0 and PRC to R1. The clock quality indication transmitted by R2 to R1 may indicate to R1 that the clock signal transmitted by R2 should be used as the reference clock for the synchronous network. As a result, R1 may determine that the clock signal transmitted by R2 should be selected as the reference clock for the synchronization network (e.g., using BMCA in a manner similar to that described above). R1 may generate the same clock signal (e.g., Clk-0) as received from R2 and transmit the clock signal along with an indication of the clock quality of the PRC to other network devices downstream of R1.

Similarly, R2 may transmit a clock signal (e.g., Clk-0) and an associated clock quality indication (e.g., PRC) to one or more downstream network devices, such as R3. This may cause the downstream network device to select the clock signal (e.g., Clk-0) transmitted by R2 as the reference clock.

In some implementations, the clock signal Clk-0 transmitted by R0 may be a poor quality clock signal. For example, the clock signal generated by R0 may have a high frequency error rate (e.g., 4.1ppm, etc.) due to a fault associated with R0. In some implementations, the higher frequency error rate may be based on a fault associated with R0. The fault may be a transmission fault (e.g., a fault of a port based on R0, a fault of a line card of R0, a fault of an optical module used at R0, etc.), a hardware fault associated with generating a clock signal, etc. In some implementations, the higher frequency error rate may be based on a failure associated with a network device upstream of R0 (e.g., a network device transmitting a clock signal to R0). However, R0 may not be able to detect a high frequency error rate because R0 can only select the reference clock and match the clock of R0 to the selected reference clock. In some implementations, R0 may not detect a transmission failure associated with sending a clock signal (e.g., because the internal hardware of R0 generating the clock signal may not fail). As a result, R0 may transmit a clock signal with a higher frequency error rate to R2 while indicating (e.g., via a clock quality indication) that the clock signal is associated with a high quality (e.g., 0ppm frequency error rate, etc.) clock signal. This may cause R2 to select the clock signal transmitted by R0 and drive the clock signal to R1 and/or other downstream network devices (e.g., R3, etc.) at a higher frequency error rate while indicating (e.g., via a clock quality indication) that the clock signal is associated with a high quality clock signal.

As shown in fig. 1B and reference numeral 120, R2 may determine that the quality metric of the clock signal received from R0 does not satisfy a threshold (e.g., does not satisfy a threshold, is not within a threshold range, etc.). As described above, R0 may indicate in the clock quality indication (via SSM packets) that the clock quality of the clock signal transmitted by R0 is PRC (e.g., indicating that the clock signal of R0 should be used as the reference clock for the synchronous network). For example, R2 may be configured with one or more threshold quality metrics (e.g., frequency error rate, frequency accuracy, etc.). The threshold quality metric may indicate that the quality metric of the physical clock signal must satisfy a particular value (e.g., in ppm), must be within a particular value range, and so on.

R2 may determine a quality metric associated with the clock signal received from R0. For example, R2 may analyze or measure the clock signal received from R0 to determine a quality metric. R2 may determine or measure a quality metric of the clock signal of R0 via the PLL (or the like) of R2 (e.g., R2 may input the clock signal of R0 into the PLL of R2 to measure or determine the quality metric). As a result, R2 may determine that an error (e.g., a clock failure) associated with the clock signal received from R0 has occurred based on the quality metric of the clock signal received from R0 not satisfying the threshold.

As shown in fig. 1C and reference numeral 130, R2 may provide clock fault feedback to R0 using the clock quality indication provided to R0 (e.g., as described above with respect to fig. 1A). For example, R2 may provide a clock failure notification to R0 via SSM packets to notify R0 that the clock signal transmitted from R0 to R2 is bad (e.g., the quality metric of the clock signal does not meet the threshold, as described above). During this time, since the clock quality indication received from R0 has not changed (e.g., the clock quality indication transmitted by R0 is still PRC), R2 may continue to use the clock signal from R0 as the reference clock.

The clock fail notification may be an indication in the TLV field of the SSM transmitted to R0. In some implementations, the SSM may be the same type of SSM used to transmit the clock quality indication (e.g., if R0 is an updated or enhanced network device, as described below with respect to fig. 3). In some implementations, the SSMs may be different types of SSMs (e.g., if R0 is not configured to detect clock failure notifications in SSMs). Examples of one or more clock failure notifications are discussed in more detail below with reference to FIG. 3.

As shown in fig. 1D and reference numeral 140, the clock failure notification may be configured to cause R0 to degrade the clock quality indication transmitted by R0 (e.g., to a lower priority clock quality indication, to a clock quality indication of a DNU, to a clock quality indication indicating a clock failure, etc.). For example, based on the clock failure notification received from R2, R0 may transmit a clock quality indication of the DNU to R2.

As indicated by reference numeral 150, R2 may select the clock signal of R1 (e.g., Clk-1) as the new reference clock based on receiving the degraded clock quality indication from R0. For example, R2 may select the clock signal of R1 as the new reference clock in a manner similar to that described above (e.g., using BMCA, etc.). R2 may compare the clock quality indication (e.g., SSU) received from R1 with the clock quality indication (e.g., DNU) received from R0. The R2 may select the clock signal of R1 based on the clock quality indication received from R1 having a higher priority than the clock quality indication (e.g., degraded clock quality indication) received from R0. In some implementations, when determining a clock signal to select as a new reference clock for the synchronous network, R2 may receive the clock signal and associated clock quality indication from one or more other network devices. The R2 may transfer a clock quality indication of the DNU to the D1 based on selecting the clock signal of R1 as the reference clock (e.g., indicating to R1 that R1 should not use the clock signal sent by R2 as the reference clock).

As indicated by reference numeral 160, R2 may provide the selected reference clock to R0, R3, and/or one or more other network devices. For example, R2 may generate the same clock signal (e.g., Clk-1) as the clock signal received from R1. The R2 may transmit the clock signal and associated clock quality indication (e.g., SSU) to R0 and/or R3. For example, R2 may transmit a clock signal (e.g., Clk-1) to R0 and/or R3 via the physical layer of the synchronous network. R2 may transmit a clock quality indication of the SSU to R0 and/or R3 via the ESMC of the synchronous network. As a result, a clock signal (e.g., Clk-1) may be selected as a reference clock for R0, R1, R2, and/or R3, and may be used to synchronize R0, R1, R2, and/or R3 (e.g., according to a synchronous ethernet protocol). In some implementations, R0 may not select the clock signal of R1 as the reference clock. For example, R0 may receive a clock quality indication of the PRC from one or more other network devices (not shown) upstream of R0. As a result, R0 may select the clock signals transmitted by one or more other network devices because the clock quality indications (e.g., PRCs) transmitted by one or more other network devices have a higher priority than the clock quality indications (e.g., SSUs) transmitted by R1.

As shown in FIG. 1E, an alternative to FIG. 1D is shown. That is, the network device may perform the actions described with respect to fig. 1D or the actions described with respect to fig. 1E. Whether a network device performs the actions described with respect to fig. 1D or fig. 1E may be based on whether R0 is a legacy network device (e.g., not configured to detect clock failure notifications) or an enhanced or updated network device (e.g., configured to detect clock failure notifications). If R0 is an enhanced or updated network device (e.g., configured to perform one or more of the functions described herein), the network device may perform the actions described with respect to fig. 1D. If R0 is a legacy network device, the network device may perform the actions described with respect to FIG. 1E. In some implementations, R0 may not be configured to detect clock failure notifications. For example, R0 may be a legacy network device (e.g., may not be updated, may not be upgraded, or may not be able to detect a clock failure notification). In this case, R0 may not perform any action associated with receiving a clock failure notification.

As indicated by reference numeral 170, after R2 provides clock failure notification to R0, R0 may not degrade the clock quality indication transmitted by R0 to R2. That is, R2 may continue to transmit the clock quality indication of the PRC to R0. For example, if R0 is not configured to detect clock quality notifications, R0 may continue to transmit clock quality indications for PRCs because R0 may ignore clock failure notifications, drop packets carrying clock failure notifications (e.g., based on R0 being configured to handle packet types), and so on. For example, if R0 is a legacy network device, R2 may transmit the clock failure notification in a new type of SSM different from the type of SSM used to transmit the clock quality indication. R0 may not be configured to handle the new type of SSM and thus may drop the new type of SSM carrying the clock fail notification. The configuration of clock failure notification for conventional network devices is discussed in more detail below with reference to fig. 3.

As indicated by reference numeral 180, R2 may continue to use the clock signal of R0 (e.g., Clk-0) as the reference clock based on the indication that R0 is not degrading the clock quality transmitted to R2. For example, the clock quality indication transmitted by R0 may still be a PRC that has a higher priority than the clock quality indication (e.g., SSU) transmitted by R1. As a result, R2 may continue to select the clock signal of R0 instead of the clock signal of R1. In this way, R2 may continue to transmit the clock signal of Clk-0 and the clock quality indication of the PRC to R1, R3, and/or one or more other network devices.

As shown in fig. 1F and reference numeral 190, the provision of a new reference clock signal (e.g., Clk-1) by R2 may cause R0 and/or R3 to use the clock of R1 as the new reference clock for the synchronous network and transmit the clock signal (e.g., Clk-1) and the clock quality indication of the SSU (e.g., the clock quality indication transmitted by R1) to other network devices. For example, R0 and/or R3 may select the clock signal of R1 as the reference clock for the synchronous network. As a result, R0 and/or R3 may transmit the clock signal of R1 and the associated clock quality indication of the SSU to one or more other network devices of the synchronous network. This may cause one or more other network devices of the synchronous network to select the clock signal of R1 as the reference clock of the synchronous network. In some implementations, if R0, R3, and/or one or more other network devices are receiving a higher priority clock quality indication (e.g., PRC) from another network device, R0, R3, and/or one or more other network devices may select the clock signal of the network device transmitting the higher priority clock quality indication instead of the clock signal of R1.

As a result, network devices of the synchronous network may synchronize using the clock signal of R1 instead of the clock signal of R0 that is determined to be associated with clock failure or poor quality. Thus, the synchronous network will not use a poor clock signal (e.g., Clk-0) to synchronize the network devices of the synchronous network. This may save computational and/or network resources that would otherwise be used to synchronize network devices of the synchronous network using a poor clock signal. Furthermore, ensuring that network devices that do not use a poor clock signal to synchronize the synchronous network may improve the performance and reliability of communications sent by the network devices over the synchronous network.

As shown above, fig. 1A to 1F are provided as examples. Other examples may differ from the examples described with respect to fig. 1A-1F. The number and arrangement of the devices shown in fig. 1A to 1F are provided as examples. In practice, there may be more devices, fewer devices, different devices, or differently arranged devices than those shown in fig. 1A-1F. Further, two or more devices shown in fig. 1A to 1F may be implemented within a single device, or a single device shown in fig. 1A to 1F may be implemented as a plurality of distributed devices. Additionally or alternatively, a set of devices (e.g., one or more devices) shown in fig. 1A-1F may perform one or more functions described as being performed by another set of devices shown in fig. 1A-1F.

FIG. 2 is a diagram of an example implementation 200 described herein. As shown in fig. 2, the example implementation 200 includes a network device (e.g., R2) receiving a clock quality indication (QL) from a second network device (e.g., R0) and a third network device (e.g., R1) in a synchronous network. R0, R1, and R2 may correspond to network devices R0, R1, and R2 described above with reference to fig. 1A through 1E.

As shown in fig. 2, R2 may select different clocks as the reference clock for the synchronous network at different points in time. For example, as indicated by the circled arrow, R2 may select the clock signal received from R0 or R1 based on the clock quality indication received from R0 or R1 and/or the clock failure detected by R2. R2 may receive the clock signal and the clock quality indication and select the reference clock in a manner similar (or identical) to that described above with respect to fig. 1A-1F.

Clock quality indications received from different network devices may be received in different ports of R2. For example, the clock quality indication received by R2 from R0 may be received in a first port (e.g., P2-1) of R2. The clock quality indication received by R2 from R1 may be received in a second port (e.g., P2-2) of R2.

As shown in FIG. 2 and reference numeral 205, R2 may receive a clock quality indication of a master reference clock (PRC) from R0 via port P2-1 of R2. As indicated by reference numeral 210, R2 may determine that R1 is not transmitting a clock at the time (e.g., no clock) or that the clock quality indication transmitted by R1 is a lower priority (e.g., SSU). As a result, R2 may select the clock of R0 as the reference clock for the synchronous network. R2 may determine that the physical clock signal received from R0 has failed (e.g., based on determining that a quality metric of the clock signal received from R0 does not meet a threshold in a manner similar to that described above with respect to fig. 1A-1F). R2 may transmit a clock failure notification to R0 based on determining that a clock failure has occurred. As a result, R0 may downgrade the clock quality indication transmitted by R0 to unused (DNU), as indicated by reference numeral 215.

As indicated by reference numeral 220, the port P2-2 of R2, which may have R2, receives a clock quality indication of the SSU from R1. R2 may select the clock of R1 as the reference clock for the synchronous network based on detecting a clock failure associated with R0, the R0 degrading the clock quality indication to DNU, and/or the clock quality indication of R1 from the SSU. For example, even if the clock quality indication (e.g., PRC) transmitted by R0 indicates a high quality clock, the clock signal transmitted by R0 may have a high frequency error rate (e.g., 4.1PPM, etc.). The clock signal of R1 may have a lower frequency error rate (e.g., 0ppm, etc.) even if the clock quality indication (e.g., SSU) transmitted by R1 indicates a lower priority than the clock quality indication transmitted by R0. As a result, R2 may be enabled to select a clock signal having a lower frequency error rate (e.g., the clock signal transmitted by R1) as the reference clock even if the clock quality indication (e.g., SSU) transmitted by R1 has a lower priority than the clock quality indication initially transmitted by R2 (e.g., the clock quality indication initially transmitted by R2 is PRC, but is now DNU, which enables R2 to select the clock signal transmitted by R1 as the reference clock).

As indicated by reference numeral 225 and reference numeral 235, R2 may receive other clock quality indications from R0, and may determine that the clock quality indications indicate that the DNU or R0 clock has not recovered from a clock failure (e.g., as indicated by the arrow labeled "clock failure" in fig. 2). As indicated by reference numeral 230, R2 may continue to select the clock of R1 as the reference clock for the synchronous network during that time.

As indicated by reference numeral 240, R2 may determine that the clock of R1 has failed (e.g., based on determining that a quality metric of the clock signal received from R1 does not meet a threshold in a manner similar to that described above with respect to fig. 1A-1F). R2 may transmit a clock failure notification to R1. Further, R2 may determine that the clock of R0 has not recovered from the clock failure. As a result, during this time (e.g., where all clock signals received by R2 have not recovered from the clock failure), R2 may not select a clock for synchronizing the reference clock of the network. During this time, R2 may be in a hold state or a free-running state.

As indicated by reference numeral 245, R2 may determine that the clock quality indication transmitted by R0 is a DNU, while the clock quality indication is initially a PRC. As a result, R2 may not select the clock of R0 as the reference clock for the synchronous network. R2 may determine that the clock of R1 has recovered from the clock failure (e.g., based on an indication received from R1, based on a determination that a quality metric of the clock signal received from R1 satisfies a threshold, etc.). As indicated by reference numeral 250, R2 may determine that the clock quality indication transmitted by R1 is an SSU. R2 may select the clock of R1 as the reference clock for the synchronous network (e.g., based on the clock quality indication of the SSU).

As indicated by reference numeral 260, R2 may determine that another clock fault associated with the clock of R1 has occurred. Additionally, as indicated by reference numeral 255, R2 may determine that the latest clock quality indication received from R0 is a DNU. As a result, R2 may not select a clock as the reference clock, but may enter a hold state or a free-running state.

R0 may continue to transmit the DNU's clock quality indication, as indicated by reference numeral 265. As indicated by reference numeral 270, R2 may determine that the clock of R1 has recovered from the clock failure (e.g., based on an indication received from R1, based on a determination that a quality metric of the clock signal received from R1 satisfies a threshold, etc.). R2 may determine that the clock quality indication transmitted by R1 is an SSU. As a result, R2 may select the clock of R1 as the reference clock for the synchronous network.

As noted above, fig. 2 is provided as an example. Other examples may differ from those described with respect to fig. 2. The number and arrangement of devices shown in fig. 2 are provided as examples. In fact, there may be more devices, fewer devices, different devices, or differently arranged devices than those shown in FIG. 2. Further, two or more of the devices shown in fig. 2 may be implemented within a single device, or a single device shown in fig. 2 may be implemented as multiple distributed devices. Additionally or alternatively, a set of devices (e.g., one or more devices) shown in fig. 2 may perform one or more functions described as being performed by another set of devices shown in fig. 2.

Fig. 3 includes a diagram of one or more example clock failure notification configurations 300 described herein. As shown in fig. 3, the clock quality indication (QL) may be transmitted in one or more packets via the ethernet communication layer of the synchronous network. The packet may use a Synchronization Status Message (SSM) format including different TLV fields to indicate a type of TLV format or a type of SSM, a length of TLV, SSM code (e.g., associated with a clock quality indication such as PRC, SSU, SEC, DNU, etc.), and/or one or more unused fields. For example, the tables shown in FIG. 3 (e.g., tables 1 and 2) may represent the configuration of the QL-TLV format for transmission via the Ethernet Synchronization Message Channel (ESMC) of the synchronous network.

As described above, a network device of a synchronous network may transmit a clock quality indication using a first type of SSM format. The first type of SSM format may be a SSM TLV format. The first type of SSM format may be modified to include a failure notification. The configuration of the first type of SSM format may be as shown in table 1. For example, 8 bits may be used to indicate the type of SSM, 16 bits may be used to indicate the length of SSM, 4 bits may be used to indicate the SSM code, and 4 bits may not be used. The SSM code may indicate a clock quality indication as described above with respect to fig. 1A-1F. For emutexample, SSM code 0010 may indicate PRC, SSM code 0100 may indicate SSU-a, SSM code 1000 may indicate SSU-B, SSM code 1011 may indicate SEC, and SSM code 1111 may indicate DNU.

In some implementations, the fault code may be inserted into the first type of SSM format using an unused field (e.g., 4 unused bits). For example, a first type of SSM format may be configured such that a fault code (e.g., in 4 unused bits) indicates a default state or a no fault state (e.g., using fault code "0000"). The first type of SSM format may be configured such that the fault code (e.g., in 4 unused bits) indicates a clock fault status (e.g., using fault code "0001"). A first type of SSM format may be used to transport SSMs in a similar manner as described above (e.g., ESMC via a synchronous network). The receiving network device may be configured to detect a fault code in the first type of SSM format such that the receiving network device may detect fault code "0001" in the first type of SSM format and determine that the transmitting network device has detected a clock fault associated with the clock of the receiving network device.

In some implementations, the receiving network device may not be configured to detect the fault code in the first type of SSM format. For example, the receiving network device may be a legacy network device that has not been updated, upgraded, unable to detect a fault code, and so forth. A legacy network device may experience a failure (e.g., timeout, processing error, etc.) associated with processing a first type of SSM format having a fault code. In some implementations, legacy network devices may ignore information included in previously unused fields of the SSM format. For example, the legacy device may attempt to process the first type of SSM format based on identifying the first type of SSM format. The SSM format may experience a failure associated with handling a fault code within the first type of SSM format.

In some implementations, the fault code may be indicated in a second type of SSM format. The second type of SSM format may be a new TLV format type. The configuration of the second type of SSM format may be as shown in table 2. For example, 8 bits may be used to indicate a second type of SSM format (e.g., type: 0x03, etc.), 16 bits may be used to indicate the length of the SSM, 4 bits may be used to indicate a fault code, and 4 bits may be reserved and/or unused. The second type of SSM format may be sent by the network device to indicate a clock failure (e.g., a clock failure notification) and may be separate from the SSM sent to indicate a clock quality indication (e.g., the first type of SSM format).

The legacy network device may not be able to recognize the second type of SSM format because the second type of SSM format may be a new SSM format. As a result, legacy network devices may discard or reject SSM using the second type of SSM format. Thus, as described above, the legacy network device will not attempt to process SSM using the second type of SSM format and may not experience the failures associated with processing SSM. In this manner, a network device may be enabled to use the second type of SSM format to indicate a clock failure to other network devices having the same configuration (e.g., configured to detect and/or process fault codes in SSMs) without causing legacy network devices to encounter a failure associated with processing fault codes.

When the network device associated with the clock failure is an enhanced or updated network device, the network device that detected the clock failure may transmit a modified TLV (e.g., as shown in table 1). This may cause the enhanced or updated network device to perform actions as described above with respect to fig. 1D. In some implementations, if the network device that detects the clock failure determines that the network device associated with the clock failure is a legacy network device, the network device may transmit a new TLV type (e.g., as shown in table 1). This may cause the legacy network device to perform actions as described above with respect to fig. 1E.

As described above, fig. 3 is provided as one or more examples. Other examples may be different than described with respect to fig. 3.

Fig. 4A is a diagram of an example process 400 for a network device detecting a clock failure as described herein. In some implementations, one or more of the process blocks of fig. 4 may be performed by the network devices of fig. 1A-1F and/or fig. 2 (e.g., R0, R1, R2, R3, etc.). Example process 400 may include steps or actions performed by a network device in selecting a reference clock as described above.

As indicated by reference numeral 405, the network device may select a reference clock from all available clock sources. For example, the network device may select the reference clock according to a Best Master Clock Algorithm (BMCA). The network device may select the reference clock in a manner similar to that described above with respect to fig. 1A-1F.

As indicated by reference numeral 410, the network device may determine whether the clock signal of the selected reference clock is good. For example, the network device may determine whether a quality metric of the clock signal satisfies a threshold (e.g., using a phase-locked loop of the network device). The network device may determine whether the clock signal of the selected reference clock is good in a manner similar to that described above with respect to fig. 1A-1F.

As indicated by reference numeral 415, if the network device determines that the clock signal of the selected reference clock is good (e.g., the quality metric of the clock signal satisfies a threshold), the network device may lock to the selected reference clock. After locking to the selected reference clock, the network device may operate according to International Telecommunication Union (ITU) telecommunication standardization sector (ITU-T) recommendations for synchronizing ethernet clocks, ethernet synchronization message channels, and the like (e.g., ITU-T rec.g.8262, g.8264, and the like).

As indicated by reference numeral 420, if the network device determines that the clock signal of the selected reference clock is not good (e.g., the quality metric of the clock signal does not meet a threshold), the network device may determine whether to enable clock failure handling. That is, the network device may determine whether the network device is enabled to notify the upstream network device(s) of a bad clock signal. For example, if the network device is a legacy network device (e.g., a network device that is not configured with the ability to detect clock failure notifications or notify other network devices of clock failures), the network device may determine that clock failure handling is not enabled.

As indicated by reference numeral 425, if the network device determines that clock failure processing is enabled, the network device may send a clock failure notification upstream to the network device that sent the clock signal of the selected reference clock and/or to one or more other network devices. The network device may send the clock failure notification in a manner similar to that described above with respect to fig. 1A-1F, 2, and 3.

As indicated by reference numeral 430, if the network device determines that clock failure handling is not enabled (e.g., if the network device is a legacy network device), the network device may lock to a selected reference clock (e.g., a bad clock signal). After locking to the selected reference clock, the network device may operate according to ITU-T recommendations for synchronous ethernet clocks, ethernet synchronous message channels, and the like (e.g., ITU-T rec.g.8262, g.8264, and the like).

Although fig. 4A shows example blocks of the example process 400, in some implementations, the example process 400 may include more blocks, fewer blocks, different blocks, or differently arranged blocks than shown in fig. 4A. Additionally or alternatively, two or more blocks of process 400 may be performed in parallel.

Fig. 4B is a diagram of an example process 450 for a network device experiencing a clock failure as described herein. In some implementations, one or more of the process blocks of fig. 4B may be performed by the network devices of fig. 1A-1F and/or fig. 2 (e.g., R0, R1, R2, R3, etc.). The example process 450 may include steps or actions performed by a network device upon receiving a clock failure notification as described above.

As indicated by reference numeral 455, the network device may determine whether a clock failure notification has been received. If a clock failure notification has not been received, the network device may continue to operate normally, as indicated by reference numeral 460. For example, if no clock failure notification is received, the network device may operate according to ITU-T recommendations for synchronizing ethernet clocks, ethernet synchronization message channels, and so forth (e.g., ITU-T rec.g.8262, g.8264, and so forth).

As indicated by reference numeral 465, if the network device determines that a clock failure notification has been received, the network device may determine whether clock failure processing is enabled. For example, a legacy network device (e.g., a network device that is not configured with the capability to detect clock failure notifications) may determine that clock failure handling is not enabled. As indicated by reference numeral 460, if the network device determines that clock failure handling is not enabled, the network device may continue to operate normally (e.g., receiving a clock failure notification may not affect or change the performance of the network device that does not enable clock failure handling). For example, if clock failure handling for the network device is not enabled, the network device may operate according to ITU-T recommendations for synchronous ethernet clocks, ethernet synchronous message channels, and so forth (e.g., ITU-T rec.g.8262, g.8264, and so forth).

As indicated by reference numeral 470, if the network device determines that a clock failure notification has been received, the network device may determine whether all ports of the network device are demotable. For example, a network device may be transmitting a clock quality indication to one or more other network devices using one or more ports of the network device. The network device may determine that one or more ports of the network device cannot be degraded (e.g., based on a configuration of the network device, a communication status of the network device, an operational status of the network device, etc.). For example, the network device may determine that some ports, but not all ports, of the network device can be degraded.

As indicated by reference numeral 475, if the network device determines that one or more ports of the network device cannot degrade, the network device can degrade a clock quality indication (QL) on the port that received the clock failure notification. For example, if the network device receives a clock quality notification in the first port, the network device may degrade a clock quality indication transmitted by the network device via the first port.

As indicated by reference numeral 480, if the network device determines that all ports of the network device can degrade, the network device may degrade the clock quality indications transmitted by the network device on all ports. In some implementations, the network device may adjust a clock signal of a clock of the network device based on receiving the clock failure notification.

The network device may continue to transmit the degraded clock quality indication until the network device determines that the clock of the network device has recovered from the clock failure. In some implementations, the network device may determine that the clock of the network device has recovered from the clock failure based on a measurement of a quality metric of the clock performed by the network device, based on a reboot or shutdown of the network device, based on an indication received from a different network device, and so on.

Although fig. 4 shows example blocks of the example process 400, in some implementations, the example process 400 may include more blocks, fewer blocks, different blocks, or differently arranged blocks than shown in fig. 4. Additionally or alternatively, two or more blocks of process 400 may be performed in parallel.

FIG. 5 is an illustration of an example environment 500 in which systems and/or methods described herein may be implemented. As shown in FIG. 5, environment 500 may include a set of network devices 510 (shown as network device 510-1 through network device 510-N), and a network 520. The devices of environment 500 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections.

Network device 510 includes one or more devices capable of receiving, processing, storing, routing, and/or providing traffic (e.g., packets, other information or metadata, etc.) in the manner described herein. For example, network device 510 may include routers, such as Label Switched Routers (LSRs), Label Edge Routers (LERs), ingress routers, egress routers, provider routers (e.g., provider edge routers, provider core routers, etc.), virtual routers, and so forth. Additionally or alternatively, network device 510 may include a gateway, switch, firewall, hub, bridge, reverse proxy, server (e.g., proxy server, cloud server, data center server, etc.), load balancer, and/or the like. In some implementations, the network device 510 may be a physical device implemented within a housing, such as a rack. In some implementations, the network device 510 may be a virtual device implemented by one or more computer devices of a cloud computing environment or data center. In some implementations, the set of network devices 510 may be a set of data center nodes for routing traffic flows through the network 520.

Network 520 includes one or more wired and/or wireless networks. For example, network 520 may include a packet-switched network, a cellular network (e.g., a fifth generation (5G) network, a fourth generation (4G) network, such as a Long Term Evolution (LTE) network, a third generation (3G) network, a Code Division Multiple Access (CDMA) network, a Public Land Mobile Network (PLMN), a Local Area Network (LAN), a Wide Area Network (WAN), a Metropolitan Area Network (MAN), a telephone network (e.g., the Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the internet, a fiber-based network, a cloud computing network, and the like, and/or a combination of these or another type of network.

The number and arrangement of devices and networks shown in fig. 5 are provided as examples. In practice, there may be more devices and/or networks, fewer devices and/or networks, different devices and/or networks, or differently arranged devices and/or networks than those shown in fig. 5. Further, two or more of the devices shown in fig. 5 may be implemented within a single device, or a single device shown in fig. 5 may be implemented as multiple distributed devices. Additionally or alternatively, a set of devices (e.g., one or more devices) of environment 500 may perform one or more functions described as being performed by another set of devices of environment 500.

FIG. 6 is a diagram of example components of a device 600. Device 600 may correspond to one or more network devices 510-1 through 510-N, etc. In some implementations, one or more network devices 510-1 through 510-N may include one or more devices 600 and/or one or more components of devices 600. As shown in fig. 6, device 600 may include a bus 610, a processor 620, a memory 630, a storage component 640, an input component 650, an output component 660, and a communication interface 670.

Bus 610 includes components that allow communication among the components of device 600. Processor 620 is implemented in hardware, firmware, or a combination of hardware and software. Processor 620 is a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Accelerated Processing Unit (APU), microprocessor, microcontroller, Digital Signal Processor (DSP), Field Programmable Gate Array (FPGA), Application Specific Integrated Circuit (ASIC), or another type of processing component. In some implementations, the processor 620 includes one or more processors that can be programmed to perform functions. Memory 630 includes Random Access Memory (RAM), Read Only Memory (ROM), and/or another type of dynamic or static storage device (e.g., flash memory, magnetic storage and/or optical storage) that stores information and/or instructions for use by processor 620.

The storage component 640 stores information and/or software related to the operation and use of the device 600. For example, storage component 640 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, and/or a solid state disk), a Compact Disc (CD), a Digital Versatile Disc (DVD), a floppy disk, a cassette, a tape, and/or another type of non-transitory computer-readable medium, and a corresponding drive.

Input components 650 include components that allow device 600 to receive information, such as via user input (e.g., a touch screen display, keyboard, keypad, mouse, buttons, switches, and/or microphone). Additionally or alternatively, input component 650 may include sensors for sensing information (e.g., Global Positioning System (GPS) components, accelerometers, gyroscopes, and/or actuators). Output components 660 include components that provide output information from device 600 (e.g., a display, a speaker, and/or one or more LEDs).

Communication interface 670 includes transceiver-like components (e.g., a transceiver and/or a separate receiver and transmitter) that enable device 600 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communication interface 670 may allow device 600 to receive information from and/or provide information to another device. For example, communication interface 670 may include an ethernet interface, an optical interface, a coaxial interface, an infrared interface, an RF interface, a Universal Serial Bus (USB) interface, a wireless local area network interface, a cellular network interface, and/or the like.

Device 600 may perform one or more processes described herein. Device 600 may perform these processes based on processor 620 executing software instructions stored by a non-transitory computer-readable medium, such as memory 630 and/or storage component 640. A computer-readable medium is defined herein as a non-transitory memory device. The memory device includes storage space within a single physical storage device or storage space distributed among multiple physical storage devices.

The software instructions may be read into memory 630 and/or storage component 640 from another computer-readable medium or another device via communication interface 670. When executed, software instructions stored in memory 630 and/or storage component 640 may cause processor 620 to perform one or more processes described herein. Additionally or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

The number and arrangement of components shown in fig. 6 are provided as examples. In practice, device 600 may include more components, fewer components, different components, or differently arranged components than shown in fig. 6. Additionally or alternatively, a set of components (e.g., one or more components) of device 600 may perform one or more functions described as being performed by another set of components of device 600.

Fig. 7 is a diagram of example components of a device 700. Device 700 may correspond to one or more network devices 510-1 through 510-N, etc. In some implementations, one or more network devices 510-1 through 510-N, etc. may include one or more devices 700 and/or one or more components of devices 700. As shown in FIG. 7, device 700 may include one or more input components 710-1 through 710-B (B ≧ 1) (hereinafter collectively referred to as input components 710 and individually referred to as input components 710), a switch component 720, one or more output components 730-1 through 730-C (C ≧ 1) (hereinafter collectively referred to as output components 730 and individually referred to as output components 730), and a controller 740.

The input component 710 may be one or more points of attachment for a physical link and may be one or more points of entry for incoming traffic such as packets. The input component 710 can process incoming traffic, such as by performing data link layer encapsulation or decapsulation. In some implementations, input component 710 can transmit and/or receive packets. In some implementations, input components 710 may include input line cards that include one or more packet processing components (e.g., in the form of integrated circuits), such as one or more interface cards (IFCs), packet forwarding components, line card controller components, input ports, processors, memory, and/or input queues. In some implementations, the device 700 may include one or more input components 710.

The switching component 720 may interconnect the input component 710 with the output component 730. In some implementations, the switching component 720 may be implemented via one or more crossbars, via a bus, and/or provide shared memory. The shared memory may act as a temporary buffer to store packets from the input component 710 before finally scheduling the packets for transmission to the output component 730. In some implementations, switching component 720 may enable input component 710, output component 730, and/or controller 740 to communicate with each other.

Output component 730 may store the packets and may schedule the packets for transmission on an output physical link. Output component 730 may support data link layer encapsulation or decapsulation and/or various high-level protocols. In some implementations, the output component 730 may transmit packets and/or receive packets. In some implementations, output components 730 may include an output line card that includes one or more packet processing components (e.g., in the form of integrated circuits), such as one or more IFCs, packet forwarding components, line card controller components, output ports, processors, memory, and/or output queues. In some implementations, the device 700 may include one or more output components 730. In some implementations, input component 710 and output component 730 may be implemented by the same set of components (e.g., an input/output component may be a combination of input component 710 and output component 730).

Controller 740 includes a processor in the form of, for example, a CPU, GPU, APU, microprocessor, microcontroller, DSP, FPGA, ASIC, and/or another type of processor. A processor is implemented in hardware, firmware, or a combination of hardware and software. In some implementations, the controller 740 may include one or more processors that may be programmed to perform functions.

In some implementations, the controller 740 may include RAM, ROM, and/or another type of dynamic or static storage device (e.g., flash memory, magnetic storage, optical storage, etc.) that stores information and/or instructions for use by the controller 740.

In some implementations, the controller 740 may communicate with other devices, networks, and/or systems connected to the device 700 to exchange information about the network topology. Controller 740 may create a routing table based on the network topology information, may create a forwarding table based on the routing table, and may forward the forwarding table to input component 710 and/or output component 730. The input component 710 and/or the output component 730 can use a forwarding table to perform route lookups on incoming and/or outgoing packets.

Controller 740 may perform one or more processes described herein. The controller 740 may perform these processes in response to executing software instructions stored by a non-transitory computer-readable medium. A computer-readable medium is defined herein as a non-transitory memory device. The memory device includes storage space within a single physical storage device or storage space distributed among multiple physical storage devices.

The software instructions may be read into a memory and/or storage component associated with controller 740 from another computer-readable medium or from another device via a communication interface. When executed, software instructions stored in a memory and/or storage component associated with controller 740 may cause controller 740 to perform one or more processes described herein. Additionally or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

The number and arrangement of components shown in fig. 7 are provided as examples. In practice, device 700 may include more components, fewer components, different components, or a different arrangement of components than shown in fig. 7. Additionally or alternatively, a set of components (e.g., one or more components) of device 700 may perform one or more functions described as being performed by another set of components of device 700.

Fig. 8 is a flow diagram of an example process 800 associated with clock failure detection and correction between synchronized network devices. In some implementations, one or more of the process blocks of fig. 8 may be performed by a first network device (e.g., network device 510-1). In some implementations, one or more of the process blocks of fig. 8 may be performed by another device or group of devices separate from or including the first network device, such as one or more other network devices (e.g., network device 510-2, network device 510-N, etc.). Additionally or alternatively, one or more of the process blocks of fig. 8 may be performed by one or more components of device 600 (e.g., processor 620, memory 630, storage component 640, input component 650, output component 660, communication interface 670, etc.), one or more components of device 700 (e.g., input component 710, switching component 720, output component 730, controller 740, etc.), and/or the like.

As shown in fig. 8, process 800 may include: a clock quality indication associated with a clock of a second network device is received from the second network device, wherein the clock of the second network device is a reference clock for a network including the first network device and the second network device (block 810). For example, the first network device may receive, from the second network device, a clock quality indication associated with a clock of the second network device, as described above. In some implementations, the clock of the second network device is a reference clock for a network that includes the first network device and the second network device.

As further shown in fig. 8, process 800 may include determining, based on a clock signal of the second network device, that a quality metric of the clock does not meet a threshold (block 820). For example, the first network device may determine that the quality metric of the clock does not meet the threshold based on the clock signal of the second network device, as described above.

As further shown in fig. 8, process 800 may include providing a clock failure notification to the second network device to cause the second network device to degrade a clock quality indication transmitted by the second network device (block 830). For example, the first network device may provide a clock failure notification to the second network device to cause the second network device to reduce the clock quality indication transmitted by the second network device, as described above.

As further shown in fig. 8, process 800 may include selecting a new reference clock for the first network device based on receiving the degraded clock quality indication from the second network device (block 840). For example, the first network device may select a new reference clock for the first network device based on receiving the degraded clock quality indication from the second network device, as described above.

Process 800 may include other implementations such as any single implementation or any combination of implementations described below and/or described in conjunction with one or more other processes described elsewhere herein.

In a first implementation, the clock quality indication is received via an ethernet communication layer of the network and the clock signal is received via a physical communication layer of the network.

In a second implementation, either alone or in combination with the first implementation, the new reference clock is associated with a third network device of a network including the first network device and the second network device, and the new reference clock is used to synchronize the first network device and the third network device.

In a third implementation, the first network device is located downstream from the second network device and the third network device within a topology of the network, either alone or in combination with one or more of the first implementation and the second implementation.

In a fourth implementation, alone or in combination with one or more of the first through third implementations, the clock quality indication associated with the clock of the second network device has a higher priority than the clock quality indication associated with the new reference clock.

In a fifth implementation, alone or in combination with one or more of the first through fourth implementations, providing clock failure notification comprises: inserting a fault code within an unused field of a synchronization status message associated with a type of synchronization status message indicated by the clock quality, the first network device and the second network device configured to detect the fault code and provide the synchronization status message as a clock fault notification.

In a sixth implementation, alone or in combination with one or more of the first through fifth implementations, the network comprises a synchronous ethernet network, and the clock quality indication, the clock failure notification, and the new clock quality indication are synchronization status messages transmitted via an ethernet synchronization message channel of the synchronous ethernet network.

Although fig. 8 shows example blocks of the process 800, in some implementations, the process 800 may include more blocks, fewer blocks, different blocks, or differently arranged blocks than shown in fig. 8. Additionally or alternatively, two or more blocks of process 800 may be performed in parallel.

Fig. 9 is a flow diagram of an example process 900 associated with clock failure detection and correction between synchronized network devices. In some implementations, one or more of the process blocks of fig. 9 may be performed by a first network device (e.g., network device 510-1). In some implementations, one or more of the process blocks of fig. 9 may be performed by another device or group of devices separate from or including the first network device, such as one or more other network devices (e.g., network device 510-2, network device 510-N, etc.). Additionally or alternatively, one or more of the process blocks of fig. 9 may be performed by one or more components of device 600 (e.g., processor 620, memory 630, storage component 640, input component 650, output component 660, communication interface 670, etc.), one or more components of device 700 (e.g., input component 710, switching component 720, output component 730, controller 740, etc.), and/or the like.

As shown in fig. 9, process 900 may include measuring a quality metric of a clock signal, where the clock signal is associated with a clock of a second network device, and where the clock of the second network device is a reference clock for the first network device and the second network device (block 910). For example, the first network device may measure a quality metric of the clock signal, as described above. In some implementations, the clock signal is associated with a clock of the second network device. In some implementations, the clock of the second network device is a reference clock for the first network device and the second network device.

As further shown in fig. 9, the process 900 may include determining, based on the clock signal, that the quality metric does not meet the threshold (block 920). For example, the first network device may determine, based on the clock signal, that the quality metric does not meet the threshold, as described above.

As further shown in fig. 9, process 900 may include providing a clock failure notification to the second network device based on the threshold not being met to cause the second network device to degrade a clock quality indication transmitted by the second network device (block 930). For example, the first network device may provide a clock failure notification to the second network device based on the threshold not being met to cause the second network device to degrade the clock quality indication transmitted by the second network device, as described above.

As further shown in fig. 9, process 900 may include performing an action associated with establishing a new reference clock for the first network device (block 940). For example, the first network device may perform actions associated with establishing a new reference clock for the first network device, as described above.

Process 900 may include other implementations such as any single implementation or any combination of implementations described below and/or described in conjunction with one or more other processes described elsewhere herein.

In a first implementation, a clock quality indication and a clock signal are received from a second network device.

In a second implementation, alone or in combination with the first implementation, the first network device and the second network device are routers of a synchronous ethernet network.

In a third implementation, either alone or in combination with one or more of the first and second implementations, the clock quality indication is received via an ethernet communication layer of the network and the clock signal is received via a physical communication layer of the network.

In a fourth implementation, alone or in combination with one or more of the first through third implementations, the process 900 includes: receiving a degraded clock quality indication from the second network device; selecting a new reference clock based on a different clock quality indication associated with the new reference clock; and forwarding the second clock quality indication to the one or more other network devices to cause the one or more other network devices to use the new reference clock.

In a fifth implementation, either alone or in combination with one or more of the first through fourth implementations, the new reference clock is associated with a third network device of the network, and the new reference clock is configured to synchronize the first network device and the third network device.

In a sixth implementation, alone or in combination with one or more of the first through fifth implementations, the process 900 includes inserting a fault code within a field of a first type of synchronization status message, wherein the clock quality indication is associated with a second type of synchronization status message different from the first type, wherein the first network device and the second network device are different types of network devices; and provides a synchronization status message as a clock failure notification.

Although fig. 9 shows example blocks of the process 900, in some implementations, the process 900 may include more blocks, fewer blocks, different blocks, or differently arranged blocks than shown in fig. 9. Additionally or alternatively, two or more blocks of process 900 may be performed in parallel.

Fig. 10 is a flow diagram of an example process 1000 associated with clock failure detection and correction between synchronized network devices. In some implementations, one or more of the process blocks of fig. 10 may be performed by a first network device (e.g., network device 510-1). In some implementations, one or more of the process blocks of fig. 10 may be performed by another device or group of devices, separate from or including the first network device, such as one or more other network devices (e.g., network device 510-2, network device 510-N, etc.). Additionally or alternatively, one or more of the process blocks of fig. 10 may be performed by one or more components of device 600 (e.g., processor 620, memory 630, storage component 640, input component 650, output component 660, communication interface 670, etc.), one or more components of device 700 (e.g., input component 710, switching component 720, output component 730, controller 740, etc.), and/or the like.

As shown in fig. 10, process 1000 may include receiving a clock quality indication associated with a clock of a second network device, wherein the clock of the second network device is a reference clock for a network including the first network device and the second network device (block 1010). For example, a first network device may receive a clock quality indication associated with a clock of a second network device, as described above. In some implementations, the clock of the second network device is a reference clock for a network that includes the first network device and the second network device.

As further shown in fig. 10, process 1000 may include determining, based on a clock signal of the second network device, that a quality metric of the clock does not meet a threshold (block 1020). For example, the first network device may determine that the quality metric of the clock does not meet the threshold based on the clock signal of the second network device, as described above.

As further shown in fig. 10, process 1000 may include providing a clock failure notification to the second network device to cause the second network device to degrade the clock quality indication (block 1030). For example, a first network device may provide a clock failure notification to a second network device to cause the second network device to degrade a clock quality indication, as described above.

Process 1000 may include other implementations such as any single implementation or any combination of implementations described below and/or described in conjunction with one or more other processes described elsewhere herein.

In a first implementation, the clock quality indication is received via an ethernet synchronization message channel of the network and the clock signal is received via a physical communication layer of the network.

In a second implementation, alone or in combination with the first implementation, the process 1000 includes: analyzing the clock signal via a phase locked loop of the first network device to determine a quality metric; comparing the quality metric to a threshold; and determining that the quality metric does not meet a threshold.

In a third implementation, either alone or in combination with one or more of the first and second implementations, the process 1000 includes: selecting a new reference clock for the first network device; and providing a clock quality indication associated with the new reference clock to one or more other network devices.

In a fourth implementation, the network is a synchronous ethernet network, alone or in combination with one or more of the first to third implementations.

In a fifth implementation, either alone or in combination with one or more of the first through fourth implementations, the process 1000 includes: determining a configuration of a second network device; providing a clock failure notification as a failure code within one of: an unused field of a first type of synchronization status message associated with the clock quality indication or a field of a second type of synchronization status message different from the first type of synchronization status message.

Although fig. 10 shows example blocks of the process 1000, in some implementations, the process 1000 may include more blocks, fewer blocks, different blocks, or differently arranged blocks than shown in fig. 10. Additionally or alternatively, two or more blocks of process 1000 may be performed in parallel.

The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.

As used herein, the term "component" is intended to be broadly interpreted as hardware, firmware, or a combination of hardware and software.

As used herein, a service or content may comprise a set of packets. A packet may refer to a communication structure used to communicate information, such as a Protocol Data Unit (PDU), a Service Data Unit (SDU), a network packet, a datagram, a segment, a message, a block, a frame (e.g., an ethernet frame), a portion of any of the above, and/or another type of formatted or unformatted data unit capable of being transmitted over a network.

Some implementations are described herein in connection with a threshold. As used herein, meeting a threshold may refer to being greater than the threshold, greater than or equal to the threshold, less than the threshold, a value less than the threshold, less than or equal to the threshold, and so forth, depending on the context.

It is to be understood that the systems and/or methods described herein may be implemented in various forms of hardware, firmware, and/or combinations of hardware and software. The actual specialized control hardware or software code used to implement these systems and/or methods is not limiting of implementation. Thus, the operation and behavior of the systems and/or methods have been described herein without reference to the specific software code. It should be understood that the systems and/or methods may be implemented using software and hardware based on the description herein.

Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the disclosure of the various implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification. Although each dependent claim listed below may depend directly on only one claim, the disclosure of various implementations includes each dependent claim in combination with every other claim in the set of claims.

No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. In addition, as used herein, the articles "a" and "an" are intended to include one or more items, and may be used interchangeably with "one or more. In addition, as used herein, the article "the" is intended to include the item or items to which the article "the" refers, and may be used interchangeably with "one or more". Further, as used herein, the term "collection" is intended to include one or more items (e.g., related items, unrelated items, combinations of related and unrelated items, etc.) and may be used interchangeably with "one or more. Where only one item is intended, the phrase "only one item" or similar language is used. In addition, as used herein, the terms "having," "has," "having," and the like are intended to be open-ended terms. Further, the phrase "based on" is intended to mean "based, at least in part, on" unless explicitly stated otherwise. In addition, as used herein, the term "or" when used in a serial manner is intended to be inclusive and may be used interchangeably with "and/or" unless specifically stated otherwise (e.g., if used in conjunction with "or" only one of ").