Traffic forwarding method, device, equipment, medium and program product

Abstract

The invention provides a traffic forwarding method and device, equipment, a medium and a program product, and relates to the field of computer networks and communication, and the method comprises the steps: obtaining a data packet corresponding to a traffic forwarding request in response to the traffic forwarding request; detecting whether network congestion exists; if it is determined that network congestion exists, target next-hop equipment is determined based on a pre-established explicit congestion notification neighbor list; adding an explicit congestion notification mark for the data packet; sending the data packet added with the explicit congestion notification mark to a target next hop device; according to the method provided by the invention, the technical effects of improving the traffic forwarding efficiency and reducing the forwarding delay are achieved.

Description

Technical Field

[0001] The present application relates to the field of computer networks and communications, and in particular to a traffic forwarding method, apparatus, device, medium, and program product. Background Art

[0002] Explicit Congestion Notification (ECN) is a congestion control mechanism in network protocols. It aims to achieve more efficient congestion management by replacing traditional packet loss feedback with proactive signaling. Its core principle is that when a network device detects that link resources are nearing saturation, it directly sends a "speed reduction notice" to the sender via the ECN flag field in the packet header. This design enables the sender to proactively adjust the transmission rate before congestion occurs, effectively avoiding the sudden drop in transmission efficiency caused by sudden packet loss while maintaining high network resource utilization. By making congestion signals explicit, ECN significantly improves the accuracy of the network's perception of congestion and the timeliness of its response. Therefore, developing more efficient traffic forwarding methods is a promising approach to building low-latency, high-throughput network transmission solutions.

[0003] In existing technologies, traffic forwarding methods primarily rely on negotiated support. Network devices mark the ECN field of packets as Congestion Experienced (CE) before congestion occurs. The receiver then provides ECN feedback via ECN-Echo, prompting the sender to reduce the rate accordingly, such as by sending a Congestion Window Reduced (CWR). This proactively avoids congestion rather than passively causing packet loss.

[0004] However, if some intermediate devices in the network path don't support ECN, they will clear the ECN field in the Internet Protocol (IP) header, preventing the receiver from obtaining congestion information. After the sender detects packet loss without receiving the ECN-Echo signal for a long time, it is forced to fall back to traditional packet loss and congestion control mechanisms, rendering ECN ineffective. This leads to low traffic forwarding efficiency and high forwarding latency. Summary of the Invention

[0005] The traffic forwarding method, device, equipment, medium and program product provided in this application are used to achieve the technical effect of improving traffic forwarding efficiency.

[0006] In a first aspect, the present application provides a traffic forwarding method, comprising:

[0007] In response to the traffic forwarding request, obtaining a data packet corresponding to the traffic forwarding request;

[0008] Detect whether there is network congestion;

[0009] If network congestion is determined to exist, a target next-hop device is determined based on a pre-established explicit congestion notification neighbor list; wherein all devices in the pre-established explicit congestion notification neighbor list support the explicit congestion notification mechanism; and the target next-hop device is a device in the pre-established explicit congestion notification neighbor list;

[0010] Add explicit congestion notification marking to packets;

[0011] Send the packet with the explicit congestion notification tag added to the target next-hop device.

[0012] In one possible implementation, if it is determined that network congestion exists, determining a target next-hop device based on a pre-established explicit congestion notification neighbor list includes:

[0013] If it is determined that there is network congestion, determining the first next-hop forwarding device corresponding to the traffic forwarding request;

[0014] According to the first next-hop forwarding device, query the pre-established explicit congestion notification neighbor list;

[0015] Based on the query results, the target next-hop device corresponding to the traffic forwarding request is determined.

[0016] In one possible implementation, determining a target next-hop device corresponding to the traffic forwarding request according to the query result includes:

[0017] If the query result shows that the pre-established explicit congestion notification neighbor list includes the first next-hop forwarding device, the first next-hop forwarding device is determined as the target next-hop device corresponding to the traffic forwarding request.

[0018] In one possible implementation, determining a target next-hop device corresponding to the traffic forwarding request according to the query result includes:

[0019] If the query result is that the pre-established explicit congestion notification neighbor list does not include the first next-hop forwarding device, querying the pre-established explicit congestion notification neighbor list for at least one second next-hop device corresponding to the forwarding device; wherein the second next-hop device and the forwarding device are neighbor devices;

[0020] In the at least one second next-hop device, a target next-hop device is determined.

[0021] In a possible implementation, determining, in at least one second next-hop device, a target next-hop device includes:

[0022] Determine the forwarding path for the second next-hop device;

[0023] The second next-hop device corresponding to the shortest forwarding path is determined as the target next-hop device.

[0024] In a possible implementation, before querying the pre-established explicit congestion notification neighbor list according to the first next-hop forwarding device, the method further includes:

[0025] Obtain the routing relationship of the forwarding device;

[0026] Determine the neighboring devices of the forwarding device based on the routing relationship;

