Hardware routing lookup method based on segmented uniform storage

Abstract

The application relates to a hardware routing lookup table method based on segmented unified storage, which comprises the following steps: first, acquiring an IPv4 / IPv6 routing prefix, dividing the IPv4 / IPv6 routing prefix into 1-4 address segments according to 32 bits, allocating unique forward and backward segment identifiers to each segment, constructing a table item containing a segment identifier, 32-bit segment data and a next hop, and uniformly storing the table item into a same TCAM. When performing lookup, the address to be looked up is segmented according to the same rule, the TCAM is queried with the segment data as the key from the first segment, the backward segment identifier and the next hop are recorded after a hit, if the backward segment identifier is invalid, the corresponding next hop is directly returned, if the backward segment identifier is valid, the identifier and the next segment data are taken as a joint key to continue the query. When a miss or identifier verification fails, a table item with the longest prefix and the valid next hop in the matched segment is selected and the next hop is returned. The application can uniformly store IPv4 / IPv6 routing table items, improve the TCAM space utilization rate, and guarantee the hardware lookup efficiency.

Description

Technical Field

[0001] This application relates to the field of computer network and hardware acceleration technology, and in particular to a hardware routing lookup method based on segmented unified storage. Background Technology

[0002] With the gradual deployment of IPv6, modern network devices generally need to support both IPv4 and IPv6 protocol stacks (i.e., dual-stack environments). In hardware implementation, routing tables typically use TCAM for high-speed Longest Prefix Match (LPM) lookups. The traditional approach, to accommodate the 128-bit address length of IPv6, uniformly sets all routing table entries to 128 bits wide. However, this design suffers from significant storage efficiency issues. First, IPv4 addresses are only 32 bits, but they still occupy the full 128 bits in a 128-bit TCAM entry, resulting in up to 75% wasted space. Many IPv6 prefixes are ≤64 bits long, and their effective information is far less than 128 bits, similarly leading to low storage space utilization and redundancy in IPv6 entries. Furthermore, TCAM is costly, power-hungry, and has limited capacity. In resource-sensitive scenarios such as data centers and edge routers, inefficient storage directly limits the size and performance of routing tables.

[0003] Existing technologies attempt to optimize through compression, hashing, or hybrid storage structures, but these often sacrifice query speed, increase control logic complexity, or make it difficult to efficiently implement longest prefix matching in hardware. Therefore, there is an urgent need for a new method that can uniformly store IPv4 / IPv6 routing table entries, significantly improve TCAM space utilization, and maintain the efficiency of hardware table lookups. Summary of the Invention

[0004] Therefore, it is necessary to provide a hardware routing lookup method based on segmented unified storage that can uniformly store IPv4 / IPv6 routing table entries, significantly improve TCAM space utilization, and maintain the high efficiency of hardware table lookup, in order to address the above-mentioned technical problems.

[0005] A hardware routing lookup method based on segmented unified storage, the method comprising:

[0006] Step 1: Obtain the IPv4 or IPv6 route prefix to be stored, and divide the IPv4 or IPv6 route prefix into 1 to 4 address segments in 32-bit units;

[0007] Step 2: Dynamically assign globally unique forward segment identifiers and backward segment identifiers to each address segment;

[0008] Step 3: Construct a corresponding table entry for each address segment. Each table entry contains the allocated forward segment identifier, 32-bit address segment data, backward segment identifier, and next-hop field.

[0009] Step 4: Store all entries corresponding to the constructed address ranges in the same TCAM storage area with a uniform width;

[0010] Step 5: Obtain the IPv4 address and IPv6 address to be queried, divide the IPv4 address or IPv6 address into 1 to 4 address segments to be queried in fixed units of 32 bits, and obtain the address segment data corresponding to each address segment to be queried;

[0011] Step 6: Starting from the first address segment to be queried, perform the longest prefix match query in the TCAM storage area according to the segment order and the address segment data corresponding to the current address segment to be queried as the key. If the query is successful, record the backward segment identifier and the next-hop field information in the current matching table entry.

