A method, apparatus and system for flow congestion control

Abstract

The application provides a traffic congestion control method, device and system, comprising: after a first device receives traffic congestion indication information sent by a second device, the first device stops sending data to the second device; the traffic congestion indication information is a priority-based traffic control (PFC) pause frame; the first device determines at least one third device which has traffic transmission with the second device; the third device is an upstream device of the first device; the first device sends a first bidirectional forwarding detection (BFD) packet to the at least one third device, the first BFD packet carries indication information used for requesting to disconnect a BFD session with the third device; after the first device receives a second BFD packet sent by the at least one third device, the first device disconnects the BFD session with the at least one third device; the second BFD packet carries indication information used for indicating that the third device agrees to disconnect the BFD session with the first device. According to the scheme, traffic congestion can be effectively controlled.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, device, and system for controlling traffic congestion. Background Art

[0002] The foundational technology currently used in the industry to ensure lossless networks, using Ethernet-based RDMA-integrated RoCEv2 (RoCEv2) technology, is priority-based flow control (PFC). This technology alleviates congestion by halting traffic at the source of congestion. On an Ethernet link, when a first device sends data to a second device, if the second device's forwarding capacity is insufficient, the transmission rate of packets of a certain priority level on the link will exceed the reception rate of the second device, leading to insufficient buffer space on the second device. When the buffer space falls below a threshold, the second device sends a PFC pause frame (PFC PAUSE) back to the first device. Upon receiving the PFC PAUSE frame, the first device immediately stops sending data. The first device subsequently receives data and caches it locally. However, as the pause accumulates, the local buffer space on the first device eventually becomes depleted, and when the buffer space falls below the threshold, it continues to send PFC PAUSE frames to the first device's upstream device (a third device) to provide back pressure. This back pressure continues hop by hop until the sending server receives the PFC PAUSE frame and stops sending data. The restriction is then lifted hop by hop, and the network congestion is finally relieved.

[0003] PFC technology directly stops upstream traffic, which may cause some tasks to timeout. Therefore, the industry generally uses it in combination with explicit congestion notification (ECN) technology.

[0004] ECN technology is an end-to-end congestion control technology that can reduce the sending rate of the sending server to alleviate congestion in the network before PFC is triggered. When the second device detects traffic congestion, the second device sends a message carrying a traffic congestion marker to the receiving server. When the receiving server receives the message carrying the traffic congestion marker sent by the second device, it knows that congestion has occurred in the transmission link, generates a CNP congestion notification message, and sends the message to the sending server. When the sending server receives the CNP message, it reduces the corresponding data flow sending rate to alleviate the congestion in the network. Therefore, through the ECN end-to-end early congestion traffic control method, the number of PFC triggers in the network is reduced.

[0005] However, due to network congestion, the time it takes for ECN's corresponding Congestion Notification Packets (CNPs) to reach the receiving server is significantly increased, triggering PFC. Furthermore, due to network redundancy, the CNPs sent by the receiving server may be forwarded to the sending server via another congested path, preventing the sending server from reducing its sending rate in a timely manner and optimizing the triggering of PFC.

[0006] Therefore, how to effectively control traffic congestion remains to be solved. Summary of the Invention

[0007] The present application provides a traffic congestion control method, device and system, which can effectively control traffic congestion.

[0008] In a first aspect, an embodiment of the present application provides a traffic congestion control method, which can be executed by a traffic congestion control device, which can be a routing device or a module for a routing device, or a switch or a module for a switch. The present application does not limit the execution subject of the method. The method includes: after a first device receives traffic congestion indication information sent by a second device, it stops sending data to the second device; wherein the second device is a downstream device of the first device; the traffic congestion indication information is a priority-based flow control PFC pause frame; the first device determines at least one third device with which traffic is transmitted; the third device is an upstream device of the first device; the first device sends a first bidirectional forwarding monitoring BFD message to the at least one third device, the first BFD message carries indication information for requesting to disconnect the BFD session with the third device; after the first device receives a second BFD message sent by the at least one third device, it disconnects the BFD session with the at least one third device; the second BFD message carries indication information for indicating that the third device agrees to disconnect the BFD session with the first device.

[0009] In the above solution, when the first device receives traffic congestion indication information from the second device, it determines that traffic congestion has occurred on the link between the first and second devices. At this point, the first device immediately sends a first BFD message to the multiple upstream devices corresponding to the first device, disconnecting the BFD sessions with the multiple upstream devices. Based on the dynamic routing protocol, the upstream device, i.e., the third device, reselects a routing path for data transmission and forwards the data to the second device via the reselected routing path. Therefore, the original congested link is promptly avoided without waiting for the PFC message to be delivered to the sending server and for the sending server to stop traffic transmission. The PFC PAUSE frame can be terminated at the first hop, quickly updating the traffic path to regulate link congestion.

[0010] In one possible implementation method, the first device sends the first BFD message to N-1 third devices respectively; wherein, there are N third devices that have traffic transmission with the second device, and N is an integer greater than or equal to 2.

[0011] In the above solution, if the first device has N upstream devices, it only disconnects the BFD sessions with N-1 upstream devices. The remaining flow can still maintain single-flow transmission along the original path. This ensures that there is no traffic congestion between the first and second devices, and prevents the first device from being isolated, thereby improving network transmission efficiency.

[0012] In one possible implementation method, stop sending BFD Hello messages to the N-1 third devices and start a first timer; after the first timer expires, send the BFD Hello messages to the N-1 third devices and establish BFD sessions with the N-1 third devices respectively.

[0013] In the above solution, after a period of time, the BFD session between the first device and N-1 third devices is re-established. Based on the dynamic routing protocol, the interrupted link is restored, and the link between the first device and N-1 third devices will be added to the multi-link load sharing group. The N-1 third devices can still forward data to the first device, and then forward it to the second device via the first device.

[0014] In a possible implementation method, the first device sets the Diag field of the BFD message to a first value, thereby generating the first BFD message.

[0015] The above solution, by newly defining the Diag field in BFD packets, enables it to adapt to generating corresponding marked BFD packets based on received PFC packets. This can then adjust the ECMP path recalculation of network devices through a dynamic routing protocol linked to the BFD session state.

