A network congestion processing method, device, storage medium and electronic device

Abstract

The embodiment of the application provides a network congestion processing method and device, a storage medium and an electronic device. The method comprises the following steps: receiving a forward service stream transmitted by a source end to a sink end; in the case that congestion of the forward service stream is detected and there exists a reverse service stream corresponding to the forward service stream, determining the reverse service stream of the sink end to the source end; inserting a reverse display congestion identifier into a data packet of the reverse service stream to obtain a processed reverse data packet; and sending the processed reverse data packet to the source end, so that the source end controls the service stream. The method can solve the problem that if the path is relatively long, the time from the discovery of congestion to the transmission to the sink end through the explicit congestion notification mechanism is relatively long, and the congestion processing is not timely, which leads to the aggravation of congestion. After the occurrence of congestion, the speed of the notification of the congestion information to the source end is accelerated, and thus the possibility of more serious congestion or even packet loss of the network can be reduced.

Description

Technical Field

[0001] This application relates to the field of communications, and more specifically, to a network congestion handling method, apparatus, storage medium, and electronic device. Background Technology

[0002] Explicit Congestion Notification (ECN) is a congestion control mechanism that, during packet forwarding, the transmission device compares a pre-defined explicit congestion notification threshold with the current queue buffer depth to determine whether to add an ECN congestion flag to the TOS (Type of Services) header of the IP packets in that queue. If the destination device receives a packet with an ECN congestion flag, it sends a Congestion Notification Packet (CNP) to the source device. The source device parses the CNP packet and implements congestion control and traffic scheduling based on predetermined congestion and traffic scheduling algorithms, such as reducing the flow rate, thereby reducing network congestion. Currently, it is primarily used in lossless networks within data centers.

[0003] Explicit congestion notification mechanisms incorporate the transmission network elements between the source and destination ends into the congestion control process, enabling network devices to sense and identify network congestion and collaborate with terminal systems to dynamically adjust network traffic. Explicit congestion control mechanisms offer higher congestion control quality and have become the mainstream congestion control technology for lossless networks.

[0004] Figure 1 This is an architecture diagram of the explicit congestion notification mechanism in related technologies, such as... Figure 1 As shown, device A detects congestion in the path and marks the data packet with a congestion flag in the TOS field of the IP header. The packet is still forwarded to the destination according to the normal forwarding process. The destination constructs a CNP packet using hardware and sends it to the source. After receiving the CNP packet, the source performs flow control according to a predetermined strategy. In this scheme, if the path is relatively long, the time from congestion detection to transmission to the destination is relatively long; coupled with the time it takes for the destination to send the CNP packet to the source, the congestion in the network may have already worsened.

[0005] There is currently no solution to the problem that if the path is long, the time from the discovery of congestion to the transmission to the destination through the explicit congestion notification mechanism is long, and the congestion is aggravated due to untimely congestion handling. Summary of the Invention

[0006] This application provides a network congestion handling method, apparatus, storage medium, and electronic device to at least solve the problem that if the path is long, the time from congestion detection to transmission to the destination through the explicit congestion notification mechanism is long, and the untimely congestion handling leads to the aggravation of congestion.

[0007] According to one embodiment of this application, a network congestion handling method is provided, the method comprising:

[0008] Receive the forward traffic flow transmitted from the source end to the destination end;

[0009] If congestion is detected in the forward service flow and a corresponding reverse service flow exists, the reverse service flow from the destination to the source is determined.

[0010] A reverse explicit congestion flag is inserted into the data packet of the reverse service flow to obtain the processed reverse data packet.

[0011] The processed reverse data packet is sent to the source end so that the source end can control the service flow.

[0012] According to another embodiment of this application, a network congestion processing apparatus is also provided, the apparatus comprising:

[0013] The receiving module is used to receive the forward service flow transmitted from the source end to the destination end;

[0014] The determination module is used to determine the reverse service flow from the destination to the source when congestion is detected in the forward service flow and a reverse service flow corresponding to the forward service flow exists.

[0015] The first insertion module is used to insert a reverse explicit congestion flag into the data packet of the reverse service flow to obtain a processed reverse data packet.

[0016] The first sending module is used to send the processed reverse data packet to the source end so that the source end can control the service flow.

