CN114884877A - IPv6 route searching method combining hash table and HOT - Google Patents

Abstract

The invention belongs to the technical field of route searching, and particularly relates to an IPv6 route searching method combining a hash table and an HOT. The invention provides a route searching algorithm combining a hash table and HOT on the basis of analyzing the distribution rule of prefix addresses of a backbone route table. The verification proves that the method has better performance in the aspects of query time, space occupation and the like.

Description

IPv6 route searching method combining hash table and HOT

Technical Field

The invention belongs to the technical field of route searching, and particularly relates to an IPv6 route searching method combining a hash table and an HOT.

Background

In recent years, the rapid development of the internet is seriously hindered by increasingly exhausted IPv4 address resources, and at present, IPv4 addresses are completely allocated, so that the problem of address shortage is very serious. Because the defects of the IPv4 protocol become bottlenecks which limit the development of next generation networks, the IPv6 designed by IETF to replace the IPv4 protocol is gradually popularized and is rapidly deployed, and as of 2021, the number of IPv6 active users in China is increased from 2.7 hundred million to 6.08 hundred million in the end of 2019, and accounts for 60.11% of all netizens in China. The next generation internet based on IPv6 effectively alleviates and solves the problem of IPv4 address exhaustion, but at present, because the IPv6 network is still in a development stage, it also faces many difficulties and challenges in terms of performance. Compared with the IPv4, the IPv6 increases the address length from 32 bits to 128 bits, which results in that the original IPv4 route searching algorithm is not completely compatible with the IPv6, and meanwhile, the current mainstream IPv6 route searching algorithm also has the problems of difficulty in dynamic update, too high time complexity, severe hash collision and the like, which results in low route searching efficiency and poor user experience. Therefore, how to design a high-performance IPv6 routing lookup algorithm has become a problem that needs to be solved urgently.

With the rapid development of the internet, the global business deployment of IPv6 enters a new development stage, the industry has new knowledge about the importance of IPv6, and has made a lot of research on the aspect of efficient routing forwarding of IPv 6. At present, the routing lookup structure based on the IPv6 prefix address is mainly divided into two types: one is a Trie-based route lookup structure, and the other is a hash table-based route lookup structure.

The route searching structure based on Trie is, for example, BinT (binary Trie), RadT (Radix Trie), ART (adaptive Radix Trie), etc. BinT is a binary tree, each node only stores one bit of binary bits, and the address length of IPv6 is 128 bits, so that 128 memory accesses are needed in the worst case when performing route lookup. In order to reduce the BinT search depth, researchers put forward RadT, the RadT adopts a core idea of increasing step width, the tree hierarchy is compressed to reduce the height of the RadT, in the searching process, the memory access times can be reduced, the searching efficiency is improved, but for the RadT, the space utilization rate is not high, and a large amount of free space cannot be recycled. ART is optimization based on RadT, can predefine multiple node types, and the node can dynamically select the node type according to the size of the node, so as to prevent redundant space waste. Although the route searching structure based on the Trie has better query efficiency, the problems of tree height imbalance and the like still exist, so that the stability of route query time is difficult to guarantee by the algorithm.

The routing lookup structure based on the hash table is the most common routing lookup method, and in general, an algorithm maintains one hash table for each address prefix length, and in routing lookup, the longest address prefix is sequentially matched until matching is successful, and in an ideal case, the hash table has the complexity of search time of O (1), but with the increase of routing table entries, the problem of hash collision becomes more serious, and even when necessary, hash table transplantation is required, so that query performance is seriously affected.

Disclosure of Invention

Aiming at the problems, the invention introduces the multi-data structure fusion technology into the IPv6 routing field, provides a routing search algorithm HHR combining a hash table and HOT, and is used for solving the problems of low IPv6 routing search efficiency, hash collision and the like.

The technical scheme of the invention is as follows:

an IPv6 route searching method combining a hash table and HOT is characterized by comprising the following steps:

building data structures

S1, establishing a hash table:

