Detecting path faults in a network

WO2026162120A1PCT designated stage Publication Date: 2026-08-06HUAWEI TECH CO LTD +1
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
HUAWEI TECH CO LTD
Filing Date
2025-01-28
Publication Date
2026-08-06

Smart Images

  • Figure EP2025052140_06082026_PF_FP_ABST
    Figure EP2025052140_06082026_PF_FP_ABST
Patent Text Reader

Abstract

In some examples, for detecting path faults in a network comprises (i) sending, by a sender, a reverse probe request message to a receiver, (ii) in response to receiving, by the receiver, the reverse probe request message, sending, by the receiver, multiple probe messages to the sender, (iii) receiving, by the sender, zero or more of the multiple probe messages sent by the receiver, and (iv) determining, by the sender, the presence of path faults in the network based on the number of probe messages received.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] DETECTING PATH FAULTS E A NETWORK

[0002] TECHNICAL FIELD

[0003] The present disclosure relates, in general, to methods and systems for detecting and diagnosing faults in computer and communication networks. Aspects of the disclosure relate to reverse path fault detection.

[0004] BACKGROUND

[0005] Fault detection is a fundamental requirement in computer and communication networks, as it ensures the reliability and integrity of data transmission. Over the years, various techniques have been developed to identify faults, often relying on the exchange of control messages between nodes. One common approach is the use of Internet Control Message Protocol (ICMP)-based utilities, such as Ping, where a source node sends “echo request” messages to a destination node. If responses are not received, a fault is inferred. However, while Ping can detect the presence of faults, it provides no information on their specific location or nature.

[0006] Traceroute is another widely used utility that offers some insight into the path taken by packets through the network. By incrementally increasing the time to live (TTL) value in the packet headers, Traceroute elicits responses from intermediate routers along the path to the destination. This allows identification of the last responsive router before a fault occurs. Despite its utility, Traceroute has significant limitations. It provides visibility only into the forward path from source to destination and does not distinguish between forward and reverse path issues.

[0007] Reverse Traceroute extends the Traceroute concept to gather information about the reverse path by having the destination node initiate a conventional Traceroute towards the source. However, this method remains constrained by the inherent limitations of Traceroute itself, offering limited diagnostic capability when faults occur on specific paths. Transport protocols like Transmission Control Protocol (TCP) and QUIC protocol incorporate fault detection mechanisms using acknowledgements (ACKs) and retransmission timeouts. These protocols improve fault detection reliability but are primarily designed to ensure end-to-end data delivery rather than diagnose specific faults in the network. For example, recurring timeouts or the use of transport-layer PING messages may indicate a fault, but they do not provide information about the location of the fault or whether it is on the forward or reverse path.

[0008] The inability of existing methods to accurately diagnose faults on reverse paths is a significant limitation. In complex networks with multiple paths between nodes, understanding the exact location and nature of a fault is essential for effective troubleshooting and efficient network operation. Existing methods fail to provide explicit information about reverse path faults, leaving network operators with limited insight into the root cause of connectivity issues. This lack of diagnostic precision can lead to increased downtime, inefficient resource utilisation, and operational challenges, particularly in large-scale networks.

[0009] SUMMARY

[0010] An objective of the present disclosure is to provide a method for detecting reverse path faults in a network.The foregoing and other objectives are achieved by the features of the independent claims.

[0011] Further implementation forms are apparent from the dependent claims, the description and the Figures.

[0012] A first aspect of the present disclosure provides a method for detecting path faults in a network, the method comprising sending, by a sender, a reverse probe request message to a receiver, in response to receiving, by the receiver, the reverse probe request message, sending, by the receiver, multiple probe messages to the sender, receiving, by the sender, zero or more of the multiple probe messages sent by the receiver, and determining, by the sender, the presence of path faults in the network based on the number of probe messages received.

[0013] Accordingly, a method which enables the detection and localisation of faults specifically on reverse paths can be provided. Advantageously, this effect is not achieved by existing solutions. Unlike traditional methods that only detect general connectivity issues, the method described herein explicitly identifies which reverse paths are functional and which are faulty, offering granular fault detection. The ability to detect reverse path faults is particularly valuable in multi-path networks, where existing solutions do not distinguish between forward and reverse path issues. As such, the proposed solution improves network reliability and facilitates more efficient troubleshooting.

[0014] In response to receiving, by the sender, none of the multiple probe messages sent by the receiver, a fault may be detected on a forward path in the network.

[0015] In response to receiving, by the sender, at least one but not all of the multiple probe messages sent by the receiver, a fault may be detected on at least one reverse path in the network.