[0012] Step 7: Determine if the backward segment identifier in the current matching table entry of the record is valid. If invalid, terminate the subsequent segment query and return the next-hop field information of the record as the table query result; if valid, use the current backward segment identifier and the address segment data corresponding to the next address segment to be queried as the composite key, return to step 6 to continue the longest prefix matching query.

[0013] Step 8: If a segment of the address to be queried in Step 6 fails to be found or the backward segment identifier verification in Step 7 fails, then the subsequent segment query is terminated. Select the table entry with the longest prefix length and a valid next-hop field from the table entries corresponding to the matched segments, and return its next-hop field information as the final table query result.

[0014] The aforementioned hardware routing lookup method based on segmented unified storage achieves compatibility between dual-stack entries by using a fixed 32-bit segmentation rule. For IPv4 routing prefixes, the high-order bits are first padded with zeros to extend to 128 bits, and then divided into 32-bit address segments. For IPv6 routing prefixes, the length is flexibly divided into 1-4 address segments. Entries for both protocols are converted into a unified 32-bit basic unit. All address segment entries are then stored in the same TCAM storage area with a uniform width, eliminating the need for separate storage areas for IPv4 and IPv6, thus naturally achieving unified management of dual-stack entries. Furthermore, by dividing the address segments into 32-bit segments according to the actual length of the routing prefix, and storing only the last address segment with a valid next-hop while setting the next-hops of the remaining segments to invalid, redundant data occupation is further reduced, significantly improving TCAM storage density. When looking up a table, it starts from the first address segment to be queried. Each segment query is a longest prefix matching operation natively supported by TCAM, without complex algorithm overhead. The continuity between segments is only verified by the backward segment identifier. If it is valid, the query continues with the SID plus the next segment data as the joint key. If it is invalid, it terminates. The whole process only adds a small amount of SID comparison logic, avoiding the query latency or logical complexity caused by compression and hashing in traditional optimization schemes, and ensuring hardware table lookup performance and LPM semantic correctness. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating a hardware routing table lookup method based on segmented unified storage in one embodiment.

[0016] Figure 2 This is a schematic representation of IPv4 / IPv6 dual-stack routing in one embodiment;

[0017] Figure 3 This is a schematic diagram of a TCAM table entry where the IPv4 / IPv6 dual-stack routing table is directly and uniformly stored in one embodiment.

[0018] Figure 4 This is a schematic diagram of a TCAM entry in an IPv4 / IPv6 dual-stack routing table based on segmented unified storage, as shown in another embodiment.

[0019] Figure 5 This is an example diagram illustrating the table lookup process of an IPv4 / IPv6 dual-stack routing table based on segmented unified storage in one embodiment. Detailed Implementation

[0020] 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.

[0021] In one embodiment, such as Figure 1As shown in the figure, a hardware routing table lookup method based on segmented unified storage is provided, including the following steps:

[0022] Step 1: Obtain the IPv4 or IPv6 routing prefix to be stored, and divide the IPv4 or IPv6 routing prefix into 1 to 4 address segments in units of 32 bits.

[0023] An address segment is the basic unit of storage and query obtained by splitting the routing prefix in a fixed length of 32 bits. Its core function is to uniformly convert IPv4 / IPv6 routing prefixes of different lengths into standardized storage units, solving the storage redundancy problem of traditional solutions. If the routing prefix to be stored is an IPv4 routing prefix, it needs to be padded with zeros at the high position to be extended to 128 bits first, and then segmented in units of 32 bits; if it is an IPv6 routing prefix, it is directly segmented in units of 32 bits. The specific segmentation rule is: when the length L of the IPv6 routing prefix satisfies 0 ≤ L ≤ 32, it is divided into 1 address segment; when 32 < L ≤ 64, it is divided into 2 address segments; when 64 < L ≤ 96, it is divided into 3 address segments; when 96 < L ≤ 128, it is divided into 4 address segments. Among them, except for the last address segment after segmentation, the 32-bit address segment data corresponding to the other address segments are all exact values, and the 32-bit address segment data corresponding to the last address segment is the partial valid data with a prefix length of L - 32×(n - 1), where n represents the total number of address segments divided. For example, for the IPv4 routing prefix 192.168.1.0 / 24 (L = 24 ≤ 32), after being extended to 128 bits, the high 32 bits are taken as 1 address segment; for the IPv6 routing prefix 2001:db8:1234:: / 48 (L = 48), it is divided into 2 address segments, namely the high 32-bit exact value and the partial valid data of the second high 32 bits and a prefix length of 16 bits. As Figure 2 shown in the figure, it is a diagram of an IPv4 / IPv6 dual-stack routing table.

