Broadcast storm suppression and QoS (Quality of Service) port identification method in ad hoc network scene

Abstract

The invention discloses a broadcast storm suppression and QoS (Quality of Service) port identification method in an ad hoc network scene, which comprises the following steps: after receiving an IP (Internet Protocol) data packet, a host determines whether the IP data packet is a broadcast message and detects whether a fragment mapping table corresponds to the IP data packet; according to the information of the IP header and the transport layer port, whether QoS port mapping needs to be carried out on the IP data packets is judged, and the types of the IP data packets are divided into two types, namely ports which do not need to be identified and ports which need to be identified; the method comprises the following steps: determining a service type of a service flow through a port number, dividing the received service flow into different priorities, adding the IP data packets which are subjected to classification processing and do not need port identification and the IP data packets of which the service types have been determined into a self-defined packet header for packaging according to the priorities and other service information, and subsequent QoS processing is facilitated. According to the method, the quintuple information and other related information are extracted from the IP data packet to establish the fragment mapping table, so that the port mapping method required by broadcast storm suppression and QoS flow classification can be realized at the same time, the processing flow is simplified, and system resources are saved.

Description

Technical Field

[0001] The invention relates to a self-organizing network, and in particular to a broadcast storm suppression and QoS port identification method in a self-organizing network scenario. Background Art

[0002] With its unique characteristics of multi-hop, flexibility and anti-destruction, ad hoc networks have shown very broad application prospects in environments such as military communications and emergency rescue that urgently need to establish temporary and rapid networks. In the data link constructed by ad hoc networks, the data of various sensors or peripherals are first connected to the ad hoc network nodes through wired means, and then these data are transmitted to other ad hoc network nodes through the wireless interface (or wireless air interface) of the ad hoc network nodes, thereby realizing the interconnection between devices.

[0003] In the wired + wireless communication scenario of an ad hoc network, broadcast communication may encounter the problem of broadcast storms. Broadcast, as a "one-to-all" communication mode between hosts, means that a host sends data to all hosts in the subnet through a predefined fixed IP address. When all hosts receive this data, they will unconditionally copy and forward it. However, as a fault phenomenon in broadcast communication, broadcast storms are often caused by defects in network protocols or improper network configuration, resulting in a closed loop between the links of the hosts. In this case, broadcast data packets will continue to circulate in the ring and be copied in large quantities, which will cause network congestion and even network paralysis in severe cases.

[0004] When the size of the transmitted data packet exceeds the MTU (maximum transmission unit) of the link, IP data packet fragmentation occurs, that is, the complete packet is divided into smaller fragments to ensure that they can be successfully transmitted. However, in the fragmented data packet, except for the first fragment that contains complete source port and destination port information, other fragments usually do not contain this information. Therefore, QoS traffic identification and classification based on port mapping cannot be performed on these fragments.

[0005] For suppression of broadcast storms, when a loop has been formed, the TTL (time to live) field of the IP data packet itself is mainly used to prevent the data packet from circulating infinitely in the loop. However, the data packet will still circulate a limited number of times in the loop, still occupying a large amount of network bandwidth and system resources, increasing the network burden.

[0006] There are currently several solutions to the problem of being unable to identify the fragmented packet port. For example, the service identification field in the IP packet header can be redefined, but this method requires modifying the protocol stack, which is relatively complicated and may cause other possible problems. There is also path MTU discovery, which is to discover the MTU on the network transmission path by trying to send data packets. When the data is subsequently sent, the packet size is controlled to be less than or equal to the MTU value to avoid fragmentation, but this method will reduce network utilization and will be difficult to sustain when the network is unstable and the transmission path changes dramatically.

[0007] As can be seen from the above, the current solutions to the two problems of broadcast storm and the inability to perform QoS port mapping on IP fragments still have different defects, and each only solves one of them, and does not combine them to solve them simultaneously. Summary of the invention

[0008] The purpose of the present invention is to provide a broadcast storm suppression and QoS port identification method in a self-organizing network scenario.

[0009] The technical solution to achieve the purpose of the present invention is: a method for suppressing broadcast storms and identifying QoS ports in an ad hoc network scenario, comprising:

[0010] Step 1, preprocessing of IP data packets: After receiving the IP data packet, the host determines whether the IP data packet is a broadcast message and detects whether there is a corresponding fragment mapping table;

[0011] Step 2, classification processing of IP data packets: According to the information of IP header and transport layer port, determine whether the IP data packet needs QoS port mapping, and divide the types of IP data packets into two categories, those that do not need to identify ports and those that need to identify ports;

[0012] Step 3, subsequent processing of IP data packets: determine the service type of the service flow by the port number, divide the received service flow into different priorities, and for IP data packets that do not require port identification after classification and IP data packets whose service types have been determined, add a custom packet header to the IP data packet for encapsulation based on the priority and other service information to facilitate subsequent QoS processing.

[0013] Furthermore, the IP data packet contains two parts of information, including:

[0014] One part is the field containing specific information in the IP data packet header, including 16-bit ID identification, 3-bit identification bit, 13-bit fragment offset, 8-bit protocol type, 32-bit source IP address and 32-bit destination IP address. The 16-bit ID identification field means that the IP software maintains a counter in the memory. Every time a data packet is generated, the counter is increased by 1 and this value is assigned to the identification field. When fragmentation occurs, the value of this identification field is copied to the ID identification field of all fragment packets of the same source; the second DF of the 3-bit identification bit indicates whether it can be fragmented, 0 indicates fragmentation, and 1 indicates that it cannot be fragmented; the third MF indicates whether the message is the last fragment, 0 indicates the last fragment, and 1 indicates that there are more fragments behind; the 13-bit fragment offset field refers to the relative position of a fragment in the original packet after fragmentation occurs. If there is no fragmentation, the default value here is 0; the 8-bit protocol type field identifies the protocol type of the information contained in the current data packet; the 32-bit source IP address and the 32-bit destination IP address refer to the host IP address that sends the current IP data packet and the host IP address that receives the current data packet;

[0015] The other part is the port information of the transport layer message contained in the IP data packet, including the 16-bit source port number and 16-bit destination port number information in the transport layer data packet header. The 16-bit source port number field is used to identify the sending process, and the 16-bit destination port number field is used to identify the receiving process.

[0016] Furthermore, the shard mapping table is established in the form of a hash table combined with a bidirectional linked list, where:

[0017] The key code of the hash table is the index of the shard mapping table, which is obtained by performing a hash operation on the source IP address, destination IP address and ID extracted from the IP data packet. The data stored in the shard mapping table is the ID, source port, destination port, shard offset and linked list pointer.

[0018] The hash function uses the remainder method. Suppose the number of addresses allowed in the hash table is M, and take a prime number p that is not greater than M but closest to or equal to M as the divisor. Use the following hash function to convert the key into a hash address:

[0019] Hash(key)=key%p,p<=M

[0020] The Key is composed of 32-bit source IP address + 32-bit destination IP address + 16 ID identifiers. The value of M is determined according to the size of the point-to-point traffic per second in the communication network. The factor considered is to minimize the table lookup time.

[0021] The bidirectional linked list is used to maintain the access order of the shard mapping table, that is, the nodes closer to the head of the linked list represent the shard mapping table that is more recently used, and the nodes closer to the tail of the linked list represent the shard mapping table that has not been used for a long time.

[0022] Further, step 1, pre-processing of IP data packets: after receiving the IP data packet, the host determines whether the IP data packet is a broadcast message and detects whether there is a corresponding fragment mapping table. The specific method is as follows:

[0023] 1.1) After receiving the IP data packet, the host detects whether the 32-bit destination IP address of the IP data packet is a broadcast address based on the fact that the destination IP address of the broadcast message is predetermined and fixed, and determines whether the IP data packet is a broadcast message:

[0024] a. If it is a broadcast message, proceed to the next step to check whether there is a corresponding fragment mapping table;

[0025] b. If it is not a broadcast message, only fragmented IP packets are identified in the subsequent processing of IP packets;

[0026] 1.2) Check whether there is a corresponding shard mapping table:

[0027] If there is a fragment mapping table corresponding to the IP data packet, the IP data packet is discarded;

[0028] If not, all IP data packets are identified in the subsequent processing of IP data packets.

[0029] Further, step 2, classification processing of IP data packets: according to the information of IP header and transport layer port, determine whether the IP data packet needs QoS port mapping, and divide the types of IP data packets into 2 categories, those that do not need to identify ports and those that need to identify ports. The specific method is as follows:

[0030] 2.1) According to the information of IP header and transport layer port, determine whether the IP data packet needs QoS port mapping, and divide the types of IP data packets into two categories, including those that do not need to identify the port and those that need to identify the port;

[0031] 2.2) For IP packets that do not require port identification:

[0032] a. If it is not a broadcast message, there is no need to establish a fragmentation mapping table. Just add a custom packet header encapsulation and perform subsequent QoS processing;

[0033] b. If it is a broadcast message, after establishing the fragmentation mapping table, add a custom packet header encapsulation and perform subsequent QoS processing;

[0034] 2.3) For IP packets that require port identification, they are classified according to the 3-bit identification bit and 13-bit offset in the IP header and are divided into the following three categories:

[0035] a. Complete packet: There are two cases. The first case is a packet that cannot be fragmented. The second DF bit of the 3-bit flag bit of the IP header is 1. The second case is a packet that can be fragmented, but not fragmented. The second DF bit of the 3-bit flag bit of the IP header is 0, the third MF bit is 0, and the 13-bit fragment offset of the IP header is 0.

[0036] b. First fragment: The identification method is that the second DF bit of the 3-bit flag bit of the IP header is 0, the third MF bit is 1, and the 13-bit fragment offset of the IP header is 0;