defining the first 64 bits of an IPv6 address as a prefix address, and dividing the prefix address into [1, 16], [17,32], [33,48], [49,64] four sections, and respectively taking the first 16 bits, 17 bits, 33 bits, 49 bits of the address to establish 4 hash tables which are respectively defined as HTable1, HTable2, HTable3 and HTable4, then the HTable1 stores a routing table entry with the prefix address length of 16 bits, the HTable2 stores the address with the prefix address length of [17,32] section, the HTable3 stores the address with the prefix address length of [33,48] section, and the HTable4 stores the address with the prefix address length of [49,64] section, wherein the structure of the HTable1 stores a prefix value and a next hop routing address, and the structures of the HTable2, the HTable3 and the HTable4 store a prefix value, a conflict pointer, a hash pointer and a next hop address pointing to the next hop routing address;

s2, establishing HOT:

based on the hash table in S1, inserting the remaining part of the prefix address into HOT, storing all feature bits Partial key after data comparison when storing data, and simultaneously storing a plurality of feature bits in one node by adopting a compound node mode;

based on the hash table in S1, corresponding HOTs are respectively established, and specific locations, for example, routing table entries with prefix address length of 64 bits, are located by the HOT pointers stored in the hash table, the first 49 bits are taken out and stored in the hash structure, and the bits in the [49,64] interval are stored in the HOTs. The HOT stores data in a compound node mode, namely, the HOT is defined as a node storing 8 value values at most, and a data structure of the HOT stores a characteristic bit position, a characteristic value (Partial key), a next node pointer and a value. Firstly, the head stores the characteristic bit positions of all value values, the characteristic bit positions are coded into a form of combining the characteristic bit positions with a single mask by means of a single mask technology, then the corresponding characteristic bits of each value are taken out to form a Partial key, the Partial key selects an 8-bit array structure and continuously stores the 8-bit array structure, parallel search of the Partial key based on the single mask technology is achieved, and the query speed is accelerated. And if the matching is successful and a next node pointer exists, the next node is required to carry out deeper matching until the longest address prefix is matched, and otherwise, forwarding is carried out according to the latest value.

Route lookup

A. Taking the first 49 bits of the address of the received IPv6 data packet, performing hash calculation, comparing the hash calculation with the HTable4, recording a corresponding value if the matching is successful, and performing HOT search, otherwise performing step E;

B. according to the position of the characteristic bit of the HOT node, sequentially extracting the corresponding characteristic bits between [49 and 64], comparing the characteristic bits with the characteristic value Partial key in parallel, if the matching of the characteristic bits is successful, extracting the value corresponding to the Partial key, otherwise, carrying out routing forwarding according to the latest value;

C. comparing the value with the bit value corresponding to [49,64] in sequence, if the value is the same as the bit value, updating the value at the moment, and otherwise, carrying out route forwarding according to the latest value;

D. judging whether the Partial key has a pointer pointing to the next node or not, if so, searching whether the next node has a longer matching item or not, otherwise, carrying out route forwarding according to the value recorded before;

E. taking the first 33 bits of the address to perform Hash calculation and comparing the Hash calculation with HTable3, if the matching is successful, recording a corresponding value, and entering HOT search, otherwise, entering step F, wherein the HOT search method is the same as the step BCD;

F. taking the first 17 bits of the address to perform Hash calculation and comparing the Hash calculation with HTable2, if the matching is successful, recording a corresponding value, and entering HOT search, otherwise, entering a step G, wherein the HOT search method is the same as the step BCD;

G. and taking the first 16 bits of the address to carry out hash calculation and comparing the hash calculation with the HTable1, if the matching is successful, forwarding according to the next hop of routing information, otherwise, forwarding according to the default route.

The invention has the beneficial effects that: when the method is applied to the IPv6, the problem of high difficulty in transplanting the hash table is solved, and the low-cost and high-speed performance of the IPv6 route searching algorithm is realized.

Drawings

Fig. 1 is a schematic diagram of the structure of the global unicast address of IPv 6.

Fig. 2 is a schematic diagram illustrating distribution characteristics of prefix lengths of routing table entries of a core router.

FIG. 3 is a schematic diagram of the structure of HTable 2/3/4.

Fig. 4 is a schematic diagram of the characteristic bits indicating all data.

Fig. 5 is a schematic diagram of a composite node structure.

Fig. 6 is a schematic diagram of HOT encoding format.

Fig. 7 is a schematic diagram of HOT overflow insertion process.

Fig. 8 is an algorithm flow chart.

FIG. 9 is a diagram illustrating query performance versus results.