[0016] In a second aspect, embodiments of the present application provide a method for controlling traffic congestion. This method can be performed by a traffic congestion control device, which can be a routing device or a module for a routing device, or a switch or a module for a switch. This application does not limit the subject that performs this method. The method includes: a third device receives a first bidirectional forwarding monitoring BFD message sent by a first device; wherein, the first BFD message is a message sent by the first device to the third device after receiving a priority-based flow control PFC pause frame from the second device; the second device is a downstream device of the first device; the third device is an upstream device of the first device and has traffic transmission between it and the second device; the first BFD message carries indication information for requesting to disconnect the BFD session with the third device; the third device sends a second BFD message to the first device, and the second BFD message carries indication information for indicating that the third device agrees to disconnect the BFD session with the first device; the third device revokes the routing information with the first device from the routing forwarding table, and determines a fourth device based on recalculating the route; the fourth device is a downstream device of the third device, and the fourth device is an upstream device of the second device; the third device transmits traffic with the second device via the fourth device.

[0017] In the above solution, when the first device receives traffic congestion indication information from the second device, it determines that traffic congestion has occurred on the link between the first and second devices. At this point, the first device immediately sends a first BFD packet to the multiple upstream devices corresponding to the first device, terminating the BFD sessions with these multiple upstream devices. Based on the dynamic routing protocol, the upstream device, i.e., the third device, removes the routing information for the first device from its routing forwarding table and, based on recalculated routes, identifies the fourth device. The third device then transmits traffic to the second device via the fourth device. This effectively avoids the original congested link without waiting for the PFC packet to be delivered to the sending server and for the sending server to stop traffic transmission. The PFC PAUSE frame can be terminated at the first hop, rapidly updating the traffic path to regulate link congestion.

[0018] In one possible implementation method, the third device stops sending BFD Hello messages to the first device and starts a second timer; after the second timer expires, the third device sends a BFD Hello message to the first device to establish a BFD session with the first device; the third device adds routing information with the first device to the routing forwarding table.

[0019] In the above solution, after a period of time, the BFD session between the first device and the third device is re-established. Based on the dynamic routing protocol, the interrupted link is restored, and the link between the first device and the third device will be added to the multi-link load sharing group. The third device can still forward data to the first device, and then forward it to the second device via the first device.

[0020] In a possible implementation method, the third device sets the Diag field of the BFD message to a second value, thereby generating the second BFD message.

[0021] The above solution, by newly defining the Diag field in BFD packets, enables it to adapt to generating corresponding marked BFD packets based on received PFC packets. This can then adjust the ECMP path recalculation of network devices through a dynamic routing protocol linked to the BFD session state.

[0022] In a third aspect, an embodiment of the present application provides a traffic congestion control device, which is applied to a first device, wherein the first device is included in a traffic congestion control system, and the traffic congestion control system further includes a second device and a third device, wherein the second device is a downstream device of the first device, and the third device is an upstream device of the first device, and the first device includes: a transceiver unit and a processing unit. The transceiver unit is configured to stop sending data to the second device after receiving traffic congestion indication information sent by the second device; wherein the traffic congestion indication information is a priority-based traffic control PFC pause frame; send a first bidirectional forwarding monitoring BFD message to the at least one third device, wherein the first BFD message carries indication information for requesting to disconnect the BFD session with the third device; disconnect the BFD session with the at least one third device after receiving a second BFD message sent by the at least one third device; the second BFD message carries indication information for indicating that the third device agrees to disconnect the BFD session with the first device; and the processing unit is configured to determine at least one third device with which traffic transmission exists.

[0023] In one possible implementation method, the transceiver unit is used to send the first BFD message to N-1 third devices respectively; wherein, there are N third devices with traffic transmission with the second device, and N is an integer greater than or equal to 2.

[0024] In one possible implementation method, the transceiver unit is used to stop sending BFDHello messages to the N-1 third devices and start a first timer; after the first timer ends, the BFD Hello message is sent to the N-1 third devices to establish a BFD session with the N-1 third devices respectively.

[0025] In a possible implementation method, the processing unit is configured to, by the first device, set the Diag field of the BFD message to a first value, thereby generating the first BFD message.

[0026] In a fourth aspect, an embodiment of the present application provides a traffic congestion control device, which is applied to a third device. The third device is included in a traffic congestion control system. The traffic congestion control system also includes a first device and a second device. The second device is a downstream device of the first device, and the third device is an upstream device of the first device. The third device includes: a transceiver unit and a processing unit. A transceiver unit, configured to receive a first bidirectional forwarding monitoring BFD message sent by a first device; wherein, the first BFD message is a message sent by the first device to the third device after receiving a priority-based flow control PFC pause frame from the second device; the second device is a downstream device of the first device; the third device is an upstream device of the first device and has traffic transmission with the second device; the first BFD message carries indication information for requesting to disconnect the BFD session with the third device; a second BFD message is sent to the first device, and the second BFD message carries indication information for indicating that the third device agrees to disconnect the BFD session with the first device; a processing unit, configured to revoke the routing information with the first device from the routing forwarding table, and determine a fourth device based on recalculating the route; the fourth device is a downstream device of the third device, and the fourth device is an upstream device of the second device; the third device transmits traffic with the second device via the fourth device.

[0027] In one possible implementation method, the transceiver unit is used to stop sending BFD Hello messages to the first device and start a second timer; after the second timer expires, the transceiver sends a BFD Hello message to the first device to establish a BFD session with the first device; the third device adds routing information with the first device to the routing forwarding table.

[0028] In a possible implementation method, the processing unit is configured to set the Diag field of the BFD message to a second value, thereby generating the second BFD message.

[0029] In a fifth aspect, an embodiment of the present application further provides a computing device, including:

[0030] a memory for storing program instructions;

[0031] The processor is used to call the program instructions stored in the memory and execute any method of the first aspect or any method of the second aspect according to the obtained program instructions.

[0032] In a sixth aspect, an embodiment of the present application further provides a computer-readable storage medium storing computer-readable instructions. When a computer reads and executes the computer-readable instructions, any method of the above-mentioned first aspect or any method of the above-mentioned second aspect is implemented.

