A broadcast storm suppression and QoS port identification method in a self-organizing network scenario

Abstract

The application discloses a broadcast storm suppression and QoS port identification method in a self-organizing network scene. After a host receives an IP data packet, it is determined whether the IP data packet is a broadcast message and whether there is a fragment mapping table corresponding to the IP data packet. According to the information of the IP header and the transmission layer port, it is judged whether the IP data packet needs to be mapped to a QoS port. The type of the IP data packet is divided into two types, i.e. a type without needing to identify a port and a type needing to identify a port. The service type of a service flow is determined through a port number, and the received service flow is divided into different priorities. For the IP data packet without needing to identify a port and the IP data packet with a determined service type after classification processing, the IP data packet is encapsulated by adding a self-defined packet header according to the priority and other service information, so as to facilitate subsequent QoS processing. The application can simultaneously realize the broadcast storm suppression and the port mapping needed by the QoS flow classification by extracting the five-tuple information and other related information from the IP data packet to establish a fragment mapping table, so that the processing flow is simplified and the system resources are saved.

Description

Technical Field

[0001] This invention relates to ad hoc networks, and more specifically to a method for broadcast storm suppression and QoS port identification in ad hoc network scenarios. Background Technology

[0002] Ad hoc networks, with their unique characteristics such as multi-hop capability, flexibility, and resilience, demonstrate a very broad application prospect in environments that urgently require temporary and rapid network deployment, such as military communications and emergency rescue. In the data link constructed by an ad hoc network, data from various sensors or peripherals are first connected to the ad hoc network nodes via wired connections. Subsequently, this data is transmitted to other ad hoc network nodes through the wireless interface (or air interface) of the ad hoc network nodes, thereby achieving interconnection and interoperability between devices.

[0003] In wired and wireless communication scenarios within ad hoc networks, broadcast communication can encounter broadcast storms. Broadcast, a "one-to-all" communication mode between hosts, refers to a host sending data to all hosts within a subnet using a predefined fixed IP address. Once all hosts receive this data, they unconditionally copy and forward it. However, broadcast storms, a type of failure in broadcast communication, often arise from network protocol flaws or improper network configuration, causing a closed loop in the link between hosts. In this situation, broadcast packets circulate continuously within the loop, being copied extensively, leading to network congestion and, in severe cases, even network paralysis.

[0004] When the size of a transmitted data packet exceeds the link's MTU (Maximum Transmission Unit), IP packet fragmentation occurs, dividing the complete packet into smaller fragments to ensure successful transmission. However, in fragmented packets, only the first fragment contains complete source and destination port information; other fragments typically do not. Therefore, QoS traffic identification and classification based on port mapping cannot be performed on these fragments.

[0005] To suppress broadcast storms, when a loop has already formed, the TTL (Time to Live) field inherent in the IP packets themselves is mainly used to prevent packets from looping infinitely within the loop. However, packets will still loop a limited number of times within the loop, consuming a significant amount of network bandwidth and system resources, thus increasing the network burden.

[0006] There are several solutions to the problem of not being able to identify fragmented packet ports. One solution is to redefine the service identifier field in the IP packet header, but this requires modifying the protocol stack, which is complex and can introduce other potential problems. Another solution is path MTU discovery, which involves attempting to send packets to discover the MTU along the network transmission path. Subsequent data transmissions then control the packet size to be less than or equal to the MTU value, thus avoiding fragmentation. However, this method reduces network utilization and becomes unsustainable when the network is unstable or the transmission path changes drastically.

[0007] As can be seen from the above, the current solutions to the problems of broadcast storms and the inability to perform QoS port mapping for IP fragmentation still have different shortcomings, and each solution only addresses one of them, without combining them to solve them simultaneously. Summary of the Invention

[0008] The purpose of this invention is to propose a method for broadcast storm suppression and QoS port identification in ad hoc network scenarios.

[0009] The technical solution to achieve the purpose of this invention is: a method for broadcast storm suppression and QoS port identification in a self-organizing network scenario, comprising:

[0010] Step 1, IP packet preprocessing: After receiving an IP packet, the host determines whether the IP packet is a broadcast message and checks whether there is a corresponding fragmentation mapping table;