[0024] Step 2: Dynamically allocate a globally unique forward segment identifier and a backward segment identifier to each address segment.

[0025] The "Forward Segment Identifier (SID_pre)" and "Backward Segment Identifier (SID_post)" are w-bit globally unique identifiers used to establish associations between adjacent address segments. The w bits are dynamically allocated by the system when an entry is inserted, ensuring that address segments from different routing entries do not interfere with each other. The allocation rule is as follows: if the address segment is the first address segment after route prefix division, the forward segment identifier for that address segment is set to invalid; if the address segment is the last address segment after route prefix division, the backward segment identifier for that address segment is set to invalid. Dynamic allocation uses an idle SID pool management mechanism. When a new routing entry is inserted and SID allocation is required, the smallest unused SID is selected from the idle SID pool; when a routing entry is deleted and SIDs are released, the released SIDs are added back to the idle SID pool, achieving efficient reuse of SID resources.

[0026] Step 3: Construct a corresponding table entry for each address segment. Each table entry contains the allocated forward segment identifier, 32-bit address segment data, backward segment identifier, and next-hop field.

[0027] An "entry" is the storage medium for address segments in TCAM, and its structural design directly determines storage efficiency and lookup logic. The "next-hop field" stores next-hop information for routing. To ensure the correctness of the longest prefix matching semantics, only the entry corresponding to the last address segment after route prefix division stores valid next-hop information in the next-hop field; entries for other address segments have their next-hop field set to invalid. The uniform width of an entry is (2w + 32 + M) bits, where w is the number of bits for SID_pre and SID_post, 32 is the number of bits for the address segment data, and M is the number of bits for the next-hop field, satisfying M ≥ log2(P_max) (P_max represents the maximum number of ports supported by the system), ensuring that the next-hop field can accurately identify all possible forwarding ports. Figure 4 As shown, entry S1 contains SID_pre=invalid, address range data 192.168.1.0 / 24, SID_post=invalid, and next-hop=0 (valid); entry S2 contains SID_pre=invalid, address range data 2001:db8 / 32, SID_post=0, and next-hop=invalid.

[0028] Step 4: Store all entries corresponding to the constructed address ranges in the same TCAM storage area with a uniform width.

[0029] The TCAM (Tri-State Content-Addressable Memory) is the core hardware for implementing high-speed longest prefix match (LPM). Its key feature is its support for parallel lookups, enabling a match query to be completed within a single clock cycle. "Uniform width storage" refers to the use of the same bit width for entries corresponding to all address segments, eliminating the need for separate TCAM storage areas for IPv4 and IPv6. This achieves a unified storage architecture for dual-stack routing table entries, simplifying hardware design. The TCAM storage capacity is designed to satisfy the formula C_TCAM ≥ N_max × 4 × (2w + 32 + M) / 8 (where C_TCAM represents the TCAM storage capacity in bytes; N_max represents the maximum number of routing table entries supported by the system; and 4 represents the maximum number of address segments a single routing table entry can be divided into), ensuring that it can accommodate entries corresponding to all address segments. (Comparison) Figure 3 (Traditional 128-bit fixed-width storage) and Figure 4 (This application uses segmented unified storage), which clearly shows that this method significantly reduces the storage space occupied by TCAM.