[0037] c. Non-first fragment: The identification method is that the second DF bit of the 3-bit flag bit of the IP header is 0, the third MF bit is 1, and the 13-bit fragment offset of the IP header is not 0;

[0038] 2.4) For the complete package:

[0039] a. If it is not a broadcast message, there is no need to establish a fragmentation mapping table, and the QoS service type can be determined directly based on the port;

[0040] b. If it is a broadcast message, after establishing the fragmentation mapping table, the QoS service type is determined according to the port;

[0041] 2.5) For the first packet, after establishing the fragment mapping table, determine the QoS service type according to the port;

[0042] 2.6) For non-first fragment packets, extract the IP header information and match it with the existing fragment mapping table:

[0043] a. If there is a corresponding fragment mapping table, extract the port information recorded in the fragment mapping table, and detect whether all homologous fragments are recognized according to the fragment offset;

[0044] b. If there is no fragmentation packet corresponding to the fragmentation mapping table, proceed to 2.7) fragmentation disorder processing flow;

[0045] 2.7) Check whether all homologous fragments are recognized based on the fragment offset. That is, based on the 13-bit fragment offset of the IP header, add the fragment offsets of all homologous fragments that have been processed except the last fragment. When the accumulated value is equal to the fragment offset of the last fragment received, it indicates that all homologous fragments have been recognized. There are two cases:

[0046] a. Identify all the same-source fragments: Actively delete the fragment mapping table and determine the QoS service type based on the port;

[0047] b. If all fragments of the same source are not identified, the fragment mapping table is retained and the QoS service type is determined directly based on the port.

[0048] A broadcast storm suppression and QoS port identification system in a self-organizing network scenario implements the broadcast storm suppression and QoS port identification method in a self-organizing network scenario to achieve broadcast storm suppression and QoS port identification in a self-organizing network scenario.

[0049] Compared with the prior art, the present invention has the following significant advantages: by extracting quintuple information and other related information from IP data packets to establish a fragment mapping table, a method for simultaneously realizing the port mapping required for broadcast storm suppression and QoS traffic classification can be achieved, which not only simplifies the processing flow but also saves system resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Figure 1 Schematic diagram of data link of ad hoc network.

[0051] Figure 2 This is the broadcast storm topology diagram.

[0052] Figure 3 This is a schematic diagram of IP fragmentation.

[0053] Figure 4 This is a diagram showing the relationship between broadcast storm suppression and QoS port mapping.

[0054] Figure 5 This is a diagram of the IP data packet format.

[0055] Figure 6 This is a diagram of the UDP message format.

[0056] Figure 7 A schematic diagram of the shard mapping table.

[0057] Figure 8 The following is a schematic diagram of the correspondence between the hash table key value and the shard mapping table.

[0058] Fig. 9 This is a schematic diagram of the bidirectional linked list structure and the shard mapping table content.

[0059] Fig.10 The flowchart of the broadcast storm suppression and QoS port identification method in the self-organizing network scenario.

[0060] Fig.11 This is a flowchart of the preprocessing of IP data packets.

[0061] Fig.12 This is a flowchart of the processing of IP data packets in Example 1.

[0062] Fig.13This is a flowchart of the processing of IP data packets in Example 2. DETAILED DESCRIPTION

[0063] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0064] When a host in the network broadcasts, other nodes receive the broadcast IP data packet and continue to broadcast the IP data packet. If the host cannot identify whether the received broadcast message is previously received, a loop will be formed between multiple hosts (such as Figure 2 ), so that the broadcast IP data packets are repeated in this loop, resulting in a broadcast storm, causing network congestion and even paralysis. A fragment mapping table is established for all broadcast messages to record the reception status of the broadcast messages.

[0065] When the host receives a broadcast message again, the present invention matches the information of the IP data packet with the fragment mapping table. If the match is successful, it means that the broadcast message is a duplicate message and is directly discarded, thereby effectively suppressing the broadcast storm. Similarly, when a fragment mapping table is established only for the fragment data packet, the problem that the QoS port cannot be identified after IP fragmentation can be solved. When a group of IP fragment packets of the same source arrive, the IP data packet header information of the first fragment and the upper transport layer port information are extracted to establish a fragment mapping table. When subsequent non-first fragment packets arrive, the information of their IP headers is extracted and matched with the existing fragment mapping table. After the match is successful, the port information of the upper transport layer is extracted from the fragment mapping table, thereby meeting the requirements of QoS service type classification and identification. In addition, in order to solve the problem of disordered internal transmission, a custom packet header can be added when the port identification is completed and the data packet is transmitted to the lower layer.

[0066] The present invention needs to extract two parts of information in the IP data packet, one part is several fields containing specific information in the IP data packet header, and the other part is the port information of the transport layer message contained in the IP data packet. Figure 5 It is the message format of IP data packet.

