JP2001517024A - Method and system for fast routing lookup - Google Patents

Abstract

(57) Abstract: A method of IP routing lookup in a routing table that includes an entry of an arbitrary length prefix with associated next hop information in a next hop table to determine where to forward an IP datagram In, the representation of the routing table is stored in the form of a complete prefix tree (7) defined by the prefixes of all routing table entries. In addition, a representation of the bit vector (8) containing the data of the cut of the prefix tree (7) at the current depth (D) and an array of pointers containing the next hop table and the index to the next level chunk And are saved. The bit vector (8) is divided into bit masks and the representation of the bit mask is stored in a map table. Thereafter, an array of codewords encoding each row index into a map table and pointer offset, and an array of base addresses are stored. Finally, a lookup is performed.

Description

DETAILED DESCRIPTION OF THE INVENTION

FIELD OF THE INVENTION The present invention generally relates to IP routing in a routing table that includes an entry of an arbitrary length prefix with relevant next hop information in a next hop table that determines where to forward IP datagrams. -It relates to a lookup method and system.

2. Description of the Prior Art The Internet is an interconnected collection of networks, where each of its constituent networks retains its identity and requires specialized mechanisms for communication between multiple networks. is there. The constituent networks are called sub-networks.

Each sub-network in the Internet supports communication between devices connected to that sub-network. Further, the sub-network is an interconnection unit.
It is connected by a device called (IWU). Each IWU connects two networks that are similar or not
Is the router used to This router makes use of the Internet Protocol (IP) that exists on each router and each host on the network.

[0004] IP provides connectionless or datagram services between stations. Routing is generally accomplished by maintaining a routing table at each station and router that indicates, for each possible destination network, the next router to which the IP datagram should be sent. The IP router performs a routing lookup in the routing table and determines where to forward the IP datagram. The result of this operation is the next hop on the route toward the destination. An entry in the routing table is conceptually an arbitrary length prefix with relevant next hop information. The routing lookup must find the routing entry with the longest matching prefix.

[0005] Since IP routing lookups were inherently slow and complex, operation with prior art solutions has led to the widespread adoption of techniques that avoid their use.
Various link layer switching techniques below IP, IP layer bypass method (Computer Communication Conference (IEEE Infocom) Bulletin, San Francisco, CA, March 1996)
Mon, Gigabit Network Workshop Bulletin, Boston, April 1995
Moon, and ACM SIGCOMM '95, pp. 49-58, Cambridge, Mass., Disclosed in August 1995) and the development of alternative network layers based on virtual circuit technology such as ATM would avoid IP routing lookups to some extent It is the result of the desire.

[0006] The use of a switching link layer below the IP level and a flow or tag switching architecture adds complexity and redundancy to the network. Modern IP router designs use caching techniques,
There, routing entries for recently used destination addresses are kept in a cache. This technique relies on the fact that there is sufficient locality in the traffic so that the cache hit rate is high enough and the cost of routing lookup is shared across several packets. This cache method has worked well in the past. However, as the rapid growth of the current Internet increases the size of the address cache required, hardware caches can become uneconomical.

[0007] The traditional realization of the routing table is the data structure invented almost 30 years ago, the Patricia tree (ACM Journal, 15 (4): 514-534, 196).
(Disclosed in October 2008), modified for the longest prefix match. A direct implementation of the Patricia tree for routing lookup purposes, such as in a NetBSD 1.2 implementation, uses 24 bytes for leaves and internal nodes. For 40,000 entries, the tree alone is almost 2 megabytes, and a perfect balanced tree would have to traverse 15 or 16 nodes to find a routing entry.

In some cases, the longest-matching prefix rule may require traversal of additional nodes to find the appropriate routing information, which ensures that the initial search finds the appropriate leaves. Because they are not. There are optimizations that can reduce the size of the Patricia tree and improve lookup speed. Nevertheless, the data structures are large and searching for them requires too expensive memory references. Current Internet routing tables are too large to fit in the on-chip cache, and DRAM off-chip memory references are too slow to support the required routing speed.

[0009] Early work to improve IP routing performance by avoiding complete routing lookups (found in the IEEE Infocom Bulletin, New Orleans, Louisiana, March 1988) By the way, a small destination address cache can improve routing lookup performance by at least 65 percent. Less than 10 slots were required to achieve a hit rate of over 90 percent. Such a small destination address cache is inadequate for today's high Internet traffic density and host count.

[0010] ATM (Asynchronous Transfer Mode) avoids performing routing lookups by having a signaling protocol that communicates addresses to the network during connection setup. The transfer state accessed by the virtual circuit identifier (VCI) is installed on the switch along the path of the connection during setup. ATM cells are used as a direct index into a table with forwarding state or as a key to a hash function
Includes VCI. The routing decision is simple for ATM. However, if the packet size is greater than 48 bytes, more ATM routing decisions need to be made.

