Path signature of data flow

Abstract

The present disclosure describes various methods, systems, and devices related to identifying path changes of data flows in a network. An example method includes receiving, at a node, a packet that includes a first path signature. The method further includes generating a second path signature by inputting the first path signature and one or more node details into a hash function. The method includes replacing the first path signature with the second path signature in the packet. The packet that includes the second path signature is forwarded by the node.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims priority to U.S. Application No. 16 / 661,540, filed on October 23, 2019, the entire content of which is incorporated herein by reference. Technical Field

[0003] The present disclosure generally relates to generating path signatures for data streams over a network and diagnosing network problems based on the path signatures. Background Art

[0004] Data can be transmitted from a source to a destination over a network in the form of a unidirectional data stream. The data stream may include multiple data packets that are propagated from the source to the destination over the network. The order in which the data packets are transmitted from the source may be the order in which the data packets are to be consumed by the destination. For example, a content server may transmit the data packets in a video stream in an order corresponding to the progression of the video, such that the data packets corresponding to the beginning of the video are transmitted first and the data packets corresponding to the end of the video are transmitted subsequently.

[0005] Various modern network topologies may include various nodes through which information can be transmitted. Individual nodes in the network can be connected to more than two other nodes in the network. Due to the interconnectivity of the nodes, there may be multiple paths through the network between any two endpoints. Individual nodes can select an appropriate path based on various conditions of the network. For example, a node can select between multiple paths based on load balancing, connectivity, etc.

[0006] However, if the data packets in the same data stream are transmitted over the network along different paths, the order in which the data packets arrive at the destination may be different from the order in which they are intended to be consumed. For example, one packet may be transmitted through a node with high latency, while another data packet may be transmitted through a node with lower latency. Out-of-Order (OoO) data packets can have a negative impact on the Quality of Service (QoS) of the end user. To avoid OoO data packets in a data stream, it is necessary to identify whether the packets in a particular data stream travel different paths through the network.

[0007] In-situ Operations, Administration, and Management (IOAM) provides mechanisms by which each node that transmits data packets over a network can add metadata to the data packets. In some cases, this metadata can be used to derive the path that a data packet traverses through the network. However, IOAM metadata can significantly increase the size of a given data packet. At each hop through the network, the IOAM metadata may add a large amount of data (e.g., 100 bytes) to a given data packet. In various networks, the size of the IOAM metadata may be unacceptable, especially when a data packet traverses a large number of nodes on its way to a destination. For example, in various networks, nodes may lack the hardware required to support IOAM and to transmit data packets with IOAM metadata. Some alternatives to IOAM, such as In-Network Telemetry (INT), Inband Flow Analyzer (IFA), and In-situ Flow Information Telemetry (IFIT), also have similar drawbacks. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The following detailed description will be made with reference to the accompanying drawings. In the drawings, the leftmost digit(s) of a reference numeral indicates the drawing in which the reference numeral first appears. The same reference numerals are used in different drawings to indicate similar or identical items. The systems depicted in the drawings are not to scale, and the components in the drawings may not be depicted to scale relative to each other.

[0009] Figure 1 An example environment is illustrated in which packets of a flow are transmitted over different paths in a network.

[0010] Figure 2 An example environment is illustrated in which a first packet of a flow is transmitted over a first path in a network.

[0011] Figure 3 An example environment is illustrated in which a second packet of a flow is transmitted over a second path in a network.

[0012] Figure 4A and Figure 4B An example environment is illustrated in which a node forwards packets of a flow with a path signature.

[0013] Figure 5A and Figure 5B An example environment is illustrated in which a node forwards packets of a flow with a revised path signature.

[0014] Figure 6A Illustrates an example of a flow table with various entries corresponding to different flows passing through a particular node.

[0015] Figure 6B Illustrates an example of a flow table with various entries corresponding to different path signatures of packets in a flow, where the path signatures correspond to different paths taken by the packets of the flow.

[0016] Figure 7A Illustrates an example process for adding a path signature to a data packet.

[0017] Figure 7B Illustrates an example process for updating the path signature of a data packet.

[0018] Figure 8 Illustrates an example process for sending an alert based on data packets with different path signatures.

[0019] Figure 9 Illustrates an example process for reporting a problem to a central administrator based on a path change.

[0020] Figure 10 Shows an example computer architecture of a computer capable of executing program components for implementing the functions described herein. Detailed Description

[0021] Overview

[0022] Aspects of the present invention are recited in the independent claims and preferred features are recited in the dependent claims. Features of one aspect may be applied alone to any aspect or in combination with other aspects.

[0023] The present disclosure describes various techniques for generating and utilizing in-situ path signatures for data flows traversing a network. A network node may generate a path signature for a particular data packet in a data flow traversing the network node. The path signature may represent the unique path that the data packet has traversed to reach the network node. When a network node identifies that different data packets in the same data flow have different path signatures, the network node may trigger an alert indicating that the packets in the data flow may be out of order and / or that there may be a problem with the network causing out-of-order packets. The network node may be a physical device, a server, a switch, etc.

[0024] In various implementations, the techniques described herein may be performed by a system and / or device having a non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors, perform the methods described herein.

[0025] Example Embodiments

[0026] Various implementations of the present disclosure relate to identifying a path through which data packets are transmitted over a network. Certain implementations provide a path signature data field in a data packet, which can be modified by individual nodes through which the data packet is transmitted.

[0027] In some implementations, a node may receive a data packet with an existing path signature. The node may input the existing path signature and other information based on the node itself into a hash function, which may return a revised path signature. The node may replace the existing path signature in the data packet with the revised path signature before forwarding the data packet to another node in the network. The revised path signature may represent the unique path that the data packet has traversed up to that node itself.

[0028] In certain cases, a node or some other device may track path signatures corresponding to data packets in the same data stream. If the node identifies a change in the path signature in the data stream, the node may send an alert to a collector. The collector may diagnose problems in the network based on the alert and / or other alerts corresponding to the data stream from other nodes in the network. In some cases, the path signature may be tracked as part of existing NetFlow functionality.

[0029] Unlike IOAM metadata, the path signature data field may have a fixed size, regardless of the number of nodes through which the data packet is transmitted. For example, the path signature data field may be limited to 32 bits or 64 bits. Since the path signature can have a relatively small size, it can be easily implemented in existing network node hardware.

[0030] The various implementations described herein provide specific improvements to the field of computer networking. As data streams are transmitted over a network, path signatures can enable in-situ network path tracking for individual data streams. Thus, problems within the network can be efficiently diagnosed in real time.

[0031] The various implementations of the present disclosure will be described in detail with reference to the accompanying drawings, in which like reference numerals represent like components and assemblies in several views. Additionally, any examples recited in this specification are not intended to be limiting, but merely recite some of the many possible implementations.

[0032] Figure 1 An example environment 100 is illustrated in which packets of a flow are transmitted over different paths. In Figure 1 , data plane transmissions are depicted by solid arrows and control plane transmissions are depicted by dashed arrows.

[0033] As Figure 1As shown, source 102 may send data to destination 104 via network 106. Source 102 and destination 104 may each be an example of a node. As used herein, the terms "node", "network node", and their equivalents, may refer to any entity within a network that can send packets to and / or receive packets from at least one other node. A node may be a device, a software instance, a virtual machine (VM), and the like. In some examples, a node may be a client, a server, or a combination thereof. In some cases, a node may be an endpoint of a flow, such as source 102 or destination 104. Source 102 may be, for example, a content server. Destination 104 may be, for example, a user equipment (UE).

[0034] Source 102 may send data in a flow that includes ordered packets 108. As used herein, the terms "flow", "data flow", "traffic flow", "packet flow", and their equivalents, may refer to a plurality of packets sent from a source to a destination. In some examples, a flow may include packets that share at least one of the following: the same ingress interface (e.g., SNMPifIndex), source (e.g., from the same IP address), destination (e.g., pointing to the same IP address), protocol (e.g., IP protocol), source port (e.g., for UDP or TCP), destination port (e.g., for UDP, TCP, or ICMP), or type of service (e.g., IP type of service (ToS)). As used herein, the terms "packet", "data packet", and their equivalents, may refer to a unit of data transmitted between two nodes. In various examples, a packet may have a header and a payload, the header may include control data, and the payload may include user data. The header may include information such as an identifier of the source of the packet, an identifier of the destination of the packet, an indication of the type of user data in the payload, and the like. In some cases, a packet may be defined by a particular networking protocol, such as IP, TCP, UDP, or other networking protocols.

[0035] As used herein, the term "port" and its equivalents may refer to a component of a node that is configured to connect the remainder of the node to an interface. A node may have a fixed set of ports that may be selectively connected to a particular interface. Each port of a node may have a unique identity, which may be represented by a port number. As used herein, the terms "ingress port", "incoming port", and their equivalents, may refer to the port through which a data packet enters a node. As used herein, the terms "egress port", "outgoing port", and their equivalents, may refer to the port through which a packet leaves a node.

[0036] AsFigure 1 As shown in Figure 1 , the ordered packets 108 are labeled in the order of "A", "B", and "C" and are sent from the source 102. The ordered packets 108 may successively arrive at the first node 110 in the network 106. The first node 110 may forward the packets along different paths through the network 106, which include the first path 112, the second path 114, and the third path 116. The first node 110 may forward the packets along different paths based on various factors. For example, the first node 110 may include a load balancer that may identify that the first path 112 is the least congested path when receiving packet "A", but may identify that the second path 114 is the least congested path when receiving packet "B". In some cases, the first node 110 may identify that the second path 114 is connected when receiving packet "B", but may identify that the second path 114 is disconnected when receiving packet "C", and thus may select the third path 116 instead of the second path 114 for packet "C". In a particular implementation, problems in the network (e.g., problems causing congestion or disconnection) may cause the first node 110 to forward the packets along different paths.

