WO2013040730A1 - Ip查找方法和装置以及路由更新方法和装置 - Google Patents

Ip查找方法和装置以及路由更新方法和装置 Download PDF

Info

Publication number
WO2013040730A1
WO2013040730A1 PCT/CN2011/001725 CN2011001725W WO2013040730A1 WO 2013040730 A1 WO2013040730 A1 WO 2013040730A1 CN 2011001725 W CN2011001725 W CN 2011001725W WO 2013040730 A1 WO2013040730 A1 WO 2013040730A1
Authority
WO
WIPO (PCT)
Prior art keywords
prefix
lookup
sram
update
tree
Prior art date
Application number
PCT/CN2011/001725
Other languages
English (en)
French (fr)
Inventor
罗腊咏
谢高岗
谢应科
Original Assignee
中国科学院计算技术研究所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中国科学院计算技术研究所 filed Critical 中国科学院计算技术研究所
Publication of WO2013040730A1 publication Critical patent/WO2013040730A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • H04L45/74591—Address table lookup; Address filtering using content-addressable memories [CAM]

Definitions

  • IP search method and device IP search method and device, and route update method and device
  • the present invention relates to IP-based network routers, and more particularly to an IP lookup method and a route update method. Background technique
  • IP lookup is a core component of network routers. Since the introduction of CIDR (Classless Inter-Domain Routing) in 1993, the IP lookup problem has become the problem of Longest Prefix Matching (LPM). Given a destination IP address, multiple IP prefixes in the routing table may match the address. Among these matched prefixes, the next hop information corresponding to the longest prefix will correctly determine the next hop of the packet. As network link rates progress toward 40 Gbps and beyond, IP lookups based on longest prefix matching become a major bottleneck in routers. To achieve 40Gbps throughput, a 40-byte network packet needs to complete IP lookups within 8 nanoseconds, which is difficult to achieve in traditional software-based IP lookup methods. There are two hardware platforms commonly used to achieve high throughput: Tri-State Content Addressable Memory (TCAM) and Static Random Access Memory (SRAM).
  • TCAM Tri-State Content Addressable Memory
  • SRAM Static Random Access Memory
  • TCAM is a specialized high-speed lookup device
  • a given search key may be in the range of 0 (the time all the entries in the TCAM stored simultaneously, and outputs the address matching entry is located. Since the TCAM, each memory cell Can be assigned to one of three states ("0""1" and "X" (optional), TCAM is very suitable for the longest prefix match.
  • a given destination IP address may match the storage in the TCAM Multiple prefixes, TCAM output address with the smallest matching prefix address. Therefore, in order to ensure the correct longest prefix match, the IP prefix must be stored in the TCAM in a certain order. The order restriction between the prefixes leads to routing. A large number of prefix movements may be required when updating, which affects forwarding performance and causes packet loss.
  • IP lookup pipeline Another common fast lookup hardware technology is based on SRAM's IP lookup pipeline.
  • the 1-bit trie data structure is often used to implement an IP lookup pipeline.
  • a single implementation of the IP lookup pipeline is to store the nodes of each level of the Terry tree separately into a pipeline level in the pipeline.
  • Each pipeline stage has a separate SRAM to store the Terry tree nodes, so multiple pipeline stages can be searched in parallel for high throughput (one IP lookup in one clock cycle).
  • the number of pipeline stages in the IP lookup pipeline is directly related to the number of layers in the Terry tree (32 for ipv4), which requires a large amount of SRAM in the IP lookup pipeline.
  • FPGAs Field-programmable logic gate arrays
  • SRAM-based IP lookup pipeline fast routing updates can be implemented using the write bubble method proposed by Anindya Basu et al. (refer to the article: Fast incremental updates for pipelined forwarding engines, INFOCOM 2003).
  • SRAM in the FPGA chip is a relatively scarce resource, and its reasonable allocation and effective use are especially important.
  • researchers have proposed a large number of storage equalization methods.
  • the SRAM resources on the chip are well utilized, on the whole, the on-chip SRAM resources are still difficult to meet the current large routing table for SRAM capacity. demand.
  • the lack of on-chip SRAM memory capacity has become a bottleneck in the IP lookup pipeline based on the on-chip SRAM of the FPGA, thus reducing the practicability of the IP lookup pipeline based on the on-chip SRAM of the FPGA. Summary of the invention
  • an IP search apparatus comprising: a TCAM-based IP lookup engine for storing a first prefix set, the first prefix set including a forwarding information base according to a router (FIB) a prefix corresponding to all leaf nodes of the 1-bit trie constructed;
  • a TCAM-based IP lookup engine for storing a first prefix set, the first prefix set including a forwarding information base according to a router (FIB) a prefix corresponding to all leaf nodes of the 1-bit trie constructed;
  • An SRAM-based IP lookup pipeline for storing a second prefix set, the second prefix set including a prefix corresponding to all intermediate nodes of the trie tree;
  • a priority arbitration module for arbitrating the output of the TCAM-based IP lookup engine and the SRAM-based IP lookup pipeline to output next hop information.
  • the second prefix set is stored in a data structure of a 1-bit trie in an SRAM-based IP lookup pipeline.
  • the output of the TCAM-based IP lookup engine has a higher priority than the output of the SRAM-based IP lookup pipeline.
  • the priority arbitration module directly selects the output result as the next hop information; otherwise, selects the TCAM-based IP search engine. The output is used as the next hop information.
  • each of the SRAM-based IP lookup pipelines uses a separate dual-port SRAM, one port of which is only read and the other port is only written.
  • an IP lookup method based on the above IP lookup apparatus comprising:
  • Step 1) After receiving the destination IP address of the data packet to be queried, it is simultaneously sent to the TCAM-based search engine and the SRAM-based search pipeline for searching;
  • Step 2) When only one search result is obtained in step 1), the result is directly used as the next hop information; when step 1) obtains two search results, the search result output by the TCAM-based search engine is selected as the next hop. information.
  • a route update method based on the above IP search device comprising:
  • Step 1) updating the auxiliary 1-bit trie in the router control plane based on the routing update of the forwarding information base of the router, and obtaining an update operation sequence for the first prefix set and the second prefix set; Step 2) According to the update operation sequence, for the TCAM-based search engine and the SRAM-based search pipeline, corresponding update operations are respectively performed in the data plane.
  • the update of the auxiliary 1-bit trie in the router control plane in the step 1) includes (a) inserting a new prefix, (b) deleting an existing prefix, and (C) modifying An existing prefix.
  • the step of inserting a new prefix includes the following steps: Step 101: Insert the prefix P into the original Terry tree T to obtain a new Terry tree ⁇ ; Step 102) In the new Terry tree , in , find the longest prefix Q of the prefix ⁇ , the longest prefix Q is the prefix corresponding to the ancestor node closest to the node where the prefix ⁇ is located in the new trie tree ;;
  • Step 103 If the prefix ⁇ is a non-leaf prefix in the trie, the prefix ⁇ is inserted into the second prefix set;
  • Step 104) If ⁇ is the leaf prefix in the Terry tree, determine whether Q is the non-leaf prefix in the original Terry tree; if yes, insert ⁇ into the first prefix set, otherwise insert Q into the second Prefix the set and remove Q from the first prefix set, then insert ⁇ into the first prefix set.
  • the deleting the update of an existing prefix includes the following steps:
  • Step 111) deleting the prefix ⁇ from the original trie tree to obtain a new trie ⁇
  • step 112) finding the longest prefix Q of the prefix ⁇ in the original trie tree, the longest prefix Q being in the original a prefix corresponding to the ancestor node closest to the node where the prefix is located in the tree;
  • Step 113) If the prefix ⁇ is a non-leaf prefix in the trie tree, the ⁇ is deleted from the second prefix set;
  • Step 114) If the prefix ⁇ is a leaf prefix in the trie tree, it is determined whether Q is a non-leaf prefix in the trie tree, and if so, the ⁇ is deleted from the first prefix set; otherwise, from the first prefix set Delete ⁇ , then insert Q into the first prefix set and remove 0 from the second prefix set.
  • the step 2) performs a write operation on the TCAM-based search engine in the data plane, and performs an update operation on the SRAM-based search pipeline in a manner of writing bubbles.
  • a routing update apparatus comprising:
  • a TCAM-based IP lookup engine for storing a first prefix set, the first prefix
  • the set includes a prefix corresponding to all leaf nodes of the 1-bit trie constructed according to the forwarding information base of the router;
  • An SRAM-based IP lookup pipeline for storing a second prefix set, the second prefix set including a prefix corresponding to all intermediate nodes of the trie tree;
  • An update control unit configured to perform an update of the auxiliary 1-bit trie in the router control plane according to the routing update of the forwarding information base of the router, to obtain an update operation sequence for the first prefix set and the second prefix set; And for updating, in the data plane, the first prefix set in the TCAM based lookup engine and the second prefix set in the SRAM based lookup pipeline, respectively, according to the update operation sequence.
  • the second prefix set is stored in the data structure of the 1-bit trie in the SRAM-based IP lookup pipeline.
  • each of the SRAM-based IP lookup pipelines uses a separate dual-port SRAM, one port of the dual-port SRAM only performs read operations, and the other port performs only write operations.
  • the update control unit is mainly configured to complete the first prefix set and the SRAM based on the TCAM-based search engine by using the route update method as described above according to the routing update of the forwarding information base of the router.
  • the second set of prefixes in the lookup pipeline are updated.
  • the prefix stored in the TCAM-based lookup engine is a disjoint leaf prefix, there is no need to follow any order restrictions between the leaf prefixes, and therefore, the leaf prefixes can be stored in any position in the TCAM in any order.
  • Flexible storage ensures that TCAM utilization is close to 100% (there is still a need to reserve the appropriate space for further routing updates).
  • the space required for the overlapping prefix set actually stored in the SRAM-based IP lookup pipeline is also very small, which alleviates the problem of insufficient SRAM storage space in the FPGA.
  • FIG. 1 is a schematic structural diagram of an IP search device according to an embodiment of the present invention.
  • FIG. 2(a) is a schematic diagram of a 1-bit trie tree used in an embodiment of the present invention
  • FIG. 2(b) is a schematic diagram of a disjoint prefix set corresponding to a leaf node of a trie tree shown in FIG. 2(a);
  • Figure 2 (c) is a schematic diagram of the remaining trie corresponding to the overlapping prefix set
  • FIG. 3(a) is a schematic structural diagram of an SRAM-based IP lookup pipeline according to an embodiment of the present invention.
  • Figure 3 (b) is a detailed schematic diagram of each flow level of the IP lookup pipeline shown in Figure 3 (a);
  • FIG. 4 is a schematic diagram showing changes in the insertion of a leaf prefix into the disjoint prefix set and the overlapping prefix set in the trie shown in FIG. 2( a );
  • FIG. 5 is a schematic diagram showing changes in deleting a leaf prefix to a disjoint prefix set and an overlapping prefix set in the trie shown in FIG. 2(a);
  • FIG. 6 is a schematic diagram showing a comparison of theoretical throughput and actual throughput of an IP lookup device according to an embodiment of the present invention
  • Figure 7 is a comparison of the update overhead of various TCAM-based lookup engines simulated with the actual routing table. detailed description
  • FIG. 1 shows a block diagram of an embodiment of an IP lookup device.
  • the IP lookup device includes two parallel IP lookup engines: a TCAM based IP lookup engine and an SRAM based IP lookup pipeline.
  • TCAM-based IP lookup engine all the leaf prefixes of the 1-bit trie constructed according to the forwarding information base of the router are stored, and the leaf prefix is the prefix corresponding to the leaf node of the trie.
  • Stored in the SRAM-based IP lookup pipeline are all non-leaf prefixes of a 1-bit trie constructed according to the forwarding information base of the router, the non-leaf prefix being the prefix corresponding to the intermediate node of the trie.
  • the intermediate node of the 1-bit trie constructed according to the forwarding information base of the router may correspond to the prefix, and may not correspond to any prefix.
  • a 1-bit Terry tree tube is hereinafter referred to as a Terry tree.
  • the method of constructing a 1-bit trie tree well known to those skilled in the art can be used to construct a trie tree according to the forwarding information base of the router.
  • an example prefix set P1-P6 of a single cartridge is selected, corresponding to P1: 0*, P2: 00*, P3: 11*, P4: 100, respectively. *, P5: 101*, P6: 111*.
  • Figure 2 (a) shows a 1-bit trie constructed in accordance with the example prefix set.
  • the gray node represents the prefix node (ie, the node corresponds to a prefix), and has corresponding next hop information;
  • the white node represents a non-prefixed node, and there is no corresponding Next hop information.
  • the entries in the forwarding information base include not only the prefix but also the corresponding next hop information.
  • the management of the next hop information has little effect on the routing update. Therefore, for convenience of description, the management of the next hop information is ignored in the present invention, and the terms of the forwarding information base and the prefix set are not distinguished.
  • the prefixes P2, P4, P5, and P6 are leaf prefixes, and these leaf prefixes are collected into a leaf prefix set.
  • Figure 2 (b) shows the leaf prefix set of the Terry tree of Figure 2 (a). Since the prefixes in the leaf prefix set do not intersect, they can also be called disjoint prefix sets.
  • the disjoint prefix set is stored in the TCAM based IP lookup engine of the IP lookup device.
  • the corresponding prefix in the trie tree shown in Figure 2 (c) (where P1 corresponds to 0* and P3 corresponds to 11*), which overlaps with the address range indicated by the prefix shown in Figure 2 (b), for example, P1 represents The address range covers the address range represented by P2.
  • the prefix set corresponding to the trie tree shown in FIG. 2(C) can also be referred to as an overlapping prefix set.
  • the prefix in the overlapping prefix set is a sub-prefix of the prefix in the disjoint prefix set, for example, P1 is a sub-prefix of P2, and P3 is a sub-prefix of P6.
  • this overlapping prefix set is stored in a 1-bit trie data structure into the SRAM-based IP lookup pipeline of the IP lookup device.
  • the overlapping prefix set may also be stored in the SRAM-based IP lookup pipeline of the IP lookup device in other trie tree data structures.
  • an IP lookup pipeline based on an FPGA on-chip SRAM can be employed. For a given data packet, the packet header is sent to the packet header parsing module for parsing, and the destination IP address is extracted. At the same time, the packet is buffered in the packet buffer waiting for the next hop information of the query.
  • the destination IP address is simultaneously sent to the TCAM-based IP lookup engine and the SRAM-based IP lookup pipeline for simultaneous lookup. Since the prefix stored in the SRAM-based lookup pipeline is a sub-prefix of the prefix stored in the TCAM-based lookup engine, the result output by the TCAM lookup engine has a higher priority (representing a longer prefix).
  • the priority arbitration module arbitrates the output of the TCAM lookup engine and the SRAM lookup pipeline. When only one search engine outputs the search result, the priority arbitration module directly outputs the result as the final next hop information; when both search engines output the search result, the priority arbitration module selects the result output by the TCAM search engine as the next One hop message.
  • the packet modification module reads a data packet from the data packet buffer, performs corresponding modification on the data packet header according to the next hop information, and then sends the data packet to the next One-hop information specifies the physical interface.
  • the IP lookup device in this embodiment can also implement fast IP lookup. Moreover, the IP search device in this embodiment effectively alleviates the problem of insufficient storage space in the existing IP lookup pipeline based on the FPGA on-chip SRAM. This is because only the overlapping prefix sets are stored in the SRAM-based IP lookup pipeline of the IP lookup device. In the above description, a simple prefix set Pl-P6 is used for convenience of description.
  • the IP search device in this embodiment can support fast incremental update because only the leaf prefix shown in Figure 2(b) is stored in the TCAM-based IP lookup engine of the IP lookup device. Collection (disjoint prefix set). Since the prefixes in the leaf prefix set do not intersect, a maximum of one prefix can be matched for a given destination IP address. The storage of the disjoint prefix set in the TCAM-based IP lookup engine does not need to consider any order restrictions. A new prefix can be inserted into any available location in the TCAM-based IP lookup engine without causing the incorrect maximum length. The prefix matches.
  • the routing update in the TCAM-based IP search engine does not cause any prefix movement;
  • all the prefixes in the disjoint prefix set are naturally disjoint, no prefix is copied. Therefore, for a routing update, only one TCAM write operation is required in one worst case.
  • SRAM-based IP lookup pipelines write bubbles are often used to implement incremental updates (refer to the literature: Fast incremental updates for pipelined forwarding engines, INFOCOM 2003 and literature: Dynamic pipelining: Making IP lookup truly scalable, SIGCOMM 2005) .
  • a single-port SRAM is used in the pipeline, and writing a bubble may cause the IP search pipeline to stall, because the IP lookup performs a read operation, the routing update performs a write operation, and the read and write operations. It is not possible to do it on the same port of the SRAM at the same time.
  • SRAM in FPGAs generally has dual port characteristics. For example, the block RAM in Xilinx FPGA is double port.
  • the overall IP lookup performance depends on the lookup performance of the TCAM (because the lookup performance of the SRAM based lookup pipeline is generally higher than that of the TCAM based lookup engine). Therefore, in another embodiment, in order to ensure that the routing update has no effect on the IP lookup in the SRAM-based lookup pipeline without affecting the overall lookup performance, a dual-port SRAM is adopted in the IP lookup device. IP lookup pipeline with independent lookup and update paths.
  • Figure 3 (a) shows a block diagram of an embodiment of a dual-port SRAM-based IP lookup pipeline with independent lookup and update channel paths. Among them, one port of the dual port SRAM is dedicated to IP lookup, and the other port is dedicated to routing update. Thus, although a pipeline is still in use, routing updates and IP lookups do not affect each other.
  • Figure 3 (b) depicts the specific details of each of the flow levels shown in Figure 3 (a).
  • one port of the dual-port SRAM is only read, that is, the node content is read according to the node address during IP lookup; the other port is only written, that is, in the routing update. Add or modify node content at the corresponding address. Therefore, read and write operations can be performed simultaneously without conflict.
  • IP lookup pipeline shown in Figure 3 (a) IP lookup and routing updates are performed using two different data paths, thus solving the impact of routing updates on IP lookups.
  • the overlapping prefix set corresponds to the Terry tree stored to be based on
  • SRAM's IP lookup pipeline nodes of different levels are stored in different pipeline stages.
  • IP lookup the destination IP address is traversed sequentially from the first pipeline level shown in Figure 3 (a).
  • the node information accessed in the current pipeline level is read out. If the current node is a prefix node, the content of the longest prefix is updated.
  • the address of the child node of the current node that should be traversed in the next-class water level is determined. Then, use the address of the child node to access the next pipeline level.
  • the longest prefix recorded is the longest prefix that matches the destination IP address.
  • the write bubble that implements the current update is calculated in the software of the router control plane. It is worth noting that the write bubble itself does not contain any data.
  • the write bubble does not need to wait for data, and it takes only one clock cycle to access each pipeline level, which means that the speed at which the write bubble traverses the pipeline level is the same as the speed at which the IP lookup traverses the pipeline level. Therefore, fast IP lookups and routing updates can be supported.
  • IP lookups and routing updates are performed simultaneously, IP lookups do not access an inconsistent trie state.
  • IP lookup and write bubble access the same node of the same pipeline level at the same time, IP lookup always reads out the node content before modification (please refer to the READ_FIRST feature of Xilinx FPGA on-chip SRAM), and this kind of read The preferred characteristics are maintained throughout the traversal process. Therefore, even if routing updates and IP lookups occur simultaneously, IP lookups always access a full Trie tree without the worst longest prefix match.
  • the overhead of routing update in the IP lookup device in this embodiment is very small, because the routing update in the SRAM-based IP lookup pipeline has no effect on the performance of the IP lookup; and in the TCAM-based IP lookup engine In the case of a routing update, only one TCAM write operation is required in the worst case. And with the existing two-port SRAM-based two streams Compared with the waterline structure, the pipeline structure with independent search and update paths in this embodiment is convenient to implement.
  • an IP search method based on the foregoing IP search device is further provided.
  • the method firstly divides a trie constructed according to a forwarding information base of a router into a disjoint set of leaf prefixes and an overlap. a prefix set; store the disjoint set of leaf prefixes in a TCAM-based lookup engine, store overlapping prefix sets in a SRAM-based lookup pipeline in a data structure of the Terry tree; and simultaneously use a TCAM-based lookup engine and IP lookup in the SRAM lookup pipeline. It mainly includes the following steps:
  • Step 1 Split the trie constructed according to the forwarding information base of the router.
  • all the leaf prefixes of the constructed trie are collected into a collection (ie, a disjoint prefix set). Then all the leaf nodes in the original trie are deleted, and all the non-prefixed leaf nodes are recursively deleted from the remaining trie, until all the leaf nodes in the cropped trie are prefix nodes. Finally, all the prefixes corresponding to the trimmed Terry tree are collected into another set (ie, the overlapping prefix set).
  • Step 2 Store the disjoint prefix set in the TCAM-based lookup engine and store the overlapping prefix set in the Stree-based lookup pipeline in the data structure of the trie.
  • Step 3 Simultaneously perform IP lookup in the TCAM-based search engine and the SRAM-based lookup pipeline.
  • the search result is directly used as the final Next hop information;
  • the search result in the TCAM based search engine is selected as the next hop information.
  • a route update method for the above IP lookup device is also proposed.
  • a routing update to the original forwarding repository may result in routing updates in both the TCAM based lookup engine and the SRAM based lookup pipeline.
  • a routing update can be divided into three categories: (1) insert a new prefix; (2) delete an existing prefix; (3) modify an existing prefix.
  • the implementation of the third type of update is very simple, because this type of update is only a modification of the next hop information of the existing prefix, and does not change the nature of the original trie.
  • the first two types of updates are relatively complex. Inserting or deleting a prefix may result in a change in the original trie shape, affecting both the disjoint prefix set and the overlapping prefix set.
  • an auxiliary 1-bit trie is maintained at the control plane of the router for recording the location of the prefix stored in the IP lookup device described above. It should be noted that this 1-bit trie is on the road Used for auxiliary routing updates in the control plane of the device (for example: in the CPU). Any operation for this auxiliary 1-bit trie will not affect the forwarding process because the forwarding engine is in the data plane.
  • a complete routing update operation includes two phases.
  • the first phase completes the update of the auxiliary trie in the router control plane.
  • the main purpose of this phase is to find the impact of this routing update on disjoint prefix sets and overlapping prefix sets.
  • the second phase focuses on TCAM-based lookup engines and SRAM-based lookup pipelines, implementing update operations in the data plane (writes for TCAM and writes to SRAM).
  • the above routing update process will be more clearly described below with reference to Figs. 4 and 5.
  • Figure 4 shows a scenario in which a new leaf prefix P7 is inserted in the trie shown in Figure 2(a).
  • the prefixes P2, P4, P5, and P6 are leaf prefixes, belonging to the disjoint prefix set, and should be stored in the TCAM-based search engine;
  • the prefixes P1 and P3 are prefixes stored by the intermediate nodes, belonging to the overlapping prefix set. It should be stored in the SRAM-based IP lookup pipeline in the form of a trie tree.
  • the node where P7 is located is a new leaf node. Therefore, the prefix P7 becomes a new leaf prefix in the updated trie.
  • the previous leaf prefix P2 becomes a non-leaf prefix.
  • the changes brought by the insertion of the prefix P7 to the disjoint prefix set and the overlapping prefix set can be summarized as: (1) the prefix P2 should be inserted into the overlapping prefix set; (2) the prefix P2 should be deleted from the disjoint prefix set; (3) the prefix P7 should be inserted into the disjoint prefix set.
  • the prefix P2 should be inserted into the SRAM-based IP lookup pipeline in a bubble-by-buffer manner.
  • the prefix P7 should override the prefix P2 already stored in the TCAM-based lookup engine.
  • Leaf Prefix The storage location in the TCAM-based lookup engine can be recorded in the leaf node of the auxiliary 1-bit trie of the control plane.
  • Figure 5 shows a scenario in which an existing prefix P2 is deleted in the trie shown in Figure 2).
  • the prefixes P2, P4, P5, and P6 are leaf prefixes, belonging to the disjoint prefix set, and should be stored in the TCAM-based search engine;
  • the prefixes P1 and P3 are prefixes stored by the intermediate nodes, belonging to the overlapping prefix set. It should be stored in the SRAM-based IP lookup pipeline in the form of a trie tree.
  • the previous non-leaf prefix P1 becomes the leaf prefix.
  • the changes brought by the deletion of the prefix P2 to the disjoint prefix set and the overlapping prefix set can be summarized as follows: (1) The prefix P2 should be deleted from the disjoint prefix set; (2) the prefix P1 should be inserted into the disjoint prefix set; (3) The prefix P1 should be removed from the overlapping prefix set.
  • the prefix P1 should override the prefix P2 already stored in the TCAM based lookup engine.
  • the storage location of the leaf prefix in the TCAM-based lookup engine can be recorded in the leaf node of the auxiliary 1-bit trie of the control plane.
  • the deletion of the prefix P1 in the overlapping prefix set should be done in a SRAM-based IP lookup pipeline in a bubble-by-buffer manner.
  • Figures 4 and 5 are just two typical update scenarios, and other types of insertion and deletion operations can be similarly accomplished.
  • the prefix insertion algorithm used is:
  • the longest prefix Q is the prefix corresponding to the ancestor node closest to the node where P is located in the tree, that is, if the parent node of the node where P is located is the prefix node, then the prefix corresponding to the parent node is the most Long prefix Q; If its parent node is not a prefix node, then continue upwards to find its nearest ancestor node containing the prefix information, the prefix corresponding to the ancestor node is the longest prefix Q.
  • the prefix deletion algorithm used is as follows:
  • the update overhead is very small (note that inserting a prefix and deleting one in the TCAM can be combined into one write operation.
  • the prefix insertion algorithm step 10 in the disjoint prefix The centralized deletion of the prefix Q and the insertion of the prefix P can be done with one write operation: The prefix P is inserted into the location where the prefix Q is stored (ie: the prefix Q is overwritten with the prefix P).
  • the order between the TCAM-based lookup engine and the SRAM-based lookup pipeline in the IP lookup device described above must be in the order of the steps of the above algorithm to prevent incorrect longest prefix matching.
  • the order described in the algorithm must be maintained. Otherwise, the prefix Q will disappear in the entire IP lookup device for a period of time during the gap between two write operations. , affecting the integrity of the entire routing table, may result in incorrect longest prefix matching.
  • a routing update apparatus comprising a TCAM based IP lookup engine and an SRAM based IP lookup pipeline and an update control unit as described above.
  • the update control unit is mainly used for performing routing update according to the forwarding information base of the router, and adopting the route update method as described above to complete the overlap in the disjoint prefix set and the SRAM-based lookup pipeline in the TCAM-based search engine. Update of the prefix set.
  • the experimental routing table file is 14 IPv4 routes downloaded from the RIPE RIS project (refer to: RIS RAW Data, http://www.ripe.net/data-tools/stats/ris/ris-raw-data ) table.
  • RIS RAW Data http://www.ripe.net/data-tools/stats/ris/ris-raw-data
  • all routing tables have the same prefix (because each backbone router has essentially the same view of the entire network).
  • Table 1 shows the statistical results of 14 routing tables. As can be seen from Table 1, for all routing tables, more than 90% of the prefixes are leaf prefixes, which are included in the disjoint prefix set. The number of nodes of the last trimmed Terry tree is about 12% of the number of original Terry tree nodes. Based on the results of the data analysis, the following conclusions can be drawn:
  • FIG. 6 shows the throughput achieved on the PEARL platform with four Gigabit network interfaces (refer to: PEARL: A programmable virtual router platform, IEEE Communications Magazine 2011) according to the IP lookup device provided by the above embodiment.
  • the PEARL platform is equipped with a Xilinx Virtex-5 family of XC5VLX110T-1 FPGAs and an IDT company's IDT75K72100 TCAM.
  • the FPGA's post-layout timing report shows that the FPGA's internal SRAM-based IP lookup pipeline has a maximum clock frequency of 297MHz (meaning that the pipeline's maximum throughput is 297 MLPS (million searches per second)).
  • the maximum throughput of the TCAM-based IP lookup engine is 250 MLPS. Therefore, the maximum theoretical throughput of this embodiment is 250 MLPS, far exceeding the throughput requirement of 100G Ethernet (in 100G Ethernet, IP lookup)
  • the maximum throughput requirement is approximately 148 MLPS).
  • the PEARL hardware platform has only four Gigabit physical interfaces and is limited by the bandwidth of the real physical interface, the maximum throughput that can be tested in embodiments of the present invention is approximately 5.95 MLPS.
  • Figure 6 shows a comparison of the actual test throughput of an IP lookup device based on the PEARL platform with the theoretical maximum throughput (4 Gigabit line speeds) that the platform can achieve.
  • the actual throughput of the IP lookup device in this embodiment can reach the line rate of 4 Gigabit interfaces.
  • the IP lookup device has a significant advantage in supporting fast routing updates.
  • each updated TCAM write operation is used in the experiment.
  • Table 2 is a theoretical comparison of the update overhead of various TCAM-based lookup engines (represented by the number of TCAM write operations required per average update).
  • the update overhead of the PLO_OPT technology and the CAO_OPT technology requires only one TCAM write operation for one update, and the update overhead of the MIPS method and the IP lookup device of the present invention is one update only. It takes 0 TCAM writing operations.
  • the differences in various technology update costs are large.
  • the CAO_OPT technique the chained order of prefixes needs to be maintained, and the free space of the TCAM is maintained in the middle of the TCAM, so one update requires D/2 TCAM write operations in the worst case (where D is the length of the longest chain, In the case of IPv4, the theoretical maximum value of D is 32).
  • MIPS technology uses the leaf pushing technique to convert the original set of prefixes into a disjoint set of prefixes, avoiding any ordering requirements between prefixes.
  • leaf push may result in prefix replication.
  • a prefix may be copied f- 1 times.
  • the prefix set stored in the TCAM is a naturally disjoint prefix, neither maintenance of any prefix order nor any prefix is copied, so in the worst case, only one route update is required. Secondary TCAM write operation.
  • Figure 7 is a comparison of the runtime update overhead (represented by the number of TCAM writes required per average update) simulated with the actual routing table.
  • the routing table file rrcOO and the one-hour routing update file are all from RIPE RIS. Project acquisition (please refer to: RIS RAW Data, http://www.ripe.net/data-tools/stats/ris/ris-raw-data )»
  • the four curves in Figure 7 represent the average update cost of the four methods. A situation that changes as the number of updated prefixes increases. In the IP lookup device of the present invention, the average update overhead is always lower than one TCAM write operation per second.
  • the number of TCAM writes required for a worst-case routing update is directly The size of the packet buffer in the IP lookup device is determined (in order to prevent packet loss caused by a decrease in IP lookup performance during route update, a packet buffer cache is required to wait for a packet to be searched for update).
  • the worst case update overhead simulated by the actual routing table (only one TCAM write operation is required for one routing update) is far lower than the other three methods (as shown in Table 3, 3 is the update cost comparison result simulated by the actual routing table).
  • each write bubble is at the worst. This can cause the route lookup to stall for one clock cycle.
  • the impact of routing updates in an SRAM-based IP lookup pipeline on IP lookups is completely eliminated by employing a dual-port based SRAM pipeline with independent lookup and update data paths.
  • the IP search device and the IP search and route update method of the embodiments of the present invention implement fast update while ensuring fast search.
  • a routing update will only generate a TCAM write and will have no effect on the SRAM-based IP lookup pipeline.
  • the routing update overhead is much lower than existing related technologies.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明提供一种IP查找装置，其包括基于TCAM的IP查找引擎和基于SRAM的IP查找流水线，可以同时在这两个查找引擎中进行IP查找。在基于TCAM的IP查找引擎中，存储的是根据路由器的转发信息库构造的1比特特里树的所有叶子节点所对应的前缀，而在基于SRAM的IP查找流水线中，存储的是该特里树的中间节点对应的所有前缀。该装置在实现快速IP查找的同时，支持快速的增量路由更新。而且提高了TCAM的利用率，并缓解了基于FPGA片内SRAM的IP查找流水线存储空间不足的问题。

Description

IP查找方法和装置以及路由更新方法和装置
技术领域
本发明涉及基于 IP的网络路由器， 尤其涉及 IP查找方法和路由更新 方法。 背景技术
IP查找是网络路由器的核心组成部分。 自从 1993年采用 CIDR (无类 别域间路由）以来， IP查找问题变成了最长前缀匹配（LPM, Longest Prefix Matching ) 问题。 给定一个目的 IP地址， 路由表中多个 IP前缀可能匹配 该地址。 在这些匹配的前缀中， 最长前缀对应的下一跳信息将正确决定数 据包的下一跳。 随着网络链路速率朝 40Gbps及其以上发展， 基于最长前 缀匹配的 IP查找成为路由器中的一个主要瓶颈。 为了达到 40Gbps的吞吐 量， 一个 40字节的网络数据包需要在 8纳秒之内完成 IP查找， 这在传统 的基于软件的 IP 查找方法中难以实现。 有两种硬件平台常用于实现高吞 吐量： 三态内容可寻址存储器（ TCAM )和静态随机存取存储器（ SRAM )。
TCAM是一种专用的高速查找器件， 一个给定搜索关键字可以在 0( 的时间内与 TCAM中存储的所有条目同时进行比较，并输出匹配条目所在 的地址。由于 TCAM中的每个存储单元都可以被指定为三种状态（ "0" "1" 和 "X" (随意））之一， TCAM非常适用于最长前缀匹配。 然而， 一个给 定的目的 IP地址， 可能匹配 TCAM中存储的多条前缀， TCAM输出地址 最小的匹配前缀的地址。 因此， 为了保证正确的最长前缀匹配， IP前缀在 TCAM中的存储必须遵循一定的顺序限制。这种前缀之间的顺序限制导致 路由更新时可能需要大量的前缀移动， 从而影响转发性能， 导致丟包。
为了解决基于 TCAM的路由更新问题， Devavrat Shah等人提出了两 种具体的方法： PLO_OPT 和 CAO_OPT (请参考文献： Fast updating algorithms for TCAMs , Micro 2001 )。 在 PLO_OPT方法中， 所有的 IP前 缀按照前缀长度降序存储在 TCAM中， 同时将 TCAM中的空闲空间维护 在 TCAM中央位置。在 CAO_OPT方法中， 前缀长度顺序限制只应用于同 一条链上的 IP前缀（在用 1比特特里树（ 1-bit trie )结构表示的 IP前缀中， 一条链指从该特里树的根节点出发的任意一条路径）。 上述两种方法都降 低了每次路由更新可能导致的前缀移动次数。 然而， 由于前缀长度顺序限 制依然存在， 一次路由更新仍然可能导致多次前缀移动。 在 Gesan Wang 等人提出的 MIPS ( Minimum Independent Prefix Set, 最小独立前缀集）方 法中 (请参考文献： TCAM-Based Forwarding Engine with Minimum Independent Prefix Set (MIPS) for Fast Updating , ICC 2006 ), 使用了一种 叶推技术（ leaf pushing ), 将整个前缀集转换为一个不相交的前缀集， 从 而彻底地避免了前缀顺序。 然而， 叶推技术可能导致前缀复制。 当更新一 条被复制的前缀时， 与该前缀对应的多条复制前缀都需要更新。 因此， 在 最坏情况下， 一次路由更新仍然需要多次 TCAM写操作。
另一个常见的快速查找硬件技术是基于 SRAM 的 IP查找流水线。 1 比特特里树数据结构常用于实现 IP查找流水线。 IP查找流水线的一种筒 单实现方式是将特里树的每个层次的节点分别存储到流水线中的一个流 水级。 每个流水级都有独立的 SRAM来存储特里树节点， 因此， 多个流 水级可以并行查找， 从而实现高吞吐量 （一个时钟周期输出一个 IP查找 结果）。 然而， IP查找流水线中流水级的个数跟特里树的层数有直接关系 (对 ipv4来说是 32个）， 在 IP查找流水线中需要大量的 SRAM。 现场可 编程逻辑门阵列 （ FPGA ) 内部有大量的小 SRAM, 因此， FPGA常用于 实现基于 SRAM的 IP查找流水线。 在基于 SRAM的 IP查找流水线中， 快速的路由更新可以使用 Anindya Basu等人提出的写气泡 (write bubble) 方法实现 (请参考文献： Fast incremental updates for pipelined forwarding engines, INFOCOM 2003 )。
然而， FPGA片内的 SRAM是相对稀缺的资源， 对其的合理分配和有 效利用尤为重要。 最近几年研究学者提出了大量的存储均衡方法， 虽然很 好的利用了片内的 SRAM资源， 但是， 从总体上讲， 片内的 SRAM资源 还是很难满足目前大的路由表对 SRAM容量的需求。 片内 SRAM存储容 量的不足， 成为基于 FPGA片内 SRAM的 IP查找流水线的一个瓶颈， 从 而降^ 了基于 FPGA片内 SRAM的 IP查找流水线的实用性。 发明内容
因此， 本发明的目的在于克服上述现有技术的缺陷， 提供一种 IP 查 找装置， 在保证快速查找的同时， 支持快速的路由更新。 本发明的目的是通过以下技术方案实现的：
根据本发明的一个方面， 提供了一种 IP查找装置， 所述装置包括： 基于 TCAM的 IP查找引擎， 其用于存储第一前缀集， 所述第一前缀 集包括根据路由器的转发信息库 （FIB )构造的 1 比特特里树的所有叶子 节点对应的前缀；
基于 SRAM的 IP查找流水线， 其用于存储第二前缀集， 所述第二前 缀集包括所述特里树的所有中间节点对应的前缀；
优先级仲裁模块， 其用于对基于 TCAM的 IP查找引擎和基于 SRAM 的 IP查找流水线的输出结果进行仲裁， 以输出下一跳信息。
上述 IP查找装置中， 所述第二前缀集以 1 比特特里树的数据结构存 储在基于 SRAM的 IP查找流水线中。
上述 IP查找装置中， 基于 TCAM的 IP查找引擎的输出结果比基于 SRAM的 IP查找流水线的输出结果具有更高的优先级。
上述 IP查找装置中， 当基于 TCAM的 IP查找引擎和基于 SRAM的 IP查找流水线只有一个输出结果时，优先级仲裁模块直接选择该输出结果 作为下一跳信息， 否则， 选择基于 TCAM的 IP查找引擎的输出结果作为 下一跳信息。
上述 IP查找装置中，基于 SRAM的 IP查找流水线中的每个流水级都 采用独立的双口 SRAM,所述双口 SRAM的一个端口只进行读操作， 另一 个端口只进行写操作。
根据本发明的另一个方面， 提供了基于上述 IP查找装置的 IP查找方 法， 所述方法包括：
步骤 1 )在接收到待查询的数据包的目的 IP地址后， 同时将其送入基 于 TCAM的查找引擎和基于 SRAM的查找流水线中进行查找；
步骤 2 ) 当步骤 1 ) 只得到一个查找结果时， 直接将该结果作为下一 跳信息； 当步骤 1 )得到两个查找结果时， 选择基于 TCAM的查找引擎所 输出的查找结果作为下一跳信息。
根据本发明的又一个方面， 提供了基于上述 IP 查找装置的路由更新 方法， 所述方法包括：
步骤 1 )基于路由器的转发信息库的路由更新， 完成对路由器控制平 面中辅助的 1比特特里树的更新， 得到对第一前缀集和第二前缀集的更新 操作序列； 步骤 2 )根据所述更新操作序列， 针对基于 TCAM的查找引擎和基于 SRAM的查找流水线， 在数据平面中分别执行相应的更新操作。
上述路由更新方法中， 所述步骤 1 ) 中对路由器控制平面中辅助的 1 比特特里树的更新包括（a ) 插入一条新前缀， （b ) 删除一条已存在的前 缀， 以及 （C )修改一条已存在的前缀。
上述路由更新方法中， 所述插入一条新前缀的更新包括以下步骤： 步骤 101 )将前缀 P插入原特里树 T中， 得到新的特里树 τ，； 步骤 102 )在新特里树 Τ， 中， 找到前缀 Ρ的最长前缀 Q, 所述最长 前缀 Q是在新特里树 Τ， 中离前缀 Ρ所处节点最近的祖先节点所对应的前 缀；
步骤 103 )如果前缀 Ρ是特里树 Τ， 中的非叶子前缀， 则将前缀 Ρ插 入第二前缀集；
步骤 104 )如果 Ρ是特里树 Τ， 中的叶子前缀， 则判断 Q是否是原特 里树 Τ中的非叶子前缀； 如果是， 则将 Ρ插入第一前缀集， 否则将 Q插入 第二前缀集并从第一前缀集中删除 Q, 然后将 Ρ插入第一前缀集。
上述路由更新方法中， 所述删除一条已存在的前缀的更新包括以下步 骤：
步骤 111 )将前缀 Ρ从原特里树 Τ中删除， 得到新的特里树 τ，； 步骤 112 )在原特里树 Τ中找到前缀 Ρ的最长前缀 Q, 所述最长前缀 Q是在原特里树 Τ中离前缀 Ρ所处节点最近的祖先节点所对应的前缀； 步骤 113 )如果前缀 Ρ在特里树 Τ中是非叶子前缀， 则从第二前缀集 中删除 Ρ;
步骤 114 )如果前缀 Ρ在特里树 Τ中是叶子前缀， 则判断 Q 在特里树 Τ， 中是否是非叶子前缀， 如果是， 则从第一前缀集中删除 Ρ ; 否则， 从第一前缀集中删除 Ρ, 然后将 Q插入第一前缀集， 并从第二前缀 集中删除0。
上述路由更新方法中， 所述步骤 2) 根据所述更新操作序列， 在数据 平面中相应地对基于 TCAM的查找引擎进行写操作， 对基于 SRAM的查 找流水线以写气泡的方式执行更新操作。
根据本发明的又一个方面， 还提供了一种路由更新装置， 所述装置包 括：
基于 TCAM的 IP查找引擎， 其用于存储第一前缀集， 所述第一前缀 集包括根据路由器的转发信息库构造的 1比特特里树的所有叶子节点对应 的前缀；
基于 SRAM的 IP查找流水线， 其用于存储第二前缀集， 所述第二前 缀集包括所述特里树的所有中间节点对应的前缀；
更新控制单元， 其用于根据路由器的转发信息库的路由更新， 完成对 路由器控制平面中辅助的 1比特特里树的更新， 以得到对第一前缀集和第 二前缀集的更新操作序列； 以及用于根据所述更新操作序列， 在数据平面 中分别对基于 TCAM的查找引擎中的第一前缀集和基于 SRAM的查找流 水线中的第二前缀集进行更新。
上述的路由更新装置中， 在基于 SRAM的 IP查找流水线中以 1比特 特里树的数据结构存储第二前缀集。
上述的路由更新装置中， 基于 SRAM的 IP查找流水线中的每个流水 级都采用独立的双口 SRAM, 所述双口 SRAM的一个端口只进行读操作， 另一个端口只进行写操作。
上述的路由更新装置中， 所述更新控制单元主要用于根据路由器的转 发信息库的路由更新，采用如上所述的路由更新方法对完成对基于 TCAM 的查找引擎中的第一前缀集和基于 SRAM 的查找流水线中的第二前缀集 进行更新。
与现有技术相比， 本发明的优点在于：
1、 在实现快速 IP查找的同时， 支持快速的增量路由更新。 通过结合 TCAM和 SRAM的特点， 针对其特点分别存储不同类型的前缀， 可以实 现很高的吞吐量， 并同时支持快速的路由更新。 在最坏情况下， 一次路由 更新只需要暂停 IP查找过程 1次 TCAM写操作的时间。
2、 提高了 TCAM的利用率， 并緩解了基于 SRAM的查找流水线存储 空间的不足的问题。 由于在本发明中，在基于 TCAM的查找引擎中存储的 前缀是不相交的叶子前缀，叶子前缀之间不需要遵循任何顺序限制， 因此， 叶子前缀可以以任意顺序存储在 TCAM中的任意位置。灵活的存储方式保 证了 TCAM的利用率可以接近 100% (仍然需要预留适当的空间供进一步 路由更新使用）。而实际存储在基于 SRAM的 IP查找流水线中的重叠前缀 集所需的空间也非常小， 緩解了 FPGA片内 SRAM存储空间不足的问题。 附图说明 以下参照附图对本发明实施例作进一步说明， 其中：
图 1为根据本发明实施例的 IP查找装置的结构示意图；
图 2 ( a ) 为本发明实施例中所使用的 1比特特里树示意图； 图 2 ( b ) 为图 2 ( a ) 所示的特里树的叶子节点对应的不相交前缀集 示意图；
图 2 ( c ) 为对应于重叠前缀集的剩余特里树的示意图；
图 3 ( a ) 为根据本发明实施例的基于 SRAM的 IP查找流水线的结构 示意图；
图 3 ( b ) 为图 3 ( a ) 所示的 IP查找流水线的每个流水级的细节示意 图；
图 4为在图 2 ( a )所示的特里树中插入一条叶子前缀给不相交前缀集 和重叠前缀集的带来的变化的示意图；
图 5为在图 2 ( a )所示的特里树中删除一条叶子前缀给不相交前缀集 和重叠前缀集的带来的变化的示意图；
图 6为根据本发明的实施例的 IP查找装置的理论吞吐量和实际吞吐量 对比示意图；
图 7为用实际路由表仿真的多种基于 TCAM的查找引擎的更新开销对 比图。 具体实施方式
为了使本发明的目的， 技术方案及优点更加清楚明白， 以下结合附图 通过具体实施例对本发明进一步详细说明。 应当理解， 此处所描述的具体 实施例仅仅用以解释本发明， 并不用于限定本发明。
图 1示出了 IP查找装置的一个实施例的架构示意图。 该 IP查找装置 包括两个并行的 IP查找引擎：一个基于 TCAM的 IP查找引擎和一个基于 SRAM的 IP查找流水线。 在基于 TCAM的 IP查找引擎中， 存储的是根据 路由器的转发信息库构造的 1比特特里树的所有叶子前缀， 所述叶子前缀 为特里树的叶子节点所对应的前缀。 在基于 SRAM的 IP查找流水线中存 储的是根据路由器的转发信息库构造的 1比特特里树的所有非叶子前缀， 所述非叶子前缀为特里树的中间节点所对应的前缀。 应指出， 根据路由器 的转发信息库构造的 1比特特里树的中间节点可能对应前缀， 也有可能不 对应任何前缀。 为了描述方便， 下文将 1比特特里树筒称为特里树。 其中， 可以使用本领域普通技术人员所熟知的构造 1比特特里树的方 法来根据路由器的转发信息库构造特里树。 在本实施例中， 为了直观地显 示特里树构造过程， 选取了一个筒单的示例前缀集合 P1-P6, 分别对应于 P1: 0*, P2: 00*, P3: 11*, P4: 100*, P5: 101*, P6: 111*。 图 2 (a)示出了根据该示例前缀集合构造的 1比特特里树。 在该特里树中 以及后续所有附图的特里树中， 灰色节点代表前缀节点 （即， 该节点对应 一个前缀）， 有对应的下一跳信息； 白色节点代表非前缀节点， 没有对应 的下一跳信息。 值得注意的是， 转发信息库中的条目不仅包括前缀， 还包 括对应的下一跳信息。下一跳信息的管理对于路由更新的影响不大， 因此， 为了描述的方便， 本发明中忽略下一跳信息的管理， 转发信息库和前缀集 合这两个术语不加以区分。 在图 2 (a) 所示的特里树中， 前缀 P2、 P4、 P5和 P6均为叶子前缀， 将这些叶子前缀收集到一个叶子前缀集合中。 图 2 ( b )所示的是图 2 (a)的特里树的叶子前缀集合。 由于叶子前缀集合中 的前缀两两不相交， 所以也可以称之为不相交前缀集。 将不相交前缀集存 储到 IP查找装置的基于 TCAM的 IP查找引擎中。
在所有的叶子前缀已经被收集到一个单独的叶子前缀集合之后， 图 2 (a)所示的原始特里树中的所有叶子节点可以删除。 删除掉节点 4、 7、 8 和 9之后， 剩下的特里树可能包含非前缀的叶子节点， 如图 2 (a) 中所示 的节点 5。 这些非前缀的叶子节点不存储任何前缀信息， 也不继续导向有 效的前缀， 因此， 所有的非前缀的叶子节点都可以递归的删除， 直到剩下 的特里树中， 所有的叶子节点都是前缀节点。 最后裁剪后的特里树如图 2 (c)所示。 图 2 (c)所示的特里树中对应的前缀（其中， P1对应 0*, P3 对应 11*), 与图 2 ( b ) 中所示的前缀表示的地址范围有重叠， 例如 P1表 示的地址范围覆盖了 P2表示的地址范围。 同时， 裁剪过的特里树中前缀 之间本身也有可能存在重叠， 因此， 也可以将图 2 ( C ) 中所示的特里树对 应的前缀集合称之为重叠前缀集。 这个重叠前缀集中的前缀是不相交前缀 集中的前缀的子前缀， 例如 P1是 P2的子前缀， P3是 P6的子前缀。 在本 实施例中， 将这个重叠前缀集以 1 比特特里树数据结构存储到 IP查找装 置的基于 SRAM的 IP查找流水线中。 在其他实施例中， 也可以以其他的 特里树数据结构将重叠前缀集存储到 IP查找装置的基于 SRAM的 IP查找 流水线中。 在本实施例中， 可以采用基于 FPGA片内 SRAM的 IP查找流 水线。 对于一个给定的数据包， 其数据包头部送入包头解析模块进行解析， 抽取出目的 IP 地址。 同时， 数据包緩存在数据包緩沖区中等待查询的下 一跳信息。 抽取出目的 IP地址之后， 目的 IP地址被同时送入基于 TCAM 的 IP查找引擎和基于 SRAM的 IP查找流水线进行同时查找。 由于基于 SRAM的查找流水线中存储的前缀为基于 TCAM的查找引擎中存储的前 缀的子前缀， TCAM查找引擎输出的结果具有更高的优先级（代表更长的 前缀）。优先级仲裁模块对 TCAM查找引擎和 SRAM查找流水线的输出结 果进行仲裁。 当只有一个查找引擎输出查找结果时， 优先级仲裁模块直接 输出该结果作为最终的下一跳信息； 当两个查找引擎均输出查找结果时， 优先级仲裁模块选择 TCAM查找引擎输出的结果作为下一跳信息。 最后， 一旦优先级仲裁模块输出下一跳信息， 数据包修改模块从数据包緩沖区中 读取一个数据包， 根据下一跳信息对数据包头部进行相应的修改， 然后将 数据包发送到下一跳信息指定的物理接口。
由于基于 TCAM的 IP查找引擎和基于 SRAM的 IP查找流水线都可 以实现快速查找， 因此本实施例中的 IP查找装置同样能够实现快速的 IP 查找。 而且本实施例中的 IP 查找装置还有效的緩解了现有的基于 FPGA 片内 SRAM的 IP查找流水线中的存储空间不足的问题。 这是因为在该 IP 查找装置的基于 SRAM的 IP查找流水线中， 只存储了重叠前缀集。 在上 文为了方便描述而使用的是一个筒单的示例前缀集合 Pl-P6。 但在使用真 实的骨干网路由器的转发信息库构造特里树并进行划分后， 可以发现， 大 约 90%的前缀为不相交的叶子前缀， 重叠前缀集很小， 其对应的裁剪过的 特里树的节点数为原始特里树节点数的 12%左右（请参考下文中的表 1的 分析结果）。 因此， 实际存储在基于 SRAM的 IP查找流水线中的重叠前缀 集所需的空间非常小。
更重要的是， 本实施例中的 IP 查找装置能够支持快速的增量更新， 因为在该 IP查找装置的基于 TCAM的 IP查找引擎中，只存储了如图 2( b ) 所示的叶子前缀集合（不相交前缀集）。 由于叶子前缀集合中的前缀两两 不相交， 对于一个给定的目的 IP 地址， 最多只能匹配其中的一个前缀。 该不相交前缀集在基于 TCAM的 IP查找引擎中的存储不需要考虑任何顺 序限制， 一条新的前缀可以插入在基于 TCAM的 IP查找引擎中任意可用 的位置， 而不会导致不正确的最长前缀匹配。 可见， 在本发明的实施例中， 在基于 TCAM的 IP查找引擎中的路由更新， 不会导致任何前缀移动； 另 夕卜， 由于该不相交前缀集中的所有前缀天然不相交的， 没有任何前缀被复 制， 因此， 对于一次路由更新， 最坏情况下只需要一次 TCAM写操作即可 完成。
在现有的基于 SRAM的 IP查找流水线中， 写气泡常用于实现增量更 新 (请参考文献： Fast incremental updates for pipelined forwarding engines , INFOCOM 2003 以及文献： Dynamic pipelining: Making IP lookup truly scalable, SIGCOMM 2005 )。 但是在上述现有的方法中， 流水线中使用的 是单口 SRAM, 写气泡有可能导致 IP查找流水线的停顿， 因为 IP查找执 行的是读操作， 路由更新执行的是写操作， 而读、 写操作不可能同时在 SRAM的同一个端口进行。 目前 FPGA中 SRAM普遍具有双口特性， 如 Xilinx公司的 FPGA中的 Block RAM就是双口的。现有的基于双口 SRAM 的 IP流水线设计 (请参考文献： Memory-efficient and scalable virtual routers using FPGA, FPGA 2011 ) , 设计了两条独立的 IP查找流水线， 但是这两 条流水线均进行 IP 查找和路由更新， 虽然提高了性能， 但是每个端口仍 然是同时既做更新又做查找， 并没有解决路由更新对查找的影响。
但是， 在根据本发明实施例的 IP查找装置中， 整体的 IP查找性能取 决于 TCAM的查找性能 （因为一般情况下， 基于 SRAM的查找流水线的 查找性能高于基于 TCAM的查找引擎）。 因此， 在又一个实施例中， 在不 影响整体查找性能的情况下， 为了保证了在基于 SRAM的查找流水线中， 路由更新对 IP查找没有任何影响，在 IP查找装置中采用了基于双口 SRAM 的、 具有独立查找和更新通路的 IP查找流水线。
图 3 ( a ) 示出了基于双口 SRAM的、 具有独立查找和更新通道通路 的 IP查找流水线的一个实施例的结构示意图。 其中， 双口 SRAM的一个 端口专用于 IP 查找， 另一个端口专用于路由更新。 这样， 虽然仍是采用 一条流水线， 但是路由更新和 IP查找互不影响。 图 3 ( b )描述了图 3 ( a ) 所示的每个流水级的具体细节。在如图 3 ( b )所示的流水级中，双口 SRAM 的一个端口只进行读操作， 即在 IP 查找时根据节点地址读出节点内容； 另外一个端口只进行写操作， 即在路由更新时在对应地址处添加或修改节 点内容。 因此， 读、 写操作可以无沖突地同时进行。 这样， 在如图 3 ( a ) 所示的 IP查找流水线中， IP查找和路由更新使用两条不同的数据通路进 行， 从而解决了路由更新对 IP查找的影响。
更具体地， 在该实施例中， 当重叠前缀集对应的特里树存储到基于 SRAM的 IP查找流水线时， 不同层次的节点存储在不同的流水级中。 当 进行 IP查找时， 目的 IP地址从图 3 ( a )所示的第一个流水级开始依次往 后遍历。 在每个流水级中， 根据上一级输出的节点地址（第一个流水级直 接访问地址 0 ), 读出当前流水级中访问的节点信息。 如果当前节点为前缀 节点， 则更新最长前缀的内容。 然后， 根据目的 IP 地址对应比特的取值 ( 0或 1 ), 以及当前访问节点的左、 右孩子指针情况， 判断应该遍历的当 前节点的孩子节点在下一流水级中的地址。 然后， 使用孩子节点的地址访 问下一个流水级。 当 IP 查找从最后一个流水级退出时， 记录的最长前缀 即为该目的 IP 地址匹配的最长前缀。 当进行路由更新时， 路由器控制平 面的软件中会计算实现当前更新的写气泡。 值得注意的是， 写气泡本身并 不包含任何数据。 在写气泡注入流水线之前， 路由更新导致的在各个流水 级中需要修改的数据及其地址事先由控制平面的软件计算好， 然后存储在 每个流水级对应的存储写气泡数据的先进先出存储器（ Write Bubble FIFO ) 中 （如图 3 ( b )所示）。 一个写气泡注入流水级后， 依次访问每个流水级。 当访问一个具体的流水级时，如果 Write Bubble FIFO中当前内容的有效标 志为 1 , 则将当前内容中的数据写入其对应的地址。 通过这种方法， 写气 泡不需要等待数据， 访问每个流水级只需要一个时钟周期， 这意味着写气 泡遍历流水级的速度和 IP 查找遍历流水级的速度相同。 因此， 可以支持 快速的 IP查找和路由更新。
另外， 当使用基于 1 比特特里树作为 IP查找流水线的数据结构时， 在最坏情况下， 一次路由更新只需要一个写气泡 （请参考文献： Dynamic pipelining: Making IP lookup truly scalable, SIGCOMM 2005 ), 因此， IP查 找和路由更新同时进行时， IP查找不会访问到一个不一致的特里树状态。 即使某个 IP查找和写气泡同时访问同一个流水级的同一个节点时， IP查 找总是读出修改前的节点内容（请参考 Xilinx公司 FPGA片内 SRAM的 READ_FIRST特性）， 并且， 这种读优先的特性在整个遍历的过程中一直 保持。 因此， 即使路由更新和 IP查找同时进行， IP查找总是访问一棵完 整的特里树， 不会发生错误的最长前缀匹配。
由此可见， 在该实施例中 IP 查找装置中的路由更新的开销非常小， 因为基于 SRAM的 IP查找流水线中的路由更新对 IP查找在性能上没有任 何影响； 而在基于 TCAM的 IP查找引擎中， 一次路由更新在最坏情况下 只需要进行一次 TCAM写操作。 而且与现有的基于双口 SRAM的两条流 水线结构相比， 本实施例中具有独立查找和更新通路的流水线结构筒单、 实现方便。
在又一个实施例中， 还提供了一种基于上述 IP查找装置的 IP查找方 法， 该方法首先将根据路由器的转发信息库所构造的特里树分割成一个不 相交的叶子前缀集合和一个重叠的前缀集合； 将不相交的叶子前缀集合存 储在基于 TCAM的查找引擎中，将重叠的前缀集合以特里树的数据结构存 储在基于 SRAM的查找流水线中； 同时在基于 TCAM的查找引擎和基于 SRAM的查找流水线中进行 IP查找。 主要包括以下步骤：
步骤 1 , 分割根据路由器的转发信息库所构造的特里树。
首先， 将所构造的特里树的所有叶子前缀收集到一个集合（即不相交 前缀集）。 接着将原始特里树中的所有叶子节点删除， 并从剩下的特里树 中递归删除所有的非前缀叶子节点， 直到裁剪后的特里树中， 所有的叶子 节点都是前缀节点。 最后将裁剪后的特里树对应的所有前缀收集到另一个 集合（即重叠前缀集）
步骤 2, 将不相交前缀集存储到基于 TCAM的查找引擎中， 将重叠前 缀集以特里树的数据结构存储到基于 SRAM的查找流水线中。
步骤 3 , 同时在基于 TCAM的查找引擎和基于 SRAM的查找流水线 中进行 IP查找， 当在基于 TCAM的查找引擎和基于 SRAM的查找流水线 中只得到一个查找结果时， 直接将该查找结果作为最终的下一跳信息； 当 在基于 TCAM的查找引擎和基于 SRAM的查找流水线中均得到查找结果 时， 选择基于 TCAM的查找引擎中的查找结果作为下一跳信息。
在又一个实施例中， 还提出了一种用于上述 IP 查找装置的路由更新 方法。 在上述 IP 查找装置的实例中， 一次针对原始的转发信息库的路由 更新， 可能导致基于 TCAM的查找引擎和基于 SRAM的查找流水线中都 产生路由更新。 一次路由更新可以分为三类： （1 )插入一条新前缀； （2 ) 删除一条已存在的前缀； （3 )修改一条已存在的前缀。 第三类更新的实现 非常筒单， 因为该类更新仅仅是对已有前缀的下一跳信息的修改， 不会改 变原始特里树的性质。 然而， 前面两类更新相对复杂， 插入或者删除一条 前缀均可能导致原始特里树形状的改变， 从而同时影响不相交前缀集和重 叠前缀集。
通常， 在路由器的控制平面维护一个辅助的 1比特特里树， 用于记录 前缀存储在上述 IP查找装置中的位置。 应指出这个 1 比特特里树是在路 由器的控制平面中 （比如： CPU中）进行维护的， 用于辅助路由更新。 针 对这个辅助 1比特特里树的任何操作， 都不会影响转发过程， 因为转发引 擎是在数据平面中。
在该实施例中， 一次完整的路由更新操作包括两个阶段。 第一个阶段 完成对路由器控制平面中辅助的特里树的更新。 该阶段的主要目的是找到 该路由更新对不相交前缀集和重叠前缀集的影响。 根据第一个阶段的结 果， 第二个阶段主要分别针对基于 TCAM的查找引擎和基于 SRAM的查 找流水线，在数据平面中具体实施更新操作（针对 TCAM的写操作以及针 对 SRAM的写气泡）。 下面结合图 4和图 5来更清楚地介绍上述路由更新 过程。
图 4所示的是在图 2 ( a ) 所示的特里树中插入一条新叶子前缀 P7的 场景。 在前缀 P7插入之前， 前缀 P2、 P4、 P5和 P6为叶子前缀， 属于不 相交前缀集， 应该存储在基于 TCAM的查找引擎中； 前缀 P1和 P3为中 间节点存储的前缀， 属于重叠前缀集， 应该以特里树的方式存储到基于 SRAM的 IP查找流水线中。在前缀 P7插入之后， P7所在的节点为一个新 的叶子节点， 因此， 前缀 P7在更新后的特里树中变成一个新的叶子前缀。 另外， 由于前缀 P7的插入， 之前的叶子前缀 P2变成了非叶子前缀。 前缀 P7的插入给不相交前缀集和重叠前缀集带来的改变可以归纳为：（ 1 )前缀 P2应该插入到重叠前缀集中； （2 ) 前缀 P2应该从不相交前缀集中删除； ( 3 )前缀 P7应该插入到不相交前缀集。 在这些改变在控制平面中被发现 后， 前缀 P2应该以写气泡的方式插入到基于 SRAM的 IP查找流水线中， 前缀 P7应该覆盖基于 TCAM的查找引擎中已经存储的前缀 P2。叶子前缀 在基于 TCAM的查找引擎中的存储位置，可以记录在控制平面的辅助的 1 比特特里树的叶子节点中。
图 5所示的是在图 2 ) 所示的特里树中删除一条已存在的前缀 P2 的场景。 在删除前缀 P2之前， 前缀 P2、 P4、 P5和 P6为叶子前缀， 属于 不相交前缀集， 应该存储在基于 TCAM的查找引擎中； 前缀 P1和 P3为 中间节点存储的前缀， 属于重叠前缀集， 应该以特里树的方式存储到基于 SRAM的 IP查找流水线中。 在删除前缀 P2之后， 之前的非叶子前缀 P1 变成了叶子前缀。 前缀 P2 的删除给不相交前缀集和重叠前缀集带来的改 变可以归纳为： （ 1 )前缀 P2应该从不相交前缀集中删除； （2 )前缀 P1应 该插入到不相交前缀集； （3 ) 前缀 P1应该从重叠前缀集中删除。 在这些 改变在控制平面中被发现后， 前缀 P1应该覆盖基于 TCAM的查找引擎中 已经存储的前缀 P2。 叶子前缀在基于 TCAM的查找引擎中的存储位置， 可以记录在控制平面的辅助的 1比特特里树的叶子节点中。 另外， 前缀 P1 在重叠前缀集中的删除操作， 应该以写气泡的方式在基于 SRAM的 IP查 找流水线中进行。
图 4和图 5所示的仅仅是两种典型的更新场景， 其它类型的插入和删 除操作可以类似地完成。 其中， 所采用的前缀插入算法为：
输入： 特里树 T, 以及待插入的前缀 P
输出： 插入前缀 P给不相交前缀集 S1和重叠前缀集 S2带来 的变化
1 将前缀 p插入特里树 τ中， 得到新的特里树 τ
2 在特里树 T中， 找到前缀 P的最长前缀 Q
3 如果 P是特里树 T中的非叶子前缀
4 将 P插入集合 S2 ;
5 否则, 如果 P是特里树 T中的叶子前缀
6 如果 Q是特里树 T中的非叶子前缀
7 将 P插入集合 S1 ;
8 否则, 如果 Q是特里树 T中的叶子前缀
9 将 Q插入集合 S2 ;
10 将 Q从集合 si删除， 然后将 p插入集合 si；
其中，最长前缀 Q是特里树中离 P所处节点最近的祖先节点所对应的 前缀， 也就是说如果 P所处节点的父节点是前缀节点， 那么， 其父节点对 应的前缀就是最长前缀 Q; 如果其父节点不是前缀节点， 那么， 继续向上， 找到其最近的包含前缀信息的祖先节点， 该祖先节点对应的前缀就是最长 前缀 Q。
所采用的前缀删除算法如下：
输入： 特里树 T, 以及待删除的前缀 P
输出： 删除前缀 P给不相交前缀集 S1和重叠前缀集
S2带来的变化 1 将前缀 p从特里树 τ中删除, 裁剪后得到新的特里树 τ
2 在特里树 Τ中找到前缀 Ρ的最长前缀 Q
3 如果 ρ在特里树 τ中是非叶子前缀
4 从集合 S2 中删除 Ρ;
5 否则, 如果前缀 Ρ在特里树 Τ中是叶子前缀
6 如果 Q在特里树 Γ中是非叶子前缀
7 从集合 中删除 Ρ;
8 否则, 如果 Q在特里树 Τ中是叶子前缀
9 从集合 中删除 Ρ, 然后将 Q插入集合 S1 ;
10 从集合 S2 中删除 上述前缀插入和删除算法都在路由器的控制平面中完成， 时间复杂度 为 O( )， 其中， /为待更新的前缀的长度。 从上述两个算法可以得出如下结 论： 一次路由更新在最坏情况下对每个查找引擎只产生一次写操作（一次
TCAM写操作和一个写气泡 ),更新开销非常小（需要注意的是，在 TCAM 中插入一条前缀和删除一条可以合并成一次写操作。 例如， 在前缀插入算 法的步骤 10中， 在不相交前缀集中删除前缀 Q和插入前缀 P, 可以用一 次写操作完成： 将前缀 P插入到前缀 Q存储的位置（即： 用前缀 P覆盖前 缀 Q ) )。
另外， 对上述 IP查找装置中的基于 TCAM的查找引擎和基于 SRAM 的查找流水线的写操作之间的顺序必须按照上述算法的步骤的顺序， 以防 止不正确的最长前缀匹配。 例如， 在前缀插入算法的步骤 9和步骤 10的 执行顺序， 必须保持算法中描述的顺序， 否则， 在两个写操作执行的间隙 时间内， 前缀 Q将会在整个 IP查找装置中消失一段时间， 影响整个路由 表的完整性， 可能导致不正确的最长前缀匹配。
在本发明的又一个实施例中， 还提供了一种路由更新装置， 所述装置 包括如上文所述的基于 TCAM的 IP查找引擎和基于 SRAM的 IP查找流 水线以及更新控制单元。 其中， 更新控制单元主要用于根据路由器的转发 信息库的路由更新，采用如上文所述的路由更新方法对完成对基于 TCAM 的查找引擎中的不相交前缀集和基于 SRAM 的查找流水线中的重叠前缀 集的更新。
性能分析 发明人设计了一系列实验来评估上述实施例所提供的 IP 查找装置的 有效性， 以及与相关技术相比的优越性。
实验用的路由表文件是从 RIPE RIS项目 （请参考： RIS RAW Data, http://www.ripe.net/data-tools/stats/ris/ris-raw-data ) 中下载的 14个 IPv4路 由表。 一般情况下， 所有的路由表的前缀都大致相同 （因为每个骨干路由 器对全网的视图基本上是一样的）。 使用上文所述的特里树分割方法对这 些路由表进行处理， 得到的结果如表 1所示。
表 1
Figure imgf000017_0001
表 1所示的是 14个路由表的统计结果。 从表 1 中可以看出， 对于所 有的路由表， 超过 90%的前缀是叶子前缀， 均被包含在不相交前缀集中。 最后裁剪过的特里树的节点数为原始特里树节点数的 12%左右。基于该数 据分析结果， 可以得出如下结论：
( 1 ) 将根据路由器的转发信息库构造的特里树进行划分后， 大部分 ( 90% )的前缀存放于基于 TCAM的查找引擎中。 同时， 由于这些前缀为 不相交的叶子前缀， 存储在基于 TCAM 的查找引擎中时没有任何顺序限 制。 该特性保证了基于 TCAM的查找引擎中路由前缀的快速更新；
( 2 )在删除了叶子节点之后， 基于 SRAM的 IP查找流水线所需要存 储的特里树节点数显著的降低（只有原始特里树节点数的 12%左右）。 因 此， FPGA片内 SRAM大小不足的问题得到了很大程度上的緩解。
图 6所示的是根据采用上述实施例提供的 IP查找装置在一个具有四 个千兆网络接口的 PEARL平台（请参考： PEARL: A programmable virtual router platform, IEEE Communications Magazine 2011 ) 上实现的吞吐量。 PEARL平台配有一个 Xilinx公司的 Virtex-5系列 XC5VLX110T-1 FPGA, 以及一个 IDT公司的 IDT75K72100 TCAM。基于 SRAM的 IP查找流水线 在 Xilinx FPGA中实现，基于 TCAM的 IP查找引擎基于 IDT的 TCAM实 现。 FPGA布局布线后的时序报告显示， FPGA内部基于 SRAM的 IP查找 流水线的最大时钟频率为 297MHz (意味着该流水线的最大吞吐量为 297 MLPS (百万次查找每秒））。 同时， 该基于 TCAM的 IP查找引擎的最大吞 吐量为 250 MLPS, 因此， 该实施例的最大理论吞吐为 250 MLPS, 远远超 过了 100G以太网的吞吐量需求 （在 100G以太网中， IP查找的最大吞吐 量需求大约为 148 MLPS )。 然而， 由于 PEARL硬件平台只有四个千兆物 理接口， 受限于真实物理接口的带宽， 本发明的实施例中能够测试出的最 大吞吐量大约为 5.95 MLPS。 图 6所示的即为基于 PEARL平台实现的 IP 查找装置的实际测试吞吐量与该平台能否获得的理论最大吞吐量 （4个千 兆线速） 的对比图。 从图 6 中可以看出， 该实施例中 IP查找装置的实际 吞吐量能够达到 4个千兆接口的线速。
而且， 该 IP 查找装置还有一个显著的优点是支持快速的路由更新。 为了全面比较本发明中 IP 查找装置的更新开销与之前其它技术 ( PLO_OPT/CAO_OPT、 MIPS以及之前基于写气泡实现路由更新的技术） 的更新开销的大小，在实验中使用每次更新的 TCAM写操作次数，作为基 于 TCAM的 IP查找引擎的更新开销大小的度量标准； 使用每个写气泡造 成的查找过程停顿的时钟周期数， 作为基于 SRAM的 IP查找流水线的更 新开销大小的度量标准。
表 2为各种基于 TCAM的查找引擎的更新开销（以平均每次更新所需 的 TCAM写操作次数来进行表示）在理论上的对比结果。 在最好情况下， PLO_OPT技术和 CAO_OPT技术的更新开销为一次更新只需要 1次 TCAM 写操作，而 MIPS方法和本发明中的 IP查找装置的更新开销为一次更新只 需要 0次 TCAM写作操作。 然而， 在最坏情况下， 各种技术更新开销的差 异较大。 在 PLO_OPT技术中， 前缀长度顺序需要保持， 并且 TCAM的空 闲空间维护在 TCAM中部，因此一次更新在最坏情况下需要 W/2次 TCAM 写操作 （其中， w 为前缀的最大长度， 在 IPv4 的情况下， W=32 )。 在 CAO_OPT技术中， 前缀的链式顺序需要保持， 并且 TCAM的空闲空间维 护在 TCAM中部， 因此一次更新在最坏情况下需要 D/2次 TCAM写操作 (其中， D为最长链的长度，在 IPv4的情况下， D理论上的最大值为 32 )。 MIPS技术使用叶推（leaf pushing )技术将原始的前缀集合转换为一个不 相交的前缀集合， 从而避免前缀之间的任何顺序要求。 然而， 叶推可能导 致前缀复制。 在最坏情况下， 一个前缀可能被复制 f—1次。 在本发明的 IP 查找装置中，存储在 TCAM中的前缀集合是自然不相交的前缀， 既不需要 维护任何前缀顺序， 也没有任何前缀被复制， 因此最坏情况下一次路由更 新也只需要 1次 TCAM写操作。
表 2
Figure imgf000019_0001
图 7为用实际路由表仿真的运行时更新开销（以平均每次更新所需的 TCAM写操作次数来进行表示）对比图， 使用的路由表文件 rrcOO和一个 小时的路由更新文件均从 RIPE RIS项目获取（请参考： RIS RAW Data, http://www.ripe.net/data-tools/stats/ris/ris-raw-data )» 图 7中的四条曲线分别 表示四种方法的平均更新开销随着更新的前缀数目的增加而变化的情况。 在本发明的 IP查找装置中， 平均更新开销一直低于 1次 TCAM写操作每 秒。 该实验结果可以用如下事实来解释： 当一次路由更新发生在一个叶子 前缀上时，只需要 1次 TCAM写操作； 当一次路由更新发生在一个非叶子 前缀时， 需要 0次 TCAM写操作。 因此， 一次路由更新所需的平均 TCAM 写操作一直低于 1次。 从图 7所示的曲线可以看出， 本发明的 IP查找装 置中， 一次路由更新平均需要的 TCAM写操作次数远低于其它三种方法。 更为重要的是，最坏情况下一次路由更新所需的 TCAM写操作次数， 直接 决定了 IP查找装置中数据包緩沖区的大小 （为了防止路由更新时 IP查找 性能下降导致的丟包， 需要用一个数据包緩沖区緩存更新时等待查找的数 据包）。 而本发明的 IP查找装置中， 用实际路由表仿真的最坏情况下的更 新开销（一次路由更新只需要 1次 TCAM写操作 )远远低于其它三种方法 (如表 3所示， 表 3为用实际路由表仿真的更新开销对比结果）。
表 3
Figure imgf000020_0001
另外， 在现有的基于写气泡实现路由更新的技术中 （参考文献 Fast incremental updates for pipelined forwarding engines , INFOCOM 2003和文 献 Dynamic pipelining: Making IP lookup truly scalable, SIGCOMM 2005 ), 每个写气泡在最坏情况下会导致路由查找停顿一个时钟周期。 在本发明的 实施例中，通过采用基于双口的具备独立查找和更新数据通路的 SRAM流 水线，彻底消除了基于 SRAM的 IP查找流水线中路由更新对 IP查找的影 响。
综上所述，本发明实施例的 IP查找装置及其 IP查找和路由更新方法， 在保证快速查找的同时， 实现了快速更新。 一次路由更新最坏情况下只会 产生一次 TCAM写操作， 同时， 对基于 SRAM的 IP查找流水线部分没有 任何影响。 路由更新开销远远低于现有相关技术。
虽然本发明已经通过优选实施例进行了描述， 然而本发明并非局限于 这里所描述的实施例， 在不脱离本发明范围的情况下还包括所作出的各种 改变以及变化。