[0067] There are multiple fields with different meanings in the header of an IP data packet. By extracting the information from these fields, an IP data packet or a group of fragment packets of the same source can be specifically identified. Among them, the fields to be extracted are 16-bit ID identification, 3-bit identification bit, 13-bit fragment offset, 8-bit protocol type, 32-bit source IP address and 32-bit destination IP address. The 16-bit ID identification field means that the IP software maintains a counter in the memory. Every time a data packet is generated, the counter is increased by 1 and this value is assigned to the identification field. When fragmentation occurs, the value of this identification field is copied to the ID identification field of all fragment packets of the same source. The second bit DF (Don't Fragment) of the 3-bit identification bit refers to: whether it can be fragmented, 0 means it can be fragmented, 1 means it cannot be fragmented; the third bit MF (More Fragment) means whether the message is the last fragment, 0 means the last fragment, 1 means there are more fragments. The 13-bit fragment offset field refers to the relative position of a fragment in the original packet after fragmentation occurs. If there is no fragmentation, the default value here is 0. The 8-bit protocol type field identifies the protocol type of the information contained in the current data packet. The 32-bit source IP address and 32-bit destination IP address refer to the host IP address that sends the current IP data packet and the host IP address that receives the current data packet.

[0068] At the same time, in order to meet the port mapping requirements in QoS service type classification and identification in the IP fragmentation scenario, it is also necessary to extract the 16-bit source port number and 16-bit destination port number information of the transport layer packet header contained in the IP packet. Figure 6 As shown, the 16-bit source port number field is used to identify which application sends (sending process), and the 16-bit destination port number field is used to identify which application receives (receiving process).

[0069] The specific method for forming, establishing, matching and deleting the shard mapping table in the present invention is as follows:

[0070] (1) Composition of the shard mapping table

[0071] The shard mapping table is built in the form of a hash table combined with a doubly linked list: the hash table is used to store key-value pairs to achieve O(1) time complexity search; the doubly linked list is used to maintain the access order of the shard mapping table. In the maintenance of the doubly linked list, active deletion and passive deletion based on the AGING algorithm are combined.

[0072] The hash function uses the remainder method. Suppose the number of addresses allowed in the hash table is M, and take a prime number p that is not greater than M but closest to or equal to M as the divisor. Use the following hash function to convert the key into a hash address:

[0073] Hash(key)=key%p(p<=M)

[0074] The Key consists of a 32-bit source IP address + a 32-bit destination IP address + a 16-bit ID. The value of M is determined based on the size of the point-to-point traffic per second in the communication network, and the main consideration is to minimize the time required for table lookup.

[0075] The doubly linked list is used to maintain the access order of the shard mapping table, that is, the nodes closer to the head of the linked list represent the most recently used shard mapping table, and the nodes closer to the tail of the linked list represent the least recently used shard mapping table. The key of the hash table is the index of the shard mapping table, and the value is the ID, source port, destination port, shard offset, and the pointer of the shard mapping table in the linked list. In this way, the required shard mapping table search, insertion, and deletion operations can be completed within O(1) time complexity, thereby realizing efficient LRU cache.

[0076] (2) Establishment of shard mapping table

[0077] Check whether the remaining cache area of ​​the shard mapping table is sufficient:

[0078] If the cache area is sufficient, extract the five-tuple information (including 8-bit protocol type, 32-bit source IP address, 32-bit destination IP address, 16-bit source port number, 16-bit destination port number), fragment offset and ID, and establish a fragment mapping table;

[0079] If the cache area is insufficient, perform a passive deletion operation on the shard mapping table: delete the oldest (i.e., the tail of the linked list) shard mapping table, extract the five-tuple information, shard offset, and ID, and establish the shard mapping table.

[0080] (3) Shard Mapping Table Matching

[0081] Check whether there is a match in the fragment mapping table. The detection method is to compare the source IP, destination IP, protocol type, and 16-bit ID identification field of the IP header of the fragment with the existing fragment mapping table. If all four conditions match, it can be determined that the fragment corresponds to the fragment mapping table:

[0082] If there is a match in the fragment mapping table, the port information recorded in the fragment mapping table is matched with the IP data packet;

[0083] If there is no match in the fragment mapping table, the fragment data packet is cached, and the timer starts counting, entering the fragment out-of-order processing flow.

[0084] (4) Deletion of the shard mapping table

[0085] Active deletion: refers to when all fragment packets of the same source have been identified, after the waiting time T, the fragment mapping table is actively deleted to avoid occupying additional memory space. The waiting time T is to avoid broadcast storms, and the value of T is determined according to the actual size of the point-to-point traffic in the network. The method for judging whether all fragments of the same source have been completely identified is: according to the 13-bit fragment offset of the IP header, the fragment offsets of all fragments of the same source that have been processed except the last fragment are added together. When the accumulated value is equal to the fragment offset of the last fragment received, it indicates that all fragments of the same source have been identified.

[0086] Passive deletion: When some fragment packets cannot be identified or are missing, the fragment mapping table will not be deleted, resulting in the accumulation of undeleted fragment mapping tables in the linked list. Due to limited memory space, when the number of fragment mapping table records reaches the maximum value M, the fragment mapping table with the greatest possibility of no longer being used, that is, the fragment mapping table at the end of the linked list, should be deleted to ensure that the fragment mapping table being identified will not be deleted.

[0087] The processing of out-of-order fragmentation of the present invention is specifically as follows:

[0088] Fragment out of order means that fragments cannot be received in order, and a non-first fragment of a group of homologous fragments arrives before the first fragment, resulting in the non-first fragment not being able to detect the corresponding fragment mapping table. The solution is as follows:

[0089] Cache the non-first fragment data packet and start the timer counting. After the next first fragment arrives and the fragment mapping table is established, immediately identify the unidentified fragment packets in the fragment cache area;

[0090] At the same time, check whether it is identified within the survival time:

[0091] If a shard mapping table corresponding to the cache shard can be identified within the lifetime, the port information recorded in the shard mapping table is extracted, and the homologous shards are detected based on the shard offset to see whether all shards are identified;

[0092] If no fragment mapping table corresponding to the cache fragment is identified within the lifetime, a custom packet header encapsulation is directly added for subsequent QoS processing.

[0093] The present invention discloses a method for suppressing broadcast storms and identifying QoS ports in a self-organizing network scenario, which is divided into three parts, namely, pre-processing of IP data packets, classification processing of IP data packets and subsequent processing of IP data packets. The main operations used include extracting IP data packet information, establishing, matching and deleting a fragment mapping table, and processing of out-of-order fragments.

[0094] Step 1: Preprocessing of IP packets

[0095] 1.1) After receiving the IP data packet, the host detects whether the 32-bit destination IP address of the IP data packet is a broadcast address based on the fact that the destination IP address of the broadcast message is predetermined and fixed, and determines whether the IP data packet is a broadcast message:

[0096] a. If it is a broadcast message, proceed to the next step to check whether there is a corresponding fragment mapping table;

[0097] b. If it is not a broadcast message, only fragmented IP packets are identified in the subsequent processing of IP packets.

[0098] 1.2) Check whether there is a corresponding shard mapping table:

[0099] a. If there is a fragment mapping table corresponding to an IP data packet, it means a broadcast storm has occurred and the IP data packet is discarded;

[0100] b. If not, all IP packets are identified in the subsequent processing of IP packets.

[0101] Note: The difference between identifying only fragmented packets and identifying all packets:

[0102] a. Identify only fragmented packets: Because it is not a broadcast message, only QoS port identification needs to be considered, so only the five-tuple and ID identification information of the fragmented IP data packet are extracted to establish a fragment mapping table for processing;

[0103] b. Identify all packets: Because they are broadcast messages, in order to solve the two problems of broadcast storm and QoS port identification at the same time, it is necessary to extract the five-tuple and ID information of all IP data packets to establish a fragment mapping table for processing.

[0104] Step 2: Classification and processing of IP packets

[0105] 2.1) According to the information of IP header and transport layer port, determine whether IP data packet needs QoS port mapping, and divide the types of IP data packets into 2 categories:

[0106] a. No need to identify ports: For example, ICMP protocol messages do not contain port information;

[0107] b. Port identification is required: Continue with subsequent fragment type identification.

[0108] 2.2) For IP packets that do not require port identification:

[0109] a. If it is not a broadcast message, there is no need to establish a fragmentation mapping table. Instead, you can directly add a custom header encapsulation (for example, QoS processing priority, source port, destination port, etc.) to perform subsequent QoS processing.

[0110] b. If it is a broadcast message, after establishing the fragment mapping table, add a custom packet header encapsulation and perform subsequent QoS processing.

[0111] 2.3) For IP packets that require port identification, they are classified according to the 3-bit identification bit and 13-bit offset in the IP header and are divided into the following three categories:

[0112] a. Complete packet: There are two cases. The first case is a packet that cannot be fragmented. The identification method is that the second DF bit of the 3-bit flag bit of the IP header is 1; the second case is a packet that can be fragmented, but not fragmented. The identification method is that the second DF bit of the 3-bit flag bit of the IP header is 0, the third MF bit is 0, and the 13-bit fragment offset of the IP header is 0;

[0113] b. First fragment: The identification method is that the second DF bit of the 3-bit flag bit of the IP header is 0, the third MF bit is 1, and the 13-bit fragment offset of the IP header is 0;

[0114] c. Non-first fragment: The identification method is that the second DF bit of the 3-bit flag bit of the IP header is 0, the third MF bit is 1, and the 13-bit fragment offset of the IP header is not 0.

[0115] 2.4) For the complete package:

[0116] a. If it is not a broadcast message, there is no need to establish a fragmentation mapping table, and the QoS service type can be determined directly based on the port;

[0117] b. If it is a broadcast message, after establishing the fragment mapping table, the QoS service type is determined according to the port.

