IPv4 data message processing method and device based on longest prefix matching

Abstract

The invention relates to an IPv4 data message processing method and device based on longest prefix matching. The method comprises the following steps: acquiring an IPv4 data message, and extracting a destination IP address in the message; based on a longest prefix matching mode, extracting a preset number of bits from the high order of the destination IP address; generating a search index through the preset number of bits; determining a corresponding table item in a pre-stored FPGA rule matching table according to the lookup index; extracting a message processing rule according to pre-stored information of the table item; and executing a subsequent processing action on the IPv4 data message based on the message processing rule. According to the method and the device, the IPv4 message prefix matching can be carried out through FPGA hardware acceleration, a matching result is generated through single query, linear speed processing under million-level rules is supported, and meanwhile, the longest prefix priority principle is automatically maintained when the rules are changed through a CPU-FPGA collaborative updating mechanism.

Description

Technical Field

[0001] This application relates to the field of computer information processing. Specifically, it relates to a method and device for processing IPv4 data packets based on the longest prefix match. Background Art

[0002] With the rapid development of network technology, network devices need to efficiently identify and filter data packets. Traditionally, network devices use an exact match rule based on a five-tuple (source IP address, destination IP address, source port, destination port, and protocol type) to process packets. Although this exact match mechanism is simple and straightforward, it has obvious limitations: a data packet can only match a single unique rule, and when there is no exactly matching five-tuple rule, the packet will not hit any rule, lacking flexibility.

[0003] To improve the flexibility of matching, the industry has proposed a rule processing method based on the longest prefix match. This mechanism is similar to the routing lookup process and preferentially matches the IP network segment with the longest mask length. The main technical solutions for implementing the longest prefix match currently include:

[0004] Hash table algorithm: This algorithm needs to maintain 32 different-length hash tables. When looking up, the hash values are calculated in descending order of mask length (from 32 bits to 1 bit) until a match is found. The lookup performance of this method is greatly affected by the number of routing table entries and the mask length distribution. In the worst case, all lengths of hash tables need to be traversed.

[0005] Prefix tree (Trie tree) algorithm: This algorithm stores IP addresses in segments in a tree structure and matches layer by layer starting from the root node. Although it has certain improvements compared to the hash table algorithm, there are still the following problems: it is necessary to construct a complex prefix tree structure, the lookup performance is affected by the total number of routing tables and the mask length distribution, and the overhead of updating and maintaining the tree structure is large.

[0006] Existing technical solutions all face serious performance bottlenecks when dealing with millions of rule entries and are difficult to meet the requirements of high-speed forwarding. Specifically, it is manifested as: high lookup time complexity, inability to achieve deterministic latency, low rule update efficiency, affecting the overall performance of the system, large storage overhead, and difficulty in supporting large-scale rule tables. These problems severely restrict the application of network devices in high-performance scenarios.

[0007] Therefore, a new method and device for processing IPv4 data packets based on the longest prefix match are needed.

[0008] The above information disclosed in the background art section is only used to enhance the understanding of the background of this application. Therefore, it may include information that does not constitute the prior art known to those of ordinary skill in the art. Summary of the Invention

[0009] In view of this, the present application provides an IPv4 data packet processing method and apparatus based on the longest prefix match, which can perform prefix matching of IPv4 packets through FPGA hardware acceleration, generate a matching result in a single query, support line speed processing under millions of rules, and at the same time ensure the automatic maintenance of the longest prefix priority principle when the rules change through the CPU-FPGA collaborative update mechanism.

[0010] Other features and advantages of the present application will become apparent through the following detailed description, or will be learned in part through the practice of the present application.

[0011] According to one aspect of the present application, an IPv4 data packet processing method based on the longest prefix match is proposed. The method includes: obtaining an IPv4 data packet and extracting the destination IP address in the packet; based on the longest prefix match method, extracting a preset number of bit positions from the high-order bits of the destination IP address; generating a search index through the preset number of bit positions; determining a corresponding table entry in a pre-stored FPGA rule matching table according to the search index; extracting a packet processing rule according to the pre-stored information in the table entry; and performing subsequent processing actions on the IPv4 data packet based on the packet processing rule.

[0012] In an exemplary embodiment of the present application, it further includes: receiving a longest prefix rule to be updated, where the longest prefix rule includes an IP network segment address, a prefix length, and a packet processing rule; determining a table entry range of a corresponding FPGA rule matching table according to the IP network segment address and the prefix length; updating the rule bitmap information maintained by the CPU, where the bitmap is used to identify the validity of each prefix length; determining the prefix length corresponding to each table entry according to the updated bitmap information; and updating the prefix length and the packet processing rule to the corresponding table entry in the FPGA rule matching table.

