In-line detection method and device, electronic equipment and storage medium

Abstract

This application relates to the field of computer network communication technology, and provides a flow-following detection method, apparatus, electronic device, and storage medium. When a service flow arrives for the first time, the source node determines the flow identifier assigned to the service flow, generates a multicast address based on the flow identifier, and joins the multicast group corresponding to the multicast address. Then, it performs flow-following detection on the service flow, generates local IFIT measurement data, and sends it to the multicast group. Simultaneously, it receives IFIT measurement data sent by other nodes in the multicast group and executes local traffic engineering policies based on the local IFIT measurement data and the IFIT measurement data sent by other nodes. In this way, each node can directly obtain the IFIT measurement data of other nodes through the multicast group, and can execute local traffic engineering policies after receiving the IFIT measurement data from other nodes' devices, thereby achieving flow-following detection that simultaneously considers low overhead, low latency, and inter-node collaboration.

Description

Technical Field

[0001] This application relates to the field of computer network communication technology, and more specifically, to a method, apparatus, electronic device, and storage medium for flow detection. Background Technology

[0002] In high-performance network scenarios such as 5G bearer networks and data center interconnects, to achieve intelligent traffic engineering, it is necessary to obtain the accurate performance status (such as latency, packet loss, jitter, etc.) of the end-to-end path of the service flow in real time. Figure 1 As shown, the service flow passes through the source node, intermediate forwarding node and destination node in sequence to form an end-to-end data transmission path, and is measured using IFIT (In-situ Flow Information Telemetry).

[0003] However, existing IFIT schemes mainly include two models, both of which have significant shortcomings: I. Local Analysis Model: Measurement data is processed locally at each intermediate forwarding node. The source node cannot know the measurement results of the downstream nodes, which means that network adjustment decisions can only be limited to a single node and cannot achieve end-to-end collaborative optimization.

[0004] II. Controller Model: Each node needs to report massive amounts of measurement data to a centralized controller via protocols such as Telemetry. The controller then aggregates and analyzes the data before distributing strategies to each node. This approach introduces additional communication latency and processing overhead, increasing the control plane load.

[0005] Currently, there is no IFIT solution that can simultaneously meet the three major requirements of low overhead, low latency, and inter-node collaboration. Summary of the Invention

[0006] The purpose of this application is to provide a method, apparatus, electronic device, and storage medium for in-flow detection, so as to improve the above-mentioned problems.

[0007] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: In a first aspect, embodiments of this application provide a flow detection method applied to a source node, the method comprising: When a service flow arrives for the first time, its flow identifier is determined. A multicast address is generated based on the stream identifier, and the multicast address is added to the multicast group corresponding to the multicast address. Perform flow-following detection on the service flow to generate local flow-following detection IFIT measurement data, and send the local IFIT measurement data to the multicast group; Receive IFIT measurement data sent by other nodes in the multicast group; Based on the local IFIT measurement data and the received IFIT measurement data from other nodes, a local traffic engineering policy is executed.

[0008] Optionally, the step of determining the flow identifier of the service flow when it first arrives includes: An instance identifier is generated when the business flow arrives for the first time; The instance identifier is concatenated with the device identifier of the source node to obtain the flow identifier of the service flow.

[0009] Optionally, the flow identifier includes an instance identifier and the device identifier of the source node; The step of generating a multicast address based on the stream identifier and adding it to the multicast group corresponding to the multicast address includes: Extract the instance identifier and the device identifier of the source node from the flow identifier; The device identifier of the source node is hashed to obtain a hash value; Take the bit value at a preset position in the hash value and concatenate it with the instance identifier and the preset multicast prefix to obtain the multicast address; Send a join message to the multicast address to join the multicast group corresponding to the multicast address.

[0010] Optionally, the step of executing a local traffic engineering strategy based on the local IFIT measurement data and the received IFIT measurement data from the other nodes includes: Based on the local IFIT measurement data and the IFIT measurement data of other nodes, calculate the network quality parameters between any two nodes on the IFIT flow detection path; Based on the network quality parameters between any two nodes, execute a local traffic engineering strategy.

[0011] Optionally, the method further includes: Delete the local IFIT instance when the instance deletion conditions are met; After confirming that the local IFIT instance has been deleted, exit the multicast group.

[0012] Secondly, embodiments of this application provide a flow detection method, applied to intermediate forwarding nodes or destination nodes, the method comprising: Upon receiving a service flow, extract the flow identifier of the service flow; A multicast address is generated based on the stream identifier, and the multicast address is added to the multicast group corresponding to the multicast address. Perform flow-following detection on the service flow to generate local IFIT measurement data, and send the local IFIT measurement data to the multicast group; Receive IFIT measurement data sent by other nodes in the multicast group; Based on the local IFIT measurement data and the received IFIT measurement data from other nodes, a local traffic engineering policy is executed.