[0011] Step 2, IP packet classification and processing: Based on the information of the IP header and transport layer port, determine whether the IP packet needs to be mapped to QoS port, and classify the IP packet into two categories: those that do not need to identify the port and those that do need to identify the port.

[0012] Step 3, Post-processing of IP packets: Determine the service type of the service flow by the port number, divide the received service flows into different priorities, and encapsulate the IP packets with a custom header according to priority and other service information for subsequent QoS processing.

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

[0014] One part is the IP packet header, which contains fields containing specific information, including a 16-bit ID identifier, a 3-bit identifier bit, a 13-bit fragment offset, an 8-bit protocol type, a 32-bit source IP address, and a 32-bit destination IP address. The 16-bit ID identifier field is maintained by a counter in the IP software's memory. Each time a packet is generated, the counter is incremented by 1, and this value is assigned to the identifier field. When fragmentation occurs, the value of this identifier field is copied to the ID identifier fields of all fragmented packets from the same source. The second bit of the 3-bit identifier bit, DF, indicates whether fragmentation is possible (0 for fragmentation, 1 for no fragmentation). The third bit, MF, indicates whether this is the last fragment (0 for the last fragment, 1 for more fragments). The 13-bit fragment offset field indicates the relative position of a fragment within the original packet after fragmentation; if there is no fragmentation, this field defaults to 0. The 8-bit protocol type field identifies the protocol type of the information contained in the current packet. The 32-bit source IP address and 32-bit destination IP address refer to the IP addresses of the host that sent and received the current IP packet, respectively.

[0015] The other part is the port information of the transport layer message contained in the IP packet, including the 16-bit source port number and 16-bit destination port number information in the header of the transport layer packet. 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 sharding mapping table is built using a combination of a hash table and a doubly linked list, where:

[0017] The key of the hash table is the index of the fragmentation mapping table, which is obtained by hashing the source IP address, destination IP address and ID identifier extracted from the IP packet. The data stored in the fragmentation mapping table is the ID identifier, source port, destination port, fragment offset and linked list pointer.

[0018] The hash function uses the division remainder method. Let M be the number of allowed addresses in the hash table. Take a prime number p, not greater than M but closest to or equal to M, as the divisor. Then, convert the key into a hash address using the following hash function:

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

[0020] The Key is composed of a 32-bit source IP address + a 32-bit destination IP address + a 16-bit ID identifier. M is determined based on the amount of point-to-point traffic per second in the communication network, with the consideration of minimizing table lookup time.

[0021] Doubly linked lists are used to maintain the access order of sharded maps. Nodes closer to the head of the list represent more recently used sharded maps, while nodes closer to the tail of the list represent sharded maps that have not been used for a long time.

[0022] Further, in step 1, IP packet preprocessing: After receiving an IP packet, the host determines whether the IP packet is a broadcast message and checks if there is a corresponding fragmentation mapping table. The specific method is as follows:

[0023] 1.1) After receiving an IP packet, the host checks whether the 32-bit destination IP address of the IP packet is a broadcast address, based on the characteristic that the destination IP address of a broadcast message is predetermined and fixed, to determine whether the IP packet is a broadcast message:

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

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

[0026] 1.2) Check if there is a corresponding sharding mapping table:

[0027] If a fragmentation mapping table corresponds to an IP packet, discard the IP packet.

[0028] If not, all IP packets will be identified during subsequent IP packet processing.

[0029] Further, in step 2, IP packet classification processing: Based on the IP header and transport layer port information, determine whether the IP packet needs QoS port mapping, and classify the IP packet type into two categories: those that do not require port identification and those that do. The specific method is as follows:

[0030] 2.1) Based on the information in the IP header and transport layer port, determine whether the IP packet needs to be mapped to QoS port. Divide the IP packet type into two categories: those that do not need to identify the port and those that do 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 create a fragmentation mapping table. Just add a custom packet header for 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 for encapsulation and perform subsequent QoS processing;

[0034] 2.3) For IP packets requiring port identification, they are classified into three categories based on the 3-bit identifier and 13-bit offset in the IP header:

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

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

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