[0027] Obtain the explicit congestion notification mechanism type of the neighboring device; the explicit congestion notification mechanism type includes supporting the explicit congestion notification mechanism and not supporting the explicit congestion notification mechanism;

[0028] Create an explicit congestion notification neighbor list based on neighbor devices and explicit congestion notification mechanism type.

[0029] In one possible implementation, determining a first next-hop forwarding device corresponding to a traffic forwarding request includes:

[0030] Obtain the service message corresponding to the traffic forwarding request;

[0031] Determine the target address corresponding to the traffic forwarding request based on the service message;

[0032] Determine the first next-hop forwarding device based on the target address.

[0033] In a possible implementation, detecting whether network congestion exists includes:

[0034] Check the cache of the forwarding device;

[0035] Determine whether there is network congestion based on the cache and the preset cache threshold.

[0036] In a second aspect, the present application provides a traffic forwarding device, comprising:

[0037] An acquisition module, configured to respond to a traffic forwarding request and acquire a data packet corresponding to the traffic forwarding request;

[0038] A detection module, used to detect whether there is network congestion;

[0039] a determination module configured to determine, if it is determined that network congestion exists, a target next-hop device based on a pre-established explicit congestion notification neighbor list; wherein all devices in the pre-established explicit congestion notification neighbor list support the explicit congestion notification mechanism; and the target next-hop device is a device in the pre-established explicit congestion notification neighbor list;

[0040] Marking module, used to add explicit congestion notification marks to data packets;

[0041] The sending module is used to send the data packet with the explicit congestion notification mark added to the target next-hop device.

[0042] In a possible implementation, the determination module is further configured to:

[0043] If it is determined that there is network congestion, determining the first next-hop forwarding device corresponding to the traffic forwarding request;

[0044] According to the first next-hop forwarding device, query the pre-established explicit congestion notification neighbor list;

[0045] Based on the query results, the target next-hop device corresponding to the traffic forwarding request is determined.

[0046] In a possible implementation, the determination module is further configured to:

[0047] If the query result shows that the pre-established explicit congestion notification neighbor list includes the first next-hop forwarding device, the first next-hop forwarding device is determined as the target next-hop device corresponding to the traffic forwarding request.

[0048] In a possible implementation, the determination module is further configured to:

[0049] If the query result is that the pre-established explicit congestion notification neighbor list does not include the first next-hop forwarding device, querying the pre-established explicit congestion notification neighbor list for at least one second next-hop device corresponding to the forwarding device; wherein the second next-hop device and the forwarding device are neighbor devices;

[0050] In the at least one second next-hop device, a target next-hop device is determined.

[0051] In a possible implementation, the determination module is further configured to:

[0052] Determine the forwarding path for the second next-hop device;

[0053] The second next-hop device corresponding to the shortest forwarding path is determined as the target next-hop device.

[0054] In a possible implementation, the determination module is further configured to:

[0055] Obtain the routing relationship of the forwarding device;

[0056] Determine the neighboring devices of the forwarding device based on the routing relationship;

[0057] Obtain the explicit congestion notification mechanism type of the neighboring device; the explicit congestion notification mechanism type includes supporting the explicit congestion notification mechanism and not supporting the explicit congestion notification mechanism;

[0058] Create an explicit congestion notification neighbor list based on neighbor devices and explicit congestion notification mechanism type.

[0059] In a possible implementation, the determination module is further configured to:

[0060] Obtain the service message corresponding to the traffic forwarding request;

[0061] Determine the target address corresponding to the traffic forwarding request based on the service message;

[0062] Determine the first next-hop forwarding device based on the target address.

[0063] In a possible implementation, the detection module is further configured to:

[0064] Check the cache of the forwarding device;

[0065] Determine whether there is network congestion based on the cache and the preset cache threshold.

[0066] In a third aspect, the present application provides a traffic forwarding device, comprising: a memory, a processor;

[0067] Memory stores computer-executable instructions;

[0068] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the above first aspect and / or various possible implementations of the first aspect.

[0069] In a fourth aspect, the present application provides a computer-readable storage medium, which stores computer-executable instructions. When the computer-executable instructions are executed by a processor, they are used to implement the above first aspect and / or various possible implementation methods of the first aspect.

[0070] In a fifth aspect, the present application provides a computer program product, comprising a computer program, which, when executed by a processor, implements the above first aspect and / or various possible implementations of the first aspect.

