Method and system for compressing multi-tenant uniform storage routing table entries based on identity mapping

Abstract

The application relates to a multi-tenant uniform storage routing table item compression method and system based on identification mapping. The method comprises the following steps: in a routing table item insertion stage, a minimum available reduceID is dynamically allocated for each new tenant, and it is ensured that the IP prefix space of the tenant is not overlapped with a tenant using the same reduceID; in a lookup stage, a message VNI is converted into a reduceID through a mapping table based on RAM, and then reduceID+destination IP is used as a joint key to query a TCAM, and the mapping relationship between the VNI and the reduceID is constructed, so that the bit width of the TCAM table item is significantly reduced under the premise of ensuring routing correctness. The application is suitable for an IPv4 / IPv6 multi-tenant environment, and can effectively reduce the hardware area and power consumption in a FPGA or ASIC high-performance data plane, while maintaining the line-speed forwarding capability.

Description

Technical Field

[0001] This application relates to the fields of cloud computing network architecture and high-performance network data plane hardware acceleration technology, and in particular to a method and system for compressing multi-tenant unified storage routing table entries based on identifier mapping. Background Technology

[0002] With the rapid development of cloud computing and virtualization technologies, multi-tenant networks have become a core feature of modern data center infrastructure. To achieve network isolation between tenants, the VxLAN (Virtual eXtensible Local Area Network) protocol is widely adopted. VxLAN theoretically supports over 16 million logical networks by encapsulating a 24-bit VNI (VXLAN Network Identifier) ​​field outside the original Ethernet frame, meeting the needs of large-scale multi-tenancy. In actual deployments, network devices need to maintain an independent routing table for each tenant. To improve resource utilization and avoid storage fragmentation, the industry generally adopts a "unified storage" strategy, which centrally stores all tenant routing table entries in the same hardware table, with each entry consisting of "VNI + IP prefix + next hop". However, this solution faces significant challenges at the hardware implementation level. Firstly, for IPv4 (32-bit IP addresses), the introduction of the 24-bit VNI increases the entry width from 32 bits to 56 bits; for IPv6 (128 bits) or its commonly used 64-bit prefix form, the entry width increases significantly. High-performance data planes typically rely on TCAMs to achieve longest prefix match (LPM), and the area, power consumption, and bit width of TCAMs are strongly linearly related. Increasing the bit width of entries directly leads to chip area expansion, increased static / dynamic power consumption, and may limit TCAM capacity, thereby affecting the scale of routes that can be supported.

[0003] Existing optimization solutions mainly fall into two categories: tenant-isolated storage, which allocates independent TCAM space to each tenant. While this method avoids the VNI field, it leads to a large amount of space fragmentation, resulting in low resource utilization, especially when tenant routing scales differ significantly; route aggregation or prefix compression reduces the number of entries by merging similar prefixes, but sacrifices the flexibility of tenant-defined routes and cannot solve the fixed overhead per entry caused by VNI.

[0004] In summary, there is an urgent need for a technical solution that can both retain the advantages of multi-tenant unified storage and effectively compress the width of the VNI field. Summary of the Invention

[0005] Therefore, it is necessary to provide a method and system for compressing multi-tenant unified storage routing table entries based on identifier mapping, which can both retain the advantages of multi-tenant unified storage and effectively compress the bit width of the VNI field, in order to address the above-mentioned technical problems.

[0006] A method for compressing multi-tenant unified storage routing table entries based on identifier mapping, the method comprising:

[0007] Obtain the original VxLAN network identifier (VNI) of the tenant to be inserted and the set of IP prefixes of the tenant to be inserted;

[0008] Starting from the initial value, check sequentially whether there is prefix space overlap between the set of used tenant IP prefixes corresponding to the current candidate reduceID and the set of IP prefixes of the tenant to be inserted. The first candidate reduceID that meets the non-overlap condition is determined as the target reduceID of the tenant to be inserted.

[0009] By combining the target reduceID with the IP prefixes of each tenant to be inserted, a compressed routing table entry is constructed and stored in TCAM;

[0010] A mapping table from VNI to reduceID is built based on RAM. The original VNI of the tenant to be inserted is associated with the target reduceID and written into the mapping table to complete the mapping relationship maintenance.