[0013] Thirdly, embodiments of this application provide a flow detection device applied to a source node, the device comprising: The flow identifier allocation module is used to determine the flow identifier of the service flow when the service flow arrives for the first time; The first execution module is configured to generate a multicast address based on the flow identifier and join the multicast group corresponding to the multicast address; perform flow-following detection on the service flow to generate local flow-following detection IFIT measurement data and send the local IFIT measurement data to the multicast group; receive IFIT measurement data sent by other nodes in the multicast group; and execute a local traffic engineering policy based on the local IFIT measurement data and the received IFIT measurement data from the other nodes.

[0014] Fourthly, embodiments of this application provide a flow detection device applied to an intermediate forwarding node or a destination node, the device comprising: The flow identifier extraction module is used to extract the flow identifier of the service flow when a service flow is received; The second execution module is configured to generate a multicast address based on the flow identifier and join the multicast group corresponding to the multicast address; perform flow-following detection on the service flow to generate local IFIT measurement data and send the local IFIT measurement data to the multicast group; receive IFIT measurement data sent by other nodes in the multicast group; and execute a local traffic engineering policy based on the local IFIT measurement data and the received IFIT measurement data from the other nodes.

[0015] Fifthly, embodiments of this application provide an electronic device, including a processor and a memory, wherein the memory is used to store a program, and the processor is used to implement the following detection method in the first aspect above, or the following detection method in the second aspect above, when executing the program.

[0016] In a sixth aspect, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the flow detection method in the first aspect above, or the flow detection method in the second aspect above.

[0017] Compared to existing technologies, the following application provides a flow-following detection method, apparatus, electronic device, and storage medium. When a service flow arrives for the first time, the source node determines the flow identifier of the service flow, generates a multicast address based on the flow identifier, joins the multicast group corresponding to the multicast address, and then performs flow-following detection on the service flow to generate local IFIT measurement data, which is then sent to the multicast group. Simultaneously, it receives IFIT measurement data sent by other nodes in the multicast group and executes local traffic engineering policies based on the local IFIT measurement data and the IFIT measurement data sent by other nodes. In this way, on the one hand, each node can directly obtain the IFIT measurement data of other nodes through the multicast group, so that network adjustment decisions are no longer limited to a single node, solving the problem of incoordination between nodes in the local analysis model; on the other hand, all nodes do not need to report IFIT measurement data to the controller, nor do they need to wait for the controller to summarize and analyze the data before issuing policies. They can execute local traffic engineering policies immediately after receiving the IFIT measurement data from other node devices, avoiding communication round-trip delays and centralized computing overhead, solving the problems of high latency and high overhead in the controller model. Therefore, it can achieve flow-following detection that simultaneously achieves low overhead, low latency, and inter-node coordination. Attached Figure Description

[0018] Figure 1 The illustration shows an application scenario provided by an embodiment of this application. Figure 1 .

[0019] Figure 2 The illustration shows an application scenario provided by an embodiment of this application. Figure 2 .

[0020] Figure 3 The diagram shows a flow chart of a method for detecting sources in a source node, provided in an embodiment of this application.

[0021] Figure 4 The diagram shows a flow-following detection method for intermediate forwarding nodes or destination nodes provided in an embodiment of this application.

[0022] Figure 5 The diagram shows a block diagram of a flow detection device applied to a source node according to an embodiment of this application.

[0023] Figure 6 The diagram shows a block diagram of a flow detection device applied to an intermediate forwarding node or a destination node, according to an embodiment of this application.

[0024] Figure 7 A block diagram of an electronic device provided in an embodiment of this application is shown.

[0025] Icons: 100, 200 - Flow detection device; 101 - Flow identifier allocation module; 102 - First execution module; 201 - Flow identifier extraction module; 202 - Second execution module; 10 - Electronic device; 11 - Processor; 12 - Memory; 13 - Communication module. Detailed Implementation

[0026] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0027] Please refer to Figure 2 , Figure 2 A schematic diagram of an application scenario is shown, including a source node, intermediate forwarding nodes, a destination node, a multicast forwarding device, a source host, and a destination host.

[0028] It should be noted that the number and location of intermediate forwarding nodes in the diagram are merely examples. Those skilled in the art will understand that in a real network, an end-to-end forwarding path may contain one or more intermediate forwarding nodes, specifically determined by the path dynamically generated by the network control plane, and the intermediate forwarding nodes included in different forwarding paths are usually different.

[0029] The source host can be the CE1 device (Customer Edge) that receives data, used to initiate service flows. Service flows can be ordinary IPv4 / IPv6 flows.

