Message sending method, electronic device, storage medium and program product

Abstract

The application discloses a message sending method, an electronic device, a storage medium and a program product, and belongs to the technical field of Internet. The message sending method is applied to a forwarding device and includes the following steps: in response to the fact that the egress of a cache queue is congested, a notification message indicating the congestion is generated, wherein the outer source four-layer port number of a virtual extensible local area network (VXLAN) encapsulation message in the cache queue is carried in the notification message; and the notification message is sent to a target tunnel endpoint device, wherein the notification message is used to instruct the target tunnel endpoint device to send a congestion notification message to a source end server of a target flow corresponding to the VXLAN encapsulation message, and the target tunnel endpoint device is a tunnel endpoint device corresponding to the outer source address of the VXLAN encapsulation message.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a message sending method, electronic device, storage medium, and program product. Background Technology

[0002] As data center networks expand in scale, Virtual eXtensible Local Area Networks (VxLANs) are increasingly being deployed. VxLAN technology is used to extend network virtualization to obtain a sufficient number of virtual networks to meet user needs.

[0003] However, in VxLAN networks, the underlay forwarding devices do not have overlay routing tables and are unaware of overlay forwarding information. Therefore, they cannot generate Fast Congestion Notification (CNP) messages, which leads to the inability to perform congestion control quickly in VxLAN networks. Summary of the Invention

[0004] This application provides a message sending method, electronic device, storage medium, and program product that can achieve fast congestion control on VxLAN networks.

[0005] In a first aspect, a message sending method is provided, applied to a forwarding device, comprising: generating a congestion notification message in response to congestion occurring at the exit of a buffer queue, wherein the notification message carries the outer source Layer 4 port number of a Virtual Scalable Local Area Network (VScalable LAN) Encapsulated Message in the buffer queue; and sending the notification message to a target tunnel endpoint device, wherein the notification message instructs the target tunnel endpoint device to send a congestion notification message to the source server of the target flow corresponding to the VScalable LAN Encapsulated Message, and the target tunnel endpoint device is the tunnel endpoint device corresponding to the outer source address of the VScalable LAN Encapsulated Message.

[0006] Secondly, a congestion notification message sending method is provided, applied to a tunnel endpoint device, comprising: in response to receiving a notification message indicating that a target transmission tunnel is congested, determining, based on the target outer source Layer 4 port number carried in the notification message, the flow information of a target flow matching the target outer source Layer 4 port number, wherein the target transmission tunnel is a tunnel transmitting the target flow; generating a congestion notification message based on the flow information of the target flow; and sending the congestion notification message to the source server corresponding to the target flow.

[0007] Thirdly, an electronic device is provided, the electronic device including a processor and a memory, the memory storing a program or instructions executable on the processor, the program or instructions, when executed by the processor, implementing the steps of the method described in the first or second aspect above.

[0008] Fourthly, a readable storage medium is provided, on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first or second aspect above.

[0009] Fifthly, a computer program product is provided, the computer program product comprising a computer program stored on a non-transitory computer-readable storage medium, the computer program comprising program instructions that, when executed by a computer, cause the computer to perform the steps of the method described in the first or second aspect above.

[0010] In this embodiment of the application, when congestion occurs at the exit of the cache queue, the forwarding device can generate and send a congestion notification message to the target tunnel endpoint device. The notification message carries the outer source Layer 4 port number of the VxLAN encapsulated message in the cache queue. The notification message is used to instruct the target tunnel endpoint device to send a congestion notification message (CNP) to the source server of the target flow corresponding to the Virtual Extensible LAN encapsulated message, thereby enabling fast congestion control on the VxLAN network.

[0011] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

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

[0013] Figure 1 A schematic diagram of the RoCE message structure transmitted based on RoCE technology; Figure 2 A flowchart illustrating an exemplary embodiment of this application provides a message transmission method; Figure 3 This illustration shows a schematic diagram of the structure of a VxLAN encapsulated message in an exemplary embodiment of this application; Figure 4 A flowchart illustrating the generation of a congestion notification message in an exemplary embodiment of this application is shown; Figure 5 A flowchart illustrating the generation of a congestion notification message in another exemplary embodiment of this application is shown; Figure 6A flowchart illustrating a congestion notification message sending method provided in an exemplary embodiment of this application is shown. Figure 7 A flowchart of a congestion notification message sending method provided in another exemplary embodiment of this application is shown; Figure 8 A flowchart of a congestion notification message sending method provided in yet another exemplary embodiment of this application is shown; Figure 9 A schematic diagram of a networking scenario in an exemplary embodiment of this application is shown; Figure 10 This invention illustrates a flowchart of a forwarding device generating and sending a notification message according to an exemplary embodiment of this application; Figure 11 This application illustrates a flowchart of a VTEP device generating and sending CNP messages according to an exemplary embodiment of the present application; Figure 12 This is a structural block diagram of an electronic device according to an exemplary embodiment. Detailed Implementation