[0033] In the seventh aspect, an embodiment of the present application provides a computer program product, comprising a computer program executable by a computer device, wherein when the program is run on the computer device, the computer device executes any method implementing the above-mentioned first aspect or any method implementing the above-mentioned second aspect.

[0034] In an eighth aspect, an embodiment of the present application provides a traffic congestion control system, which includes a first device for executing any method of the above-mentioned first aspect, and a third device for executing any method of the above-mentioned second aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 An architectural diagram of a traffic congestion control system provided in an embodiment of the present application;

[0036] Figure 2 A flow chart of a traffic congestion control method provided in an embodiment of the present application;

[0037] Figure 3 A flow chart of a traffic congestion control method provided in an embodiment of the present application;

[0038] Figure 4 A BFD message format diagram provided in an embodiment of the present application;

[0039] Figure 5 A flow chart of a traffic congestion control method provided in an embodiment of the present application;

[0040] Figure 6 A flow chart of a traffic congestion control method provided in an embodiment of the present application;

[0041] Figure 7 A schematic diagram of the structure of a traffic congestion control device provided in an embodiment of the present application;

[0042] Figure 8 A schematic structural diagram of a traffic congestion control device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0043] The following is a brief explanation of several professional terms.

[0044] Remote Direct Memory Access (RDMA) technology addresses the latency caused by kernel copies during network data transmission in the traditional TCP / IP network protocol stack. RDMA technology allows direct access to memory data through the network interface, without the intervention of the operating system kernel. This enables high-throughput, low-latency network communication, making it particularly suitable for use in large-scale parallel computer clusters.

[0045] RDMA over Converged Ethernet (RoCEv2) is an Ethernet RDMA technology defined by the IBTA standard. Because the RoCEv2 protocol uses UDP / IP over Ethernet, it can be deployed on traditional Layer 3 Ethernet networks. It has become the industry's mainstream RDMA network technology. RoCEv2 adds UDP, IP, and Layer 2 Ethernet headers to the existing IB message header, identifying RoCE messages with the UDP destination port number 4791. Source port numbers are hashed for ECMP multipath load balancing, improving network utilization.

[0046] Priority Flow Control (PFC) is the most widely used Ethernet flow control technology. When a PFC-enabled queue experiences network congestion, the downstream device sends a PFCPAUSE frame to notify the upstream device to stop sending traffic for the congested queue. This occurs until the downstream device's ingress buffer falls below the configured congestion watermark, at which point it resends a notification to the upstream device to resume transmission.

[0047] Explicit Congestion Notification (ECN): This is an end-to-end network congestion notification mechanism defined in RFC3168. When a network device detects congestion, it sends a message carrying a congestion marker to the receiving server. The receiving server then sends Congestion Notification Packets (CNP messages) to the sending server, instructing it to reduce its message transmission rate, thereby alleviating congestion.

[0048] Bidirectional Forwarding Detection (BFD) is a high-speed fault detection mechanism based on the RFC5880 standard. After two systems establish a BFD session, they periodically send BFD packets on the channel between them. If one system does not receive a BFD packet within the negotiated detection time, it is considered that a fault has occurred on the bidirectional channel. The previous-hop routing protocol detects the link failure through BFD and can take timely measures to recover from the fault.

[0049] Most of the traffic carried by RoCEv2 networks is "elephant flows," meaning there are only a few communication flows, but each flow carries a large amount of traffic. Therefore, traditional ECMP (Extensive Load Balancing) technology, which uses per-flow hashing, can result in high traffic on a single path. Furthermore, in large-scale networks, when multiple "elephant flows" are hashed to the same link, this can cause congestion on that link and lead to packet loss. Because RDMA technology is extremely sensitive to packet loss, packet loss can cause a large number of retransmissions, leading to a sharp drop in network throughput. Therefore, appropriate traffic congestion control technology is essential in RoCEv2 networks.

[0050] Currently, the industry's foundational technology for ensuring lossless RoCEv2 networks is PFC, which alleviates congestion by stopping traffic at the source of congestion. However, because PFC directly stops traffic from upstream devices, it can cause some training tasks to time out and terminate. Therefore, the industry generally combines it with Explicit Congestion Notification (ECN). Through ECN's end-to-end, proactive congestion control, the number of PFC triggers in the network can be reduced.

[0051] PFC technology provides priority-based flow control on a per-link basis. On an Ethernet link, when a first device sends data to a second device, if the second device's forwarding capacity is insufficient, the transmission rate of packets of a certain priority on the link will exceed the reception rate of the second device, leading to insufficient buffer space on the second device. When the buffer space falls below a threshold, the second device sends a PFC pause frame (PFC PAUSE frame) back to the first device. Upon receiving the PFC PAUSE frame, the first device immediately stops sending data. The first device subsequently caches data received locally, but as the time between transmissions accumulates, the first device's local buffer space will eventually be consumed, and the buffer space will fall below the threshold. As a result, the first device will continue to send PFC PAUSE frames to the first device's upstream device (a third device) to provide back pressure. This hop-by-hop back pressure continues until the sending server receives the PFC PAUSE frame and stops sending data. The restriction is then lifted hop by hop, and the network congestion is finally relieved.

[0052] Since traffic backpressure needs to be performed hop by hop, which is inefficient, end-to-end flow control technology can effectively improve the flow control effect in RoCEv2 RDMA networks that require high throughput and zero packet loss.

[0053] ECN technology is an end-to-end congestion control technology that can alleviate network congestion by reducing the sending rate through the sending server before PFC is triggered. When congestion occurs on the second device, the second device sets the ECN flag field in the IP header and forwards it normally to the receiving server. When the receiving server receives a data packet with the ECN flag field in the IP header set, it knows that congestion has occurred in the transmission link. At this time, it will immediately generate a CNP congestion notification message and send it to the sending server. When the sending server receives the CNP message, it reduces the sending rate of the corresponding data stream to alleviate the congestion in the network. Although ECN can effectively reduce the number of PFC triggers, the following reasons also make ECN technology have limited optimization of the number of PFC triggers in certain scenarios:

[0054] (1) When ECN is congested in the outbound queue, the second device sets the ECN field in the IP header of the message to be sent and then places the message into the outbound queue for transmission. However, since the outbound queue is already congested at this time, if the congestion is severe, the forwarding time will be greatly increased, which will cause PFC to trigger.

[0055] (2) Due to the redundancy of the network, the CNP congestion notification message sent by the receiving server may be forwarded to the sending server from another congested path, which may cause the sending server to be unable to reduce the sending rate in time and unable to optimize the triggering of PFC.

[0056] The following describes the method provided in the embodiments of the present application.

[0057] Figure 1 An architectural diagram of a traffic congestion control system provided in an embodiment of the present application, the traffic congestion control system includes a first device, a second device, and a third device. Among them, the second device is a downstream device of the first device, and the third device is an upstream device of the first device; the first device, the second device, and the third device can be routers or switches. The traffic congestion control system can also include a first terminal, a second terminal, and other routing devices or switch devices in addition to the above three devices. Since the data transmission is bidirectional, the first terminal and the second terminal can both be a sending end server or a receiving end server, and the corresponding first device, second device, and third device also undergo conversion, which is not limited in this application. In the following embodiments, the first terminal is explained as a sending end server and the second terminal is explained as a receiving end server.

[0058] In one possible implementation method, there are multiple first devices, namely, first device 1 to first device n, where n is an integer greater than or equal to 2. The third device can forward data to the second device through the first device 1, or forward data to the second device through the first device n.

[0059] In one possible implementation method, the first terminal sends data to the second terminal, and the data is sent to the receiving end server via the third device, the first device, and the second device. Of course, multiple routers or switches may be included between the third device and the first terminal, and multiple routers or switches may be included between the second device and the second terminal. This application does not limit this. For example, the first terminal sends data to the third device. After the third device receives the data, based on the dynamic routing protocol, it selects the first device as the routing forwarding point to send the data. The third device forwards the data to the first device. After the first device receives the data, based on the dynamic routing protocol, it selects the second device as the routing forwarding point to send the data. The first device forwards the data to the second device. After the second device receives the data, it forwards it to the second terminal. In this application, the first terminal and the second terminal can be converted to each other, that is, the second terminal can also serve as a sending end server to send data to the first terminal. This application does not limit this.

[0060] Figure 2 This is a flow chart of a traffic congestion control method provided in an embodiment of the present application, which is executed by a first device or a module of the first device. This application does not limit the execution subject of this method.

[0061] The method comprises the following steps:

[0062] Step 201: After receiving traffic congestion indication information sent by a second device, the first device stops sending data to the second device.

[0063] The second device is a downstream device of the first device; and the traffic congestion indication information is a priority-based flow control PFC pause frame.

[0064] In one possible implementation method, traffic congestion occurs when multiple sending servers send data to multiple receiving servers. For example, the sending ends include sending server A and sending server B, and the receiving ends include receiving server A and receiving server B. The link from sending server A to receiving server A is: sending server A - third device A - first device A - second device A - receiving server A; the link from sending server B to receiving server B is: sending server B - third device B - first device A - second device A - receiving server B. It can be seen that both third device A and third device B send data to second device A through first device A. If the data received by second device A exceeds the threshold it can bear, traffic congestion indication information is sent to first device A, informing first device A that the link is sending traffic congestion.

[0065] In one possible implementation method, traffic congestion occurs when multiple sending servers each send data to a receiving server. For example, the sending end includes a sending server A and a sending server B, and the receiving end includes a receiving server A. That is, both sending server A and sending server B send data to receiving server A. The link from sending server A to receiving server A is: sending server A - third device A - first device A - second device A - receiving server A; the link from sending server B to receiving server A is: sending server B - third device B - first device A - second device A - receiving server A. Clearly, both third device A and third device B send data to second device A via first device A. If the data received by second device A exceeds a threshold that it can bear, traffic congestion indication information is sent to first device A, informing first device A that the link is experiencing traffic congestion.

[0066] One possible implementation method is that each device includes multiple ports. Since the ports are duplex, that is, each port can serve as both an input port and an output port; when a port serves as an input port, the device connected to the input port is an upstream device; when a port serves as an output port, the device connected to the output port is a downstream device; the input port of each device is used to receive data sent by the upstream device, and the output port of each device is used to send data to the downstream device.

[0067] In one possible implementation, multiple ingress ports of a first device are connected to multiple third devices, respectively. The first egress port of the first device is connected to the first ingress port of a second device. The first device needs to forward data sent by the multiple third devices to the first ingress port of the second device via the first egress port. For example, ingress port 1 of the first device is connected to third device 1, ingress port 2 of the first device is connected to third device 2, and ingress port 3 of the first device is connected to third device 3. The first device receives data sent by third device 1, third device 2, and third device 3, and then sends the data sent by these three third devices to the first ingress port of the second device via the first egress port of the first device.

[0068] In one possible implementation method, the data volume processed by each device port is a fixed value. For example, the data volume processed by each port of the first, second, and third devices is 10 GB. Third device 1 sends 5 GB of data to ingress port 1 of the first device, third device 2 sends 2 GB of data to ingress port 2 of the first device, and third device 3 sends 3 GB of data to ingress port 3 of the first device. Then, the first device receives 10 GB of data, and all of this 10 GB of data is sent to the first ingress port of the second device. After receiving 10 GB of data, the first ingress port of the second device detects that the PFC trigger threshold has been reached. The first ingress port of the second device then sends traffic congestion indication information to the first device, namely, a PFCPAUSE frame to notify the first device to stop sending data to the first ingress port of the second device.

[0069] Step 202: The first device determines at least one third device that has traffic transmission with the second device.

[0070] The third device is an upstream device of the first device.

[0071] In one possible implementation, after receiving traffic congestion indication information from a second device, a first device determines, based on PFC backpressure rules, at least one third device with which the second device is transmitting traffic. This third device is the first device's upstream device. Because PFC applies backpressure upwards one level at a time, each device knows its upstream device.

[0072] Step 203: The first device sends a first bidirectional forwarding monitoring BFD message to at least one third device.

[0073] The first BFD message carries instruction information for requesting to disconnect the BFD session with the third device.