[0030] Step 5: Obtain the IPv4 address and IPv6 address to be queried, divide the IPv4 address or IPv6 address into 1 to 4 address segments to be queried in fixed units of 32 bits, and obtain the address segment data corresponding to each address segment to be queried.

[0031] The address range to be queried is the preprocessed result of the IP address to be queried adapted to the storage architecture. Its segmentation logic is consistent with the segmentation logic of the routing prefix to ensure the correspondence during the query. If the address to be queried is an IPv4 address, it needs to be padded with zeros to extend it to 128 bits, and then divided into one address range in 32-bit units. If it is an IPv6 address, regardless of the length of its corresponding routing prefix, it is divided into 4 address ranges in 32-bit units. The address range data corresponding to the first k address ranges to be queried are exact values ​​(k represents the total number of address ranges after the routing prefix corresponding to the IPv6 address to be queried is divided). The address range data corresponding to the remaining address ranges to be queried do not need to participate in the effective matching during the query process. For example, the IPv6 address to be queried is 2001:db8:1234:abcd:1234:5678:1234:abcd. Divided into 32-bit segments, these segments are: Vseg1=0x2001db8, Vseg2=0x1234abcd, Vseg3=0x12345678, and Vseg4=0x1234abcd. Figure 5 As shown.

[0032] Step 6: Starting from the first address segment to be queried, perform the longest prefix match query in the TCAM storage area according to the segment order and the address segment data corresponding to the current address segment to be queried as the key. If the query is successful, record the backward segment identifier and next-hop field information in the current matching table entry.

[0033] "Longest Prefix Match (LPM)" is the core semantic of route lookup, referring to selecting the entry with the longest prefix length among all matching routing table entries as the basis for forwarding. The query is performed segment by segment. The first address segment to be queried uses its own address segment data as the unique query key. Subsequent address segments to be queried need to combine the backward segment identifier of the previous segment to form a composite key, ensuring the continuity between address segments. When performing a longest prefix match query in the TCAM storage area, the matching priority is P = L_seg + 32 × (i-1), where P represents the priority of the current matching prefix; L_seg represents the prefix length corresponding to the current address segment; and i represents the sequence number of the current address segment after the route prefix division, starting from 1. The entry with the highest priority is selected as the matching result to ensure the accuracy of the longest prefix match.

[0034] Step 7: Determine if the backward segment identifier in the current matching table entry of the record is valid. If invalid, terminate the subsequent segment query and return the next-hop field information of the record as the table query result; if valid, use the current backward segment identifier and the address segment data corresponding to the next address segment to be queried as the union key, and return to step 6 to continue the longest prefix matching query.

[0035] The "backsegment identifier validity check" is a crucial step in verifying the continuity of associations between address segments. "Valid" indicates that there are still subsequent associated address segments after the current address segment, requiring further querying to find a longer prefix match; "Invalid" indicates that the current address segment is the last segment of the routing prefix, the longest prefix match has been found, and the result can be returned directly. The "combined key" consists of the backsegment identifier of the previous segment and the data of the current address segment being queried. Its purpose is to avoid mismatches of address segments from different routing table entries, ensuring the accuracy of the query.

[0036] Step 8: If a segment of the address to be queried in Step 6 fails to be found or the backward segment identifier verification in Step 7 fails, then the subsequent segment query is terminated. Select the table entry with the longest prefix length and a valid next-hop field from the table entries corresponding to the matched segments, and return its next-hop field information as the final table query result.

[0037] "Query miss" means there is no matching entry for the current address segment in TCAM. "Back segment identifier verification failure" means the back segment identifier of the current matching entry does not match the identifier in the subsequent composite key. In both cases, subsequent queries must be terminated to avoid invalid operations. When selecting the final result, the effective prefix length is calculated using L_total = 32 × (m - 1) + L_last. L_total represents the total prefix length corresponding to the current matching entry; m represents the number of matched address segments; and L_last represents the prefix length corresponding to the last matched address segment. The entry with the longest total prefix length and a valid next-hop is selected to ensure compliance with the longest prefix matching semantics.