[0014] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0015] With the continuous evolution of network technology in recent years, emerging technologies, such as AI-Generated Content (AIGC), are placing increasing demands on networks. To reduce network transmission latency and improve network throughput within data centers, RoCE (RDMA overconverged Ethernet), based on remote direct memory access (RDMA), has been widely deployed in Ethernet data center networks (DCNs). However, during RDMA transmission, even the loss of a single data packet can significantly reduce network throughput, substantially increasing stream completion time and severely impairing application service performance. Figure 1 This is a schematic diagram of the RoCE message structure transmitted based on RoCE technology.

[0016] To ensure efficient and reliable RDMA data transmission, priority-based flow control (PFC) mechanisms are widely deployed in data center Ethernet networks to prevent buffer overflows. PFC is a port-based hop-by-hop flow control mechanism. When the length of the inbound port queue on a switch exceeds the PFC pause threshold, a PFC pause message is sent to the upstream switch, suspending data transmission on the relevant outbound ports of the upstream switch. When the length of the inbound port queue decreases to below the PFC recovery threshold, a PFC recovery message is sent to the upstream port, resuming its data transmission.

[0017] However, the aforementioned port-based PFC pause / resume mechanism is highly susceptible to problems such as head-of-line congestion, congestion propagation, and deadlock. Specifically, when a switch's output port is paused by PFC, packets destined for other uncongested output ports will also be blocked. More seriously, when a switch in the network experiences persistent congestion, the hop-by-hop PFC flow control mechanism will eventually cause upstream switches unrelated to the congestion to receive PFC pause signals and suspend packet forwarding, resulting in increased packet queuing delays, decreased network throughput, and significantly increased flow completion time.

[0018] To address the aforementioned issues, Data Center Quantized Congestion Notification (DCQCN) for flow-level end-to-end transport protocols was proposed to alleviate network congestion and reduce the number of PFC triggers. However, according to the implementation principle of DCQCN, the Congestion Notification Packet (CNP) is generated by the destination network interface card (NIC) after receiving a data packet carrying an Explicit Congestion Notification (ECN) tag. The CNP packet format also conforms to the definition of the Remote Direct Memory Access over Converged Ethernet (RoCE) packet format, with only some field differences. Based on the above principle, the inventors discovered that congestion points occur at switch nodes in the packet transmission path, but the device that reports congestion is the destination server at the tail of the network. An excessively long congestion feedback path prevents the source server's traffic from being reduced in a timely manner, potentially leading to further congestion in the forwarding device's buffer, and even causing the entire network to suspend traffic transmission due to PFC flow control.

[0019] Fast CNP, or FAST CNP congestion notification scheme, can effectively solve the above problems. After enabling the Fast CNP congestion notification function on the forwarding device, the forwarding device will record the information of the packet in the flow table entry when forwarding the packet. When it receives a packet carrying the ECN congestion flag in the future, it will send a CNP congestion notification packet to the source server based on the learned flow table entry information, which shortens the congestion feedback path, thereby adjusting the flow rate of the source server in a timely manner and alleviating the congestion in the forwarding device's cache.

[0020] As data center networks expand in scale, VxLAN is gradually being deployed. VxLAN technology is used to extend network virtualization to obtain a sufficient number of virtual networks to meet user needs.

[0021] A VxLAN network consists of two roles: VxLAN Tunnel End Point (VTEP) devices and underlay forwarding devices. VTEP devices are responsible for encapsulating raw user packets with VxLAN headers and decapsulating them. VTEP devices form VxLAN tunnels. The source Internet Protocol (IP) address of a VxLAN tunnel packet is the IP address of the local VTEP device, and the destination IP address is the IP address of the remote VTEP device. The source port number is not fixed; typically, each flow is assigned a port number, while the destination port number is usually a fixed value. Underlay forwarding devices are responsible for the connection and forwarding between VTEP devices. VTEP devices maintain both an overlay routing table and an underlay routing table, while underlay forwarding devices only have an underlay routing table.

[0022] VxLAN networks also suffer from congestion issues, and network congestion control technologies need to be applied to them. It is generally believed that PFC can support VxLAN networks, and after resolving the consistency issue of ECN inner and outer layer labels through ECN label mapping, DCQCN can also be deployed in VxLAN networks. However, for devices to use the fast CNP function and generate CNP packets, they need to obtain information such as source IP, destination IP, and queue pairs (QPs) based on user ROCE session traffic, establish ROCE session entries, and then generate CNP packets based on these entries.

[0023] However, in VxLAN networks, underlay forwarding devices do not have overlay routing tables and are unaware of overlay forwarding information. They cannot directly obtain information such as IP and QP within VxLAN encapsulated packets, and cannot establish and maintain user session entries based on VxLAN encapsulated traffic. Therefore, CNP packets cannot be generated in the traditional way.

[0024] In summary, how to apply Fast CNP in VxLAN networks when underlay forwarding devices cannot perceive and obtain VxLAN inner encapsulation information has become an urgent technical problem to be solved.

[0025] Figure 2 A flowchart illustrating a message transmission method provided in an exemplary embodiment of this application is shown. This method can be executed by a forwarding device, which can be an underlay forwarding device in a VxLAN network. Figure 2 As shown, the message sending method mainly includes the following steps.

