A network congestion notification method and related device

Abstract

This invention discloses a network congestion notification method and related equipment. The method includes: monitoring the queue length of its outgoing port through a network device; triggering a congestion notification when the queue length exceeds a preset congestion threshold; responding to the congestion notification, determining an offset based on the byte length of each protocol header in the currently forwarded target data packet through the network device, and extracting a communication object field from the target data packet based on the offset; generating a congestion notification message through packet encapsulation based on the communication object field; and transmitting the congestion notification message to the source device through the network device, so that the source device can parse the communication object field and reduce the sending rate of the target communication object based on the communication object field. The congestion detection and notification of this invention are initiated directly at the point of congestion, without the need for relaying through the receiving end, which helps to shorten the congestion response latency, enabling the source device to perceive and alleviate network congestion more quickly. This method can be widely applied in the field of data processing technology.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a network congestion notification method and related equipment. Background Technology

[0002] Large-scale models are driving an exponential increase in computing power demand. Remote Direct Memory Access (RDMA), with its advantages such as kernel bypass, zero-copy, and CPU offloading, offers higher transmission efficiency than traditional TCP / IP network protocols. InfiniBand (IB) is a completely redesigned RDMA protocol, but devices supporting IB are expensive, making the cost of building an IB-based RDMA network too high. RoCEv2 (RDMA over converged ethernet version 2) encapsulates the IB transport layer onto UDP, enabling RDMA transmission across traditional IP networks without requiring equipment upgrades, making it the current mainstream technology for RDMA networks. However, UDP is not a reliable transmission protocol; if packet loss occurs, RDMA's go-back-N retransmission mechanism can drastically reduce effective transmission efficiency.

[0003] In RoCEv2 networks, the basic unit of communication is a Queue Pair (QP), not a node. Each QP on each node has a unique number called a Queue Pair Number (QPN), which uniquely identifies a QP on a node. For each node, each process can use several QPs, and each local Source QP can be associated with a remote Destination QP. The Base Transport Header (BTH) of the IB transport layer contains the Destination QP, which is the target queue QP number at the receiving end, equivalent to a TCP port number, indicating which remote QP should receive the data packet.

[0004] In a RoCEv2 network, triggering a rate reduction at the sending end requires knowing the sending end's QP information. Traditional congestion notification methods, such as ECN (Explicit Congestion Notification), require setting the ECN field to CE(11) as a marker for the congestion packet and sending it to the receiving end. The receiving end then generates a CNP (Congestion Notification Packet) message to notify the source end to reduce its rate. The CNP message contains the Destination QP. When the sending end receives the CNP message, it parses the Destination QP from the BTH and obtains the local Source QP based on the negotiation relationship during connection establishment, thereby reducing the rate of that Source QP. This method requires sending the congestion notification to the receiving end first, resulting in a delay in the congestion notification process. Summary of the Invention

[0005] The main objective of this invention is to provide a network congestion notification method, apparatus, electronic device, storage medium, and program product, aiming to solve at least one problem in the prior art.

[0006] To achieve the above objectives, one aspect of this invention provides a network congestion notification method, the method comprising: The network device monitors the queue length at its outgoing port, and triggers a congestion notification when the queue length exceeds a preset congestion threshold. In response to congestion notification, the network device determines the offset based on the byte length of each protocol header in the currently forwarded target data packet, and extracts the communication object field from the target data packet based on the offset; Based on the communication object field, a congestion notification message is generated through message encapsulation. The congestion notification message is transmitted from the network device to the source device, so that the source device can parse the communication object field and reduce the sending rate of the target communication object based on the communication object field.

[0007] In some implementations, the network device monitors the queue length at its outgoing port. When the queue length exceeds a preset congestion threshold, a congestion notification is triggered, including the following steps: Based on the queue depth register / counter that is statistically analyzed in real time by the media access control layer or physical layer of the network device, the queue length corresponding to the queue length of the network device's output port is extracted. The depth value is compared with a preset congestion threshold. When the depth value is greater than the preset congestion threshold, a congestion notification is triggered. The preset congestion threshold is pre-configured based on network bandwidth and expected latency and stored in the network device's memory.

[0008] In some implementations, the network device determines the offset based on the byte length of each protocol header in the currently forwarded target data packet, and extracts the communication object field from the target data packet based on the offset, including the following steps: Obtain the IPv6 base header of the target data packet and determine the first offset based on the fixed length of the IPv6 base header; Obtain the UDP header following the IPv6 basic header in the target datagram, and determine the second offset based on the fixed length of the UDP header; Obtain the IB transport layer header following the UDP header in the target datagram; The communication object field is located in a preset byte in the IB transport layer header; Use the number of bytes from the beginning of the IB transport layer header to the beginning of the communication object field as the third offset; The first offset, the second offset, and the third offset are summed to obtain the total offset; Starting from the first byte of the target data packet, offset by the total offset, and then continuously read a preset number of bytes of data to obtain the communication object field; The preset quantity is the number of bytes in the fields of the communication object.