[0011] Receive incoming packets encapsulated in VxLAN, parse the VNI in the outer VxLAN header and the destination IP address in the inner IP packet, and use them as input parameters for route lookup;

[0012] The parsed VNI is used as the query key to perform an exact match query in the constructed mapping table to obtain the reduceID corresponding to the VNI;

[0013] The reduceID obtained from the query is concatenated with the destination IP address obtained from the parsing to form a composite key. The composite key is then input into the TCAM that stores compressed routing table entries, and the longest prefix matching is performed to obtain the matching routing table entries.

[0014] Based on matching routing table entries, the forwarding decision for incoming packets is made.

[0015] A multi-tenant unified storage routing table entry compression system based on identifier mapping, the system comprising:

[0016] The insertion preparation module is used to obtain the original VxLAN network identifier (VNI) of the tenant to be inserted and the set of IP prefixes of the tenant to be inserted, and output them to the reduceID allocation module.

[0017] The reduceID allocation module receives the VNI and IP prefix set output by the insertion preparation module. Starting from the initial value, it sequentially checks whether there is prefix space overlap between the IP prefix set of the used tenant corresponding to the current candidate reduceID and the IP prefix set of the tenant to be inserted. The first candidate reduceID that meets the non-overlap condition is determined as the target reduceID of the tenant to be inserted and output to the table entry storage module and the mapping table establishment module.

[0018] The table entry storage module is used to receive the target reduceID output by the reduceID allocation module and the IP prefix set output by the insertion preparation module, construct compressed routing table entries, and store the compressed routing table entries in TCAM;

[0019] The mapping table creation module is used to build a mapping table from VNI to reduceID based on RAM. It receives the VNI output by the insertion preparation module and the target reduceID output by the reduceID allocation module, associates the original VNI of the tenant to be inserted with the target reduceID, writes it into the mapping table and outputs it to the lookup preparation module.

[0020] The lookup preparation module is used to receive incoming packets encapsulated in VxLAN, parse the VNI and destination IP address of the incoming packets, output the VNI to the reduceID lookup module, and output the destination IP address to the union key matching module.

[0021] The reduceID query module is used to receive the VNI output by the lookup preparation module and the mapping table output by the mapping table creation module, query the reduceID corresponding to the VNI in the mapping table, and output it to the union key matching module.

[0022] The composite key matching module receives the reduceID output by the reduceID query module and the destination IP address output by the lookup preparation module, concatenates them to form a composite key, inputs the composite key into the TCAM that stores compressed routing table entries, performs the longest prefix matching, obtains the matching routing table entries, and outputs them to the forwarding decision module.

[0023] The forwarding decision module receives the matching routing table entries output by the union key matching module and makes forwarding decisions for incoming packets based on these entries.

[0024] The aforementioned method and system for compressing multi-tenant unified storage routing table entries based on identifier mapping, through dynamic allocation of reduceIDs and strict verification of IP prefix space overlap, ensures that routing table entries sharing the same reduceID will not conflict when matching the longest prefix, thus maintaining routing isolation and correctness in the unified storage scenario and fully preserving the core advantage of unified storage in terms of resource utilization. It also introduces a dynamic identifier, reduceID. The bit width of reduceID can be dynamically adjusted according to the actual number of tenants. During the routing table entry insertion phase, by allocating the minimum available reduceID that satisfies the requirement of no IP prefix space overlap for new tenants, the 24-bit VNI field that originally needed to be stored in the TCAM entry is replaced with the smaller-bit reduceID. During the lookup phase, using a RAM-based VNI-to-reduceID mapping table, the packet VNI is first converted to a reduceID, and then the TCAM is queried using reduceID + destination IP as the composite key. This eliminates the need for TCAM entries to carry the 24-bit VNI; only the reduceID and IP prefix, with a bit width much smaller than VNI, need to be stored, thus significantly reducing the entry bit width. Meanwhile, the lookup latency of the RAM mapping table is only in the nanosecond range, which will not affect the line-speed forwarding capability of the data plane. In high-performance data planes such as FPGAs or ASICs, it can effectively reduce hardware area and power consumption, and achieve efficient compression of VNI field width. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating a method for compressing multi-tenant unified storage routing table entries based on identifier mapping in one embodiment.