Claims

权 利 要 求
1. 一种 IP查找装置， 包括：
基于 TCAM的 IP查找引擎， 其用于存储第一前缀集， 所述第一前缀 集包括根据路由器的转发信息库构造的 1比特特里树的所有叶子节点对应 的前缀；
基于 SRAM的 IP查找流水线， 其用于存储第二前缀集， 所述第二前 缀集包括所述特里树的所有中间节点对应的前缀；
优先级仲裁模块， 其用于对基于 TCAM的 IP查找引擎和基于 SRAM 的 IP查找流水线的输出结果进行仲裁， 以输出下一跳信息。
2.根据权利要求 1所述的 IP查找装置， 其中， 所述第二前缀集以 1比 特特里树的数据结构存储在基于 SRAM的 IP查找流水线中。
3.根据权利要求 1所述的 IP查找装置， 其中， 对基于 TCAM的 IP查 找引擎的输出结果比基于 SRAM的 IP查找流水线的输出结果具有更高的 优先级。
4.根据权利要求 1所述的 IP查找装置， 其中当基于 TCAM的 IP查找 引擎和基于 SRAM的 IP查找流水线只有一个输出结果时， 优先级仲裁模 块直接选择该输出结果作为下一跳信息， 否则， 选择基于 TCAM的 IP查 找引擎的输出结果作为下一跳信息。
5.根据权利要求 1、 2、 3或 4所述的 IP查找装置， 其中基于 SRAM 的 IP 查找流水线中的每个流水级都采用独立的双口 SRAM, 所述双口 SRAM的一个端口只进行读操作， 另一个端口只进行写操作。
6.—种基于如上述任一权利要求所述的 IP查找装置的 IP查找方法， 所述方法包括：
步骤 1 )在接收到待查询的数据包的目的 IP地址后， 同时将其送入基 于 TCAM的查找引擎和基于 SRAM的查找流水线中进行查找；
步骤 2 ) 当步骤 1 ) 只得到一个查找结果时， 直接将该结果作为下一 跳信息； 当步骤 1 )得到两个查找结果时， 选择基于 TCAM的查找引擎所 输出的查找结果作为下一跳信息。
7.—种基于如权利要求 1、 2、 3、 4或 5所述的 IP查找装置的路由更 新方法， 所述方法包括：
步骤 1 )基于路由器的转发信息库的路由更新， 完成对路由器控制平 面中辅助的 1比特特里树的更新， 得到对第一前缀集和第二前缀集的更新 操作序列；
步骤 2 )根据所述更新操作序列， 针对基于 TCAM的查找引擎和基于 SRAM的查找流水线， 在数据平面中分别执行相应的更新操作。
8.根据权利要求 7所述的路由更新方法， 所述步骤 1 ) 中对路由器控 制平面中辅助的 1 比特特里树的更新包括（a )插入一条新前缀， （b )删 除一条已存在的前缀， 以及 （c )修改一条已存在的前缀。
9.根据权利要求 8所述的路由更新方法， 所述插入一条新前缀的更新 包括以下步骤：
步骤 101 )将前缀 P插入原特里树 T中， 得到新的特里树 ;
步骤 102 )在新特里树 T，中， 找到前缀 P的最长前缀 Q, 所述最长前 缀 Q是在新特里树 T，中离前缀 P所处节点最近的祖先节点所对应的前缀； 步骤 103 )如果前缀 P是特里树 T，中的非叶子前缀， 则将前缀 P插入 第二前缀集；
步骤 104 )如果 P是特里树 T，中的叶子前缀， 则判断 Q是否是原特里 树 T中的非叶子前缀； 如果是， 则将 P插入第一前缀集， 否则将 Q插入第 二前缀集并从第一前缀集中删除 Q, 然后将 P插入第一前缀集。
10.根据权利要求 8所述的路由更新方法， 所述删除一条已存在的前缀 的更新包括以下步骤：
步骤 111 )将前缀 P从原特里树 T中删除， 得到新的特里树 ;
步骤 112 )在原特里树 T中找到前缀 P的最长前缀 Q, 所述最长前缀 Q 是在原特里树 T中离前缀 P所处节点最近的祖先节点所对应的前缀；
步骤 113 )如果前缀 P在特里树 T中是非叶子前缀， 则从第二前缀集中 删除 P;
步骤 114 )如果前缀 P在特里树 T中是叶子前缀，则判断 Q 在特里树 T， 中是否是非叶子前缀， 如果是， 则从第一前缀集中删除 Ρ； 否则， 从第一前缀集中删除 Ρ, 然后将 Q插入第一前缀集， 并从第二前缀 集中删除0。
11.根据权利要求 7所述的路由更新方法，所述步骤 2) 根据所述更新操 作序列，在数据平面中相应地对基于 TCAM的查找引擎进行写操作，对基 于 SRAM的查找流水线以写气泡的方式执行更新操作。
12.—种路由更新装置， 所述装置包括：
基于 TCAM的 IP查找引擎， 其用于存储第一前缀集， 所述第一前缀 集包括根据路由器的转发信息库构造的 1比特特里树的所有叶子节点对应 的前缀；
基于 SRAM的 IP查找流水线， 其用于存储第二前缀集， 所述第二前 缀集包括所述特里树的所有中间节点对应的前缀；
更新控制单元， 其用于根据路由器的转发信息库的路由更新， 完成对 路由器控制平面中辅助的 1比特特里树的更新， 以得到对第一前缀集和第 二前缀集的更新操作序列； 以及用于根据所述更新操作序列， 在数据平面 中分别对基于 TCAM的查找引擎中的第一前缀集和基于 SRAM的查找流 水线中的第二前缀集进行更新。
13.根据权利要求 12所述的路由更新装置， 其中， 在基于 SRAM的 IP 查找流水线中以 1比特特里树的数据结构存储第二前缀集。
14.根据权利要求 12所述的路由更新装置， 其中， 基于 SRAM的 IP 查找流水线中的每个流水级都采用独立的双口 SRAM ,所述双口 SRAM的 一个端口只进行读操作， 另一个端口只进行写操作。
15.根据权利要求 12、 13或 14所述的路由更新装置， 其中所述更新控 制单元对路由器控制平面中辅助的 1 比特特里树的更新包括（a )插入一 条新前缀， （b ) 删除一条已存在的前缀， 以及 （c )修改一条已存在的前 缀。
16.根据权利要求 15所述的路由更新装置， 所述更新控制单元以如下 方式插入一条新前缀：
( 101 )将前缀 P插入原特里树 T中， 得到新的特里树 T，；
( 102 )在新特里树 Τ，中， 找到前缀 Ρ的最长前缀 Q, 所述最长前缀 Q是在新特里树 Τ，中离前缀 Ρ所处节点最近的祖先节点所对应的前缀；
( 103 )如果前缀 Ρ是特里树 Τ，中的非叶子前缀， 则将前缀 Ρ插入第 二前缀集；
( 104 )如果 Ρ是特里树 Τ，中的叶子前缀， 则判断 Q是否是原特里树 Τ中的非叶子前缀； 如果是， 则将 Ρ插入第一前缀集， 否则将 Q插入第二 前缀集并从第一前缀集中删除 Q, 然后将 Ρ插入第一前缀集。
17.根据权利要求 15所述的路由更新装置， 所述更新控制单元以如下 方式删除一条已存在的前缀： ( 111 )将前缀 P从原特里树 T中删除， 得到新的特里树 τ，；
( 112 )在原特里树 Τ中找到前缀 Ρ的最长前缀 Q, 所述最长前缀 Q 是在原特里树 Τ中离前缀 Ρ所处节点最近的祖先节点所对应的前缀；
( 113 )如果前缀 Ρ在特里树 Τ中是非叶子前缀， 则从第二前缀集中 删除 Ρ;
( 114 )如果前缀 Ρ在特里树 Τ中是叶子前缀，则判断 Q 在特里树 Τ， 中是否是非叶子前缀， 如果是， 则从第一前缀集中删除 Ρ； 否则， 从第一前缀集中删除 Ρ, 然后将 Q插入第一前缀集， 并从第二前缀 集中删除0。
18.根据权利要求 12所述的路由更新装置， 其中， 所述更新控制单元在 数据平面中以对基于 TCAM 的查找引擎进行写操作的方式对第一前缀集 进行更新；以及以写气泡的方式对基于 SRAM的查找流水线中的第二前缀 集进行更新。
PCT/CN2011/001725 2011-09-23 2011-10-14 Ip查找方法和装置以及路由更新方法和装置 WO2013040730A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201110286512.5A CN102307149B (zh) 2011-09-23 2011-09-23 Ip查找方法和装置以及路由更新方法和装置
CN201110286512.5 2011-09-23