[0009] In some implementations, a congestion notification message is generated through message encapsulation based on the communication object field, including the following steps: Extract the destination IP address from the IPv6 base header of the target data packet as the target IP address; The timestamp that triggers the congestion notification is determined based on the local clock of the network device. The network device generates an ICMPv6 Echo Request message as the first notification message; The target IP, communication object field, and timestamp are sequentially encapsulated in the Data field of the first notification message to obtain the second notification message; The configuration source address is determined based on the IPv6 loopback interface address of the network device, and the configuration destination address is determined based on the IP address of the source device corresponding to the target data packet. The congestion notification message is obtained by encapsulating the configuration IPv6 basic header into the second notification message based on the configured source address and configured destination address.

[0010] In some implementations, the method further includes the following steps: Configure the priority field in the IPv6 base header to be of high priority, so that devices along the route that transmit congestion notification messages forward the congestion notification messages with the highest priority. None of the devices along the route modify or remark the priority field.

[0011] In some implementations, transmitting congestion notification messages to the source device via a network device includes the following steps: The IP address of the source device is determined by the network device based on the destination address configured in the IPv6 base header of the congestion notification message. The local routing table is queried using the IP address of the source device to determine the next-hop forwarding interface, and the congestion notification message is sent from the forwarding interface until it is transmitted to the source device.

[0012] In some implementations, the congestion notification message encapsulates a communication object field and the target IP address corresponding to the destination IP address of the target data packet. The source device parses the communication object field and reduces the transmission rate of the target communication object based on the communication object field, including the following steps: By parsing the congestion notification message from the source device, the target IP and communication object fields can be read. Using the target IP and communication object fields as a combined index, the local communication object associated with the remote communication object corresponding to the target IP and communication object fields is matched in the preset communication object mapping table and used as the target communication object. The communication object mapping table records the association between each remote communication object and the local communication object. The communication object mapping table also records the IP and fields of each remote communication object and the local communication object. The sending rate of the target communication object is reduced by slowing down the target communication object through the source device.

[0013] To achieve the above objectives, another aspect of the present invention provides a network congestion notification device, the device comprising: The first module is used to monitor the queue length of the network device's outgoing port and trigger a congestion notification when the queue length exceeds a preset congestion threshold. The second module is used to respond to congestion notifications by determining the offset based on the byte length of each protocol header in the target data packet currently being forwarded by the network device, and extracting the communication object field from the target data packet based on the offset. The third module is used to generate congestion notification messages based on the communication object fields and through message encapsulation. The fourth module is used to transmit congestion notification messages to the source device through the network device, so that the source device can parse the communication object field and reduce the sending rate of the target communication object based on the communication object field.

[0014] To achieve the above objectives, another aspect of the present invention provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned method.

[0015] To achieve the above objectives, another aspect of the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned method.

[0016] To achieve the above objectives, another aspect of the present invention provides a computer program product, including a computer program that, when executed by a processor, implements the aforementioned method.

[0017] The embodiments of the present invention include at least the following beneficial effects: The present invention provides a network congestion notification method, apparatus, electronic device, storage medium, and program product. This solution monitors the queue length of the outgoing port of a network device. When the queue length exceeds a preset congestion threshold, a congestion notification is triggered. In response to the congestion notification, the network device determines the offset based on the byte length of each protocol header in the currently forwarded target data packet, and extracts the communication object field from the target data packet based on the offset. Based on the communication object field, a congestion notification message is generated through packet encapsulation. The network device transmits the congestion notification message to the source device, so that the source device can parse the communication object field and reduce the sending rate of the target communication object based on the communication object field. The congestion detection and notification of this invention are initiated directly by the network device at the point of congestion, without the need for relaying through the receiving end. This shortens the congestion feedback path and helps to reduce congestion response latency, enabling the source device to detect and alleviate network congestion more quickly. Furthermore, this invention only needs to determine the offset based on the fixed byte length of each protocol header in the data packet. It does not require the network device to perform deep parsing of RoCEv2 private protocol fields or support specific private protocol identification capabilities. Nor does it require adding extra fields or modifying existing fields in the RoCEv2 data packet. This reduces the capability requirements of the network device and is conducive to deployment and implementation on existing network devices. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of an implementation environment for the network congestion notification method provided in this embodiment of the invention; Figure 2 This is a flowchart illustrating the network congestion notification method provided in an embodiment of the present invention; Figure 3 This is a schematic diagram illustrating an example of the message format of RoCEv2 provided in an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating an example of the UDP header format provided in an embodiment of the present invention; Figure 5 This is a schematic diagram illustrating an example of the IPv6 basic packet header format provided in an embodiment of the present invention; Figure 6This is a schematic diagram illustrating the format of the ICMPv6 portion of the congestion notification message provided in an embodiment of the present invention; Figure 7 This is a schematic diagram illustrating the format of the IPv6 header portion of the congestion notification message provided in an embodiment of the present invention; Figure 8 This is a schematic diagram illustrating an implementation process example of the network congestion notification method provided in an embodiment of the present invention; Figure 9 This is a schematic diagram of the network congestion notification device provided in an embodiment of the present invention; Figure 10 This is a schematic diagram of the structure of the electronic device provided in an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the embodiments of this invention; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this invention as detailed in the appended claims.

[0020] It is understood that the terms "first," "second," etc., used in this invention may be used to describe various concepts, but unless specifically stated otherwise, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of embodiments of this invention, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words "if" or "when" as used herein may be interpreted as "when," "in response to determination," or "in the event of a determination."