Tag Switching and Flow Switching (Computer Communication Conference (IEEE
Infocom) Bulletin, San Francisco, Calif., Disclosed in March 1996) is two IP bypass methods intended to operate over ATM. The general idea is to have IP control the link-level ATM hardware that does the actual data transfer. A dedicated protocol (comment request RFC 1953) that matches between ATMs which ATM virtual circuit identifier is used and which packet uses which VCI.
Internet Engineering Task Force, disclosed in May 1996).

Another approach also aimed at avoiding IP processing is the IP / ATM architecture (Gigabit Network Workshop Bulletin, Boston, April 1995, and ACM SIGCOMM '95 Bulletin, pages 49-58, Mass.) (August 1995, Cambridge, U.S.A.), where an ATM backplane connects a number of line and routing cards. routing·
An IP processing element arranged on the card processes the IP header. When a packet stream arrives, only the first IP header is considered, and subsequent packets are routed like the first. The primary purpose of this shortcut seems to be to share the cost of IP processing over many packets.

The IP router design is based on the IBM router (High Speed Network Journal, 1 (4): 281)
288, disclosed in 1993), IP processing may be performed using dedicated hardware. This is an inflexible solution. Any change in the IP format or protocol invalidates this design. The flexibility of software and the rapid increase in performance of general purpose processors make this solution a good choice. Another hardware approach is to use CAM to perform routing lookups (Computer Communication Conference (IEEE)
Infocom) Bulletin, Vol. 3, pp. 1382-1391, San Francisco, 199
3 years). This is a fast but expensive solution.

BBN is currently manufacturing a pair of multi-gigabit routers using a general purpose processor as the forwarding engine. Little information has been released so far. However, the plan was based on the Alpha processor
ssor) and all IP processing will be done in software. The publication Gigabit Networking, Addison-Wesley, Redding, MA, 1993, shows that assuming a hit in the route cache, IP processing can be done with as few as 200 instructions. Alpha's secondary cache is used as a large LRU (least recently used) cache of destination addresses. This method assumes the locality of the traffic pattern. Poor locality can result in too low a cache hit rate and sacrificing performance.

SUMMARY OF THE INVENTION It is therefore an object of the present invention to provide an improved IP routing lookup method and system that performs a full routing lookup for each IP packet up to gigabit speed. The system overcomes the disadvantages mentioned above.

Yet another object is to increase the speed of routing lookups with conventional microprocessors. Another purpose is to minimize lookup time in the forwarding table. It is yet another object of the present invention to provide a data structure that fits entirely in the cache of a conventional microprocessor.

As a result, memory access is many times faster than if the data structure had to be in memory, for example consisting of relatively slow DRAM. These objectives are obtained by the method and system of IP routing lookup according to the present invention, which can represent large routing tables in a very small form and use few memory references. It is a data structure that can be searched at high speed.

In order to more fully describe the present invention and to explain the advantages and features of the present invention, preferred embodiments are described in detail below with reference to the accompanying drawings. DETAILED DESCRIPTION OF THE INVENTION Referring to FIG. 1, a router design includes a number of network inbound interfaces 1, a network outbound interface 2, a forwarding engine 3, and a network processor 4, all of which are connected. Interconnected by a fabric 5. The inbound interface 1 sends the packet header to the forwarding engine 3 through the connection fabric 5. On the other hand, the forwarding engine 3 determines to which output interface 2 the packet should be transmitted. This information is returned to the inbound interface 1 from which the packet is forwarded to the outbound interface 2. The only task of the forwarding engine 3 is to process the packet header. All other tasks, such as participating in routing protocols, reserving resources, handling packets that require special attention, and other management operations, are handled by the network processor 4.

Each forwarding engine 3 makes a routing decision using a forwarding table that is a local version of the routing table downloaded from the network processor 4 and stored in storage means in the forwarding engine 3. There is no need to download a new forwarding table for each routing update. Although routing updates are frequent, the routing tables take some time to converge, so the forwarding tables are not very stale and need to be changed at most once per second (Stanford University Fast Routing And Switching Workshop, December 1996, http: // tiny-te
ra.stanford.edu/Workshop_Dec96/).

The network processor 4 needs a dynamic routing table designed for fast updating and fast generation of forwarding tables. On the other hand, the forwarding table can be optimized for lookup speed and does not need to be dynamic. The memory required during the lookup to minimize lookup time
Two parameters, the number of accesses and the size of the data structure, must be minimized in the transfer table data structure.

It is important to reduce the number of memory accesses required during a lookup, since memory accesses are relatively slow and typically bottleneck the lookup procedure. If the data structure can be made small enough, it will fit entirely in a conventional microprocessor cache. This means that the data structure is orders of magnitude faster than if it had to reside in a relatively slow DRAM memory, as in the Patricia tree.