[0013] In an exemplary embodiment of the present application, based on the longest prefix match method, extracting a preset number of bit positions from the high-order bits of the destination IP address includes: determining that the preset number is N based on the longest prefix match method and the system processing capacity; and extracting N bit positions from the address bit positions of the destination IP address from high to low.

[0014] In an exemplary embodiment of the present application, determining a corresponding table entry in a pre-stored FPGA rule matching table according to the search index includes: accessing the corresponding table entry of the pre-stored FPGA rule matching table with the search index as the address bit.

[0015] In an exemplary embodiment of the present application, extracting a packet processing rule according to the pre-stored information of the table entry includes: reading the valid bit and the prefix length from the pre-stored information of the table entry; when the valid bit is 1, determining that the packet matches the packet processing rule corresponding to the prefix length; when the valid bit is 0, determining that the packet does not match the packet processing rule.

[0016] In an exemplary embodiment of the present application, determining the table entry range of the corresponding FPGA rule matching table according to the IP network segment address and the prefix length includes: performing a bitwise AND operation on the IP network segment address and the mask 0xFFFFFF80 and then shifting it right by 7 bits to use as the starting table entry address: calculating the number of table entries to be updated; determining the table entry range through the starting table entry address and the number of table entries to be updated.

[0017] In an exemplary embodiment of the present application, updating the rule bitmap information maintained by the CPU, where the bitmap is used to identify the validity of each prefix length, includes: when adding the longest prefix rule, setting the bit corresponding to the prefix length in the bitmap to 1; when deleting the longest prefix rule, setting the bit corresponding to the prefix length in the bitmap to 0.

[0018] In an exemplary embodiment of the present application, determining the prefix length corresponding to each table entry according to the updated bitmap information includes: scanning from the most significant bit to the least significant bit of the bitmap, and selecting the prefix length corresponding to the first set bit as the prefix length of the table entry.

[0019] In an exemplary embodiment of the present application, updating the prefix length and the packet processing rule to the corresponding table entry of the FPGA rule matching table includes: using the batch write method for the prefix length and the packet processing rule, and accelerating data transmission to the corresponding table entry of the FPGA rule matching table through DMA.

[0020] According to an aspect of the present application, a device for processing IPv4 data packets based on the longest prefix matching is proposed. The device includes: a packet module for obtaining an IPv4 data packet and extracting the destination IP address in the packet; an address module for extracting a preset number of bit positions from the high bits of the destination IP address based on the longest prefix matching method; an index module for generating a search index through the preset number of bit positions; a matching module for determining the corresponding table entry in the pre-stored FPGA rule matching table according to the search index; a rule module for extracting a packet processing rule according to the pre-stored information of the table entry; and a processing module for performing subsequent processing actions on the IPv4 data packet based on the packet processing rule.

[0021] According to one aspect of the present application, an electronic device is provided, which includes: one or more processors; a storage device for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors implement the method as described above.

[0022] According to one aspect of the present application, a computer-readable medium is provided, on which a computer program is stored, and when the program is executed by a processor, the method as described above is implemented.

[0023] Based on the longest prefix matching IPv4 data packet processing method and apparatus of the present application, by obtaining an IPv4 data packet, extracting the destination IP address in the packet; based on the longest prefix matching method, extracting a preset number of bits from the high bits of the destination IP address; generating a search index through the preset number of bits; determining a corresponding table entry in a pre-stored FPGA rule matching table according to the search index; extracting a packet processing rule according to the pre-stored information of the table entry; based on the packet processing rule, performing subsequent processing actions on the IPv4 data packet, it is possible to perform prefix matching of IPv4 packets through FPGA hardware acceleration, generate a matching result in a single query, support wire-speed processing under millions of rules, and at the same time ensure the automatic maintenance of the longest prefix priority principle when the rules change through the CPU-FPGA cooperative update mechanism.

[0024] It should be understood that the above general description and the following detailed description are only exemplary and do not limit the present application. Description of the Drawings

[0025] By referring to the accompanying drawings and describing its exemplary embodiments in detail, the above and other objects, features and advantages of the present application will become more obvious. The following described drawings are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0026] Figure 1 It is a flowchart of a method for processing an IPv4 data packet based on the longest prefix matching according to an exemplary embodiment.

[0027] Figure 2 It is a flowchart of a method for processing an IPv4 data packet based on the longest prefix matching according to another exemplary embodiment.

[0028] Figure 3 It is a schematic diagram of a method for processing an IPv4 data packet based on the longest prefix matching according to another exemplary embodiment.

[0029] Figure 4It is a block diagram of an IPv4 data packet processing device based on the longest prefix match shown according to an exemplary embodiment.

[0030] Figure 5 It is a block diagram of an electronic device shown according to an exemplary embodiment.