[0021] The terms “at least one,” “multiple,” “each,” “any,” etc., used in this invention, “at least one” includes one, two, or more than two; “multiple” includes two or more than two; “each” refers to each of the corresponding multiple; and “any” refers to any one of the multiple.

[0022] Unless otherwise defined, all technical and scientific terms used in this invention have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used in this invention is for descriptive purposes only and is not intended to limit the invention.

[0023] To facilitate understanding of the technical solution of this invention, the following explanations are provided regarding the technical terms that may be involved in the technical solution of this invention: RDMA: A networking technology that allows one computer to directly access the memory of another computer without the intervention of the other computer's operating system. By bypassing the kernel protocol stack and zero-copy technology, RDMA achieves high-throughput, low-latency, and low-CPU-overhead data transfer, making it a key technology for high-performance computing, distributed storage, and AI training.

[0024] RoCEv2, short for RDMA over Converged Ethernet version 2, is a network protocol. It encapsulates RDMA services within UDP / IPv6 packets for transmission, enabling the deployment of RDMA on standard IP Ethernet infrastructure and overcoming the scalability limitations of InfiniBand private networks.

[0025] QP: Short for Queue Pair, it is the core communication object in the RDMA architecture. A QP consists of a pair of work queues (a send queue and a receive queue). Applications initiate RDMA operations by submitting work requests to the QP. Each QP represents an independent communication connection endpoint.

[0026] ECN, short for Explicit Congestion Notification, is a network congestion control mechanism. It allows network devices to explicitly notify the data sender by marking the ECN field in the IP header when they detect impending congestion, thereby proactively reducing the transmission rate before packet loss occurs.

[0027] CNP: Short for Congestion Notification Packet, it is a specific control message in RoCEv2 networks. When a network device detects congestion and finds that the ECN of a data packet is marked, it generates a CNP and sends it to the source host that caused the congestion, notifying it that a specific QP is congested and triggering rate adjustment.

[0028] ICMPv6, short for Internet Control Message Protocol for IPv6, is a network layer protocol in the IPv6 protocol suite used for transmitting control messages. ICMPv6 is used for network diagnostics (such as ping6), error reporting (such as destination unreachable), and core function implementation (such as Neighbor Discovery (NDP)).

[0029] DSCP, short for Differentiated Services Code Point, is a field in the IP packet header. DSCP is used to mark the service level of a packet. Network devices can provide differentiated services to different types of traffic based on the DSCP value, such as priority scheduling and guaranteed bandwidth, and is the foundation for implementing QoS.

[0030] In related technologies, traditional IP network equipment does not support BTH resolution and cannot directly obtain Destination QP. Upgrading the entire network equipment is costly.

[0031] In view of this, this embodiment of the invention provides a network congestion notification method and related device. This method monitors the queue length at the outgoing port of the network device. When the queue length exceeds a preset congestion threshold, a congestion notification is triggered. In response to the congestion notification, the network device determines the offset based on the byte length of each protocol header in the currently forwarded target data packet, and extracts the communication object field from the target data packet based on the offset. Based on the communication object field, a congestion notification message is generated through packet encapsulation. The network device transmits the congestion notification message to the source device, enabling the source device to parse the communication object field and reduce the sending rate of the target communication object based on the communication object field. The congestion detection and notification of this invention are initiated directly by the network device at the point of congestion, without the need for relaying through the receiving end. This shortens the congestion feedback path and helps to reduce congestion response latency, enabling the source device to detect and alleviate network congestion more quickly. Furthermore, this invention only needs to determine the offset based on the fixed byte length of each protocol header in the data packet. It does not require the network device to perform deep parsing of RoCEv2 private protocol fields or support specific private protocol identification capabilities. Nor does it require adding extra fields or modifying existing fields in the RoCEv2 data packet. This reduces the capability requirements of the network device and is conducive to deployment and implementation on existing network devices.

[0032] It is understood that the network congestion notification method provided by this invention can be applied to any computer device with data processing and computing capabilities, and this computer device can be various types of terminals or servers. When the computer device in the embodiment is a server, the server is an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. Optionally, the terminal can be a smartphone, tablet computer, laptop computer, or desktop computer, but it is not limited to these.

[0033] like Figure 1 The diagram shown is a schematic representation of an implementation environment provided by an embodiment of the present invention. (Refer to...) Figure 1 The implementation environment includes at least one terminal 102 and a server 101. The terminal 102 and the server 101 can be connected via a network, either wirelessly or via a wired connection, to complete data transmission and exchange.

[0034] Server 101 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0035] Additionally, server 101 can also be a node server in a blockchain network. Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms.

[0036] Terminal 102 can be a smartphone, tablet computer, laptop computer, desktop computer, smart speaker, smartwatch, etc., but is not limited to these. Terminal 102 and server 101 can be directly or indirectly connected via wired or wireless communication, and this embodiment of the invention does not impose any limitations.

[0037] For example, based on Figure 1 The implementation environment shown in this embodiment of the invention provides a network congestion notification method. The following description uses the application of this network congestion notification method in server 101 as an example. It can be understood that this network congestion notification method can also be applied to terminal 102.