[0030] The source node can be the ingress PE device (Provider Edge) of an SRv6 (Segment Routing over IPv6) path, denoted as R1. At the source node, an SRv6 tunnel marker and an IFIT detection marker are added to the service flow. The source node is also used to determine a unique flow identifier for each new service flow and, according to preset fixed conversion rules, convert the flow identifier into a multicast address (e.g., 228.xxx.xxx.xxx). Subsequently, the source node sends a join message to the multicast forwarding device through the management interface or other interfaces capable of node communication to join the multicast group corresponding to the multicast address. Simultaneously, the source node is also used to collect local IFIT measurement data (e.g., one-way latency, packet loss rate, jitter, etc. from R1 to the next-hop node R2) and send it to the multicast group. It also receives IFIT measurement data from other members within the multicast group and executes local traffic engineering policies (e.g., path switching, flow control, bandwidth adjustment, etc.) based on the received data and its own measurement results.

[0031] Intermediate forwarding nodes can be P-devices (Providers, core operator devices) in the SRv6 path, denoted as R2. The intermediate forwarding node extracts the flow identifier of the service flow, reuses the same fixed conversion rules as the source node, independently calculates a multicast address completely identical to the source node, and then sends a grouping message through the management interface or other interfaces capable of node communication to join the multicast group corresponding to the multicast address. Simultaneously, the intermediate forwarding node also collects local IFIT measurement data (such as one-way latency, packet loss rate, jitter, etc. from R2 to the next-hop node R3) and sends it to the multicast group. It also receives IFIT measurement data from other members within the multicast group and executes local traffic engineering policies (such as local link diagnosis, cooperative policy response, etc.) based on the received data and its own measurement results.

[0032] The destination node can be the egress PE device of the SRv6 path, denoted as R3. The destination node is also used to extract the flow identifier of the service flow, calculate the same multicast address according to preset fixed conversion rules, and join the multicast group by sending a join message through the management interface or other interfaces capable of node communication. Simultaneously, the destination node is also used to collect local IFIT measurement data (such as one-way latency, packet loss rate, jitter, etc. from R3 to the destination host) and send it to the multicast group, receive IFIT measurement data from other members in the multicast group, and execute local traffic engineering strategies (such as sensing upstream link status, reverse collaborative feedback, etc.) based on the received data and its own measurement results.

[0033] Multicast forwarding devices can be network devices that support Layer 3 multicast forwarding capabilities, including but not limited to routers and Layer 3 switches. Multicast forwarding devices are used to receive grouping messages from nodes such as R1, R2, and R3, dynamically build and maintain multicast forwarding table entries, and ensure that IFIT measurement messages sent by each node to the multicast address can be accurately forwarded to members within the multicast group.

[0034] The destination host can be a CE2 device (Customer Edge) used to receive service streams. The destination host does not participate in the multicast feedback process, and the performance metrics of the link from R3 to the destination host are measured by R3.

[0035] In a practical scenario, source host CE1 initiates a service flow to destination host CE2. This service flow is forwarded hop-by-hop through the SRv6 path R1, R2, and R3. Each node along the way performs IFIT measurements synchronously. At the same time, R1, R2, and R3 independently generate unique multicast addresses based on the same flow identifier and join the corresponding multicast group. Then, R1, R2, and R3 encapsulate their respective measured IFIT measurement data (such as one-way latency from R1 to R2, packet loss rate from R2 to R3, jitter value from R3 to CE2, etc.) into UDP (User Datagram Protocol) packets, with the multicast address as the destination address, and send them through their respective management interfaces or other interfaces that enable node communication. The multicast forwarding device accurately distributes the packets to the members within the multicast group according to the multicast group membership table. In this way, R1 can receive and parse IFIT measurement data from R2 and R3 locally in real time, analyze the health status of the end-to-end path by combining its own local IFIT measurement data, and perform local traffic engineering decisions (such as path switching, traffic control, bandwidth adjustment, etc.) when it determines that there are degraded link segments. The whole process does not require the intervention of the controller, nor does it require point-to-point signaling negotiation between nodes, thus achieving flow detection that can simultaneously take into account low overhead, low latency and inter-node collaboration.

[0036] The following is a detailed description of the in-flow detection method provided in the embodiments of this application.

[0037] Please refer to Figure 3 , Figure 3 This illustration shows a flowchart of a flow-in-flow detection method provided in an embodiment of this application. This flow-in-flow detection method is applied to… Figure 2 The source node in the data may include the following steps: S101, when the service flow arrives for the first time, determine the flow identifier of the service flow; S102, Generate a multicast address based on the stream identifier and add it to the multicast group corresponding to the multicast address; S103, perform flow-following detection on the service flow to generate local flow-following detection IFIT measurement data, and send the local IFIT measurement data to the multicast group; S104, Receive IFIT measurement data sent by other nodes in the multicast group; S105 executes local traffic engineering policies based on local IFIT measurement data and received IFIT measurement data from other nodes.