[0031] Figure 6 It is a block diagram of a computer-readable medium shown according to an exemplary embodiment. Detailed implementation manners

[0032] Example embodiments will now be described more fully with reference to the accompanying drawings. However, the example embodiments can be implemented in various forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the concept of the example embodiments to those skilled in the art. Identical reference numerals in the figures denote identical or similar parts, and thus their repeated description will be omitted.

[0033] In addition, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of the embodiments of this application. However, those skilled in the art will realize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, devices, steps, etc. can be adopted. In other cases, well-known methods, devices, implementations, or operations are not shown or described in detail to avoid obscuring aspects of this application.

[0034] The block diagrams shown in the accompanying drawings are only functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0035] The flowcharts shown in the accompanying drawings are only illustrative and do not necessarily include all the content and operations / steps, nor do they necessarily have to be executed in the described order. For example, some operations / steps can be decomposed, while some operations / steps can be combined or partially combined, so the actual execution order may change according to the actual situation.

[0036] It should be understood that although terms such as first, second, and third may be used herein to describe various components, these components should not be limited by these terms. These terms are used to distinguish one component from another. Therefore, the first component discussed below can be referred to as the second component without departing from the teachings of the concept of this application. As used herein, the term "and / or" includes any one and all combinations of one or more of the associated listed items.

[0037] Those skilled in the art can understand that the accompanying drawings are only schematic diagrams of exemplary embodiments, and the modules or processes in the accompanying drawings are not necessarily essential for implementing this application, so they cannot be used to limit the protection scope of this application.

[0038] The technical abbreviations involved in this application are explained as follows:

[0039] ACL: Access Control List, an access policy table implemented in software / hardware. Network devices can search this access policy table for traffic according to a specified algorithm, and perform corresponding control on network traffic based on the access policy returned by the search.

[0040] FPGA: Field Programmable Gate Array, a programmable chip. The internal storage unit realizes the functions of the chip by loading program code. Compared with traditional logic circuits, FPGA allows unlimited programming.

[0041] Packet filtering: Filter data traffic to screen out concerned or unconcerned traffic.

[0042] Longest route matching: A routing search algorithm. When querying the routing table for the IP address of a data packet, it preferentially matches the routing table entry with the longest IP mask length in the routing table, and forwards the IP packet according to the longest matching result.

[0043] To meet the high-speed search and forwarding requirements of millions of IPv4 routing table entries, this application proposes a rule management and data processing method based on the cooperation of CPU and FPGA.

[0044] In view of the performance bottleneck of the CPU in processing real-time searches of millions of routing table entries, relying solely on the CPU cannot achieve efficient data packet forwarding. Therefore, a system architecture of cooperative processing between the CPU and FPGA is adopted. Among them, the CPU undertakes the functions of rule management and control plane, and is responsible for organizing, maintaining, and updating millions of longest prefix rules; the FPGA undertakes the functions of data forwarding and search plane, and uses its high-speed parallel processing ability and sufficient internal resource space to achieve fast search and matching of large-capacity rule table entries.

[0045] In specific implementation, the CPU issues the longest prefix rules that have been managed and optimized to the storage space of the FPGA. The FPGA generates a search index based on the destination IP address, retrieves the stored table entries, completes the rule search based on the longest prefix match, and performs corresponding subsequent processing actions on the data packet according to the hit packet processing rule.

[0046] By functionally separating the control plane from the data forwarding plane, this solution not only meets the performance requirements for high-speed lookup of millions of table entries, but also effectively improves the stability and expandability of device operation, and is applicable to application scenarios with extremely high forwarding performance requirements such as large-scale data centers and high-performance routers.

[0047] The following uses specific embodiments to elaborate in detail on the technology of this application.

[0048] Figure 1 It is a flowchart of a method for processing IPv4 data packets based on the longest prefix match shown according to an exemplary embodiment. The method 10 for processing IPv4 data packets based on the longest prefix match at least includes steps S102 to S112.

[0049] As Figure 1 shown, in S102, obtain the IPv4 data packet and extract the destination IP address in the packet. After the device receives the IPv4 data packet to be processed, it first parses the packet and extracts the destination IP address field in the packet header.

[0050] For example, for a received data packet, its destination IP address is 10.20.50.123, which is 0A.14.32.7B in hexadecimal representation.

[0051] In S104, based on the longest prefix match method, extract a preset number of bit positions from the high-order bits of the destination IP address. For example, based on the longest prefix match method, the preset number can also be determined as N in combination with the processing capacity of the actual system; extract N bit positions from the address bit positions of the destination IP address from high to low. In an embodiment of this application, N can be 25. That is, extract the highest 25 bits from the 32 bits of the destination IP address as the matching index.