[0038] Reference Figure 2 , Figure 2 This is an optional flowchart of the network congestion notification method provided in the embodiments of the present invention. The execution subject of the network congestion notification method can be any of the aforementioned computer devices (including servers or terminals). Figure 2 The method may include, but is not limited to, steps S100 to S400.

[0039] Step S100: Monitor the queue length of the network device's outgoing port. When the queue length exceeds a preset congestion threshold, trigger a congestion notification. It should be noted that in some embodiments, monitoring the queue length of the network device's outgoing port and triggering a congestion notification when the queue length exceeds a preset congestion threshold may include the following steps: extracting the depth value corresponding to the queue length of the network device's outgoing port based on the queue depth register / counter counted in real time by the network device's media access control layer or physical layer; comparing the depth value with the preset congestion threshold, and triggering a congestion notification when the depth value is greater than the preset congestion threshold; wherein, the preset congestion threshold is pre-configured based on network bandwidth and expected latency and stored in the network device's memory.

[0040] For example, in some specific implementations, a queue depth register / counter can be configured on each egress port of a network device (e.g., a data center switch). This register / counter is maintained in real time by the network device's Media Access Control (MAC) layer or physical layer to count the amount of packet data buffered in the forwarding queue of that egress port at the current moment (e.g., in bytes or packets). The queue depth value reflects the real-time congestion level of the port. The network device then compares the real-time queue depth value with a preset congestion threshold in its memory. When the depth value is greater than the preset congestion threshold, it means that the queuing situation at the current egress port has exceeded the expected limit. If not handled promptly, packet loss will occur. In this case, the network device triggers a congestion notification, generating a congestion event signal for subsequent response steps and initiating the congestion notification process. If the depth value does not exceed the preset congestion threshold, the network device continues monitoring without triggering a congestion notification.

[0041] In step S200, in response to the congestion notification, the network device determines the offset based on the byte length of each protocol header in the currently forwarded target data packet, and extracts the communication object field from the target data packet based on the offset. It should be noted that in some embodiments, the network device determines the offset based on the byte length of each protocol header in the currently forwarded target data packet, and extracts the communication object field from the target data packet based on the offset. This may include the following steps: obtaining the IPv6 basic header of the target data packet, and determining the first offset based on the fixed length of the IPv6 basic header; obtaining the UDP header after the IPv6 basic header in the target data packet, and determining the second offset based on the fixed length of the UDP header; obtaining the IB transport layer header after the UDP header in the target data packet; wherein the communication object field is located in a preset number of bytes in the IB transport layer header; taking the number of bytes from the beginning of the IB transport layer header to the beginning of the communication object field as the third offset; accumulating the first, second, and third offsets to obtain the total offset; starting from the first byte of the target data packet, offsetting by the total offset, and then continuously reading a preset number of bytes to obtain the communication object field; wherein the preset number is the number of bytes in the communication object field.

[0042] For example, in some specific implementations, the target data packet can be an IPv6-based RoCEv2 packet. RoCEv2 packets are carried by standard Ethernet frames at the link and physical layers. Their core is encapsulating InfiniBand transmission units within UDP / IP packets at the network and transport layers. A RoCEv2 packet sequentially includes an IPv6 base header, a UDP header, and an IB transport layer header (BTH), where the IB transport layer header contains a Destination QP field (i.e., the communication object field). First, the network device obtains the IPv6 base header of the target RoCEv2 packet. The IPv6 base header has a fixed length of 40 bytes and is used as the first offset. Then, the network device obtains the UDP header following the IPv6 base header in the target RoCEv2 packet. The UDP header has a fixed length of 8 bytes (containing four fields: source port number, destination port number, length, and checksum, each field being 2 bytes), and is used as the second offset. In addition, the network device obtains the IB transport layer header (BTH) after the UDP header in the target RoCEv2 packet. The BTH is 12 bytes long and contains information such as Opcode, Destination QP, and Packet Sequence Number. The Destination QP is located in bytes 6-8 of the BTH, meaning the offset from the beginning of the BTH to the beginning of the Destination QP field is 5 bytes, which is used as the third offset. Finally, the first offset (40 bytes), the second offset (8 bytes), and the third offset (5 bytes) are added together to obtain a total offset of 53 bytes. Based on this, starting from the first byte of the IPv6 header of the target RoCEv2 packet, offsetting by the total offset of 53 bytes, and then continuously reading 3 bytes of data (i.e., bytes 6-8 in the BTH), the value of the communication object field—the Destination QP field—can be obtained.

[0043] Step S300: Based on the communication object field, generate a congestion notification message through message encapsulation; It should be noted that in some embodiments, generating a congestion notification message based on the communication object field through message encapsulation may include the following steps: extracting the destination IP address from the IPv6 basic header of the target data packet as the target IP; determining the timestamp that triggers the congestion notification based on the local clock of the network device; generating an ICMPv6 EchoRequest message as a first notification message through the network device; encapsulating the target IP, the communication object field, and the timestamp in sequence in the Data field of the first notification message to obtain a second notification message; determining the configuration source address based on the IPv6 loopback interface address of the network device, and determining the configuration destination address based on the IP address of the source device corresponding to the target data packet; encapsulating the configuration IPv6 basic header of the second notification message based on the configuration source address and the configuration destination address to obtain the congestion notification message.