[0038] In this embodiment, when a service flow arrives for the first time, the source node determines the flow identifier (Flow-ID) of the service flow. The flow identifier is a unique identifier for the service flow. Optionally, the flow identifier is 40 bits long and is composed of the source node's device identifier (Device-ID) and a randomly generated instance identifier (Instance-ID). The device identifier is a 20-bit unique number pre-configured by the source node, and the instance identifier is a 20-bit sequence number generated by the source node when the service flow arrives for the first time.

[0039] The source node then generates a multicast address (such as 228.xxx or ff05:: / 64) based on the flow identifier and joins the multicast group corresponding to the multicast address. The multicast address is a unique address dynamically generated using preset fixed conversion rules, and all nodes participating in the IFIT measurement can independently generate completely identical multicast addresses once they obtain this flow identifier.

[0040] Optionally, the input to the fixed conversion rule is a 40-bit stream identifier. The processing includes: first, splitting the stream identifier into a high 20-bit (device identifier) ​​and a low 20-bit (instance identifier); then taking all 20 bits of the device identifier and the lowest 4 bits of the hash value of the instance identifier; then concatenating the above 20 bits and 4 bits into 24 bits, which are used as the last 24 bits of the IPv4 multicast address 228.0.0.0 / 8. That is, taking 20 bits of the device identifier and the lowest 4 bits of the hash value of the instance identifier to form 24 bits, and adding the fixed multicast prefix to form a 32-bit multicast address, and finally outputting a multicast address in the format 228.XXX.XXX.XXX.

[0041] Based on this, the source node performs flow-following detection on the service flow, generates local IFIT measurement data (such as latency and packet loss), encapsulates the local IFIT measurement data into UDP packets, and sends them to the multicast group with the multicast address as the destination address. Simultaneously, the source node continuously listens to the multicast address, receiving IFIT measurement data sent by other nodes in the multicast group, including intermediate forwarding nodes and the destination node. Upon receiving a service flow carrying a flow identifier, the intermediate forwarding nodes and the destination node dynamically create instances based on the IFIT header, and generate the same multicast address according to fixed conversion rules based on the flow identifier. They then send a join message to join the multicast group corresponding to the multicast address, and encapsulate their respective measured local IFIT measurement data into UDP packets and send them to that multicast address.

[0042] Finally, the source node executes local traffic engineering policies based on its own local IFIT measurement data and the IFIT measurement data received from other nodes. Therefore, it does not need to request instructions from the controller or establish point-to-point connections with other nodes. It can identify link segments with degraded performance and trigger path switching or traffic control actions based solely on the aggregated full-path IFIT measurement data.

[0043] It should be noted that the flow identifier is created by the source node when the service flow first arrives, and its existence period is strictly bound to the lifecycle of the service flow. The generation of multicast addresses is deterministic, that is, the same flow identifier will always generate the same multicast address, and it will not change due to node type, deployment location, or runtime. At the same time, joining a multicast group is initiated by the node and is only directed to the management plane interface, without affecting the forwarding plane of service packets.

[0044] In one possible implementation, the process of determining the flow identifier of the service flow when the service flow first arrives in step S101 may include: S1011, when the business flow arrives for the first time, an instance identifier is generated; S1012, concatenate the instance identifier with the device identifier of the source node to obtain the flow identifier of the service flow; S1013 encapsulates the flow identifier into the header of the service flow message and forwards it.

[0045] In this embodiment, when a service flow first arrives at the source node, the source node first generates a 20-bit instance identifier to distinguish different service flows initiated concurrently on the same source node and avoid identifier conflicts. Then, the source node concatenates its own pre-configured 20-bit device identifier with the instance identifier to obtain a flow identifier with a total length of 40 bits.

[0046] Optionally, the device identifier is pre-configured for each node to uniquely identify the corresponding node. For example, the device identifier for R1 is 74565 (corresponding to hexadecimal 0x12345), the device identifier for R2 is 144470 (corresponding to hexadecimal 0x23456), and the device identifier for R3 is 214375 (corresponding to hexadecimal 0x34567). The instance identifier is generated by the source node each time a new service flow arrives, for example, 11259375 (corresponding to hexadecimal 0xABCDEF).

[0047] For example, suppose CE1 initiates a new service flow to CE2. R1, as the entry PE, creates an IFIT instance. At the same time, R1's system assigns a 20-bit instance identifier to the IFIT instance, for example, 11259375 (corresponding to hexadecimal 0xABCDEF). R1 ​​concatenates its own device identifier (74565) and instance identifier (11259375) into a 40-bit flow identifier.

[0048] After the source node generates a 40-bit flow identifier, it encapsulates the flow identifier into the header field of the first packet of the service flow and forwards it normally to the downstream of the network, so that the flow identifier can be identified and extracted by all intermediate forwarding nodes and destination nodes participating in the detection along the path.