[0118] 2.5) For the first packet, after establishing the fragment mapping table, determine the QoS service type according to the port;

[0119] 2.6) For non-first fragment packets, extract the IP header information and match it with the existing fragment mapping table:

[0120] a. If there is a corresponding fragment mapping table, extract the port information recorded in the fragment mapping table, and detect whether all homologous fragments are recognized according to the fragment offset;

[0121] b. If there is no fragment packet corresponding to the fragment mapping table, it is likely that fragments are out of order: the non-first fragment of the same source fragment arrives before the first fragment, resulting in the absence of a corresponding fragment mapping table. Enter 2.7) fragment out of order processing flow;

[0122] 2.7) Check whether all homologous fragments are recognized based on the fragment offset. The judgment method is to add the fragment offsets of all homologous fragments that have been processed except the last fragment based on the 13-bit fragment offset of the IP header. When the accumulated value is equal to the fragment offset of the last fragment received, it indicates that all homologous fragments have been recognized:

[0123] a. Identify all the same-source fragments: Actively delete the fragment mapping table, and then determine the QoS service type based on the port;

[0124] b. If all fragments of the same source are not identified, the fragment mapping table is retained and the QoS service type is determined directly based on the port.

[0125] Step 3: Subsequent processing of IP packets

[0126] (1) Determine the service type based on the port: At the application layer, different fixed ports are specified in advance according to different service types. In this step, after the IP data packets that need port identification are classified, the service type of the service flow is determined by the port number, and the received service flow is divided into different priorities.

[0127] (2) Add custom packet header encapsulation for subsequent QoS processing: For IP packets that have been classified and do not require port identification and IP packets whose service types have been determined, custom packet headers will be added to the IP packets for encapsulation based on priority and other service information to facilitate subsequent QoS processing.

[0128] The present invention also proposes a broadcast storm suppression and QoS port identification system in a self-organizing network scenario, implements the broadcast storm suppression and QoS port identification method in a self-organizing network scenario, and realizes broadcast storm suppression and QoS port identification in a self-organizing network scenario.

[0129] In order to verify the effectiveness of the scheme of the present invention, the following experimental design was carried out.

[0130] Example 1

[0131] Receive a non-broadcast ICMP packet and a group of out-of-order fragmented UDP packets

[0132] At the inlet [receiving IP data packets], the broadcast address is a pre-determined, fixed IP address. Therefore, [detect whether the destination IP is a broadcast address], determine that "ICMP packets" and "UDP packets" are not broadcast packets, and only identify fragmented packets in subsequent processing.

[0133] First, check whether port identification is required based on the 16-bit protocol type field in the IP header, and identify the protocol types as "ICMP packet" and "UDP packet". "ICMP packet" does not require port identification and does not contain port information, so it directly proceeds to the step of "adding custom header encapsulation and performing subsequent QoS processing". "UDP packet" requires port identification processing, and proceeds to the next processing step to check whether it is fragmented.

[0134] In the step of checking whether it is fragmented, the data packets that need to identify the port are divided into two types: complete packets and fragmented packets. The fragmented "UDP packet" packet is identified as a fragmented packet, based on whether the third MF bit of the 3-bit flag bit of the IP header is 1 or the 13-bit fragment offset of the IP header is not 0.

[0135] In the [Determine the fragment type] step, the fragmented packets are divided into two types: first-fragment packets and non-first-fragment packets. The first-fragment packet is identified by the third MF bit of the 3-bit flag bit of the IP header being 1 and the 13-bit fragment offset of the IP header being 0. The non-first-fragment packet is identified by the 13-bit fragment offset of the IP header being not 0.

[0136] For the "UDP first packet", after establishing the fragment mapping table, determine the QoS service type according to the port. For the "UDP non-first packet", extract the IP header information and match it with the existing fragment mapping table. If there is a corresponding fragment mapping table, extract the port information recorded in the fragment mapping table, and detect whether all the fragments of the same source are recognized according to the fragment offset; if there is no fragment packet corresponding to the fragment mapping table, it is likely that the fragments are out of order, and enter the fragment out of order processing process.

[0137] For the "UDP packet" that has been identified with the fragment mapping table, [check whether all the fragments of the same source have been identified based on the fragment offset]. If all the fragments of the same source have been identified, actively delete the fragment mapping table and proceed to the next step [determine the service type based on the port]; if all the fragments of the same source have not been identified, retain the fragment mapping table and directly proceed to the next step [determine the service type based on the port].

[0138] At the application layer, different fixed ports are specified in advance according to different service types. In the step [Determine service type according to port], the service type of the "UDP packet" service flow is directly determined by the port number, and the received service flow is divided into different priorities. Go to the next step [Add custom packet header encapsulation for subsequent QoS processing].

[0139] In the step [Add custom packet header encapsulation for subsequent QoS processing], custom packet headers are added to the "ICMP packet" and "UDP packet" for encapsulation based on priority and other business information to facilitate subsequent QoS processing.