[0038] 2.4) For complete packages:

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

[0040] b. If it is a broadcast message, the QoS service type is determined based on the port after the fragmentation mapping table is established.

[0041] 2.5) For the first packet, after establishing the fragmentation mapping table, determine the QoS service type based on the port;

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

[0043] a. If a corresponding fragment mapping table exists, extract the port information recorded in the fragment mapping table, and check whether all source fragments are identified based on the fragment offset;

[0044] b. If there is no fragment packet corresponding to the fragment mapping table, proceed to step 2.7) Fragment out-of-order processing flow;

[0045] 2.7) Detect whether all homogeneous fragments have been identified based on fragment offset. That is, based on the 13-bit fragment offset in the IP header, add the fragment offsets of all homogeneous fragments that have been processed except for the last fragment. When the accumulated value equals the fragment offset of the received last fragment, it indicates that all homogeneous fragments have been identified. There are two cases:

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

[0047] b. Not all fragments from the same source are identified: Retain the fragmentation mapping table and directly determine the QoS service type based on the port.

[0048] A broadcast storm suppression and QoS port identification system for ad hoc network scenarios is provided, which implements the broadcast storm suppression and QoS port identification method for ad hoc network scenarios to achieve broadcast storm suppression and QoS port identification in ad hoc network scenarios.

[0049] Compared with the prior art, the present invention has the following significant advantages: by extracting the five-tuple information and other relevant information from IP packets to establish a fragmentation mapping table, a method for simultaneously realizing the port mapping required for broadcast storm suppression and QoS traffic classification can be achieved. This not only simplifies the processing flow but also saves system resources. Attached Figure Description

[0050] Figure 1 This is a schematic diagram of a self-organizing network data link.

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

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

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

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

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

[0056] Figure 7 This is a schematic diagram of the fragmented mapping table.

[0057] Figure 8 This is a schematic diagram showing the correspondence between hash table key values ​​and sharding mapping tables.

[0058] Figure 9 This is a schematic diagram illustrating the structure of a doubly linked list and the contents of a sharded mapping table.

[0059] Figure 10 This is a flowchart of a broadcast storm suppression and QoS port identification method in an ad hoc network scenario.

[0060] Figure 11 This is a flowchart of the IP packet preprocessing process.

[0061] Figure 12 This is a flowchart of the IP packet processing in Example 1.

[0062] Figure 13This is a flowchart of the IP packet processing in Example 2. Detailed Implementation

[0063] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0064] When a host broadcasts on a network, other nodes that receive the broadcast IP packet will continue to broadcast the same IP packet. If a host cannot recognize whether the received broadcast packet is one it has received before, a loop will form between multiple hosts (e.g., ...). Figure 2 This causes broadcast IP packets to loop repeatedly within this loop, resulting in a broadcast storm, which can lead to network congestion or even paralysis. Creating a fragmentation mapping table for all broadcast packets can record the reception status of these packets.

[0065] When a host receives a broadcast message again, this invention matches the information of the IP data packet with the fragmentation mapping table. If a match is successful, it indicates that the broadcast message is a duplicate and is discarded, effectively suppressing broadcast storms. Similarly, by establishing a fragmentation mapping table only for fragmented data packets, the problem of QoS port recognition after IP fragmentation can be solved. When a group of IP fragmented packets from the same source arrives, the header information of the first fragment's IP data packet and the upper-layer transport layer port information are extracted to establish a fragmentation mapping table. When subsequent non-first fragmented packets arrive, their IP header information is extracted and matched with the existing fragmentation mapping table. After a successful match, the upper-layer transport layer port information is extracted from the fragmentation mapping table, thus meeting the requirements for QoS service type classification and recognition. Furthermore, to solve the problem of out-of-order internal transmission, a custom header can be added when transmitting data packets to the lower layer after port recognition is completed.

[0066] This invention requires extracting two parts of information from the IP data packet: one part is several fields in the IP data packet header that contain specific information, and the other part is the port information of the transport layer message contained in the IP data packet. Figure 5 This refers to the message format of IP data packets.