Even if the forwarding table does not fit entirely in the cache, it would be beneficial if most of the table could be in the cache. Most lookups are fast because the locality of the traffic pattern keeps the most frequently used parts of the data structure in the cache. In addition, the use of high-speed SRAM as a small amount of required external memory becomes feasible. SRAM is expensive, and the higher the speed, the more expensive. For a fixed cost, SRAM is faster when the required amount is smaller.

As a second design goal, to avoid costly instructions and cumbersome bit extraction operations, the data structure requires fewer instructions during the look-up and keeps the entities as natural as possible. Should be able to be retained. Numerous large-scale routing tables have been discussed to determine quantitative design parameters for data structures, as described below. There are quite a few distinct routing entries in these tables, 40,000. If the next hop is the same, the rest of the routing information is the same, so that all routing entries that specify the same next hop can share the routing information. It is surprising that this number is small even for large backbone routers, since the number of distinct next hops in the router's routing table is limited by the number of other routers or hosts that can be reached by one hop. Not that. However, if the router is connected to a large ATM network, for example, the number of next hops may be higher.

In this embodiment, the forwarding table data structure is designed to accommodate 2 ¹⁴ or 16K individual next hops, which is sufficient in most cases. If there are fewer than 256 distinct next hops, the forwarding table described here is modified to take up significantly less space in another embodiment, since the index into the next hop table can be stored in one byte. it can.

A forwarding table is essentially a tree with three levels. One level of search requires 1-4 memory accesses. Therefore, the maximum number of memory accesses is twelve. However, in conventional routing tables, the majority of lookups require only one or two levels, so the majority of memory accesses are less than eight.

For the purpose of understanding the data structure, imagine the binary tree 6 shown in FIG. 2 and spread over the entire IP address space. Its depth is 32 and the number of leaves is 2 ³² , one for each possible IP address. The prefix of the routing table entry defines a path in the tree terminating at a certain node. All IP addresses (leaves) of the subtree rooted at that node are routed by that routing entry. In this way, each routing table entry defines a range of IP addresses that have the same routing information.

If several routing entries target the same IP address,
The longest match rule applies. Thereby, for an IP address, the routing entry with the longest matching prefix is used. This situation is shown in FIG. Routing entry e1 is hidden by e2 for addresses in range r.

The forwarding table is an indication of a binary tree 6 and a prefix tree 7 spanning all routing entries. The prefix tree needs to be complete, that is, each node of the tree must either have two children or have no children. Nodes with one child must be expanded to have two children. Children added in this fashion are always leaves, and their next hop information is the same as the next hop of the nearest ancestor with next hop information, or `` undefined '' if no such ancestor exists Next hop.

This procedure, shown in FIG. 4, increases the number of nodes in the prefix tree 7, but allows the construction of a small forwarding table. However, it is not necessary to actually build the prefix tree to build the forwarding table. The prefix tree is used for simplicity. The forwarding table can be built during one pass through all routing entries.

The set of routing entries divides the IP address space into a set of IP addresses. The problem of finding the correct routing information is the interval set membership problem (SIAM Computer Journal, 17 (1): 1093-11102).
, December 1988). In this case, since each interval is defined by a node in the prefix tree, it has properties that can be used to compress the forwarding table. For example, each range of IP addresses has a length that is a power of two.

As shown in FIG. 5, level 1 of the data structure targets a prefix tree up to a depth of 16, level 2 targets a depth of 17 to 24, and level 3 of a data structure ranges from a depth of 25 to 32 Target. Whenever a part of the prefix tree extends below level 16, a level two chunk describes that part of the tree. Similarly, level 3 chunks describe portions deeper than 24 in the prefix tree.
The result of searching the level of the data structure is an index into the next hop table or an array into the next level of the chunk array.

For example, at level 1 in the data structure of FIG. 5, there is a cut of the prefix tree 7 at a depth of 16. The cut is stored in a bit vector of one bit for each possible node at depth 16. That is, it requires two ^16-bit = 64K bits = 8K bytes. To find the bit corresponding to the first part of the IP address, the top 16 bits of the address are used as an index into the bit vector.