[0074] Step 204: After receiving the second BFD packet sent by the at least one third device, the first device disconnects the BFD session with the at least one third device.

[0075] The second BFD message carries indication information for indicating that the third device agrees to disconnect the BFD session with the first device.

[0076] In the above solution, when the first device receives traffic congestion indication information from the second device, it determines that traffic congestion has occurred on the link between the first and second devices. At this point, the first device immediately sends a first BFD message to the multiple upstream devices corresponding to the first device, disconnecting the BFD sessions with the multiple upstream devices. Based on the dynamic routing protocol, the upstream device, i.e., the third device, reselects a routing path for data transmission and forwards the data to the second device via the reselected routing path. Therefore, the original congested link is promptly avoided without waiting for the PFC message to be delivered to the sending server and for the sending server to stop traffic transmission. The PFC PAUSE frame can be terminated at the first hop, quickly updating the traffic path to regulate link congestion.

[0077] In one possible implementation method, in step 203, the first device sends a first BFD packet to each of N-1 third devices; the number of third devices with which the second device is transmitting traffic is N, where N is an integer greater than or equal to 2. That is, the first device selects N-1 third devices to send the first BFD packet, disconnects the BFD sessions with the N-1 third devices, and retains one BFD session with the third device. The sending server can still send data to the retained third device, which then forwards the data to the first device. The first device then sends the data to the first ingress port of the second device via the first egress port, which then forwards the data to the receiving server via the second device. This solution only disconnects the BFD sessions with the N-1 upstream devices, while the remaining single flow can continue to transmit along the original path. This ensures that traffic congestion does not occur between the first and second devices, while also preventing the first device from being isolated, thereby improving network transmission efficiency.

[0078] In one possible implementation method, after step 204, the method further includes: stopping sending BFD Hello messages to the N-1 third devices and starting a first timer; after the first timer expires, sending the BFD Hello messages to the N-1 third devices to establish BFD sessions with each of the N-1 third devices. That is, after a certain period, the BFD session with the N-1 third devices is re-established.

[0079] Figure 3 This is a flow chart of a traffic congestion control method provided in an embodiment of the present application, which is executed by a third device or a module of a third device. This application does not limit the execution subject of this method.

[0080] The method comprises the following steps:

[0081] Step 301: A third device receives a first bidirectional forwarding monitoring (BFD) message sent by a first device.

[0082] Among them, the first BFD message is a message sent by the first device to the third device after receiving the priority-based flow control PFC pause frame of the second device; the second device is a downstream device of the first device; the third device is an upstream device of the first device and there is traffic transmission between the third device and the second device; the first BFD message carries indication information for requesting to disconnect the BFD session with the third device.

[0083] Step 302: The third device sends a second BFD packet to the first device.

[0084] The second BFD packet carries indication information for indicating that the third device agrees to disconnect the BFD session with the first device;

[0085] Step 303: The third device removes the routing information with the first device from the routing forwarding table, and determines the fourth device based on recalculated routes.

[0086] The fourth device is a downstream device of the third device, and the fourth device is an upstream device of the second device.

[0087] In one possible implementation method, after the BFD session between the third device and the first device is disconnected, BFD quickly senses the link change and promptly notifies the routing management module. When the link is interrupted, the static route bound to the BFD session is promptly removed from the forwarding table, the active route is recalculated, and a new routing path, namely the fourth device, is selected. The third device forwards the data to the fourth device, and the first egress port of the fourth device forwards the data to the second ingress port of the second device, which then forwards the data to the receiving server. When traffic congestion occurs at the first ingress port of the second device, the data is forwarded to the second ingress port of the second device via the fourth device, promptly avoiding the original congested link.

[0088] In step 304, the third device transmits traffic to the second device via the fourth device.

[0089] In the above solution, when the first device receives traffic congestion indication information from the second device, it determines that traffic congestion has occurred on the link between the first and second devices. At this point, the first device immediately sends a first BFD packet to the multiple upstream devices corresponding to the first device, terminating the BFD sessions with these multiple upstream devices. Based on the dynamic routing protocol, the upstream device, i.e., the third device, removes the routing information for the first device from its routing forwarding table and, based on recalculated routes, identifies the fourth device. The third device then transmits traffic to the second device via the fourth device. This effectively avoids the original congested link without waiting for the PFC packet to be delivered to the sending server and for the sending server to stop traffic transmission. The PFC PAUSE frame can be terminated at the first hop, rapidly updating the traffic path to regulate link congestion.

[0090] One possible implementation involves configuring static routes in conjunction with dynamic BFD during the initial routing phase. After being optimized, static routes are sent to the forwarding table to guide packet forwarding. However, static routes themselves cannot detect whether the link to the next hop is up. By binding static routes to BFD sessions, BFD quickly detects link changes and promptly notifies the routing management module. If a link is interrupted, the static route bound to the BFD session is promptly removed from the forwarding table, and the active route is recalculated, achieving rapid convergence.

[0091] In one possible implementation, traditional BFD packets cannot indicate the termination of a BFD session between two devices. Traditional BFD packets are mainly used for liveness detection. That is, after a BFD session is established between two devices, they periodically send BFDHello packets to each other for liveness detection. If one device does not receive a BFD packet within the negotiated detection time, it is considered that a fault has occurred on the bidirectional channel. The previous-hop routing protocol detects the link failure through BFD and can take timely measures to recover from the fault.

[0092] In one possible implementation method, the format of the BFD message is as follows: Figure 4As shown in the figure, each BFD packet carries a diagnostic code value (DIAG). The RFC (Request For Comments) protocol stipulates that a DIAG value of 0 indicates no diagnosis: No Diagnostic; a DIAG value of 1 indicates control detection timeout: Control Detection TimeExpired; a DIAG value of 2 indicates echo function failure: Echo Function Failed; a DIAG value of 3 indicates that the neighbor signaled session is down: Neighbor Signaled Session Down; a DIAG value of 4 indicates forwarding plane reset: Forwarding Plane Reset; a DIAG value of 5 indicates path down: Path Down; a DIAG value of 6 indicates concatenated path down: Concatenated Path Down; a DIAG value of 7 indicates administratively down: System down; a DIAG value of 8 indicates reverse link down: Reverse Concatenated Path Down; DIAG values ​​9-31 indicate reserved for future use: Reserved for future use.