[0049] As described above, the flow identifier includes an instance identifier and a source node's device identifier. In one possible implementation, step S102, which generates a multicast address based on the flow identifier and joins the multicast group corresponding to the multicast address, may include: S1021, Extract the instance identifier and the source node's device identifier from the flow identifier; S1022, perform a hash calculation on the device identifier of the source node to obtain the hash value; S1023, take the bit value at the preset position in the hash value, and concatenate it with the instance identifier and the preset multicast prefix to obtain the multicast address; S1024, send a join message to the multicast address to join the multicast group corresponding to the multicast address.

[0050] In this embodiment, the flow identifier is a 40-bit binary sequence, where the high 20 bits correspond to the device identifier of the source node, and the low 20 bits correspond to the instance identifier of the service flow. The device identifier is a globally unique management address code pre-configured in the IFIT system for the source node. For example, the device identifier of R1 is 74565 (corresponding to hexadecimal 0x12345), and its binary representation is 00010010001101000101. The instance identifier is a 20-bit value generated by the source node when the service flow first arrives, for example, 11259375 (corresponding to hexadecimal 0xABCDEF).

[0051] In practical applications, after the source node determines the flow identifier for the first arriving service flow, it extracts the high 20 bits from the 40-bit flow identifier as the device identifier and the low 20 bits as the instance identifier. Then, it performs a hash calculation on the extracted instance identifier (e.g., 0xABCDEF) to obtain a hash value. Hash calculation follows a deterministic rule; the same instance identifier input always produces the same hash value output. For example, after performing a hash calculation on 0xABCDEF, the hash value is assumed to be 0x5A3C. Next, the low 4 bits of the resulting hash value, i.e., 0xC (corresponding to binary 1100), are taken.

[0052] Next, the binary sequence of the 20-bit device identifier is concatenated with the 4-bit value obtained in the previous step to form a continuous 24-bit field, for example, 00010010001101000101 1100, which corresponds to hexadecimal 0x1234C.

[0053] Finally, this 24-bit field is used as the last 24 bits of the IPv4 address 228.0.0.0 to obtain the complete 32-bit multicast address, for example, 228.18.52.76. That is, multicast address = 228.0.0.0 + 0x1234C = 228.18.52.76. The source node then sends a join message to the multicast address 228.18.52.76 to join the multicast group corresponding to that multicast address.

[0054] In other words, using the structural information carried by the flow identifier itself as the only input, the flow identifier is split into a high 20-bit device identifier and a low 20-bit instance identifier through a preset fixed conversion rule. After performing a hash operation on the instance identifier, its lowest 4 bits are extracted and concatenated with the entire 20-bit device identifier to form a 24-bit field. This 24-bit field is then used as the last 24 bits to fill the fixed multicast prefix 228.0.0.0 to generate the final multicast address. This converts the 40-bit flow identifier into a standard 32-bit IPv4 multicast address, ensuring that the source node, intermediate forwarding node, and destination node can generate the exact same multicast address and join the same multicast group when they are processing the same service flow independently.

[0055] In one possible implementation, the process of executing a local traffic engineering strategy based on local IFIT measurement data and received IFIT measurement data from other nodes in step S105 may include: S1051, Calculate the network quality parameters between any two nodes on the IFIT flow detection path based on the local IFIT measurement data and the IFIT measurement data of other nodes. S1052 executes local traffic engineering policies based on network quality parameters between any two nodes. These local traffic engineering policies include path switching, traffic control, and bandwidth adjustment.

[0056] In this embodiment, the source node first performs flow detection on the next-hop node it is connected to, and generates local IFIT measurement data. For example, R1 measures the one-way delay from itself to R2 as 1ms. At the same time, the source node receives the one-way delay (e.g., 50ms) of the link segment from R2 to R3 and the one-way delay (e.g., 2ms) of the link segment from R3 to CE2 by joining the multicast group corresponding to the multicast address (e.g., 228.18.52.76).

[0057] Subsequently, the source node calculates the network quality parameters between any two nodes on the IFIT flow detection path based on the aforementioned local IFIT measurement data and the IFIT measurement data received from other nodes. For example, the latency of the R1 to R2 segment, the R2 to R3 segment, and the R1 to R3 segment. Then, it executes a traffic engineering strategy locally based on the network quality parameters between any two nodes.

[0058] For example, referring to the above example, since the one-way latency from R2 to R3 is as high as 50ms, far exceeding the one-way latency of the preceding and following link segments (1ms from R1 to R2 and 2ms from R3 to CE2), it can be reasonably inferred that there is performance degradation in the link segment between R2 and R3, thus immediately triggering a local traffic engineering strategy. Local traffic engineering strategies can include, but are not limited to, path switching, flow control, and bandwidth adjustment. Path switching can involve switching subsequent traffic flows destined for the same address from the primary path of the currently degraded link segment (such as R2 to R3) to another pre-configured backup path. Flow control can temporarily reduce the forwarding rate of traffic flows towards the degraded link segment to alleviate congestion. Bandwidth adjustment can dynamically reallocate bandwidth quotas for traffic flows on available paths, prioritizing the transmission quality of critical services.