[0071] The present application provides a traffic forwarding method, apparatus, device, medium, and program product. By clarifying the data packets to be processed, a specific object is provided for subsequent congestion detection and forwarding operations. By checking the cache usage, it is timely determined whether the network is congested, providing a basis for starting congestion control. The next hop is selected by using a pre-recorded list of neighbor devices that support ECN, thereby avoiding the problem that the entire network cannot use the ECN mechanism due to the presence of devices that do not support ECN in the path. By adding ECN tags to data packets, congestion information is directly embedded in the data, ensuring that subsequent ECN-supporting devices can recognize and transmit this information. By sending the marked data packets to the next-hop device that supports ECN, the congestion information can ultimately be transmitted to the receiving end. After the receiving end feedbacks, the sending end reduces the sending speed, thereby effectively alleviating network congestion and maintaining stable network operation, thereby achieving the technical effects of improving traffic forwarding efficiency and reducing forwarding delay. BRIEF DESCRIPTION OF THE DRAWINGS

[0072] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0073] Figure 1 A schematic diagram of an application data processing system architecture provided in an embodiment of the present application;

[0074] Figure 2 Schematic diagram of the flow of the traffic forwarding method provided in this embodiment of the application Figure 1 ;

[0075] Figure 3 Schematic diagram of the flow of the traffic forwarding method provided in this embodiment of the application Figure 2 ;

[0076] Figure 4 Schematic diagram of the flow of the traffic forwarding method provided in this embodiment of the application Figure 3 ;

[0077] Figure 5 Schematic diagram of the network topology provided in this application embodiment Figure 1 ;

[0078] Figure 6 Schematic diagram of the network topology provided in this application embodiment Figure 2 ;

[0079] Figure 7 Schematic diagram of the flow of the traffic forwarding method provided in this embodiment of the application Figure 4 ;

[0080] Figure 8 Schematic diagram of the flow of the traffic forwarding method provided in this embodiment of the application Figure 5 ;

[0081] Figure 9 Schematic diagram of the flow of the traffic forwarding method provided in this embodiment of the application Figure 6 ;

[0082] Figure 10 A schematic diagram of the structure of a traffic forwarding device provided in an embodiment of the present application;

[0083] Figure 11 A schematic diagram of the structure of the traffic forwarding device provided in an embodiment of the present application.

[0084] The above drawings illustrate specific embodiments of the present application, which will be described in more detail below. These drawings and the textual description are not intended to limit the scope of the present application in any way, but rather to illustrate the concepts of the present application to those skilled in the art by reference to specific embodiments. DETAILED DESCRIPTION

[0085] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

[0086] When some intermediate devices in the network path don't support ECN, they clear the ECN field in the IP header, preventing the receiver from obtaining congestion information. After the sender detects packet loss despite not receiving the ECN-Echo signal for a long time, it is forced to fall back to traditional packet loss and congestion control mechanisms, rendering ECN ineffective. This leads to low traffic forwarding efficiency and high forwarding latency.

[0087] In response to the above problems, the present application provides a traffic forwarding method, apparatus, device, medium and program product, which, by clarifying the data packets to be processed, provide specific objects for subsequent congestion detection and forwarding operations; by checking cache usage, timely determine whether the network is congested, and provide a basis for starting congestion control; select the next hop by using a pre-recorded list of neighbor devices that support ECN, thereby avoiding the problem that the entire network cannot use the ECN mechanism due to the presence of devices that do not support ECN in the path; by adding ECN tags to data packets, congestion information is directly embedded in the data, ensuring that subsequent ECN-supporting devices can recognize and transmit this information; by sending the marked data packets to the next-hop device that supports ECN, the congestion information can eventually be transmitted to the receiving end. After the receiving end feedbacks, the sending end reduces the sending speed, thereby effectively alleviating network congestion and maintaining stable network operation, thereby achieving the technical effects of improving traffic forwarding efficiency and reducing forwarding delay.

[0088] The following specific embodiments describe in detail the technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0089] Figure 1 This is a schematic diagram of an application data processing system architecture provided in an embodiment of the present application. The application data processing system is a computer device. Figure 1 As shown, the above architecture includes at least one of a data acquisition device 101 , a processing device 102 and a display device 103 .

[0090] It is understood that the structure illustrated in the embodiments of this application does not constitute a specific limitation on the architecture of the application data processing system. In other feasible implementations of this application, the above architecture may include more or fewer components than shown, or combine or split certain components, or arrange the components differently. The specific configuration can be determined based on the actual application scenario and is not limited here. Figure 1 The components shown can be implemented in hardware, software, or a combination of software and hardware.

[0091] In a specific implementation process, the data acquisition device 101 may include an input / output interface and may also include a communication interface. The data acquisition device 101 may be connected to the processing device via the input / output interface or the communication interface.

[0092] When network congestion occurs, processing device 102 intelligently selects ECN-compatible nodes as data relay paths based on a pre-configured list of ECN-supported devices and adds congestion markers to data packets. This design ensures that congestion signals are proactively transmitted to the receiving end, enabling it to reduce speeds in advance rather than passively waiting for packet loss. This shifts network regulation from a "post-event" approach to a "pre-emptive" approach, significantly improving transmission efficiency and bandwidth utilization.

[0093] The display device 103 may also be a touch screen display or a screen of a terminal device, which is used to receive user instructions while displaying the above content to achieve interaction with the user.