[0017] According to yet another embodiment of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to perform the steps in any of the above method embodiments when it is run.

[0018] According to yet another embodiment of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0019] In this embodiment, a forward service flow transmitted from a source end to a destination end is received. If congestion is detected in the forward service flow and a corresponding reverse service flow exists, a reverse service flow from the destination end to the source end is determined. A reverse explicit congestion identifier is inserted into the data packet of the reverse service flow to obtain a processed reverse data packet. The processed reverse data packet is sent to the source end so that the source end can control the service flow. This addresses the problem that if the path is long, the explicit congestion notification mechanism takes a long time from congestion detection to transmission to the destination end, leading to delayed congestion handling and exacerbated congestion. By accelerating the speed at which congestion information is notified to the source end after congestion occurs, the possibility of more severe network congestion or even packet loss can be reduced. Attached Figure Description

[0020] Figure 1 This is an architecture diagram of the explicit congestion notification mechanism in related technologies;

[0021] Figure 2 This is a hardware structure block diagram of a mobile terminal for a network congestion handling method according to an embodiment of this application.

[0022] Figure 3 This is a flowchart of a network congestion handling method according to an embodiment of this application;

[0023] Figure 4 This is a schematic diagram of the bidirectional service flow between the source and destination ends according to this embodiment. Figure 1 ;

[0024] Figure 5 This is a schematic diagram of the bidirectional service flow between the source and destination ends according to this embodiment. Figure 2 ;

[0025] Figure 6 This is a diagram illustrating congestion in the service flow between the source and destination ends according to this embodiment. Figure 1 ;

[0026] Figure 7 This is a schematic diagram of bidirectional service flow based on SR-MPLS tunnel according to this embodiment;

[0027] Figure 8 This is a schematic diagram of the TTL field of the SR Path Label according to this embodiment;

[0028] Figure 9 This is a schematic diagram of the newly defined ECN guide label according to this embodiment;

[0029] Figure 10 This is a schematic diagram of a bidirectional service flow based on SRv6 according to this embodiment;

[0030] Figure 11This is a schematic diagram of the SRH Flags field according to this embodiment;

[0031] Figure 12 This is a diagram illustrating congestion in the service flow between the source and destination ends according to this embodiment. Figure 2 ;

[0032] Figure 13 This is a block diagram of a network congestion handling device according to this embodiment. Detailed Implementation

[0033] The embodiments of this application will be described in detail below with reference to the accompanying drawings and examples.

[0034] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0035] The methods and embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Taking running on a mobile terminal as an example, Figure 2 This is a hardware structure block diagram of a mobile terminal for a network congestion handling method according to an embodiment of this application, as shown below. Figure 2 As shown, a mobile terminal may include one or more ( Figure 2 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 2 The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 2 The more or fewer components shown, or having the same Figure 2 The different configurations shown.

[0036] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the network congestion handling method in this embodiment. The processor 102 executes various functional applications and service chain address pool slicing processing by running the computer program stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0037] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the mobile terminal's communication provider. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0038] This embodiment provides a network congestion handling method operating on the aforementioned mobile terminal or network architecture. Figure 3 This is a flowchart of a network congestion handling method according to an embodiment of this application, such as... Figure 3 As shown, the process includes the following steps:

[0039] Step S302: Receive the forward service flow transmitted from the source end to the destination end;

[0040] Step S304: If congestion is detected in the forward service flow and there is a reverse service flow corresponding to the forward service flow, determine the reverse service flow corresponding to the forward service flow from the destination to the source.

[0041] In this embodiment, the source and the destination are each other's source and destination. Forward service flow and reverse service flow are relative service flows. Forward service flow refers to the service flow that is congested, and reverse service flow is the service flow that is opposite to the forward service flow.

[0042] Step S306: Insert a reverse explicit congestion flag into the data packet of the reverse service flow to obtain the processed reverse data packet;

[0043] Step S308: The processed reverse data packet is sent to the source end so that the source end can control the service flow.

[0044] By using steps S302 to S308 above, the problem of congestion aggravation caused by the long time from the discovery of congestion to the destination when the explicit congestion notification mechanism is used can be solved. After congestion occurs, the speed at which congestion information is notified to the source can be accelerated, thereby reducing the possibility of more serious network congestion or even packet loss.

