CZ2000941A3 - Method and system for fast routing lookups - Google Patents

Abstract

In the routing lookup method in Intemet log in the routing table, this table contains records with prefixes of any length with associated information about another jump in the next jump table, to see where they should redirect the Intranet protocol datagrams. The representation of this routing table is stored in a form a complete prefix tree (7), defined by prefixes all records in the routing table. Next it is saved a representation of the bit vector (8) containing the slice data a prefix tree at a certain depth (D), and an array of pointers, containing indexes to the next jump table and to the next one level. The bit vector (8) is divided into bit masks and the representation of these bit masks is stored in the mapping table. Next, the base address field and the code field are stored of words where each encodes a row index to a mapping table and Pointer offset. Finally, a search is performed.

Description

Technical field

The present invention generally relates to an Internet Protocol (IP) routing lookup system and method in a routing table comprising arbitrary length prefix entries with associated next hop information in the next hop table to determine where IP datagrams are to be redirected.

BACKGROUND OF THE INVENTION

The Internet is an interconnected set of networks where each of the creation networks retains its identity and a special mechanism is needed for communication between multiple networks. Creation networks are called subnets.

Each subnet on the Internet supports communication between devices connected to that subnet. Individual subnets are connected by devices called network couplers.

A particular network coupler is a router that is used to connect two networks that may or may not be similar. This router uses an Internet Protocol (IP) that is present in each router and in each network host. IP provides datagram or no-link transmission between stations.

Routing is generally performed by maintaining a routing table at each station and router, indicating for each possible target network another router to which an IP datagram is to be sent.

♦ ···

IP routers perform routing lookups in the routing table to determine where the IP datagram is to be redirected. The result of this operation is another jump on the way towards the target. Conceptually, the entry in the routing table is a prefix of any length with associated jump information. The routing search must find the routing record with the longest matching prefix.

Because IP routing lookup is inherently slow and complex, operation of the prior art has led to the spread of techniques that exclude routing lookup. Various Link Layer Under IP Technology, IP Layer Bypassing Methods (published in IEEE Infocom), San Francisco, California, March 1996, Proceedings of Gigabit Network Workshop, Boston, April 1995 and Proceedings of ACM SIGCOMM '95, p. 49-58, Cambridge, Massachusetts, August 1995) and the development of alternative network layers based on virtual circuit technologies such as ATM, are to some extent the results of the desire to exclude IP routing searches.

The use of link-layer switching and flagship and flow-over-IP switching architecture increases network complexity and redundancy.

Most current IP routers use cache caching techniques, where routing records of the most recently used destination addresses are cached. This technique relies on certain locations where much of the traffic is directed, so that the caching search success rate is high enough and the cost of routing searches are amortized in a few packets. These cached methods have worked well in the past. With the simultaneous rapid growth of the Internet, the required size of address caches increases, and hardware caches may become uneconomical.

0

The traditional implementation of routing tables uses the version of Patricia trees (published in Journal of the ACM, 15 (4): 514534, October 1968), the data structures invented thirty years ago, with modifications to find the longest matching prefixes.

Direct implementation of Patricia trees for routing lookup purposes, for example in NetBSD 1.2 implementation, uses 24 bytes for end and inner nodes. At 40000 records, the tree structure itself is nearly 2 megabytes, and in a perfectly balanced tree, 15 or 16 nodes must be traversed to find the routing record.

In some cases, because of the longest matching prefix rule, additional nodes must be traversed to find the correct routing information, as there is no guarantee that the default search will find the correct end node. There are optimizations that can reduce the size of Patricia's tree and increase search speed, but the data structure is large and requires too much expensive memory references to find it. Current Internet lookup tables are too large to fit in on-chip buffers, and links to out-of-chip DRAMs are too slow to achieve the desired search speed.

Initial work to improve IP routing performance by eliminating full routing lookups (published in IEEE Infocom, New Orleans, Louisiana, March 1988) found that small destination cache can improve routing lookup performance by at least 65%. Less than 10 slots are required to achieve over 90% search success. Such small destination address buffers are not sufficient for large traffic volumes and large numbers of hosts on today's Internet.

k ··· · · «4 toto toto 4 to to <

ATM (asynchronous transfer mode) excludes routing lookups by having a signaling protocol that forwards addresses to the network during connection set-up. The redirection state, accessible to the virtual circuit identifier (VCI), is installed in the switches along the path during the establishment of the connection. ATM cells contain a VCI that can be used as a direct index to a redirection status table or as a key to a transformation function. Routing decisions are easier for ATM, but if packet sizes are larger than 48 bytes, more ATM routing decisions need to be made.

Feature switching and flow switching (published in IEEE Infocom, San Francisco, California, March 1996) are two methods of bypassing IP that are designed to operate over ATM. The general idea is to let IP control ATM line-level hardware that performs real data redirection. Special purpose protocols (published in Request for Comments RFC 1953, Internet Engineering Task Force, May 1996) are necessary to agree between routers on which ATM virtual circuit identifiers to use and which packet can use which virtual circuit identifier.