If a node exists in the depth 16 prefix tree, the corresponding bit in the vector is set. If the tree has leaves at a depth of less than 16, the least significant bit of the target interval for the leaves is set. All other bits are zero. That is, the bits in the bit vector are 1, the root head (root head (
Bits 6, 12 and 13 in FIG. 6) or 1, representing a leaf at depth 16 or less, a genuine head (bits 0, 4, 7, 8, 14 and 15 in FIG. 6), or 0 (bits 1, 2, 3, 5, 9, 10, and 11 in FIG. 6) meaning that this value is a member of the range of interest for leaves with a depth less than 16. The member has the same next hop as the largest head smaller than the member.

For a pure head, an index to the next hop table must be stored. The member uses the same index as the largest head smaller than the member. For the root head, the index to the level 2 chunk representing the corresponding subtree must be stored. The head information is encoded with a 16-bit pointer stored in the array.
The two bits of the pointer encode what kind of pointer it is, and the remaining 14 bits are an index into either the next hop table or an array containing level 2 chunks.

In order to find the appropriate pointer, the bit vector is split into bit masks of length 16, where there are 2 ¹² = 4096. Furthermore, the position of the pointer in the array is obtained by adding three entities: the base index, the 6-bit offset and the 4-bit offset. Base index plus 6 bits
The offset determines where the pointer corresponding to a particular bit mask is stored. The 4-bit offset specifies which of the pointers to retrieve. FIG. 7 shows how to find these entities. The following paragraphs are a detailed description of the procedure.

Since the bit mask is generated from the complete prefix tree, not all combinations of 16 bits are possible. A non-zero bit mask of length 2n is either two bit masks of length n or some combination of bit masks of value one. Let a (n) be the number of possible non-zero bit masks of length 2 ⁿ . a (n) is defined by the following recurrence formula.

A (0) = 1, a (n) = 1 + a (n−1) ² That is, the number of possible bit masks of length 16 is a (4) + 1 = 678, but 1 is added This is because the bit mask may be zero. Thus, an index into a table with an entry for each bit mask needs only 10 bits.

This table, the map table, is maintained to map the number of bits in the bit mask range to a 4-bit offset. This offset is equal to the number of set bits less than the bit index, since it specifies how many pointers to skip to find the required pointer. These offsets are the same for all forwarding tables, regardless of what value the pointer happens to have. The map table is constant and is generated for all at once.

Possible bit masks are even powers of 2 in length, with an interval of bits starting at a bit index that is a multiple of the same power of 2 1) containing all 0s or 2
) Has the property of either having the least significant bit set. The mapping from bit masks and bits to offsets provided by the map table is key to achieving a small forwarding table size, with extension of the prefix to complete the prefix tree and enable the use of the mapping.

The actual bit mask is not required, and instead of a bit vector, it holds an array of 16-bit code words consisting of a 10-bit index into the map table plus a 6-bit offset. Since the 6-bit offset covers up to 64 pointers, one base index is required for every four codewords. Since there can be up to 64K pointers, the base index can be up to 16 bits (2 ¹⁶ = 64)
K).

In the procedure shown in FIG. 7, the next step of the pseudo code is required to search the first level of the data structure, where the array of code words is called a code and the base address is The array is called the base, ix is the first index of the IP address in the array of codewords, bit is the column index of the IP address into the map table, and ten
Is the row index part of the codeword into the map table, bix is the second index part of the IP address into the array of base addresses, and pix is the index into the next hop table along with the index into the level 2 chunk. Is a pointer to an array of pointers.

Ix: = upper 12 bits of IP address bit: = lower 16 bits of upper 16 bits of IP address code word: = sign [ix] ten: = 10 bits from code word six: = 6 bits from code word bix: = higher 10 bits of IP address pix: = base [bix] + six + map table [ten] [bit] pointer: = level 1_pointer [pix] That is, only extraction of several bits, array reference and addition are necessary is there. No multiplication or division instructions are required, other than the implicit multiplication when indexing the array.

To search the first level, a total of 7 bytes need to be accessed, ie, a 2-byte codeword, a 2-byte base address, a 1-byte in the map table.
A byte (actually 4 bits), and finally a 2 byte pointer. The first level size is 8K bytes for the codeword array, 2K bytes for the base index array, plus a number of pointers. The 5.3 Kbytes required by the map table are shared by all three levels.

If the bit mask is 0 or has one bit set,
The pointer must be an index into the next hop table. Since such pointers can be encoded directly into codewords, the map table need not include entries for bit masks 1 and 0. That is, the number of map table entries is reduced to 676 (index 0-675). If the 10 bits of the codeword (ten above) are greater than 675, the codeword represents a direct index into the next hop table. The 6 bits from the codeword are used as the least significant 6 bits of the index, and (ten-6
76) is the upper bit of the index. By this encoding, the maximum (1024-676) is obtained.
) × 2 ⁶ = 22272 indices, which is more than the 16K to be designed. This optimization removes three memory references when the routing entry is deeper than 12, and significantly reduces the number of pointers in the pointer array.
This is due to comparisons and conditional branches.

The mapping is represented by the following data and functions in the C programming language. An important feature of this code is the mapping from the individual bit masks it provides to an array of offsets. Even if there is a change such as exchanging entries of mtable (and mt), the given mapping is the same. Thus, there would be other ways to represent an array of offsets, such as two 32-bit words instead of four 16-bit words. / ^* Map table ^* / # define MAPVECLEN 4 typedef uint16 MAPVEC [MAPVECLEN]; typedef MAPVEC MCOMPACT; MCOMPACT mt [TMAX]; / ^* mt is a map table used at the time of lookup.