[0026] S210, in response to congestion at the exit of the buffer queue, generates a congestion notification message.

[0027] In this embodiment, the announcement message carries the outer source Layer 4 port number of the VxLAN encapsulated message in the buffer queue of the forwarding device. For example, after traffic congestion occurs at the VxLAN underlay forwarding node, an announcement message without VxLAN encapsulation can be generated using the message information in the queue buffer. The announcement message carries the outer source Layer 4 port number.

[0028] In this embodiment of the application, the above-mentioned notification message can be a message improved based on the CNP message, or it can be other types of messages, as long as the message carries the above-mentioned outer source layer 4 port number and is sent to the above-mentioned target tunnel endpoint device. The specific format is not limited in this embodiment of the application.

[0029] In addition, in this embodiment of the application, the forwarding device can obtain the outer source address and outer source Layer 4 port number of the VxLAN encapsulated packet by means of fixed offset matching of access control list (ACL) or chip register reading, and the specific acquisition method is not limited in this embodiment of the application.

[0030] S212, send the above notification message to the target tunnel endpoint device.

[0031] The notification message is used to instruct the target tunnel endpoint device to send a congestion notification message to the source server of the target flow corresponding to the aforementioned Virtual Scalable Local Area Network (VLAN) encapsulated message. The target tunnel endpoint device is the tunnel endpoint device corresponding to the outer source address of the VLAN encapsulated message.

[0032] In this embodiment of the application, by sending the above-mentioned notification message to the target tunnel endpoint device, the target tunnel endpoint device can determine the flow information of the target flow that matches the target outer source layer 4 port number based on the target outer source layer 4 port number carried in the notification message, generate a congestion notification message based on the flow information of the target flow, and send the congestion notification message to the source server of the target flow corresponding to the above-mentioned VxLAN encapsulated message to achieve congestion control.

[0033] Figure 3 A schematic diagram of a VxLAN-encapsulated message structure is shown, as follows: Figure 3 As shown, the forwarding device obtains the outer source Layer 4 port number and outer source IP address through the outer Medium Access Control (MAC) packet header and outer IP packet header encapsulated in the VxLAN encapsulated packet. Therefore, when congestion occurs, the forwarding device can generate an announcement packet carrying the obtained outer source Layer 4 port number and send the announcement packet to the tunnel endpoint device corresponding to the outer source IP address. In other words, the destination address of the announcement packet is the outer source address of the VxLAN encapsulated packet.

[0034] In this embodiment, the tunnel endpoint device is used to encapsulate the original packet with a VxLAN header to obtain a VxLAN encapsulation, and to encapsulate the packet with VxLAN to obtain the original packet. This tunnel endpoint device can be a VTEP device in a VxLAN network.

[0035] Through the technical solutions provided in the embodiments of this application, when congestion occurs at the exit of the cache queue, the forwarding device can generate and send a congestion notification message to the target tunnel endpoint device. The notification message carries the outer source layer 4 port number of the VxLAN encapsulated packet in the cache queue, thereby enabling the target tunnel endpoint device to send a congestion notification message (CNP) to the source server of the target flow corresponding to the outer source layer 4 port number, thereby achieving congestion control and avoiding packet loss due to untimely traffic reduction after VxLAN forwarding device congestion.

[0036] In some embodiments, congestion at the exit of a cache queue can be determined based on a target parameter corresponding to the cache queue and used to indicate the congestion process of the cache queue. In these embodiments, the method may include: determining that congestion has occurred at the exit of the cache queue in response to the target parameter corresponding to the cache queue exceeding a preset threshold, wherein the target parameter indicates the degree of congestion of the cache queue. In these embodiments, a preset threshold can be set, and congestion at the exit of the cache queue can be determined when the target parameter corresponding to the cache queue exceeds the preset threshold. The preset threshold may correspond to a certain degree of congestion in the cache queue; that is, congestion at the exit of the cache queue is determined when the congestion degree indicated by the target parameter exceeds a preset congestion degree. The preset threshold can be a rational number greater than or equal to 0. When the preset threshold is 0, it indicates only a slight degree of congestion, and the cache queue is determined to be congested.

[0037] In some embodiments, generating a congestion notification message may include the following steps: Step 1: Determine the target number of the notification messages based on the target parameters corresponding to the cache queue, wherein the target parameters are used to indicate the congestion level of the cache queue, and the target number is proportional to the congestion level indicated by the target parameters; Step 2: Generate the target number of notification messages.

[0038] In these embodiments, the more severe the congestion level indicated by the target parameters, the more notification messages are generated, thereby indicating the congestion situation to the target tunnel endpoint device through the number of notification messages.

[0039] In some embodiments, the target parameters may include at least one of the depth of the cache queue and the probability that VLANs encapsulated in the cache queue are marked with an explicit congestion notification tag. For example, congestion at the exit of the cache queue is determined if either the depth of the cache queue exceeds a first threshold or the probability that VLANs encapsulated in the cache queue are marked with an explicit congestion notification tag is greater than a second threshold. Alternatively, the target number of announcement messages generated may be determined based on at least one of the depth of the cache queue and the probability that VLANs encapsulated in the cache queue are marked with an explicit congestion notification tag.