[0140] Finally, [deliver to the next layer] for processing.

[0141] Example 2

[0142] Receives duplicate ICMP packets and non-duplicate complete UDP packets for broadcast

[0143] At the entrance [receive IP data packets], the broadcast address is a pre-determined, fixed IP address. Therefore, [check whether the destination IP is a broadcast address], determine whether the "ICMP packet" and "UDP packet" are broadcast packets, and proceed to the next step [check whether there is a corresponding fragment mapping table].

[0144] In [Check whether there is a fragment mapping table corresponding to the "ICMP packet", if there is a fragment mapping table corresponding to the "ICMP packet", it means that a broadcast storm has occurred and the "ICMP packet" is discarded; if there is no fragment mapping table corresponding to the "UDP packet", all packets will be identified later.

[0145] First, the 16-bit protocol type field in the IP header is used to detect whether port identification is required, and the protocol type is identified as "UDP packet". "UDP packet" needs to be processed for port identification, and the next processing step is to detect whether fragmentation is required.

[0146] In the step of checking whether it is fragmented, the data packets that need to identify the port are divided into two cases: complete packets and fragmented packets. The fragmented "UDP packet" packet is identified as a complete packet, based on the third MF bit of the 3-bit flag bit of the IP header is 0 and the 13-bit fragment offset of the IP header is 0.

[0147] For a complete "UDP packet", after the fragment mapping table is established, the QoS service type is determined according to the port.

[0148] At the application layer, different fixed ports are specified in advance according to different service types. In the step [Determine service type according to port], the service type of the "UDP packet" service flow is directly determined by the port number, and the received service flow is divided into different priorities. Go to the next step [Add custom packet header encapsulation for subsequent QoS processing].

[0149] In the step [Add custom packet header encapsulation for subsequent QoS processing], a custom packet header is added to the "UDP packet" for encapsulation based on the priority and other business information to facilitate subsequent QoS processing.

[0150] Finally, [deliver to the next layer] for processing.

[0151] In summary, the present invention extracts quintuple information and other related information from IP data packets to establish a fragment mapping table, thereby being able to simultaneously achieve the port mapping required for broadcast storm suppression and QoS traffic classification, which not only simplifies the processing flow but also saves system resources.

[0152] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0153] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A method for suppressing broadcast storms and identifying QoS ports in a self-organizing network scenario, characterized in that: include: Step 1, preprocessing of IP data packets: After receiving the IP data packet, the host determines whether the IP data packet is a broadcast message and detects whether there is a corresponding fragment mapping table; Step 2, classification processing of IP data packets: According to the information of IP header and transport layer port, determine whether the IP data packet needs QoS port mapping, and divide the types of IP data packets into two categories, those that do not need to identify ports and those that need to identify ports; Step 3, subsequent processing of IP data packets: determine the service type of the service flow by the port number, divide the received service flow into different priorities, and for IP data packets that do not require port identification after classification and IP data packets whose service types have been determined, add a custom packet header to the IP data packet for encapsulation based on the priority and other service information to facilitate subsequent QoS processing.

2. The method for suppressing broadcast storms and identifying QoS ports in a self-organizing network scenario according to claim 1, characterized in that: The IP data packet contains two parts of information: One part is the field containing specific information in the IP data packet header, including 16-bit ID identification, 3-bit identification bit, 13-bit fragment offset, 8-bit protocol type, 32-bit source IP address and 32-bit destination IP address. The 16-bit ID identification field means that the IP software maintains a counter in the memory. Every time a data packet is generated, the counter is increased by 1 and this value is assigned to the identification field. When fragmentation occurs, the value of this identification field is copied to the ID identification field of all fragment packets of the same source; the second DF of the 3-bit identification bit indicates whether it can be fragmented, 0 indicates fragmentation, and 1 indicates that it cannot be fragmented; the third MF indicates whether the message is the last fragment, 0 indicates the last fragment, and 1 indicates that there are more fragments behind; the 13-bit fragment offset field refers to the relative position of a fragment in the original packet after fragmentation occurs. If there is no fragmentation, the default value here is 0; the 8-bit protocol type field identifies the protocol type of the information contained in the current data packet; the 32-bit source IP address and the 32-bit destination IP address refer to the host IP address that sends the current IP data packet and the host IP address that receives the current data packet; The other part is the port information of the transport layer message contained in the IP data packet, including the 16-bit source port number and 16-bit destination port number information in the transport layer data packet header. The 16-bit source port number field is used to identify the sending process, and the 16-bit destination port number field is used to identify the receiving process.