[0067] The header of an IP packet contains several fields with different meanings. By extracting information from these fields, an IP packet or a group of same-origin fragmented packets can be specifically identified. The fields to be extracted include a 16-bit ID identifier, a 3-bit identifier bit, a 13-bit fragment offset, an 8-bit protocol type, a 32-bit source IP address, and a 32-bit destination IP address. The 16-bit ID identifier field is maintained by a counter in IP software's memory. Each time a packet is generated, the counter is incremented by 1, and this value is assigned to the identifier field. When fragmentation occurs, the value of this identifier field is copied to the ID identifier fields of all same-origin fragmented packets. The second bit of the 3-bit identifier bit, DF (Don't Fragment), indicates whether fragmentation is allowed (0 indicates fragmentation is allowed, 1 indicates fragmentation is not allowed); the third bit, MF (More Fragment), indicates whether this is the last fragment (0 indicates the last fragment, 1 indicates there are more fragments to follow). The 13-bit fragment offset field indicates the relative position of a fragment within the original packet after fragmentation. 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 IP addresses of the host that sent the current IP data packet and the host that received the current data packet.

[0068] Simultaneously, to meet the port mapping requirements in QoS service type classification and identification under IP fragmentation scenarios, it is also necessary to extract the 16-bit source port number and 16-bit destination port number information from the transport layer packet header contained in the IP packet. For example... Figure 6 As shown, the 16-bit source port number field is used to identify which application sent the data (sending process), and the 16-bit destination port number field is used to identify which application received the data (receiving process).

[0069] The specific methods for constructing, creating, matching, and deleting the sharding mapping table in this invention are as follows:

[0070] (1) Construction of the partitioned mapping table

[0071] The sharded mapping table is built using a combination of a hash table and a doubly linked list: the hash table stores key-value pairs to achieve O(1) time complexity lookups; the doubly linked list maintains the access order of the sharded mapping table. The maintenance of the doubly linked list combines active deletion with passive deletion based on the AGING algorithm.

[0072] The hash function uses the division remainder method. Let M be the number of allowed addresses in the hash table. Take a prime number p, not greater than M but closest to or equal to M, as the divisor. Then, convert the key into a hash address using the following hash function:

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

[0074] The key is composed of a 32-bit source IP address + a 32-bit destination IP address + a 16-bit ID identifier. M is determined based on the amount of point-to-point traffic per second in the communication network, primarily considering minimizing table lookup time.

[0075] A doubly linked list is used to maintain the access order of the sharding table; nodes closer to the head of the list represent more recently used sharding tables, while nodes closer to the tail represent less frequently used sharding tables. The hash table's key is the index of the sharding table, and its value includes the ID, source port, destination port, shard offset, and a pointer to the sharding table within the linked list. This allows for the lookup, insertion, and deletion of the required sharding table in O(1) time complexity, thus achieving an efficient LRU cache.

[0076] (2) Establishment of the partitioned mapping table

[0077] Check if there is enough remaining cache space in the sharding mapping table:

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

[0079] If the cache area is insufficient, a passive deletion operation is performed on the sharding mapping table: the oldest sharding mapping table (i.e., the tail of the linked list) is deleted, the 5-tuple information, shard offset and ID identifier are extracted, and a new sharding mapping table is established.

[0080] (3) Matching the fragmented mapping table

[0081] The method to check for a fragment mapping table match involves comparing the fragment's source IP, destination IP, protocol type, and the 16-bit ID field in the IP header with an existing fragment mapping table. If all four conditions match, then the fragment corresponds to a fragment mapping table.

[0082] If a fragmentation mapping table match is found, the port information recorded in the fragmentation mapping table will be matched with the IP packet.

[0083] If no fragment mapping table matches, the fragment data packet is cached, a timer starts counting, and the fragment out-of-order processing flow begins.

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

[0085] Proactive deletion refers to the process of actively deleting the fragment mapping table after a waiting time T, once all same-origin fragments have been identified, to avoid consuming additional memory space. The waiting time T is to avoid broadcast storms, and its value is determined based on the actual size of point-to-point traffic in the network. The method for determining whether all same-origin fragments have been fully identified is as follows: based on the 13-bit fragment offset in the IP header, add the fragment offsets of all processed same-origin fragments except the last fragment. When the accumulated value equals the fragment offset of the received last fragment, it indicates that all same-origin fragments have been identified.