[0094] It should be understood that the above-mentioned processing device can be implemented by a processor reading instructions in a memory and executing the instructions, or it can be implemented by a chip circuit.

[0095] In addition, the network architecture and business scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Ordinary technicians in this field can know that with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0096] Figure 2 Schematic diagram of the flow of the traffic forwarding method provided in this embodiment of the application Figure 1 ,like Figure 2 As shown, the traffic forwarding method provided in this embodiment is applied to a forwarding device and includes:

[0097] S201. In response to a traffic forwarding request, obtain a data packet corresponding to the traffic forwarding request.

[0098] When a forwarding device receives a traffic forwarding request, it first needs to obtain the data packet to be processed. This is the starting point of the entire forwarding process. The device analyzes the packet header to determine its transmission path and service characteristics, providing basic data for subsequent congestion detection and path selection.

[0099] S202: Detect whether there is network congestion.

[0100] Forwarding devices check for network congestion. This is typically accomplished by monitoring internal buffer occupancy and other indicators. If congestion is detected, the device triggers subsequent congestion control mechanisms to prevent further deterioration in network performance.

[0101] S203: If it is determined that network congestion exists, determine a target next-hop device based on a pre-established explicit congestion notification neighbor list.

[0102] In this embodiment, all devices in the pre-established explicit congestion notification neighbor list support the explicit congestion notification mechanism; the target next-hop device is a device in the pre-established explicit congestion notification neighbor list.

[0103] The device has previously memorized which neighboring devices (such as other routers) support Congestion Notification. When it detects network congestion, it doesn't follow the default route to the next device (which might not support Congestion Notification). Instead, it selects a device from the memorized list of devices that support Congestion Notification as its next stop.

[0104] S204: Add an explicit congestion notification mark to the data packet.

[0105] After determining the target next-hop device, the device sets the ECN flag field in the IP header of the data packet. This flag is used to inform downstream devices that the current network is congested, thereby triggering the sender to adjust the rate.

[0106] S205: Send the data packet with the explicit congestion notification mark added to the target next-hop device.

[0107] Finally, the device sends the ECN-tagged packet to the target next-hop device. This step ensures that the ECN tag is continuously transmitted throughout the network, ensuring that even if there are devices that do not support ECN, the communication terminal receives the congestion signal and takes appropriate congestion control measures.

[0108] The present application provides a traffic forwarding method that, by clarifying the data packets to be processed, provides specific objects for subsequent congestion detection and forwarding operations; by checking cache usage, it is timely determined whether the network is congested, providing a basis for starting congestion control; by selecting the next hop using a pre-recorded list of neighbor devices that support ECN, the problem of the entire network being unable to use the ECN mechanism due to the presence of devices that do not support ECN in the path is avoided; by adding ECN tags to data packets, congestion information is directly embedded in the data, ensuring that subsequent devices that support ECN can recognize and transmit this information; by sending the marked data packets to the next hop device that supports ECN, the congestion information can ultimately be transmitted to the receiving end. After the receiving end feedbacks, the sending end reduces the sending speed, thereby effectively alleviating network congestion and maintaining stable network operation, thereby achieving the technical effects of improving traffic forwarding efficiency and reducing forwarding delay.

[0109] Figure 3 Schematic diagram of the flow of the traffic forwarding method provided in this embodiment of the application Figure 2 ,like Figure 3 As shown, this embodiment, based on the above embodiment, describes in detail the process of determining the target next-hop device, including:

[0110] S301: If it is determined that network congestion exists, determine a first next-hop forwarding device corresponding to the traffic forwarding request.

[0111] After confirming network congestion, the device determines the default next-hop device for the packet based on its routing table. This step is crucial for determining the packet's transmission path, as the device selects the most appropriate next-hop device to continue forwarding the packet.

[0112] S302: Query a pre-established explicit congestion notification neighbor list according to the first next-hop forwarding device.

[0113] The device queries a pre-established ECN neighbor list to check whether the default next-hop device supports ECN. This list is dynamically maintained through Internet Control Message Protocol (ICMP) detection to ensure real-time accuracy of the device list.

[0114] S303: Determine the target next-hop device corresponding to the traffic forwarding request according to the query result.

[0115] Based on the query results, the device determines the final target next-hop device. If the default next-hop device supports ECN, it is used as the target next-hop device. If not, another ECN-supported neighboring device is selected as the target next-hop device to ensure continuous transmission of the ECN tag.

[0116] This application provides a traffic forwarding method. When congestion is detected, the system prioritizes searching a pre-established list of devices that support the ECN mechanism and selects only compatible devices as data transfer nodes, ensuring that congestion signals can be effectively transmitted through ECN marking. This strategy enables the receiving end to sense congestion in advance and proactively reduce the speed, avoiding the drastic performance drop caused by traditional packet loss. Ultimately, smooth rate adjustment is achieved under congestion conditions, fully utilizing bandwidth resources while shortening the congestion response cycle through proactive feedback. This creates a more efficient and congestion-resistant network transmission system, thereby achieving the technical effects of improving traffic forwarding efficiency and reducing forwarding latency.