[0052] In practical applications, the range of the prefix length of the Ipv4 longest prefix rule is 8 - 25. When the logical table entry resources of the system are sufficient, the high 25 bits of the ip address can be directly used as the lookup table index. For the convenience of explanation, some names in the following text are explained:

[0053] Elements of the longest prefix match rule:

[0054] Ipaddr: The network segment that a rule needs to match, represented by an ip address

[0055] Prefix: The mask length of the ip address that a rule needs to match, with a range of 8 - 25

[0056] For example, 192.168.20.1 / 16 indicates that the mask length of the IP address segment 192.168.20.1 is 16, that is, all IP addresses within the range of 192.168.X.X match this IPv4 longest prefix rule.

[0057] For the above-mentioned longest prefix rule, the corresponding FPGA rule matching table (fpga_index) is the high 25 bits of all IPs within this network segment range. Therefore, a total of 2^(25 - 16) = 512 FPGA table entries need to match the above-mentioned longest prefix rule.

[0058] In the following text, in order to obtain the matching result in one search, when the prefix length prefix_len of a certain longest prefix rule is < 25, it is necessary to update the FPGA table entries at the fpga_index corresponding to all IP addresses belonging to this network segment range. The specific content is as Figure 3 shown in the embodiments of

[0059] In S106, a search index is generated through the preset number of bit positions. For example, the corresponding table entry of the pre-stored FPGA rule matching table can be accessed using the search index as the address bit. The extracted N bits are used as the index value to locate the specific table entry of the rule matching table pre-stored in the FPGA.

[0060] For example, consider the above-mentioned extracted 25 bits as a binary number, convert it to hexadecimal, and form the search index 0x0A14320.

[0061] In S108, the corresponding table entry is determined in the pre-stored FPGA rule matching table according to the search index.

[0062] In S110, the packet processing rule is extracted according to the pre-stored information of the table entry. For example, the valid bit and the prefix length are read from the pre-stored information of the table entry; when the valid bit is 1, it is determined that the packet matches the packet processing rule corresponding to the prefix length; when the valid bit is 0, it is determined that the packet does not match the packet processing rule.

[0063] Parse the information stored in the FPGA table entry, determine whether the rule is hit, and extract the packet processing action that is matched.

[0064] For example, read the valid field and the prefix_len field in the table entry;

[0065] If valid = 1, it means that the current search hits, and continue to read the associated packet processing rule;

[0066] If valid = 0, it means that the current search does not hit any rule, and by default, it is processed according to the no-match rule.

[0067] For example, it is read from the table entry that:

[0068] valid = 1

[0069] prefix_len = 24

[0070] Packet processing rule = Discard

[0071] It is then determined that the current packet matches a rule with a prefix length of 24 bits, and the "Discard" action should be executed.

[0072] In S112, subsequent processing actions are performed on the IPv4 data packet based on the packet processing rule. If the packet processing rule is "Forward to port 1", the data packet is output to port 1; if the packet processing rule is "Discard", the data packet is directly discarded; other actions can also be performed, such as rate limiting, marking QoS tags, etc.

[0073] In the above example, since the matched rule indicates "Discard", the device discards the data packet and does not forward it externally.

[0074] According to the IPv4 data packet processing method based on the longest prefix match of the present application, by obtaining the IPv4 data packet, the destination IP address in the packet is extracted; based on the longest prefix match method, a preset number of bits are extracted from the high bits of the destination IP address; a search index is generated through the preset number of bits; a corresponding table entry is determined in the pre-stored FPGA rule match table according to the search index; the packet processing rule is extracted according to the pre-stored information of the table entry; based on the packet processing rule, subsequent processing actions are performed on the IPv4 data packet, which can perform the prefix match of the IPv4 packet through FPGA hardware acceleration, generate a matching result in a single query, support wire speed processing under millions of rules, and at the same time ensure the automatic maintenance of the longest prefix priority principle when the rules change through the CPU-FPGA collaborative update mechanism.

[0075] It should be clearly understood that the present application describes how to form and use specific examples, but the principles of the present application are not limited to any details of these examples. On the contrary, based on the teachings of the content disclosed in the present application, these principles can be applied to many other embodiments.

[0076] Figure 2 is a flowchart of a method for processing an IPv4 data packet based on the longest prefix match shown in accordance with an exemplary embodiment. Figure 2 The flow 20 shown is a supplementary description of Figure 1 the flow shown.

[0077] Such as Figure 2As shown, in S202, receive the longest prefix rule to be updated, where the longest prefix rule includes an IP network segment address, a prefix length, and a packet processing rule.