3. The method for suppressing broadcast storms and identifying QoS ports in a self-organizing network scenario according to claim 1, characterized in that: The shard mapping table is established in the form of a hash table combined with a bidirectional linked list, where: The key code of the hash table is the index of the shard mapping table, which is obtained by performing a hash operation on the source IP address, destination IP address and ID extracted from the IP data packet. The data stored in the shard mapping table is the ID, source port, destination port, shard offset and linked list pointer. The hash function uses the remainder method. Suppose the number of addresses allowed in the hash table is M, and take a prime number p that is not greater than M but closest to or equal to M as the divisor. Use the following hash function to convert the key into a hash address: Hash(key)=key%p,p<=M The Key is composed of 32-bit source IP address + 32-bit destination IP address + 16 ID identifiers. The value of M is determined according to the size of the point-to-point traffic per second in the communication network. The factor considered is to minimize the table lookup time. The bidirectional linked list is used to maintain the access order of the shard mapping table, that is, the nodes closer to the head of the linked list represent the shard mapping table that is more recently used, and the nodes closer to the tail of the linked list represent the shard mapping table that has not been used for a long time.

4. The method for suppressing broadcast storms and identifying QoS ports in a self-organizing network scenario according to claim 3, characterized in that: Step 1: Preprocessing of IP data packets: After receiving the IP data packet, the host determines whether the IP data packet is a broadcast message and detects whether there is a corresponding fragment mapping table. The specific method is as follows: (1.1) After receiving the IP data packet, the host detects whether the 32-bit destination IP address of the IP data packet is a broadcast address based on the fact that the destination IP address of the broadcast message is predetermined and fixed, and determines whether the IP data packet is a broadcast message: a. If it is a broadcast message, proceed to the next step to check whether there is a corresponding fragment mapping table; b. If it is not a broadcast message, only fragmented IP packets are identified in the subsequent processing of IP packets; (1.2) Check whether there is a corresponding shard mapping table: If there is a fragment mapping table corresponding to the IP data packet, the IP data packet is discarded; If not, all IP data packets are identified in the subsequent processing of IP data packets.

5. The method for suppressing broadcast storms and identifying QoS ports in a self-organizing network scenario according to claim 4, characterized in that: Step 2, classification processing of IP data packets: According to the information of IP header and transport layer port, determine whether the IP data packet needs QoS port mapping, and divide the types of IP data packets into two categories, those that do not need to identify ports and those that need to identify ports. The specific method is as follows: (2.1) According to the information of IP header and transport layer port, determine whether the IP data packet needs QoS port mapping, and classify the types of IP data packets into two categories, including those that do not need to identify ports and those that need to identify ports; (2.2) For IP packets that do not require port identification: a. If it is not a broadcast message, there is no need to establish a fragmentation mapping table. Just add a custom packet header encapsulation and perform subsequent QoS processing; b. If it is a broadcast message, after establishing the fragmentation mapping table, add a custom packet header encapsulation and perform subsequent QoS processing; (2.3) For IP packets that require port identification, they are classified according to the 3-bit identification bit and 13-bit offset in the IP header and are divided into the following three categories: a. Complete packet: There are two cases. The first case is a packet that cannot be fragmented. The second DF bit of the 3-bit flag bit of the IP header is 1. The second case is a packet that can be fragmented, but not fragmented. The second DF bit of the 3-bit flag bit of the IP header is 0, the third MF bit is 0, and the 13-bit fragment offset of the IP header is 0. b. First fragment: The second DF bit of the 3-bit flag bit of the IP header is 0, the third MF bit is 1, and the 13-bit fragment offset of the IP header is 0; c. Non-first fragment: The second DF bit of the 3-bit flag bit of the IP header is 0, the third MF bit is 1, and the 13-bit fragment offset of the IP header is not 0; (2.4) For a complete package: a. If it is not a broadcast message, there is no need to establish a fragmentation mapping table, and the QoS service type can be determined directly based on the port; b. If it is a broadcast message, after establishing the fragmentation mapping table, the QoS service type is determined according to the port; (2.5) For the first packet, after the fragment mapping table is established, the QoS service type is determined according to the port; (2.6) For non-first fragment packets, extract the IP header information and perform matching operations with the existing fragment mapping table: a. If there is a corresponding fragment mapping table, extract the port information recorded in the fragment mapping table, and detect whether all homologous fragments are recognized according to the fragment offset; b. If there is no fragmentation packet corresponding to the fragmentation mapping table, proceed to 2.7) fragmentation disorder processing flow; (2.7) Check whether all homologous fragments are recognized based on the fragment offset. That is, based on the 13-bit fragment offset in the IP header, add the fragment offsets of all homologous fragments that have been processed except the last fragment. When the accumulated value is equal to the fragment offset of the last fragment received, it indicates that all homologous fragments have been recognized. There are two cases: a. Identify all the same-source fragments: Actively delete the fragment mapping table and determine the QoS service type based on the port; b. If all fragments of the same source are not identified, the fragment mapping table is retained and the QoS service type is determined directly based on the port.

6. A broadcast storm suppression and QoS port identification system in a self-organizing network scenario, characterized in that: Implement the broadcast storm suppression and QoS port identification method in the self-organizing network scenario as described in any one of claims 1-5 to achieve broadcast storm suppression and QoS port identification in the self-organizing network scenario.

Images