[0038] The aforementioned hardware routing lookup method based on segmented unified storage achieves compatibility between dual-stack entries by using a fixed 32-bit segmentation rule. For IPv4 routing prefixes, the high-order bits are first padded with zeros to extend to 128 bits, and then divided into 32-bit address segments. For IPv6 routing prefixes, the length is flexibly divided into 1-4 address segments. Entries for both protocols are converted into a unified 32-bit basic unit. All address segment entries are then stored in the same TCAM storage area with a uniform width, eliminating the need for separate storage areas for IPv4 and IPv6, thus naturally achieving unified management of dual-stack entries. Furthermore, by dividing the address segments into 32-bit segments according to the actual length of the routing prefix, and storing only the last address segment with a valid next-hop while setting the next-hops of the remaining segments to invalid, redundant data occupation is further reduced, significantly improving TCAM storage density. When looking up a table, it starts from the first address segment to be queried. Each segment query is a longest prefix matching operation natively supported by TCAM, without complex algorithm overhead. The continuity between segments is only verified by the backward segment identifier. If it is valid, the query continues with the SID plus the next segment data as the joint key. If it is invalid, it terminates. The whole process only adds a small amount of SID comparison logic, avoiding the query latency or logical complexity caused by compression and hashing in traditional optimization schemes, and ensuring hardware table lookup performance and LPM semantic correctness.

[0039] In one embodiment, if it is an IPv4 routing prefix, it is first padded with zeros to extend it to 128 bits, and then the extended 128-bit IPv4 routing prefix or the original IPv6 routing prefix is ​​divided into 1 to 4 address segments in fixed units of 32 bits.

[0040] In one embodiment, in step 3, only the next-hop field of the entry corresponding to the last address segment after the routing prefix division stores valid next-hop information, while the next-hop field of the entries corresponding to the other address segments is set to invalid.

[0041] In one embodiment, the forward segment identifier and the backward segment identifier are w-bit globally unique identifiers, which are dynamically allocated by the system when an entry is inserted.

[0042] In one embodiment, if the address segment is the first address segment after the routing prefix is ​​divided, the forward segment identifier of the address segment is set to invalid; if the address segment is the last address segment after the routing prefix is ​​divided, the backward segment identifier of the address segment is set to invalid.

[0043] In one embodiment, the segmentation rule for dividing an IPv4 or IPv6 routing prefix into 1 to 4 address segments in units of 32 bits is as follows: When the length L of the IPv6 routing prefix satisfies 0 ≤ L ≤ 32, it is divided into 1 address segment; when 32 < L ≤ 64, it is divided into 2 address segments; when 64 < L ≤ 96, it is divided into 3 address segments; when 96 < L ≤ 128, it is divided into 4 address segments. Among them, except for the last address segment after segmentation, the 32-bit address segment data corresponding to the remaining address segments are all exact values, and the 32-bit address segment data corresponding to the last address segment is partial valid data with a prefix length of L - 32×(n - 1), where n represents the total number of divided address segments.

[0044] In one embodiment, the segmentation rule for the IPv6 address to be queried is: Regardless of the length of the routing prefix corresponding to the IPv6 address to be queried, it is divided into 4 address segments to be queried in a fixed unit of 32 bits. Among them, the address segment data corresponding to the first k address segments to be queried are exact values, where k represents the total number of address segments after the routing prefix corresponding to the IPv6 address to be queried is divided, and the address segment data corresponding to the remaining address segments to be queried do not need to participate in effective matching during the query process.

[0045] In one embodiment, when performing the longest prefix match query in the TCAM storage area, the matching priority is: P = L_seg + 32×(i - 1), where P represents the prefix priority of the current match, L_seg represents the prefix length corresponding to the current address segment, and i represents the sequence number of the current address segment after the routing prefix is divided.