[0078] In S204, determine the table entry range of the corresponding FPGA rule matching table according to the IP network segment address and the prefix length. The IP network segment address can be ANDed with the mask 0xFFFFFF80 bit by bit and then shifted right by 7 bits to be used as the starting table entry address: calculate the number of table entries to be updated; determine the table entry range through the starting table entry address and the number of table entries to be updated.

[0079] In a specific embodiment: for the process of adding / deleting the longest prefix rule update, see the following examples S1, S2, S3

[0080] Calculation of the updated table entry address: The high 25 bits of the packet IP address can be extracted as the FPGA rule matching table address fpga_index, and the address range is 0x0000000 - 0x1FFFFFF

[0081] Content in the updated table entry address: valid: indicates whether there is a rule at this address, 1 means valid, 0 means invalid

[0082] Len: represents the mask length of this table entry address.

[0083] S1: Add rule Rule-A: 10.20.50.11 / 16, and the corresponding ipaddr address range is 0x0A140000 - 0x0A14FFFF

[0084] Shift ipaddr right by 7 bits to get the fpga_index range: 0x142800 - 0x1429FF

[0085] The FPGA rule matching table is as shown in Tab1

[0086] Table entry address Table entry content 0x0000000 ... 0x142800 Valid = 1, pre_len = 16 . . 0x1429FF Valid = 1, pre_len = 16 ... 0x1FFFFFF

[0087] Tab1: In the FPGA table entry content, valid is the valid flag bit, and prefix_len is the prefix length of the rule at the table entry position. At this time, there is only Rule-A: 10.20.50.11 / 16

[0088] S2: Then add rule Rule-B: 10.20.50.11 / 24, and the corresponding ipaddr address range is 0x0A143200 - 0x0A1432FF

[0089] Shift ipaddr right by 7 bits to get the fpga_index range: 0x142864 - 0x142865

[0090] The FPGA rule matching table is as shown in Tab2

[0091]

[0092]

[0093] Tab2: In the content of the FPGA table entry, valid is the valid flag bit, and prefix_len is the prefix length of the rule at the table entry position. At this time, there are in the table:

[0094] Rule-A: 10.20.50.11 / 16,

[0095] Rule-B: 10.20.50.11 / 24

[0096] S3: Delete rule Rule-A: 10.20.50.11 / 16, and the corresponding ipaddr address range is 0x0A140000 - 0x0A14FFFF

[0097] Shift ipaddr to the right by 7 bits to get the fpga_index range: 0x142800 - 0x1429FF,

[0098] After the FPGA rule matching table is updated, as shown in Tab3:

[0099]

[0100]

[0101] Tab3: In the content of the FPGA table entry, valid is the valid flag bit, and prefix_len is the prefix length of the rule at the table entry position. At this time, there is Rule-B: 10.20.50.11 / 24 in the table

[0102] In S206, update the rule bitmap information maintained by the CPU. The bitmap is used to identify the validity of each prefix length. When adding the longest prefix rule, set the bit corresponding to the prefix length in the bitmap to 1; when deleting the longest prefix rule, set the bit corresponding to the prefix length in the bitmap to 0.

[0103] The control plane needs to manage and store the longest prefix rule. After checking for duplicates and verifying the legality of the rule for the longest prefix rule, store it in memory using the fpga_index of the FPGA table entry as the index. That is, when adding / deleting the longest prefix rule, the bitmap of the cpu-tab stored by the control plane at the index fpga_index needs to be updated, and the stored table entry of the FPGA is synchronously sent down.

[0104] The control plane uses a bitmap to record which longest prefix matching rules are configured for the ipaddr corresponding to each fpga_index. When sending the longest prefix rules to the FPGA, only the prefix rule with the longest prefix is sent.

[0105] The conversion relationship between the prefix rule network segment address ipaddr and the table entry fpga_index:

[0106] ipaddr = fpga_index << 7

[0107] fpga_index is the upper 25 bits of the network segment address.

[0108] In S208, according to the updated bitmap information, determine the prefix length corresponding to each table entry. It can be scanned from the most significant bit to the least significant bit of the bitmap, and the prefix length corresponding to the first set bit is selected as the prefix length of this table entry.

[0109] When adding the rule ipaddr / prefix, set the bitmap corresponding to the rule mask length to 1;

[0110] When deleting the rule ipaddr / prefix, set the bitmap corresponding to the rule mask length to 0.

[0111] When the CPU sends FPGA table entries, determine the FPGA storage table entry fpga_index and the number of table entries number that need to be updated according to ipaddr and prefix. After updating the bitmap stored in each index fpga_index, find the longest prefix length len in the bitmap, and send the prefix to the table entry at fpga_index in the FPGA storage table entry.

[0112] The table entry address tab-addr in the cpu memory is the same as the index fpga_index of the FPGA chip table entry, and the calculation is the same as above:

[0113] Extract the upper 25 bits of the longest prefix rule ipaddr as the table entry address tab-addr, and all the address space ranges from 0x0000000 to 0x1FFFFFF

[0114] As Figure 3 shown, when there are two rules Rule-A and Rule-B,

[0115] Rule-A: 10.20.50.11 / 24 has a total of 2^(25 - 24) = 2 addresses,

[0116] 00001010 0001010000110010x

[0117] Rule - B: 10.20.50.11 / 16 has a total of 2^(25 - 16) = 512 addresses, 0000101000010100xxxxxxxx x

[0118] In the above addresses, x represents that both 0 and 1 are valid addresses. The number of entries rule - tab - number that need to be updated for a longest prefix rule = 2^(the number of x's)

[0119] The number of x's = 25 - the rule prefix length len;

[0120] Update the int - type bitmap in each entry:

[0121] When issuing the longest prefix rule, calculate the entry address tab - addr from the network segment address Rule - ipaddr of the prefix rule:

[0122] Tab - addr = (Rule - ipaddr & 0xFFFFFF80) >> 7

[0123] Update the entry content of each tab - addr. The number of entries rule - tab - number that need to be updated for each rule:

[0124] Add rule: CPU - tab[tab - addr].bitmap |= 1 << Rule - len, set the bit at the rule length position in the bitmap to 1

[0125] Delete rule: Cpu - tab[tab - addr].bitmap &= ~(1 << Rule - len), set the bit at the rule length position in the bitmap to 0.

[0126] When issuing the FPGA entry, according to the bitmap of the entry tab - addr recorded in the CPU memory, find the highest valid bit position to obtain the rule length, and update it as the length to the content of the FPGA chip entry address tab - addr.

[0127] In S210, update the prefix length and the packet processing rule to the corresponding entry of the FPGA rule matching table. The prefix length and the packet processing rule can be written in batches, and the data transmission to the corresponding entry of the FPGA rule matching table can be accelerated through DMA.

[0128] Those skilled in the art can understand that all or part of the steps of implementing the above - mentioned embodiments are implemented as a computer program executed by the CPU. When the computer program is executed by the CPU, it executes the above - mentioned functions defined by the above - mentioned method provided in this application. The program can be stored in a computer - readable storage medium, and this storage medium can be a read - only memory, a disk, or an optical disc, etc.

[0129] In addition, it should be noted that the above-mentioned drawings are only schematic illustrations of the processes included in the method according to the exemplary embodiments of the present application, rather than for restrictive purposes. It is easy to understand that the processes shown in the above-mentioned drawings do not indicate or limit the chronological order of these processes. Additionally, it is also easy to understand that these processes can be executed synchronously or asynchronously in, for example, multiple modules.

[0130] The following is an embodiment of the apparatus of the present application, which can be used to execute the embodiment of the method of the present application. For details not disclosed in the embodiment of the apparatus of the present application, please refer to the embodiment of the method of the present application.

[0131] Figure 4 is a block diagram of an IPv4 data packet processing apparatus based on the longest prefix match shown according to an exemplary embodiment. As Figure 4 shown, the IPv4 data packet processing apparatus 40 based on the longest prefix match includes: a packet module 402, an address module 404, an index module 406, a matching module 408, a rule module 410, a processing module 412. The IPv4 data packet processing apparatus 40 based on the longest prefix match may further include: an update module 414.

[0132] The packet module 402 is used to obtain an IPv4 data packet and extract the destination IP address in the packet;

[0133] The address module 404 is used to extract a preset number of bit positions from the high-order bits of the destination IP address based on the longest prefix match method; the address module 404 is further used to determine that the preset number is N based on the longest prefix match method; extract N bit positions from the address bit positions of the destination IP address from high to low.

[0134] The index module 406 is used to generate a search index through the preset number of bit positions; the index module 406 is further used to access the corresponding entry of the pre-stored FPGA rule matching table with the search index as the address bit.

[0135] The matching module 408 is used to determine the corresponding entry in the pre-stored FPGA rule matching table according to the search index;

[0136] The rule module 410 is used to extract the packet processing rule according to the pre-stored information of the entry; the rule module 410 is further used to read the valid bit and the prefix length from the pre-stored information of the entry; when the valid bit is 1, determine that the packet matches the packet processing rule corresponding to the prefix length; when the valid bit is 0, determine that the packet does not match the packet processing rule.

[0137] The processing module 412 is used to perform subsequent processing actions on the IPv4 data packet based on the packet processing rule.

[0138] The update module 414 is configured to receive the longest prefix rule to be updated, where the longest prefix rule includes an IP network segment address, a prefix length, and a packet processing rule; determine a table entry range of a corresponding FPGA rule matching table according to the IP network segment address and the prefix length; update the rule bitmap information maintained by the CPU, where the bitmap is used to identify the validity of each prefix length; determine the prefix length corresponding to each table entry according to the updated bitmap information; and update the prefix length and the packet processing rule to the corresponding table entries of the FPGA rule matching table.

[0139] According to the IPv4 data packet processing apparatus based on the longest prefix matching in the present application, by obtaining an IPv4 data packet, extracting the destination IP address in the packet; based on the longest prefix matching method, extracting a preset number of bit positions from the high order of the destination IP address; generating a search index through the preset number of bit positions; determining a corresponding table entry in a pre-stored FPGA rule matching table according to the search index; extracting a packet processing rule according to the pre-stored information of the table entry; and performing subsequent processing actions on the IPv4 data packet based on the packet processing rule, the longest prefix matching of the IPv4 packet can be accelerated by FPGA hardware, a matching result can be generated by a single query, line speed processing under millions of rules can be supported, and at the same time, the longest prefix priority principle can be automatically maintained when the rules change through the CPU-FPGA collaborative update mechanism.

[0140] Figure 5 is a block diagram of an electronic device shown according to an exemplary embodiment.

[0141] Reference is now made to Figure 5 to describe the electronic device 500 according to this embodiment of the present application. Figure 5 The electronic device 500 shown is merely an example and should not impose any limitation on the functions and usage scope of the embodiments of the present application.

[0142] As Figure 5 shown, the electronic device 500 is presented in the form of a general-purpose computing device. The components of the electronic device 500 may include, but are not limited to: at least one processing unit 510, at least one storage unit 520, a bus 530 connecting different system components (including the storage unit 520 and the processing unit 510), a display unit 540, and the like.

[0143] Among them, the storage unit stores program code, and the program code can be executed by the processing unit 510, so that the processing unit 510 executes the steps according to various exemplary embodiments of the present application described in this specification. For example, the processing unit 510 may execute steps as shown in Figure 1 , Figure 2 shown.

[0144] The storage unit 520 may include a readable medium in the form of a volatile storage unit, such as a random access storage unit (RAM) 5201 and / or a cache storage unit 5202, and may further include a read-only storage unit (ROM) 5203.

[0145] The storage unit 520 may also include a program / utilities 5204 having a set (at least one) of program modules 5205. Such program modules 5205 include, but are not limited to: an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment.

[0146] The bus 530 may represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus structures.

[0147] The electronic device 500 may also communicate with one or more external devices 500' (such as a keyboard, a pointing device, a Bluetooth device, etc.), enabling the user to interact with the electronic device 500, and / or communicate with any device that enables the electronic device 500 to communicate with one or more other computing devices (such as a router, a modem, etc.). Such communication may be through an input / output (I / O) interface 550. Additionally, the electronic device 500 may also communicate with one or more networks (such as a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) through a network adapter 560. The network adapter 560 may communicate with other modules of the electronic device 500 through the bus 530. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with the electronic device 500, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, etc.

[0148] Through the description of the above embodiments, those skilled in the art can easily understand that the example embodiments described herein can be implemented by software, or by a combination of software and necessary hardware. Therefore, as Figure 6 shown, the technical solution according to the embodiment of the present application can be embodied in the form of a software product. The software product can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, including several instructions to enable a computing device (which can be a personal computer, a server, or a network device, etc.) to execute the above method according to the embodiment of the present application.

[0149] The software product may employ any combination of one or more readable media. The readable media can be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0150] The computer-readable storage medium may include a data signal propagated in a baseband or as part of a carrier wave, in which the readable program code is carried. Such a propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing. The readable storage medium may also be any readable medium other than the readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any appropriate medium, including but not limited to wireless, wired, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0151] The program code for performing the operations of this application may be written in any combination of one or more programming languages, including object-oriented programming languages such as Java, C++, etc., and also including conventional procedural programming languages such as the "C" language or similar programming languages. The program code may execute entirely on the user computing device, partially on the user device, execute as a stand-alone software package, execute partially on the user computing device and partially on a remote computing device, or execute entirely on the remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computing device (e.g., by using an Internet service provider to connect through the Internet).