[0059] Please refer to this again. Figure 3 After step S105, the flow detection method provided in this application embodiment further includes steps S106 to S108.

[0060] S106. When the set conditions are detected, delete the local IFIT instance; S107. After confirming the deletion of the local IFIT instance, exit the multicast group.

[0061] In this embodiment, when the source node detects that the set conditions are met, it first performs a local cleanup action, deleting the local IFIT instance bound to the service flow. The local IFIT instance is an IFIT running unit created and maintained separately by the source node for this service flow, carrying the flow identifier, measurement configuration, and temporary status information. Optionally, the set conditions may include, but are not limited to, no service flow detected for a consecutive set number (e.g., 3) measurement cycles (e.g., 100ms), no traffic after timeout, detection of user manually deleting the local IFIT instance, detection of user manually stopping IFIT measurement, etc.

[0062] Then, after confirming the deletion of the local IFIT instance, the source node leaves the multicast group. Before leaving the multicast group, it can send an IGMP (Internet Group Management Protocol) leave message to the multicast address 228.18.52.76. The IGMP leave message is a standard message sent by the node to the multicast forwarding device to explicitly declare that it will no longer receive data sent to the specified multicast address.

[0063] Please refer to Figure 4 , Figure 4 This illustration shows a flowchart of a flow-in-flow detection method provided in an embodiment of this application. This flow-in-flow detection method is applied to… Figure 2The intermediate forwarding node or destination node in the process may include the following steps: S201, Upon receiving a service flow, extract the flow identifier of the service flow; S202, Generate a multicast address based on the stream identifier and add it to the multicast group corresponding to the multicast address; S203, perform flow-following detection on the service flow to generate local IFIT measurement data, and send the local IFIT measurement data to the multicast group; S204, Receive IFIT measurement data sent by other nodes in the multicast group; S205 executes local traffic engineering policies based on local IFIT measurement data and received IFIT measurement data from other nodes.

[0064] In this embodiment, when an intermediate forwarding node or a destination node (such as R2 or R3) receives a service flow carrying a flow identifier, it first dynamically creates a local IFIT instance based on the flow identifier. This instance is a detection and operation unit temporarily established by the node for this service flow, used to carry subsequent measurement configuration and status recording.

[0065] Then, the flow identifier is extracted from the header of the service flow, and a multicast address is generated based on the flow identifier using the same fixed conversion rules as the source node. For example, the flow identifier is a 40-bit binary sequence consisting of a 20-bit device identifier and a 20-bit instance identifier. The node performs a hash calculation on the device identifier, truncates the lowest 4 bits, and then concatenates it with the instance identifier and a fixed multicast prefix (such as 228) to obtain the multicast address (such as 228.18.52.76). Next, the node sends a join message to the multicast address to join the multicast group corresponding to the multicast address.

[0066] During this process, the node synchronously performs flow-following detection on the service flow, generates local IFIT measurement data reflecting the quality of this link segment (such as one-way latency, packet loss rate, etc.), and encapsulates it into UDP packets before sending them to the aforementioned multicast address. At the same time, the node continuously receives IFIT measurement data sent from other members of the multicast group (including source node R1, other intermediate forwarding nodes R2, or destination node R3).

[0067] Finally, based on its own locally measured IFIT data and the IFIT data received from other nodes, the node executes local traffic engineering policies. These policies include path switching, flow control, and bandwidth adjustment, enabling it to detect and respond to network anomalies locally.

[0068] Please refer to Figure 4 After step S205, the flow detection method provided in this application embodiment further includes steps S206 to S207.

[0069] S206. When the service flow termination condition is met, delete the local IFIT instance. S207. After confirming the deletion of the local IFIT instance, exit the multicast group.

[0070] It should be noted that the ungrouping process in steps S206 to S207 is similar to that in steps S106 to S107, and will not be described again here.

[0071] Compared with the prior art, the in-flow detection method provided in this application has the following advantages: Each node can directly obtain IFIT measurement data from other nodes through multicast groups, enabling network regulation decisions to no longer be limited to a single node. This solves the problem of incoordination between nodes in the local analysis model. At the same time, all nodes do not need to report IFIT measurement data to the controller or wait for the controller to summarize and analyze the data before issuing policies. They can execute local traffic engineering policies as soon as they receive IFIT measurement data from other nodes, avoiding communication round-trip delays and centralized computing overhead. This solves the problems of high latency and high overhead in the controller model, thus achieving flow detection that simultaneously achieves low overhead, low latency, and inter-node coordination. Furthermore, it can be widely used in existing SRv6 network deployments, simplifying the dependence on the controller in the topology network.

[0072] In order to perform the corresponding steps in the above method embodiments and various possible implementations, the following provides an implementation of a flow detection device 100 applied to a source node and a flow detection device 200 applied to an intermediate forwarding node or a destination node.