[0040] For example, in some embodiments, the depth of the cache queue can be used to determine whether congestion occurs at the exit of the cache queue. In these embodiments, the method may further include: determining that congestion occurs at the exit of the cache queue in response to the depth of the cache queue exceeding a first threshold.

[0041] The depth of the buffer queue indicates the number of VxLAN encapsulated packets waiting in the buffer queue. The more VxLAN encapsulated packets waiting in the buffer queue, the deeper the buffer queue.

[0042] In this embodiment, a first threshold can be set. When the depth of the cache queue exceeds the first threshold, the forwarding device determines that the exit of the cache queue is congested and congestion control is required, thereby triggering the above-mentioned S210. The first threshold can be an integer greater than 0, and the specific value can be determined according to the actual application. This embodiment does not limit this value.

[0043] In addition, in this embodiment of the application, the exit of the forwarding device's cache queue can be periodically determined based on the depth of the cache queue to determine whether congestion occurs.

[0044] Through the above embodiments, it is possible to determine whether the exit of the forwarding device's cache queue is congested based on the depth of the cache queue, thereby improving the accuracy of congestion judgment.

[0045] In some embodiments, such as Figure 4 As shown, generating a congestion notification message may include the following steps: S401, Based on the depth of the cache queue, determine the target number of the above-mentioned notification messages, wherein the target number is proportional to the depth of the cache queue; In other words, the deeper the cache queue, the more announcement messages are generated.

[0046] S402, generate the target number of notification messages.

[0047] In the above embodiments, the number of announcement messages generated can be determined based on the depth of the cache queue, that is, the number of announcement messages generated within a fixed time period. Alternatively, the frequency of generating the announcement messages can be determined based on the depth of the cache queue. The deeper the cache queue, the higher the frequency of generating announcement messages. Thus, the congestion situation can be reflected by the number of announcement messages.

[0048] For example, in other embodiments, the probability that VxLAN encapsulated packets in the buffer queue are marked with an explicit Congestion Notification (ECN) can be used to determine whether congestion occurs at the egress of the buffer queue. Therefore, in these embodiments, the method may further include the following steps: Step 1: Obtain the probability that a VxLAN encapsulated packet in the buffer queue is marked with an explicit congestion notification.

[0049] In these embodiments, the probability of a VxLAN-encapsulated packet in the buffer queue being marked with an explicit congestion notification flag can be obtained. For example, a lower limit and an upper limit for the queue length can be preset. When adding a congestion flag to a VxLAN-encapsulated packet in the buffer queue, if the current length of the buffer queue is lower than the lower limit, no congestion flag will be added to the VxLAN-encapsulated packet (probability is 0). When the current length of the buffer queue is between the lower and upper limits, a congestion flag is added to the packet based on the correspondence between the marking probability and the length of the buffer queue. Specifically, as the length of the buffer queue increases, the probability of adding a congestion flag also increases (up to Pmax). When the current length of the buffer queue is higher than the upper limit, a congestion flag is added to every VxLAN-encapsulated packet in the buffer queue (the marking probability jumps from Pmax to 1).

[0050] By determining the probability that a VxLAN-encapsulated packet in the cache queue is marked with an explicit congestion notification tag, the proportion of VxLAN-encapsulated packets marked with a congestion notification tag in the cache queue can be determined. For example, assuming that the probability of a VxLAN-encapsulated packet in the cache queue being marked with an explicit congestion notification tag is 20%, then 20% of the VxLAN-encapsulated packets in the cache queue are marked with an explicit congestion notification tag.

[0051] Step 2: In response to the probability of being marked as an explicit congestion notification being greater than a second threshold, determine that the exit of the cache queue is congested.

[0052] Through the above embodiments, it is possible to determine whether the buffer queue is congested based on whether the probability of a packet in the buffer queue being marked with an ECN tag is greater than a second threshold (i.e., the ECN marking condition is met). The second threshold is a rational number greater than or equal to 0, and its specific value can be determined according to the actual application. When the probability of a packet in the buffer queue being marked with an ECN tag is greater than the second threshold, it is determined that the buffer queue is congested, and the aforementioned notification is generated, thereby improving the accuracy of congestion judgment.

[0053] In some embodiments, such as Figure 5 As shown, generating a congestion notification message may include the following steps: S501, Based on the probability of being marked as an explicit congestion notification, determine the target number of the generated notification messages, wherein the target number is proportional to the probability of being marked as an explicit congestion notification; In other words, the greater the probability of being marked with an explicit congestion notification, the greater the number of target notification messages generated. S502, generate the target number of notification messages.

[0054] In the above embodiments, the target number of the above-mentioned announcement messages can be determined based on the probability that VxLAN encapsulated packets in the cache queue are marked with ECN, that is, the number of announcement messages generated within a fixed time period. Alternatively, the frequency of generating the above-mentioned announcement messages can be determined based on the probability that VxLAN encapsulated packets in the cache queue are marked with ECN. The higher the probability, the higher the frequency of generating announcement messages. Thus, the congestion situation can be reflected by the number of announcement messages.