[0093] In one possible implementation method, when the DIAG value of the BFD message is 9-31, it is reserved for future use. This application adds a new definition for the DIAG value so that the BFD message can indicate the disconnection of the BFD session between two devices.

[0094] In one possible implementation method, the Diag field of the BFD message is set to a first value, thereby generating a first BFD message; and the Diag field of the BFD message is set to a second value, thereby generating a second BFD message. This application does not limit the specific numerical values ​​of the first value and the second value, which can be any numerical value from 9 to 31. By newly defining the Diag field of the BFD message, it can adapt to generating corresponding tagged BFD messages based on received PFC messages, and then adjust the recalculation of ECMP routing of network devices through a dynamic routing protocol linked to the BFD session state.

[0095] In one possible implementation method, the Diag field of the BFD message is set to 01001, that is, the Diag field flag is 9. This means that the sending node of the BFD message carrying this flag has received a PFC PAUSE frame and needs to close the BFD session. The flag is PFC_Received.

[0096] In one possible implementation method, the Diag field of the BFD message is set to 01010, that is, the Diag field identifier is 10. This means that the sending node of the BFD message carrying this identifier has received a BFD message carrying the PFC_Received flag and agrees to close the BFD session, which is identified as PFC_AdminDown.

[0097] The above solution generates a BFDDown notification message carrying the PFC_Received flag on the network device that receives the PFC PAUSE frame and sends it to the inbound interfaces (corresponding to the upstream devices that are about to be backpressured) that are causing the traffic in the queue identified by the received PFC frame to continue to increase. After the upstream device receives the BFD AdminDown message with the PFC_Received flag, it replies with a BFD AdminDown message marked with PFC_AdminDown. The routing protocol associated with the BFD session then converges and recalculates the multipath load balancing ECMP path, preventing the upstream device from transmitting traffic to the device that received the PFC PAUSE frame. This avoids congested paths at the device that receives the PFC PAUSE frame, eliminating the need for hop-by-hop backpressure and significantly reducing the time from the generation of the first PFC frame to the application of backpressure to the server sending traffic. Because the congested link is avoided by reselecting ECMP routing at the upstream hop of the device that receives the PFC frame, upstream devices will not continue to send PFC frames, ultimately preventing the sending server from stopping traffic and preventing cluster tasks in the RDMA network from being halted.

[0098] The following is an example of a specific embodiment to explain the specific process of the flow congestion control method. Figure 5As shown in the figure, terminal servers c and d are sending servers, terminal servers a and b are receiving servers, spineA is the first device, leafA is the downstream device of spineA, that is, the second device, and leafX and leafY are the upstream devices of spineA, that is, the third device. Terminal server c sends data to terminal server a through the routing devices leafX, spineA, and leafA. Terminal server d sends data to terminal server b through the routing devices leafY, spineA, and leafA. SpineA and spineY are the first devices on the same layer, that is, leafX and leafY can also forward data to spineY, which then forwards it to leafA. However, due to the selection of the dynamic routing protocol, the data of leafX and leafY are currently forwarded by spineA to leafA. This process is as follows: Figure 6 As shown, the following steps are included:

[0099] Step 601: The first device spineA receives a PFC PAUSE frame sent by the first egress port of the second device leafA and stops sending data to leafA.

[0100] In one possible implementation, when terminal servers a and b on leaf A communicate simultaneously with terminal servers c on leaf X and d on leaf Y, respectively, the traffic, after multi-link load balancing, may all be forwarded through the link between spain A and leaf A. At this point, if the combined traffic of the two flows exceeds the link bandwidth of the first egress port on spain A and leaf A, link congestion will occur. As the in-queue buffer on the second device port gradually decreases to a threshold due to the accumulation of data packets, the PFC mechanism takes effect. When the in-queue buffer on leaf A is filled with the aggregated traffic from the two flows, reaching the PFC trigger threshold, the first egress port on leaf A sends a PFC PAUSE frame to the upstream device, spain A, to notify it to stop data transmission in that queue.

[0101] Step 602: The first device spineA sends a first BFD message to N-1 third devices.

[0102] In one possible implementation, after receiving a PFC PAUSE frame from the first egress port of leaf A, spain A stops forwarding traffic for that queue according to PFC rules. It then uses PFC backpressure rules to locate the upstream device interfaces (the interfaces from spain A to leaf X and leaf Y) to apply backpressure, and then uses these interfaces to retrieve the corresponding BFD session information.

[0103] In one possible implementation, N-1 BFD sessions are randomly selected (the session with the largest BFD session ID is selected by default), where N is the number of upstream interfaces supporting PFC backpressure. Based on the corresponding session information, a BFDAdminDown message carrying the PFC_Received field is generated and sent along the PFC backpressure interface to the upstream device (such as leaf Y). Only N-1 traffic paths need to be adjusted. The remaining flow can still be transmitted as a single flow along the original path. That is, leaf X can still send data to the first ingress port of leaf A via spine A. Because this is a single data flow, the first ingress port of leaf A will not experience traffic congestion.

[0104] Step 603: The third device leaf Y receives the first BFD packet sent by the first device spain A, and sends a second BFD packet to the first device spain A.

[0105] In one possible implementation method, after receiving the first BFD message sent by the first device spain A, the third device leaf Y replies with a BFD AdminDown message carrying PFC_AdminDown according to the received BFD AdminDown message to notify the first device spain A to start the first timer.

[0106] In one possible implementation, after receiving the first BFD packet from the first device, spain A, the third device, leaf Y, stops sending BFD Hello packets to the first device, spain A, and starts a second timer locally. This application does not limit the specific times of the first and second timers; they can be set based on the actual duration of a single service flow in the environment.