Fig. 10 is a diagram illustrating comparison results of memory space occupation.

Detailed Description

The technical scheme of the invention is described in detail below with reference to the accompanying drawings, and the technical scheme of the invention is proved to be practical by combining a simulation example.

According to the specification of RFC3587, the IPv6 global unicast address standard format is shown in FIG. 1, and the address mainly comprises 4 parts: 3-bit address type flag, 45-bit global routing prefix, 16-bit subnet ID, 64-bit interface ID. 001 identifies the address as a unicast address, the global routing prefix identifies a site, the subnet ID identifies a subnet within the site, and the interface ID identifies a host within the subnet. According to the analysis of the prefix address length of the backbone routing table, in the 128-bit IPv6 address, the interface ID is not used for routing between subnets, so the prefix address length in the routing table is the first 64 bits.

Based on the routing table data of the core router provided by the podaro website, 40 million routing table entries in total are selected from autonomous domains AS131072, AS13172, and AS6447, and the prefix address length distribution rule is sorted and analyzed, with the result shown in fig. 2. As can be seen from the figure, the prefix address length is mainly between 16-64 bits, no table entry with the prefix length smaller than 16 bits exists, and the address distribution is extremely uneven, wherein the ratio of table entries with prefix length/48 is about 45%, the ratio of table entries with prefix length/32 is about 15%, and the distribution quantity of the remaining prefix address lengths is small.

In order to further research the distribution characteristics of address prefix values of the routing table of the core router, statistical analysis is performed on the address prefix values contained in the three autonomous domains again on the basis of the analysis conclusion, and it is found that prefix values mostly begin with 2001, 2600 and 2a02, and the beginning of other values is less. According to the IPv6 address assignment policy, common addresses begin with 2001 mostly.

As a result of the above studies, the IPv6 hierarchical address allocation results in a large difference in IPv6 prefix address length distribution, wherein the number of addresses with prefix lengths of 48 and/32 accounts for 60% of all routing table entries in total, and the prefix values also start with fixed numbers 2001, 2600 and 2a02 in many cases. Based on the uniqueness of IPv6 prefix address distribution, the invention introduces a multi-data fusion structure and adopts a two-stage query method. The first stage is hash table establishment, the prefix address length is divided into four sections of 16, [17,32], [33,48], [49,64], and the first 16 bits, 17 bits, 33 bits, and 49 bits of the address are respectively taken to establish a hash table as the second stage index. The second phase is HOT establishment, the rest part of the prefix address is inserted into the HOT, the HOT is a self-adaptive highly optimized Trie tree, and the HOT has the advantages of rapid insertion, deletion and parallel processing capability and can better adapt to the characteristic of frequent route prefix updating.

According to the analysis conclusion, most of the IPv6 prefix addresses are 48 bits, 32 bits and the like, and if a hash table is directly established by 48 bits or 32 bits, a hash function with good performance needs to be selected, which can better adapt to frequent operations such as insertion and deletion of routing table entries. To prevent the above problem, as shown in table1 below, the direct hash on the concentrated area (/48,/32) is avoided, but the prefix address is divided into two segments, the front segment is used for hash index establishment, and the back segment is stored in HOT.

Table1 two-stage values for IPv6 prefix addresses

Algorithm HHR defines 4 hash tables HTable1, HTable2, HTable3, and HTable 4.

The HTable1 stores a routing table entry with a Prefix address length of 16 bits, because the HTable1 does not have an index to the second stage, the structure body only needs to store a Prefix value and a next-hop routing address, and simultaneously, considering that the information stored by the HTable1 is less and the probability of hash collision is lower, when the collision occurs, a linear detection method is adopted to solve the collision, namely, the collision is detected from the position where the hash collision occurs and then is detected backwards in sequence until the next empty position is found.

HTable2 stores the address whose prefix address length is in the interval [17,32], HTable3 stores the address whose prefix address length is in the interval [33,48], HTable4 stores the address whose prefix address length is in the interval [49,64], and the structure is defined as shown in FIG. 3. The Prefix stores the Hash length value corresponding to the table1, for example, the address in the [17,32] interval, and only the first 17 bits are taken for hashing; next is a Hash conflict pointer, according to the IPv6 prefix address analysis result, the probability of conflict occurrence of HTable2 and HTable3 is high, and in order to reduce the number of times of conflict, the algorithm HHR adopts a chain address method to process Hash conflict, namely conflict objects at the same position are organized together by adopting a chain table, and the Next points to the Next conflict object; NP is an address pointer pointing to HOT, when HOT is positioned through Hash index, the second stage is needed to be entered, and whether longer address matching items exist is checked; the value is the next hop routing address, and if no longer address matching entry exists in the HOT, the value of the hash index is the longest routing matching entry of the current address.