[0055] In some other embodiments, S210 may also include: in response to congestion at the exit of the cache queue, generating a predetermined number of notification messages within each aggregation time period, according to a set aggregation time period. In these embodiments, a predetermined number of notification messages may be generated within each aggregation time period, wherein the predetermined number may be one or more, and the specific number may be determined according to the actual application.

[0056] In the above embodiments, the aggregation time can be automatically and dynamically adjusted based on the deep learning model, and the specific implementation of this application is not limited thereto.

[0057] In some embodiments, the notification message may also carry egress congestion information of the forwarding device. This egress congestion information instructs the target tunnel endpoint device to determine the rate at which to generate the congestion notification message. For example, the egress congestion information may include at least one of a cache queue identifier, cache queue depth, and congestion level. After receiving the notification message, the tunnel endpoint device can generate CNP messages at the corresponding rate based on the target flow and the egress congestion information. However, this is not a limitation. The notification message may also not carry the egress congestion information. The forwarding device can generate a corresponding number and rate of notification messages based on the congestion information, and the notification messages do not need to carry congestion information. The tunnel endpoint device only needs to generate CNP messages based on the number of notification messages and the matched flow, without needing to be aware of congestion information. Alternatively, the forwarding device may send a fixed number of notification messages at fixed intervals. These notification messages may also carry congestion information, and the tunnel endpoint device can reconstruct the number and rate of CNP messages that should be sent based on the congestion information in the notification messages.

[0058] With the above-described solution provided in the embodiments of this application, when congestion occurs, the forwarding device can send a notification message to the upstream tunnel site device, which can trigger the tunnel endpoint device to send a CNP message to the source server of the target flow corresponding to the VxLAN encapsulated message. This allows the source server to reduce the transmission speed of the target flow in a timely manner, thereby improving network performance and quality and enhancing the user experience.

[0059] Figure 6A flowchart illustrating a congestion notification message sending method according to an exemplary embodiment of this application is shown, which can be performed by a tunnel endpoint device. Figure 6 As shown, the congestion notification message sending method mainly includes the following steps.

[0060] S610, in response to receiving a notification message indicating that the target transmission tunnel is congested, the flow information of the target flow that matches the target outer source layer 4 port number is determined according to the target outer source layer 4 port number carried in the notification message, wherein the target transmission tunnel is a tunnel for transmitting the target flow.

[0061] Among them, the forwarding device can be according to Figure 2 The method shown above is used to send the above notification message. For details, please refer to [link / reference]. Figure 2 The descriptions of the various embodiments of the method shown will not be repeated here.

[0062] The tunnel endpoint device in this application embodiment can be a VTEP device in a VxLAN network.

[0063] S612 generates a congestion notification message based on the flow information of the target flow that matches the target outer layer source layer 4 port number.

[0064] In this embodiment of the application, when the tunnel endpoint device encapsulates the original data stream using VxLAN, one data stream can correspond to one outer source Layer 4 port number. Therefore, after receiving the notification message, the tunnel endpoint device can determine the target stream corresponding to the target outer source Layer 4 port number based on the target outer source Layer 4 port number carried in the notification message, and then generate a CNP message based on the flow information of the target stream.

[0065] In the application embodiment, the flow information of the target flow may include information such as the source IP, destination IP and target QP of the target flow. Based on the flow information of the target flow, the tunnel endpoint device can generate a CNP packet.

[0066] S614, send a congestion notification message to the source server corresponding to the target flow.

[0067] According to the technical solution provided in this application, after receiving the notification message sent by the forwarding device, the tunnel endpoint device generates a CNP message based on the flow information of the target flow that matches the target outer source layer 4 port number carried in the notification message, and sends the CNP message to the source server of the target flow. Thus, the source server can limit the flow of the target flow and achieve congestion control of the target flow.

[0068] In some embodiments, the tunnel endpoint device may store a mapping relationship for recording the outer source Layer 4 port number and the flow information of the data stream. Therefore, in these embodiments, such as Figure 7As shown, S612 may include the following steps: S6121, based on the mapping relationship between the outer source layer 4 port number and the data stream flow information, obtain the flow information of the target flow corresponding to the target outer source layer 4 port number, wherein the data stream includes the target flow.

[0069] For example, the tunnel endpoint device can store session entries. Each entry in the session entry can record the mapping relationship between the flow information of a data stream and the outer source Layer 4 port number of the corresponding Virtual Scalable Local Area Network (VSPA) encapsulated message. After receiving the notification message indicating that the target transmission tunnel is congested, the tunnel endpoint device retrieves the target entry that matches the target outer source Layer 4 port number from the session entry based on the target outer source Layer 4 port number carried in the notification message, and retrieves the flow information of the target stream from the target entry.

[0070] Through these embodiments, the tunnel endpoint device maintains a mapping relationship between the flow information of the data flow and the outer source Layer 4 port number locally. This allows it to obtain the flow information of the target flow corresponding to the target outer Layer 4 port number carried in the announcement message when it receives the announcement message, thereby improving the convenience of obtaining the flow information of the target flow.