Initialized from the mtable used during construction. ^{* / Typedef struct mentry {uint16 mask} ; / * 16 bit pattern (LSB is ^{set!) * / Uint16 len; /} * 8 bits len (values ^{1~16) * / MAPVEC map; /} * 4 of 16 in the group ^* /｝ MENTRY, * MP; void mentry2mcompact (MENTRY * from, MCOMPACT * to) / ^* Take the map part from “from” and put it in “to” ^* / ｛int i; for ( i = 0; i <MAPVECLEN; i ++) ｛(* to) [i] = from-> map [i];｝｝ extern void mtable_compact () / ^* Initialize mt from mtable ^* / ｛register int i; for (i = 0; i <TMAX; i ++) ment mentry2mcompact (& mtable [i], & mt [i]);｝ レ ベ ル Levels 2 and 3 of the data structure consist of chunks. The chunk is intended for a subtree of height 8 and may contain up to 2 ⁸ = 256 heads. The level n-1 root head points to the level n chunk.

There are three types of chunks depending on the number of heads included in the imaginary bit vector. That is, if there are 1 to 8 heads, the chunk is sparse and is represented by an array of 8-bit indices of the heads, plus 8 16-bit pointers, for a total of 24 bytes. If there are 9 to 64 heads, the chunk is dense. It is represented similarly to level 1 except for the number of base indexes. The difference is that the 6-bit offset is 64
The base index required for all 16-bit codewords is 1 to span all pointers.
It is only one. 34 bytes total, plus 1 for pointer
8 to 128 bytes are required.

If there are 65-256 heads, the chunk is super-dense. It is represented as in level 1. Sixteen codewords and four base indices add up to a total of 40 bytes. In addition, 65-256 pointers require 130-512 bytes. Dense and ultra-dense chunks are searched as in the first level. Sparse chunks are searched for by a dedicated binary search that is well tailored for the eight elements.
This is significantly faster than linear search and general binary search. In addition, this search
It can be implemented on a processor architecture with conditional move instructions without using conventional conditional jumps. / ^* Search function for sparse chunks ^* / static inline uint16 findsparse (SPARSECHUNK * chu, uint32 val) / ^* chu-> vals is a sorted array of 8-bit values. . 7

Chu-> rinfo is an array of pointers 0. . 7 val is the search key ^* / ｛uint8 ^* p, ^* q; p = q = &(chu-> vals [0]); p + = ( ^* (p-3)> val) <<2; p + = ( ^* (p + 1)> val) <<1; p + = ( ^* p>val); return (chu-> rinfo [pq]);｝ Dense and ultra-dense chunks are the same as Level 1 as described Optimized for In a sparse chunk, if the next hops of two consecutive heads are the same, they can be merged and represented by the smaller one. This merge is taken into account when determining whether a chunk is sparse or dense, so a chunk is considered sparse if the number of merged heads is 8 or less. Many of the leaves added to complete the tree occur sequentially and have the same next hop. Heads corresponding to these leaves are merged into sparse chunks.

This optimization shifts the distribution of chunks from larger dense chunks to smaller sparse chunks. For large tables, the size of the transfer table is typically reduced by 5 to 15 percent. This data structure can accommodate a significant increase in routing entries. Current designs have two limitations.

1. The number of chunks of each type is limited to 2 ¹⁴ 16384 per level. Table 1 shows that this is about 16 times larger than currently used. If the limit is still exceeded, the encoding of the pointer can be changed to allow more room for the index, or the data structure can be modified to increase the pointer size.

[0052] 2. The number of level 2 and 3 pointers is limited by the size of the base index. Current implementations use a 16-bit based index and can accommodate growth factors of 3-5. Beyond this limit, it is easy to increase the size of the base pointer to 3 bytes. Chunk size increases by 3 percent for dense chunks and 10 percent for ultra-dense chunks. Sparse chunks have no effect.

It is clear that this data structure can accommodate a large increase in the number of routing entries. Its size increases almost linearly with the number of routing entries. A number of IP routing tables were assembled to examine the performance of the forwarding tables. The Internet Routing Table is now available on the Internet Performance Measurement and Analysis (IPMA) project website (http://www.ra.net/statistics/) and was formerly a routing arbiter. It was available at the project (http://www.ra.net/statistics/), but is now closed. The collected routing tables are daily snapshots of the routing tables used at various large Internet interconnect points. Some of the routing entries in these tables contain multiple next hops. In this case, one of them
It was randomly selected as the next hop to be used in the forwarding table.

Table 1 in FIG. 8 shows data related to a forwarding table composed of various routing tables. For each site, this table shows the data and results for the routing table that generated the maximum forwarding table. The routing entry is the number of routing entries in the routing table, and the next hop is the number of individual next hops found in the table. Leaves is the number of leaves in the prefix tree after the leaves have been added to complete the prefix tree.

The construction time in Table 1 indicates the time required to generate a forwarding table from the in-memory binary tree representation of the routing table. 333M running DEC OSF1 time
Hz Alpha 21164 was measured. The next column shows the total number of sparse, dense and ultra-dense chunks in the generated table, followed by the number of lowest level chunks in the data structure.

From Table 1, it is clear that a new forwarding table can be generated quickly. 1H
At a playback frequency of z, the alpha power consumed is less than one-tenth. As explained above, playback frequencies higher than 1 Hz are not required. The larger table in Table 1 does not fit entirely into Alpha's 96Kbyte secondary cache. However, it is feasible to have a small amount of ultra-fast SRAM in the third level cache for parts that do not fit in the secondary cache and reduce the cost of secondary cache misses. Due to the locality of the traffic pattern, most memory references are to the secondary cache.

An interesting observation is that the size of these tables is comparable to that required to just store all the prefixes in the array. For larger tables, only 5.6 bytes are required per prefix. More than half of these bytes are consumed by pointers. In the Sprint table, there are 33469 pointers, requiring 65K bytes or more of storage. Obviously, the size of the transfer table can be further reduced by reducing the number of pointers.

The measurements for the look-up routine were compiled by the GNU C compiler gcc (disclosed in the use and porting manual for gnu cc., Free Software Foundation, November 1995, ISBN 1-88214-66-3). Is performed on the C function. Reported times do not include function calls or memory accesses to the next hop table. gcc generates a code that uses about 50 alpha instructions to search one level of the data structure in the worst case.
In Pentium Pro, gcc generates a code that uses 35 to 45 instructions per level at worst.

The following C sign function indicates the sign of the lookup function used in the measurement. The level 1 codeword array is called int1, and the base index array is called base1. Level 1 pointers are stored in array htab1. Chunks are stored in the arrays cis, cid, cidd, where i is a level. Base addresses and pointers for dense and ultra-dense chunks are arrays
Stored in baseid, baseidd, htabid, htabidd. / ^* Lookup function for forwarding table ^* / #include "conf.h"#include"forward.h"#include"mtentry.h"#include"mtable.h"#include"bit2index.h"#define TABLE _LOOKUP #include "sparse.h"#include"timing.h"#include"lookup.h" / ^* These macros operate only when ip is 32-bit unsigned int (uint32) ^* / #define EXTRACT (start, bits, ip) (((ip) << (start)) >> (32- (bits))) #define GETTEN (m) (((m) << 22) >> 22) #define GETSIX (m) ((m) >> 10) #define bit2o (ix, bit) ((mt [(ix)] [(bit) >> 2] >> (((bit) & 0x3) << 2)) & 0xf ) / ^* Lookup (ipaddr)-Index to routing table entry for ipaddr ^* / unsigned int lookup (uint32 ipaddr) ｛uint32 ix; / ^* Index to codeword array ^* / uint32 code; / ^* 16 bits code word ^* / int32 diff; / ^* the difference between the TMAX ^* / uint32 ten; / ^* index into mt ^* / uint32 six; / ^* the sign of the six "extra" bits ^* / int32 nhop; / ^* next hop The pointer ^* / uint32 off; / ^* pointer offset ^* / uint32 hbase; / ^* base for the hash table ^* / uint32 ^pntr; / ^* hash table entry ^* / int32 kind; / ^{* pntr} of type ^* / uint32 chunk; / ^* chunk index ^* / uint8 * p, * q; / ^* pointer to search sparse ^* / uint32 key; / ^* sparse search key ^* / / ^{* *} Take timing from HERE ^{* *} /

[0060]

[Table 1]

[0061]

[Table 2]

[0062]

[Table 3]

[0063]

[Table 4]

/ ^* HERE! Take the timing until ^* / return nhop; こ と が It is possible to read the current value of the alpha and Pentium Pro (Pentium Pro) clock cycle counters. This mechanism was used to measure the lookup time with high accuracy. One clock tick is 5 nanoseconds at 200 MHz and 3 nanoseconds at 333 MHz.

Ideally, the entire forwarding table is located in the cache, and the lookup is performed by an undisturbed cache. This emulates the behavior of a dedicated forwarding engine cache. However, since the measurements were made on a conventional general-purpose workstation, it is difficult to control the cache contents with such a system. The cache is used when I / O is performed, when an interrupt occurs,
Or, it is always disturbed when the execution of another process is started. Without disturbing the cache, it is not possible to print out the measurement data or read out the new IP address from the file.

The method used performs each lookup twice and measures the lookup time of the second lookup. In this method, the first lookup is a perturbation cache (d
the second time in the cache with all the necessary data placed in the primary cache by the first lookup. After each set of lookups, the measurement data is printed out and a new address is fetched, but this procedure again perturbs the cache.

The second lookup works better than the lookup in the transfer engine because the data and instructions have moved to the primary cache closest to the processor. In order to obtain the upper limit of the lookup time, the additional time required for the memory access to the secondary cache must be added to the measurement time. To test all paths through the forwarding table, the lookup time was measured for each entry in the routing table, including the entry added by the extension to the full tree.

The average lookup time cannot be inferred from these experiments, since the real traffic mix is unlikely to have a uniform probability of accessing each routing entry. In addition, the average look-up time is reduced because frequently accessed parts of the data structure are kept in the primary cache due to the locality of the traffic pattern. The performance values calculated below are:
All memory accesses are conservative, as they assume a miss in the primary cache and always have worst case execution times. The real lookup speed is much faster.

Table 1 shows that there are very few chunks at level 3 of the data structure. This means that most of the lookups need to search at most two levels to find the next hop. Thus, the additional time for a memory access to the secondary cache is calculated for eight memory accesses instead of the worst case twelve. If large parts of the lookup may access those few chunks, they are moved to the L1 cache, so
All memory accesses will be less expensive.

The experiments were performed on an Alpha 21164 with a clock frequency of 333 MHz.
One cycle is 3 nanoseconds. Access to the 8 Kbyte primary data cache is completed in two cycles, and access to the secondary 96 Kbyte cache requires eight cycles. See Table 2 in FIG. FIG. 10 shows the distribution of clock ticks during the second lookup in the alpha case for the sprint routing table from January 1st. The fastest lookup observed requires 17 clock cycles. This is where the first level codeword directly encodes an index into the next hop table. There are very few such routing entries. However, since each such routing entry is for many IP addresses, actual traffic may contain many such destination addresses. Some lookups take 22 cycles, which would be the same as before. Experiments have shown that if the clock cycle counter is read for two consecutive instructions, the difference may be five instead of the expected zero.

The next spike in FIG. 10 is at 41 clock cycles, where the pointer at the first level is an index into the next hop table. Traditional class B addresses fall into this category. 52-53, 57, 62,
The 67 and 72 tick spikes correspond to pointers being found after examining a value of 1, 2, 3, 4 or 5 in a sparse level 2 chunk. The spikes of 75 and 83 ticks are so large that many tics need to search for dense and ultra-dense chunks respectively. Some ticks observed at 83 and above probably correspond to pointers found after searching for sparse level 3 chunks due to runtime changes. Such changes may occur due to cache contention in the secondary cache, or differences in the state of the pipeline and cache system before the lookup. The tail of observations that exceed 100 clock cycles is due to either such a change or a cache miss. If all data is in the primary cache, 300 nanoseconds is sufficient.

The difference in data access between the primary cache and the secondary cache is 8−2 = 6 cycles. The worst case clock cycle required to search the two levels of the data structure is 8 × 6 = 48 more than the case shown in FIG. This means that when two levels are sufficient, the worst case lookup will require up to 100 + 48 = 148 cycles or 444 ns. That is, alpha is 2
2.2 million routing lookups per second can be performed on the forwarding table in the secondary cache.

Another experiment was performed on a Pentium Pro with a clock frequency of 200 MHz. One cycle is 5 nanoseconds. The primary 8 Kbyte cache has a two cycle latency and the 256 Kbyte secondary cache has a six cycle latency. See Table 2. FIG. 11 shows the distribution of clock ticks during the second lookup for Pentium Pro for the same forwarding table as for Alpha 21164. The series of instructions that fetch the clock cycle counter is 33
Requires a clock cycle. If two fetches occur immediately after each other, the counter values differ by 33. For this reason, all reported times have been reduced by 33.

The fastest lookup observed is 11 clock cycles, about the same speed as for alpha 21164. A spike corresponding to the case where the next hop index is immediately after the first level occurs in 25 clock cycles. Spikes corresponding to sparse level 2 chunks are clustered close together in the range of 36-40 clock cycles. Pentium's different cache structure seems to handle linear scans better than the alpha 21164 cache structure.

When the second level chunk is dense and super dense, the lookups are 4
Requires 8 and 50 cycles. There are some additional irregular spikes up to 69, but much less are observed. Clearly, if all data is in the primary cache, 69 cycles (345 nanoseconds) are sufficient to perform the lookup.

The difference between the access times of the primary cache and the secondary cache is 20 nanoseconds (4 cycles). When two levels need to be examined, the look-up time for Pentium Pro is at worst 69 + 8 × 4 = 101 cycles or 505 nanoseconds. Pentium Pro can perform at least 2 million routing lookups per second on the forwarding table in the secondary cache.

It will be apparent that the present invention provides an improved IP routing lookup method and system that fully satisfies the goals and advantages set forth above. Although the present invention has been described with particular embodiments, alternatives, modifications and variations will be apparent to those skilled in the art. In the embodiment described above, the lookup function is implemented in the C programming language. It will be apparent to those skilled in the programming arts that other programming languages may be used. Also, the lookup function can be implemented in hardware using standard digital design techniques, which will also be apparent to those skilled in the art of hardware design.

For example, the present invention relates to computer system configurations other than systems using Alpha 21164 or Pentium Pro, other ways to cut prefix trees, various levels of trees, other ways to represent map tables, And other methods of encoding codewords. In addition, the invention can be used for firewall routing lookups.

[Brief description of the drawings]

FIG. 1 is a schematic diagram of a router design.

FIG. 2 is a diagram illustrating a binary tree that spans the entire IP address space.

FIG. 3 is a diagram illustrating a routing entry that defines a range of IP addresses.

FIG. 4 is a diagram illustrating the steps of expanding a prefix tree to complete it.

FIG. 5 is a diagram showing three levels of a data structure according to the present invention.

FIG. 6 is a diagram illustrating a part of a cut of a prefix tree at a depth of 16;

FIG. 7 is a diagram illustrating a first level search of a data structure.

FIG. 8 is a table showing data on a transfer table composed of various routing tables.

FIG. 9 is a table showing data of a processor and a cache;

FIG. 10 is a graph showing a look-up time distribution for alpha 21164.

FIG. 11 is a graph showing a lookup time distribution for Pentium Pro.

[Procedural Amendment] Submission of translation of Article 34 Amendment of the Patent Cooperation Treaty

[Submission date] March 15, 2000 (2000.3.15)

[Procedure amendment 1]

[Document name to be amended] Statement

[Correction target item name] Claims

[Correction method] Change

[Correction contents]

[Claims]

──────────────────────────────────────────────────続 き Continuation of front page (81) Designated country EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, MC, NL, PT, SE ), OA (BF, BJ, CF, CG, CI, CM, GA, GN, ML, MR, NE, SN, TD, TG), AP (GH, GM, KE, LS, MW, SD, SZ, UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, CA, CH, CN, CU, CZ, DE, DK, EE, ES, FI, GB, GE, GH, GM, GW, HU, ID, IL, IS, JP, KE, KG, KP, KR , KZ, LC, LK, LR, LS, LT, LU, LV, MD, MG, MK, MN, MW, MX, NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, SL, TJ, TM, TR, TT, UA, UG, UZ, VN, YU, ZW (72) Inventor Carlson, Subante Sweden, S-977 53 Lureo, Nustygen 4 (72) Invention Person Pink, Stefan Sweden, S-165 57 Haas Levy, Viveka Tolores Grand 8

Claims (2)

[Claims] 1. A method of IP routing lookup in a routing table that includes an entry of an arbitrary length prefix having relevant next hop information in a next hop table for determining where to forward an IP datagram. And each node has either no children or two children, and all added children have the same next hop information as their nearest ancestor with next hop information, or Representation of the routing table in the form of a full prefix tree (7), defined by the prefix of all routing table entries, which is completed to be a leaf with unspecified next hop if no ancestor is present Storing in a storage means the current depth (D) possible Storing, in said storage means, a representation of a bit vector (8) containing data of a cut of said prefix tree (7) of said current depth having one bit for each node, wherein said prefix Tree (7
Setting the bit if there is a node in the array, an array of pointers, an index into the next hop table for a pure head, and an index to the next level chunk for a root head. Storing in the storage means; dividing the bit vector (8) into bit masks of a certain length; storing possible bit mask representations in a map table in the storage means. Storing in the storage means an array of codewords each encoding a row index into the map table and pointer offset; storing an array of base addresses in the storage means; Accessing a codeword at a position corresponding to a first index portion (ix) of the IP address in an array; Accessing a map table entry portion at a position corresponding to an index portion (bit) and a row index portion (ten) of the codeword in the map table; and accessing the IP address in the array of base addresses. Accessing a base address at a location corresponding to a second index portion (bix); and the map table entry in the array of the base address plus the pointer offset of the codeword (six) plus pointers. Accessing a pointer at a location corresponding to the portion. 2. A system for IP routing lookup in a routing table that includes an entry of an arbitrary length prefix with relevant next hop information in a next hop table for determining where to forward an IP datagram. And each node either has no children or has two children, and all added children have the same next hop information as the nearest ancestor with next hop information, or A routing table in the form of a full prefix tree (7), defined by the prefix of all routing table entries, which is a leaf with an unspecified next hop if no such ancestor is present; D) before said current depth with one bit for each possible node An indication of a bit vector (8) containing data of cuts of the prefix tree (7), wherein the bit is set if a node is present in the prefix tree (7), and an array of pointers An index to the next hop table for a pure head, an index to a next level chunk for a root head, and the bit vector (8) divided into bit masks of a certain length; A system comprising: a map table containing possible representations of the bit mask; an array of codewords each encoding a row index into the map table and a pointer offset; and an array of base addresses.