US-12627460-B2 - Clock synchronization between networked devices based on packet congestion information

US12627460B2US 12627460 B2US12627460 B2US 12627460B2US-12627460-B2

Abstract

A network device includes control logic coupled to a receiver. The control logic detects an synchronization packet received via the receiver from a second network device over a network that is precision time protocol unaware. The control logic determines that a portion of the synchronization packet is asserted, indicating that the synchronization packet has incurred congestion traversing the network. The control logic adjusts, based on an assertion of the portion, a weight applied to timestamps associated with sending and receiving the synchronization packet in performing clock synchronization with the second network device.

Inventors

Wojciech Wasko
Dotan David Levi
Thomas Kernen

Assignees

MELLANOX TECHNOLOGIES, LTD.

Dates

Publication Date: 20260512
Application Date: 20230710

Claims (20)

1 . A network device comprising: control logic coupled to a receiver and configured to: detect a synchronization packet received via the receiver from a second network device over a network that is precision time protocol (PTP) unaware; determine that a bit of a congestion notification field of the synchronization packet is asserted, indicating that the synchronization packet has incurred congestion traversing the network; and reduce, based on an assertion of the bit, a weight applied to timestamps associated with sending and receiving the synchronization packet in performing clock synchronization with the second network device.
2 . The network device of claim 1 , wherein the network is established with communication devices capable of sending explicit congestion notifications.
3 . The network device of claim 1 , wherein the synchronization packet is one of a synchronization message received from the second network device or a delay response message received from the second network device in response to sending a delay request message to the second network device.
4 . The network device of claim 1 , wherein the synchronization packet is a delay response message received from the second network device in response to sending a delay request message to the second network device, and wherein the delay response message includes one of: an asserted bit within a congestion notification field that indicates the delay request message has incurred congestion; or information within a type-length-value (TLV) field that indicates the delay request message has incurred congestion.
5 . The network device of claim 1 , further comprising a local clock source coupled to the control logic, wherein the control logic is further to: estimate a local clock error based on a period of time since a last synchronization of the local clock source and a known accuracy metric value of the local clock source; and apply no weight to the timestamps in synchronizing the local clock source in response to determining that the local clock error is less than or equal to a maximum congestion error for the network.
6 . The network device of claim 1 , further comprising a local clock source coupled to the control logic, wherein the control logic is further to: estimate a local clock error based on a period of time since a last synchronization of the local clock source and a known accuracy metric value of the local clock source; and reduce the weight applied to the timestamps in synchronizing the local clock source in response to the local clock error being greater than a maximum congestion error for the network.
7 . The network device of claim 1 , wherein the synchronization packet is a synchronization message, and the timestamps are a first timestamp of a second clock source of the second network device and a second timestamp of a first clock source of the network device, the control logic further to: cause a delay request message to be sent to the second network device that is associated with a third timestamp of the first clock source; receive, from the second network device, a delay response message that includes a fourth timestamp of when the delay request message was received; determine a delay of the synchronization packet between the network device and the second network device based on the first, second, third, and fourth timestamps; determine a clock offset value between the first clock source and the second clock source based on the delay and a difference between the first and second timestamps; and synchronize the first clock source to the second clock source based on the reduced weight applied to one of the clock offset value or the first, second, third, and fourth timestamps.
8 . A method comprising: detecting, by a first network device, a synchronization packet received via a receiver from a second network device over a network that is precision time protocol (PTP) unaware; determining that a bit of the synchronization packet is asserted, indicating that the synchronization packet has incurred congestion traversing the network; and adjusting, based on an assertion of the bit, a weight applied to timestamps associated with sending and receiving the synchronization packet in performing clock synchronization with the second network device, wherein the synchronization packet is a delay response message received from the second network device in response to sending a delay request message to the second network device, and wherein the bit of the delay response message includes one of: an asserted bit within a congestion notification field that indicates the delay request message has incurred congestion; or information within a type-length-value (TLV) field that indicates the delay request message has incurred congestion.
9 . The method of claim 8 , further comprising establishing the network with communication devices capable of sending explicit congestion notifications.
10 . The method of claim 8 , wherein the synchronization packet is one of a synchronization message received from the second network device or a delay response message received from the second network device in response to sending a delay request message to the second network device.
11 . The method of claim 8 , further comprising: estimating a local clock error based on a period of time since a last synchronization of a local clock source and a known accuracy metric value of the local clock source of the first network device; and applying no weight to the timestamps in synchronizing the local clock source in response to determining that the local clock error is less than or equal to a maximum congestion error for the network.
12 . The method of claim 8 , further comprising: estimating a local clock error based on a period of time since a last synchronization of a local clock source and a known accuracy metric value of the local clock source of the first network device; and applying the adjusted weight to the timestamps in synchronizing the local clock source in response to the local clock error being greater than a maximum congestion error for the network.
13 . The method of claim 8 , wherein the synchronization packet is a synchronization message, and the timestamps are a first timestamp of a second clock source of the second network device and a second timestamp of a first clock source of the first network device, the method further comprising: causing a delay request message to be sent to the second network device that is associated with a third timestamp of the first clock source; receiving, from the second network device, a delay response message that includes a fourth timestamp of when the delay request message was received; determine a delay of the synchronization packet between the network device and the second network device based on the first, second, third, and fourth timestamps; determining a clock offset estimation error based on the delay; determining a local clock error of the first clock source; adjusting the weight applied to the first, second, third, and fourth timestamps based on a comparison between the clock offset estimation error and the local clock error; and synchronize the first clock source to the second clock source using the adjusted weight applied to the first, second, third, and fourth timestamps.
14 . A method comprising: detecting, by a first network device, a synchronization packet received via a receiver from a second network device over a network that is precision time protocol (PTP) unaware; determining that a bit of the synchronization packet is unasserted, indicating the synchronization packet did not incur congestion traversing the network; and applying, based on the bit being unasserted, a full weight to timestamps associated with sending and receiving the synchronization packet in performing clock synchronization with the second network device, wherein the synchronization packet is a delay response message received from the second network device in response to sending a delay request message to the second network device, and wherein the bit of the delay response message includes one of: an unasserted bit within a congestion notification field that indicates the delay request message has not incurred congestion; or information within a type-length-value (TLV) field that indicates the delay request message has not incurred congestion.
15 . The method of claim 14 , wherein the synchronization packet is one of a synchronization message received from the second network device or a delay response message received from the second network device in response to sending a delay request message to the second network device.
16 . The method of claim 14 , wherein the synchronization packet is a synchronization message, and the timestamps are a first timestamp of a second clock source of the second network device and a second timestamp of a first clock source of the first network device, the method further comprising causing a delay request message to be sent to the second network device that is associated with a third timestamp of the first clock source; receiving, from the second network device, a delay response message that includes a fourth timestamp of when the delay request message was received; determining a delay of the synchronization packet between the first network device and the second network device based on the first, second, third, and fourth timestamps; determining a clock offset value between the first clock source and the second clock source based on the delay and a difference between the first and second timestamps; and synchronizing the first clock source to the second clock source based on the full weight applied to one of the clock offset value or the first, second, third, and fourth timestamps.
17 . A network device comprising: control logic coupled to a receiver and configured to: detect a synchronization packet received via the receiver from a second network device over a network that is precision time protocol (PTP) unaware; determine that a bit of the synchronization packet is asserted, indicating that the synchronization packet has incurred congestion traversing the network; and adjust, based on an assertion of the bit, a weight applied to timestamps associated with sending and receiving the synchronization packet in performing clock synchronization with the second network device; and a local clock source coupled to the control logic, wherein the control logic is further to: estimate a local clock error based on a period of time since a last synchronization of the local clock source and a known accuracy metric value of the local clock source; and one of apply no weight or reduce the weight applied to the timestamps in synchronizing the local clock source based on the local clock error.
18 . The network device of claim 17 , wherein to apply no weight to the timestamps is in response to determining that the local clock error is less than or equal to a maximum congestion error for the network.
19 . The network device of claim 17 , wherein to reduce the weight applied to the timestamps is in response to the local clock error being greater than a maximum congestion error for the network.
20 . A network device comprising: control logic coupled to a receiver and configured to: detect a synchronization packet received via the receiver from a second network device over a network that is precision time protocol (PTP) unaware; determine that a bit of the synchronization packet is asserted, indicating that the synchronization packet has incurred congestion traversing the network; and adjust, based on an assertion of the bit, a weight applied to timestamps associated with sending and receiving the synchronization packet in performing clock synchronization with the second network device, wherein the synchronization packet is a synchronization message, and the timestamps are a first timestamp of a second clock source of the second network device and a second timestamp of a first clock source of the network device, the control logic further to: cause a delay request message to be sent to the second network device that is associated with a third timestamp of the first clock source; receive, from the second network device, a delay response message that includes a fourth timestamp of when the delay request message was received; determine a delay of the synchronization packet between the network device and the second network device based on the first, second, third, and fourth timestamps; determine a clock offset value between the first clock source and the second clock source based on the delay and a difference between the first and second timestamps; and synchronize the first clock source to the second clock source based on the adjusted weight applied to one of the clock offset value or the first, second, third, and fourth timestamps.