[0045] In this embodiment, step S304 may specifically include: determining the reverse service flow corresponding to the forward service flow based on the node information of the forward service flow; specifically, obtaining the reverse node information corresponding to the node information of the forward service flow; comparing the reverse node information with the node information of other service flows; determining that the service flow with the same comparison result is the reverse service flow corresponding to the forward service flow; or determining the reverse service flow corresponding to the forward service flow based on the SID information carried in the header of the data packet of the forward service flow; specifically, extracting the multi-layer tags of the header of the data packet of the forward service flow to obtain multiple SID (Segment ID, instruction identifier) ​​information from the outside to the inside; comparing the multiple SID information from the outside to the inside with the multiple SID information from the inside to the outside in the header of the data packet of other service flows; determining that the service flow with the same comparison result is the reverse service flow corresponding to the forward service flow.

[0046] In one embodiment, step S306 may specifically include: in a service scenario where the service flow is an SR-MPLS (Segment Routing-Multi-Protocol Label Switching) tunnel, the data packets of the reverse service flow are SR-MPLS packets; if the communication node is an intermediate node of an SR-TP (Segment Routing-Transport Profile) tunnel, the reverse explicit congestion flag is inserted into the pseudowire control word of the SR-MPLS packet; or the SR PATH of the SR-MPLS packet... The reverse explicit congestion flag is inserted into the TC or TTL field of the SID; or a new label is inserted into the SR-MPLS packet, and the reverse explicit congestion flag is inserted into the label to obtain the processed SR-MPLS packet; if the communication node is the terminus of the SR-TP tunnel, the SR-MPLS label of the SR-MPLS packet is stripped to obtain the IP packet, and the reverse explicit congestion flag is inserted into the TOS field of the IP packet, or the reverse explicit congestion flag is inserted into a newly defined option in the option field of the packet header of the IP packet to obtain the processed IP packet.

[0047] Correspondingly, step S308 above may specifically include: if the communication node is an intermediate node of the SR-TP tunnel, sending the processed SR-MPLS packet to the endpoint of the SR-TP tunnel, stripping the SR-MPLS label from the processed SR-MPLS packet through the endpoint of the SR-TP tunnel to obtain an IP packet, mapping the reverse explicit congestion flag in the SR-MPLS label to the IP packet to obtain a processed IP packet, and sending the processed IP packet to the source end; if the communication node is the endpoint of the SR-TP tunnel, sending the processed SR-MPLS packet to the source end.

[0048] In another embodiment, step S306 may further include: in a service scenario where the service flow is SRv6 (SegmentRouting version 6, source routing technology based on IPv6), the data packets of the reverse service flow are SRv6 packets, wherein the SRv6 packet includes the header and label stack SRH of the outer IPv6 (Internet Protocol version 6) packet, and the inner payload; if the communication node is SRv6... The intermediate node of the policy inserts the reverse explicit congestion flag into the TOS field of the IPv6 packet header, or inserts the reverse explicit congestion flag into the Flags field of the SRH, to obtain the processed SRv6 packet; if the communication node is the endpoint of the SRv6 policy, the reverse explicit congestion flag in the SRv6 packet is mapped to the IPv6 packet, including: inserting the reverse explicit congestion flag into the TOS field of the IPv6 packet header, or inserting the reverse explicit congestion flag into the extended header of the IPv6 packet, to obtain the processed IPv6 packet.

[0049] Correspondingly, step S308 above may specifically include: if the communication node is an intermediate node of the SRv6 policy, sending the processed SRv6 message to the endpoint of the SRv6 policy, mapping the reverse explicit congestion identifier in the processed SRv6 message to the IPv6 message to obtain the processed IPv6 message, and sending the processed IPv6 message to the source end; if the communication node is the endpoint of the SRv6 policy, sending the processed IPv6 message to the source end.

[0050] In an optional embodiment, the method further includes: when congestion is detected in the forward service flow and there is no reverse service flow, inserting a forward explicit congestion flag into the data packets of the forward service flow to obtain processed forward data packets; sending the processed forward data packets to a next node so that the next node determines the reverse service flow from the destination to the source and inserts a reverse explicit congestion flag into the data packets of the reverse service flow to obtain processed reverse data packets; and sending the processed reverse data packets to the source.