[0071] Of course, this is not the only option. In practical applications, tunnel endpoint devices can also use other methods besides session entries to store the correspondence between the outer layer 4 port number and the flow information of the target flow. For example, a tunnel endpoint device can store two tables: one table stores the correspondence between the outer layer 4 port number and the identifier of the data flow, and the other table stores the identifier of each data flow and the flow information of that data flow.

[0072] In some embodiments, the tunnel endpoint device may record the mapping relationship between the flow information of the target flow and the target outer source Layer 4 port number of the target VxLAN encapsulated packet before or after VxLAN encapsulation of the target flow. In these embodiments, such as... Figure 8 As shown, prior to S610, the method may further include the following steps: S606, The received target stream is encapsulated in a virtual scalable LAN and the encapsulated target stream is sent through the aforementioned target transmission tunnel; That is, to transmit target virtual scalable local area network encapsulated messages through the target transmission tunnel.

[0073] Before performing VxLAN encapsulation on the received target stream, the tunnel endpoint device can first determine the target outer layer 4 port number and the target outer layer source address, i.e., the address of the tunnel endpoint device, and then perform VxLAN encapsulation on the target stream.

[0074] S608, the correspondence between the flow information of the target flow and the target outer source layer 4 port number encapsulated by the target flow is recorded in the above mapping relationship.

[0075] In these embodiments, when the tunnel endpoint device receiving the target flow performs VxLAN encapsulation on the target flow, it records and maintains the mapping relationship between the flow information of the target flow and the target outer source Layer 4 port number of the target flow encapsulation. The flow information of the target flow includes the necessary information for generating a CNP, specifically including but not limited to the source IP, destination IP, and destination QP of the target flow. The flow information of a data flow can be uniquely matched through the outer source Layer 4 port number.

[0076] In the above embodiments, the VTEP device can record the above mapping relationship through ROCE session entries. The method for generating and maintaining ROCE session entries can be based on ACL rule matching or hardware-based flow learning. The mapping relationship between the outer source layer 4 port number of VxLAN encapsulation and the flow can be automatically generated based on flow hash, or pre-allocated by the network management controller based on the flow information on the server side. The specific method is not limited in the embodiments of this application.

[0077] Optionally, the above data stream can be a RoCE stream.

[0078] In some embodiments, the notification message may also carry egress congestion information of the forwarding device. In S412, the tunnel endpoint device can determine the rate at which to generate CNP messages based on the egress congestion information, and then generate CNP messages at that rate. Optionally, the egress congestion information may include, but is not limited to, the congested cache queue ID, the depth of the cache queue, and the degree of congestion.

[0079] Of course, the notification message may not include the aforementioned outbound congestion information. For example, the forwarding device can generate a corresponding number and rate of notification messages based on the outbound congestion information, and the VTEP device can generate CNP messages based on the number of received notification messages and the matched flow.

[0080] The following is based on Figure 9 Taking the network scenario shown as an example, the technical solution provided in the embodiments of this application will be described.

[0081] In this embodiment, the VTEP device in the VxLAN network maintains ROCE session information. This session information includes overlay flow information and the mapping relationship between the outer source Layer 4 port number (after the flow is encapsulated with VxLAN) and the flow. Furthermore, after congestion occurs at the underlay forwarding device, it announces the outer source Layer 4 port number and other information of the packets in the congestion queue to the upstream VTEP device. Based on the received outer source port number information, the upstream VTEP device searches its local ROCE session information, generates a CNP packet based on the matching flow, and then forwards it to the source server through the overlay routing table.

[0082] exist Figure 9 In this process, the original ROCE traffic sent by server 1 passes through VTEP1, forwarding device 1, forwarding device 2, forwarding device 3, and VTEP2, and is finally forwarded to server 2. When VTEP1 encapsulates the original ROCE traffic using VxLAN, it records and maintains ROCE session entries. These ROCE session entries contain the mapping relationship between the original ROCE flow information and the source Layer 4 port number in the outer VxLAN header. The original ROCE flow information includes the source IP, destination IP, destination QP, and other information required to generate a CNP.

[0083] During the original ROCE traffic forwarding process, for underlay forwarding devices in the network, after congestion occurs at the egress of the buffer queue, a decision can be made based on pre-set judgment rules to determine whether to generate an advertisement message. If an advertisement message needs to be generated, the outer source IP (Outer SIP) and outer source Layer 4 port number (Outer Src L4 Port) of the VxLAN encapsulated message cached in the congestion queue are extracted, and combined with the egress congestion information of the buffer queue, a first advertisement message is generated. The destination address of the advertisement message is the extracted outer source IP. The forwarding device forwards the generated advertisement message to the upstream VTEP device performing VxLAN encapsulation according to its local routing table. Figure 10 A flowchart illustrating the process of a forwarding device generating and sending an announcement message is shown, such as... Figure 10 As shown, the process of generating and sending a notification message by a forwarding device mainly includes the following steps: S1001, the exit of the buffer queue of the forwarding device is congested.