[0037] As used herein, the terms "path", "network path", and their equivalents may refer to a specific sequence of nodes and / or interfaces through which a packet may traverse. A path may be defined between two nodes. In some cases, the path of a packet transmitted from a first node to a second node may be defined based on the identity of the first node, the identity of the second node, and any sequence of intermediate nodes and / or interfaces through which the packet travels from the first node to the second node.

[0038] As used herein, the term "interface" and its equivalents may refer to a connection between two nodes in a network. In some cases, the interface may directly connect two nodes and / or may omit any intermediate nodes. The interface may connect to the first port of a first device and the second port of a second device. In some cases, the interface between two nodes may be a wired interface, whereby a packet may be transmitted as a signal conducted through a solid medium (e.g., an Ethernet cable, an optical fiber cable, etc.) connecting the two nodes. In some examples, the interface between nodes may be a wireless interface, whereby a packet may be transmitted as a signal through a fluid medium (e.g., air, water, etc.) connecting the two nodes. A wireless interface may be defined based on the type of wave used to carry the signal (e.g., acoustic wave, electromagnetic wave, etc.) and the frequency of the wave (e.g., ultrasonic frequency, radio frequency, infrared frequency, etc.). The interface may be further defined according to a specific communication protocol, which may indicate how the data transmitted through the interface is modulated. Some examples of communication protocols applicable to the present application include TCP / IP, Wi-Fi, Bluetooth, and the like.

[0039] As Figure 1 shown, the first path 112, the second path 114, and the third path 116 can converge at the second node 118, which can forward the packet to the destination 104. However, due to the differences between the first path 112, the second path 114, and the third path 116, the second node 118 may forward the packet to the destination 104 as an out-of-order (OoO) packet 120. Even though the in-order packets 108 are sent in the order of "A", "B", and "C", the OoO data packet 120 is received at the destination 104 in the order of "C", "A", and "B".

[0040] In various implementations, the first node 110 and the second node 118 can generate a path signature for the packet and modify the packet with the path signature. As used herein, the terms "signature", "path signature", and their equivalents can refer to a unique identifier of the path that the packet has traversed or is traversing. The path signature can be generated by a node, such as the first node 110 or the second node 118, based on at least one of the identifier of the node 110 or 118, the ingress port at which the node 110 or 118 receives the packet, or the egress port from which the node 110 or 118 forwards the packet for a given packet. The node 110 or 118 can further include the generated path signature in the given packet and forward the packet with the generated path signature to the destination 104.

[0041] In some cases, a revised path signature can be further generated based on a previous path signature. For example, the second node 118 can receive a given packet with a path signature generated from the first node 110 and / or any intermediate node that the packet has traversed between the first node 110 and the second node 118, and can use the previous path signature to generate a revised path signature for the given packet. Thus, in some implementations, as the path traverses the network 106, the path signature of the packet can be recursively revised.

[0042] According to various implementations of the present disclosure, the first node 110 and the second node 118 may identify that packets are being transmitted through different paths of the network 106. For example, the first node 110 may forward packets from different ports and may generate different path signatures for different packets based on the different ports. The first node 110 may identify that the path signatures are different and, in response, may send an alert 122 to the collector 124 indicating that the flow is being transmitted along different paths through the network 106. In some examples, the second node 118 may receive packets in different ports and may generate different path signatures for the packets due to the different ports. In certain implementations, the second node 118 may receive packets with different previous path signatures and may generate revised path signatures based on the different previous path signatures. The second node 118 may identify that the path signatures corresponding to the packets (e.g., generated, received, or revised) are different.

[0043] In response to identifying that the path signatures of different packets in a flow are different, the first node 110 may generate an alert 122 and send it to the collector 124. Similarly, in response to identifying that the path signatures of different packets in a flow are different, the second node 118 may generate an alert 126 and send it to the collector 124.

[0044] In some examples, the second node 118 may receive packets with different path signatures due to the first path 112, the second path 114, and the third path 116. The second node 118 may receive packets in different ports and may generate different path signatures for the packets due to the different existing path signatures and / or the different ports at which the packets are received. The second node 118 may identify that the path signatures of the received packets are different and / or that the path signatures of the sent packets are different and, in response, send an alert 126 to the collector 124 indicating that the flow is being transmitted along different paths through the network 106.

[0045] In a particular implementation, the collector 124 may identify that there is a problem with the network 106 based on the alerts 122 and 126. In some cases, the collector 124 may identify that the alert 122 is received from an upstream node (i.e., the first node 110) and the alert 126 is received from a downstream node (i.e., the second node 118). Thus, the collector 124 may identify that the problem is associated with the first node 110 rather than the second node 118. Once the problem is identified, the problem can be resolved by an administrator of the network 106.

[0046] Figure 2 An example environment 200 is illustrated where packets of a flow are transmitted through a first path in a network and the network does not generate an alert.

[0047] Source 202 can send the stream through a network including node A 204-A, node B 204-B, node C 204-C, and node D 204-D. Destination 206 can receive the stream after the stream is transmitted through the network. The network can have multiple layers of nodes. For example, node A 204-A is in the first layer, node B 204-B and node C 204-C are in the second layer, and node D 204-D is in the third layer.

[0048] As Figure 2 shown, the stream includes a first packet 208. As Figure 2As shown, the first packet 208 can be sent from the source 202 to node A 204-A. Node A 204-A can generate a path signature for the first packet 208 and can forward the first packet 208 with the path signature to node B 204-B. In an example where the first packet 208 includes a previous path signature when it is received by node A 204-A, node A 204-A can generate a new path signature at least in part based on the previous path signature. In the case where the first packet 208 does not include a previous path signature, node A 204-A can rely on other factors to generate the path signature. In various implementations, node A 204-A can generate the path signature based on any one of various factors associated with node A 204-A and / or how the first packet 208 is routed through node A 204-A. In various implementations, the first packet 208 can carry the path signature as metadata encapsulated in the header. For example, the first packet 208 can carry the path signature encapsulated in the IP (e.g., IPv4 or IPv6) header of the first packet 208, such as encapsulated in an IP option (e.g., IPv4), an extension header (e.g., IPv6), etc. In some cases, the first packet 208 can include an Ethernet frame, and the path signature can be included in the payload of the Ethernet frame and can be identified by the EtherType field of the Ethernet frame. In some examples, the path signature can be included in at least one of the following in the first packet 208: Network Service Header (NSH), Geneve header, Virtual Extensible Local Area Network (VXLAN)-Generic Protocol Extension (GPE) header, Segment Routing over IPv6 (SRv6) header, Multiprotocol Label Switching (MPLS) header, etc. In some examples, the path signature can be encapsulated in at least one of IOAM, INT, IFA, or IFIT metadata.

[0049] In various implementations, node A 204-A can identify that the flow has not changed paths based on the path signature generated by node A 204-A for the first packet 208. In some cases, the first packet 208 may be the initial packet received by node A 204-A in the flow. In some situations, the path signature generated by node A 204-A for the first packet 208 may be the same as the path signature previously generated by node A 204-A for a previous packet received and forwarded by node A 204-A in the flow. Since node A 204-A does not identify a path change in the flow, node A 204-A may not generate an alert associated with the flow.

[0050] The first packet 208 with the path signature generated by node A 204-A can be sent from node A 204-A to node B 204-B. In some cases, node B 204-B can forward the first packet 208 to node D 204-D without modifying or updating the path signature in the first packet 208. However, in some implementations, node B 204-B can generate its own path signature for the first packet 208 and can forward the first packet 208 with the path signature to node B 204-B. Node B 204-B can iteratively generate its new path signature at least in part based on the previous path signature generated by node A 204-A. In various implementations, node B 204-B can generate its new path signature based on any one of various factors associated with node B 204-B and / or how the first packet 208 is routed through node B 204-B.

[0051] In various implementations, node B 204-B can identify that the flow has not changed paths based on the path signature generated by node A 204-A for the first packet 208 and / or the path signature generated by node B 204-B for the first packet 208. In some cases, the first packet 208 may be the initial packet received by node B 204-B in the flow. In some situations, the path signature generated by node B 204-B for the first packet 208 may be the same as the path signature previously generated by node B 204-B for a previous packet received (from node A 204-A) and forwarded by node B 204-B in the flow. Since node B 204-B does not identify a path change in the flow, node B 204-B may not generate an alert associated with the flow.

[0052] A first packet 208 with a path signature generated by node A 204-A or node B 204-B can be sent from node B 204-B to node D 204-D. In various implementations, node D 204-D can generate its own path signature for the first packet 208 and can forward the first packet 208 with the path signature to the destination 206. Node D 204-D can iteratively generate its new path signature based at least in part on the previous path signature in the first packet 208 received by node D 204-D, which can be the path signature generated by node A 204-A or node B 204-B. In various implementations, node D 204-D can generate its new path signature based on any one of various factors associated with node D 204-D and / or how the first packet 208 is routed through node D 204-D.

[0053] In various implementations, node D 204-D can identify that the flow has not changed paths based on the path signature generated by node D 204-D for the first packet 208. In some cases, the first packet 208 may be the initial packet received by node D 204-D in the flow. In some situations, the path signature generated by node D 204-D for the first packet 208 may be the same as the path signature previously generated by node D 204-D for previous packets received and forwarded by node D 204-D in the flow (from node A 204-A and node B 204-B). Because node D 204-D does not identify a path change in the flow, node D 204-D may not generate an alert associated with the flow.

[0054] Figure 3 An example environment 300 is illustrated in which subsequent packets of the flow are transmitted over a second path in the network. The flow referred to Figure 3 can be the same flow as the flow discussed above for Figure 2 the flow discussed.