[0073] Please refer to Figure 5 , Figure 5 A block diagram of a flow-in-the-flow detection device 100 provided in an embodiment of this application is shown. The flow-in-the-flow detection device 100 is applied to... Figure 1 The source node in the process includes: a stream identifier allocation module 101 and a first execution module 102.

[0074] The flow identifier allocation module 101 is used to determine the flow identifier of the service flow when the service flow arrives for the first time.

[0075] The first execution module 102 is used to generate a multicast address based on the flow identifier and add it to the multicast group corresponding to the multicast address; perform flow-following detection on the service flow to generate local flow-following detection IFIT measurement data and send the local IFIT measurement data to the multicast group; receive IFIT measurement data sent by other nodes in the multicast group; and execute local traffic engineering policies based on the local IFIT measurement data and the received IFIT measurement data from other nodes.

[0076] Optionally, the flow identifier allocation module 101 is specifically used to: generate an instance identifier when the service flow arrives for the first time; and concatenate the instance identifier with the device identifier of the source node to obtain the flow identifier of the service flow.

[0077] Optionally, the flow identifier includes an instance identifier and a device identifier of the source node; the first execution module 102 executes a method of generating a multicast address based on the flow identifier and joining the multicast group corresponding to the multicast address, including: extracting the instance identifier and the device identifier of the source node from the flow identifier; performing a hash calculation on the device identifier of the source node to obtain a hash value; taking the bit value at a preset position in the hash value and concatenating it with the instance identifier and a preset multicast prefix to obtain a multicast address; and sending a join message to the multicast address to join the multicast group corresponding to the multicast address.

[0078] Optionally, the first execution module 102 executes a local traffic engineering strategy based on local IFIT measurement data and received IFIT measurement data from other nodes. This includes: calculating network quality parameters between any two nodes on the IFIT flow detection path based on the local IFIT measurement data and the IFIT measurement data from other nodes; and executing the local traffic engineering strategy based on the network quality parameters between the two nodes. The local traffic engineering strategy includes path switching, traffic control, and bandwidth adjustment.

[0079] Optionally, the first execution module 102 is further configured to: delete the local IFIT instance when a set condition is detected; and exit the multicast group after confirming that the local IFIT instance has been deleted.

[0080] Please refer to Figure 6 , Figure 6 A block diagram of a flow-in-the-flow detection device 200 provided in an embodiment of this application is shown. The flow-in-the-flow detection device 200 is applied to... Figure 1 The intermediate forwarding node or destination node in the process includes: a flow identifier extraction module 201 and a second execution module 202.

[0081] The flow identifier extraction module 201 is used to extract the flow identifier of the service flow when a service flow is received.

[0082] The second execution module 202 is used to generate a multicast address based on the flow identifier and add it to the multicast group corresponding to the multicast address; perform flow-following detection on the service flow to generate local IFIT measurement data and send the local IFIT measurement data to the multicast group; receive IFIT measurement data sent by other nodes in the multicast group; and execute local traffic engineering policies based on the local IFIT measurement data and the received IFIT measurement data from other nodes.

[0083] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the flow detection device 100 and the flow detection device 200 described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0084] Please refer to Figure 7 , Figure 7 A block diagram of an electronic device 10 provided in an embodiment of this application is shown. The electronic device 10 may be... Figure 2 The network consists of a source node, an intermediate forwarding node, or a destination node. Electronic device 10 includes a processor 11, a memory 12, and a communication module 13. These components are electrically connected directly or indirectly to enable data transmission or interaction. For example, these components can be electrically connected via one or more communication buses or signal lines. The processor 11 is responsible for control and management, the memory 12 is responsible for storing instructions and data, and the communication module 13 is responsible for sending and receiving network messages.

[0085] The memory 12 is used to store programs. After receiving an execution instruction, the processor 11 executes the programs to implement the flow detection method for source nodes disclosed in the above embodiments, or the flow detection method for intermediate forwarding nodes or destination nodes.

[0086] The memory 12 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0087] Processor 11 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed through integrated logic circuits in the hardware of processor 11 or through software instructions. Processor 11 can be a general-purpose processor, including a Central Processing Unit (CPU), a Microcontroller Unit (MCU), a Complex Programmable Logic Device (CPLD), a Field Programmable Gate Array (FPGA), embedded ARM chips, etc.

[0088] This application also provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by the processor 11, it implements the flow detection method for source nodes disclosed in the above embodiments, or the flow detection method for intermediate forwarding nodes or destination nodes.