[0044] For example, in some specific implementations, after extracting the Destination QP, the network device constructs a congestion notification message as follows: First, the network device extracts the destination IP address (Destination IP) from the IPv6 base header of the target RoCEv2 data packet. This destination IP address is 16 bytes long and corresponds to the IPv6 address of the destination device. Simultaneously, when triggering a congestion notification, the network device determines the current timestamp based on its local clock. This timestamp is 8 bytes long and is used to identify the time when congestion occurred. The network device generates an ICMPv6 Echo Request message as the format for the congestion notification message. Specifically, the network device encapsulates the aforementioned Destination IP (16 bytes), Destination QP (3 bytes), and timestamp (8 bytes) sequentially into the data field of the ICMPv6 Echo Request message to obtain the second notification message. The Destination IP is used to assist the source device in quickly locating the Source QP causing the congestion, the Destination QP identifies the QP causing the congestion, and the timestamp is used by the source device to locate the time when congestion occurred. Then, the second notification message is encapsulated with an IPv6 base header (i.e., the IPv6 base header is configured) to obtain the final congestion notification message. When encapsulating the IPv6 base header, the source address is set to the IPv6 loopback interface address of the network device, and the destination address is set to the IP address of the source device that sent the target RoCEv2 packet (to identify the path for transmitting the congestion notification message).

[0045] It should be noted that in some embodiments, the method may further include the following steps: configuring the priority field in the IPv6 basic packet header with high priority to instruct devices along the route that transmit congestion notification packets to forward the congestion notification packets with the highest priority; wherein, none of the devices along the route modify or remark the priority field.

[0046] For example, in some implementations, ICMPv6 Echo Request messages have a low priority in the network and are often dropped during network congestion. To address this issue, congestion notification messages configure the priority field (Traffic Class field) in the IPv6 base header to have a high priority when encapsulating the IPv6 base header.

[0047] Specifically, the Traffic Class field in the IPv6 basic header can be set to 48 (i.e., binary 110000). This value corresponds to a DSCP value of CS6, which is a dedicated channel for "network control traffic." By setting the Traffic Class to 48, the congestion notification message is identified as a high-priority network control message in the network. When forwarding this congestion notification message, devices along the route (intermediate devices) do not modify or remark the Traffic Class field (i.e., the DSCP value) of the message; they directly forward the message with high priority, ensuring that the congestion notification message can reach the source device quickly with high priority even under network congestion.

[0048] Step S400: The congestion notification message is transmitted to the source device through the network device, so that the source device can parse the communication object field and reduce the sending rate of the target communication object based on the communication object field. It should be noted that, in some embodiments, transmitting congestion notification messages to the source device via a network device may include the following steps: the network device determines the IP address of the source device based on the configured destination address in the IPv6 base packet header of the congestion notification message; the source device's IP address is used to query the local routing table to determine the next-hop forwarding interface, and the congestion notification message is sent from the forwarding interface until it is transmitted to the source device.

[0049] For example, in some specific implementations, after encapsulating the congestion notification message, the network device needs to send the congestion notification message from the congestion point to the source device. First, the network device reads the destination address field (which is the IP address of the source device) from the IPv6 base header of the encapsulated congestion notification message. Then, based on the IP address of the source device, it queries its local IPv6 routing table to determine the matching route entry and thus the next-hop forwarding interface. Finally, the network device sends the congestion notification message from the determined forwarding interface. When an intermediate device forwards the congestion notification message, it sees Traffic Class=48 and Next Header=58, recognizes it as a RoCEv2 congestion notification message, and forwards it directly without modifying the DSCP value. The message is forwarded hop-by-hop according to the routing path and finally reaches the source device.

[0050] It should be noted that the congestion notification message encapsulates a communication object field and the target IP address corresponding to the destination IP address of the target data packet. In some embodiments, the source device parses the communication object field and reduces the transmission rate of the target communication object based on the communication object field. This may include the following steps: the source device parses the congestion notification message to read the target IP address and the communication object field; the target IP address and the communication object field are used as a composite index to match the local communication object associated with the remote communication object corresponding to the target IP address and the communication object field in a preset communication object mapping table as the target communication object; wherein, the communication object mapping table records the association relationship between each remote communication object and the local communication object, and the communication object mapping table also records the IP address and field of each remote communication object and the local communication object; the source device performs a speed-down operation on the target communication object to reduce the transmission rate of the target communication object.

[0051] For example, in some specific implementations, after receiving a congestion notification message from a network device, the source device performs message parsing and rate reduction operations, which can be implemented as follows: After receiving the ICMPv6 Echo Request congestion notification message, the source device identifies it as a RoCEv2 ICMPv6 Echo Request congestion notification message based on the message's TrafficClass=48 and Next Header=58.

[0052] Then, the source device parses the data field of the packet, reading it sequentially in lengths of 16 bytes, 3 bytes, and 8 bytes to obtain the Destination IP, Destination QP, and timestamp, respectively.

[0053] The source device uses the resolved Destination IP and Destination QP as indexes to perform a lookup and matching based on the locally stored QP mapping relationship. By combining the Destination IP and Destination QP, the source device can uniquely identify the corresponding local Source QP. Specifically, when the same source device establishes connections with two destination devices with different Destination IPs, and the two destination devices have the same Destination QP, the source device cannot accurately locate the Source QP based solely on the Destination QP. In this case, the Destination IP can be used to locate the Source QP causing congestion.