[0051] In this embodiment, the service between the source and destination is a bidirectional flow, with each end serving as the source and destination for the other. Figure 4 This is a schematic diagram of the bidirectional service flow between the source and destination ends according to this embodiment. Figure 1 ,like Figure 4 As shown, the service flows in both directions follow completely identical paths in the network; or, Figure 5 This is a schematic diagram of the bidirectional service flow between the source and destination ends according to this embodiment. Figure 2 ,like Figure 5 As shown, the path portions of the service flows in both directions are consistent within the network. This fully utilizes the bidirectional and symmetrical nature of the service flows. When congestion occurs at a node in the network for a service flow in one direction, that node directly inserts a reverse explicit congestion flag into the data packets of the reverse flow. The congestion information reaches the source of the congested flow through the reverse flow, and the source takes flow control actions. Compared to the standard ECN scheme, it does not require dedicated protocol packets, making the scheme simpler and requiring less equipment. This scheme can improve the response speed to network congestion. In this embodiment, this scheme is called reverse flow explicit congestion flag.

[0052] Figure 6 This is a diagram illustrating congestion in the service flow between the source and destination ends according to this embodiment. Figure 1 ,like Figure 6 As shown, the source and destination devices notify the network devices by including an identifier that supports the reverse flow explicit congestion identification function in the packet header.

[0053] Flow 1 in direction A experiences congestion at device B in the network. The congestion assessment criteria continue to use the ECN mechanism, which can be based on the queue buffer depth exceeding a set threshold, the packet queuing delay exceeding a set threshold, and some enhanced dynamic threshold mechanisms based on AI algorithms.

[0054] Device B searches for the reverse flow of flow 1, and finds that the reverse flow is flow 2.

[0055] Device B inserts an explicit congestion flag into the header of Flow 2 packets. The specific insertion location depends on the packet encapsulation format, such as ordinary IP, MPLS-TP, SRv4, SRv6, etc. Leveraging the widespread bidirectional nature and bidirectional path consistency of services in wide area networks, congestion information from the forward flow is quickly communicated to the source via the reverse flow, fully utilizing packet forwarding mechanisms and packet overhead definitions to transmit congestion information.

[0056] The source of the congested flow is Source / Destination 1. When the device receives a packet from Flow 2, it analyzes the packet header and finds an explicit congestion flag indicating a reverse flow. It then immediately initiates flow control according to the pre-set flow control mechanism, which can still use the existing ECN mechanism, such as reducing the sending rate of Flow 1 for a certain period of time.

[0057] like Figure 4 As shown, in a scenario where the bidirectional flow paths are completely identical, each node can implement the solution of this embodiment when congestion occurs; as Figure 5 As shown, in scenarios where the bidirectional flow paths are partially consistent, nodes with consistent paths can implement the technical solution of this embodiment, while nodes with inconsistent paths can adopt the solution in embodiment 3.

[0058] In this embodiment, the reverse flow is located. Wide area networks (WANs) involve various technologies, among which MPLS and SR are the two most widely used technologies in WANs. This embodiment mainly focuses on these two technologies.

[0059] MPLS-TP (Multi-Protocol Label Switching-Transport Profile) tunnels are a typical example of tunnels that bind two unidirectional MPLS-TE (Multi-Protocol Label Switching-Traffic Engineering) tunnels with opposite directions but consistent paths. This bidirectional path consistency facilitates network management. In the forwarding table entries of network devices, the flow point information is interconnected. The flow point information of flow 2 can be easily found through the flow point of flow 1. Once the flow point information of flow 2 is found, reverse congestion identification information can be inserted into the packets of flow 2. As shown in Table 1, the inflow point of flow 1 is the outflow point of flow 2, and the outflow point of flow 2 is the inflow point of flow 1. Therefore, the reverse flow can be easily found through either flow 1 or flow 2. Utilizing the relevant entries of the two flows in the forwarding table for reverse flow lookup is fast and efficient.

[0060] Table 1

[0061] Stream 1 Stream 2 Inflow point 131046 131045 Outflow point 131045 131046