[0086] Passive deletion refers to the situation where, when some fragment packets cannot be recognized or are missing, the fragment mapping table is not deleted, resulting in the accumulation of undeleted fragment mapping tables in the linked list. Due to limited memory space, when the number of records in the fragment mapping table reaches the maximum value M, the fragment mapping table with the highest probability of no longer being used should be deleted, i.e., the fragment mapping table at the end of the linked list, to ensure that the fragment mapping table being recognized is not deleted.

[0087] The specific method for processing out-of-order fragmentation in this invention is as follows:

[0088] Out-of-order fragmentation refers to fragments not being received in the correct order. For example, a non-first fragment in a group of fragments from the same source arrives before the first fragment, causing the non-first fragment to not be detected in the fragment mapping table. The solution is as follows:

[0089] The non-first fragment data packet is cached, and a timer is started to count. After the next first fragment arrives and the fragment mapping table is established, the unidentified fragment packets in the fragment cache area are immediately identified.

[0090] Simultaneously detect whether it was 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 same-source shards are identified based on the shard offset.

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

[0093] This invention discloses a broadcast storm suppression and QoS port identification method for ad hoc network scenarios, which consists of three parts: IP packet preprocessing, IP packet classification, and IP packet post-processing. The main operations involved include extracting IP packet information, establishing, matching, and deleting fragmentation mapping tables, and handling out-of-order fragments.

[0094] Step 1, IP packet preprocessing

[0095] 1.1) After receiving an IP packet, the host checks whether the 32-bit destination IP address of the IP packet is a broadcast address, based on the characteristic that the destination IP address of a broadcast message is predetermined and fixed, to determine whether the IP packet is a broadcast message:

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

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

[0098] 1.2) Check if there is a corresponding sharding mapping table:

[0099] a. If there is a fragmentation mapping table corresponding to the IP packet, it indicates that a broadcast storm has occurred, and the IP packet should be discarded;

[0100] b. If not, all IP packets will be identified in subsequent IP packet processing.

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

[0102] a. Identify only fragmented packets: Since it is not a broadcast message, only QoS port identification needs to be considered. Therefore, only the 5-tuple and ID information of the fragmented IP packets are extracted to establish a fragmentation mapping table for processing.

[0103] b. Identify all packets: Since these are broadcast messages, in order to solve both the broadcast storm and QoS port identification problems at the same time, it is necessary to extract the five-tuple and ID information from all IP packets and establish a fragmentation mapping table for processing.

[0104] Step 2, IP packet classification and processing

[0105] 2.1) Based on the IP header and transport layer port information, determine whether IP packets need QoS port mapping, and classify IP packets into two types:

[0106] a. No port identification is required: For example, ICMP protocol messages do not contain port information;

[0107] b. Port identification 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 create a fragmentation mapping table. Just add a custom header encapsulation (e.g., QoS processing priority, source port, destination port, etc.) and perform subsequent QoS processing.

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

[0111] 2.3) For IP packets requiring port identification, they are classified into three categories based on the 3-bit identifier and 13-bit offset in the IP header:

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

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

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

[0115] 2.4) For complete packages:

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

[0117] b. If it is a broadcast message, the QoS service type is determined based on the port after the fragmentation mapping table is established.

[0118] 2.5) For the first packet, after establishing the fragmentation mapping table, determine the QoS service type based on the port;

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

[0120] a. If a corresponding fragment mapping table exists, extract the port information recorded in the fragment mapping table, and check whether all source fragments are identified based on the fragment offset;

[0121] b. If there is no fragment packet corresponding to the fragment mapping table, it is highly likely that fragment out-of-order has occurred: the non-first fragment of the same source fragment arrives before the first fragment, resulting in no corresponding fragment mapping table, and proceeding to the fragment out-of-order processing flow in 2.7).