As can be seen from table1, for an IPv6 prefix address, the prefix address is divided into two segments, the front segment is used for hash calculation, HOT is located, and the back segment stores the remaining bits and the next hop routing address. According to the distribution characteristics of the IPv6 prefix address length, the IPv6 addresses with prefix lengths of/48 and/32 are large in number and frequent in updating, so that the data structure for storing the second stage needs to meet the requirements of efficient query performance and guarantee stable operations of insertion, deletion and the like. The HOT is a self-adaptive highly optimized Trie tree, is optimized based on a multi-bit Trie, and has the rapid deletion and addition capability and the parallel processing characteristic, so the HOT is adopted as a storage structure of the second stage.

Based on IPv6 prefix address distribution rule conclusion analysis, the HOT storage bit length is mostly 16, and if storage is carried out according to a single bit, 16 times of memory access are needed for completing one search operation. In order to more effectively reduce the number of memory accesses, when data storage is performed, the algorithm HHR abandons storage of all bits, but stores all characteristic bits after data comparison to avoid invalid bit storage, as shown in fig. 4 below, different bits ( bits 0, 1, 2, 4) of all data are found and stored in the node. The advantage of doing so is that not only can reduce the space occupation, also can effectively reduce tree height.

For better utilization of the storage space, the algorithm HHR also changes a single node to a compound node, i.e. a node stores a plurality of characteristic bits. The logical structure of the node is shown in fig. 5, and a compound node can be regarded as a binary bit tree with 0 on the left and 1 on the right. The inner nodes store characteristic bits ( bits 0, 1, 2, 4), the leaf nodes store the complete prefix values, and the left and right branches are determined by the characteristic values on the characteristic bits. As can be seen from the figure, the tree height is reduced from the original 4 layers to the current 2 layers, and the searching performance is greatly improved.

As can be seen from fig. 5, the logic structure of the compound node is not complex, but in order to further increase the query speed, in implementation, the algorithm HHR optimizes the query performance by using SIMD (Single Instruction/Multiple Data) Instruction technology of modern CPU, and its main idea is to linearize the HOT into a compact Data that can be searched in parallel by using SIMD. In order to make the node storage suitable for SIMD parallel processing operation, the feature bit Partial key needs to be aligned, and in a physical level, the Partial key provides three storage modes: 8-bit, 16-bit and 32-bit arrays. As is known from the foregoing, the HOT stores addresses with a length ranging from 0 to 16 bits, so in order to reduce the node expansion frequency, the algorithm HHR limits the number of characteristic bits of the compound node to 8 bits, and selects an 8-bit array.

The node encoding format is shown in fig. 6. The coding mainly realizes parallel processing by means of the position of the characteristic bit (8-bit offset) and the single mask technology (64-bit mask). The feature bits of each key are firstly combined into Partial keys, then the Partial keys are continuously stored, and finally all the keys are searched in parallel by utilizing SIMD. Different from the traditional hierarchical query method, the SIMD parallel processing capability is applied, and the corresponding Tries do not need to be traversed in sequence, so that the query time is greatly saved, and the query efficiency is obviously improved.

HOT is a self-adaptive highly optimized Trie tree, when the amount of inserted data exceeds the threshold 8 of a compound node, node adjustment is carried out, as shown in fig. 7, in order to prevent the tree height from increasing caused by node splitting, an algorithm HHR adopts an upward growth principle, and only when all father nodes are full, a new node is created, so that the method not only can reduce the waste of free space, but also can prevent the endless growth of the Trie. As can be seen from fig. 5, the Partial key corresponding to each key only stores the feature bit related to itself, and other unrelated feature bits are undefined (denoted by x in the drawing), so that the insertion operation only needs to modify the value of the corresponding feature bit, which simplifies the node adjustment of HOT and facilitates the operations such as insertion and deletion.