[0117] Figure 4 Schematic diagram of the flow of the traffic forwarding method provided in this embodiment of the application Figure 3 ,like Figure 4 As shown, this embodiment provides a supplementary explanation of the process of determining the target next-hop device based on the above embodiment, including:

[0118] S401: Query a pre-established explicit congestion notification neighbor list according to a first next-hop forwarding device.

[0119] Figure 5 Schematic diagram of the network topology provided in this application embodiment Figure 1 ,like Figure 5 As shown, U1 and U2 are communication terminals. A, B, C, D, and E are forwarding devices (also known as intermediate devices, routers, etc.). A, C, D, and E support ECN, while B does not. The default network path is U1-ABCD-U2.

[0120] When network congestion is detected, the system first determines the first candidate forwarding node for the current data packet according to the default routing rule, such as Figure 5 Device B, which is the default path in the network, then performs an exact match query on a pre-built whitelist of ECN-compatible devices. This whitelist is dynamically maintained via ICMP probing and records all directly connected neighboring devices that have passed ECN capability verification.

[0121] S402: If the query result shows that the pre-established explicit congestion notification neighbor list includes the first next-hop forwarding device, the first next-hop forwarding device is determined as the target next-hop device corresponding to the traffic forwarding request.

[0122] Figure 6 Schematic diagram of the network topology provided in this application embodiment Figure 2 ,like Figure 6 As shown, neither B nor C supports ECN. However, traffic can be transmitted through the U1-AEFD-U2 transmission path.

[0123] If the query result shows that the first candidate node exists in the ECN neighbor list, such as Figure 6 If device A finds that device B supports ECN, it will directly confirm it as the final forwarding target. This process ensures that when the default path has ECN support, the stability of the original transmission path is prioritized, avoiding unnecessary path switching overhead.

[0124] It should be noted that Figure 5 and Figure 6 It is only for illustrative purposes and does not affect the scope of protection of this application.

[0125] S403: If the query result shows that the pre-established explicit congestion notification neighbor list does not include the first next-hop forwarding device, query the pre-established explicit congestion notification neighbor list for at least one second next-hop device corresponding to the forwarding device.

[0126] In this embodiment, the second next-hop device and the forwarding device are neighboring devices.

[0127] When the first candidate node is not in the ECN support list, such as Figure 5 If the B device does not support ECN, the system will start the backup path exploration mechanism. At this time, the device will traverse the local ECN neighbor list and filter out all neighbor nodes that are directly connected to the current device and support ECN as candidates, such as Figure 5 E device in.

[0128] S404: Determine a forwarding path for the second next-hop device.

[0129] For the selected candidate nodes, the device calculates the complete forwarding path to the final destination through the routing protocol. This process takes into account the link bandwidth, delay and other parameters to generate multiple alternative transmission paths, such as Figure 6 Middle U1-AEFD-U2 path.

[0130] S405: Determine the second next-hop device corresponding to the shortest forwarding path as the target next-hop device.

[0131] Among the alternative paths, the system selects the path with the least physical hops or the lowest overall cost, such as Figure 4 The AECD path is selected and the first hop device on the path is identified as the target next hop. This mechanism reduces transmission delay and balances network load through path optimization while ensuring ECN signal transmission.

[0132] The traffic forwarding method provided in the embodiments of the present application establishes a dynamic path selection mechanism. When an ECN compatibility issue is detected in the default path, the method can intelligently switch to an alternative path that supports ECN. This not only avoids the overall mechanism rollback caused by ECN failure of individual devices, but also reduces transmission delay through the shortest path priority strategy, ensuring the effective transmission of ECN marking signals between communication terminals. Thus, while maintaining the advantages of active congestion control, it optimizes network resource utilization and transmission efficiency, achieving the technical effects of improving traffic forwarding efficiency and reducing forwarding delay.

[0133] Figure 7 Schematic diagram of the flow of the traffic forwarding method provided in this embodiment of the application Figure 4 ,like Figure 7 As shown, this embodiment, based on the above embodiment, supplements the prerequisites for querying the pre-established explicit congestion notification neighbor list, including:

[0134] S701: Obtain the routing relationship of the forwarding device.

[0135] Forwarding devices obtain information about the current network topology by running dynamic routing protocols or reading static routing configurations. This process establishes a logical connection map between devices, clearly defining the paths along which packets can be forwarded and providing the foundational data for neighbor identification.

[0136] S702: Determine neighbor devices of the forwarding device based on the routing relationship.

[0137] Based on the outbound interface information in the routing table entries, the device identifies all neighboring devices connected via direct physical links.