Publications (1)

Publication Number Publication Date
WO2013040730A1 true WO2013040730A1 (zh) 2013-03-28

Family

ID=45380961

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/001725 WO2013040730A1 (zh) 2011-09-23 2011-10-14 Ip查找方法和装置以及路由更新方法和装置

Country Status (2)

Country Link
CN (1) CN102307149B (zh)
WO (1) WO2013040730A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105721475A (zh) * 2016-02-24 2016-06-29 北京浩瀚深度信息技术股份有限公司 一种基于fpga与tcam的域名封堵方法
CN112134805A (zh) * 2020-09-23 2020-12-25 中国人民解放军陆军工程大学 基于硬件实现的快速路由更新电路结构及更新方法
CN116319555A (zh) * 2023-05-22 2023-06-23 中国科学技术大学 一种面向虚拟专用网络的路由转发方法
CN117150095A (zh) * 2023-09-12 2023-12-01 北京云枢创新软件技术有限公司 层次结构树节点的查找方法、电子设备和介质

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103051543B (zh) * 2012-11-01 2015-09-09 广州键智桥网络技术有限公司 一种路由前缀的处理、查找、增加及删除方法
US10021026B2 (en) 2013-01-31 2018-07-10 Hewlett Packard Enterprise Development Lp Incremental update of a shape graph
CN106416152B (zh) 2014-06-10 2019-09-27 华为技术有限公司 一种查找装置、查找配置方法和查找方法
CN105791132B (zh) * 2014-12-17 2019-08-06 深圳市中兴微电子技术有限公司 一种基于多路搜索树路由查找的表项更新方法及装置
CN105791163B (zh) * 2014-12-26 2019-09-24 南京中兴软件有限责任公司 更新处理方法及装置
CN104901890B (zh) * 2015-06-24 2018-01-02 上海斐讯数据通信技术有限公司 一种sdn的路由生成、匹配方法和系统
CN105763454B (zh) * 2016-02-25 2018-11-27 比威网络技术有限公司 基于二维路由策略的数据报文转发方法及装置
CN107222401B (zh) * 2017-05-05 2020-07-24 大连理工大学 一种基于tcam的路由查找系统及其方法
CN109831384B (zh) * 2017-11-23 2021-08-03 华为技术有限公司 名字查找方法及路由器
CN112804153A (zh) * 2020-12-30 2021-05-14 中国科学院计算机网络信息中心 一种面向gpu加速ip查找的更新方法及系统
CN114745327B (zh) * 2022-06-10 2022-08-26 鹏城实验室 业务数据转发方法、装置、设备及存储介质
CN116208553A (zh) * 2023-03-13 2023-06-02 苏州盛科通信股份有限公司 扩大vrf路由表项的芯片实现方法及应用

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1655534A (zh) * 2005-02-25 2005-08-17 清华大学 核心路由器上支持访问控制列表功能的双栈兼容路由查找器
CN101005461A (zh) * 2007-01-16 2007-07-25 中兴通讯股份有限公司 一种IPv6路由表查找、转发的方法
KR20080006100A (ko) * 2006-07-11 2008-01-16 중앙대학교 산학협력단 인터넷 주소 검색을 위한 트리 레벨을 사용한 이진 검색구조
CN101515900A (zh) * 2009-04-13 2009-08-26 武汉烽火网络有限责任公司 基于前缀覆盖级别的二分ip路由查找方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1787477A (zh) * 2004-12-09 2006-06-14 北京三星通信技术研究有限公司 IPv6路由表的查找方法
CN101631086B (zh) * 2009-08-10 2012-09-26 武汉烽火网络有限责任公司 并行ip路由查找的路由表分区和放置方法
CN101631085A (zh) * 2009-08-10 2010-01-20 武汉烽火网络有限责任公司 一种基于阈值的自适应路由缓存方法
WO2011097385A2 (en) * 2010-02-03 2011-08-11 University Of Florida Research Foundation, Inc. Duo-dual tcam architecture for routing tables with incremental update

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1655534A (zh) * 2005-02-25 2005-08-17 清华大学 核心路由器上支持访问控制列表功能的双栈兼容路由查找器
KR20080006100A (ko) * 2006-07-11 2008-01-16 중앙대학교 산학협력단 인터넷 주소 검색을 위한 트리 레벨을 사용한 이진 검색구조
CN101005461A (zh) * 2007-01-16 2007-07-25 中兴通讯股份有限公司 一种IPv6路由表查找、转发的方法
CN101515900A (zh) * 2009-04-13 2009-08-26 武汉烽火网络有限责任公司 基于前缀覆盖级别的二分ip路由查找方法

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105721475A (zh) * 2016-02-24 2016-06-29 北京浩瀚深度信息技术股份有限公司 一种基于fpga与tcam的域名封堵方法
CN112134805A (zh) * 2020-09-23 2020-12-25 中国人民解放军陆军工程大学 基于硬件实现的快速路由更新电路结构及更新方法
CN116319555A (zh) * 2023-05-22 2023-06-23 中国科学技术大学 一种面向虚拟专用网络的路由转发方法
CN116319555B (zh) * 2023-05-22 2024-01-09 中国科学技术大学 一种面向虚拟专用网络的路由转发方法
CN117150095A (zh) * 2023-09-12 2023-12-01 北京云枢创新软件技术有限公司 层次结构树节点的查找方法、电子设备和介质
CN117150095B (zh) * 2023-09-12 2024-03-22 北京云枢创新软件技术有限公司 层次结构树节点的查找方法、电子设备和介质