[0016] In response to receiving, by the sender, all of the multiple probe messages sent by the receiver, it may be determined that there are no faults in the network.

[0017] Sending, by the sender, the reverse probe request message to the receiver may comprise sending multiple reverse probe request messages, wherein each of the multiple reverse probe request messages may be sent over a different forward path in the network.

[0018] The reverse probe request message may specify a number of reverse paths to be probed.

[0019] The number of probe messages sent by the receiver to the sender may be equal to the number of reverse paths to be probed specified in the reverse probe request message.

[0020] Each probe message sent by the receiver may include information indicating the total number of reverse paths probed. The receiver may use one or more fields in the probe message header to control which reverse path the respective probe message is forwarded through.

[0021] The one or more fields in the probe message header may comprise values used by the network to determine a forwarding path.

[0022] The multiple probe messages sent by the receiver may be transmitted over different paths in the network.A second aspect of the present disclosure provides a system for detecting path faults in a network, the system comprising a sender configured to send a reverse probe request message to a receiver, and the receiver configured to receive the reverse probe request message, and send multiple probe messages to the sender in response to the reverse probe request message, wherein the sender is configured to receive zero or more of the multiple probe messages sent by the receiver and to determine the presence of path faults in the network based on the number of probe messages received.

[0023] The reverse probe request message may comprise an indication of the number of reverse paths to be probed, and the receiver may be arranged to send a number of probe messages corresponding to the indicated number of reverse paths. Each probe message sent by the receiver may comprise an identifier of the reverse path used to send the respective probe message.

[0024] The system may further comprise a set of network devices configured to forward the probe messages to the sender based on a routing protocol, wherein the routing protocol may use one or more fields in the message header to select one of multiple available paths to the sender.

[0025] These and other aspects of the disclosure will be apparent from the embodiments) described below.

[0026] BRIEF DESCRIPTION OF THE DRAWINGS

[0027] In order that the present disclosure may be more readily understood, embodiments of the disclosure will now be described, by way of example, with reference to the accompanying drawings, in which:

[0028] Figure 1 is a flow chart of a method for detecting path faults in a network according to an example;

[0029] Figure 2 is a schematic representation of reverse path fault detection according to an example;

[0030] Figure 3 is a schematic representation of reverse path fault detection according to another example; and

[0031] Figure 4 is a schematic representation of a system according to an example.

[0032] DETAILED DESCRIPTION

[0033] Example embodiments are described below in sufficient detail to enable those of ordinary skill in the art to embody and implement the systems and processes herein described. It is important to understand that embodiments can be provided in many alternate forms and should not be construed as limited to the examples set forth herein.

[0034] Accordingly, while embodiments can be modified in various ways and take on various alternative forms, specific embodiments thereof are shown in the drawings and described in detail below as examples. There is no intent to limit to the particular forms disclosed. On the contrary, all modifications, equivalents, and alternatives falling within the scope of the appended claims should be included. Elements of the example embodiments are consistently denoted by the same reference numerals throughout the drawings and detailed description where appropriate.The terminology used herein to describe embodiments is not intended to limit the scope. The articles “a,” “an,” and “the” are singular in that they have a single referent, however the use of the singular form in the present document should not preclude the presence of more than one referent. In other words, elements referred to in the singular can number one or more, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes,” and / or “including,” when used herein, specify the presence of stated features, items, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, items, steps, operations, elements, components, and / or groups thereof.

[0035] Unless otherwise defined, all terms (including technical and scientific terms) used herein are to be interpreted as is customary in the art. It will be further understood that terms in common usage should also be interpreted as is customary in the relevant art and not in an idealized or overly formal sense unless expressly so defined herein.

[0036] Examples in the present disclosure can be provided as methods, systems or machine-readable instructions, such as any combination of software, hardware, firmware or the like. Such machine-readable instructions may be included on a computer readable storage medium (including but not limited to disc storage, CD-ROM, optical storage, etc.) having computer readable program codes therein or thereon.

[0037] The present disclosure is described with reference to flow charts and / or block diagrams of the method, devices and systems according to examples of the present disclosure. Although the flow diagrams described above show a specific order of execution, the order of execution may differ from that which is depicted. Blocks described in relation to one flow chart may be combined with those of another flow chart. In some examples, some blocks of the flow diagrams may not be necessary and / or additional blocks may be added. It shall be understood that each flow and / or block in the flow charts and / or block diagrams, as well as combinations of the flows and / or diagrams in the flow charts and / or block diagrams can be realized by machine readable instructions.