[0055] As Figure 3As shown, the flow includes a second packet 302. Similar to the first packet 208, the second packet 302 can be sent from the source 202 to node A 204-A. Node A 204-A can generate a path signature for the second packet 302. However, unlike the first packet 208, node A 204-A can forward the second packet 302 with the path signature to node C 204-C. In an example where the second packet 302 includes a previous path signature when it is received by node A 204-A, node A 204-A can generate a new path signature at least in part based on the previous path signature. In the case where the second packet 302 does not include a previous path signature, node A 204-A can rely on other factors to generate the path signature. In various implementations, node A 204-A can generate the path signature based on any one of various factors associated with node A 204-A and / or how the second packet 302 is routed through node A 204-A.

[0056] In various implementations where node A 204-A generates a path signature for the second packet 302 based on how the second packet 302 is routed through node A 204-A, the path signature generated by node A 204-A for the second packet 302 can be different from the path signature generated by node A 204-A for the first packet 209. Specifically, node A 204-A can generate a path signature for the first packet 208 based on routing the first packet 208 to node B 204-B, and can generate a path signature for the second packet 302 based on routing the second packet 302 to node C 204-C. Based on the different path signatures generated for the first packet 208 and the second packet 302, node A 204-A can identify that the flow has changed paths. In response to identifying the path change, node A 204-A can generate an alert 304 and send the alert 304 to the collector 308. The alert 304 can identify the flow whose path has changed, the time the flow changed paths, node A 204-A, and so on.

[0057] In various implementations, the second packet 302 can carry the path signature as metadata encapsulated in the header. For example, the second packet 302 can carry a path signature encapsulated in the IP (e.g., IPv4 or IPv6) header of the first packet 208, such as encapsulated in IP options (e.g., IPv4), extension headers (e.g., IPv6), and so on. In some cases, the second packet 302 can include an Ethernet frame, and the path signature can be included in the payload of the Ethernet frame and can be identified by the EtherType field of the Ethernet frame. In some examples, the path signature can be included in at least one of the following in the second packet 302: Network Service Header (NSH), Geneve header, Virtual Extensible LAN (VXLAN)-Generic Protocol Extension (GPE) header, IPv6 Segment Routing (SRv6) header, Multiprotocol Label Switching (MPLS) header, and so on. In some examples, the path signature can be encapsulated in at least one of IOAM, INT, IFA, or IFIT metadata.

[0058] The second packet 302 with the path signature generated by node A 204-A can be sent from node A 204-A to node C 204-C. In some cases, node C 204-C can forward the second packet 302 to node D 204-D without modifying or updating the path signature in the second packet 302. However, in some implementations, node C 204-C can generate its own path signature for the second packet 302 and can forward the second packet 302 with the path signature to node D 204-D. Node C 204-C can iteratively generate its new path signature at least partially based on the previous path signature generated by node A 204-A. In various implementations, node C 204-C can generate its new path signature based on any one of various factors associated with node C 204-C and / or how the second packet 302 is routed through node C 204-C.

[0059] In various implementations, node C 204-C may not recognize that the flow has changed paths. For example, the second packet 302 may be the first packet that node C 204-C has received in the flow. Since node C 204-C does not recognize a path change in the flow, node C 204-C can not generate an alert associated with the flow.

[0060] A second packet 302 with a path signature generated by node A 204-A or node C 204-C can be sent from node C 204-C to node D 204-D. In various implementations, node C 204-C can generate its own path signature for the second packet 302 and can forward the second packet 302 with the path signature to the destination 206. Node D 204-D can iteratively generate its new path signature based at least in part on a previous path signature in the second packet 302 received by node D 204-D, which can be a path signature generated by node A 204-A or node C 204-C. In various implementations, node D 204-D can generate its new path signature based on any one of various factors associated with node D 204-D and / or how the second packet 302 is routed through node D 204-D. In various examples, the path signature generated by node D 204-D for the second packet 302 can be different from the path signature generated by node D 204-D for the first packet 208.

[0061] In various implementations, node D 204-D can identify that a flow has changed paths based on the path signature generated by node D 204-D for the first packet 208 and the path signature generated by node D 204-D for the second packet 302. In response to identifying the path change, node D 204-D can send an alert 306 to the collector 308. The alert 306 can identify the flow that has changed paths, the time the flow changed paths, node D 204-D, and so on.

[0062] The collector 308 can identify a problem with the network based on the alert 304 from node A 204-A and the alert 306 from node D 204-D. In some cases, the collector 308 can assume that any problem with the network that causes a change in the path signature will cause a change in the path signature at all nodes downstream of that problem. Thus, although alerts 304 and 306 are received from both node A 204-A and node D 204-D, the collector 308 can identify that the problem with the network is associated with node A 204-A rather than node D 204-D.

[0063] In response to identifying a problem with the network, the collector 308 can send a report 310 to the central administrator 312. The report 310 can identify information about the problem, such as the node associated with the problem (e.g., node A 304-A), the time the problem was identified, and so on. The central administrator 312 can initiate a process by which the problem can be resolved.

[0064] Figure 4A An example environment 400 is illustrated in which nodes forward a first packet of a flow with a path signature. Specifically,Figure 4A Illustrated is an example where node A 204-A forwards the first packet 208.

[0065] As Figure 4A shown, node A 204-A receives the first packet 208. In Figure 4A , node A 204-A may receive the first packet 208 without a path signature. Node A 204-A receives the first packet 208 at the first ingress port 402-1. In a particular implementation, node A 204-A includes a plurality of ingress ports, such as the first ingress port 402-1 and the second ingress port 402-2. Each ingress port in node A 204-A (i.e., each of the first ingress port 402-1 and the second ingress port 402-2) may be associated with a unique identifier that differentiates the ingress port from other ingress ports in node A 204-A. A port number is an example of an identifier for an ingress port.

[0066] In Figure 4A the example shown, the path signature updater 404 intercepts the first packet 208. The path signature updater 404, or some other component of node A 204-A, selects an appropriate egress port among the first egress port 406-1 and the second egress port 406-2. Each egress port in node A 204-A (i.e., each of the first egress port 406-1 and the second egress port 406-2) may be associated with a unique identifier that differentiates the egress port from other egress ports in node A 204-A. A port number is an example of an identifier for an egress port. In the example of FIG. 4, the first egress port 406-1 has been selected.

[0067] Based on various information, such as at least one of the identifier of the first ingress port 402-1 where the first packet 208 is received, the identifier of the first egress port 406-1 that will forward the first packet 208, the identifier of node A 204-A itself, etc., the path signature updater 404 generates a first path signature 408 for the first packet 208. Examples of the identifier of node A 204-A may include a unique identification number associated with node A 204-A.

[0068] In a particular implementation, the path signature updater 404 uses a hash function to generate a first path signature 408. The hash function can return a unique value in response to a unique input. Thus, as long as the input to the hash function indicates a unique path through the network for a particular packet, the hash function will return a value unique to that path. In some examples, the hash function used by the path signature updater 404 is a cryptographic hash function, an exclusive - OR function, CRC32, or the like. For example, in various device - centric implementations, the path signature updater 404 can use the following formula 1 to generate the first path signature 408:

[0069] Formula 1 S 0 = Hash(P i ,P e ,N 1 )

[0070] where S 0 is the path signature (e.g., the first path signature 408 generated by node A 204 - A), Hash() is the hash function, P i is the identifier of the ingress port (e.g., the first ingress port 402 - 1) where the packet is received (e.g., the first packet 208), P e is the identifier of the egress port (e.g., the first egress port 406 - 1) from which the packet is forwarded, and N 1 is the identifier of the node (e.g., node A 204 - A). According to some examples, the path signature updater 404 can use the following formula 2 to generate the first path signature 408:

[0071] Formula 2 S 0 = Hash(P e ,N 1 )

[0072] where S 0 is the path signature (e.g., the first path signature 408 generated by node A 204 - A), Hash() is the hash function, P e is the identifier of the egress port (e.g., the first egress port 406 - 1) from which the packet is forwarded (e.g., the first packet 208), and N 1 is the identifier of the node (e.g., node A 204 - A). In some lightweight implementations, the path signature updater 406 uses the following formula 3 to generate a second path signature 410:

[0073] Formula 3 S 0 = Hash(N 1 )

[0074] where S 0is a path signature (e.g., the first path signature 408 generated by node A 204-A), Hash() is a hash function, and N 1 is an identifier of a node (e.g., node A 204-A).

[0075] In a particular flow-centric implementation, the path signature updater 404 can use the following formula 4 to generate a unique identifier for a flow:

[0076] Formula 4 f = Hash(I S , I D , P S , P D , Pro)

[0077] where f is the identifier of the flow, Hash() is a hash function, I S is the identifier of the source of the flow (e.g., the IP address of the source of the data packets in the flow), I D is the identifier of the destination of the flow (e.g., the IP address of the destination of the data packets in the flow), P S is the identifier of the source port (e.g., the port number), P D is the identifier of the destination port (e.g., the port number), and Pro is the identifier of the protocol associated with the flow (e.g., the protocol indicating the type of data transmitted in the flow). In some cases, various elements of the hash function in formula 4 can be omitted. For example, a 3-tuple hash function taking I S , I D and Pro as inputs can be used to uniquely identify the flow.

[0078] In various cases, the path signature updater 404 can use the identifier of the flow calculated in formula 4 to generate a path signature using the following formula 5:

[0079] Formula 5 S 0 = Hash(P i , P e , f, N 1 )

[0080] where S 0 is a path signature (e.g., the first path signature 408 generated by node A 204-A), Hash() is a hash function, P i is the identifier of the ingress port (e.g., the first ingress port 402-1) where the packet is received (e.g., the first packet 208), P e is the identifier of the egress port (e.g., the first egress port 406-1) from which the packet is forwarded, f is the identifier of the flow (e.g., generated using formula 4), and N 1is an identifier of a node (e.g., node A 204-A). According to some examples, the path signature updater 404 can use the following formula 6 to generate the first path signature 408:

[0081] Formula 6 S 0 = Hash(P e , f, N 1 )

[0082] where S 0 is the path signature (e.g., the first path signature 408 generated by node A 204-A), Hash() is a hash function, P e is the identifier of the egress port (e.g., the first egress port 406-1) from which the packet (e.g., the first packet 208) is forwarded, f is the identifier of the flow (e.g., generated using formula 4), and N 1 is the identifier of the node (e.g., node A 204-A). In some lightweight implementations, the path signature updater 406 uses the following formula 7 to generate the second path signature 410:

[0083] Formula 7 S 0 = Hash(f, N 1 )

[0084] where S 0 is the path signature (e.g., the first path signature 408 generated by node A 204-A), Hash() is a hash function, f is the identifier of the flow (e.g., generated using formula 4), and N 1 is the identifier of the node (e.g., node A 204-A).

[0085] Regardless of the formula used by the path signature updater 404, the first path signature 408 can uniquely represent the path of the first packet 208 through node A 204-A. In examples where the path signature updater 404 uses formula 1, 2, 6, or 7, the first path signature 408 can further identify a path including node B 204-B to which the first packet 208 is forwarded using the first egress port 406-1.

[0086] The path signature updater 404 adds the first path signature 408 to the first packet 208. In some examples, the path signature updater 404 adds the first path signature 408 to the header of the first packet 208. For example, the path signature updater 404 may insert a path signature field into the first packet 208 and populate the path signature field with the first path signature 408. In some cases, the path signature field is included in a header field (e.g., an IP header, an IPv4 option, an IPv6 extension header, an NSH header, a Geneve header, a VXLAN-GPE header, an SRv6 header, or an MPLS header) and / or is included in the payload (e.g., identified by an EtherType). In some examples, the path signature field is included in at least one of IOAM, INT, IFA, or IFIT metadata. Depending on the particular implementation, the path signature field has a fixed size. For example, the path signature field has a fixed size of 32 bits, 64 bits, or the like. Thus, in various implementations, each path signature (e.g., the first path signature 408) generated by the path signature updater 404 will have the same fixed size as the path signature field.

[0087] The path signature updater 404 may further forward the first packet 208 with the first path signature 408 through the first egress port 406-1. The first egress port 406-1 may be connected to an interface that is connected to another node in the same network as node A 204-A. For example, as Figure 2 shown, the first packet 208 may be forwarded from the first egress port 406-1 to node B 204-B.

[0088] As Figure 4A shown, the path signature updater 404 further stores the first path signature 408 in the flow table 410. In some cases, the flow table 410 includes multiple entries corresponding to different packets received and forwarded by node A 204-A. For example, the flow table 410 may include an entry corresponding to the first packet 208 that includes the first path signature 408. In some cases, these entries also identify the flows of different packets received and forwarded by node A 204-A. For example, the entry corresponding to the first packet 208 may further include information identifying the flow that includes the first packet 208.

[0089] Node A 204-A also includes a path change recognizer 412 in various implementations. The path change recognizer 412 can be configured to access the flow table 410 to determine whether packets in a specific flow have different paths. In some examples, the path change recognizer 412 can determine that the first path signature 408 corresponds to the initial path signature generated by the path signature updater 404 for the flow, so it can be assumed that no path change has occurred for the flow. In some cases, the path change recognizer 412 can determine that the first path signature 408 matches the previous path signature generated by the path signature updater 404 for the flow, so it can be assumed that no path change has occurred for the flow. When the path change recognizer 412 determines that no path change has occurred, the path change recognizer 412 may not generate an alert.

[0090] Figure 4B An example environment 414 is illustrated in which a node forwards another packet of a flow with a path signature. Specifically, Figure 4B An example is illustrated in which node A 204-A forwards a second packet 302.

[0091] As Figure 4B shown, node A 204-A receives a second packet 302 without a path signature. Node A 204-A receives the second packet 302 at the first ingress port 402-1. The path signature updater 404 intercepts the second packet 302.

[0092] The path signature updater 404, or some other component of node A 204-A, can select an appropriate egress port for the second packet 302 among the first egress port 406-1 and the second egress port 406-2. However, node A 204-A can select the second egress port 406-2 for the second packet 302, which is different from the first egress port 406-1 selected for the first packet 208. Node A 204-A can select the second egress port 406-2 for any of various reasons. For example, node A 204-A can identify that the interface connected to the first egress port 406-1, or the node (i.e., node B 204-B) connected to that interface, has become disconnected since the first packet 208 was forwarded. In some examples, node A 204-A can include a load balancer that identifies that the load associated with the first egress port 406-1 exceeds the load associated with the second egress port 406-2. For example, the node connected to the first egress port 406-1 (i.e., node B 204-B) may be more congested and / or associated with a higher latency than the node connected to the second egress port 406-2 (i.e., node C 204-C).

[0093] Based on at least one of various information, such as the identifier of the first ingress port 402-1 that receives the second packet 302, the identifier of the second egress port 408-2 that will forward the second packet 302, the identifier of node A 204-A itself, etc., the path signature updater 404 generates a second path signature 416 for the second packet 302.

[0094] In a particular implementation, the path signature updater 404 uses one of formulas 1, 2, 5, or 6 to generate the first path signature 408 and the second path signature 416. Thus, the first path signature 408 can be generated based on the identifier of the first egress port 406-1, and the second path signature 416 can be generated based on the identifier of the second egress port 406-2. At least for this reason, the second path signature 416 may be different from the first path signature 408.

[0095] The path signature updater 404 adds the second path signature 416 to the second packet 302. In some examples, the path signature updater 404 adds the second path signature 416 to the header of the second packet 302. For example, the path signature updater 404 can insert a path signature field into the second packet 302 and fill the path signature field with the second path signature 416. In some cases, the second path signature 416 may have the same size as the first path signature 408.

[0096] The path signature updater 404 can further forward the second packet 302 with the second path signature 416 through the second egress port 406-2. The second egress port 406-2 can be connected to an interface that is connected to another node in the same network as node A 204-A. For example, as Figure 3 shown, the second packet 302 can be forwarded from the second egress port 406-2 to node C 204-C.

[0097] As Figure 4B shown, the path signature updater 404 further stores the second path signature 416 in the flow table 410. In some cases, the flow table 410 may already have stored a first entry corresponding to the first packet 208 that includes the first path signature 408. The flow table can further store a second entry corresponding to the second packet 302 that includes the second path signature 416. In some cases, the first and second entries corresponding to the first packet 208 and the second packet 302 may also include information identifying the flow that includes the first packet 208 and the second packet 302.

[0098] The path change recognizer 412 can determine that the second path signature 416 stored in the second entry of the flow table 410 is different from the first path signature 408 stored in the first entry of the flow table 410. Based on this difference, the path change recognizer 412 can determine that there is a path change in the flow. In some cases, the path change recognizer 412 can determine that a number of packets with the first path signature 408 greater than a threshold and / or a number of packets with the second path signature 416 greater than a threshold have been received, and in response, recognize that there is a persistent path change in the flow. In response to determining that there is a path change, the path change recognizer 412 can generate and send an alert 304 from node A 204-A. The alert 304 can indicate the path change in the flow. As Figure 4B shown in the example of, the alert 304 includes a flow identifier 418. The flow identifier 418 can indicate the flow including the first packet 208 and the second packet 302. For example, the flow identifier 418 can include at least one element of the 5-tuple associated with the flow, such as source (e.g., from the same IP address), destination (e.g., pointing to the same IP address), protocol (e.g., IP protocol), source port (e.g., for UDP or TCP), destination port (e.g., for UDP, TCP, or ICMP), or the type of service of the first packet 208 and the second packet 302 (e.g., IP type of service (ToS)). In an example where the alert 304 is sent to a collector (e.g., collector 310), the flow identifier 418 can be used to identify problems in the network that cause path changes.

[0099] Figure 5A FIG. illustrates an example environment 500 in which a node forwards a first packet of a flow with a path signature. Specifically, Figure 5A FIG. illustrates an example in which node D 204-D forwards the first packet 208.

[0100] As Figure 5A shown, node D 204-D receives the first packet 208 with a third path signature 502. In some implementations where no node between node A 204-A and node D 204-D in the path of the first packet 208 changes or updates the path signature field in the first packet 208, the third path signature 502 can be the first path signature 408 generated by node A 204-A. In certain implementations where the path signature field has been updated between node A 204-A and node D 204-D, the third path signature 502 can be based on the first path signature 408 generated by node A 204-A for the first packet 208.

[0101] Node D 204-D may receive a first packet 208 with a third path signature 502 at a first ingress port 502-1, which may be connected to another node in the same network as node D 204-D (i.e., node B 204-B). In a particular implementation, node D 204-D includes multiple ingress ports, such as a first ingress port 502-1 and a second ingress port 502-2. Each ingress port in node D 204-D (i.e., each of the first ingress port 502-1 and the second ingress port 502-2) may be associated with a unique identifier that differentiates that ingress port from other ingress ports in node D 204-D.

[0102] In Figure 5A the example shown, the path signature updater 504 intercepts the first packet 208. The path signature updater 504, or some other component of node D 204-D, selects an appropriate egress port among a first egress port 506-1 and a second egress port 506-2. Each egress port in node D 204-D (i.e., each of the first egress port 506-1 and the second egress port 506-2) may be associated with a unique identifier that differentiates that egress port from other egress ports in node A 204-A. In Figure 5A the example, the first egress port 506-1 has been selected.

[0103] Based on at least one of various information, such as the identifier of the first ingress port 502-1 that received the first packet 208, the identifier of the first egress port 508-1 that will forward the first packet 508, the identifier of node D 204-D itself, etc., the path signature updater 504 generates a fourth path signature 508 for the first packet 208. Additionally, the path signature updater 504 may use a recursive function to generate the fourth path signature 508, which is at least partially based on the third path signature 502 in the first packet 208 received by node D 204-D.