Also Published As

Publication number Publication date
CN102307149B (zh) 2014-05-07
CN102307149A (zh) 2012-01-04

Similar Documents

Publication Publication Date Title
WO2013040730A1 (zh) Ip查找方法和装置以及路由更新方法和装置
JP5529976B2 (ja) 高速ｉｐルックアップのためのシストリック・アレイ・アーキテクチャ
Ravikumar et al. TCAM architecture for IP lookup using prefix properties
US9871727B2 (en) Routing lookup method and device and method for constructing B-tree structure
Kumar et al. CAMP: fast and efficient IP lookup architecture
CN110808910B (zh) 一种支持QoS的OpenFlow流表节能存储架构及其方法
Van Lunteren Searching very large routing tables in wide embedded memory
EP1551141A1 (en) Apparatus and method using hashing for efficiently implementing an IP lookup solution in hardware
Fu et al. Efficient IP-address lookup with a shared forwarding table for multiple virtual routers
JP2005513895A (ja) ネットワーク・プロセッサおよびコンピュータ・システム用ハイブリッド・サーチ・メモリ
CN103428093A (zh) 一种基于名字路由前缀存储、匹配及更新方法与装置
Le et al. Memory-efficient and scalable virtual routers using FPGA
Luo et al. A hybrid IP lookup architecture with fast updates
Luo et al. A hybrid hardware architecture for high-speed IP lookups and fast route updates
CN107454142A (zh) 一种内容路由器的非阻塞内容缓存方法及装置
Le et al. Scalable high throughput and power efficient ip-lookup on fpga
Luo et al. A trie merging approach with incremental updates for virtual routers
Jiang et al. Parallel IP lookup using multiple SRAM-based pipelines
WO2015032214A1 (zh) 一种同时支持IPv4和IPv6的高速路由查找方法及装置
CN110138661A (zh) 基于神经网络的命名数据网内容存储池
Chang et al. LayeredTrees: Most specific prefix-based pipelined design for on-chip IP address lookups
Jiang et al. Multi-terabit IP lookup using parallel bidirectional pipelines
Erdem et al. Value-coded trie structure for high-performance IPv6 lookup
Erdem et al. High-performance ip lookup engine with compact clustered trie search
van Lunteren Searching very large routing tables in fast SRAM

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11872615

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11872615

Country of ref document: EP

Kind code of ref document: A1