[0062] SRv6 technology is a new technology combining IPv6 and SR, and will be widely deployed in wide area networks. Each SRv6 packet carries the segment ID information for each hop in its SRH header. Network devices can find the reverse flow by comparing the segment ID information carried in the SRH header. As shown in Table 2, the SRH portion of Flow 1's packet header has five layers of labels, with the first to fifth labels being 1001, 1002, 1003, 1004, and 1005 respectively. Flow 2 also contains five layers of labels, and the label order is exactly the reverse of Flow 1. Therefore, Flow 1 and Flow 2 can be determined to be reverse flows. Utilizing the information carried in service packets to find the reverse flow is also one method for identifying directional flows.

[0063] Table 2

[0064] Stream 1 Stream 2 The first SID 1001 1005 2nd SID 1002 1004 3rd SID 1003 1003 4th SID 1004 1002 5th SID 1005 1001

[0065] In this embodiment, under the scenario of bidirectional service flow and completely or partially identical network paths, the transmission mechanism after congestion detection is optimized, which can accelerate the transmission speed of congestion information and thus enable faster flow control measures. This can significantly reduce the probability of further network congestion and contribute to achieving zero packet loss and low latency. It is highly necessary to deploy this in lossless networks and networks with high requirements for packet loss and latency performance, especially complex LANs or WANs. Combining the main WAN technologies MPLS and SR, a method for reverse flow identification is presented, along with a specific method for carrying congestion identification information through the reverse flow. This is an important component for the future realization of lossless (zero packet loss, low latency) WANs.

[0066] In SR-MPLS tunnel-based service scenarios, within SPN (Slicing Packet Network) networks (ITU-T MTN (Metro Transport Network) standard), SR-TP tunnels are the most commonly used tunnel type, providing connection-oriented, bidirectional path-consistent services to customers. SR-TP tunnels are an extension of unidirectional SR-TE (Segment Routing-Traffic Engineering) tunnels, equivalent to binding two SR-TE tunnels with completely identical paths but opposite directions. SR-TP tunnel-based service scenarios are one of the typical scenarios in this embodiment: service flows in both directions with consistent paths.

[0067] Figure 7 This is a schematic diagram of bidirectional service flow based on an SR-MPLS tunnel according to this embodiment, as shown below. Figure 7As shown, SR-TE1 and SR-TE2 are two unidirectional TE tunnels of a single SR-TP tunnel. Node B detects congestion in a queue service carried by SR-TE1 tunnel. Node B inserts a reverse flow explicit congestion flag into the data packets of SR-TE2 tunnel. The specific insertion location could be: 1) in the pseudowire control word; 2) in the TC field or TTL (Time To Live) field of the SR PATH SID (this field can be reused, and the current TTL has no value). Figure 8 This is a schematic diagram of the TTL field of the SR Path Label according to this embodiment, as shown below. Figure 8 As shown; 3) A new label can be inserted for flow control, where the TC field or TTL field is used to identify the explicit congestion type. Figure 9 This is a schematic diagram of the newly defined ECN boot label according to this embodiment, as shown below. Figure 9 As shown. Node A is the endpoint (PE node) of the SR-TP tunnel. The endpoint needs to strip the SR-MPLS label forwarded by the network, therefore, the reverse flow explicit congestion flag in the SR-TP label needs to be mapped to the IP packet. The location of the reverse flow explicit congestion flag in the IP packet is as follows: 1) TOS bits 6 and 7, 01 and 10 are used to mark support for ECN. 01 can be used to mark support for ECN, and 10 is used as the reverse flow explicit congestion flag; 2) The definition of the TOS field in the IP packet has been unstable. In practice, the most commonly used is 8 service priorities, i.e., 3 bits. 3 bits can be used as the ECN field, adding support for reverse flow ECN, the reverse flow explicit congestion flag, and other ECN extensions. 3) IPv4: A new option is defined in the option field of the packet header. When the source / destination 1 receives a packet with the reverse flow explicit congestion flag, it takes flow control measures according to the predetermined flow control mechanism.

[0068] In SRv6-based service scenarios, SRv6 is an SR technology architecture based on IPv6. Due to its excellent scalability, it has been commercially deployed and continues to develop rapidly. Unlike SR-TP, in some scenarios, the network paths for a single service are consistent in both directions, while in others they may be partially consistent. As mentioned earlier, in the case of partial consistency, network elements with consistent paths can still use reverse flow to display congestion indicators.