[0152] The above computer-readable medium carries one or more programs, which, when executed by the device, cause the computer-readable medium to implement the following functions: obtaining an IPv4 data packet, extracting the destination IP address in the packet; based on the longest prefix matching method, extracting a preset number of bit positions from the high-order bits of the destination IP address; generating a search index through the preset number of bit positions; determining a corresponding table entry in a pre-stored FPGA rule matching table according to the search index; extracting a packet processing rule according to the pre-stored information in the table entry; and performing subsequent processing actions on the IPv4 data packet based on the packet processing rule.

[0153] Those skilled in the art can understand that the above-mentioned modules can be distributed in the device according to the description of the embodiments, or can be correspondingly changed and distributed in one or more devices that are different from the present embodiment. The modules of the above embodiments can be combined into one module, or can be further split into multiple sub-modules.

[0154] Through the description of the above embodiments, those skilled in the art can easily understand that the exemplary embodiments described herein can be implemented by software, or can be implemented by a combination of software and necessary hardware. Therefore, the technical solution according to the embodiments of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, including several instructions to cause a computing device (which can be a personal computer, a server, a mobile terminal, or a network device, etc.) to execute the method according to the embodiments of the present application.

[0155] The above specifically shows and describes the exemplary embodiments of the present application. It should be understood that the present application is not limited to the detailed structure, setting method or implementation method described herein; on the contrary, the present application is intended to cover various modifications and equivalent settings included in the spirit and scope of the appended claims.