[0054] After identifying the corresponding Source QP, the source device reduces the transmission rate of that Source QP, thereby alleviating network congestion at the source. The timestamp is used by the source to pinpoint the time of congestion, assisting in analyzing the extent of congestion and implementing rate reduction.

[0055] To explain in detail the principle of the technical solution of the present invention, the overall process of the present invention will be described below with reference to some specific embodiments. It is easy to understand that the following is an explanation of the technical principle of the present invention and should not be regarded as a limitation of the present invention.

[0056] In view of the shortcomings of existing technologies, this invention proposes a RoCEv2 network congestion notification method and system based on IPv6. When the egress port queue length of a network device exceeds the congestion threshold, the Destination QP is obtained by offsetting the first byte of the IPv6 header in the RoCEv2 packet to the Destination QP field. Since the principle of the RoCEv2 protocol prioritizes performance, the IPv6 extended header would increase the overhead of packet processing, so it is not used in the data packet; only the basic header is used. The basic IPv6 header is 40 bytes, so the first offset is 40 bytes. The UDP header is fixed at 8 bytes, which is the second offset. The Destination QP field is located in bytes 6-8 of the IB.BTH header, and the third offset is 5 bytes, so the total offset is 40 + 8 + 5 = 53 bytes. The Destination QP length is 3 bytes; by taking 3 bytes of data after the 53-byte offset, the Destination QP can be obtained. The Destination QP, Destination IP, and the timestamp of the congestion occurrence are encapsulated in an ICMPv6 Echo request message to generate a congestion notification message, which is then sent to the sender to notify it to reduce the congestion rate.

[0057] The method of this invention is simple to implement. It does not require adding extra parameters to the RoCEv2 message or upgrading all devices on the network. It can obtain the Destination QP field, generate a congestion notification message, and directly notify the source end to reduce the speed from the point of congestion, thus having higher congestion notification efficiency.

[0058] like Figure 3 The image shown is an example of the RoCEv2 message format, specifically: RoCEv2 messages are carried by standard Ethernet frames at the link and physical layers. Their core functionality involves encapsulating InfiniBand transport units within UDP / IP packets at the network and transport layers. First, the Base Transport Header (BTH), containing information such as the Destination QP, and its data payload are included as the payload. Then, a UDP header with a fixed destination port of 4791 is added sequentially, along with a standard IP header. Finally, an Ethernet header is added, forming a complete RoCEv2 packet that can be routed in a Layer 3 IP network.

[0059] The IB Base Transport Header (BTH) field is the core of the IB protocol stack's transport layer. Its function can be summarized as: providing necessary control information for each data packet, enabling it to be correctly routed, delivered, and processed in complex networks. The BTH is 12 bytes long and contains information such as the Opcode, Destination QP, and Packet Sequence Number. The Destination QP field is the one that needs to be obtained from the message in this invention. It is located in bytes 6-8 of the BTH, and the Destination QP field in the BTH can be obtained through this offset.

[0060] like Figure 4 The image shows an example of the UDP header format. The UDP header is very concise, fixed at 8 bytes, and consists of four fields: Source Port, Destination Port, Length, and Checksum. Each field is 16 bits (2 bytes). In RoCEv2 messages, the destination port is fixed at 4791.

[0061] like Figure 5 The image shows an example of the IPv6 basic header format. The IPv6 basic header has a fixed length of 40 bytes.

[0062] like Figure 6 and Figure 7 The image shows an example of an ICMPv6 congestion notification message format, in which... Figure 6This is an example of the format for the ICMPv6 EchoRequest congestion notification message – the ICMPv6 section. Figure 7 This is an example of the format of the ICMPv6 Echo Request congestion notification message—specifically, the ICMPv6 Echo message is mainly used to detect network connectivity. This invention extends this feature by encapsulating the Destination IP (16 bytes), Destination QP (3 bytes), and the timestamp of the congestion occurrence (8 bytes) of the packet causing the congestion in the data field of the ICMPv6 Echo Request message. The Destination IP helps the source device quickly locate the Source QP causing the congestion. For example, if the same source device establishes a connection with two destination devices with different Destination IPs, and the Destination QPs of the two destination devices are the same, the source device cannot accurately locate the Source QP based on the Destination QP. In this case, the Destination IP can be used to locate the Source QP causing the congestion. The Destination QP identifies the QP causing the congestion, allowing the source device to know which Source QP is causing the congestion. The timestamp is used to locate the time when congestion occurred at the source, helping the source to analyze the degree of congestion and reduce the rate of congestion.

[0063] Furthermore, because ICMPv6 Echo Request packets have a low priority in the network, they are often dropped during network congestion. To address this, the DSCP of the Echo Request packet is set to high priority CS6 (CS6 is a dedicated channel for "network control traffic"), which means the Traffic Class field in the IPv6 header is set to 48 (110000). Devices along the route do not modify the DSCP value and directly forward this packet with high priority. When the source device receives this ICMPv6 Echo Request packet, it recognizes it as a RoCEv2 ICMPv6 Echo Request congestion notification packet based on its Traffic Class=48 and Next header=58. It then parses the Data field in the packet to obtain the Destination QP, Destination IP, and the timestamp of the congestion occurrence.