[0069] Figure 10 This is a schematic diagram of a bidirectional service flow based on SRv6 according to this embodiment, as shown below. Figure 10As shown, SRv6policy1 and SRv6policy2 are two-way unidirectional tunnels carried by a single SRv6 service. Node B detects congestion in a queue carried by SRv6policy1. Node B inserts a reverse flow explicit congestion flag into the datagrams carried by SRv6policy2. The specific insertion location could be: 1) the TOS field in the IPv6 header (see the description in the SR-MPLS tunnel-based service scenario above); or 2) the Flags field in the SRH header. Figure 11 This is a schematic diagram of the SRH Flags field according to this embodiment, as shown below. Figure 11 As shown. Node A is the endpoint (PE node) of the SRv6 policy and needs to map the reverse flow explicit congestion flag in the SRv6 policy message to the IPv6 message. The location of the reverse flow explicit congestion flag in the IPv6 message is as follows: 1) If the location where Node B is inserted is the IPv6 message header, then it is continued in the TOS field of the IPv6 message header; 2) A new IPv6 extended header is defined.

[0070] In scenarios where the bidirectional flow paths are partially consistent, similar scenarios also exist in the existing network. For the portion of the bidirectional flow paths that are consistent, the aforementioned solution can be used. If congestion occurs at devices where the bidirectional flows are inconsistent (e.g., the forward flow passes through a network element, but the reverse flow does not), then the solution in this embodiment needs to be adopted. This solution can be summarized as a combination of explicit forward congestion control and explicit reverse congestion control. Figure 12 This is a diagram illustrating congestion in the service flow between the source and destination ends according to this embodiment. Figure 2 ,like Figure 12 As shown, device B detects congestion in service flow 1; there is no reverse flow 2 of service flow 1 on device B, and device B inserts a forward explicit congestion flag on flow 1; device D receives the forward explicit congestion flag on flow 1; and inserts a reverse explicit congestion flag on flow 2 on its own device.

[0071] According to another embodiment of this application, a network congestion processing apparatus is also provided. Figure 13 This is a block diagram of a network congestion handling device according to this embodiment, such as... Figure 13 As shown, the device includes:

[0072] The receiving module 132 is used to receive the forward service flow transmitted from the source end to the destination end;

[0073] The determination module 134 is used to determine the reverse service flow from the destination to the source when congestion is detected in the forward service flow and a reverse service flow corresponding to the forward service flow exists.

[0074] The first insertion module 136 is used to insert a reverse display congestion flag into the data packet of the reverse service flow to obtain a processed reverse data packet.

[0075] The first sending module 138 is used to send the processed reverse data packet to the source end so that the source end can control the service flow.

[0076] In one embodiment, the determining module 134 includes:

[0077] The first determining submodule is used to determine the reverse service flow corresponding to the forward service flow based on the node information of the forward service flow; or

[0078] The second determining submodule is used to determine the reverse service flow corresponding to the forward service flow based on the SID information carried in the header of the data packet of the forward service flow.

[0079] In one embodiment, the first determining submodule is further configured to obtain reverse node information corresponding to the node information of the forward service flow; compare the reverse node information with the node information of other service flows respectively; and determine that the service flows with the same comparison result are the reverse service flows corresponding to the forward service flow.

[0080] In one embodiment, the second determining submodule is further configured to extract multi-layer tags from the header of the data packet of the forward service flow to obtain multiple SID information from the outside to the inside; compare the multiple SID information from the outside to the inside with the multiple SID information from the inside to the outside in the header of the data packet of other service flows; and determine that the service flow with the same comparison result is the reverse service flow corresponding to the forward service flow.

[0081] In one embodiment, the first insertion module 136 is further configured to: in a service scenario where the service flow is an SR-MPLS tunnel, where the data packet of the reverse service flow is an SR-MPLS packet; if the communication node is an intermediate node of the SR-TP tunnel, insert the reverse explicit congestion identifier into the pseudowire control word of the SR-MPLS packet; or insert the reverse explicit congestion identifier into the TC field or TTL field of the SR PATH SID of the SR-MPLS packet; or insert a new label into the SR-MPLS packet and insert the reverse explicit congestion identifier into the label to obtain a processed SR-MPLS packet; if the communication node is the endpoint of the SR-TP tunnel, strip the SR-MPLS label of the SR-MPLS packet to obtain an IP packet, insert the reverse explicit congestion identifier into the TOS field of the IP packet, or insert the reverse explicit congestion identifier into a newly defined option in the option field of the header of the IP packet to obtain a processed IP packet.