Claims

1. An IPv4 data packet processing method based on the longest prefix match, characterized in that, including: Obtain an IPv4 data packet and extract the destination IP address in the packet; Based on the longest prefix matching method, extract a preset number of bit positions from the high-order bits of the destination IP address; Generate a search index through the preset number of bit positions; Determine the corresponding table entry in the pre-stored FPGA rule matching table according to the search index; Extract the packet processing rule according to the pre-stored information of the table entry; Perform subsequent processing actions on the IPv4 data packet based on the packet processing rule.

2. The method according to claim 1, wherein It also includes: Receive the longest prefix rule to be updated, where the longest prefix rule includes an IP network segment address, a prefix length, and a packet processing rule; Determine the table entry range of the corresponding FPGA rule matching table according to the IP network segment address and the prefix length; Update the rule bitmap information maintained by the CPU, where the bitmap is used to identify the validity of each prefix length; Determine the prefix length corresponding to each table entry according to the updated bitmap information; Update the prefix length and the packet processing rule to the corresponding table entry in the FPGA rule matching table.

3. The method according to claim 1, wherein Based on the longest prefix matching method, extract a preset number of bit positions from the high-order bits of the destination IP address, including: Based on the longest prefix matching method, determine that the preset number is N; Extract N bit positions from the address bit positions of the destination IP address from high to low.

4. The method according to claim 1, wherein Determine the corresponding table entry in the pre-stored FPGA rule matching table according to the search index, including: Use the search index as the address bit to access the corresponding table entry of the pre-stored FPGA rule matching table.

5. The method as claimed in claim 1, wherein Extract the packet processing rule according to the pre-stored information of the table entry, including: Read the valid bit and the prefix length from the pre-stored information of the table entry; When the valid bit is 1, determine that the packet matches the packet processing rule corresponding to the prefix length; When the valid bit is 0, determine that the packet does not match the packet processing rule.

6. The method according to claim 2, wherein Determine the table entry range of the corresponding FPGA rule matching table according to the IP network segment address and the prefix length, including: Perform a bitwise AND operation on the IP network segment address and the mask 0xFFFFFF80 and then shift it right by 7 bits to be used as the starting table entry address: Calculate the number of table entries to be updated; Determine the table entry range through the starting table entry address and the number of table entries to be updated.

7. The method according to claim 2, wherein Update the rule bitmap information maintained by the CPU, where the bitmap is used to identify the validity of each prefix length, including: When adding the longest prefix rule, set the bit corresponding to the prefix length in the bitmap to 1; When deleting the longest prefix rule, set the bit corresponding to the prefix length in the bitmap to 0.

8. The method according to claim 2, wherein Determine the prefix length corresponding to each table entry according to the updated bitmap information, including: Scan from the most significant bit to the least significant bit of the bitmap, and select the prefix length corresponding to the first set bit as the prefix length of the table entry.

9. The method according to claim 1, wherein Update the prefix length and the packet processing rule to the corresponding table entry in the FPGA rule matching table, including: Use the batch writing method to transfer the prefix length and the packet processing rule to the corresponding table entry in the FPGA rule matching table through DMA acceleration of data transmission.

10. An IPv4 data packet processing device based on the longest prefix match, characterized in that, including: A message module, which is used to obtain an IPv4 data message and extract the destination IP address in the message; An address module, which is used to extract a preset number of bit positions from the high bits of the destination IP address based on the longest prefix matching method; An index module, which is used to generate a search index through the preset number of bit positions; A matching module, which is used to determine the corresponding table entry in the pre-stored FPGA rule matching table according to the search index; A rule module, which is used to extract the message processing rule according to the pre-stored information of the table entry; A processing module, which is used to perform subsequent processing actions on the IPv4 data message based on the message processing rule.

Images