[0026] Figure 2 This is a schematic diagram illustrating the VxLAN message processing flow and the interaction between the VR-map module and the TCAM module in one embodiment.

[0027] Figure 3 This is a schematic diagram of the process of inserting a routing table entry in one embodiment;

[0028] Figure 4 This is a schematic diagram of the route lookup process in another embodiment;

[0029] Figure 5 This is a schematic diagram illustrating prefix overlap determination in one embodiment;

[0030] Figure 6 This is a framework diagram of a multi-tenant unified storage routing table entry compression system based on identifier mapping in one embodiment. Detailed Implementation

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

[0032] In one embodiment, such as Figure 1 As shown, a method for compressing multi-tenant unified storage routing table entries based on identifier mapping is provided, including the following steps:

[0033] Step 1: Obtain the original VxLAN network identifier (VNI) of the tenant to be inserted and the set of IP prefixes of the tenant to be inserted.

[0034] The VxLAN Network Identifier (VNI) is a 24-bit identifier used to distinguish logical networks of different tenants; the IP prefix set is the set of IP address ranges used by the tenant, including IPv4 or IPv6 address prefixes. This step collects the core network identifier and address space information of the tenant to be inserted, providing basic data for subsequent reduceID allocation, compressed entry construction, and mapping relationship establishment. It is a prerequisite for realizing multi-tenant routing table entry compression, ensuring that all subsequent operations are carried out around the network attributes of the specific tenant.

[0035] Step 2: Starting from the initial value, check sequentially whether there is prefix space overlap between the set of used tenant IP prefixes corresponding to the current candidate reduceID and the set of IP prefixes of the tenant to be inserted. The first candidate reduceID that meets the non-overlap condition is determined as the target reduceID of the tenant to be inserted.

[0036] The initial value is set to 0, and candidate reduceIDs are tried sequentially in the order of 0, 1, 2, ... The reduceID is a compressed identifier used to replace the original 24-bit VNI; its bit width is less than 24 bits and can be dynamically configured according to the actual number of tenants. The core of this step is to ensure that there are no conflicts in the IP address spaces of different tenants sharing the same reduceID through prefix space overlap checking. This ensures tenant routing isolation and table lookup correctness while reusing the reduceID to achieve bit width compression. This "minimum available" allocation strategy can meet tenant isolation requirements with optimal bit width and maximize the compression effect.

[0037] Step 3: Combine the target reduceID with the IP prefixes of the tenants to be inserted to construct compressed routing table entries, and store the compressed routing table entries in TCAM.

[0038] TCAM (Tri-State Content Addressable Memory) is the core hardware for implementing Longest Prefix Match (LPM) in the high-performance data plane. Its area, power consumption, and table entry bit width are strongly linearly related. This step abandons the traditional "VNI + IP prefix + next hop" table entry format and adopts a compressed format of "reduceID + IP prefix" for storage. It no longer carries the 24-bit VNI field, which significantly reduces the bit width of TCAM table entries, thereby reducing the hardware area and power consumption of TCAM, increasing TCAM storage capacity, and solving the TCAM resource bottleneck problem caused by VNI in traditional unified storage solutions.

[0039] Step 4: Construct a mapping table from VNI to reduceID based on RAM, associate the original VNI of the tenant to be inserted with the target reduceID, and write it into the mapping table to complete the mapping relationship maintenance.

[0040] RAM (Random Access Memory) is characterized by its fast access speed and low cost. A mapping table (VR-map) built based on RAM is used to record the one-to-one correspondence between the original VNI and the compressed reduceID. This step establishes this mapping relationship to provide a basis for the VNI-to-reduceID conversion in the routing lookup stage. Moreover, the hardware implementation of RAM does not occupy valuable TCAM resources, ensuring the efficiency and low cost of mapping lookup.

[0041] Step 5: Receive the incoming packet encapsulated in VxLAN, parse the VNI in the outer VxLAN header and the destination IP address in the inner IP packet, and use them as input parameters for route lookup.