[0046] In one embodiment, a globally unique forward segment identifier and backward segment identifier are dynamically assigned to each address segment, including:

[0047] Adopt an idle SID pool management mechanism. When a new routing table entry needs to be inserted and a SID needs to be assigned, select the smallest unused SID from the idle SID pool; when a routing table entry is deleted and the SID is released, add the released SID back to the idle SID pool.

[0048] In one embodiment, select the entry with the longest prefix length and a valid next-hop field from the entries corresponding to the matched segments, including:

[0049] When selecting the entry with the longest prefix length and a valid next-hop field, calculate the effective prefix length as L_total = 32×(m - 1) + L_last, where L_total represents the total prefix length corresponding to the current matched entry, m represents the number of matched address segments, and L_last represents the prefix length corresponding to the last matched address segment.

[0050] In a specific embodiment, the process of inserting a routing table entry is as follows:

[0051] Input a routing prefix P and its prefix length L (0 ≤ L ≤ 128);

[0052] If L ≤ 32: Store the high 32 bits of P as S1 in the TCAM, SID_pre = invalid, SID_post = invalid, next-hop = NH;

[0053] If 32 < L ≤ 64: Divide P into S1 (high 32 bits, exact value) and S2 (second - high 32 bits, prefix length L 32); Assign SID1 to S1, SID_pre of S2 = SID1, SID_post = invalid;

[0054] next-hop of S1 = invalid, next-hop of S2 = NH;

[0055] If 64 < L ≤ 96: Divide it into S1, S2 (both are 32 - bit exact values), S3 (prefix length L 64);

[0056] Assign SID1 (associated with S1 - S2), SID2 (associated with S2 - S3); For S1: SID_pre = invalid, SID_post = SID1, next-hop = invalid; For S2: SID_pre = SID1, SID_post = SID2, next-hop = invalid; For S3: SID_pre = SID2, SID_post = invalid, next-hop = NH;

[0057] If 96 < L ≤ 128: Divide it into S1, S2, S3 (all are 32 - bit exact values), S4 (prefix length L 96); Assign SID1 (associated with S1 - S2), SID2 (associated with S2 - S3), SID3 (associated with S3 - S4);

[0058] For the first three segments, next-hop = invalid, next-hop of S4 = NH.

[0059] The routing table lookup process is as follows:

[0060] Uniformly expand the IP address V to be queried to 128 bits (fill zeros at the high positions of the IPv4 address), and divide it into Vseg1~Vseg4;

[0061] Execute the LPM query in the TCAM with Vseg1 as the key to obtain the matching result:

[0062] - If a match is found and is a complete 32-bit match, record SID1 and the possible next-hop NH1;

[0063] Otherwise, SID1 = invalid;

[0064] If SID1 = invalid, the table lookup ends and NH1 is returned (if valid).

[0065] If SID1 ≠ invalid, then perform the second LPM query with "SID1 + Vseg2" as the union key to obtain SID2 and NH2;

[0066] If SID2 = invalid, then compare NH1 and NH2, and return the one that is valid and has a longer prefix;

[0067] If SID2 ≠ invalid, then use "SID2 + Vseg3" as the key to query the third segment, and so on;

[0068] Finally, the one with the longest corresponding prefix length among all valid next-hops is selected as the lookup result.

[0069] The present application will be further described in detail below with reference to specific embodiments.

[0070] Example 1: Insertion of IPv4 / 24 routing table entries

[0071] Input prefix: 192.168.1.0 / 24 (L=24 ≤ 32)

[0072] Extend 192.168.1.0 to 128 bits and take the high 32 bits: 0xC0A80100;

[0073] Since the prefix length of this prefix entry is less than or equal to 32, no segmentation is required. It can be directly inserted into the TCAM entry. All segmentation-related fields are invalid: SID_pre=invalid, segment=0xC0A80100, SID_post=invalid, next-hop=0.

[0074] It only occupies one 32-bit TCAM entry.