[0104] In a particular implementation, the path signature updater 504 uses a hash function to generate a fourth path signature 508 based on the third path signature 502. The hash function can return a unique value in response to a unique input. Thus, as long as the input to the hash function indicates a unique path through the network for a particular packet, the hash function will return a value that is unique for that path. In some examples, the hash function used by the path signature updater 404 is an encryption hash function, an exclusive OR function, CRC32, or the like. In a particular implementation, the hash function utilized by the path signature updater 504 in node D 204-D may be different from the hash function utilized by the path signature updater 404 in node A 204-A. In some cases, the path signature updater 504 can use the following formula 8 to generate the fourth path signature 508:

[0105] Formula 8 S n = Hash(S n-1 ,P i ,P e ,N 1 )

[0106] Where S n is the new path signature (e.g., the fourth path signature 508), Hash() is the hash function, S n is the previous path signature (e.g., the third path signature 502), P i is the identifier of the ingress port where the first packet is received (e.g., the identifier of the first ingress port 502-1), P e is the identifier of the egress port that forwards the packet (e.g., the identifier of the first egress port 506-1), and N 1 is the identifier of the node (e.g., the identifier of node D 204-D). According to some examples, the path signature updater 504 can use the following formula 9 to generate the first path signature 508:

[0107] Formula 9 S n = Hash(S n-1 ,P i ,N 1 )

[0108] Where S n is the new path signature (e.g., the fourth path signature 508), Hash() is the hash function, S n is the previous path signature (e.g., the third path signature 502), P i is the identifier of the ingress port where the first packet is received (e.g., the identifier of the first ingress port 502-1), and N 1is an identifier of a node (e.g., the identifier of node D 204-D). According to some examples, the path signature updater 504 can use the following formula 10 to generate the fourth path signature 508:

[0109] Formula 10 S n = Hash(S n-1 , N 1 )

[0110] where S n is the new path signature (e.g., the fourth path signature 508), Hash() is a hash function, S n is the previous path signature (e.g., the third path signature 502), and N 1 is an identifier of a node (e.g., the identifier of node D 204-D).

[0111] Regardless of the formula used by the path signature updater 504, the fourth path signature 508 can uniquely represent the path of the first packet 208 from the source of the first packet 208 to node D 204-D.

[0112] The path signature updater 504 can replace the third path signature 502 with the fourth path signature 508 in the first packet 208. In some examples, the path signature updater 504 deletes the third path signature 502 and adds the fourth path signature 508 to the header of the first packet 208. For example, the path signature updater 504 can delete the third path signature 502 from the path signature field in the first packet 208 and fill the path signature field with the fourth path signature 508. In some cases, the path signature field is included in a header field (e.g., an IP header, an IPv4 option, an IPv6 extension header, an NSH header, a Geneve header, a VXLAN-GPE header, an SRv6 header, or an MPLS header) and / or is included in the payload (e.g., identified by an EtherType). In some examples, the path signature field is included in at least one of the IOAM, INT, IFA, or IFIT metadata. According to a particular implementation, the path signature field has a fixed size. For example, the path signature field has a fixed size of 32 bits, 64 bits, or the like. Thus, the fourth path signature 508 can have the same size as the third path signature 502. In various implementations, each path signature (e.g., the fourth path signature 508) generated by the path signature updater 504 will have the same fixed size as the path signature field in the first packet 208.

[0113] The path signature updater 504 may further forward the first packet 208 with the fourth path signature 508 through the first egress port 506-1. The first egress port 506-1 may be connected to an interface that is connected to another node. For example, as Figure 2 shown, the first packet 208 may be forwarded from the first egress port 506-1 to the destination 206.

[0114] As Figure 5A shown, the path signature updater 504 further stores the fourth path signature 508 in the flow table 510. In some cases, the flow table 510 includes multiple entries corresponding to different packets received and forwarded by the node D 204-D. For example, the flow table 510 may include an entry corresponding to the first packet 208 that includes the fourth path signature 508. In some cases, the entry may also include the third path signature 502. In a particular implementation, the entry also identifies the flow of different packets received and forwarded by the node D 204-D. For example, the entry in the flow table 510 corresponding to the first packet 208 may also include information identifying the flow that includes the first packet 208.

[0115] The node D 204-D also includes a path change recognizer 512 in various implementations. The path change recognizer 512 may be configured to access the flow table 510 to determine whether the packets in a particular flow have different paths. In some examples, the path change recognizer 512 may determine that the fourth path signature 508 corresponds to the initial path signature generated by the path signature updater 504 for the flow, and thus it may be assumed that no path change has occurred for the flow. In some cases, the path change recognizer 512 may determine that the fourth path signature 508 matches the previous path signature generated by the path signature updater 504 for the flow, and thus it may be assumed that no path change has occurred for the flow. When the path change recognizer 512 determines that no path change has occurred, the path change recognizer 512 may not generate an alert.

[0116] Figure 5B An example environment 514 is illustrated in which a node forwards another packet of a flow with a path signature. Specifically, Figure 5B an example of the node D 204-D forwarding a second packet 302 is illustrated.

[0117] As Figure 5BAs shown, node D 204-D receives the second packet 302 with the fifth path signature 516. In some implementations where no node between node A 204-A and node D 204-D in the path of the second packet 302 changes or updates some of the path signature fields in the second packet 302, the fifth path signature 516 can be the second path signature 416 generated by node A 204-A. In certain implementations where the path signature field has been updated between node A 204-A and node D 204-D, the fifth path signature 516 can be based on the second path signature 416 generated by node A 204-A for the first packet 208.

[0118] Node D 204-D receives the second packet 302 at the second ingress port 502-2, rather than at the first ingress port 502-1 where the first packet 208 is received. This indicates that the path the second packet 302 travels before reaching node D 204-D is different from the path the first packet 208 travels. The path signature updater 504 intercepts the second packet 302. Node D 204-D can further select the first egress port 506-1 and forward the second packet 302 to its destination from this egress port.

[0119] Based on various information, such as at least one of the identifier of the second ingress port 502-2 where the second packet 302 is received, the identifier of the first egress port 508-1 to which the second packet 302 will be forwarded, the identifier of node D 204-D itself, etc., the path signature updater 504 generates the sixth path signature 518 for the second packet 302.

[0120] In various implementations, the path signature updater 504 can generate the sixth path signature 518 based on the previous fifth path signature 516 in the received second packet 302. In some examples, the path signature updater 404 uses at least one of formulas 8-10 to generate the fourth path signature 508 and the sixth path signature 518. The sixth path signature 516 can be different from the third path signature 502 at least partially based on the difference between the third path signature 502 and the fifth path signature 516, and / or the difference between the first ingress port 502-1 where the first packet 208 is received and the second ingress port 502-2 where the second packet 302 is received.

[0121] The path signature updater 504 may replace the fifth path signature 516 with the sixth path signature 518 in the second packet 302. In some examples, the path signature updater 504 deletes the fifth path signature 516 and adds the sixth path signature 518 to the header of the second packet 302. For example, the path signature updater 504 may delete the fifth path signature 516 from the path signature field in the second packet 302 and fill the path signature field with the sixth path signature 518. In some cases, the path signature field is included in a header field (e.g., an IP header, an IPv4 option, an IPv6 extension header, an NSH header, a Geneve header, a VXLAN-GPE header, an SRv6 header, or an MPLS header) and / or is included in the payload (e.g., identified by an EtherType). In some examples, the path signature field is included in at least one of the IOAM, INT, IFA, or IFIT metadata. The path signature field may have a fixed size. Thus, the sixth path signature 518 may have the same size as the fifth path signature 516. The path signature updater 504 may further forward the second packet 302 with the sixth path signature 518 through the first egress port 506-1.

[0122] As Figure 5B shown, the path signature updater 504 further stores the sixth path signature 518 in the flow table 410. In some cases, the flow table 510 may already have stored a first entry corresponding to the first packet 208 that includes the fourth path signature 508. In some cases, the first entry may further include the third path signature 502. The flow table 510 may further store a second entry corresponding to the second packet 302 that includes the sixth path signature 518. In some examples, the second entry may further include the fifth path signature 516. In some cases, the first and second entries corresponding to the first packet 208 and the second packet 302 may also include information identifying the flow that includes the first packet 208 and the second packet 302.

[0123] The path change recognizer 512 may determine that the sixth path signature 518 stored in the second entry of the flow table 510 is different from the fourth path signature 508 stored in the first entry of the flow table 510. Based on this difference, the path change recognizer 512 may determine that there is a path change in the flow. In response to determining that there is a path change, the path change recognizer 512 may generate and send an alert 306 from the node D 204-D. The alert 306 may indicate the path change in the flow. As Figure 5B shown in the example of, the alert 306 includes the flow identifier 418. In an example where the alert 306 is sent to a collector (e.g., the collector 308), the flow identifier 518 may be used to identify the problem in the network that caused the path change.

[0124] Figure 6A Illustrates an example of a flow table 600, which has various entries corresponding to different flows passing through a particular node. In some examples, the flow table 600 can be used as the flow table 410 referenced above Figure 4A and Figure 4B described, or the flow table 510 referenced above Figure 5A and Figure 5B described. In various implementations, the flow table 600 can be managed by a node that receives and forwards packets in multiple flows.

[0125] The flow table 600 includes multiple entries. Each entry includes multiple fields. As Figure 6A shown, these fields include an entry number, a flow identifier, a count, a last packet time, and a path signature. In various implementations, an entry may include fewer or additional fields.