[0042] The incoming packet encapsulated by VxLAN includes an outer VxLAN header (containing the VNI field) and an inner IP packet (containing the destination IP address). This step parses these two core parameters to obtain the "Tenant Identifier" (VNI) and "Destination Address" (Destination IP) required for route lookup, providing the raw input for subsequent reduceID lookup and federated key construction, and is the starting point of the route lookup process.

[0043] Step 6: Use the parsed VNI as the query key to perform an exact match query in the constructed mapping table to obtain the reduceID corresponding to the VNI.

[0044] The VNI value v in the outer VxLAN header and the destination IP address p of the inner IP packet are parsed out.

[0045] Query the VR-map to obtain the reduceID value r corresponding to v. The mapping table supports exact match queries, and the query logic is to quickly locate the corresponding reduceID based on the input VNI. This step realizes the conversion from the original VNI to the compressed reduceID, and its query latency is only in the nanosecond range, which will not affect the line-speed forwarding capability of the data plane, and provides a key intermediate result for subsequent lookups based on compressed table entries.

[0046] Step 7: Concatenate the reducedID obtained from the query with the destination IP address obtained from the parsing to form a composite key. Input the composite key into the TCAM that stores compressed routing table entries and perform longest prefix matching to obtain the matching routing table entries.

[0047] Concatenate r and p to form a composite key K = (r||p); submit K to TCAM for longest prefix matching and return the matching entry. The composite key is a concatenation of "reduceID + destination IP address", and its bit width is equal to the sum of the reduceID bit width and the IP prefix bit width. In this step, TCAM performs longest prefix matching based on this composite key. Since tenant IP prefixes under the same reduceID do not overlap, the matching result is unique and accurate, achieving both efficient lookup of compressed entries and ensuring the correctness of routing forwarding.

[0048] Step 8: Based on the matching routing table entries, complete the forwarding decision for the incoming packet.

[0049] The matched routing table entries contain forwarding information such as the next hop. This step determines the forwarding path of the incoming packet based on this information, completing the data forwarding loop. The entire process compresses the entry width while maintaining forwarding logic consistent with traditional solutions, ensuring technical compatibility and practicality.

[0050] The aforementioned method and system for compressing multi-tenant unified storage routing table entries based on identifier mapping, through dynamic allocation of reduceIDs and strict verification of IP prefix space overlap, ensures that routing table entries sharing the same reduceID will not conflict when matching the longest prefix, thus maintaining routing isolation and correctness in the unified storage scenario and fully preserving the core advantage of unified storage in terms of resource utilization. It also introduces a dynamic identifier, reduceID. The bit width of reduceID can be dynamically adjusted according to the actual number of tenants. During the routing table entry insertion phase, by allocating the minimum available reduceID that satisfies the requirement of no IP prefix space overlap for new tenants, the 24-bit VNI field that originally needed to be stored in the TCAM entry is replaced with the smaller-bit reduceID. During the lookup phase, using a RAM-based VNI-to-reduceID mapping table, the packet VNI is first converted to a reduceID, and then the TCAM is queried using reduceID + destination IP as the composite key. This eliminates the need for TCAM entries to carry the 24-bit VNI; only the reduceID and IP prefix, with a bit width much smaller than VNI, need to be stored, thus significantly reducing the entry bit width. Meanwhile, the lookup latency of the RAM mapping table is only in the nanosecond range, which will not affect the line-speed forwarding capability of the data plane. In high-performance data planes such as FPGAs or ASICs, it can effectively reduce hardware area and power consumption, and achieve efficient compression of VNI field width.

[0051] In one embodiment, such as Figure 5 As shown, the criterion for prefix space overlap is: there exists any IP prefix p1 in the set of tenant IP prefixes to be inserted and any IP prefix p2 in the set of tenant IP prefixes that have used the current candidate reduceID, such that an IP address can match both p1 and p2 simultaneously in the longest prefix matching process, and the optimal matching path cannot be uniquely determined by the prefix lengths of p1 and p2.