[0122] 2.7) Determine if all same-source fragments have been identified based on the fragment offset. The method is to add the fragment offsets of all processed same-source fragments (excluding the last fragment) based on the 13-bit fragment offset in the IP header. When the sum equals the fragment offset of the received last fragment, it indicates that all same-source fragments have been identified.

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

[0124] b. Not all fragments from the same source are identified: Retain the fragmentation mapping table and directly determine the QoS service type based on the port.

[0125] Step 3, Post-processing of IP packets

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

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

[0128] This invention also proposes a broadcast storm suppression and QoS port identification system for ad hoc network scenarios, implementing the aforementioned broadcast storm suppression and QoS port identification method for ad hoc network scenarios to achieve broadcast storm suppression and QoS port identification in ad hoc network scenarios.

[0129] To verify the effectiveness of the present invention, the following experimental design was conducted.

[0130] Example 1

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

[0132] At the entry point [receiving IP packets], the broadcast address is a pre-determined, fixed IP address. Therefore, [checking if the destination IP is a broadcast address] determines that "ICMP packets" and "UDP packets" are not broadcast packets, and only fragmented packets are identified in subsequent processing.

[0133] First, the 16-bit protocol type field in the IP header is used to check if port identification is required. The protocol types identified are "ICMP packet" and "UDP packet". "ICMP packet" does not require port identification and does not contain port information, so it proceeds directly to the step of adding a custom header for encapsulation and subsequent QoS processing. "UDP packet" requires port identification processing and proceeds to the next step to check if fragmentation is needed.

[0134] In the "Fragmentation Detection" step, data packets for which port identification is required are divided into two categories: complete packets and fragmented packets. Fragmented "UDP packets" are identified as fragmented packets based on whether the third bit (MF) of the 3-bit flag in the IP header is 1 or whether the 13-bit fragment offset in the IP header is not 0.

[0135] In the "Determine Fragment Type" step, fragmented packets are divided into two cases: first fragment packets and non-first fragment packets. First fragment packets are identified by setting the third MF bit of the 3-bit flag in the IP header to 1 and setting the 13-bit fragment offset in the IP header to 0. Non-first fragment packets are identified by setting the 13-bit fragment offset in the IP header to a non-zero value.

[0136] For "UDP first packets," after establishing a fragmentation mapping table, the QoS service type is determined based on the port. For "UDP non-first packets," the IP header information is extracted and matched against the existing fragmentation mapping table. If a corresponding fragmentation mapping table exists, the port information recorded in the fragmentation mapping table is extracted, and the same-origin fragments are checked for identification based on the fragment offset. If no fragmentation packet corresponds to a fragmentation mapping table, it is highly likely that fragmentation has occurred out of order, and the fragmentation out-of-order processing flow is initiated.

[0137] For "UDP packets" that have been identified with a corresponding fragmentation mapping table, [check whether all same-origin fragments have been identified based on fragment offset]. If all same-origin fragments have been identified, actively delete the fragmentation mapping table and proceed to the next step [determine the service type based on the port]. If not all same-origin fragments have been identified, retain the fragmentation mapping table and directly proceed to the next step [determine the service type based on the port].

[0138] At the application layer, different and fixed ports are pre-defined based on different service types. In the step of "Determining Service Type Based on Port," the service type of the "UDP packet" service flow is directly determined by the port number, and the received service flows are divided into different priorities. Then, proceed to the next step, "Adding Custom Packet Header Encapsulation for Subsequent QoS Processing."

[0139] In the step of "Adding custom header encapsulation for subsequent QoS processing", custom headers are added to "ICMP packets" and "UDP packets" according to priority and other service information to facilitate subsequent QoS processing.

[0140] Finally, it is delivered to the next layer for processing.

[0141] Example 2

[0142] Received both duplicate ICMP packets and unique complete UDP packets broadcast.

[0143] At the entry point [receiving IP packets], the broadcast address is a pre-determined, fixed IP address. Therefore, [checking if the destination IP is a broadcast address] confirms that the "ICMP packet" and "UDP packet" are broadcast packets, and proceeds to the next step [checking if there is a corresponding fragmentation mapping table].