[0038] Figure 1 is a flow chart of a method for detecting path faults in a network according to an example. The method comprises, in block 101, sending, by a sender, a reverse probe request message to a receiver. The sender may comprise, for example, a network device such as a server, router, or network interface card (NIC). Similarly, the receiver may also comprise such network devices capable of processing reverse probe requests and generating probe messages. The reverse probe request message may specify a number of reverse paths to be probed. For example, the reverse probe request message may include a field indicating the total number of reverse paths (N) that the receiver should evaluate. This message may be sent over a specific network path, which could be determined using routing protocols or based on the network topology. The reverse probe request message may also include additional metadata, such as a unique identifier, allowing the receiver to associate incoming probes with the original request.

[0039] The sender may send multiple probe request messages to the receiver. Each of these multiple probe request messages may be sent over a different forward path in the network. A forward path is the network route that data packets follow from the sender to the receiver. These paths may vary based on the routing algorithm used, which could include equalcost multi-path (ECMP) routing or source / segment routing. Different forward paths may ensure that the probe messages traverse diverse segments of the network, increasing fault detection reliability.

[0040] In block 102, the method comprises, in response to receiving, by the receiver, the reverse probe request message, sending, by the receiver, multiple probe messages to the sender. The probe messages may be network packets generated by the receiver as a response to the reverse probe request message. Each probe message may include information aboutthe reverse path being used, allowing the sender to evaluate the status of that path. The relationship between the probe messages and the reverse probe request is that each request specifies the number of reverse paths to probe, and the receiver sends a corresponding number of probe messages. For example, if the reverse probe request message specifies probing three reverse paths, the receiver may generate and send three probe messages, each routed through a different path. Each probe message sent by the receiver may include information indicating the total number of reverse paths probed. This information allows the sender to verify whether all expected probe messages have been received. As such, this ensures that any discrepancies in the number of received probe messages can be easily identified and attributed to specific paths.

[0041] The receiver may use one or more fields in a probe message header to control which reverse path the respective probe message is forwarded through. For example, the receiver may include fields such as source and destination IP addresses, protocol numbers, or segment routing headers to influence the path selection. The remaining fields in the probe message header may be used to ensure packet integrity or provide additional metadata, such as timestamps or unique sequence numbers for each probe message. One or more fields in the probe message header may comprise values used by the network to determine a forwarding path. These values may include hash-based identifiers used in ECMP, which rely on the packet's header fields to select a specific path, or explicit path identifiers in a source routing scenario.

[0042] In block 103, the method comprises receiving, by the sender, zero or more of the multiple probe messages sent by the receiver. The number of probe messages received by the sender may depend on factors such as network conditions, path reliability, and the presence of faults. For instance, if a specific reverse path is faulty, the corresponding probe message may be lost, resulting in fewer received messages.

[0043] The method comprises, in block 104, determining, by the sender, the presence of path faults in the network based on the number of probe messages received. The sender analyses the number of received probe messages to identify potential faults. For example, if the sender does not receive any probe messages, this may indicate a fault on the forward path (the path from the sender to the receiver). Conversely, if the sender receives only some of the expected probe messages, it may infer that specific reverse paths are faulty.

[0044] For example, if the sender does not receive any of the multiple probe messages sent by the receiver, the sender may determine that there is a fault present on a forward path in the network. A forward path refers to the route taken by the reverse probe request message from the sender to the receiver, as opposed to the reverse path, which is the route taken by the probe messages from the receiver to the sender. Similarly, if the sender receives some - for example, at least one - but not all messages sent by the receiver, the sender may determine that a fault is present on at least one reverse path in the network. In this case, the received probe messages help identify which reverse paths are functional, while the absence of certain messages points to the faulty paths. Finally, if the sender receives all of the messages sent by the receiver, the sender may determine that no faults are present in the network - in other words, that both the forward and reverse paths are fully functional.

[0045] Figure 2 is a schematic representation of reverse path fault detection according to an example. In particular, Figure 2 demonstrates the procedure in an ideal situation where all paths between the receiver and the sender are operational, and the sender receives probes over all specified paths. The sender 201 initiates the process by sending a reverse probe request to the receiver 202. In response, the receiver 202 sends probes back to the sender 201 over multiple available paths. Two such paths are depicted: probe path 1 and probe path (n), both successfully reaching the sender 201. However, the disclosure is not limited thereto, and many more probe paths may be present.Figure 3 depicts a schematic representation of reverse path fault detection according to another example. Same elements in Figures 2 and 3 are referred to using the same reference numerals and function likewise. Figure 3 shows a scenario where a fault exists on one of the paths. Similar to the example in Figure 2, the sender 201 sends a reverse probe request to the receiver 202. The receiver 202 attempts to send probes back to the sender 201 over multiple paths, including probe path 1 and probe path (n). However, probe path (i), which is also initiated by the receiver, is incomplete and does not reach the sender due to a fault. Thus, figure 3 depicts detection of a reverse path fault when the sender 201 identifies that it has not received a probe over probe path (i), indicating an issue with that specific path.