[0126] In some cases, the flow table 600 includes a fixed number of entries associated with a fixed number of flow identifiers. This fixed number can be an integer greater than 1. As Figure 6A shown, the flow table 600 includes ten entries (entry #1 - #10). The entries stored in the flow table 600 may correspond to the ten flows whose packets were most recently received and forwarded by the node. If more than ten flows include packets received and forwarded by the node, only the ten entries corresponding to the ten most recent flows may be stored in the flow table 600. Thus, the size of the flow table 600 can be limited to conserve memory resources at the node.

[0127] The flow identifier field of an entry corresponding to a packet can indicate the flow corresponding to that entry. In some cases, the flow identifier field may include at least one of the following: an ingress interface (e.g., SNMP ifIndex), a source (e.g., from the same IP address), a destination (e.g., pointing to the same IP address), a protocol (e.g., IP protocol), a source port (e.g., for UDP or TCP), a destination port (e.g., for UDP, TCP, or ICMP), or a type of service associated with the flow (e.g., IP type of service (ToS)). In certain implementations, the flow identifier field can be a string that can be used to identify the flow.

[0128] The count field of an entry corresponding to a flow can correspond to the number of packets that the node has received and / or forwarded in the flow. In some cases, the count field can correspond to the number of packets of the flow that are received and / or forwarded with a particular signature and the flow has not experienced a path change. For example, "Count 1" can correspond to the number of packets with "Flow Identifier 1" received by the node. In some cases, "Count 1" can correspond to the number of packets with "Signature 1" received since the start of the flow or the last path change of the flow.

[0129] The time field of an entry corresponding to a flow can indicate the time when the most recent packet of the flow was received by the node, the time when the most recent packet of the flow was forwarded by the node, or a combination thereof.

[0130] The path signature field of an entry corresponding to a flow can include a path signature generated by the node for the packets of the flow. In some cases, the path signature field can also include a previous path signature received by the node for the flow.

[0131] In a particular implementation, the path signature field can be used to identify whether the flow is associated with a path change. For example, in the Figure 6A example shown, the "Signature 1" corresponding to "Flow Identifier 1" can be set to "Signature A". When the node receives a packet corresponding to "Flow Identifier 1" that includes a signature different from "Signature A", the node can identify a path change in the flow with "Flow Identifier 1". Thus, the node can generate and send an alert corresponding to "Flow Identifier 1".

[0132] Figure 6B Illustrates an example of a flow table 602, in which a path change in a particular data flow is illustrated. For example, the flow table 602 can correspond to "Entry #1" in the flow table 600 described above with reference to Figure 6A description.

[0133] As shown, the flow table 602 can correspond to a single flow identifier, such as "Flow Identifier 1". The flow table 602 can track individual packets received and / or forwarded by the node in the flow corresponding to "Flow Identifier 1". In some cases, the flow table 602 can track a predetermined number of the most recent packets corresponding to "Flow Identifier 1", such as the most recent ten packets received and / or forwarded in the flow corresponding to "Flow Identifier 1".

[0134] Each individual packet can have its own timestamp (e.g., one of "Timestamp A" to "Timestamp J"). In some cases, a given timestamp can correspond to the time when the node received the individual packet and / or the time when the node forwarded the individual packet in the flow. Refer to Figure 6A"Timestamp 1" can be the most recent one among "Timestamp A" to "Timestamp J".

[0135] Flow table 602 can also track the path signature of individual packets. A given path signature in flow table 602 can correspond to the path signature in the received packet and / or the path signature in the packet forwarded by the node. For example, five packets in the flow corresponding to "Flow Identifier 1" can have a path signature of "Signature A", while five packets in the flow can have a path signature of "Signature B". Refer to Figure 6A "Signature 1" can be the most recent path signature observed in Flow Identifier 1 (e.g., "Signature A" or "Signature B").

[0136] Flow table 602 can be used to identify path changes in the flow corresponding to "Flow Identifier 1". Assuming that flow table 602 is arranged in chronological order, where "Timestamp J" is the most recent timestamp, a path change can be observed between "Timestamp E" and "Timestamp F", where the packets of the flow change from "Signature A" to "Signature B". Therefore, path changes in the flow can be efficiently identified.

[0137] Figure 7A and Figure 7B illustrates example processes 700 and 712 for updating the path signature of data packets. In some example implementations, process 700 and / or process 712 are performed by a network node, such as the first node 110 or network node 118 described above with reference to Figure 1 or any one of nodes A to D 204-A to 204-D described above with reference to Figures 2 - 5B Process 700 can be performed by a node that receives a data packet without an existing path signature. At 702, a packet is received. The packet may be part of a flow from a source to a destination through the network. In some cases, the received packet may omit the path signature.

[0138] At 704, a path signature is generated based on one or more node details. The one or more node details can include at least one of the identifier of the specific ingress port where the packet is received, the identifier of the egress port from which the packet will be forwarded, the identifier of the node that receives the packet, and so on. In various implementations, a hash function can be used to generate the path signature. For example, any one of the above formulas 1 to 3 or 5 to 7 can be used to generate the path signature. In some implementations, the path signature can have a limited size, such as 32 bits, 64 bits, or a similar size.

[0139]

[0140] ​At 706, a path signature is added to the packet. In some cases, the path signature is populated in a data field in the header of the packet (e.g., an IP header, IPv4 options, IPv6 extension headers, NSH header, Geneve header, VXLAN-GPE header, SRv6 header, or MPLS header) and / or in the payload (e.g., identified by EtherType). In some examples, the data field is included in at least one of the IOAM, INT, IFA, or IFIT metadata within the packet. The data field may have a fixed size corresponding to the length of the path signature.

[0141] At 708, the packet is forwarded together with the path signature. In various implementations, the packet is forwarded from a selected egress port. The egress port may be selected based on at least one of the destination of the packet, the load associated with the node affiliated with the egress port, the load associated with the node attached to another egress port, etc. For example, the header of the packet may indicate the destination of the packet, and the egress port may be selected to forward the packet in the direction of the destination. In some cases, a load balancing function may be used to select an egress port attached to at least one relatively uncongested node in the network.

[0142] At 710, the flow table is updated based on the path signature. In some cases, entries for the flow table may be generated to include at least one of the path signature and the identifier of the flow, the timestamp at which the packet was received, the timestamp at which the packet was forwarded, etc. In various examples, the path signature generated in process 700 may be the same path signature utilized in previous packets of the same flow. According to various implementations, an existing entry in the flow table corresponding to the path signature may be identified and updated at 710. For example, the entry may include at least one of a count corresponding to the number of packets of the flow with the path signature or a last packet time corresponding to the timestamp of the most recent packet with the path signature. The count and / or the last packet time may be updated based on the packets received, updated, and forwarded in process 700.

[0143] Although not illustrated in Figure 7A the entity that executes process 700 may additionally identify a path change of the flow based on the flow table. For example, a path change may be identified by adding a new entry corresponding to a new path signature that otherwise does not appear in the flow table. In some cases, the entity that executes process 700 may identify that more than a threshold number of packets with one or more path signatures in the flow have been received and / or forwarded, and thus may identify that a path change has occurred. In some cases, the entity may generate and send an alert identifying the path change.

[0144] Procedure 712 may be performed by a node that receives a data path with an existing path signature. At 714, a packet including a first path signature is received. The packet may be part of a flow from a source to a destination over a network. In some cases, the first path signature may have been generated and / or added to the packet by a previous node in the network.

[0145] At 716, a second path signature is generated based on the first path signature and one or more node details. The one or more node details may include at least one of an identifier of a specific ingress port at which the packet is received, an identifier of an egress port from which the packet will be forwarded, an identifier of the node that received the packet, and the like. In various implementations, a hash function may be used to generate the path signature. For example, any one of Formulas 8 to 10 above may be used to generate the path signature. In some implementations, the path signature may have a limited size, such as 32 bits, 64 bits, or a similar size. The second path signature may have the same size as the first path signature.

[0146] At 718, the first path signature in the packet is replaced with the second path signature. In some cases, the first path signature is deleted from a data field and / or payload (e.g., identified by EtherType) in a header field of the packet (e.g., an IP header, IPv4 options, IPv6 extension headers, NSH header, Geneve header, VXLAN-GPE header, SRv6 header, or MPLS header), and the second path signature is filled therein. In some examples, the data field is included in at least one of IOAM, INT, IFA, or IFIT metadata within the packet. The data field may have a fixed size corresponding to the length of the path signature.

[0147] At 720, the packet is forwarded together with the second path signature. In various implementations, the packet is forwarded from a selected egress port. The egress port may be selected based on at least one of the destination of the packet, the load associated with the node affiliated with the egress port, the load associated with the node attached to another egress port, and the like. For example, the header of the packet may indicate the destination of the packet, and the egress port may be selected to forward the packet in the direction of the destination. In some cases, a load balancing function may be used to select an egress port attached to at least one relatively uncongested node in the network.

[0148] At 722, the flow table is updated based on the first path signature and / or the second path signature. In some cases, entries for the flow table may be generated to include at least one of the first path signature and / or the second path signature and an identifier of the flow, a timestamp at which the packet was received, a timestamp at which the packet was forwarded, and so on. In various examples, the first path signature and / or the second path signature may be the same path signature utilized in a previous packet of the same flow. According to various implementations, existing entries in the flow table corresponding to the first path signature and / or the second path signature may be identified and updated at 722. For example, the entry may include at least one of a count corresponding to the number of packets of the flow with the first path signature and / or the second path signature or a last packet time corresponding to the timestamp of the most recent packet with the first path signature and / or the second path signature. The count and / or the last packet time may be updated based on the packets received, updated, and forwarded in process 712.

[0149] Although not illustrated in Figure 7B , the entity performing process 712 may additionally identify a path change of the flow based on the flow table. For example, a path change may be identified by adding a new entry to the flow table corresponding to a new path signature (e.g., the first path signature and / or the second path signature) that otherwise does not appear in the flow table. In some cases, the entity performing process 712 may identify that more than a threshold number of packets with one or more path signatures in the flow have been received and / or forwarded, and thus may identify that a path change has occurred. In some cases, the entity may generate and send an alert identifying the path change.

[0150] Figure 8 Example process 800 for sending an alert based on data packets with different path signatures is illustrated. In some example implementations, process 800 is performed by a network node, such as the first node 110 or network node 118 described above with reference to Figure 1 , or any one of nodes A through D 204-A through 204-D described above with reference to Figures 2 - 5B .

[0151] At 802, a first path signature of a first packet in the flow is identified. In some implementations, the first path signature is in the first packet received from a previous node in the network. In some cases, the first path signature is in the first packet forwarded to the next node in the network. According to a particular implementation, the first path signature may be generated by the device performing process 800.

[0152] At 804, a second path signature of a second packet in the flow is identified. In some cases, the second path signature may be from the same source as the first path signature. For example, if the first path signature is generated by the node executing process 800, the second path signature is also generated by the node executing process 800. In various implementations, the second path signature may have the same size as the first path signature. For example, the first and second path signatures may each have a size of 32 bits, 64 bits, or a similar size.

[0153] At 806, the first path signature is determined to be different from the second path signature. In some cases, the first path signature and the second path signature are stored in local memory, such as in a flow table. Thus, the first path signature and the second path signature can be compared even after one or both of the first and second packets have been forwarded to another node in the network. In some cases, the entity executing process 800 may additionally determine that the number of packets in the flow with the first path signature and / or the number of packets in the flow with the second path signature exceeds a predetermined threshold. In various implementations, the first path signature and the second path signature can be compared before the first and second packets are forwarded, at the time of forwarding, or immediately after forwarding.

[0154] At 808, an alert indicating the flow is sent to a collector. The collector can be a separate device that can receive other alerts from other nodes in the network. In various implementations, the alert can be a data packet that includes a flow indicator in the payload. The flow indicator may include at least one of at least one element of a 5-tuple associated with the flow, such as a source (e.g., from the same IP address), a destination (e.g., pointing to the same IP address), a protocol (e.g., IP protocol), a source port (e.g., for UDP or TCP), a destination port (e.g., for UDP, TCP, or ICMP), or the type of service of the first and second packets (e.g., IP type of service (ToS)). In some cases, the alert may also indicate the device executing process 800. For example, the alert may include a node identifier (e.g., an IP address) in the header or payload.

[0155] Figure 9 An example process 900 for reporting a problem to a central administrator based on a path change is illustrated. In some example implementations, process 900 is executed by a collector, such as collector 124 described above with reference to Figure 1 or collector 308 described above with reference to Figure 3

[0156] ​At 902, an alert is received from a node. The alert can indicate a path change in the network to which the node belongs. In various implementations, the alert can be a data packet that includes a flow indicator in the payload. The flow indicator can include at least one of at least one element of a 5-tuple associated with the flow, such as a source (e.g., from the same IP address), a destination (e.g., pointing to the same IP address), a protocol (e.g., IP protocol), a source port (e.g., for UDP or TCP), a destination port (e.g., for UDP, TCP, or ICMP), or the type of service of a first packet and a second packet (e.g., IP type of service (ToS)). In some cases, the alert can also indicate the node itself. For example, the alert can include a node identifier (e.g., an IP address) in the header or payload.

[0157] At 904, a problem associated with the node is identified. In some cases, another alert can be received from another node that is downstream of the node from which the alert was received at 902. The path change at the downstream node can be determined to originate from the node from which the alert was received at 902. In some cases, the problem can be a problem associated with the interface between the node and the downstream node. For example, the node can determine to forward a first packet in a flow to the downstream node, then determine that the interface has been interrupted, and then can determine to forward a second packet in the flow to a different node in the network. In some cases, the problem can be a problem associated with congestion in the network. For example, the node can determine to forward a first packet in a flow to the downstream node, can determine that the downstream node is congested, and then can decide to forward a second packet in the flow to a different downstream node.

[0158] At 906, the problem is reported to a central administrator. In some cases, the central administrator can initiate a process by which the problem can be resolved. In various implementations, the central administrator can be a device that can output an alert to a person or system that can resolve the problem. For example, the central administrator can dispatch a person to correct the problem in the network.

[0159] Figure 10 An example computer architecture of a server computer 1000 that can execute program components for implementing the functions described above is shown. Figure 10 The illustrated computer architecture diagram shows a traditional server computer, workstation, desktop computer, laptop computer, tablet device, network device, e-reader, smart phone, or other computing device and can be utilized to execute any software components presented herein. In some examples, the server computer 1000 can correspond to the network node 204 described herein.

[0160] Computer 1000 includes a substrate 1002, or "motherboard", which is a printed circuit board to which many components or devices can be connected by means of a system bus or other electrical communication paths. In an illustrative configuration, one or more central processing units ("CPU") 1004 operate in conjunction with a chipset 1006. The CPU 1004 can be a standard programmable processor that performs the arithmetic and logical operations necessary for the operation of computer 1000.

[0161] The CPU 1004 performs operations by transitioning from one discrete physical state to the next, where the state transitions are achieved by manipulation of switching elements that distinguish and change these states. The switching elements generally include electronic circuits that maintain one of two binary states, such as flip-flops, and electronic circuits that provide an output state based on a logical combination of the states of one or more other switching elements, such as logic gates. These basic switching elements can be combined to create more complex logic circuits, including registers, adders, subtractors, arithmetic logic units, floating-point units, and so on.

[0162] The chipset 1006 provides an interface between the CPU 1004 and the remaining components and devices on the substrate 1002. The chipset 1006 can provide an interface to the RAM 1008, which is used as the main memory in computer 1000. The chipset 1006 can further provide an interface to a computer-readable storage medium, such as a read-only memory ("ROM") 1010 or non-volatile RAM ("NVRAM"), for storing basic routines that assist in booting computer 1000 and transferring information between various components and devices. The ROM 1010 or NVRAM can also store other software components necessary for the operation of computer 1000 according to the configurations described herein.

[0163] Computer 1000 can operate in a networked environment, using a logical connection to remote computing devices and computer systems via a network (e.g., network 1008). The chipset 1006 can include functionality for providing network connectivity via a network interface controller (NIC) 1012 (such as a gigabit Ethernet adapter). The NIC 1012 is capable of connecting computer 1000 to other computing devices via network 1008. It should be understood that multiple NICs 1012 can be present in computer 1000, connecting the computer to other types of networks and remote computer systems. In some cases, the NIC 1012 can include at least one ingress port and / or at least one egress port.

[0164] The computer 1000 may be connected to a storage device 1018 that provides non-volatile storage for the computer. The storage device 1018 may store an operating system 1020, programs 1022, and data, which have been described in more detail herein. The storage device 1018 may be connected to the computer 1000 through a storage controller 1014 that is connected to the chipset 1006. The storage device 1018 may be composed of one or more physical storage units. The storage controller 1014 may interface with the physical storage units through a Serial Attached SCSI (SAS) interface, a Serial Advanced Technology Attachment (SATA) interface, a Fiber Channel (FC) interface, or other types of interfaces for physically connecting and transferring data between the computer and the physical storage units.

[0165] The computer 1000 may store data on the storage device 1018 by transforming the physical state of the physical storage units to reflect the information being stored. In different embodiments of the present specification, the specific transformation of the physical state may depend on various factors. Examples of such factors may include, but are not limited to, the technology used to implement the physical storage units, whether the storage device 1018 is characterized as primary storage or secondary storage, and so on.

[0166] For example, the computer 1000 may store information on the storage device 1018 by issuing instructions through the storage controller 1014 to change the magnetic characteristics of a specific location within a disk drive unit, the reflection or refraction characteristics of a specific location within an optical storage unit, or the electrical characteristics of a specific capacitor, transistor, or other discrete component within a solid-state storage unit. Other transformations of the physical medium are possible without departing from the scope and spirit of the present specification, and the foregoing examples are provided only for the convenience of the present specification. The computer 1000 may further read information from the storage device 1018 by detecting the physical state or characteristics of one or more specific locations within the physical storage units.

[0167] In addition to the above-described mass storage device 1018, computer 1000 can also access other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. Those skilled in the art should understand that computer-readable storage media are any available media that provide non-transitory storage of data and can be accessed by computer 1000. In some examples, operations performed by network nodes (e.g., network node 204), sources (e.g., 202), destinations (e.g., 206), collectors (e.g., 308), or central administrators (e.g., 312) can be supported by one or more devices similar to computer 1000. In other words, some or all of the operations performed by network nodes, collectors, and / or central administrators can be performed by one or more computer devices 1000 operating in a cloud-based arrangement.

[0168] By way of example, and not limitation, computer-readable storage media can include volatile and non-volatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media include, but are not limited to, RAM, ROM, erasable programmable ROM ("EPROM"), electrically-erasable programmable ROM ("EEPROM"), flash memory or other solid state memory technologies, compact disc ROM ("CD-ROM"), digital versatile disk ("DVD"), high definition DVD ("HD-DVD"), BLU-RAY or other optical storage devices, cassette tapes, magnetic tapes, disk storage devices or other magnetic storage devices, or any other medium that can be used to store the desired information in a non-transitory manner.

[0169] As briefly mentioned above, storage device 1018 can store operating system 1020 that is utilized to control the operation of computer 1000. According to one embodiment, the operating system includes the LINUX operating system. According to another embodiment, the operating system includes the SERVER operating system from MICROSOFT Corporation of Redmond, Washington. According to additional embodiments, the operating system can include the UNIX operating system or one of its variants. It should be understood that other operating systems can also be utilized. Storage device 1018 can store other systems or application programs and data utilized by computer 1000.

[0170] In one embodiment, the storage device 1018 or other computer-readable storage medium is encoded with computer-executable instructions that, when loaded into the computer 1000, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. As described above, these computer-executable instructions transform the computer 1000 by specifying how the CPU 1004 transitions between states. According to one embodiment, the computer 1000 is capable of accessing a computer-readable storage medium storing computer-executable instructions that, when executed by the computer 1000, perform the various processes described above with respect to Figures 1 - 9 the description. The computer 1000 may also include a computer-readable storage medium having instructions stored thereon for performing any other computer-implemented operations described herein.

[0171] As Figure 10 shown, the storage device 1018 stores a path signature updater 1024, a path change recognizer 1026, and a flow table 1028. In some implementations, at least one of the path signature updater 1024, the path change recognizer 1026, or the flow table 1028 may be omitted. Using the instructions stored in the path signature updater 1024, the (one or more) CPUs 1004 may be configured to generate and update path signatures for individual data packets in a data stream traversing the computer 1000. Using the instructions stored in the path change recognizer 1026, the (one or more) CPUs 1004 may be configured to identify whether a path change has occurred in the data stream by comparing the path signatures of different data packets within the data stream. The flow table 1026 may store one or more past path signatures associated with one or more data streams whose data packets are traversing the computer 1000.

[0172] The computer 1000 may also include one or more input / output controllers 1016 for receiving and processing inputs from a number of input devices such as a keyboard, mouse, touchpad, touch screen, electronic stylus, or other type of input device. Similarly, the input / output controller 1016 may provide outputs to a display such as a computer monitor, flat panel display, digital projector, printer, or other type of output device. It will be appreciated that the computer 1000 may not include all of the components Figure 10 shown, may include other components not explicitly shown Figure 10 herein, or may utilize an architecture completely different from that Figure 10 shown.

[0173] In summary, the present disclosure describes various methods, systems, and devices related to identifying path changes of data flows in a network. An example method includes receiving, at a node, a packet including a first path signature. The method further includes generating a second path signature by inputting the first path signature and one or more node details into a hash function. The method includes replacing the first path signature with the second path signature in the packet. The packet including the second path signature is forwarded by the node.

[0174] In some instances, one or more components herein may be referred to as “configured to,” “configurable to,” “operable / operable to,” “suitable for / suited to,” “capable of,” “adapted to,” etc. Those skilled in the art will recognize that, unless the context requires otherwise, such terms (e.g., “configured to”) generally can encompass active state components and / or inactive state components and / or standby state components.

[0175] As used herein, the term “based on” may be used synonymously with “at least partially based on” and “at least partially upon.”

[0176] As used herein, the terms “comprising” and “including” and their equivalents may be used interchangeably. An apparatus, system, or method “comprising A, B, and C” includes A, B, and C, but may also include other components (e.g., D). That is, the apparatus, system, or method is not limited to components A, B, and C.

[0177] Although the invention is described with respect to specific examples, it is to be understood that the scope of the invention is not limited to these specific examples. Since other modifications and variations are obvious to those skilled in the art for adapting to specific operating requirements and environments, the invention is not considered limited to the examples chosen for the purpose of disclosure and covers all variations and modifications that do not constitute a departure from the true spirit and scope of the invention.

[0178] Although this application describes embodiments having specific structural features and / or method acts, it is to be understood that the claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts merely illustrate some embodiments within the scope of the claims of this application.

Claims

1. A method for identifying path changes of data flows in a network, comprising: receiving, at a node, a packet including a first path signature, where the path signature represents the unique path that the packet has traversed; generating a second path signature by inputting the first path signature and an identifier of the node into a hash function; replacing the first path signature with the second path signature in the packet; and forwarding, by the node, the packet including the second path signature, where the packet is the first packet in a flow, and the method further comprises: receiving, at the node, a second packet in the flow, the second packet including a third path signature; generating a fourth path signature by inputting the third path signature and the identifier of the node into the hash function; identifying that the fourth path signature is different from the second path signature; and sending, in response to identifying that the fourth path signature is different from the second path signature, an alert identifying the node and the flow to a network administrator.

2. The method according to claim 1, wherein the packet including the first path signature is received at a specific ingress port of the node, and wherein generating the second path signature includes inputting an identifier of the specific ingress port into the hash function.

3. The method according to claim 1 or 2, wherein the packet including the second path signature is forwarded from a specific egress port of the node, and wherein generating the second path signature includes inputting an identifier of the specific egress port into the hash function.

4. The method according to claim 1, further comprising: selecting a specific egress port based on at least one of a destination of the packet, connectivity of the specific egress port, or a load associated with the specific egress port, wherein the packet including the second path signature is forwarded through the specific egress port.

5. The method according to claim 1, wherein the size of the first path signature is equal to the size of the second path signature.

6. The method according to claim 1, wherein each of the size of the first path signature and the size of the second path signature is 32 bits or 64 bits.

7. The method according to claim 1, wherein the first path signature is equal to the third path signature.

8. The method according to claim 1, wherein replacing the first path signature with the second path signature includes replacing the first path signature in a data field of a fixed size with the second path signature, the data field including at least one of the following: in-situ OAM IOAM field, in-network telemetry INT field, in-band flow analyzer IFA field, or in-situ flow information telemetry IFIT field.

9. A system for identifying path changes of data flows in a network, comprising: at least one processor; and a memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform operations, the operations including: Receive a packet including a first path signature at a node, where the path signature represents the unique path that the packet has traversed; Generate a second path signature by inputting the first path signature and the identifier of the node into a hash function; Replace the first path signature with the second path signature in the packet; and forward the packet including the second path signature by the node, where the packet is the first packet in a flow, and the operation further includes: Receive a second packet in the flow at the node, the second packet including a third path signature; Generate a fourth path signature by inputting the third path signature and the identifier of the node into the hash function; Identify that the fourth path signature is different from the second path signature; and In response to identifying that the fourth path signature is different from the second path signature, send an alert identifying the node and the flow to a network administrator.

10. The system according to claim 9, wherein, The packet including the first path signature is received at a specific ingress port of the node, and wherein generating the second path signature includes inputting the identifier of the specific ingress port into the hash function.

11. The system according to claim 9 or 10, wherein, The packet including the second path signature is forwarded from a specific egress port of the node, wherein generating the second path signature includes inputting the identifier of the specific egress port into the hash function.

12. The system according to claim 9, wherein, The operation further includes: Select a specific egress port based on at least one of the destination of the packet, the connectivity of the specific egress port, or the load associated with the specific egress port, wherein the packet including the second path signature is forwarded through the specific egress port.

13. The system according to claim 9, wherein, The size of the first path signature is equal to the size of the second path signature.

14. The system according to claim 9, wherein, Replacing the first path signature with the second path signature includes replacing the first path signature in a data field of a fixed size with the second path signature, the data field including at least one of the following: in-situ OAM IOAM field, in-network telemetry INT field, in-band flow analyzer IFA field, or in-situ flow information telemetry IFIT field.

15. A system for identifying path changes in a data flow in a network, comprising: A first node, including: A plurality of first ingress ports; A plurality of first egress ports; At least one first processor; and A first memory storing instructions that, when executed by the at least one first processor, cause the at least one first processor to perform operations, the operations including: Receive a packet in a flow at a specific ingress port among the plurality of first ingress ports; Identify the destination of the packet specified in the header of the packet; Identify a first path signature in the packet, where the path signature represents the unique path that the packet has traversed; Select a specific egress port among the plurality of first egress ports based on the destination; Generate a second path signature by inputting the first path signature, the identifier of the node, the identifier of the specific ingress port, and the identifier of the specific egress port into a hash function, wherein the size of the first path signature is equal to the size of the second path signature; Replace the first path signature with the second path signature in the packet; and Forward the packet with the second path signature through the specific egress port, wherein the packet is a first packet, and the operation further includes: Receiving a second packet including a third path signature; Identifying that the second packet is in the flow; Forwarding the second packet including a fourth path signature; Identifying that the third path signature is different from the first path signature or the fourth path signature is different from the second path signature; and In response to determining that the third path signature is different from the first path signature or the fourth path signature is different from the second path signature, sending an alert including at least one identifier of the flow to a collector.

16. The system according to claim 15, wherein the alert is a first alert, and wherein the system further includes: The collector, including: At least one second processor; and A second memory storing instructions that, when executed by the at least one second processor, cause the at least one second processor to perform operations, the operations including: Receiving the first alert from the first node; Receiving a second alert including at least one identifier of the flow from a second node downstream of the first node; Diagnosing a problem in the network associated with the first node based on the alert; and Sending a report of the problem to a network administrator.

17. The system according to claim 15, further includes: A network including a first layer, a second layer, and a third layer, the first layer including the first node, the second layer including a plurality of second nodes connected to the first node, and the third layer including a plurality of third nodes connected to the plurality of second nodes, wherein the packet with the second path signature is forwarded by the first node to a specific second node among the plurality of second nodes, wherein the specific second node forwards the packet with the second path signature to a specific third node among the plurality of third nodes, and wherein the specific third node generates a third path signature in response to receiving the packet with the second path signature and forwards the packet with the third path signature.

18. An apparatus for identifying a path change of a data flow in a network, including: Means for receiving, at a node, a packet including a first path signature, wherein the path signature represents a unique path that the packet has traversed; Means for generating a second path signature by inputting the first path signature and the identifier of the node into a hash function; Means for replacing the first path signature with the second path signature in the packet; and Apparatus for forwarding, by the node, the packet including the second path signature, wherein the packet is the first packet in a flow, and the apparatus further comprises: apparatus for receiving, at the node, a second packet in the flow, the second packet including a third path signature; apparatus for generating a fourth path signature by inputting the third path signature and an identifier of the node into the hash function; apparatus for identifying that the fourth path signature is different from the second path signature; and apparatus for sending, in response to identifying that the fourth path signature is different from the second path signature, an alert identifying the node and the flow to a network manager.

19. The apparatus according to claim 18, further comprising apparatus for implementing the method according to any one of claims 2 to 8.

20. A computer program product or a computer-readable medium, comprising instructions which, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 1 to 8.

Images