[0084] S1002, the outer source IP and outer source Layer 4 port number of the VxLAN encapsulated packet cached in the congestion queue of the forwarding device.

[0085] S1003, the forwarding device obtains the exit congestion information of the cache queue.

[0086] The outbound congestion information may include information such as the identifier of the congested buffer queue, the depth of the buffer queue, and the congestion procedure.

[0087] This step is optional.

[0088] S1004, the forwarding device generates an announcement message, which may carry the aforementioned outer source layer 4 port number and outgoing congestion information.

[0089] S1005, the forwarding device forwards the advertisement message to the VTEP device that performs VxLAN encapsulation according to the local routing table, that is, the VTEP device corresponding to the outer source address of the VxLAN encapsulated message.

[0090] For example, Figure 9 Congestion occurred on forwarding device 2. Upon detecting congestion in the egress queue buffer, forwarding device 2 retrieved the outer source IP (Outer SIP) and outer source Layer 4 port (Outer Src L4 Port) of the VxLAN encapsulated packets cached in the congestion queue. Combining this with the queue congestion information, it generated an advertisement message. The destination address of the advertisement message was the extracted outer source IP. Further, forwarding device 2 forwarded the generated advertisement message to the upstream VTEP1 device performing the VxLAN encapsulation, according to its local routing table.

[0091] The VTEP device receives an advertisement message from the underlay forwarding device. Based on the outer source Layer 4 port number information in the advertisement message, it searches its local ROCE session table for a matching entry. Each source Layer 4 port number in the ROCE session table corresponds one-to-one with a ROCE flow, allowing for a unique match and identification of an entry. Based on the matched entry, a complete CNP message is generated. Furthermore, the VTEP device can determine the CNP message generation rate based on the congestion information carried in the advertisement message; higher congestion levels result in a higher CNP generation rate. The VTEP device then forwards the generated CNP message to the source server via its local overlay routing table. The source server then applies the DCQCN algorithm to reduce the traffic flow.

[0092] Figure 11 The flowchart illustrating the generation and transmission of CNP messages by the VTEP device is shown, as follows: Figure 11 As shown, the VTEP device generates and sends CNP messages, mainly including the following steps: S1101, the VTEP device receives an announcement message sent by the underlay forwarding device.

[0093] Among them, the underlay forwarding device can be configured according to Figure 10 The process shown sends this notification message; for details, please refer to the above information regarding... Figure 10 Related descriptions.

[0094] S1102, VTEP searches for a matching entry in the local ROCE session table based on the outer source layer 4 port number in the announcement message.

[0095] S1103, Based on the matched flow information, generate a CNP message.

[0096] S1104 forwards CNP packets to the source server via the local overlay routing table entry.

[0097] For example, Figure 9 After receiving the announcement message sent by the aforementioned forwarding device 1, the VTEP1 device searches for a matching entry in its local ROCE session table based on the outer source Layer 4 port number in the announcement message. Based on the flow information in the matching entry, it generates a complete CNP message. Furthermore, the VTEP1 device can determine the rate at which it generates the CNP message based on the congestion information carried in the announcement message; the higher the congestion level, the faster the CNP message is generated. The VTEP1 device forwards the generated CNP message to server 1 through its local overlay routing table. Server 1 then reduces the traffic flow according to the DCQCN algorithm.

[0098] The technical solutions provided in this application embodiment allow for simple modifications to VxLAN forwarding devices and VTEP devices, enabling fast CNP on the VxLAN forwarding device. This avoids the problem of delayed speed reduction due to long congestion feedback paths caused by sending CNP packets through the destination server. Applying this method also reduces the network bandwidth consumption of CNP packets, improving network performance, network quality, and user experience.

[0099] Figure 12 A structural block diagram of an electronic device 1200 illustrating an exemplary embodiment of this application is shown. This electronic device can be implemented as a cloud terminal management platform or a cloud server with cloud terminals as described above in this application. The electronic device 1200 includes a Central Processing Unit (CPU) 1201, a system memory 1204 including Random Access Memory (RAM) 1202 and Read-Only Memory (ROM) 1203, and a system bus 1205 connecting the system memory 1204 and the CPU 1201. The electronic device 1200 also includes a large-capacity storage device 1206 for storing an operating system 1209, application programs 1210, and other program modules 1211.

[0100] Without loss of generality, the computer-readable medium may include computer storage media and communication media. Computer storage media include volatile and non-volatile, removable and non-removable media implemented using any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media include RAM, ROM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other solid-state storage technologies, CD-ROM, digital versatile disc (DVD) or other optical storage, magnetic tape cassettes, magnetic tape, disk storage, or other magnetic storage devices. Of course, those skilled in the art will recognize that the computer storage media are not limited to the above-mentioned types. The system memory 1204 and mass storage device 1206 described above can be collectively referred to as memory.

[0101] According to various embodiments of this disclosure, the electronic device 1200 can also be connected to a remote computer on a network, such as the Internet. That is, the electronic device 1200 can be connected to a network 1208 via a network interface unit 1207 connected to the system bus 1205, or it can use the network interface unit 1207 to connect to other types of networks or remote computer systems (not shown).