[0082] In one embodiment, the first sending module 138 is further configured to, if the communication node is an intermediate node of the SR-TP tunnel, send the processed SR-MPLS packet to the endpoint of the SR-TP tunnel, strip the SR-MPLS label from the processed SR-MPLS packet through the endpoint of the SR-TP tunnel to obtain an IP packet, map the reverse explicit congestion flag in the SR-MPLS label to the IP packet to obtain a processed IP packet, and send the processed IP packet to the source end; if the communication node is the endpoint of the SR-TP tunnel, send the processed SR-MPLS packet to the source end.

[0083] In one embodiment, the first insertion module 136 is further configured to: in a service scenario where the service flow is SRv6, the data packet of the reverse service flow is an SRv6 packet, wherein the SRv6 packet includes the header and label stack SRH of the outer IPv6 packet, and the payload of the inner packet; if the communication node is an intermediate node of the SRv6 policy, insert the reverse explicit congestion identifier into the TOS field of the header of the IPv6 packet, or insert the reverse explicit congestion identifier into the Flags field of the SRH, to obtain a processed SRv6 packet; if the communication node is an endpoint of the SRv6 policy, map the reverse explicit congestion identifier in the SRv6 packet to the IPv6 packet, including: inserting the reverse explicit congestion identifier into the TOS field of the header of the IPv6 packet, or inserting the reverse explicit congestion identifier into the extended header of the IPv6 packet, to obtain a processed IPv6 packet.

[0084] In one embodiment, the first sending module 138 is further configured to: if the communication node is an intermediate node of the SRv6 policy, send the processed SRv6 message to the endpoint of the SRv6 policy; obtain a processed IPv6 message by mapping the reverse explicit congestion identifier in the processed SRv6 message to the IPv6 message; and send the processed IPv6 message to the source end; if the communication node is the endpoint of the SRv6 policy, send the processed IPv6 message to the source end.

[0085] In one embodiment, the device further includes:

[0086] The second insertion module is used to insert a forward display congestion flag into the data packets of the forward service flow when congestion is detected in the forward service flow and there is no reverse service flow, so as to obtain a processed forward data packet.

[0087] The second sending module is used to send the processed forward data packet to the next node, so that the next node can determine the reverse service flow from the destination to the source, insert a reverse explicit congestion identifier into the data packet of the reverse service flow, and obtain the processed reverse data packet; and send the processed reverse data packet to the source.

[0088] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when run.

[0089] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0090] Embodiments of this application also provide an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0091] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0092] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0093] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

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

Claims

1. A network congestion handling method applied to a communication node, characterized in that, The method comprises: receiving a forward service stream transmitted by a source end to a sink end; in a case where congestion of the forward service stream is detected and a reverse service stream corresponding to the forward service stream exists, determining a reverse service stream of the sink end to the source end; inserting a reverse display congestion identifier into a data packet of the reverse service stream to obtain a processed reverse data packet; sending the processed reverse data packet to the source end to enable the source end to control the service stream.

2. The method of claim 1, wherein, The determination of the reverse service stream of the sink end to the source end comprises: determining the reverse service stream corresponding to the forward service stream according to node information of the forward service stream; or determining the reverse service stream corresponding to the forward service stream according to SID information carried in a packet header of a data packet of the forward service stream.

3. The method of claim 2, wherein, The determination of the reverse service stream corresponding to the forward service stream according to node information of the forward service stream comprises: obtaining reverse node information corresponding to the node information of the forward service stream; respectively comparing the reverse node information with node information of other service streams; and determining that a service stream with a same comparison result is the reverse service stream corresponding to the forward service stream.

4. The method of claim 2, wherein, The determination of the reverse service stream corresponding to the forward service stream according to SID information carried in a packet header of a data packet of the forward service stream comprises: extracting a plurality of SID information from outside to inside from a plurality of labels of the packet header of the data packet of the forward service stream; respectively comparing the plurality of SID information from outside to inside with a plurality of SID information from inside to outside in a packet header of a data packet of other service streams; and determining that a service stream with a same comparison result is the reverse service stream corresponding to the forward service stream.