[0138] Combined with the above Figure 5 ,Router A determines that the directly connected devices B and E are candidate neighbor nodes by parsing the routing table, forming an initial neighbor device set.

[0139] S703: Obtain the explicit congestion notification mechanism type of the neighboring device.

[0140] In this embodiment, the explicit congestion notification mechanism type includes supporting the explicit congestion notification mechanism and not supporting the explicit congestion notification mechanism.

[0141] The device sends a customized ICMP probe message to each candidate neighbor and sets the ECN capability flag (01 or 10) in the message's IP header. It then analyzes the ECN field in the neighbor's returned Echo Reply message to determine whether it retains its original value. This determines whether the neighbor supports ECN, thereby forming a structured device capability list.

[0142] S704: Create an explicit congestion notification neighbor list according to neighbor devices and explicit congestion notification mechanism types.

[0143] The detection results are stored in a local database as "IP address-ECN support status" key-value pairs to build an ECN neighbor whitelist. This list updates the device's ECN capability status in real time, providing a query interface for subsequent path selection, ensuring that traffic is prioritized over ECN-supported transmission channels.

[0144] The traffic forwarding method provided in the embodiments of the present application constructs a dynamically updated ECN-compatible device map through active topology perception and device capability detection, thereby ensuring the integrity of neighbor device identification and filtering out nodes that do not support ECN through the ICMP verification mechanism. This provides an accurate path selection basis for subsequent congestion control, fundamentally avoiding mechanism degradation caused by the presence of ECN-failed devices in the path, and ensuring that the network always operates in the optimal congestion control mode, thereby achieving the technical effects of improving traffic forwarding efficiency and reducing forwarding latency.

[0145] Figure 8 Schematic diagram of the flow of the traffic forwarding method provided in this embodiment of the application Figure 5 ,like Figure 8 As shown, this embodiment, based on the above embodiment, describes in detail the process of determining the first next-hop forwarding device, including:

[0146] S801. Obtain a service message corresponding to a traffic forwarding request.

[0147] When a forwarding device receives a traffic forwarding request, the system extracts the complete service data packet from the request. This packet includes the transport layer header and the network layer header, providing a complete five-tuple of information for subsequent routing decisions, ensuring that the device can accurately identify the service type and destination address.

[0148] S802: Determine the target address corresponding to the traffic forwarding request according to the service message.

[0149] The device parses the network layer header of the service packet and extracts the destination IP address field. It then searches the local routing table or forwarding information base (FIB) and associates the destination IP address with the routing entry with the longest prefix match, thereby determining the destination address to which the packet should be delivered.

[0150] S803: Determine the first next-hop forwarding device according to the target address.

[0151] Based on the outgoing interface and next hop information in the routing table, the device determines the initial forwarding path for the data packet. Figure 5 When U1 sends data to U2, device A determines that the default next hop is device B through routing table query, forming a transmission path of U1-ABCD-U2, providing a reference path for subsequent congestion detection and path optimization.

[0152] The traffic forwarding method provided in the embodiment of the present application establishes a mapping relationship from service messages to physical transmission paths by parsing message header information layer by layer and matching the routing table. This ensures that the device can accurately identify the final destination of the data flow and quickly determine the initial forwarding path through the default routing mechanism, providing basic path support for subsequent congestion perception and ECN-compatible path selection. While ensuring routing accuracy, it reduces path calculation overhead, achieving the technical effects of improving traffic forwarding efficiency and reducing forwarding delay.

[0153] Figure 9 Schematic diagram of the flow of the traffic forwarding method provided in this embodiment of the application Figure 6 ,like Figure 9 As shown, this embodiment, based on the above embodiment, describes in detail the process of detecting network congestion, including:

[0154] S901: Check the cache of the forwarding device.

[0155] Forwarding devices determine network load by monitoring the occupancy of their internal data buffers in real time. They continuously monitor the number of packets or bytes accumulated in the input and output queues, generating a dynamic buffer occupancy metric that provides a quantitative basis for congestion assessment.

[0156] S902: Determine whether there is network congestion based on the cache and a preset cache threshold.

[0157] The device compares the real-time buffer occupancy rate with a preset congestion threshold. If the buffer occupancy rate exceeds the threshold, the system determines network congestion and immediately triggers the subsequent ECN marking and path optimization processes. If the threshold is not exceeded, normal forwarding continues.

[0158] The traffic forwarding method provided in the embodiment of the present application achieves quantitative perception of the network load status by establishing a congestion detection mechanism based on physical cache. This not only avoids the misjudgment or missed judgment that may be caused by traditional fuzzy congestion judgment, but also ensures that the active control process can be started at the early stage of congestion through a threshold comparison mechanism, so that the timing of adding ECN tags is accurately matched with the actual network status, minimizing data transmission delay and unnecessary retransmission overhead, and achieving the technical effects of improving traffic forwarding efficiency and reducing forwarding delay.