[0052] Specifically, longest prefix matching is the core logic of route lookup, and its principle is to prioritize matching the routing table entry with the longest prefix length. When an IP address can match both p1 and p2, and p1 and p2 have the same prefix length, or although their lengths are different, a unique optimal path cannot be determined through length priority, it is considered a prefix space overlap. For example, if p1 is 192.168.0.0 / 16 and p2 is 192.168.1.0 / 24, an IP address 192.168.1.5 can match both p1 and p2. In this case, p2 has a longer prefix length, which uniquely determines the optimal path, and it is not considered an overlap. However, if p1 is 192.168.0.0 / 16 and p2 is 192.168.0.0 / 16, then IP address 192.168.0.5 can match both, and since their prefix lengths are the same, a unique optimal path cannot be determined, and it is considered an overlap. This criterion ensures that tenant routing table entries sharing the same reduceID will not cause ambiguity during lookup, guaranteeing the correctness of routing and forwarding. It is a key prerequisite for realizing reduceID reuse and bit width compression.

[0053] In one embodiment, the bit width of reduceID is dynamically configured according to the maximum number of tenant isolations N required in the actual deployment scenario, typically 4 bits, 6 bits, or 8 bits.

[0054] Specifically, in real-world deployment scenarios, the maximum number of tenant isolations N required is far less than the 16 million theoretically supported by a 24-bit VNI. For example, if a data center needs to support a maximum of 256 independent tenants (N=256), then configuring the reduceID bit width W to 8 bits is sufficient; if it needs to support 64 tenants, W=6 bits is enough; and if it supports 16 tenants, W=4 bits is sufficient. This dynamic configuration method allows the reduceID bit width to accurately match actual needs, avoiding bit width waste, maximizing the bit width compression effect of TCAM entries, and simultaneously ensuring compatibility with multi-tenant deployment scenarios of different scales, thus improving the flexibility and applicability of the technical solution.

[0055] In one embodiment, TCAM only stores compressed routing table entries in the format of "reduceID+IP prefix" and does not store the original 24-bit VNI field. Let the width of the original routing table entry be S and the width of the compressed routing table entry be S', then S'=W+L, where W is the bit width of reduceID and L is the bit width of IP prefix.

[0056] In one embodiment, such as Figure 3 As shown, when there are no tenants with already used reduceIDs in the system, the candidate reduceID=0 is directly determined as the target reduceID of the tenant to be inserted. There is no need to perform prefix space overlap checks, and the routing table entries are directly compressed and stored.

[0057] Specifically, in the initial state of the system, there are no tenants, and no used reduceIDs and corresponding IP prefix sets exist. Therefore, the precondition for prefix space overlap does not hold, and no checking process is required. This embodiment optimizes the reduceID allocation logic for the initial tenant, eliminating meaningless overlap checking steps, simplifying the routing table entry insertion process, and improving initial deployment efficiency. Simultaneously, fixing the reduceID of the first tenant to 0 conforms to the "minimum availability" allocation strategy, laying a unified logical foundation for the reductionID allocation of subsequent tenants.

[0058] In one embodiment, such as Figure 5 As shown, when performing prefix space overlap check, the prefix intersection determination algorithm is used. Let the network address of the two IP prefixes to be checked be Net1 and the prefix length be Len1, and the network address of p1 be Net2 and the prefix length be Len2. Calculate the longest common prefix of p1 and p2. If the length of the longest common prefix is ​​≥ min(Len1, Len2), then it is determined that p1 and p2 have prefix space overlap; otherwise, it is determined that there is no overlap.

[0059] Specifically, network addresses Net1 and Net2 are the starting addresses of the network segments corresponding to the IP prefixes, and prefix lengths Len1 and Len2 represent the number of network bits in the network address. The longest common prefix refers to the prefix formed by comparing Net1 and Net2 bit by bit, starting from the most significant bit. This algorithm provides specific implementation logic for prefix space overlap checking. By quantitatively calculating the longest common prefix length, it ensures the accuracy and operability of overlap determination, avoids errors caused by subjective judgment, and provides reliable support for the reasonable allocation of reduceIDs.

[0060] In one embodiment, such as Figure 4 As shown, the execution logic of the longest prefix matching is as follows: traverse all compressed routing entries in the TCAM format of "reduceID+IP prefix", filter out all entries that match the composite key, compare the length of the IP prefix in the filtered entries, and determine the entry with the longest prefix length as the optimal matching entry, which is then output as the final matching result.