[0075] Example 2: Insertion of IPv6 / 48 routing table entries

[0076] Input prefix: 2001:db8:1234:: / 48 (L=48)

[0077] Since the prefix length is between 33 and 64, it needs to be divided into two segments:

[0078] The first segment, S2, is 0x2001db8 (high 32 bits, precise value).

[0079] The second segment S3 = 0x12340000 (second highest 32 bits, prefix length 16 bits);

[0080] S2 and S3 are connected by assigning SID=0.

[0081] S2 entries:

[0082] SID_pre=invalid, segment=0x2001db8, SID_post=0, next-hop=invalid;

[0083] S3 entries: SID_pre=0, segment=0x12340000 / 16, SID_post=invalid, next-hop=1;

[0084] It occupies two 32-bit TCAM entries, saving 50% of space.

[0085] Example 3: Insertion of IPv6 / 80 routing table entries

[0086] Input prefix: 2001:db8:1234:abcd:1234:: / 80 (L=80)

[0087] Since the prefix length is between 64 and 96, it needs to be divided into three segments:

[0088] The first segment S2 = 0x2001db8 (high 32 bits, precise value). This precise value already exists and can be reused as a segment entry.

[0089] The second segment S4 = 0x1234abcd (the second highest 32 bits, the exact value). This exact value does not exist between segments, so SID=1 is assigned and linked with the subsequent segment.

[0090] The third segment S5 = 0x12340000 (the third segment is 32 bits, and the prefix length is 16 bits);

[0091] S2 and S4 are connected via SID=0.

[0092] S4 and S5 are connected via SID=1.

[0093] S4 table entry: SID_pre=0, segment=0x1234abcd, SID_post=1, next-hop=invalid;

[0094] S5 entries: SID_pre=1, segment=0x12340000 / 16, SID_post=invalid, next-hop=2;

[0095] It occupies two 32-bit TCAM entries, saving 50% of space.

[0096] Example 4: IPv6 Address Lookup

[0097] Address to be searched: 2001:db8:1234:abcd:1234:5678:1234:abcd

[0098] Vseg1=0x2001db8, Vseg2=0x1234abcd, Vseg3=0x12345678,, Vseg4=0x1234abcd;

[0099] The first segment matches S2, resulting in SID1=0;

[0100] The second segment matches S4 with SID1+Vseg2, resulting in SID2=1;

[0101] The third segment matches SID2+Vseg3 with S5, resulting in SID3=invalid and next-hop=2;

[0102] Since SID3=invalid, the fourth segment match is not triggered, and next-hop=2 is returned;

[0103] Through the above mechanism, this application greatly improves the storage density and flexibility of the hardware routing table while ensuring the correctness of table lookup.

[0104] It should be understood that, although Figure 1 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 1 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0105] 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.

[0106] 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 hardware routing lookup method based on segmented unified storage, characterized in that, The method includes: Step 1: Obtain the IPv4 or IPv6 route prefix to be stored, and divide the IPv4 or IPv6 route prefix into 1 to 4 address segments in 32-bit units; Step 2: Dynamically assign globally unique forward segment identifiers and backward segment identifiers to each address segment; Step 3: Construct a corresponding table entry for each address segment. Each table entry contains the allocated forward segment identifier, 32-bit address segment data, backward segment identifier, and next-hop field. Step 4: Store all entries corresponding to the constructed address ranges in the same TCAM storage area with a uniform width; Step 5: Obtain the IPv4 address and IPv6 address to be queried, divide the IPv4 address or IPv6 address into 1 to 4 address segments to be queried in fixed units of 32 bits, and obtain the address segment data corresponding to each address segment to be queried; Step 6: Starting from the first address segment to be queried, perform the longest prefix match query in the TCAM storage area according to the segment order and the address segment data corresponding to the current address segment to be queried as the key. If the query is successful, record the backward segment identifier and the next-hop field information in the current matching table entry. Step 7: Determine if the backward segment identifier in the current matching table entry of the record is valid. If invalid, terminate the subsequent segment query and return the next-hop field information of the record as the table query result; if valid, use the current backward segment identifier and the address segment data corresponding to the next address segment to be queried as the composite key, return to step 6 to continue the longest prefix matching query. Step 8: If a segment of the address to be queried in Step 6 fails to be found or the backward segment identifier verification in Step 7 fails, then the subsequent segment query is terminated. Select the table entry with the longest prefix length and a valid next-hop field from the table entries corresponding to the matched segments, and return its next-hop field information as the final table query result.