Another approach with the same goal of excluding IP processing is used in the IP / ΑΤΜ architecture (published in Proceedings of ACM SIGCOMM '95, p. 49-58, Cambridge, Massachusetts, August 1995), where an ATM backplane interconnects a number of line and routing cards. IP processing members located on routing cards process IP headers. When a packet stream arrives, only the first IP header is examined and the next packets are routed the same way as the first. It seems that the main purpose of these truncations is to amortize the cost of IP processing in many packets.

»» · · 99 99 999 9 9 9 9 9999999 ·· · *

IP router designs can use dedicated hardware for IP processing, such as in an IBM router (published in the Journal of High Speed Networks, 1 (4): 281-288, 1993). But this can be an inflexible solution. Any changes to the IP format or protocol may render such a design unusable. Software flexibility and rapid performance enhancement for general purpose processors favor a solution that way. Another hardware approach is to use CAM to perform routing searches (published in Proceedings of the Conference on Computer Communications (IEEE Infocom), volume 3, p. 1382-1391, San Francisco, 1993). This is a fast but expensive solution.

BBN is currently building a pair of multigigabit routers that use general purpose processors as redirection machines. Little information has been published so far, but the idea seems to be to use Atpha processors as redirection machines and perform all IP processing with software. Gigabit networking, Addison-Wesley. Reading, Massachusetts, 1993 shows that it is possible to perform IP processing in less than 200 instructions, assuming success in the routing cache. The second cache of the Alpha processor is used as a large LRU (least recently grayed) destination address cache. This scheme assumes that traffic is directed to certain locations. If there are few of these specific locations, the cache search success rate becomes low and performance decreases.

SUMMARY OF THE INVENTION

Thus, an object of the present invention is an improved IP routing lookup method and system for performing full routing lookups for each IP packet up to a gigabit (ig). This method and system overcome the aforementioned disadvantages.

Another goal is to increase the speed of routing searches with a conventional microprocessor.

Yet another objective is to minimize search time in the redirection table.

Yet another object of the present invention is to provide a data structure that fits entirely in the cache of a conventional microprocessor. As a result, memory accesses will be of a significantly faster rate than if the data structure must be located in memory, such as a relatively slow DRAM.

These objectives can be met by the IP routing search method and system of the invention, which system is a data structure that can represent large routing tables in a very compact form, and which can be quickly searched through several memory references.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more detailed explanation of the invention, its advantages and features, a preferred embodiment of the invention will be described in detail below with reference to the accompanying drawings, in which Fig. 1 is a schematic view of a router design.

Fig. 2 is an illustrative view of a binary tree comprising the entire IP address space.

Fig. 3 is an illustrative view of routing records defining IP address ranges.

Fig. 4 is an illustrative view of the step of expanding the prefix tree to be full.

Fig. 5 is an illustrative view of three levels of the data structure of the invention.

Fig. 6 is an illustrative view of a section of a prefix tree at depth 16.

Fig. 7 is an illustrative view of a first level search of the data structure.

Fig. 8 is a table illustrating data in redirection tables constructed from different routing tables.

Figure 9 is a table of processor and cache data.

Fig. 10 is a diagram showing a search time distribution for an Alpha 21164 processor.

Fig. 11 is a diagram showing a search time distribution for a Pentium Pro processor.

DETAILED DESCRIPTION OF THE INVENTION

It can be seen that the design of the router consists of a plurality of network input interfaces 1, network output interfaces 2, redirection means 3, and a network processor 4, all of which are interconnected by an interface structure 5. Input interface 1.

Send packet headers to the redirection means 3 via the linking structure 5. The redirection means 3, in turn, determine to which output interface 2 the packet is to be sent. . This information is sent back to the input interface 1, which redirects the packet to the output interface 2. The only task of the redirection means 3 is to handle the packet header. All other tasks, such as participation in routing protocols, resource reservation, packet processing that require special attention, and other administrative responsibilities are handled by the network processor 4.

Each redirection means 3 uses a local version of the routing table, i.e., a redirection table loaded from the network processor 4 and stored in the memory of the redirection means 3 for making its routing decisions. It is not necessary to upload a new redirection table for each routing update. Routing updates may be frequent, but because routing protocols need some time to converge, the redirection table may become a bit obsolete and may not change more than once per second (published at Stanford University Workshop on Fast Routing and Switching, December 1996; http: // tinvtera) .staanford.edu / Workshop Dec96 /).

Network processor 4 needs a dynamic routing table designed for fast updates and fast generation of redirection tables. Conversely, these redirection tables can be optimized for search speed and not dynamic.

To minimize search time, two parameters in the data structure in the redirection table must be minimized simultaneously, namely the number of memory accesses required during the search and the size of the data structure.

Reducing the number of memory accesses required during searches is important because memory accesses are relatively slow and usually form the bottleneck of search procedures. If a sufficiently small data structure is created, it can be placed in the cache of a conventional processor. This means that accesses to memory will be of an order of magnitude faster than if the data structure has to be placed in a relatively slow DRAM memory, which is the case with Patricia's trees.

if the entire redirection table does not fit in the cache, it is still advantageous if a large portion of the redirection table is located in the cache. Certain traffic patterns will keep the most used parts of the data structure in this cache, so most searches will be fast. In addition, it will be possible to use fast SRAM memory for the small external memory required. SRAM is expensive and the more expensive the faster it is. For this cost, this SRAM can be faster if less is needed,

Other design objectives are that the data structure needs little instruction during the retrieval and that the entities remain as naturally aligned as possible to avoid costly instructions and difficult bit extraction operations.

To determine the quantitative design parameters of the data structure, a number of large routing tables were investigated as described below. In these tables, there are 40000 rather few routing records. If the other jumps are the same, the rest of the routing information is also the same so that all routing records specifying the same next hop can share the routing information. The number of different additional hops in the router routing table is limited by the number of additional routers or hosts that can be reached by a single hop, so it is not • to ······· Surprisingly, these numbers may be small even for large backbone routers. However, if the router is connected to a large ATM network, for example, the number of additional jumps may be much higher.

In this arrangement, the redirection table data structure is designed to accommodate 2 ¹⁴ or 16K different jumps, which should be sufficient for most cases. If there are fewer than 256 different additional jumps, so that the index in the next jump table can be stored in a single byte, the redirection tables described herein may be modified in another arrangement to occupy substantially less space.

The redirection table is basically a tree with three levels. Searching one level requires one to four memory accesses. This implies that the maximum number of memory accesses is twelve. However, the vast majority of routing table searches need one or two levels of search, so the most likely number of memory accesses is eight or less.

For the purpose of understanding the data structure, a binary tree 6 that encompasses the entire IP address space shown in FIG. Its depth is 32 and the number of end nodes is 2 ³² , one for each possible IP address. The record prefix in the routing table defines a tree path ending at a node. All IP addresses (end nodes) in a subtype that has a root in that node can be routed according to this routing record. In this way, each entry in the routing table defines a range of IP addresses with the same routing information.

If several routing records cover the same IP address, the longest match rule applies, which states that the routing record with the longest matching «······ prefix should be used for that IP address. This situation is shown in Figure 3, where the routing record e1 is hidden by the record e2 for addresses in the range r.

The redirection table is a representation of the binary tree 6 with all routing records-prefix tree 7. It is required that the prefix tree is full, that is, each node in the tree has either two or no successors. Nodes with one successor must be expanded to have two successors. Successors added in this way are always end nodes and their next jump information will be the same as the next jump of the next predecessor with the next jump information, or “undefined next jump if there is no such predecessor.

This procedure, shown in Fig. 4, increases the number of nodes in the prefix tree 7, but allows the creation of a small redirection table. However, it is not really necessary to create a prefix tree to create a redirection table. The prefix tree is used to simplify the description. The redirection table can be created in a single pass through all routing records.

A set of routing records divides the IP address space into sets of IP addresses. The problem of finding the correct routing information is similar to the problem of belonging to the interval set (published in SIAM Journal on Computing, 17 (1): 1093-1102, December 1988). In this case, each interval is defined by a node in the prefix tree and therefore has properties that can be used to create a compact redirection table. For example, each IP address range has a length that is a power of two.

As shown in Fig. 5, level one of the data structure covers the prefix tree to depth 16, level two covers the depths 17 to 24 and level three depths to 25 to 32. Wherever part of the prefix tree extends below level 16, this portion of the tree describes the level batch two.

Similarly, the batch at level three describes those portions of the prefix tree that are deeper than 24. The search for the data structure level results in either an index to the next jump table or an index to the batch field for the next level.

For example, at one data structure in Figure 5 is a section by prefix tree at depth 16. This cut is stored in the bit vector, with one bit for each possible node at depth 16. It is therefore necessary to 2 ¹⁶ bits = 64 kbits = 8 kbyte . To find the bit corresponding to the initial portion of the IP address, the 16 upper bits of that address are used as an index into the bit vector.

If a node exists in the prefix tree at depth 16, the corresponding bit in the vector is set. Also, if the tree has an end node at a depth less than 16, the lowest bit in the interval covered by that end node is set. All other bits are zero. Thus, the hitting in the bit vector may be one representing that the prefix tree continues below the slice or root header (bits 6, 12 and 13 in Fig. 6) or the one representing the end node at depth 16 or less or right header (bits 0, 4). 7, 8, 14, and 15 in FIG. 6) or zero, which means that this value is part of the range covered by the end node at a depth of less than 16 (bits 1, 2, 3, 5, 9, 10, and 11 in FIG. , 6). Components have the same additional jump as the largest header smaller than the component.

For the right headers, the index must be stored in the next jump table. Components use the same index as the largest header smaller than the component. For root headers, the index must be stored in a level two batch that represents the corresponding subtree. The header information is encoded into 16-bit pointers that are stored in the array. The two pointer bits encode what kind of pointer it is, and the remaining 14 bits are either indexes to the next jump table or to a field that contains level two batches.

To find the correct pointer, the bit vector is divided into 16 bit masks of 2 ¹² = 4096. The pointer position in the array is further obtained by adding three entities: base index, six-bit offset and four-bit offset. The base index plus the six-bit offset determines where pointers are stored corresponding to a particular bit mask. The four-bit offset determines which of these pointers to select. Figure 7 shows how these entities are found. The following paragraphs develop this procedure.

Since bit masks are generated from a full prefix tree, not all 16-bit combinations are possible. A non-zero bit mask of length 2n can be any combination of two bit masks of length n or a bit mask of 1. Let a (n) be the number of possible non-zero bit masks of length 2. and (n) is defined by recurrence a (0) = 1, and (n) = 1 + and (n-1) ² .

The number of possible bit masks with a length of 16 is therefore a (4) + 1 = 678, where the added one is because the bit mask can be zero. Thus, an index to a table with an entry for each bit mask only needs 10 bits.

Such a table, the mapping table, is maintained to map the bit numbers in the bit mask to a four-bit offset. This offset specifies how many pointers need to be skipped to find the desired pointer so that it is equal to the number of set bits smaller than the bit index. These offsets are the same for all redirection tables, no matter what pointer values they currently have. The mapping table is constant and is generated once and for all.

To to to • to to to to to to • • • to • • • to «♦ ♦ ♦ ·

Possible bit masks have the property that any bit interval whose length is an even power of two and starts at a bit index that is a multiple of the same power of two, either 1) contains all zeros or 2) has the lowest bit set.