[0064] like Figure 8 The diagram shown is an example of a congestion notification process. In some specific application scenarios, the technical solution of this invention can be implemented as follows: 1. In an IPv6-based RoCEv2 network, when the length of the device's outgoing port queue exceeds the congestion threshold, it indicates that congestion is about to occur. The Destination QP is obtained by offsetting the first byte of the IPv6 header in the RoCEv2 packet to the Destination QP field. Offset 53 bytes from the first byte of the IPv6 packet to obtain the Destination QP in the RoCEv2 packet (take 3 bytes of data after 53 bytes).

[0065] 2. For devices that are about to experience congestion, encapsulate the Destination IP (16 bytes), Destination QP (3 bytes), and timestamp (8 bytes) in the data field of the ICMPv6 Echo Request message. When encapsulating the IPv6 header, set DSCP to 48 (Traffic Class=48), use the IPv6 loopback interface address of the device about to experience congestion as the source address, and use the IP address of the source device that sent the RoCEv2 data packet as the destination address. Generate a congestion notification message and send it to the sender.

[0066] 3. When an intermediate device forwards a congestion notification message, it sees that the message has Traffic Class=48 and Next header=58, and knows that it is a RoCEv2 congestion notification message. Without modifying the DSCP value, it forwards the message directly.

[0067] 4. When the sending end receives the congestion notification message, it finds that Traffic Class=48 and Next header=58, indicating that this is a RoCEv2 congestion notification message. It then parses out the Destination QP, Destination IP, and timestamp, maps the corresponding Source QP, and reduces the sending rate of the Source QP.

[0068] In summary, this method is simple and easy to implement, requiring no complex modifications. Specifically, the Destination QP can be obtained using a fixed offset from the IPv6 header length, the UDP header, and the BTH. Then, the Destination QP, Destination IP, and the timestamp of the congestion event are encapsulated in the data field of an ICMPv6 Echo request message, with the DSCP set to 48, generating a congestion notification message. Intermediate devices do not modify the DSCP value of the message and directly forward the notification message. Upon receiving the congestion notification message, the sending device parses out the Source QP and applies rate reduction.

[0069] This invention does not require adding extra parameters to RoCEv2 packets or upgrading all network equipment. It directly notifies the source end to reduce speed at the point of congestion, resulting in higher congestion notification efficiency. The method of this invention can be used for congestion notification in any RoCEv2 network to improve both congestion notification and data transmission efficiency. By combining the congestion notification method proposed in this invention, it is possible to notify the source end to reduce speed at the point of congestion without upgrading IP devices or adding extra parameters to data packets, thus reducing the probability of congestion and ensuring lossless transmission of service traffic.

[0070] like Figure 9 As shown, this embodiment of the invention also provides a network congestion notification device 900, which can implement the above-described method. This device may include: The first module 901 is used to monitor the queue length of the network device's outgoing port and trigger a congestion notification when the queue length exceeds a preset congestion threshold. The second module 902 is used to respond to congestion notification by determining the offset based on the byte length of each protocol header in the currently forwarded target data packet through the network device, and extracting the communication object field from the target data packet based on the offset. The third module 903 is used to generate congestion notification messages based on the communication object field through message encapsulation. The fourth module 904 is used to transmit congestion notification messages to the source device through the network device, so that the source device can parse the communication object field and reduce the sending rate of the target communication object based on the communication object field.

[0071] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0072] This invention also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described above. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0073] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0074] like Figure 10 As shown, Figure 10 The hardware structure of an electronic device 1000 according to another embodiment is illustrated. The electronic device 1000 includes: The processor 1001 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (aSIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present invention. The memory 1002 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RaM). The memory 1002 can store the operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1002 and is called and executed by the processor 1001. Input / output interface 1003 is used to implement information input and output; The communication interface 1004 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 1005 transmits information between various components of the device (e.g., processor 1001, memory 1002, input / output interface 1003, and communication interface 1004); The processor 1001, memory 1002, input / output interface 1003 and communication interface 1004 are connected to each other within the device via bus 1005.

[0075] The electronic device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0076] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0077] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0078] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0079] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0080] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0081] The network congestion notification method, apparatus, electronic device, storage medium, and program product provided in this invention monitor the queue length of the network device's outgoing port. When the queue length exceeds a preset congestion threshold, a congestion notification is triggered. In response to the congestion notification, the network device determines the offset based on the byte length of each protocol header in the currently forwarded target data packet, and extracts the communication object field from the target data packet based on the offset. Based on the communication object field, a congestion notification message is generated through packet encapsulation. The network device transmits the congestion notification message to the source device, so that the source device can parse the communication object field and reduce the sending rate of the target communication object based on the communication object field. The congestion detection and notification of this invention are initiated directly by the network device at the point of congestion, without the need for relaying through the receiving end. This shortens the congestion feedback path and helps to reduce congestion response latency, enabling the source device to detect and alleviate network congestion more quickly. Furthermore, this invention only needs to determine the offset based on the fixed byte length of each protocol header in the data packet. It does not require the network device to perform deep parsing of RoCEv2 private protocol fields or support specific private protocol identification capabilities. Nor does it require adding extra fields or modifying existing fields in the RoCEv2 data packet. This reduces the capability requirements of the network device and is conducive to deployment and implementation on existing network devices.