The algorithm flow is shown in fig. 8. The lookup process is divided into two stages, namely a hash table lookup stage and an HOT lookup stage.

1) When an IPv6 data packet arrives, the first 49 bits of the address are taken for hash calculation and are compared with HTable4, if the matching is successful, the corresponding value is recorded and HOT searching is carried out, otherwise, the step 5 is carried out;

2) according to the position (Bit positions) of the feature bits of the HOT node, sequentially taking out the corresponding feature bits between [49 and 64], parallelly comparing the feature bits with the feature value Partial key, if the matching of the feature bits is successful, taking out the value corresponding to the Partial key, otherwise, carrying out routing forwarding according to the latest value;

3) comparing the value with the bit value corresponding to [49,64] in sequence, if the value is the same, updating the value at the moment, and otherwise, performing route forwarding according to the latest value;

4) and judging whether the Partial key has a pointer pointing to the next node or not, if so, searching whether the next node has a longer matching item or not (the process is similar to the steps 2 and 3), otherwise, carrying out route forwarding according to the previously recorded value.

5) Taking the first 33 bits of the address to carry out Hash calculation and comparing with HTable3, wherein the searching method is similar to the steps 2, 3 and 4;

6) taking the first 17 bits of the address to carry out Hash calculation and comparing with HTable2, wherein the searching method is similar to the steps 2, 3 and 4;

7) and taking the first 16 bits of the address to carry out hash calculation and comparing the hash calculation with the HTable1, if the matching is successful, forwarding according to the next hop of routing information, otherwise, forwarding according to the default route.

And analyzing the performance of the algorithm from the aspects of hash collision, query updating performance, storage space and the like.

4 hash tables are designed by the algorithm HHR, wherein HTbal 1 adopts a linear detection method to process conflicts, and the rest HTable adopts a chain address method to process conflicts. As can be seen from fig. 2, the prefix address length which is easy to conflict is/48 and/32, and the algorithm HHR avoids the hash value of the prefix length of the central area being/48 and/32, but performs hash calculation by respectively adopting the first 33 bits and 17 bits of the prefix length of the address, thereby greatly reducing the probability of hash conflict. Through the statistic analysis of the number of conflicts of more than 40 ten thousand routing table entries in total of the AS131072, the AS13172 and the AS6447, the result shows that the probability of the conflict is 0.04% when the number of conflicts is more than 40.

The route searching is divided into two stages, namely a hash table searching stage and an HOT searching stage, wherein the complexity of the hash table searching time is close to O (1), the HOT tree is approximately balanced in height, the SIMD command parallel processing capability is fully utilized, and the searching time is limited to a microsecond level. The complexity of the insertion time of the hash table is close to O (1), and the HOT adopts the idea of storing characteristic value positions Bit positions and characteristic values Partial keys, when the insertion operation is subjected to node splitting, only the Bit positions and the Partial keys of corresponding nodes need to be modified, the Partial keys of all the nodes do not need to be modified, the modification data volume is reduced, and the updating time is shortened.

The storage structure of algorithm HHR comprises a hash table and HOT.

The algorithm HHR designs 4 hash tables, wherein the HTable2, the HTable3 and the HTable4 comprise two pointers Next and NP besides the Prefix and value values, and each routing table entry occupies about 200 bits on average.

The HOT stores offset, single mask, Partial key, Next node pointer Next, and value values. The offset occupies 8 bits, the single mask occupies 64 bits, one routing table entry Partial key occupies 8 bits, the Next node pointer Next occupies 16 bits, and the value occupies 64 bits, and as is known in the foregoing, one node includes 8 values at most, so that one node occupies 800 bits at most.

Simulation example

In the simulation experiment, more than 40 million routing table entries in total are selected from autonomous domains AS131072, AS13172 and AS6447, and code testing is carried out on VScode by using C + +. Table2 shows the prefix length distribution.

Table2 prefix distribution of three autonomous domains

In the test query performance section, algorithm HHR is compared to algorithms Trie, ART, and HOT, respectively. Fig. 9 is a query time for searching 1 ten thousand pieces of data based on 40 ten thousand stored routing table entries. As can be seen from fig. 9, the algorithm HHR adopts a data structure combining the hash table and the HOT, and the query time is slightly better than that of the HOT and far better than those of the algorithms Trie and ART, so that the query performance of the algorithm HHR is better than that of other routing algorithms.