[0102] The memory further includes at least one instruction, at least one program, code set, or instruction set, which are stored in the memory. The central processing unit 1201 executes the at least one instruction, at least one program, code set, or instruction set to implement all or part of the steps in the message sending method shown in the above embodiments, or to implement all or part of the steps in the congestion notification message sending method shown in the above embodiments.

[0103] Those skilled in the art will understand that Figure 12 The structure shown does not constitute a limitation on the electronic device 1200, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0104] In one exemplary embodiment, a readable storage medium is also provided, which stores at least one computer program. This computer program is loaded and executed by a processor to implement all or part of the steps in the above-described message transmission method, or to implement all or part of the steps in the above-described congestion notification message transmission method, and has the same technical effects, which will not be elaborated further here. For example, the readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, and optical data storage device, etc.

[0105] In one exemplary embodiment, a computer program product is also provided, comprising a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions that, when executed by a computer, perform all or part of the steps in the above-described message transmission method, or perform all or part of the steps in the above-described congestion notification message transmission method, and have the same technical effects, which will not be elaborated further here.

[0106] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0107] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A message transmission method, applied to a forwarding device, comprising: In response to congestion at the exit of the cache queue, a congestion notification message is generated, wherein the notification message carries the outer source Layer 4 port number of the Virtual Extensible LAN Encapsulated Message in the cache queue. Send the notification message to the target tunnel endpoint device, wherein the notification message is used to instruct the target tunnel endpoint device to send a congestion notification message to the source server of the target flow corresponding to the VLAN encapsulated message, and the target tunnel endpoint device is the tunnel endpoint device corresponding to the outer source address of the VLAN encapsulated message.

2. The method according to claim 1, characterized in that, The method further includes: In response to the target parameter corresponding to the cache queue exceeding a preset threshold, it is determined that the exit of the cache queue is congested, wherein the target parameter is used to indicate the degree of congestion of the cache queue.

3. The method according to claim 1, characterized in that, The generation of the congestion notification message includes: Based on the target parameters corresponding to the cache queue, the target number of the notification messages is determined, wherein the target parameters are used to indicate the congestion level of the cache queue, and the target number is proportional to the congestion level indicated by the target parameters; Generate the target number of notification messages.

4. The method according to claim 2 or 3, characterized in that, The target parameter includes at least one of the following: The depth of the cache queue; The probability that a Virtual Scalable LAN Encapsulated Packet in the cache queue is marked with an explicit congestion notification tag.

5. The method according to claim 1, characterized in that, The response to congestion at the exit of the buffer queue, generating a congestion notification message, includes: In response to congestion at the exit of the cache queue, a predetermined number of notification messages are generated within each aggregation time period, according to a set aggregation time.

6. The method according to any one of claims 1 to 3 and 5, characterized in that, The notification message also carries out the egress congestion information of the forwarding device, which is used to instruct the target tunnel endpoint device to determine the rate at which the congestion notification message is generated.

7. A method for sending congestion notification messages, applied to tunnel endpoint devices, comprising: In response to receiving a notification message indicating that a target transmission tunnel is congested, the flow information of a target flow that matches the target outer source layer 4 port number is determined based on the target outer source layer 4 port number carried in the notification message, wherein the target transmission tunnel is a tunnel for transmitting the target flow. Based on the flow information of the target flow, a congestion notification message is generated; The congestion notification message is sent to the source server corresponding to the target flow.

8. The method according to claim 7, characterized in that, The step of determining the flow information of the target flow matching the target outer source layer 4 port number based on the target outer source layer 4 port number carried in the notification message includes: Based on the mapping relationship between the outer source layer 4 port number and the flow information of the data stream, the flow information of the target flow corresponding to the target outer source layer 4 port number is obtained, and the data stream includes the target flow.

9. The method according to claim 8, characterized in that, Before determining the flow information of the target flow matching the target outer source layer 4 port number based on the target outer source layer 4 port number carried in the notification message, the method further includes: The received target stream is encapsulated using a virtual scalable local area network (VSDN), and the encapsulated target stream is sent through the target transmission tunnel. The correspondence between the flow information of the target flow and the target outer source layer 4 port number encapsulated by the target flow is recorded in the mapping relationship.

10. The method according to any one of claims 7 to 9, characterized in that, The notification message also carries the outgoing congestion information of the forwarding device; the generation of the congestion notification message based on the flow information of the target flow includes: Based on the exit congestion information, determine the rate at which the congestion notification message is generated; Based on the flow information of the target flow, the congestion notification message is generated at the determined rate.

11. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory storing programs or instructions that can run on the processor, the programs or instructions being executed by the processor to implement the steps of the method as described in any one of claims 1 to 10.

12. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the method as described in any one of claims 1 to 10.

13. A computer program product comprising a computer program stored on a non-transitory computer-readable storage medium, the computer program including program instructions that, when executed by a computer, cause the computer to perform the steps of the method as described in any one of claims 1 to 10.

Images