[0159] Figure 10 This is a schematic diagram of the structure of the traffic forwarding device provided in the embodiment of the present application. The device of this embodiment can be in the form of software and / or hardware. Figure 10 As shown, the traffic forwarding device 1000 provided in the embodiment of the present application includes: an acquisition module 1001, a detection module 1002, a determination module 1003, a marking module 1004, and a sending module 1005:

[0160] The acquisition module 1001 is configured to obtain a data packet corresponding to the traffic forwarding request in response to the traffic forwarding request;

[0161] Detection module 1002, used to detect whether there is network congestion;

[0162] A determination module 1003 is configured to determine a target next-hop device based on a pre-established explicit congestion notification neighbor list if network congestion is determined to exist; wherein all devices in the pre-established explicit congestion notification neighbor list support the explicit congestion notification mechanism; and the target next-hop device is a device in the pre-established explicit congestion notification neighbor list;

[0163] a marking module 1004, configured to add an explicit congestion notification mark to a data packet;

[0164] The sending module 1005 is configured to send the data packet with the explicit congestion notification mark added to the target next-hop device.

[0165] In a possible implementation, the determining module 1003 is further configured to:

[0166] If it is determined that there is network congestion, determining the first next-hop forwarding device corresponding to the traffic forwarding request;

[0167] According to the first next-hop forwarding device, query the pre-established explicit congestion notification neighbor list;

[0168] Based on the query results, the target next-hop device corresponding to the traffic forwarding request is determined.

[0169] In a possible implementation, the determining module 1003 is further configured to:

[0170] If the query result shows that the pre-established explicit congestion notification neighbor list includes the first next-hop forwarding device, the first next-hop forwarding device is determined as the target next-hop device corresponding to the traffic forwarding request.

[0171] In a possible implementation, the determining module 1003 is further configured to:

[0172] If the query result is that the pre-established explicit congestion notification neighbor list does not include the first next-hop forwarding device, querying the pre-established explicit congestion notification neighbor list for at least one second next-hop device corresponding to the forwarding device; wherein the second next-hop device and the forwarding device are neighbor devices;

[0173] In the at least one second next-hop device, a target next-hop device is determined.

[0174] In a possible implementation, the determining module 1003 is further configured to:

[0175] Determine the forwarding path for the second next-hop device;

[0176] The second next-hop device corresponding to the shortest forwarding path is determined as the target next-hop device.

[0177] In a possible implementation, the determining module 1003 is further configured to:

[0178] Obtain the routing relationship of the forwarding device;

[0179] Determine the neighboring devices of the forwarding device based on the routing relationship;

[0180] Obtain the explicit congestion notification mechanism type of the neighboring device; the explicit congestion notification mechanism type includes supporting the explicit congestion notification mechanism and not supporting the explicit congestion notification mechanism;

[0181] Create an explicit congestion notification neighbor list based on neighbor devices and explicit congestion notification mechanism type.

[0182] In a possible implementation, the determining module 1003 is further configured to:

[0183] Obtain the service message corresponding to the traffic forwarding request;

[0184] Determine the target address corresponding to the traffic forwarding request based on the service message;

[0185] Determine the first next-hop forwarding device based on the target address.

[0186] In a possible implementation, the detection module 1002 is further configured to:

[0187] Check the cache of the forwarding device;

[0188] Determine whether there is network congestion based on the cache and the preset cache threshold.

[0189] The traffic forwarding device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effects are similar, and are not described in detail in this embodiment.

[0190] Figure 11 This is a schematic diagram of the structure of the traffic forwarding device provided in the embodiment of the present application. Figure 11 As shown, the traffic forwarding device 1100 provided in this embodiment includes: at least one processor 1101 and a memory 1102. Optionally, the device 1100 also includes a communication component 1103. The processor 1101, the memory 1102, and the communication component 1103 are connected via a bus.

[0191] During the specific implementation process, at least one processor 1101 executes the computer-executable instructions stored in the memory 1102, so that the at least one processor 1101 performs the above method.

[0192] The specific implementation process of the processor 1101 can be found in the above method embodiment. Its implementation principle and technical effects are similar and will not be repeated here in this embodiment.

[0193] In the above embodiments, it should be understood that the processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASICs), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the present invention may be directly executed by a hardware processor or by a combination of hardware and software modules within the processor.

[0194] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage.

[0195] A bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. Buses can be categorized as address buses, data buses, and control buses. For ease of illustration, the buses in the drawings of this application are not limited to just one bus or just one type of bus.

[0196] An embodiment of the present application also provides a computer program product, including a computer program, which implements the above method when executed by a processor.

[0197] An embodiment of the present application further provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above-mentioned method is implemented.

[0198] The readable storage medium may be implemented by any type of volatile or non-volatile memory device, or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium may be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0199] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be an integral part of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (ASIC). Of course, the processor and the readable storage medium can also exist in the device as discrete components.