Description

TECHNICAL FIELD At least one embodiment pertains to processing resources used to perform and facilitate network communication. For example, at least one embodiment pertains to technology for clock synchronization between networked devices based on packet congestion information. BACKGROUND Network devices (e.g., switches, routers, hubs, endpoints, and the like) operate within a network that either fully supports precision time protocol (PTP), e.g., IEEE 1588, or does not fully support PTP. A network that is PTP “aware” is built upon networked communication devices that can synchronize clocks throughout the network. If a local area network (LAN) is PTP aware, for example, the LAN can achieve clock accuracy in the sub-microsecond range, making the LAN suitable for measurement and control systems. PTP is employed to synchronize financial transactions, mobile phone tower transmissions, sub-sea acoustic arrays, and networks that require precise timing but lack access to satellite navigation signals. Many networks are considered PTP-unaware, however, and therefore do not have access to full timing support, resulting in significant challenges in reliably synchronizing clocks. BRIEF DESCRIPTION OF DRAWINGS Various embodiments in accordance with the present disclosure will be described with reference to the drawings, in which: FIG. 1 is a network diagram of an exemplary distributed network system including a pair of communicating network devices between which clock synchronization occurs in accordance with at least some embodiments; FIG. 2 is a flow diagram of a method for synchronizing clocks between network devices based on packet congestion information in accordance with at least some embodiments; FIG. 3 is a timing diagram illustrating timestamp-based clock synchronization, in accordance with at least some embodiments; FIG. 4 is a flow diagram of a method for synchronizing clocks between network devices based on an adjusted weight applied to timestamps based on local clock error and clock offset estimation error, in accordance with at least some embodiments; and FIG. 5 is a flow diagram of a method for synchronizing clocks based on the packets and timestamps sent back and forth between a leader network device and a follower network device, as illustrated in FIG. 2, in accordance with at least some embodiments. DETAILED DESCRIPTION Certain types of special packets can play a role in timestamp synchronization by which local clock sources of network devices are synchronized. The better able networked devices are at determining the time when packets cross one or more network paths, the better the networked devices can synchronize these local clock sources with each other. The IEEE 1588 (or PTP) protocol captures and sends timestamps with ingress and egress packets between a leader network device and a follower network device, each of which can be any type of network node such as a switch, router, endpoints having network interface adapters, or a mixture thereof. Delay of packets moving through the network impacts clock synchronization in the network, e.g., packets between leader and follower devices may go through switches and routers that create variable delays in having their own buffers, queues, arbiters, and the like. For example, having more packets ingress into a port than egress out of the port creates a delay where waiting packets are buffered. Furthermore, the path through a network can change over time due to adaptive routing and adaptive switching. This interim delay between leader and follower devices could then become separated by some variable delay (e.g., a dynamic or random delay) in addition to any static delay. In certain specialized networks, this variable delay can be countered by introducing a “transparent clock,” which determines how long a packet resides inside of the switch (or other intermediate nodes) and sends a compensation value like a residence time counter value to the end node so that the end node can compensate for the time the packet spent in the switch (or other network components). Thus, if a packet experiences congestion, the receiver of this packet can correct for the extra propagation time due to network congestion, resulting in generating accurate timestamps. For example, a switch, acting as a transparent clock, can provide a per-packet compensation value to account for the residence time of the packet in the switch. The use of such transparent clock technology is performed in, e.g., telecommunication or radio access networks. A weakness of this transparent clock approach, however, is the requirement of explicit transparent clock support throughout the entire network, e.g., all network components (switches, routers, hubs) in the network have to support this kind of compensation for residence time. Also, the specialized network needs to have trusted network components that are part of a security domain of the network, e.g., compensation values received from network components ar