[0046] Figure 4 is a schematic representation of a system according to an example. The system 400 comprises a sender 410 and at least one receiver 420. The system 400 comprises the sender 410 and the receiver 420 arranged to perform the method described herein in relation to Figures 1-3. In particular, the sender 410 is configured to send a reverse probe request message to the receiver 420. The receiver 420 is configured to receive the reverse probe request message, and send multiple probe messages to the sender in response to the reverse probe request message. The sender 410 is configured to receive zero or more of the multiple probe messages sent by the receiver 420 and to determine the presence of path faults in the network based on the number of probe messages received.

[0047] The preceding description has been provided to enable others skilled in the art to best utilize various aspects of the exemplary embodiments disclosed herein. This exemplary description is not intended to be exhaustive or to be limited to any precise form disclosed. Many modifications and variations are possible without departing from the spirit and scope of the instant disclosure. The embodiments disclosed herein should be considered in all respects illustrative and not restrictive. Reference should be made to the appended claims and their equivalents in determining the scope of the instant disclosure.

Claims

CLAIMS1. A method for detecting path faults in a network, the method comprising:sending, by a sender, a reverse probe request message to a receiver (101);in response to receiving, by the receiver, the reverse probe request message, sending, by the receiver, multiple probe messages to the sender (102);receiving, by the sender, zero or more of the multiple probe messages sent by the receiver (103); and determining, by the sender, the presence of path faults in the network based on the number of probe messages received (104).

2. The method of claim 1 , wherein, in response to receiving, by the sender, none of the multiple probe messages sent by the receiver, a fault is detected on a forward path in the network.

3. The method of claim 1 or 2, wherein, in response to receiving, by the sender, at least one but not all of the multiple probe messages sent by the receiver, a fault is detected on at least one reverse path in the network.

4. The method of any one of claims 1 to 3, wherein, in response to receiving, by the sender, all of the multiple probe messages sent by the receiver, it is determined that there are no faults in the network.

5. The method of any one of claims 1 to 4, wherein sending, by the sender, the reverse probe request message to the receiver (101) comprises sending multiple reverse probe request messages, wherein each of the multiple reverse probe request messages is sent over a different forward path in the network.

6. The method of any one of claims 1 to 5, wherein the reverse probe request message specifies a number of reverse paths to be probed.

7. The method of claim 6, wherein the number of probe messages sent by the receiver to the sender is equal to the number of reverse paths to be probed specified in the reverse probe request message.

8. The method of any one of claims 1 to 7, wherein each probe message sent by the receiver includes information indicating the total number of reverse paths probed.

9. The method of any one of claims 1 to 8, wherein the receiver uses one or more fields in the probe message header to control which reverse path the respective probe message is forwarded through.

10. The method of claim 9, wherein the one or more fields in the probe message header comprise values used by the network to determine a forwarding path.

11. The method of any one of claims 1 to 10, wherein the multiple probe messages sent by the receiver are transmitted over different paths in the network.

12. A system (400) for detecting path faults in a network, the system (400) comprising:a sender (410) configured to send a reverse probe request message to a receiver (420); andthe receiver (420) configured to:receive the reverse probe request message; andsend multiple probe messages to the sender (410) in response to the reverse probe request message,wherein the sender (410) is configured to receive zero or more of the multiple probe messages sent by the receiver (420) and to determine the presence of path faults in the network based on the number of probe messages received.

13. The system of claim 12, wherein the reverse probe request message comprises an indication of the number of reverse paths to be probed, and the receiver (420) is arranged to send a number of probe messages corresponding to the indicated number of reverse paths.

14. The system of claim 12 or 13, wherein each probe message sent by the receiver (420) comprises an identifier of the reverse path used to send the respective probe message.

15. The system of any one of claims 12 to 14, further comprising a set of network devices configured to forward the probe messages to the sender (410) based on a routing protocol, wherein the routing protocol uses one or more fields in the message header to select one of multiple available paths to the sender (410).