[0107] In one possible implementation method, after the third device leaf Y receives the first BFD packet sent by the first device spain A, the third device leaf Y sets the BFD session to the Down state, and the dynamic routing protocol associated with it converges, removing the PFC upstream link, i.e., the link between leaf Y and spain A, from the ECMP path. The forwarding table of the leaf Y node is updated due to the recalculation of the routing protocol. As a result of the recalculation of the multipath sharing by the leaf Y node, the original communication flow from b to d is hashed to a different spain node. For example, spain Y node forwards the data, i.e., leaf Y node forwards the data to spine Y node, and spine Y node forwards the data to the second ingress port of leaf X (different from the previous forwarding of data to the first ingress port of leaf X by spine X). At this time, the two originally congested elephant flows are split on different links, thereby resolving the original congested link situation.

[0108] In one possible implementation method, after the second timer expires, the third device leaf Y resends a BFD Hello message to the first device spainA to re-establish a BFD session with the first device spainA. At this time, the dynamic routing protocol accepts the request and the path is re-added to the ECMP group.

[0109] Step 604: After receiving the second BFD packet sent by the third device, the first device spain A disconnects the BFD session with the third device.

[0110] In one possible implementation method, after receiving a BFD AdminDown message carrying PFC_AdminDown from upstream device Leaf Y, spain node A starts a first timer and stops sending BFD Hello messages to Leaf Y. The BFD session between spain node A and Leaf Y is set to the Down state, the corresponding dynamic link protocol converges, and the upstream interface link, that is, the link between spain node A and Leaf Y, is removed from the multipath load sharing ECMP group.

[0111] Step 605: After the first timer expires, the first device spain A sends a BFD Hello message to the third device to re-establish the BFD session with the third device.

[0112] In one possible implementation method, after the first timer expires, spain node A and upstream node leaf Y resume sending BFD Hello messages, the BFD session is re-established, the corresponding dynamic link protocol also reconverges, the link that was interrupted by the original protocol is restored, added to the multi-link load sharing group, and restored to the state before the link congestion.

[0113] Based on the same technical concept, Figure 7 A traffic congestion control device 700 provided in an embodiment of the present application is exemplarily shown. The traffic congestion control device 700 includes a transceiver unit 701 and a processing unit 702 .

[0114] In one embodiment, when the traffic congestion control device 700 is applied to a first device, the transceiver unit 701 is used to stop sending data to the second device after receiving traffic congestion indication information sent by the second device; wherein the traffic congestion indication information is a priority-based flow control PFC pause frame; send a first bidirectional forwarding monitoring BFD message to the at least one third device, and the first BFD message carries indication information for requesting to disconnect the BFD session with the third device; after receiving a second BFD message sent by the at least one third device, disconnect the BFD session with the at least one third device; the second BFD message carries indication information for indicating that the third device agrees to disconnect the BFD session with the first device; the processing unit 702 is used to determine at least one third device that has traffic transmission with the second device.

[0115] In one possible implementation method, the transceiver unit 701 is used to send the first BFD message to N-1 third devices respectively; wherein, there are N third devices that have traffic transmission with the second device, and N is an integer greater than or equal to 2.

[0116] In one possible implementation method, the transceiver unit 701 is used to stop sending BFDHello messages to the N-1 third devices and start a first timer; after the first timer ends, the BFD Hello message is sent to the N-1 third devices to establish a BFD session with the N-1 third devices respectively.

[0117] In a possible implementation method, the processing unit 702 is configured to enable the first device to set the Diag field of the BFD message to a first value, thereby generating the first BFD message.

[0118] In another embodiment, when the traffic congestion control device 700 is applied to a third device, the transceiver unit 701 is used to receive a first bidirectional forwarding monitoring BFD message sent by the first device; wherein the first BFD message is a message sent by the first device to the third device after receiving the priority-based flow control PFC pause frame of the second device; the second device is a downstream device of the first device; the third device is an upstream device of the first device and there is traffic transmission between the third device and the second device; the first BFD message carries indication information for requesting to disconnect the BFD session with the third device; a second BFD message is sent to the first device, and the second BFD message carries indication information for indicating that the third device agrees to disconnect the BFD session with the first device; the processing unit 702 is used to revoke the routing information with the first device from the routing forwarding table, and determine the fourth device based on recalculating the route; the fourth device is a downstream device of the third device, and the fourth device is an upstream device of the second device; the third device transmits traffic with the second device via the fourth device.

[0119] In one possible implementation method, the transceiver unit 701 is used to stop sending BFD Hello messages to the first device and start a second timer; after the second timer expires, a BFD Hello message is sent to the first device to establish a BFD session with the first device; and the third device adds routing information with the first device to the routing forwarding table.

[0120] In a possible implementation method, the processing unit 702 sets the Diag field of the BFD message to a second value, thereby generating the second BFD message.

[0121] Based on the same technical concept, the embodiment of the present application provides a flow congestion control device 800, which can be a routing device or a switch device. Figure 8 As shown, a traffic congestion control device 800 includes at least one processor 801 and a memory 802 connected to the at least one processor. The specific connection medium between the processor 801 and the memory 802 is not limited in the embodiment of the present application. Figure 8 For example, the processor 801 and the memory 802 are connected via a bus. The bus can be divided into an address bus, a data bus, a control bus, and the like.

[0122] In an embodiment of the present application, the memory 802 stores instructions that can be executed by at least one processor 801. The at least one processor 801 can execute the above-mentioned traffic congestion control method by executing the instructions stored in the memory 802.

[0123] The processor 801 is a control center of the traffic congestion control device 800. It can connect various parts of the computer device using various interfaces and lines, and perform resource settings by running or executing instructions stored in the memory 802 and calling data stored in the memory 802. Optionally, the processor 801 may include one or more determination units. The processor 801 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the modem processor mainly processes wireless communications. It is understood that the modem processor may not be integrated into the processor 801. In some embodiments, the processor 801 and the memory 802 may be implemented on the same chip. In some embodiments, they may also be implemented on separate chips.

[0124] The processor 801 can be a general-purpose processor, such as a central processing unit (CPU), a digital signal processor, an application-specific integrated circuit (ASIC), a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, and can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in conjunction with the embodiments of the present application can be directly embodied as being executed by a hardware processor, or can be executed by a combination of hardware and software modules in the processor.