2. The method according to claim 1, characterized in that, The method further includes: If it is an IPv4 routing prefix, first pad its high-order bits with zeros to extend it to 128 bits, and then divide the extended 128-bit IPv4 routing prefix or the original IPv6 routing prefix into 1 to 4 address segments with 32 bits as the fixed unit.

3. The method according to claim 1, characterized in that, The method further includes: In step 3, only the next-hop field of the entry corresponding to the last address segment after the route prefix division stores valid next-hop information, while the next-hop field of the entries corresponding to the other address segments is set to invalid.

4. The method according to claim 1, characterized in that, The forward segment identifier and the backward segment identifier are w-bit globally unique identifiers, which are dynamically assigned by the system when an entry is inserted.

5. The method according to claim 4, characterized in that, The method further includes: If the address segment is the first address segment after the routing prefix is ​​divided, the forward segment identifier of the address segment is set to invalid; if the address segment is the last address segment after the routing prefix is ​​divided, the backward segment identifier of the address segment is set to invalid.

6. The method according to claim 1, characterized in that, The method further includes: The segmentation rule for dividing an IPv4 or IPv6 routing prefix into 1 to 4 address segments in units of 32 bits is as follows: when the length L of the IPv6 routing prefix satisfies 0 ≤ L ≤ 32, it is divided into 1 address segment; when 32 < L ≤ 64, it is divided into 2 address segments; when 64 < L ≤ 96, it is divided into 3 address segments; when 96 < L ≤ 128, it is divided into 4 address segments. Among them, except for the last address segment after segmentation, the 32-bit address segment data corresponding to the remaining address segments are all exact values, and the 32-bit address segment data corresponding to the last address segment is the partial valid data with a prefix length of L - 32×(n - 1), where n represents the total number of address segments divided.

7. The method according to claim 1, characterized in that, The method further includes: The segmentation rule for the IPv6 address to be queried is: regardless of the length of the routing prefix corresponding to the IPv6 address to be queried, it is divided into 4 address segments to be queried in a fixed unit of 32 bits. Among them, the address segment data corresponding to the first k address segments to be queried are exact values, k represents the total number of address segments after the routing prefix corresponding to the IPv6 address to be queried is divided, and the address segment data corresponding to the remaining address segments to be queried do not need to participate in effective matching during the query process.

8. The method according to claim 1, characterized in that, The method further includes: When performing the longest prefix match query in the TCAM storage area, the match priority is: P = L_seg + 32×(i - 1), where P represents the prefix priority of the current match, L_seg represents the prefix length corresponding to the current address segment, and i represents the serial number of the current address segment after the routing prefix is divided.

9. The method according to claim 1, characterized in that, Dynamically allocate a globally unique forward segment identifier and backward segment identifier for each address segment, including: Adopt an idle SID pool management mechanism. When inserting a new routing table entry and needing to allocate a SID, select the smallest unused SID from the idle SID pool; when deleting a routing table entry and releasing the SID, re-add the released SID to the idle SID pool.

10. The method according to claim 1, characterized in that, Select the entry with the longest prefix length and a valid next-hop field from the entries corresponding to the matched segments, including: When selecting the entry with the longest prefix length and a valid next-hop field, calculate the effective prefix length as L_total = 32×(m - 1) + L_last, where L_total represents the total prefix length corresponding to the current matched entry, m represents the number of matched address segments, and L_last represents the prefix length corresponding to the last matched address segment.

Images