[0144] In the "Check if there is a corresponding fragmentation mapping table" step, if there is a fragmentation mapping table corresponding to "ICMP packet", it indicates that a broadcast storm has occurred, and the "ICMP packet" is discarded; if there is no fragmentation mapping table corresponding to "UDP packet", then all packets will be identified subsequently.

[0145] First, the 16-bit protocol type field in the IP header is used to check whether port identification is required. The protocol type is identified as "UDP packet". "UDP packet" requires port identification processing, and the process proceeds to the next step to check whether fragmentation is needed.

[0146] In the "Fragmentation Detection" step, data packets for which port identification is required are divided into two categories: complete packets and fragmented packets. Fragmented "UDP packets" are identified as complete packets based on the fact that the third bit (MF) of the 3-bit flags in the IP header is 0 and the 13-bit fragment offset in the IP header is 0.

[0147] For a complete "UDP packet", after establishing a fragmentation mapping table, the QoS service type is determined based on the port.

[0148] At the application layer, different and fixed ports are pre-defined based on different service types. In the step of "Determining Service Type Based on Port," the service type of the "UDP packet" service flow is directly determined by the port number, and the received service flows are divided into different priorities. Then, proceed to the next step, "Adding Custom Packet Header Encapsulation for Subsequent QoS Processing."

[0149] In the step of "Adding a custom header for subsequent QoS processing", a custom header is added to the "UDP packet" according to the priority and other service information to facilitate subsequent QoS processing.

[0150] Finally, it is delivered to the next layer for processing.

[0151] In summary, this invention establishes a fragmentation mapping table by extracting 5-tuple information and other relevant information from IP packets, thereby simultaneously achieving the port mapping required for broadcast storm suppression and QoS traffic classification. This not only simplifies the processing flow but also saves system resources.

[0152] The technical features of the above embodiments can be combined in any way. For the sake of brevity, 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 embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these modifications and improvements all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for broadcast storm suppression and QoS port identification in a self-organizing network scenario, characterized in that, include: Step 1, IP packet preprocessing: After receiving an IP packet, the host determines whether the IP packet is a broadcast message and checks if there is a corresponding fragmentation mapping table. The specific method is as follows: 1.1) After receiving an IP packet, the host checks whether the 32-bit destination IP address of the IP packet is a broadcast address, based on the characteristic that the destination IP address of a broadcast message is predetermined and fixed, to determine whether the IP packet is a broadcast message: a. If it is a broadcast message, proceed to the next step to check if there is a corresponding fragment mapping table; b. If it is not a broadcast message, only fragmented IP packets will be identified in the subsequent processing of IP packets; 1.2) Check if there is a corresponding sharding mapping table: If a fragmentation mapping table corresponds to an IP packet, discard the IP packet. If not, all IP packets will be identified during subsequent IP packet processing; Step 2, IP packet classification and processing: Based on the IP header and transport layer port information, determine whether the IP packet needs QoS port mapping. Divide the IP packet type into two categories: those that do not require port identification and those that do. The specific method is as follows: 2.1) Based on the information in the IP header and transport layer port, determine whether the IP packet needs to be mapped to QoS port. Divide the IP packet type into two categories: those that do not need to identify the port and those that do need to identify the port. 2.2) For IP packets that do not require port identification: a. If it is not a broadcast message, there is no need to create a fragmentation mapping table. Just add a custom packet header for encapsulation and perform subsequent QoS processing. b. If it is a broadcast message, after establishing the fragmentation mapping table, add a custom packet header for encapsulation and perform subsequent QoS processing; 2.3) For IP packets requiring port identification, they are classified into three categories based on the 3-bit identifier and 13-bit offset in the IP header: a. Complete packet: There are two cases. The first case is a packet that cannot be fragmented, in which the second DF bit of the 3-bit flag in the IP header is 1. The second case is a packet that can be fragmented, but is not fragmented, in which the second DF bit of the 3-bit flag in the IP header is 0, the third MF bit is 0, and the 13-bit fragment offset in the IP header is 0. b. First chip: The second DF bit of the 3-bit flag bits in the IP header is 0, the third MF bit is 1, and the 13-bit chip offset of the IP header is 0; c. Non-first chip: The second DF bit of the 3-bit flag bits in the IP header is 0, the third MF bit is 1, and the 13-bit chip offset of the IP header is not 0; 2.4) For complete packages: a. If it is not a broadcast message, there is no need to establish a fragmentation mapping table; the QoS service type can be determined directly based on the port. b. If it is a broadcast message, the QoS service type is determined based on the port after the fragmentation mapping table is established. 2.5) For the first packet, after establishing the fragmentation mapping table, determine the QoS service type based on the port; 2.6) For non-first fragment packets, extract the IP header information and match it with the existing fragmentation mapping table: a. If a corresponding fragment mapping table exists, extract the port information recorded in the fragment mapping table, and check whether all source fragments are identified based on the fragment offset; b. If there is no fragment packet corresponding to the fragment mapping table, proceed to step 2.7) Fragment out-of-order processing flow; 2.7) Detect whether all homogeneous fragments have been identified based on fragment offset. That is, based on the 13-bit fragment offset in the IP header, add the fragment offsets of all homogeneous fragments that have been processed except for the last fragment. When the accumulated value equals the fragment offset of the received last fragment, it indicates that all homogeneous fragments have been identified. There are two cases: a. Identify all fragments from the same source: Actively delete fragment mapping tables and determine the QoS service type based on the port; b. Not all fragments from the same source are identified: Retain the fragmentation mapping table and directly determine the QoS service type based on the port; Step 3, Post-processing of IP packets: Determine the service type of the service flow by the port number, divide the received service flows into different priorities, and encapsulate the IP packets with a custom header according to priority and other service information for subsequent QoS processing.