Mapping from bit mask and bit to offset provided by the mapping table, together with prefix extension that completes the prefix tree and allows mapping to be used, is the key to achieving a small redirection table size.

Actual bit masks are not necessary and instead a 16-bit codeword array consisting of a 10-bit index into a mapping table and a 6-bit offset is stored. The 6-bit offset spans up to 64 pointers, so one base index is needed for four code words. Because there may be up to 64K of indicators will be the base index greater than 16 bits (2 ¹⁶ - 64K).

In the procedure shown in Fig. 7, the following pseudo-code steps are required to search the first level of the data structure, wherein the codeword field is called code, the base address field is called base, ix is the IP address portion with the first index in the codeword field, IP addresses with a column index in the mapping table, ten (ten) is the part of the codeword with the row index to the mapping table, bix is the part of the IP address with the second index to the base address field, and pix is a pointer to the pointer field containing the indexes to the next jump table as well as indices up to the level two batch.

íx: = upper 12 bits of IP address bit: = lower 4 of upper 16 bits of IP address code word: = code [ix] ten: = ten bits of code word six: = six bits of code word bix: = upper 10 bits of IP addresses • ··· • · ι pix: = base [bix] + six + mapping_table [ten] [hitting] pointer: = level_level_1 [pix]

Thus, only a few bit selections, field references, and additions are needed. No multiplication and division instructions are required, except for implicit multiplication when indexing an array.