[0200] The division of units is merely a logical functional division; actual implementations may employ alternative divisions, such as combining or integrating multiple units or components into another system, or omitting or disabling certain features. Furthermore, any direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units, either through an interface, electrical, mechanical, or other means.

[0201] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0202] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0203] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the portion that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the method of the present invention. The aforementioned storage medium includes various media that can store program code, such as USB flash drives, mobile hard drives, read-only memories (ROMs), random access memories (RAMs), magnetic disks, or optical disks.

[0204] Those skilled in the art will appreciate that all or part of the steps in the above-described method embodiments can be implemented using hardware associated with program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0205] Finally, it should be noted that those skilled in the art will readily identify other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses, or adaptations of the present invention that follow the general principles of the present invention and include common knowledge or customary techniques in the art not disclosed herein. The present invention is not limited to the precise structure described above and illustrated in the accompanying drawings, and various modifications and variations may be made without departing from the scope thereof. The scope of the present invention is limited solely by the appended claims.

Claims

1. A traffic forwarding method, characterized in that: Applied to a forwarding device, the method includes: In response to a traffic forwarding request, obtaining a data packet corresponding to the traffic forwarding request; Detect whether there is network congestion; If it is determined that there is network congestion, determining a target next-hop device based on a pre-established explicit congestion notification neighbor list; wherein all devices in the pre-established explicit congestion notification neighbor list support the explicit congestion notification mechanism; and the target next-hop device is a device in the pre-established explicit congestion notification neighbor list; adding an explicit congestion notification tag to the data packet; The data packet with the explicit congestion notification mark added is sent to the target next-hop device.

2. The method according to claim 1, characterized in that If it is determined that network congestion exists, determining a target next-hop device based on a pre-established explicit congestion notification neighbor list includes: If it is determined that network congestion exists, determining a first next-hop forwarding device corresponding to the traffic forwarding request; querying, according to the first next-hop forwarding device, in the pre-established explicit congestion notification neighbor list; According to the query result, the target next-hop device corresponding to the traffic forwarding request is determined.

3. The method according to claim 2, characterized in that The determining, according to the query result, a target next-hop device corresponding to the traffic forwarding request includes: If the query result is that the pre-established explicit congestion notification neighbor list includes the first next-hop forwarding device, the first next-hop forwarding device is determined as the target next-hop device corresponding to the traffic forwarding request.

4. The method according to claim 2, characterized in that The determining, according to the query result, a target next-hop device corresponding to the traffic forwarding request includes: If the query result is that the pre-established explicit congestion notification neighbor list does not include the first next-hop forwarding device, querying the pre-established explicit congestion notification neighbor list for at least one second next-hop device corresponding to the forwarding device; wherein the second next-hop device and the forwarding device are neighboring devices; In the at least one second next-hop device, a target next-hop device is determined.

5. The method according to claim 4, characterized in that The determining of a target next-hop device in the at least one second next-hop device includes: Determining a forwarding path for the second next-hop device; The second next-hop device corresponding to the shortest forwarding path is determined as the target next-hop device.

6. The method according to any one of claims 2 to 5, characterized in that Before querying the pre-established explicit congestion notification neighbor list according to the first next-hop forwarding device, the method further includes: Obtaining a routing relationship of the forwarding device; Determining a neighbor device of the forwarding device according to the routing relationship; Obtaining an explicit congestion notification mechanism type of the neighboring device; wherein the explicit congestion notification mechanism type includes supporting the explicit congestion notification mechanism and not supporting the explicit congestion notification mechanism; An explicit congestion notification neighbor list is established according to the neighbor device and the explicit congestion notification mechanism type.

7. The method according to claim 6, characterized in that The determining the first next-hop forwarding device corresponding to the traffic forwarding request includes: Obtaining a service message corresponding to the traffic forwarding request; Determine, according to the service message, a target address corresponding to the traffic forwarding request; A first next-hop forwarding device is determined according to the target address.

8. The method according to claim 1, characterized in that The detecting whether there is network congestion includes: detecting a cache of the forwarding device; It is determined whether there is network congestion based on the cache and a preset cache threshold.

9. A traffic forwarding device, characterized in that: include: An acquisition module, configured to, in response to a traffic forwarding request, acquire a data packet corresponding to the traffic forwarding request; A detection module, used to detect whether there is network congestion; a determination module configured to determine, if it is determined that network congestion exists, a target next-hop device based on a pre-established explicit congestion notification neighbor list; wherein all devices in the pre-established explicit congestion notification neighbor list support the explicit congestion notification mechanism; and the target next-hop device is a device in the pre-established explicit congestion notification neighbor list; a marking module, configured to add an explicit congestion notification mark to the data packet; A sending module is configured to send the data packet with the explicit congestion notification mark added to the target next-hop device.

10. A traffic forwarding device, characterized in that: include: Memory, processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the processor performs the method according to any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 8 when executed by a processor.

12. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 8 when executed by a processor.

Images