In the test memory space occupation part, the algorithm HHR is compared with the algorithms Trie, ART and HOT respectively. Fig. 10 is a result of searching for 1 ten thousand pieces of data based on 40 ten thousand pieces of routing table entries, where the space consumption ratio is increased due to the algorithm Trie and ART allocating a large amount of space in advance, and the space ratio is optimized because HOT is known with the least space usage. The algorithm HHR is introduced with a hash table structure to accelerate the query speed, so that the final space occupation is slightly more than that of HOT, but is also close to the HOT. Therefore, the algorithm HHR possesses a near-optimal space consumption performance.

From the experimental simulation result, the algorithm HHR is close to the optimal balance in the aspects of hash collision avoidance, search performance, storage space occupation and the like, and various performance indexes are good.

With the large-scale deployment of the IPv6 network, enterprises and related industries actively organize the key technology research of the IPv6 gateway. However, at present, the route searching method is still in a development stage, and in order to improve the route searching efficiency, the invention provides a route searching algorithm combining a hash table and HOT on the basis of analyzing the distribution rule of prefix addresses of a backbone route table. The algorithm has better performance in the aspects of query time, space occupation and the like.

Claims (1)

1. An IPv6 route searching method combining a hash table and HOT is characterized by comprising the following steps:

building data structures

S1, establishing a hash table:

defining the first 64 bits of IPv6 address as prefix address, and dividing into [1, 16], [17,32], [33,48], [49,64] four sections, and taking the first 16 bits, 17 bits, 33 bits, 49 bits of address to build 4 hash tables, respectively defined as HTable1, HTable2, HTable3, and HTable4, then HTable1 stores routing table entry with prefix address length of 16 bits, HTable2 stores address with prefix address length of [17,32] section, HTable3 stores address with prefix address length of [33,48] section, HTable4 stores address with prefix address length of [49,64] section, wherein, structure of HTable1 stores prefix value and next hop routing address, and structure of HTable2, HTable3, HTable4 stores prefix value, hash pointer, HOT address, and next hop routing address pointing to one hop address;

s2, establishing HOT:

respectively establishing corresponding HOTs (HOT addresses) based on a hash table in S1, specifically, storing the rest parts of prefix addresses except for the prefix addresses stored in the hash table into the HOTs, wherein the HOTs comprise characteristic bit positions of value values, characteristic values (Partial keys), next node pointers and the value values, the Partial keys are formed by corresponding characteristic bits of all the value values, the HOTs store data in a compound node mode, namely, the Partial keys are defined as a node which stores 8 value values at most, and the Partial keys select 8-bit array structures and store the 8 value array structures continuously;

route lookup

A. Taking the first 49 bits of the address of the received IPv6 data packet, performing hash calculation, comparing the hash calculation with the HTable4, recording a corresponding value if the matching is successful, and performing HOT search, otherwise performing step E;

B. according to the position of the characteristic bit of the HOT node, sequentially extracting the corresponding characteristic bits between [49 and 64], comparing the characteristic bits with the characteristic value Partial key in parallel, if the matching of the characteristic bits is successful, extracting the value corresponding to the Partial key, otherwise, carrying out routing forwarding according to the latest value;

C. comparing the value with the bit value corresponding to [49,64] in sequence, if the value is the same as the bit value, updating the value at the moment, and otherwise, carrying out route forwarding according to the latest value;

D. judging whether the Partial key has a pointer pointing to the next node or not, if so, searching whether the next node has a longer matching item or not, otherwise, carrying out route forwarding according to the value recorded before;

E. taking the first 33 bits of the address to perform Hash calculation and comparing the Hash calculation with HTable3, if the matching is successful, recording a corresponding value, and entering HOT search, otherwise, entering step F, wherein the HOT search method is the same as the step BCD;

F. taking the first 17 bits of the address to perform Hash calculation and comparing the Hash calculation with HTable2, if the matching is successful, recording a corresponding value, and entering HOT search, otherwise, entering a step G, wherein the HOT search method is the same as the step BCD;

G. and taking the first 16 bits of the address to carry out hash calculation and comparing the hash calculation with the HTable1, if the matching is successful, forwarding according to the next hop of routing information, otherwise, forwarding according to the default route.

Images