A first level search requires access to a total of 7 bytes: two bytes of the codeword, two bytes of the base address, one byte (actually 4 bits) in the mapping table, and finally two bytes of the pointer. The size for the first level is 8 bytes for the codeword field, 2 bytes for the base index field plus the number of pointers.

5.3 The bytes required by the mapping table are shared by all three levels.

If the bit mask is equal to zero or has one bit set, the pointer must be an index to the next jump table. Such pointers may be encoded directly into the codeword, and thus the mapping table need not include entries for bit masks zero and one. The number of entries in the mapping table is thus reduced to 676 (indexes 0 to 675). If ten bits in the code word (ten upper) are greater than 675, the code word represents a direct index to the next jump table. Six bits of the codeword are used as the lower 6 bits in the index and (ten-676) are the upper bits in the index. This encoding allows a maximum of (1024-676) x ²⁶ = 22272 indexes of the next jump, which is more than the 16K for which the design was created. This optimization eliminates three memory references when the routing record is located at a depth of 12 or more and significantly reduces the number of pointers in the pointer array. The price for this is comparison and conditional jump.

The mapping includes the following data and functions in C programming language.

000 · 000

00 00 0 0 0 0 0000 00 «·

An important feature of this code is that the mapping it provides is from an individual bit mask to an offset field.

Changes such as permutation of mtable (and mt) records give the same mapping. Likewise, other ways to represent an offset field, such as two 32-bit words instead of four 16-bit words.

/ ‘Mapping table 7 #define MAPVECLEN 4 typedef uintl 6 MAPVEC [MAPVECLEN];

typedef MAPVEC MCOMPACT;

MCOMPACT mt [TMAX];

/ * mt is a mapping table used during searches and initialized from mtable that is used during construction 7 typedef struct mentry {uintl6 mask; / * 16 bit shape (LSB is always set!) 7 uint16 len; / * 8 bit len (value 1-16) 7 MAPVEC maps; / * 16 4-bit offsets in groups of four 7} MENTRY, * MP;

void mentry2mcompact (MENTRY * from, MCOMPACT‘to) / * takes part of the map from "from" and puts it in "to" 7} int i;