2. The broadcast storm suppression and QoS port identification method in a self-organizing network scenario according to claim 1, characterized in that, The IP packet contains two parts of information, namely: One part is the IP packet header, which contains fields containing specific information, including a 16-bit ID identifier, a 3-bit identifier bit, a 13-bit fragment offset, an 8-bit protocol type, a 32-bit source IP address, and a 32-bit destination IP address. The 16-bit ID identifier field is maintained by a counter in the IP software's memory. Each time a packet is generated, the counter is incremented by 1, and this value is assigned to the identifier field. When fragmentation occurs, the value of this identifier field is copied to the ID identifier fields of all fragmented packets from the same source. The second bit of the 3-bit identifier bit, DF, indicates whether fragmentation is possible (0 for fragmentation, 1 for no fragmentation). The third bit, MF, indicates whether this is the last fragment (0 for the last fragment, 1 for more fragments). The 13-bit fragment offset field indicates the relative position of a fragment within the original packet after fragmentation; if there is no fragmentation, this field defaults to 0. The 8-bit protocol type field identifies the protocol type of the information contained in the current packet. The 32-bit source IP address and 32-bit destination IP address refer to the IP addresses of the host that sent and received the current IP packet, respectively. The other part is the port information of the transport layer message contained in the IP packet, including the 16-bit source port number and 16-bit destination port number information in the header of the transport layer packet. 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 broadcast storm suppression and QoS port identification method in a self-organizing network scenario according to claim 1, characterized in that, The sharding mapping table is built using a combination of a hash table and a doubly linked list, where: The key of the hash table is the index of the fragmentation mapping table, which is obtained by hashing the source IP address, destination IP address and ID identifier extracted from the IP packet. The data stored in the fragmentation mapping table is the ID identifier, source port, destination port, fragment offset and linked list pointer. The hash function uses the division remainder method. Let M be the number of allowed addresses in the hash table. Take a prime number p, not greater than M but closest to or equal to M, as the divisor. Then, convert the key into a hash address using the following hash function: Hash(key) = key % p, p <= M The Key is composed of a 32-bit source IP address + a 32-bit destination IP address + a 16-bit ID identifier. M is determined based on the amount of point-to-point traffic per second in the communication network, with the consideration of minimizing table lookup time. Doubly linked lists are used to maintain the access order of sharded maps. Nodes closer to the head of the list represent more recently used sharded maps, while nodes closer to the tail of the list represent sharded maps that have not been used for a long time.

Images