[0089] In summary, the following flow detection method, apparatus, electronic device, and storage medium provided in this application, when a service flow arrives for the first time, the source node determines the flow identifier of the service flow, generates a multicast address based on the flow identifier, joins the multicast group corresponding to the multicast address, then performs flow detection on the service flow to generate local IFIT measurement data and sends it to the multicast group. Simultaneously, it receives IFIT measurement data sent by other nodes in the multicast group and executes local traffic engineering policies based on the local IFIT measurement data and the IFIT measurement data sent by other nodes. Thus, on the one hand, the source node can directly obtain the IFIT measurement data of other nodes through the multicast group, so that network adjustment decisions are no longer limited to a single node, solving the problem of incoordination between nodes in the local analysis model; on the other hand, all nodes do not need to report IFIT measurement data to the controller, nor do they need to wait for the controller to summarize and analyze the data before issuing policies. The source node can execute local traffic engineering policies immediately after receiving the IFIT measurement data from other node devices, avoiding communication round-trip delays and centralized computing overhead, solving the problems of high latency and high overhead in the controller model; thereby achieving flow detection that simultaneously considers low overhead, low latency, and inter-node coordination.

[0090] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for detecting flow-in-flow, characterized in that, Applied to the source node, the method includes: When a service flow arrives for the first time, its flow identifier is determined. A multicast address is generated based on the stream identifier, and the multicast address is added to the multicast group corresponding to the multicast address. Perform flow-following detection on the service flow to generate local flow-following detection IFIT measurement data, and send the local IFIT measurement data to the multicast group; Receive IFIT measurement data sent by other nodes in the multicast group; Based on the local IFIT measurement data and the received IFIT measurement data from other nodes, a local traffic engineering policy is executed.

2. The in-flow detection method as described in claim 1, characterized in that, The step of determining the flow identifier of the service flow upon its first arrival includes: An instance identifier is generated when the business flow arrives for the first time; The instance identifier is concatenated with the device identifier of the source node to obtain the flow identifier of the service flow.

3. The in-flow detection method as described in claim 1, characterized in that, The flow identifier includes an instance identifier and the device identifier of the source node; The step of generating a multicast address based on the stream identifier and adding it to the multicast group corresponding to the multicast address includes: Extract the instance identifier and the device identifier of the source node from the flow identifier; The device identifier of the source node is hashed to obtain a hash value; Take the bit value at a preset position in the hash value and concatenate it with the instance identifier and the preset multicast prefix to obtain the multicast address; Send a join message to the multicast address to join the multicast group corresponding to the multicast address.

4. The in-flow detection method as described in claim 1, characterized in that, The step of executing a local traffic engineering policy based on the local IFIT measurement data and the received IFIT measurement data from other nodes includes: Based on the local IFIT measurement data and the IFIT measurement data of other nodes, calculate the network quality parameters between any two nodes on the IFIT flow detection path; Based on the network quality parameters between any two nodes, execute a local traffic engineering strategy.

5. The in-flow detection method as described in claim 1, characterized in that, The method further includes: Delete the local IFIT instance when the set conditions are met; After confirming the deletion of the local IFIT instance, exit the multicast group.

6. A method for detecting flow-in-flow, characterized in that, Applied to intermediate forwarding nodes or destination nodes, the method includes: Upon receiving a service flow, extract the flow identifier of the service flow; A multicast address is generated based on the stream identifier, and the multicast address is added to the multicast group corresponding to the multicast address. Perform flow-following detection on the service flow to generate local IFIT measurement data, and send the local IFIT measurement data to the multicast group; Receive IFIT measurement data sent by other nodes in the multicast group; Based on the local IFIT measurement data and the received IFIT measurement data from other nodes, a local traffic engineering policy is executed.

7. A flow-following detection device, characterized in that, Applied to the source node, the device includes: The flow identifier allocation module is used to determine the flow identifier of the service flow when the service flow arrives for the first time; The first execution module is configured to generate a multicast address based on the flow identifier and join the multicast group corresponding to the multicast address; perform flow-following detection on the service flow to generate local flow-following detection IFIT measurement data and send the local IFIT measurement data to the multicast group; receive IFIT measurement data sent by other nodes in the multicast group; and execute a local traffic engineering policy based on the local IFIT measurement data and the received IFIT measurement data from the other nodes.

8. A flow-following detection device, characterized in that, Applied to intermediate forwarding nodes or destination nodes, the device includes: The flow identifier extraction module is used to extract the flow identifier of the service flow when a service flow is received; The second execution module is configured to generate a multicast address based on the flow identifier and join the multicast group corresponding to the multicast address; perform flow-following detection on the service flow to generate local IFIT measurement data and send the local IFIT measurement data to the multicast group; receive IFIT measurement data sent by other nodes in the multicast group; and execute a local traffic engineering policy based on the local IFIT measurement data and the received IFIT measurement data from the other nodes.

9. An electronic device, characterized in that, It includes a processor and a memory, the memory being used to store a program, and the processor being used to implement the flow detection method as described in any one of claims 1-5, or the flow detection method as described in claim 6, when executing the program.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the flow detection method as described in any one of claims 1-5, or the flow detection method as described in claim 6.

Images