5. The method of claim 1, wherein, The insertion of the reverse display congestion identifier into the data packet of the reverse service stream to obtain the processed reverse data packet comprises: in a service scenario where the service stream is an SR-MPLS tunnel, the data packet of the reverse service stream is an SR-MPLS packet; if the communication node is an intermediate node of an SR-TP tunnel, the reverse display congestion identifier is inserted into a pseudo-wire control word of the SR-MPLS packet, or the reverse display congestion identifier is inserted into a TC field or a TTL field of an SR PATH SID of the SR-MPLS packet, or a label is newly inserted into the SR-MPLS packet, and the reverse display congestion identifier is inserted into the label to obtain a processed SR-MPLS packet; if the communication node is a terminal node of the SR-TP tunnel, an SR-MPLS label of the SR-MPLS packet is stripped to obtain an IP packet, and the reverse display congestion identifier is inserted into a TOS field of the IP packet or an option field newly defined in a packet header of the IP packet to obtain a processed IP packet.

6. The method of claim 5, wherein, The sending of the processed reverse data packet to the source end comprises: If the communication node is an intermediate node of the SR-TP tunnel, sending the processed SR-MPLS packet to a terminal node of the SR-TP tunnel, stripping the SR-MPLS label of the processed SR-MPLS packet through the terminal node of the SR-TP tunnel to obtain an IP packet, and mapping the reverse display congestion identifier in the SR-MPLS label to the IP packet to obtain a processed IP packet, and sending the processed IP packet to the source end; If the communication node is a terminal node of the SR-TP tunnel, sending the processed SR-MPLS packet to the source end.

7. The method of claim 1, wherein, Inserting a reverse display congestion identifier into the data packet of the reverse service flow to obtain a processed reverse data packet, including: In the service scenario where the service flow is SRv6, the data packet of the reverse service flow is an SRv6 packet, wherein the SRv6 packet includes a packet header and a label stack SRH of an outer IPv6 packet, and a payload of an inner layer; If the communication node is an intermediate node of the SRv6 policy, inserting the reverse display congestion identifier into a TOS field of the packet header of the IPv6 packet or into a Flags field of the SRH to obtain a processed SRv6 packet; If the communication node is a terminal node of the SRv6 policy, mapping the reverse display congestion identifier in the SRv6 packet to an IPv6 packet, including: inserting the reverse display congestion identifier into a TOS field of a packet header of the IPv6 packet or into an extended packet header of the IPv6 packet to obtain a processed IPv6 packet.

8. The method of claim 7, wherein, Sending congestion information to the source end through the processed reverse data packet, including: If the communication node is an intermediate node of the SRv6 policy, sending the processed SRv6 packet to a terminal node of the SRv6 policy, mapping the reverse display congestion identifier in the processed SRv6 packet to an IPv6 packet to obtain a processed IPv6 packet, and sending the processed IPv6 packet to the source end; If the communication node is a terminal node of the SRv6 policy, sending the processed IPv6 packet to the source end.

9. The method according to any one of claims 1 to 8, characterized in that, The method further includes: In a case where the forward service flow is detected to have congestion and the reverse service flow does not exist, inserting a forward display congestion identifier into a data packet of the forward service flow to obtain a processed forward data packet; Sending the processed forward data packet to a next node, so that the next node determines a reverse service flow of the sink end to the source end, inserts a reverse display congestion identifier into a data packet of the reverse service flow to obtain a processed reverse data packet, and sends the processed reverse data packet to the source end.

10. A network congestion handling apparatus, characterized by, The apparatus includes: a receiving module configured to receive a forward service flow transmitted by a source end to a sink end; The determining module is configured to determine a reverse service flow from the sink end to the source end when it is detected that the forward service flow is congested and there is a reverse service flow corresponding to the forward service flow. The first inserting module is configured to insert a reverse display congestion identifier into a data packet of the reverse service flow to obtain a processed reverse data packet. The first sending module is configured to send the processed reverse data packet to the source end so that the source end performs control on the service flow.

11. A computer-readable storage medium having stored therein a computer program, wherein, The computer program is configured to execute the method in any one of claims 1 to 9 when running. 12.An electronic device comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the computer program to perform the method in any one of claims 1 to 9.

Images