[0061] Specifically, the composite key is "reduceID + destination IP address". The matching logic is as follows: first, matches entries with the same reduceID; then, filters these entries to find those whose IP prefix covers the destination IP address. This execution logic continues the core principle of traditional longest prefix matching, ensuring the correctness of route lookup. At the same time, it performs matching based on the compressed entry format, achieving compression of the entry width without sacrificing performance, thus balancing correctness and efficiency.

[0062] In one embodiment, such as Figure 2 , Figure 4 As shown, the mapping table is implemented using a hash table, and the types of hash tables include Cuckoo Hash, chained hash, or open addressing hash.

[0063] A hash table is a data structure that enables fast key-value pair lookup based on hash functions, supporting exact match queries with an average time complexity of O(1). Cuckoo Hash uses multiple hash functions and hash tables to store and retrieve keys, featuring fast lookup speed and efficient collision handling. Chained hashing resolves hash collisions through linked lists, offering simplicity and strong compatibility. Open addressable hashing stores conflicting keys by probing free locations, requiring no additional linked list space and achieving high memory utilization. In this embodiment, the mapping table uses the aforementioned hash table types, ensuring that the query latency from VNI to reduceID is controlled at the nanosecond level, meeting the line-speed forwarding requirements of high-performance data planes. Furthermore, the hash table is implemented based on RAM, eliminating the need to occupy TCAM resources, reducing hardware costs, and working in conjunction with TCAM to achieve the optimization goal of "low-cost mapping + efficient compressed lookup".

[0064] The following detailed description of the implementation process of the present invention is provided through a specific embodiment.

[0065] Scene setting:

[0066] The system is initially empty;

[0067] Tenant A (VNI=100) uses the IP range 192.168.0.0 / 16;

[0068] Tenant B (VNI=200) uses 10.0.0.0 / 8;

[0069] Tenant C (VNI=300) uses 172.16.0.0 / 12;

[0070] Tenant D (VNI=400) uses 192.168.1.0 / 24.

[0071] Insertion process:

[0072] Insert tenant A:

[0073] The first tenant is assigned reduceID=0;

[0074] TCAM write: 0+192.168.0.0 / 16;

[0075] VR-map update: 100 → 0.

[0076] Insert tenant B:

[0077] Try reduceID=0: 10.0.0.0 / 8 and 192.168.0.0 / 16 have no overlap → can be reused;

[0078] TCAM write: 0+10.0.0.0 / 8;

[0079] VR-map update: 200 → 0.

[0080] Insert tenant C:

[0081] Trying reduceID=0: 172.16.0.0 / 12 has no overlap with 192.168.0.0 / 16 and 10.0.0.0 / 8 → it can be reused;

[0082] TCAM write: 0+172.16.0.0 / 12;

[0083] VR-map update: 300 → 0.

[0084] Insert tenant D:

[0085] When trying reduceID=0: 192.168.1.0 / 24 and 192.168.0.0 / 16 have an inclusion relationship → overlap, conflict;

[0086] Try reduceID=1: No tenant currently using 1 → no conflict;

[0087] TCAM write: 1+192.168.1.0 / 24;

[0088] VR-map update: 400 → 1.

[0089] Search process:

[0090] Received a data packet with VNI=400 and destination IP=192.168.1.5:

[0091] Query VR-map → reduceID=1;

[0092] Construction bond: 1+192.168.1.5;

[0093] TCAM matched 192.168.1.0 / 24 and forwarded correctly.

[0094] Received VNI=100, Destination IP=192.168.10.20:

[0095] VR-map→reduceID=0;

[0096] Key: 0+192.168.10.20;

[0097] Matches 192.168.0.0 / 16, correct.

[0098] Even if tenants A and D have an inclusion relationship in their IP spaces, the entries in TCAM will not interfere with each other because their reduceIDs are different (0 to 1), thus ensuring tenant isolation.

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

[0100] In one embodiment, such as Figure 6 As shown, a multi-tenant unified storage routing table entry compression system based on identifier mapping is provided, including:

[0101] The insertion preparation module is used to obtain the original VxLAN network identifier (VNI) of the tenant to be inserted and the set of IP prefixes of the tenant to be inserted, and output them to the reduceID allocation module.