[0082] The embodiments described in this invention are for the purpose of more clearly illustrating the technical solutions of the embodiments of this invention, and do not constitute a limitation on the technical solutions provided by the embodiments of this invention. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this invention are also applicable to similar technical problems.

[0083] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present invention, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0084] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0085] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0086] The preferred embodiments of the present invention have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present invention. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and spirit of the present invention should be within the scope of the claims of the present invention.

Claims

1. A network congestion notification method, characterized in that, The method includes the following steps: The network device monitors the queue length at its outgoing port, and triggers a congestion notification when the queue length exceeds a preset congestion threshold. In response to the congestion notification, the network device determines the offset based on the byte length of each protocol header in the currently forwarded target data packet, and extracts the communication object field from the target data packet based on the offset; Based on the communication object fields, a congestion notification message is generated through message encapsulation. The network device transmits the congestion notification message to the source device, so that the source device can parse the communication object field and reduce the sending rate of the target communication object based on the communication object field.

2. The method according to claim 1, characterized in that, The method of monitoring the queue length of the network device's outgoing port and triggering a congestion notification when the queue length exceeds a preset congestion threshold includes the following steps: Based on the queue depth register / counter that is statistically analyzed in real time by the media access control layer or physical layer of the network device, the depth value corresponding to the queue length of the network device's output port is extracted. The depth value is compared with a preset congestion threshold. When the depth value is greater than the preset congestion threshold, a congestion notification is triggered. The preset congestion threshold is pre-configured based on network bandwidth and expected latency and stored in the memory of the network device.

3. The method according to claim 1, characterized in that, The step of determining the offset based on the byte length of each protocol header in the currently forwarded target data packet by the network device, and extracting the communication object field from the target data packet based on the offset, includes the following steps: Obtain the IPv6 basic header of the target data packet, and determine the first offset based on the fixed length of the IPv6 basic header; Obtain the UDP header following the IPv6 basic header in the target data packet, and determine the second offset based on the fixed length of the UDP header; Obtain the IB transport layer header following the UDP header in the target data packet; The communication object field is located in a preset byte in the IB transport layer header; The number of bytes from the beginning of the IB transport layer header to the beginning of the communication object field is used as the third offset; The first offset, the second offset, and the third offset are summed to obtain the total offset; Starting from the first byte of the target data packet, offset by the total offset, and then continuously read a preset number of bytes of data to obtain the communication object field; The preset quantity refers to the number of bytes in the field of the communication object.

4. The method according to claim 1, characterized in that, The process of generating a congestion notification message based on the communication object field through message encapsulation includes the following steps: Extract the destination IP address from the IPv6 base header of the target data packet as the target IP; The timestamp that triggers the congestion notification is determined based on the local clock of the network device. The network device generates an ICMPv6 Echo Request message as the first notification message; The target IP, the communication object field, and the timestamp are sequentially encapsulated in the Data field of the first notification message to obtain the second notification message; The configuration source address is determined based on the IPv6 loopback interface address of the network device, and the configuration destination address is determined based on the IP address of the source device corresponding to the target data packet. The congestion notification message is obtained by encapsulating the configuration IPv6 basic message header in the second notification message based on the configured source address and the configured destination address.

5. The method according to claim 4, characterized in that, The method further includes the following steps: The priority field in the configuration IPv6 basic packet header is configured with high priority to instruct devices along the route that transmit the congestion notification message to forward the congestion notification message with the highest priority. None of the devices along the route modify or remark the priority field.

6. The method according to claim 4, characterized in that, The transmission of the congestion notification message to the source device via the network device includes the following steps: The network device determines the IP address of the source device based on the configured destination address in the configured IPv6 base packet header of the congestion notification message; The local routing table is queried using the IP address of the source device to determine the next-hop forwarding interface, and the congestion notification message is sent from the forwarding interface until it is transmitted to the source device.

7. The method according to claim 1, characterized in that, The congestion notification message encapsulates the communication object field and the target IP address corresponding to the destination IP address of the target data packet. The source device parses the communication object field and reduces the transmission rate of the target communication object based on the communication object field, including the following steps: The source device parses the congestion notification message to obtain the target IP and the communication object fields. Using the target IP and the communication object field as a combined index, the local communication object associated with the remote communication object corresponding to the target IP and the communication object field is matched in the preset communication object mapping table and used as the target communication object; The communication object mapping table records the association between each remote communication object and the local communication object. The communication object mapping table also records the IP address and fields of each remote communication object and the local communication object. The source device performs a speed-down operation on the target communication object to reduce the transmission rate of the target communication object.

8. A network congestion notification device, characterized in that, The apparatus, applicable to the method of any one of claims 1 to 7, comprises: The first module is used to monitor the queue length of the network device's outgoing port, and trigger a congestion notification when the queue length exceeds a preset congestion threshold. The second module is used to respond to the congestion notification by having the network device determine the offset based on the byte length of each protocol header in the currently forwarded target data packet, and extract the communication object field from the target data packet based on the offset. The third module is used to generate a congestion notification message based on the communication object field through message encapsulation; The fourth module is used to transmit the congestion notification message to the source device through the network device, so that the source device can parse the communication object field and reduce the sending rate of the target communication object based on the communication object field.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 7.

Images