for (i = 0; i <MAPVECLEN; i ++) {* * · · .. .. .. .. .. .. .. .. .. * * * * ];

}}

extern void mtable_compact {) / * initializes mt from mtable * / {

register int i;

for (i = 0; i <TMAX; i ++) {ment2mcompact (& mtable [ij, & mt [i]);

}}

Levels two and three data structures consist of batches. The batch covers a subtree of height 8 and can contain a maximum of ²⁸ = 256 headers. The root header at level n-1 points to a batch at level n. There are three kinds of batches, depending on how many headers the imaginary bit vector contains. If it is:

- 8 headers, the batch is sparse and is represented by an array of 8-bit header indexes and eight 16-bit pointers, which is a total of 24 bytes;

9-64 header, the dose is dense and is represented analogously to level 1 except for base indexes. The difference is that only one base index is needed for all 16 code words, because the 6-bit offset covers all 64 pointers. A total of 34 bytes are needed, plus 18 to 128 bytes for the indicators;

- 256 headers, the batch is very dense and is represented analogously to level 1. 16 code words and 4 base indexes give a total of 40 bytes. In addition, 65 to 256 pointers need 130 to 512 bytes.

’** ** ** ΐ · · · ·« · · · · · ** · · · · · ** ** ** **

Dense and very dense doses are searched analogously to the first level. Sparse batches are searched by a dedicated binary search, which is specially designed for 8 elements. This is significantly faster than linear scan and general binary scan. In addition, this search can be implemented without the use of conditional jumps in processor architecture that have conditional move instructions.

/ * search function for sparse batches 7 static inline uintl6 findsparse (SPARSECHUNK * chu, uint32 val) / * chu-> vals is an array of 0..7 eight-bit chu-> rtnfo values corresponding to 0..7 pointers val is searchable key {

uint * * p, * q;

p = q = & (ch-> vals [0]);

P ^{+ =} (* (P + 3)> val)

P ^{+ =} (* (P + 1)> val) <<1; p + = (* p>val);

lips (ch-> rinfo [p - q]);

}

Dense and very dense doses are optimized analogously to level 1 as described above. In sparse batches, two consecutive headers may be merged and represented smaller if their other jumps are identical. When deciding whether the dose is dense • · * · + ·· «····

Or sparse, this merging is considered, so the batch appears sparse if the number of merged headers is 8 or less. Many of the end nodes that have been added to the tree will be sorted and will have the same additional jumps. Headers corresponding to such internal nodes will be merged into sparse batches.

Such optimization shifts the dose distribution from larger dense doses towards smaller sparse doses. For large tables, the redirection table size is typically reduced by 5 to 15 percent.

The data structure is able to cope with a substantial increase in the number of routing records. There are two limitations in the current proposal:

1. The number of doses of each species is limited to 2 ¹⁴ = 16384 per level.

Table 1 shows that this is about 16 times more than currently used. However, should the limit be exceeded, the data structure may be modified so that the pointers are encoded in another way to allow more space for indexes or to increase the pointer size.

2. The number of indicators at levels two and three is limited by the size of the base indexes.

The current implementation uses 16-bit base indexes and is able to accommodate growth 3 to 5x. Should this limit be exceeded, the size of the base indicators can be simply increased to three bytes. This increases the dose size by 3% for dense doses and by 10% for very dense doses. Sparse benefits are not affected.

Obviously, the data structure is capable of accommodating a large increase in the number of routing records. Its size will grow almost linearly with the number of routing inputs.

• ♦ ··

A number of IP routing tables have been collected to investigate the performance of redirection tables. Internet routing tables are currently available on the Internet Performance Measurement and Analysis (IPMA) website (http: /www.ra.net/statistics/) and were previously made available by the now completed Routing Arbiter project (http: /www.ra.net / statistics /). The collected routing tables are daily snapshots of the routing tables used on various large Internet connection points. Some of the routing entries in these tables contain more jumps. In such cases, one of them was randomly selected as the next jump used in the redirection table.

Table 1 in Figure 8 shows the data of redirection tables constructed from different routing tables. For each location, it shows the data and results for the routing table that generated the largest largest redirection table. The routing records indicate the number of routing records in the routing table, and the next jumps indicate the number of different other jumps that were found in the table. End nodes indicate the number of end nodes in the prefix tree after the end nodes have been added to be added to the solid tree.

The creation time in Table 1 is the time required to generate a redirection table from a routing table representation in the form of a binary tree in memory. Times were measured on an Alpha 333 MHz processor running under DEC OSF1. The following columns show the total number of sparse, dense, and very dense batches in the generated table, followed by the number of batches at the lowest level of the data structure.

It can be seen from Table 1 that a new redirection table can be generated quickly. At 1 Hz, less than one-tenth of the Alpha processor's capacity is consumed. As previously stated, regeneration frequencies higher than 1 Hz are not required.

The largest tables in Table 1 do not fit entirely into the 96 Kbyte Alpha processor secondary cache. However, it is possible to have a small, very fast SRAM in the third-level cache for those portions that do not fit in the secondary cache and thereby reduce the cost of not found in the secondary cache. With certain points in the nature of the traffic, most memory references will be in the secondary cache.

An interesting observation is that the size of these tables is comparable to what it would take to simply store all the prefixes in an array. For these large tables no more than 5.6 bytes per prefix is needed. More than half of these dwellings are consumed by indicators. The Sprint table has 33469 pointers that need over 65 Kbytes of memory. It is clear that further redirection table reductions can be achieved by reducing the number of pointers.

Measurements on the search routine are performed on a C function compiled with the GNU C-compiler gcc (published in Using and porting gnu cc. Manual, Free Software Foundation, November 1995, ISBN 1-882114-66-3). The reported times do not include function calls or memory accesses to the next jump table, gcc generates code that uses approximately 50 Alpha processor instructions to search one level of data structure in the worst case. For the Pentium Pro processor, it generates gcc code that uses 35 to 40 instructions per level in the worst case.

The following C function shows the search function code used for measurement.

· Toto toto to to to to to to to toto toto toto toto toto toto

The level 1 codeword field is called intl and the basel base index field. Level 1 indicators are stored in the htabl field. Batches are stored in the fields c / s, c / d, c / dd, where / 'is the level. Base addresses and pointers for dense and very dense batches are stored in the base / d, base / dd, and htab / d, htab / dd fields.

/ * lookup function for redirection table 7 #include “conf.h #include forward.h” #include “mtentry.h” #include “mtable.h” #include “bitindex.h” #define TABLE_LOOKUP #include “sparse.h ' ¹ #include “timing.h” #include “lookup.h” / * these macros only work if the ip is a 32-bit unsigned integer (uint32) 7 #define EXTRACT (start, bits, ip) ( ((ip) << (start)) >> (32 - (bits))) #define GETTEN (m) (((m) «22)» 21) #define GETSIX (m) {(m) »10) #define bit2o (ix, bit) ((mt [(ix)] [(bit) »2]» (((bit) & 0x3) «2)) & Oxf) / * lookup (ipaddr) - index to routing table entry for ipaddr 7 • unsigned int lookup (uint32 ipaddr) {

uint32 ix; Γ index to the code field * Z uint32 code; Z * 16 bit codeword * / int32 diff; / * unlike TMAX * / uint32 ten; / * index to mt * / uint32 six; / * six "extra" bits of code * / int32nhop; / * next jump pointer * / uint32off; / * pointer offset * / uint32hbase; / * base for transformation table uint32pntr; Z * record in transformation table int32 kind; Type pntr * uint32chunk; Batch index * uint8 * p, * q; Z * search bar sparse * / uint32 key; Z * search key in sparse * / / * time measured • THERE * Z ix = EXTRACT (0.12, ipaddr); code = int1 [ix]; ten = GETTEN (code); six = GETSIX; if ((diff = (ten-TMAX))> = 0) { nhop = (six I (diff (6));

goto end;

} off = bit2o (ten, EXTRACT (12.4, ipaddr)); hbase = basel [ix >> 2]; pntr = htab1 [hbase + six + off];

if ((kind = (pntr & 0x3))) {·· ·· · * ·· · chunk = (pntr >> 2);

if (~ kind) {if (-kind) {key = EXTRACT (16.8, ipaddr); p = q = c2s [chunk] .vals [0]);

if (* (p + 3)> key) {

P + = 4;

};

while (* p> key) {

P ++:

pntr = c2s [chunk] .rinfo [p-q];

} eis {ix = EXTRACT (16.4, ipaddr); code = c2dd [chunk] [ix]; ten = GETTEN (code); six = GETSIX;

if ((diff = (ten-TMAX)) > = 0 {nhop = (six | (diff << 6)); goto end;

hbase - htab2ddbase [(chunk << 2) j (ix >> 2)];

• 9 10 000 0 · * 0 φ 0 0 0 0 0 * ·· 00 9 «0 0000 0000 0000 0 * 00 00 ··> 0 · * off = bit2o (the one, EXTRACT (20.4, ipaddr)); pntr = htab2dd [hbase + six + off];

}} else {ix = EXTRACT (16.4, ipaddr); code = c2d [chunk] [ix]; ten = GETTEN (code); six = GETSIX;

if ((diff = (ten / TMAX)) > = 0) {nhop = (six | (diff << 6)); goto end;

hbase = htab2dbase [chunk];

off = bit2o (ten, EXTRACT (16.4, ipaddr));

pntr = htab2d [hbase + six + off];

} if ((kind = (pntr & 0x3))) {chunk = (pntr »2);

if (-kind) {

If (-kind) {key = EXTRACT (24.8, ipaddr); p = q = c3s [chunk] .vals [0]);

if (* (p + 3)> key) {

P + = 4;

};

··· • ···· • · «• · ·· ·· ·» · ·· while {ρ *> key) {p ^++;

};

pntr = c3s [chunk] .rinfo [p-q];

else {ix = EXTRACT (24.4, ipaddr); code = c3d [chunk] [ix]; ten = GETTEN (code); six = GETSIX;

if ((diff = (ten / TMAX)) > = 0) {nhop = (six | (diff << 6)); goto end;

} off = bit2o (ten, EXTRACT (28.4, ipaddr)); hbase = htab3ddbase [(chunk << 1) | (ix >> 2)]; pntr = htab3dd [hbase + six + off];

}} else {ix = EXTRACT (24.4, ipaddr); code = c3d [chunk] [ix]; ten = GETTEN (code); six = GETSIX;

if {(diff = (ten / TMAX))> = 0) {nhop = (six (diff << 6)); goto end;

* · «« Φ φ φ · · · ·

off = bit2o (ten, EXTRACT (28.4, ipaddr)); hbase = htab3ddbase [chunk]; pntr = htab3dd [hbase + six + off];

}}

} nhop = (pntr >> 2);

end:

/ * time measured by SEM! * / return nhop;

}

The Alpha and Pentium Pro processors can read the instantaneous counter of the clock cycle. This option was used to measure search time with great accuracy. One clock period is 5 nsec at 200 MHz and 3 nsec at 333 MHz.

Ideally, the entire redirection table would be placed in a cache so that the lookup would be performed with a cache that is not disturbed. This would emulate the cache behavior in a dedicated redirection resource. However, measurements have been performed on conventional general purpose workstations and in such systems it is difficult to control the contents of the cache. This cache is interrupted at every I / O operation, interrupt, or at the start of the next process. Without interrupting the cache, it is not even possible to print measurement data or read a new IP address from a file.

Fefefe * fefe * fe

The method used performs each search twice and measures the search time of the second search. In this method, the first cache search is interrupted and the second cache search is where all the necessary data has been placed in the primary cache at the first search. After each search pair, the measurement data is printed and a new address is called, a procedure that again clears the cache.

The performance of the second lookup is better than the lookup in the redirect, because the data and instructions move into the primary cache closer to the processor. To obtain the upper limit of the search time, it is necessary to add to the measured times the additional time required to access the secondary cache. To test all redirection table paths, the search time for each record in the routing table was measured, including those that were added for the full tree extension.

Average search times cannot be derived from these experiments because the actual traffic pattern is unlikely to have an even likelihood of access to each routing record. In addition, certain traffic points will keep frequently accessed parts of the data structure in the primary cache, thereby reducing average search times. The performance data calculated below is conservative because it is assumed that all memory accesses will pass the primary cache and hence the worst case execution time will always occur. Realistic search speeds will be higher.

Table 1 shows that there are very few batches in the third level of the data structure. This suggests that the vast majority of searches will not need to search more than two ········ ♦ ·

0 · ·· levels to find the next jump. Therefore, the additional time for accesses to the secondary cache is calculated for eight accesses instead of the twelve accesses in the worst case. If a significant portion of the searches accessed these multiple batches, these batches would be moved to the primary cache, making all twelve accesses less expensive.

The experiment was performed on an Alpha 21164 processor with a clock frequency of 333 MHz, so one cycle lasts 3 nsec. As shown in Table 2 of FIG. 9, the accesses to the 8-byte primary cache are 2 cycles and the accesses to the 96-byte secondary cache require 8 cycles.

Fig. 10 shows for Alpha processor the distribution of hourly cycles that expire during the second Sprint lookup of January 1. The fastest observed searches require 17 clock cycles. These are the cases where the code word in the first level directly encodes the index into the next jump table. There are very few such routing records, but since each such routing record covers many IP addresses, the actual traffic may contain many such destination addresses. Some searches need 22 cycles, which must be the same as the previous one. Experiments confirmed that if the clock cycle counter is read with two consecutive instructions, the difference is occasionally 5 cycles instead of the expected 0 cycles.

The next peak in FIG. 10 is on 41 hour cycles. This is the case when the pointer found in the first level is an index to the next jump table. Traditional Class B addresses fall into this category. Peaks on 52-53, 57, 62, 67, and 72 clock cycles correspond to finding a pointer after examining one, two, three, four, or five values in a low level 2 dose. cycles are needed

00 0 0 0 for searching a dense or very dense dose. A few observed peaks above 83 correspond to the indicators found after scanning a sparse dose of level 3, probably due to variations in execution time. Conflicts in the secondary cache or differences in the chained state and the cache system can cause these variations. The remainder of the observed peaks over 100 hour cycles are caused by either such variations or not found in the cache. 300 nsec should be sufficient for the search if all data is in the primary cache.

The difference between data access in the primary cache and in the secondary cache is 8-2 = 6 cycles. Searching the two levels of the data structure in the worst case needs 8x6 = 48 clock cycles more than shown in Figure 10. This means that 100 + 48 = 148 cycles or 444 nsec is sufficient for the worst case of two-level search. Therefore, the Alpha processor is capable of performing at least 2.2 million routing scans per second, with a redirection table located in the secondary cache.

Another experiment was performed on a Pentium Pro processor with a clock frequency of 200 MHz, so one clock cycle lasts 5 nsec. The primary cache of 8 bytes has a latency of 2 cycles and the secondary cache has a latency of 6 cycles, as shown in Table 2.

Figure 11 shows for the Pentium Pro the distribution of the clock cycles that pass during the second search in the same redirection table as the Alpha 21164. The sequence of instructions that invokes the clock cycle counter takes 33 clock cycles. When two invocations are executed in succession, the counter values will differ by 33. For this reason, all reported times must be reduced by 33 cycles.

The fastest observed searches are 11 cycles, which is roughly the same speed as the Alpha 21164 processor. The 25 cycles show a peak corresponding to the case when the next jump index is found immediately after the first level. The peaks corresponding to the second level sparse dose are grouped over a range of 36 to 40 cycles. The different cache structure in the Pentium processor seems to cope better with linear scans than the cache structure in the Alpha 21164 processor.

If the second level doses are dense and very dense, the search needs 48 and 50 cycles, respectively. There are a few irregular spikes in the figure up to 69 cycles, with very little observation above this value. Obviously, 69 cycles (345 nsec) are sufficient to perform a lookup if all data is in the primary cache.

The difference in access time between the primary and secondary cache is 20 nsec (4 cycles). If two levels need to be investigated, the search time for the Pentium Pro processor is at worst 69 + 8x4 = 101 cycles or 505 nsec. Thus, the Pentium Pro processor can perform at least 2 Mition routing scans per second when the redirection table is in the secondary cache.

The present invention provides an improved IP routing search method and system that fully corresponds to the objectives and advantages shown above. Although the invention has been described in connection with a specific embodiment, alternatives, modifications and variations will be apparent to those skilled in the art.

···· ···· κ

In the above-described arrangement, the search function is implemented in the C programming language. Those skilled in the art will recognize that other programming languages may be used. Alternatively, the search function can be implemented in hardware using conventional digital design techniques, as is also apparent to those skilled in the art of hardware design.

For example, the invention is applicable to computer systems other than those using Alpha 21165 or Pentium Pro processors, it is possible to perform prefix tree cuts in different ways, different number of levels in the tree, different ways of representing a mapping table and other ways of coding code words.

In addition, the invention can be used for the routing search of firewalls.

Claims (2)

PATENT CLAIMS A method of routing lookup in an Internet protocol in a routing table, consisting of records of any prefix length with associated next hop information in the next hop table, to determine where datagrams in the Internet protocol are to be redirected, characterized in that: that consists of the steps of storing a routing table representation in the memory means in the form of a complete prefix tree (7) defined by the prefixes of all routing table entries and supplemented so that each node has either no or two successors and all added successors are end nodes with the same the next jump as the closest predecessor with information about the next jump or an undefined next jump, if no such predecessor exists, storing in said storage means a representation of the bit vector (8) containing the prefix tree section data (7) at a general depth (D) with one bit for each possible node at that general depth, where that bit is set, if a node exists in the prefix tree (7), storing in the said memory means a pointer array, which for the right headers is an index dividing the bit vector (8) into bit masks of a certain length, storing in said storage means a representation of the possible bit masks in the mapping table, storing in said storage means an array of code words, each coding row lines index to the mapping table and pointer offset, «000 0 · · 0 • 0 stored in said base address field memory, access to the codeword in the codeword field at a location corresponding to the first index portion (ix) of the Internet protocol address, access to the record in the mapping table at that point in the mapping table e, which corresponds to a portion of an Internet protocol address with a column index (bit) and a codeword portion with a row index (ten), accessing a base address in a base address field at a location corresponding to a second index portion (bix) of the Internet protocol address an array of pointers in place corresponding to the base address plus the pointer offset (six) in the codeword plus portions of the mapping table entry. 2. An Internet Protocol routing lookup system in a routing table, consisting of records of arbitrary prefix length with associated next hop information in the next hop table, to determine where datagrams in the Internet protocol should be redirected, characterized by comprising a routing table in the memory means in the form of a complete prefix tree (7) defined by the prefixes of all routing table entries, where each node has either no or two successors and all the added successors are end nodes with the same next hop information as the nearest predecessor information about another jump or with an undefined next jump, if no such predecessor exists, a representation of the bit vector (8) containing the prefix tree (7) section data at a general depth (D) with one bit for each possible node at that general depth this b it is set if a node exists in the prefix tree (7), ν · * ··· · pointer array, which is the index to the next jump table for the right headers and the index to the next level batch for the root headers, bit vector distribution (8) into bit masks of a certain length, a mapping table made up of a representation of possible bit masks, an array of code words, each encoding a row index into a mapping table, and an offset of a pointer and a base address array. Represented by: Dr.Miloš Všetečka v.r. · Fe fe fe fe fe fe ♦ ♦ * * * * * * * * * * »*» During the proceedings on this PCT application No. PCT / SE98 / 00854, the wording of the patent claims has been modified (based on the International Preliminary Examination). The amended version of these claims is attached hereto. The amendments apply to pages 33-36.