[0102] The reduceID allocation module receives the VNI and IP prefix set output by the insertion preparation module. Starting from the initial value, it sequentially checks whether there is prefix space overlap between the IP prefix set of the used tenant corresponding to the current candidate reduceID and the IP prefix set of the tenant to be inserted. The first candidate reduceID that meets the non-overlap condition is determined as the target reduceID of the tenant to be inserted and output to the table entry storage module and the mapping table establishment module.

[0103] The table entry storage module is used to receive the target reduceID output by the reduceID allocation module and the IP prefix set output by the insertion preparation module, construct compressed routing table entries, and store the compressed routing table entries in TCAM;

[0104] The mapping table creation module is used to build a mapping table from VNI to reduceID based on RAM. It receives the VNI output by the insertion preparation module and the target reduceID output by the reduceID allocation module, associates the original VNI of the tenant to be inserted with the target reduceID, writes it into the mapping table and outputs it to the lookup preparation module.

[0105] The lookup preparation module is used to receive incoming packets encapsulated in VxLAN, parse the VNI and destination IP address of the incoming packets, output the VNI to the reduceID lookup module, and output the destination IP address to the union key matching module.

[0106] The reduceID query module is used to receive the VNI output by the lookup preparation module and the mapping table output by the mapping table creation module, query the reduceID corresponding to the VNI in the mapping table, and output it to the union key matching module.

[0107] The composite key matching module receives the reduceID output by the reduceID query module and the destination IP address output by the lookup preparation module, concatenates them to form a composite key, inputs the composite key into the TCAM that stores compressed routing table entries, performs the longest prefix matching, obtains the matching routing table entries, and outputs them to the forwarding decision module.

[0108] The forwarding decision module receives the matching routing table entries output by the union key matching module and makes forwarding decisions for incoming packets based on these entries.

[0109] Specific limitations regarding the identifier-mapping-based multi-tenant unified storage routing table entry compression system can be found in the limitations of the identifier-mapping-based multi-tenant unified storage routing table entry compression method described above, and will not be repeated here. Each module in the aforementioned identifier-mapping-based multi-tenant unified storage routing table entry compression system can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each module.

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

[0111] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these modifications and improvements all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for compressing multi-tenant unified storage routing table entries based on identifier mapping, characterized in that, The method includes: Obtain the original VxLAN network identifier (VNI) of the tenant to be inserted and the set of IP prefixes of the tenant to be inserted; Starting from the initial value, check sequentially whether there is prefix space overlap between the set of used tenant IP prefixes corresponding to the current candidate reduceID and the set of IP prefixes of the tenant to be inserted. The first candidate reduceID that meets the non-overlap condition is determined as the target reduceID of the tenant to be inserted. A compressed routing table entry is constructed by combining the target reduceID with the IP prefixes of each tenant to be inserted, and the compressed routing table entry is stored in TCAM; A mapping table from VNI to reduceID is constructed based on RAM. The original VNI of the tenant to be inserted is associated with the target reduceID and written into the mapping table to complete the mapping relationship maintenance. Receive incoming packets encapsulated in VxLAN, parse the VNI in the outer VxLAN header and the destination IP address in the inner IP packet, and use them as input parameters for route lookup; The parsed VNI is used as the query key to perform an exact match query in the constructed mapping table to obtain the reduceID corresponding to the VNI; The reduceID obtained from the query is concatenated with the destination IP address obtained from the parsing to form a composite key. The composite key is then input into the TCAM that stores compressed routing table entries, and the longest prefix matching is performed to obtain the matching routing table entry. Based on the matching routing table entry, the forwarding decision for the incoming packet is completed.

2. The method according to claim 1, characterized in that, The criterion for determining prefix space overlap is: there exists any IP prefix p1 in the set of tenant IP prefixes to be inserted and any IP prefix p2 in the set of tenant IP prefixes that have used the current candidate reduceID, such that an IP address can match both p1 and p2 simultaneously in the longest prefix matching process, and the optimal matching path cannot be uniquely determined by the prefix lengths of p1 and p2.

3. The method according to claim 1, characterized in that, The bit width of the reduceID is dynamically configured based on the maximum number of tenant isolations N required in the actual deployment scenario.