[0125] The memory 802 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs, non-volatile computer executable programs and modules. The memory 802 may include at least one type of storage medium, such as a flash memory, a hard disk, a multimedia card, a card-type memory, a random access memory (Random Access Memory, RAM), a static random access memory (Static Random Access Memory, SRAM), a programmable read-only memory (Programmable Read Only Memory, PROM), a read-only memory (Read Only Memory, ROM), an electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), a magnetic memory, a disk, an optical disk, etc. The memory 802 is any other medium that can be used to carry or store a desired program code in the form of an instruction or data structure and can be accessed by a computer, but is not limited thereto. The memory 802 in the embodiment of the present application can also be a circuit or any other device that can realize a storage function, for storing program instructions and / or data.

[0126] An embodiment of the present application further provides a computer-readable storage medium, which stores a computer-executable program. The computer-executable program is used to enable a computer to execute a traffic congestion control method listed in any of the above methods.

[0127] An embodiment of the present application provides a computer program product, including a computer program executable by a computer device. When the program is run on the computer device, the computer device executes a traffic congestion control method listed in any of the above-mentioned methods.

[0128] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0129] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0130] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0131] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0132] Obviously, those skilled in the art may make various changes and modifications to this application without departing from the spirit and scope of this application. Thus, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application is intended to include these modifications and variations.

Claims

1. A traffic congestion control method, characterized in that: include: After receiving traffic congestion indication information sent by a second device, the first device stops sending data to the second device; wherein the second device is a downstream device of the first device; the traffic congestion indication information is a priority-based flow control PFC pause frame; The first device determines at least one third device that has traffic transmission with the second device; the third device is an upstream device of the first device; The first device sends a first bidirectional forwarding monitoring (BFD) message to the at least one third device, where the first BFD message carries instruction information for requesting to disconnect the BFD session with the third device; After receiving the second BFD message sent by the at least one third device, the first device disconnects the BFD session with the at least one third device; the second BFD message carries indication information for indicating that the third device agrees to disconnect the BFD session with the first device; The third device reselects a routing path for data transmission, and forwards the data to the second device via the reselected routing path.

2. The method according to claim 1, wherein The first device sending a first bidirectional forwarding monitoring (BFD) message to the at least one third device includes: The first device sends the first BFD message to N-1 third devices respectively; wherein, there are N third devices with which traffic transmission occurs with the second device, and N is an integer greater than or equal to 2.

3. The method according to claim 2, wherein After the first device receives the second BFD packet sent by the at least one third device, the method further includes: Stop sending BFD Hello messages to the N-1 third devices and start a first timer; After the first timer expires, the BFD Hello message is sent to the N-1 third devices to establish a BFD session with each of the N-1 third devices.

4. The method according to any one of claims 1 to 3, characterized in that Before the first device sends the first bidirectional forwarding monitoring BFD packet to the at least one third device, the method further includes: The first device sets the Diag field of the BFD message to a first value, thereby generating the first BFD message.

5. A traffic congestion control method, characterized in that: include: The third device receives a first bidirectional forwarding monitoring (BFD) message sent by the first device; wherein the first BFD message is a message sent by the first device to the third device after receiving a priority-based flow control (PFC) pause frame from the second device; the second device is a downstream device of the first device; the third device is an upstream device of the first device and has traffic transmission with the second device; the first BFD message carries instruction information for requesting to disconnect the BFD session with the third device; The third device sends a second BFD packet to the first device, where the second BFD packet carries indication information for indicating that the third device agrees to disconnect the BFD session with the first device; The third device removes the routing information with the first device from the routing forwarding table, and determines a fourth device based on recalculating the route; the fourth device is a downstream device of the third device, and the fourth device is an upstream device of the second device; The third device transmits traffic with the second device via the fourth device.

6. The method according to claim 5, wherein After the third device receives the first bidirectional forwarding monitoring BFD message sent by the first device, the method further includes: The third device stops sending BFD Hello messages to the first device and starts a second timer; After the second timer expires, send a BFD Hello message to the first device to establish a BFD session with the first device. The third device adds routing information about the first device to the routing forwarding table.

7. The method according to claim 5, wherein Before the third device sends the second BFD packet to the first device, the method further includes: The third device sets the Diag field of the BFD message to a second value, thereby generating the second BFD message.

8. A traffic congestion control device, applied to a first device, wherein the first device is included in a traffic congestion control system, the traffic congestion control system further comprising a second device and a third device, wherein the second device is a downstream device of the first device, and the third device is an upstream device of the first device, characterized in that: The first device includes: A transceiver unit, configured to stop sending data to the second device after receiving traffic congestion indication information sent by the second device; wherein the traffic congestion indication information is a priority-based flow control PFC pause frame; send a first bidirectional forwarding monitoring BFD message to at least one third device, the first BFD message carrying indication information for requesting to disconnect the BFD session with the third device; disconnect the BFD session with the at least one third device after receiving a second BFD message sent by the at least one third device; the second BFD message carries indication information for indicating that the third device agrees to disconnect the BFD session with the first device; the third device reselects a routing path for data transmission, and forwards the data to the second device via the reselected routing path; The processing unit is configured to determine at least one third device that has traffic transmission with the second device.

9. A traffic congestion control device, applied to a third device, the third device being included in a traffic congestion control system, the traffic congestion control system further comprising a first device and a second device, the second device being a downstream device of the first device, and the third device being an upstream device of the first device, characterized in that: The third device includes: A transceiver unit, configured to receive a first bidirectional forwarding monitoring BFD message sent by a first device; wherein the first BFD message is a message sent by the first device to the third device after receiving a priority-based flow control PFC pause frame from the second device; the second device is a downstream device of the first device; the third device is an upstream device of the first device and has traffic transmission with the second device; the first BFD message carries indication information for requesting to disconnect the BFD session with the third device; and sends a second BFD message to the first device, wherein the second BFD message carries indication information for indicating that the third device agrees to disconnect the BFD session with the first device; A processing unit, configured to revoke routing information related to the first device from a routing forwarding table, and determine a fourth device based on recalculating the route; the fourth device is a downstream device of the third device, and the fourth device is an upstream device of the second device; the third device transmits traffic with the second device via the fourth device.

10. A traffic congestion control system, characterized in that: The traffic congestion control system includes a first device for executing the method according to any one of claims 1 to 4 and a third device for executing the method according to any one of claims 5 to 7.

Images