4. The method according to claim 1, characterized in that, The TCAM only stores compressed routing table entries in the format of "reduceID+IP prefix" and does not store the original 24-bit VNI field. Let the width of the original routing table entry be S and the width of the compressed routing table entry be S', then S'=W+L, where W is the bit width of reduceID and L is the bit width of IP prefix.

5. The method according to claim 1, characterized in that, The method further includes: When there are no tenants with already used reduceIDs in the system, the candidate reduceID=0 is directly determined as the target reduceID of the tenant to be inserted. There is no need to perform prefix space overlap checks, and the routing table entry is directly compressed and stored.

6. The method according to claim 2, characterized in that, The method further includes: When performing prefix space overlap checks, a prefix intersection determination algorithm is used. Let the network address of the two IP prefixes to be checked be Net1 and the prefix length be Len1, and the network address of the two IP prefixes to be checked be Net2 and the prefix length be Len2. Calculate the longest common prefix of p1 and p2. If the length of the longest common prefix is ​​≥ min(Len1, Len2), then it is determined that p1 and p2 have prefix space overlap; otherwise, it is determined that there is no overlap.

7. The method according to claim 1, characterized in that, The execution logic for the longest prefix matching is as follows: traverse all compressed routing entries in the TCAM format of "reduceID+IP prefix", filter out all entries that match the composite key, compare the length of the IP prefix in the filtered entries, and determine the entry with the longest prefix length as the optimal matching entry, which is then output as the final matching result.

8. The method according to claim 1, characterized in that, The mapping table is implemented using a hash table, and the type of the hash table includes Cuckoo Hash, chained hash, or open addressing hash.

9. A multi-tenant unified storage routing table entry compression system based on identifier mapping, characterized in that, The system includes: The insertion preparation module is used to obtain the original VxLAN network identifier (VNI) of the tenant to be inserted and the set of IP prefixes of the tenant to be inserted, and output them to the reduceID allocation module. The reduceID allocation module receives the VNI and IP prefix set output by the insertion preparation module. Starting from the initial value, it sequentially checks whether there is prefix space overlap between the IP prefix set of the used tenant corresponding to the current candidate reduceID and the IP prefix set of the tenant to be inserted. The first candidate reduceID that meets the non-overlap condition is determined as the target reduceID of the tenant to be inserted and output to the table entry storage module and the mapping table establishment module. The table entry storage module is used to receive the target reduceID output by the reduceID allocation module and the IP prefix set output by the insertion preparation module, construct compressed routing table entries, and store the compressed routing table entries in TCAM; The mapping table creation module is used to build a mapping table from VNI to reduceID based on RAM. It receives the VNI output by the insertion preparation module and the target reduceID output by the reduceID allocation module, associates the original VNI of the tenant to be inserted with the target reduceID, writes it into the mapping table and outputs it to the lookup preparation module. The lookup preparation module is used to receive incoming packets encapsulated in VxLAN, parse the VNI and destination IP address of the incoming packets, output the VNI to the reduceID lookup module, and output the destination IP address to the union key matching module. The reduceID query module is used to receive the VNI output by the lookup preparation module and the mapping table output by the mapping table creation module, query the reduceID corresponding to the VNI in the mapping table, and output it to the union key matching module. The composite key matching module receives the reduceID output by the reduceID query module and the destination IP address output by the lookup preparation module, concatenates them to form a composite key, inputs the composite key into the TCAM that stores compressed routing table entries, performs the longest prefix matching, obtains the matching routing table entries, and outputs them to the forwarding decision module. The forwarding decision module receives matching routing table entries output by the union key matching module and makes forwarding decisions for incoming packets based on these routing table entries.

10. The multi-tenant unified storage routing table entry compression system based on identifier mapping according to claim 9, characterized in that, The system is deployed on an FPGA or ASIC hardware platform. The RAM in the mapping table creation module is SRAM. The TCAM in the table entry storage module is integrated with the SRAM. By reducing the bit width of the TCAM table entries, the chip area and static and dynamic power consumption of the FPGA or ASIC hardware platform are reduced. The SRAM is used to implement VR-map to ensure query latency.

Images